Si un agent effectue des opérations dans les systèmes de l'entreprise, une identité se tient derrière ces opérations. Qui est cette identité reste l'une des questions les plus escamotées en production.
01. Deux modèles
L'agent agit soit au nom de l'utilisateur, soit sous une identité de service propre. Dans le premier cas il est borné par les droits de l'utilisateur et la traçabilité va de soi. Dans le second, la tendance est d'accorder de larges droits — et c'est là le risque.
02. Le piège des droits larges
Un agent tournant avec des droits d'administrateur "pour simplifier" signifie un accès total en cas de manipulation de consigne. Le moindre privilège pèse ici plus que dans les applications classiques.
03. Bornes au niveau des outils
Accordez les droits au niveau de l'outil, pas du système. Quels outils l'agent peut appeler et quels enregistrements chaque outil peut toucher se définissent séparément.
04. Opérations d'écriture
Les outils qui créent, modifient ou suppriment doivent exiger une validation. Ne pas exposer directement les opérations irréversibles à un agent est un principe de base ; argent, contrats et communication externe en relèvent.
05. Limite de durée
Ne donnez pas de clés permanentes aux identités d'agent. Des identifiants à courte durée et de portée étroite bornent les dégâts en cas de fuite.
06. Piste d'audit
Chaque opération doit consigner quel agent l'a faite, sur quelle demande d'utilisateur et dans quelle exécution. Cette chaîne est le seul moyen de remonter à la source d'un problème.