Demandez à une équipe sécurité combien d'employés ont accès à la production. Elle vous donnera un nombre, et il sera à peu près juste.
Demandez combien d'agents, de scripts et de comptes de service l'ont. La pause avant la réponse est tout le problème.
Un agent n'est ni un utilisateur ni un compte de service
Les systèmes d'identité ont été bâtis sur deux hypothèses, et les agents cassent les deux.
Une identité humaine a une personne attachée. Il y a un manager, un ordinateur portable, une date d'arrivée et — surtout — une date de départ qui déclenche le retrait des accès. Quand quelqu'un change de rôle, une revue d'accès attrape les permissions devenues inutiles. Tout l'appareil repose sur un cycle de vie humain.
Le compte de service est l'autre modèle : un identifiant fixe qui fait une chose prévisible, selon un horaire. Il exécute la même requête chaque nuit. S'il lit soudain une autre table, c'est une anomalie qui mérite enquête.
Un agent n'est ni l'un ni l'autre. Il n'a aucun événement de cycle de vie auquel accrocher le retrait d'accès, et son comportement n'est pas prévisible par conception — tout l'intérêt est justement qu'il décide quoi faire. La détection d'anomalies qui fonctionne pour les comptes de service produit des faux positifs en continu face à quelque chose dont l'état normal est de faire du nouveau.
Fig. — Les deux modèles de contrôle sur lesquels les systèmes d'identité ont été bâtis. Les agents n'entrent dans aucun.
Les trois défaillances observées en pratique
Des identifiants surdimensionnés, presque partout. Un agent doit lire dans six systèmes — alors il reçoit une clé à large accès sur les six, parce que la limiter proprement exigerait six conversations avec six responsables. Cette clé est désormais l'identifiant le plus précieux du parc — et elle vit quelque part où un agent victime d'injection de prompt pourrait être persuadé de s'en servir.
Aucun chemin de révocation. Quand un humain part, les RH déclenchent le départ. Quand une équipe cesse d'utiliser un agent, rien ne déclenche rien. L'identifiant reste valide indéfiniment, attaché à une charge de travail que personne ne surveille, référencé dans un fichier de configuration dont l'auteur est parti depuis longtemps.
L'effondrement de l'attribution. Un agent agissant pour le compte d'un utilisateur s'authentifie généralement en son propre nom — le journal d'audit enregistre donc l'agent, pas la personne dont la demande l'a mis en mouvement. Quand quelque chose tourne mal, vous voyez ce qui s'est passé, mais ni pourquoi ni pour qui. En environnement régulé, ce n'est pas un désagrément ; c'est un constat d'audit.
Le problème d'injection sous tout cela
Il existe un mode de défaillance sans équivalent propre dans la sécurité traditionnelle, et il mérite d'être dit platement.
Un agent qui lit du contenu non fiable — un e-mail, un ticket de support, une page web, un document déposé par un client — peut être instruit par ce contenu. L'instruction arrive comme donnée et se fait traiter comme intention. Un attaquant n'a pas besoin de compromettre les identifiants de votre agent ; il lui suffit de placer du texte là où l'agent lira.
C'est pourquoi le périmétrage des permissions compte plus ici que dans les systèmes conventionnels. Vous ne pouvez pas totalement empêcher un agent d'être manipulé. Vous pouvez faire en sorte qu'un agent manipulé n'ait rien de précieux à atteindre.
Conséquence pratique : supposez que tout agent qui touche du contenu externe finira par faire quelque chose qu'un attaquant lui aura dicté — et concevez le rayon d'explosion en conséquence.
À quoi ressemble le bien
Une identité par agent, par environnement. Des identifiants partagés entre plusieurs agents détruisent l'attribution au moment précis où vous en avez besoin — c'est-à-dire toujours pendant un incident.
Des périmètres assez étroits pour être inconfortables. Si un agent rapproche des factures, il lit des factures et écrit des enregistrements de rapprochement. Il n'a pas besoin des données personnelles des clients — et le fait que les accorder soit plus facile n'est pas une raison.
Des identifiants éphémères plutôt que des clés statiques. Un agent qui récupère un jeton valable quinze minutes est un problème catégoriquement plus petit qu'un agent détenant une clé valable jusqu'à ce que quelqu'un la fasse tourner — c'est-à-dire pendant des années.
Une expiration sur chaque identité d'agent. Pas un rappel de revue — une vraie expiration qui l'arrête. Le renouvellement doit exiger que quelqu'un confirme que c'est encore nécessaire. Ce seul contrôle élimine le problème de l'agent abandonné — autrement insoluble, parce que personne ne remarque une absence.
Et l'identité déléguée là où elle existe : l'agent agissant pour un utilisateur précis doit porter le contexte de cet utilisateur dans la piste d'audit — pour que le journal réponde au qui autant qu'au quoi.
Pourquoi l'outillage n'a pas suivi
Il vaut la peine de comprendre pourquoi c'est difficile, plutôt que de supposer vos fournisseurs simplement en retard.
Les plateformes d'identité sont bâties autour d'annuaires de personnes. Le modèle de données a un humain au centre, avec des attributs comme le service et le manager — et les fonctions de gouvernance — revues d'accès, campagnes de certification, séparation des tâches — supposent toutes qu'un humain répond à une question sur un autre humain. Y forcer des agents produit des résultats bancals : une revue d'accès qui demande à un manager de certifier si un logiciel a encore besoin d'une permission qu'il ne comprend pas.
Les fournisseurs cloud ont les primitives d'identité machine — fédération d'identité de charge de travail, jetons éphémères, rôles par charge — et elles sont réellement bonnes. Le manque : elles opèrent à la couche infrastructure, tandis que le comportement réel de l'agent se joue à la couche applicative. Votre fournisseur cloud peut vous dire qu'une charge a assumé un rôle. Il ne peut pas vous dire que l'agent a ensuite lu quatre cents fiches clients parce qu'un ticket de support le lui a demandé.
C'est dans ce manque que se loge la génération actuelle d'outillage, et elle est jeune. En attendant, les contrôles qui marchent sont les sans-gloire : périmètres étroits, identifiants courts, expirations dures — et quelqu'un dont le nom figure dessus.
Par où commencer
L'inventaire d'abord — et attendez-vous à ce que le nombre soit faux. La plupart des organisations découvrent des agents et des intégrations que personne ne se souvient d'avoir commandés, détenant des identifiants que personne ne peut justifier. Cette découverte est inconfortable — et c'est le but de l'exercice.
Pour chacun, trois questions. Que peut-il atteindre ? Que nous coûterait sa compromission totale demain ? Qui en est propriétaire — nommément ?
La troisième question est celle qui échoue le plus souvent — et l'agent sans propriétaire nommé est celui qui tournera encore avec un accès production dans deux ans.
Puis réparez d'abord le pire rayon d'explosion. Pas le plus grand nombre d'agents, pas le plus facile — le seul identifiant dont la compromission ferait le plus mal. Réduisez son périmètre, posez une expiration — et vérifiez que la piste d'audit enregistre réellement ce qu'il fait.
Ce n'est pas tant une nouvelle discipline qu'une ancienne, appliquée à une population qui a grandi plus vite que tous les processus. Les organisations qui s'en sortent bien ne sont pas celles au meilleur outillage. Ce sont celles qui ont commencé à compter avant d'avoir une raison de le faire.
