Les identités machines et, plus largement, les identités non humaines sont devenues le principal périmètre de sécurité des systèmes d'information modernes. Comptes de service, clés d'API, jetons d'intégration, certificats, identités de charges de travail dans le cloud et, plus récemment, agents d'IA capables d'agir de manière autonome : chacune de ces identités donne accès à des données ou à des actions, souvent avec des privilèges élevés et sans humain pour remarquer un usage anormal.
Leur nombre progresse avec chaque microservice, chaque intégration SaaS et chaque pipeline d'automatisation. Pourtant, elles échappent largement aux processus conçus pour les collaborateurs : pas d'arrivée ni de départ formalisés, pas de revue périodique des droits, pas toujours de propriétaire identifié. Le risque ne vient pas d'une faille technique particulière, mais de cette absence de gouvernance.
Cet article décrit les principaux risques recensés par l'OWASP, l'évolution des certificats vers des durées de vie très courtes, l'apport des identités de charge de travail et les questions nouvelles que posent les agents d'IA.
De quoi parle-t-on exactement ?
Une identité non humaine est un moyen d'authentification utilisé par un logiciel, un service ou un processus automatisé plutôt que par une personne. L'OWASP, dans son Top 10 consacré à ces identités, cite les comptes de service et les clés d'accès, les clés d'API, les jetons, les clés de chiffrement et les certificats 1. On peut les regrouper en quatre familles :
- Les comptes techniques classiques : comptes de service Active Directory, comptes applicatifs de bases de données, comptes de batch.
- Les secrets d'intégration : clés d'API, jetons OAuth, jetons d'accès personnels détournés vers des usages automatisés.
- Les identités cryptographiques : certificats TLS serveur et client, clés SSH, clés de signature.
- Les identités de charges de travail et d'agents : rôles cloud attachés à une machine virtuelle ou à un conteneur, identités de pods, agents d'IA qui appellent des outils et des API.
La distinction avec les identités humaines est utile, mais trompeuse si elle conduit à traiter ces identités à part. Un compte de service avec des droits d'administration de domaine est une identité à privilèges, et doit être gouverné comme tel.
Les dix risques identifiés par l'OWASP
Le Top 10 2025 de l'OWASP sur les identités non humaines offre une grille de lecture utile pour un premier diagnostic 1. Les risques recensés sont, dans l'ordre : le défaut de désactivation des identités devenues inutiles, la fuite de secrets, les identités non humaines de tiers vulnérables, l'authentification non sécurisée, les identités sur-privilégiées, les configurations de déploiement cloud non sécurisées, les secrets de longue durée, l'absence d'isolation entre environnements, la réutilisation d'une même identité pour plusieurs usages et l'usage d'identités non humaines par des humains 1.
Quatre de ces risques relèvent directement de la gouvernance et sont souvent les plus faciles à objectiver lors d'un audit.
Le défaut de désactivation
Un compte créé pour un projet terminé, une intégration remplacée ou un prestataire parti reste actif. Sans propriétaire, personne ne demande sa suppression. C'est le premier risque du classement de l'OWASP 1.
Les privilèges excessifs
Faute de connaître précisément les besoins d'une application, on lui accorde des droits larges « pour que ça marche ». Ces droits ne sont ensuite jamais réduits.
La réutilisation
Une même identité sert à plusieurs applications ou à plusieurs environnements. En cas de compromission, le rayon d'impact s'étend à tous ses usages, et la traçabilité devient impossible.
L'usage humain d'une identité machine
Des administrateurs utilisent un compte de service pour contourner l'authentification forte ou les restrictions de leur compte nominatif. Cette pratique efface la frontière entre action humaine et action automatisée dans les journaux.
Une identité non humaine sans propriétaire est une identité que personne ne désactivera jamais.
Raccourcir la durée de vie des justificatifs
Certificats : la fin des durées de vie longues
Les certificats sont des identités machines à part entière, et leur gestion change d'échelle. Le CA/Browser Forum, qui fixe les règles applicables aux certificats TLS publics, a adopté en avril 2025 le scrutin SC-081v3, qui réduit progressivement la durée de validité maximale de ces certificats de 398 jours à 47 jours 2. Les réductions ont commencé en mars 2026 et s'achèveront en mars 2029 2. Le même scrutin réduit aussi la durée de réutilisation des données de validation de domaine, jusqu'à 10 jours au terme du calendrier 2.
Cette évolution ne concerne directement que les certificats TLS publics, mais elle oblige toutes les organisations à revoir leur modèle. Un renouvellement manuel, piloté par un tableur et des rappels de calendrier, devient intenable lorsqu'il faut le répéter plusieurs fois par an pour chaque certificat. Pour les organisations qui n'automatisent pas, le risque d'interruption de service causée par un certificat expiré augmente mécaniquement avec la fréquence des renouvellements.
La réponse est d'abord un inventaire complet des certificats, publics et internes, avec leur propriétaire et leur point de déploiement, puis l'automatisation du renouvellement et du déploiement, par exemple avec le protocole ACME ou les mécanismes natifs des plateformes cloud et des équilibreurs de charge. Les autorités de certification internes méritent la même discipline, car elles émettent souvent des certificats de plusieurs années pour des usages critiques.
Identités de charge de travail : remplacer les secrets partagés
La meilleure façon de réduire le risque lié aux secrets d'une identité non humaine est souvent de ne plus en avoir. Les identités de charge de travail reposent sur un principe différent : la plateforme atteste de l'identité du processus qui s'exécute, et lui délivre des justificatifs cryptographiques de courte durée, renouvelés automatiquement.
Le standard ouvert SPIFFE en est l'illustration la plus aboutie. Il définit un ensemble de standards pour identifier de manière sûre des logiciels dans des environnements dynamiques et hétérogènes, afin qu'ils puissent s'authentifier mutuellement où qu'ils s'exécutent 3. Les identités y prennent la forme de documents cryptographiques de courte durée, les SVID, au format X.509 pour authentifier une connexion TLS ou au format JWT pour signer des jetons, délivrés par une API dédiée qui en assure la rotation automatique 3.
Les grands fournisseurs cloud proposent des mécanismes comparables pour leurs propres services, et la fédération d'identités permet à un pipeline d'intégration continue d'obtenir un accès temporaire à un compte cloud sans clé stockée. Pour une organisation, la feuille de route consiste à identifier les flux encore fondés sur des secrets statiques et à les faire migrer, en priorité, vers ces identités attestées par la plateforme.
Agents d'IA : identité, délégation et traçabilité
Les agents d'IA ajoutent une dimension nouvelle. Le NIST, à travers son centre d'excellence NCCoE, a publié en février 2026 un document de cadrage consacré à l'identité et à l'autorisation des agents logiciels et des agents d'IA, soumis à consultation publique jusqu'au 2 avril 2026 4. Il décrit les agents comme des systèmes capables de prendre des décisions et d'agir de manière autonome avec une supervision humaine limitée 5.
Le document pose les questions que tout RSSI doit se poser avant de déployer des agents en production 5 :
- Comment appliquer le moindre privilège à un agent dont les actions ne sont pas entièrement prévisibles au moment du déploiement ?
- Comment lier l'identité d'un agent à celle de l'humain pour le compte duquel il agit, afin de conserver une responsabilité claire et des validations humaines pour les actions sensibles ?
- Comment journaliser les actions et les intentions d'un agent de façon vérifiable et résistante à l'altération ?
- Quels contrôles permettent de prévenir l'injection de prompt et d'en limiter l'impact ?
Le NIST relève que le protocole MCP, qui permet aux agents de découvrir et d'utiliser des outils externes, s'appuie sur OAuth comme principal mécanisme d'autorisation, et cite SPIFFE parmi les approches possibles pour identifier et authentifier les charges de travail des agents 5. En pratique, un agent ne devrait jamais réutiliser le compte de service d'une application existante ni les identifiants d'un utilisateur : il doit disposer de sa propre identité, de jetons délégués à portée et durée limitées, et d'une traçabilité qui relie chaque action à l'humain mandant.
Gouverner les identités machines et non humaines : la checklist
La gouvernance des identités non humaines repose sur les mêmes principes que celle des identités humaines, adaptés à l'automatisation :
- Inventorier toutes les identités non humaines, y compris celles des fournisseurs SaaS connectés, et les rattacher à une application et à un propriétaire nominatif.
- Interdire la création d'identité sans propriétaire ni date de revue, et désactiver automatiquement celles qui ne sont plus utilisées.
- Réduire les privilèges à partir des usages observés, et séparer strictement les identités par application et par environnement.
- Remplacer les secrets statiques par des identités de charge de travail ou des jetons de courte durée, et automatiser le cycle de vie des certificats.
- Surveiller les comportements : connexion depuis une origine inhabituelle, usage interactif d'un compte technique, élévation de privilèges.
- Donner à chaque agent d'IA une identité propre, des droits délégués limités et une journalisation qui permet de reconstituer ses actions.
Conclusion
Les identités non humaines ne sont pas un sujet émergent : elles sont déjà présentes à chaque couche du système d'information, et les agents d'IA vont en accélérer la croissance. Les organisations qui en reprennent le contrôle commencent par l'inventaire et la désignation de propriétaires, puis réduisent la durée de vie des justificatifs et les privilèges. DATASWING aide ses clients à structurer cette gouvernance, de l'inventaire à l'automatisation du cycle de vie.
— Questions fréquentes
Ce qu'on nous demande souvent
Qu'est-ce qu'une identité non humaine ?+
C'est une identité utilisée par un logiciel, un service ou un processus automatisé pour s'authentifier, et non par une personne. Elle prend la forme d'un compte de service, d'une clé d'API, d'un jeton, d'un certificat, d'une clé SSH ou d'une identité de charge de travail cloud. Les agents d'IA qui appellent des outils ou des API relèvent aussi de cette catégorie.
Comment sécuriser les comptes de service ?+
En les rattachant à un propriétaire et à une application, en limitant leurs droits au strict nécessaire, en interdisant leur usage interactif et leur réutilisation entre applications ou environnements, et en remplaçant leurs mots de passe statiques par des identifiants à durée de vie courte. Une revue périodique et la désactivation automatique des comptes inactifs complètent le dispositif.
Pourquoi la durée de validité des certificats TLS diminue-t-elle ?+
Le CA/Browser Forum a adopté en avril 2025 un calendrier qui ramène progressivement la validité maximale des certificats TLS publics de 398 à 47 jours entre mars 2026 et mars 2029. Des certificats plus courts limitent la durée d'exploitation d'une clé compromise ou d'informations de validation obsolètes, mais imposent d'automatiser le renouvellement.
Un agent d'IA doit-il avoir sa propre identité ?+
Oui. Réutiliser le compte d'un utilisateur ou d'une application empêche de distinguer les actions de l'agent et de limiter ses droits. Les travaux du NIST insistent sur le moindre privilège, sur le lien entre l'agent et l'humain pour le compte duquel il agit, et sur une journalisation vérifiable. Des jetons délégués à portée et durée limitées sont la pratique recommandée.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
OWASP Top 10 Non-Human Identities Risks – 2025 ↗OWASP · 2025
-
[2]
Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods ↗CA/Browser Forum · 2025-04
-
[3]
SPIFFE Overview ↗SPIFFE · 2026
- [4]
- [5]
