Accès orphelins : la faille cyber silencieuse

Les comptes de service, les clés API et les agents d’IA dépassent souvent en nombre les comptes humains. Or, personne ne se soucie de la plupart de ces accès. C’est précisément là que s’ouvre la prochaine faille : en dehors de l’endpoint sécurisé.

Articles associés :Quel contrôle subsiste après le déploiement des agents ?  /  Kimi met fin aux abonnements : 7 vérifications pour le Capex IA

Pourquoi le nombre d’identités machines échappe à tout contrôle

Chaque migration vers le cloud, chaque nouveau microservice et chaque automatisation génère des identités. Un pipeline de déploiement a besoin d’un jeton pour déployer du code. Un service de monitoring nécessite une clé pour lire les métriques. Une intégration entre deux plateformes SaaS crée en arrière-plan un compte technique. Rien de tout cela n’apparaît dans les processus classiques des ressources humaines, car derrière ces accès ne se cache aucun être humain à onboarder ou à offboarder.

Dans de nombreuses organisations, les identités non humaines dépassent largement les identités humaines. Ce qui compte moins, c’est la relation exacte que la dynamique de croissance. Les identités humaines croissent de manière linéaire avec les effectifs. Les identités machines, elles, augmentent avec chaque décision architecturale, chaque outil dans la stack et désormais avec chaque agent IA qui accède de manière autonome aux systèmes. Leur nombre évolue plus rapidement que la plupart des programmes de gestion des identités ne peuvent suivre.

Le problème s’aggrave du fait que ces identités sont mal documentées. Une clé API est souvent créée rapidement pour faire fonctionner une intégration. Elle est stockée dans un fichier de configuration, un script ou un gestionnaire de secrets, puis rarement touchée ensuite. Après quelques changements de personnel, plus personne ne sait qui l’a créée, à quoi elle sert ni si elle est encore nécessaire.

Lorsqu’un collaborateur quitte l’entreprise, le réflexe d’offboarding s’applique. Les comptes machines, eux, continuent souvent de fonctionner jusqu’à ce qu’une attaque ne les révèle.

Les accès orphelins restent actifs après la fin du projet

Lorsqu’un collaborateur quitte l’entreprise, un processus établi se met en place : compte bloqué, appareils récupérés, droits révoqués. Pour les identités machines, ce réflexe est quasi inexistant. Un compte de service créé par un développeur parti depuis longtemps pour un projet reste actif. Le jeton d’une application désactivée n’est jamais révoqué. La clé de test qui a par erreur atterri en production continue de fonctionner.

Ces accès orphelins sont particulièrement attractifs pour les attaquants. Ils disposent souvent de droits étendus, car le principe du moindre privilège est moins appliqué aux comptes techniques qu’aux utilisateurs humains. Ils sont rarement surveillés, car personne ne s’attend à un comportement suspect de leur part. De plus, ils contournent de nombreux mécanismes de protection conçus pour les utilisateurs humains. L’authentification multifactorielle ne s’applique pas à une clé API statique. Un jeton volé se comporte techniquement comme un jeton légitime.

Les identifiants compromis et les secrets mal gérés figurent parmi les vecteurs d’attaque récurrents. Les clés et jetons concernés sont souvent intégrés dans le code, un dépôt ou un fichier de logs : au-delà du mot de passe humain. Sécuriser uniquement le volet humain revient à protéger une infime partie de la surface d’attaque.

Quatre étapes pour maîtriser l’expansion anarchique des identités

Pour sortir du chaos, il faut une gestion structurée des identités existantes. Un simple produit de sécurité supplémentaire ne suffira pas. Quatre étapes forment un programme solide.

Premièrement, l’inventaire et la découverte. Avant de sécuriser quoi que ce soit, il faut avoir une vue d’ensemble. Quels comptes de service, clés, jetons et bots existent, dans quels systèmes et avec quels droits ? Les plateformes cloud, les pipelines CI/CD, les gestionnaires de secrets et les intégrations SaaS sont les sources typiques. Un premier examen manuel vaut mieux que d’attendre l’outil parfait.

Deuxièmement, l’attribution des responsabilités. Chaque identité machine doit avoir un responsable humain. Un compte sans propriétaire est un compte que personne ne désactivera, faute de personne pour s’en soucier. L’attribution des responsabilités transforme un jeton anonyme en une décision traçable, vérifiable et révocable.

Troisièmement, le principe du moindre privilège et la rotation. Les comptes techniques reçoivent souvent plus de droits que nécessaire, simplement pour gagner du temps. Chaque identité ne devrait porter que les autorisations strictement requises par sa fonction. Les secrets statiques et permanents doivent être remplacés par des identifiants éphémères et automatiquement renouvelés. Une clé réémise toutes les quelques heures représente une cible bien plus réduite.

Quatrièmement, la gestion du cycle de vie et la désactivation. Les identités machines méritent le même cycle de vie que les utilisateurs humains. Lorsqu’une application est arrêtée, un projet terminé ou une intégration supprimée, l’accès associé doit disparaître automatiquement. Un contrôle régulier permet de repérer les comptes inactifs depuis des mois. Ces « comptes fantômes » sont les premiers candidats à la révocation.

Les agents IA reproduisent les mêmes erreurs de cycle de vie

La prochaine vague provient de votre propre service d’innovation. Les agents IA autonomes, capables d’exécuter des tâches de manière indépendante, nécessitent un accès aux systèmes, aux données et à d’autres services. Chacun de ces agents représente une nouvelle identité machine, souvent dotée de droits étendus pour garantir une flexibilité optimale. Contrairement à un script rigide, un agent prend des décisions en temps réel. Son comportement est donc plus difficile à anticiper, et par conséquent, plus complexe à surveiller.

Si vous ne maîtrisez pas aujourd’hui l’expansion anarchique des identités (Identity-Sprawl), vous importerez ce problème sous une forme aggravée avec chaque nouvelle initiative IA. Un agent doté de droits excessifs, dont personne ne peut identifier le propriétaire, est exactement le type d’accès qui, dans deux ans, sera considéré comme abandonné. La rigueur appliquée aujourd’hui aux comptes de service constitue la condition sine qua non pour déployer des agents IA en toute sécurité.

La première étape des 90 prochains jours

L’entrée en matière n’a rien de spectaculaire, et c’est précisément ce qui en fait l’efficacité. Un inventaire des identités non humaines dans les environnements les plus critiques, en commençant par la plateforme cloud et les pipelines centraux. Chaque identité découverte se voit attribuer trois informations : sa finalité, son propriétaire et sa dernière activité. Tout ce qui ne dispose pas d’une finalité claire ou qui n’a pas été utilisé au cours des derniers mois est placé sur une liste de vérification. Cette liste sert de base à la première opération de nettoyage, qui à son tour permet d’établir une règle pour l’avenir. Aucun nouvel accès technique ne sera accordé sans propriétaire désigné ni condition d’expiration définie. Le nombre d’identités machines ne cessera d’augmenter. C’est cette discipline qui déterminera si leur croissance sera maîtrisée ou non.

Questions fréquentes

Source de l’image : générée par IA (juillet 2026)