Comptes zombies : le point aveugle de l’IAM dans le processus de départ

6 Min. de lecture

Un microservice est désactivé, la documentation est archivée et l’équipe passe à autre chose. Le compte de service avec lequel il fonctionnait reste actif, avec des droits que personne ne contrôle plus. OWASP appelle cela le point aveugle numéro un des identités machine, et les attaquants le savent depuis longtemps.

Les points clés en bref

Les machines survivent à leur départ : Les comptes de service, les clés API et les identités de workload restent actifs longtemps après que le service associé ait disparu. Pour les humains, il existe un processus RH, mais pour les machines, il n’y en a généralement pas.
OWASP le classe en premier : Dans la liste des 10 principales vulnérabilités des identités non humaines, le départ inadéquat est classé comme risque NHI1. Les identités orphelines sont en pratique un chemin préféré pour le mouvement latéral.
Le levier est un cycle de vie : Qui inventorie les identités machine, attribue un propriétaire et les lie à la durée de vie du service, ferme la faille avant que la vague de l’IA ne fasse augmenter le nombre de comptes.

Lié :Les comptes que personne ne compte / MFA adaptatif dans l’audit NIS2

Pourquoi les comptes machine survivent à leur propre fin de vie

Lorsqu’un employé quitte l’entreprise, un processus est enclenché. Le département des ressources humaines signale la sortie, le compte est désactivé et les autorisations sont retirées. Pour les identités humaines, ce processus est bien établi, même s’il ne fonctionne pas toujours de manière impeccable. Pour les identités machine, il n’existe pas dans de nombreuses organisations.

Qu’est-ce qu’une identité machine ? C’est tout ce avec quoi un système s’authentifie au lieu d’un humain : comptes de service, clés API, jetons, certificats ou l’identité d’une charge de travail dans le cloud. Ces comptes sont créés de manière incidente lorsqu’un service est configuré. Mais ils ne disparaissent pas de manière incidente lorsque le service est désactivé. La désactivation concerne le code et l’infrastructure, mais rarement l’identité avec laquelle les deux fonctionnaient.

C’est précisément là que OWASP intervient. Dans la liste des 10 principales vulnérabilités des identités non humaines de 2025, le départ inadéquat est classé en premier, devant la fuite de secrets et les comptes surprivilegés. La définition est sobre : la désactivation ou la suppression insuffisante des identités machine lorsqu’elles ne sont plus nécessaires. Derrière la formulation sobre se cache un problème pratique. Personne ne se sent responsable de désactiver un compte dont il ne connaît pas l’existence.

En pratique, un tel compte est créé en quelques secondes et survit pendant des années. Un développeur crée un compte de service pour une intégration, dépose une clé API dans la pipeline, le travail est effectué. Lorsque l’intégration est remplacée plus tard, l’équipe s’occupe de la nouvelle voie, mais pas de la trace laissée par l’ancienne. La clé reste valide, le compte reste autorisé et les deux n’apparaissent dans aucun processus de sortie, car il n’y a pas de sortie pour une machine. Ainsi, des couches d’identités s’accumulent au fil du temps, que personne ne peut plus attribuer à un objectif.

Comment un compte oublié devient un vecteur d’attaque

Un compte de service orphelin n’est pas un risque théorique. C’est une identité valide avec des droits valides, qui n’attire plus aucune attention. Pour un attaquant, c’est la situation idéale. Qui prend le contrôle d’un tel compte se déplace dans le réseau sans déclencher d’alerte, car le compte est légitime et son activité n’est plus surveillée.

Cela se complique avec deux autres points de la liste OWASP, qui apparaissent rarement seuls. Long‑Lived Secrets, c’est‑à‑dire des identifiants sans date d’expiration, rendent un compte orphelin utilisable indéfiniment. Des identités machines sur‑privilégiées lui confèrent davantage de droits que le service d’origine n’aurait jamais nécessité. Les deux ensemble transforment un compte oublié en un point d’ancrage confortable pour le Lateral Movement, c’est‑à‑dire le déplacement latéral d’un système compromis à un autre.

La différence avec une identité humaine est fondamentale, et elle explique pourquoi les routines d’Offboarding éprouvées ne fonctionnent pas ici.

