Qu'est-ce qu'une identité non humaine, concrètement ?

Tout ce qui s'authentifie sans être une personne : comptes de service, principaux d'application dans Entra ID, rôles et clés d'accès dans AWS, jetons d'API, secrets de pipelines CI, comptes techniques de sauvegarde ou de surveillance, et maintenant les agents IA qui appellent des outils avec leurs propres autorisations. Elles sont créées vite, souvent par des développeurs, et rarement supprimées.

Nos revues d'accès trimestrielles ne suffisent-elles pas ?

Elles couvrent en général les comptes nommés, pas les identités techniques, parce que le propriétaire est inconnu et que personne n'ose retirer un accès dont dépend peut-être un processus. Résultat : les jetons les plus puissants sont les moins revus. La solution n'est pas une revue plus fréquente, c'est un inventaire avec un propriétaire par identité et une date d'expiration.

Par où commencer si nous n'avons rien ?

Par l'inventaire, pas par l'outil : exporter les principaux d'application, les clés d'accès et les jetons personnels de vos trois plateformes principales, leur trouver un propriétaire, supprimer ce qui n'a pas servi depuis quatre-vingt-dix jours, faire tourner le reste. Cet exercice tient en deux semaines et retire souvent le tiers des identités.

Analyse · Identité

Identités non humaines : l'angle mort de vos revues d'accès

Comptes de service, clés API, jetons et agents IA : la première porte d'entrée des attaquants. Pourquoi vos revues d'accès les ratent et par où commencer.

Par Sentrix · Publié le 2026-09-20

Depuis dix ans, les programmes de sécurité traitent l'identité comme une affaire de personnes : mots de passe, MFA, revues d'accès trimestrielles, départs d'employés. Pendant ce temps, la population d'identités qui ne sont pas des personnes a explosé, et c'est par elle que les attaquants entrent désormais le plus souvent.

Ce que disent les rapports de 2026

Le rapport 2026 de SpyCloud sur les menaces d'identité, publié le 9 septembre 2026, place les identités non humaines compromises en tête des voies d'entrée dans les entreprises : elles sont le point d'entrée principal dans 31 % des incidents analysés, près du double de l'hameçonnage et de l'ingénierie sociale, à 17 %. Le rapport de réponse aux incidents 2026 de l'Unit 42 de Palo Alto Networks décrit le même déplacement : les identités, les plateformes SaaS, les droits infonuagiques et les cadres d'automatisation sont devenus les chemins préférés des attaquants, à mesure que les organisations adoptent l'IA à grande échelle.

La Cloud Security Alliance, dans son livre blanc sur le vide de gouvernance des identités non humaines, met des mots sur la cause : ces identités sont créées par les équipes de développement et d'exploitation, en dehors des processus RH qui déclenchent les revues, et les agents d'IA ajoutent une catégorie qui prend des décisions et change de chemin d'exécution d'une manière que les revues d'accès n'ont jamais été conçues pour attraper. Darktrace, dans son bilan de mi-année 2026, résume la tendance d'une formule : la confiance est devenue la nouvelle surface d'attaque.

Pourquoi vos revues d'accès les ratent

Une revue d'accès classique part d'une liste de personnes et demande à un gestionnaire de confirmer ce que chacune peut faire. Trois choses la font passer à côté des identités techniques.

Personne n'en est propriétaire. Un compte de service créé pour une intégration en 2023 appartient à un projet terminé, à un développeur parti, ou à « l'équipe ». Quand le propriétaire est inconnu, le réviseur confirme l'accès par prudence.

Le coût de l'erreur est asymétrique. Retirer l'accès d'une personne qui en a besoin coûte un billet de soutien. Retirer un jeton dont dépend un traitement de nuit coûte un incident de production. Les réviseurs le savent et laissent passer.

