On parle souvent d’identité numérique comme d’un attribut propre à l’humain : un nom, un login, une empreinte biométrique, parfois un badge. Pourtant, dans les systèmes d’information modernes, ces identités humaines sont aujourd’hui minoritaires. La grande majorité des flux, des connexions et des traitements sont déclenchés non pas par des personnes, mais par des processus automatisés : scripts, conteneurs, API, applications interconnectées. Ces entités, que l’on regroupe sous le terme d’identités non humaines (ou NHIs, pour non-human identities), forment une population massive, en constante expansion, dont la gestion reste souvent mal maîtrisée.
“Une entreprise peut compter 50 fois plus d’identités machines que d’utilisateurs humains”
La montée en puissance du cloud, de l’automatisation et des microservices a fait exploser le nombre de NHIs dans les entreprises. Chaque tâche planifiée, chaque fonction serverless, chaque conteneur orchestré génère ou utilise des secrets d’authentification pour accéder à des ressources : base de données, bucket S3, outil de CI/CD, ou encore API tierce. Ces secrets – tokens, clés d’API, certificats, fichiers de configuration – deviennent les équivalents fonctionnels des identifiants humains. Pourtant, ils n’ont ni carte d’identité, ni processus RH, ni conscience du danger. Ils apparaissent, vivent et parfois disparaissent sans laisser de trace dans les référentiels officiels.
La difficulté commence ici. Car si les NHIs sont omniprésentes, elles sont rarement inventoriées, encore moins gouvernées. Leur cycle de vie est flou : un script de test génère une clé, une application produit un jeton, un développeur intègre un mot de passe dans un fichier .env… Et ces artefacts, faute d’outillage ou de politique claire, restent actifs, exposés, parfois longtemps après que leur usage a cessé. Résultat : une surface d’attaque gigantesque, souvent invisible aux yeux des responsables sécurité.
“Le principal problème des NHIs, c’est qu’on ne sait pas toujours qu’elles existent”
Dans la gestion classique des identités humaines, les règles sont établies : création à l’embauche, suppression au départ, rattachement à une unité ou un poste. Mais pour les identités non humaines, rien n’est aussi structuré. Un conteneur peut créer une NHI à la volée pour accéder à une ressource, sans que celle-ci soit enregistrée dans un annuaire. Une clé API peut être partagée entre plusieurs environnements sans suivi. Une application tierce peut imposer son propre système de gestion, indépendant des standards de l’entreprise.
Les tentatives d’inventaire manquent souvent de cohérence. Entre les secrets gérés par des outils natifs (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault), les mots de passe dans des dépôts Git privés, et les configurations hardcodées dans du code, la cartographie est vite obsolète. Et les outils de gestion des identités (IAM) traditionnels, pensés pour les utilisateurs, peinent à intégrer ce foisonnement d’identités non humaines éphémères ou distribuées.
Ce vide crée un déséquilibre : alors que l’effort de sécurité s’est longtemps porté sur les comptes utilisateurs, les NHI deviennent aujourd’hui le maillon faible par défaut. Elles bénéficient rarement d’une authentification forte, leurs permissions sont souvent surdimensionnées, et leur révocation, quand elle a lieu, est manuelle. En cas de compromission, ces identités fantômes peuvent offrir un accès silencieux et profond à l’ensemble du système d’information.
“Les secrets ne sont pas dangereux en soi. Ce qui l’est, c’est qu’on oublie qu’ils existent”
L’une des approches qui émerge pour mieux contrôler les NHIs consiste à les envisager non pas comme des comptes, mais comme des relations sécurisées portées par des secrets. Le secret devient alors l’unité d’analyse : chaque token, chaque clé, chaque certificat est une empreinte d’identité, associée à un usage précis, un périmètre, un cycle de vie. Plutôt que de tenter d’attribuer une NHI à un service ou à une application, on cartographie les secrets eux-mêmes, on suit leur usage, on en mesure la durée de vie et l’exposition.
Cette approche présente plusieurs avantages. D’abord, elle permet une meilleure observabilité. Un jeton utilisé de façon inhabituelle, à une heure anormale ou depuis un nouvel environnement, devient un signal faible à surveiller. Ensuite, elle facilite la gouvernance : les secrets peuvent être centralisés, stockés dans des coffres-forts numériques, et intégrés dans des pipelines d’automatisation. Leur rotation peut être planifiée, leur révocation automatisée, leur création soumise à des politiques.
Mais cette approche a aussi ses limites. Un secret exposé reste un risque critique, quelle que soit sa durée de vie. Et la gestion centralisée suppose un effort initial important : standardiser les pratiques, migrer les secrets existants, former les équipes, auditer les configurations. De plus, certains environnements (legacy, on-premise, systèmes embarqués) ne permettent pas toujours l’intégration d’outils modernes de gestion des secrets.
Dans les faits, les entreprises font souvent face à un double défi : mieux gérer les secrets existants, souvent disséminés et non renouvelés, et éviter l’apparition incontrôlée de nouveaux secrets non gouvernés. Cela passe par des mécanismes de création encadrée (via des portails ou des API sécurisées), par des politiques de durée de vie maximales, et par des audits réguliers sur les dépôts de code, les images de conteneurs, les configurations CI/CD.
“Tant qu’on n’attribue pas clairement une identité à un usage, on ne peut pas la sécuriser”
Un autre point souvent négligé dans la gestion des NHIs est la question de l’attribution. Qui a créé cette clé ? Pour quoi ? Est-elle encore utilisée ? Si oui, par qui ? Ce flou rend difficile la réponse à incident : en cas de compromission, il devient presque impossible de savoir quels accès étaient ouverts, depuis combien de temps, et si des données ont été exfiltrées.
Certaines entreprises commencent à lier les secrets à des identifiants de projet, des tickets de changement, ou des comptes de service. D’autres mettent en place des règles simples : tout secret doit avoir un propriétaire humain identifié, une date d’expiration, et un périmètre d’usage explicite. Ces bonnes pratiques, bien qu’élémentaires, sont encore loin d’être généralisées.
Le problème prend une dimension supplémentaire avec les environnements multi-clouds ou hybrides. Chaque fournisseur a ses propres outils, ses formats de secrets, ses mécanismes d’attribution. Or, dans un environnement moderne, les identités non humaines opèrent souvent en transversal : un conteneur dans Azure déclenche une fonction dans AWS qui appelle une API hébergée on-premise. Sans une vision unifiée, la gouvernance devient illusoire.
L’enjeu est donc de taille. Les NHIs sont omniprésentes, peu visibles, et leur compromission peut ouvrir la voie à des attaques très profondes, sans alerte. Les campagnes récentes de type supply chain ou exploitation de secrets exposés l’ont démontré : un token oublié dans un dépôt Git peut suffire à infiltrer toute une infrastructure.
Ce que révèle cette dynamique, c’est un changement de paradigme. On ne sécurise plus seulement des comptes et des mots de passe, mais des flux de confiance automatisés, entre entités sans visage ni mot de passe. Cela implique de revoir nos réflexes : auditer les dépendances, cartographier les appels API, traquer les secrets exposés, et intégrer la sécurité dès le design des architectures.
Ce n’est pas un chantier simple, mais c’est un chantier prioritaire. À mesure que les infrastructures deviennent plus dynamiques, plus décentralisées, et plus automatisées, les NHIs deviennent les nouveaux points d’entrée favoris des attaquants. Mieux les gérer, c’est réduire la surface d’attaque, renforcer la traçabilité, et bâtir une cybersécurité réellement alignée avec les pratiques techniques contemporaines.