Aspect	Identité humaine	Identité machine
Déclencheur de l’Offboarding	Départ, signalé par les RH	Arrêt du service, souvent non signalé
Propriétaire	La personne elle‑même plus les supérieurs	Souvent incertain ou orphelin
Durée de vie des identifiants	Liée à l’emploi	Souvent sans date d’expiration
Visibilité après la fin	Compte désactivé, accès bloqué	Reste actif, l’utilisation paraît légitime

Le deuxième piège : quand les humains utilisent des comptes machines

Il existe une variante du problème, moins souvent abordée et répertoriée dans la liste OWASP sous le code NHI10 : Human Use of NHI. Il s’agit du cas où un administrateur utilise un compte de service pour une tâche manuelle, simplement parce qu’il est disponible et possède les droits nécessaires. À ce moment‑là, cela fait gagner du temps. Ensuite, la piste d’audit est compromise, et un compte disposant souvent de droits machines étendus se retrouve entre les mains d’un humain sans contrôle.

Dokumentarisches Foto eines unüberwachten Maschinen-Kontos im Serverraum - ein Angriffspfad ohne Alarm. — Les comptes oubliés ouvrent aux attaquants la porte du réseau à leur insu.

Lorsque qu’une action humaine s’exécute sous une identité machine, il devient impossible de séparer proprement, a posteriori, ce qui a été automatisé de ce qui a été déclenché par une personne. Pour l’analyse forensique d’un incident, c’est un vrai problème. Au moment même où l’on a besoin d’une trace claire, les activités privilégiées des machines et des humains se mêlent dans un même journal. Dans les environnements hybrides où les comptes d’administration sont partagés, ce réflexe est encore quotidien, alors que la supervision et la régulation exigent depuis longtemps des traces vérifiables.

Ce qu'il faut pour un cycle de vie NHI propre

Aucune de ces lacunes ne nécessite un nouveau produit. Elles nécessitent un cycle de vie que les identités humaines possèdent depuis longtemps. Trois éléments constitutifs portent la plus grande partie.

Le premier est un inventaire. On ne peut désactiver quelque chose que l'on connaît, et dans la plupart des organisations, il n'y a pas de liste complète des identités de machines actives. Le deuxième est la propriété. Chaque identité de machine a besoin d'une personne responsable ou d'une équipe, sinon le problème de base se répète à chaque désactivation. Le troisième est le couplage au cycle de vie du service. Lorsqu'un service est mis hors service, son identité doit être désactivée dans le même pas, et non dans un pas ultérieur qui ne vient jamais.

La pression sur ce sujet augmente parce que le nombre d'identités de machines avec des agents d'intelligence artificielle et des pipelines automatisés augmente plus vite que toute routine manuelle de départ. Celui qui ne met en place le cycle de vie que lorsque les comptes sont déjà ingérables doit d'abord nettoyer ce qui est déjà une prolifération. Commencer maintenant est nettement moins cher que plus tard.

Foire aux questions

Qu'est-ce qu'une identité de machine ?

Une identité de machine, souvent appelée identité non humaine, est tout ce avec quoi un système s'authentifie au lieu d'un humain : comptes de service, clés API, jetons, certificats ou l'identité d'une charge de travail dans le cloud. Elle permet aux services de communiquer entre eux et avec les ressources.

Qu'est-ce que signifie un départ inapproprié pour les identités de machines ?

Un départ inapproprié décrit la désactivation ou la suppression insuffisante d'une identité de machine lorsqu'elle n'est plus nécessaire. L'OWASP la classe dans les top 10 des identités non humaines de 2025 comme risque NHI1, donc en première position.

Pourquoi les comptes de service orphelins sont-ils si dangereux ?

Ils sont des identités valides avec des droits valides que personne ne surveille plus. Un attaquant qui prend le contrôle d'un tel compte se déplace dans le réseau sans déclencher d'alarme, car l'activité semble légitime. Cela fait des comptes orphelins un chemin préféré pour le mouvement latéral.

Comment puis-je trouver des identités de machines orphelines ?

La première étape consiste à inventorier toutes les identités de machines actives avec le service associé et le propriétaire. Les identités sans service actif reconnaissable ou sans propriétaire sont les premiers candidats à une vérification et à une désactivation.

Quel est le lien avec l'intelligence artificielle ?

Les agents d'intelligence artificielle et les pipelines automatisés créent de nouvelles identités de machines à un rythme élevé. Cela fait augmenter le nombre de comptes plus vite que les processus manuels de départ ne peuvent suivre, et le point aveugle s'agrandit si aucun cycle de vie n'est établi.