Le point de vue de Souleymane
Kabbaj chez Squad, Practice Leader Identité & Zéro Trust.
La gouvernance des
identités non humaines s'impose comme le nouveau front de l'IAM : comptes
techniques, workloads, clés d'API, bots et agents automatisés dépassent
désormais largement les utilisateurs humains dans de nombreux systèmes
d'information.
Une explosion
d'identités difficiles à recenser
Les identités non
humaines (NHI) regroupent comptes de service, secrets applicatifs, certificats,
clés d'API, bots RPA, agents d'IA, objets connectés et workloads cloud,
tous associés à des droits d'accès bien réels. Avec la généralisation des
architectures cloud natives, des micro-services et surtout l'arrivée des agents
IA autonomes, qui peuvent eux-mêmes engendrer de nouvelles NHI, elles excèdent
désormais largement les identités humaines : sur les environnements cloud
natifs, le ratio mesuré atteint 144 pour 1, contre 92 pour 1 un an plus tôt.
Peu visibles des équipes applicatives, IAM et sécurité, elles forment une «
masse sombre » où droits surdimensionnés et persistants ouvrent un terrain
idéal aux attaquants.
Des risques systémiques
sous-estimés
Les identités machines
disposent fréquemment de privilèges élevés par praticité, à l'opposé du moindre
privilège (« avec tous les droits, je suis sûr que cela fonctionne »), sans
revue régulière ni propriétaire identifié. Comptes techniques laissés actifs
après une migration, tokens d'API à durée de vie excessive, mots de passe de
service codés en dur : autant de portes d'entrée discrètes mais critiques. Le
paradoxe est net au regard du Zero Trust, les contrôles se resserrant sur les
humains pendant que les machines conservent une confiance implicite.
Un token OAuth
compromis, une clé API exposée dans un dépôt Git ou un service principal
surprivilégié permettent de contourner les mécanismes appliqués aux
utilisateurs : leur exploitation est devenue une étape centrale des
compromissions cloud récentes. S'y ajoute une échéance peu anticipée : la durée
de vie maximale des certificats TLS, ramenée à 200 jours depuis mars 2026,
tombera à 100 jours en mars 2027, rendant toute gestion manuelle intenable.
Les agents IA déplacent
la nature du problème
L'arrivée des agents
autonomes ajoute une catégorie d'identités et remet en cause, dans le même
mouvement, les cadres construits pour les gouverner. La supervision
comportementale suppose un comportement attendu stable, qu'un agent non
déterministe ne présente pas ; l'inventaire par découverte périodique suppose
un parc plus lent que le cycle de scan, alors qu'un agent peut instancier ses
propres identifiants à l'exécution. Surtout, dans la majorité des déploiements
observés, l'agent n'agit pas sous une identité propre mais par délégation de
celle d'un collaborateur : la frontière entre identités humaines et non
humaines, sur laquelle repose l'essentiel des dispositifs IAM actuels,
s'estompe. L'écart entre usage et maîtrise est documenté : en 2026, plus de
neuf organisations sur dix utilisent des agents IA, une sur dix seulement
dispose d'une stratégie aboutie pour les gérer.
Les nouvelles approches
ne considèrent plus les NHI comme de simples variantes des comptes
utilisateurs. Elles combinent découverte continue, attribution d'un
propriétaire, gestion du cycle de vie, moindre privilège, hygiène des secrets,
traçabilité probante et capacité d'interruption. Les deux derniers leviers sont
les moins outillés, et ceux qui résistent le moins bien aux agents.
La traçabilité,
condition de l'imputabilité
Quand un agent
déclenche un virement, modifie un droit d'accès ou publie un correctif en
production, le journal applicatif montre une action autorisée par un jeton
valide, sans indiquer qui l'a voulue, sous quelle autorité, ni qui en répond.
Trois niveaux doivent être consignés : l'identité technique (credential),
l'identité d'exécution, l'agent ou le workload qui agit, et l'identité
d'origine, la personne ou le processus qui a mandaté l'action. Un journal qui
ne consigne que la première n'a aucune valeur d'imputabilité. Consigner ne
suffit d'ailleurs pas : un log modifiable et non scellé ne constitue pas une
preuve. Horodatage qualifié, chaînage cryptographique, écriture unique et
exploitabilité réelle au moment de l'incident forment le socle minimal, que le
règlement européen sur l'IA, NIS2 et DORA imposent chacun dans leur périmètre,
sans distinguer l'auteur humain de l'auteur machine.
L'arrêt d'urgence (kill
switch), à concevoir avant l'incident
Désactiver un compte
utilisateur fait tomber les sessions. Révoquer le credential d'un agent
n'arrête rien de ce qui est déjà engagé : les jetons porteurs émis restent
valides jusqu'à expiration si les ressources consommatrices ne vérifient pas
leur révocation à chaque appel, et les sous-processus auxquels l'agent a
délégué ses droits continuent d'agir après sa désactivation. La capacité
d'arrêt dépend donc de la durée de vie des jetons et de la connaissance de la
chaîne de délégation. Un mécanisme exploitable est gradué, de la suspension des
nouveaux appels au gel des écritures puis à la révocation complète, chaque
niveau associé à un impact métier documenté. Il doit être déclenchable par la
supervision sans validation hiérarchique, et testé périodiquement : un
dispositif jamais exercé n'est pas un dispositif disponible.
Un enjeu stratégique
La montée en puissance
de l'IA, de la RPA et du multi-cloud ne fera qu'accélérer cette prolifération.
Les organisations qui tardent à intégrer ces identités dans leur gouvernance
IAM bâtissent leur cybersécurité sur un socle truffé de comptes critiques échappant
au radar.
L'enjeu n'est plus simplement de gérer des identités, ni même de sécuriser l'ensemble des entités capables d'agir au sein du système d'information, qu'elles soient humaines ou artificielles. Il est de pouvoir interrompre au plus tôt un comportement déviant et d'établir, à tout moment et de manière opposable, qui a fait quoi, sous quelle autorité, et qui en répond.