Les droits sont invisibles dans l'outil de revue. Un principal d'application avec une portée Directory.ReadWrite.All, une clé d'accès attachée à une politique administrateur, un jeton personnel sans expiration : ces droits ne s'affichent pas comme « administrateur » dans un tableau de revue conçu pour des rôles humains.

Le résultat est mesurable dans presque chaque évaluation que nous menons : les identités les plus puissantes du parc sont celles qui n'ont jamais été revues.

Ce que nous en pensons chez Sentrix

Le problème n'est pas une question d'outil ; c'est une question d'inventaire et de propriété. Sur la carte d'exposition que nous utilisons pour raisonner en gestion continue de l'exposition aux menaces, le domaine Identité compte autant d'identités non humaines que de comptes de personnes, et il faut les traiter comme des actifs : découverts, attribués, datés, retirés.

Concrètement, dans l'ordre :

Inventorier à partir des sources, pas des tableurs : principaux d'application et secrets dans Entra ID, utilisateurs et clés d'accès IAM dans AWS, comptes de service dans Google Workspace, jetons personnels et secrets de dépôt dans GitHub et GitLab, jetons d'API des outils SaaS critiques.
Attribuer un propriétaire nommé à chaque identité, avec une date d'expiration. Une identité sans propriétaire après trente jours est désactivée, pas supprimée : si rien ne casse en quatorze jours, elle est supprimée.
Réduire les portées : remplacer les droits larges par la portée minimale, séparer lecture et écriture, une identité par usage plutôt qu'un jeton partagé.
Faire tourner et expirer : rotation automatique là où la plateforme le permet, expiration obligatoire sur tout ce qui se crée à la main.
Traiter les agents d'IA comme des identités de premier ordre : chaque agent a un propriétaire, une portée d'outils explicite, un journal d'actions, et sa propre revue.
Mettre la revue des identités non humaines dans le même cycle que celle des personnes, avec les mêmes preuves conservées pour l'auditeur.

Ce programme n'exige aucune plateforme nouvelle pour démarrer. Il exige une liste, des noms et des dates. C'est aussi, pour ISO 27001 (contrôles 5.16 à 5.18 et 8.2) et pour SOC 2 (critères CC6), exactement ce que l'auditeur demandera de voir.

La prochaine étape

Les rapports cités convergent sur un point : la visibilité déclarée dépasse largement la surveillance réelle. Avant d'investir dans un outil, mesurez l'écart chez vous : combien d'identités non humaines avez-vous, combien ont un propriétaire, combien ont servi dans les quatre-vingt-dix derniers jours. Les trois chiffres tiennent sur une ligne, et ils disent l'essentiel.

Sources

Questions fréquentes

Qu'est-ce qu'une identité non humaine, concrètement ?: Tout ce qui s'authentifie sans être une personne : comptes de service, principaux d'application dans Entra ID, rôles et clés d'accès dans AWS, jetons d'API, secrets de pipelines CI, comptes techniques de sauvegarde ou de surveillance, et maintenant les agents IA qui appellent des outils avec leurs propres autorisations. Elles sont créées vite, souvent par des développeurs, et rarement supprimées.
Nos revues d'accès trimestrielles ne suffisent-elles pas ?: Elles couvrent en général les comptes nommés, pas les identités techniques, parce que le propriétaire est inconnu et que personne n'ose retirer un accès dont dépend peut-être un processus. Résultat : les jetons les plus puissants sont les moins revus. La solution n'est pas une revue plus fréquente, c'est un inventaire avec un propriétaire par identité et une date d'expiration.
Par où commencer si nous n'avons rien ?: Par l'inventaire, pas par l'outil : exporter les principaux d'application, les clés d'accès et les jetons personnels de vos trois plateformes principales, leur trouver un propriétaire, supprimer ce qui n'a pas servi depuis quatre-vingt-dix jours, faire tourner le reste. Cet exercice tient en deux semaines et retire souvent le tiers des identités.

Parlons de votre programme de conformité.

Nous contacter

Dernière mise à jour : 2026-09-20