Comprendre les Non-Human Identities : Les risques cachés des accès automatisés

À mesure que les infrastructures modernes deviennent plus complexes, la notion d’identité s’étend bien au-delà des seuls utilisateurs humains. Les systèmes, applications, services cloud et autres entités logicielles interagissent avec des ressources critiques et y accèdent. Ces acteurs non-humains, appelés identités non-humaines (NHI), jouent un rôle de plus en plus central dans le fonctionnement des organisations.

Durant mes missions en tant que pentesteur, j’ai exploité à plusieurs reprises des identités non-humaines exposées ou mal gérées pour obtenir un accès initial ou approfondir ma pénétration dans les environnements que j’auditais.

Comprendre leur nature, les risques associés et les bonnes pratiques pour leur gestion est devenu indispensable pour une cybersécurité robuste.

Non human identities

Qu’est-ce qu’une identité non-humaine ?

Une identité non-humaine désigne toute entité numérique qui nécessite une authentification et une autorisation pour accéder à des ressources, mais qui n’est pas un utilisateur humain. Cela englobe une vaste catégorie d’éléments, notamment :

  • Les comptes de service : utilisés par les applications et services pour interagir avec le système d’exploitation, les bases de données ou d’autres applications.
  • Les clés API : permettent aux applications de communiquer entre elles sans intervention humaine.
  • Les secrets et certificats : utilisés pour l’authentification et le chiffrement.
  • Les workloads cloud : instances de machines virtuelles, conteneurs et fonctions serverless fonctionnant dans le cloud.
  • Les bots et scripts automatisés : effectuent des tâches répétitives et interagissent avec d’autres systèmes. (Vous en utilisez peut-être un pour envoyer des messages sur votre canal Slack ou Discord)
  • Les objets IoT (Internet of Things) : capteurs, caméras et autres appareils connectés qui communiquent et échangent des données.

Quand on parle d’identités non-humaines, on pense souvent rapidement aux clés API et aux tokens JWT. Ce sont des mécanismes couramment utilisés aujourd’hui par les services et applications pour s’authentifier et communiquer de manière sécurisée, mais les NHI peuvent prendre de nombreuses formes : identifiants classiques avec nom d’utilisateur et mot de passe, certificats, etc.

Il faut aussi garder à l’esprit que les utilisateurs humains peuvent agir via des NHI. Par exemple, quand une personne utilise une application web qui effectue des appels API en arrière-plan, l’interaction réelle avec le système est réalisée par une identité non-humaine (par exemple : un compte de service ou un token système), même si l’intention provient d’un humain.

Et parfois, tout simplement parce que les humains restent humains, ils finissent par utiliser directement les identifiants de comptes de service. C’est un contournement familier et pratique qui accorde des privilèges élevés avec un minimum de friction.

Pourquoi les NHI représentent-elles un enjeu de sécurité majeur ?

La prolifération des NHI complique considérablement le paysage sécuritaire. Plusieurs facteurs contribuent à ce défi :

  • Volume et diversité : les NHI dépassent souvent largement en nombre les utilisateurs humains, et elles prennent de nombreuses formes (microservices, bots, tâches planifiées, fonctions cloud), ce qui rend difficile leur inventaire et leur gouvernance cohérente.
  • Manque de visibilité : contrairement aux comptes utilisateurs, les NHI sont souvent non documentées ou cachées dans les couches d’infrastructure. De plus, l’absence de propriété définie et de gestion complète du cycle de vie introduit des lacunes critiques de visibilité dans la télémétrie de sécurité et les workflows de réponse aux incidents.
  • Gestion d’accès complexe : attribuer et révoquer des permissions pour les NHI est un défi. Sans gouvernance stricte, les NHI peuvent accumuler des privilèges excessifs ou obsolètes, augmentant le risque de mouvement latéral ou d’escalade de privilèges.
  • Privilèges par défaut et sur-provisioning : les NHI sont souvent créées avec des privilèges par défaut ou hérités, correspondant généralement aux permissions de l’utilisateur ou du système qui les a créées. Par exemple, lors de la génération d’un token d’accès personnel GitHub ou GitLab, il peut par défaut avoir des portées larges sauf restriction explicite. Malheureusement, l’outillage pour réduire ou dimensionner automatiquement ces permissions est limité, conduisant à une sur-exposition persistante.
  • Rotation des secrets : les NHI reposent sur des identifiants comme les clés API, tokens et certificats. Ceux-ci sont souvent codés en dur, mal tournés, ou complètement oubliés (laissant encore une fois les systèmes vulnérables à des compromissions à long terme).
  • Surveillance limitée : l’activité des identités non-humaines est souvent sous-surveillée, avec une visibilité temps réel ou une analyse comportementale limitée. Contrairement aux utilisateurs humains, les NHI peuvent fonctionner silencieusement en arrière-plan. Elles déclenchent rarement des alertes ou font l’objet d’un examen dans les tableaux de bord de sécurité. Ce manque de supervision crée un angle mort dangereux, où les erreurs de configuration ou les comportements malveillants peuvent persister sans être détectés pendant de longues périodes.
  • Cibles privilégiées : en raison de leur accès large et souvent privilégié, les NHI constituent des cibles attrayantes pour les attaquants. Compromettre une NHI peut fournir un point d’ancrage discret et puissant pour un mouvement latéral ou une exfiltration de données. (Jackpot, j’ai une clé pour exécuter des requêtes sur l’API Azure Graph, youpi !)

Ironiquement, c’est souvent seulement lors d’un test de pénétration ou d’un audit externe que ces problèmes remontent à la surface. Révélant soudainement des lacunes critiques au RSSI et à la direction sécurité. Cette découverte réactive souligne une faiblesse systémique : les organisations ignorent souvent à quel point leur paysage NHI est réellement exposé jusqu’à ce que quelqu’un essaie activement de le casser. Et même alors, les équipes sécurité et IT restent souvent incertaines sur la façon de réagir efficacement.

Utilisons quelques statistiques concrètes pour mieux visualiser cela. Les statistiques suivantes sont tirées du rapport « The State of the Secret Sprawl 2025 » de GitGuardian.

En 2024, GitGuardian a détecté un nombre stupéfiant de 23,8 millions de secrets divulgués dans les dépôts GitHub publics. Une augmentation étonnante de 25% par rapport à l’année précédente. De façon alarmante, 4,6% de tous les dépôts publics et 35% des privés contenaient au moins un secret exposé, les dépôts privés étant souvent traités avec moins de précaution en raison d’un faux sentiment de sécurité. Plus préoccupant encore est la persistance de ces fuites : 70% des secrets exposés en 2022 étaient toujours actifs en 2024, soulignant un gap majeur de remédiation. Les identifiants MongoDB étaient les plus couramment divulgués dans les dépôts publics, représentant 18,8% des cas, tandis que les clés AWS IAM apparaissaient dans 8% des dépôts privés. C’est cinq fois plus que dans les publics. Ce problème persistant est largement causé par l’utilisation d’identifiants à longue durée de vie, l’absence de politiques d’expiration, et un manque de workflows automatisés pour la rotation et la révocation des secrets.

Risques associés aux identités non-humaines (OWASP Top 10 NHI)

L’OWASP (Open Web Application Security Project) a récemment publié un Top 10 des risques liés aux identités non-humaines, soulignant leur importance croissante dans le domaine de la sécurité :

  1. Inventaire et gestion inadéquats des NHI : manque de visibilité et de contrôle sur les NHI existantes.
  2. Secrets codés en dur : inclusion de clés API, mots de passe ou certificats directement dans le code ou les fichiers de configuration.
  3. Gestion compromise des secrets : stockage non sécurisé ou rotation insuffisante des secrets.
  4. Permissions excessives : attribution aux NHI de droits d’accès plus larges que nécessaire pour leurs fonctions.
  5. Manque d’authentification et d’autorisation fortes : utilisation de méthodes d’authentification faibles ou absence de politiques d’autorisation robustes.
  6. Surveillance et audit insuffisants : manque de suivi de l’activité des NHI pour détecter les comportements anormaux.
  7. Provisioning et deprovisioning non sécurisés : processus inadéquats pour créer et supprimer les NHI, laissant potentiellement des accès orphelins.
  8. Usage malveillant des NHI : compromission de NHI par des attaquants pour mener des activités illégitimes.
  9. Vulnérabilités dans les plateformes de gestion des NHI : faiblesses de sécurité dans les outils utilisés pour gérer les NHI elles-mêmes.
  10. Absence de gestion du cycle de vie des NHI : manque de politiques claires pour la création, l’utilisation, la révocation et la suppression des NHI.

Je recommande personnellement à tous ceux qui s’intéressent au sujet de le lire comme point de départ, ainsi que tous les autres articles liés sur le site web d’OWASP.

Bonnes pratiques pour gérer les identités non-humaines

Pour gérer efficacement les risques de sécurité croissants associés aux NHI, les organisations doivent adopter une approche proactive, structurée et basée sur le cycle de vie. Cela signifie intégrer la gouvernance des NHI au cœur des pratiques d’Identity and Access Management (IAM).

Sensibilisation et formation

La première chose qui me vient à l’esprit quand on me demande comment sécuriser les NHI, c’est d’éduquer les équipes sur l’importance de la sécurité des NHI et les bonnes pratiques. Si vous pouvez créer un défi de type CTF qui implique l’abus de NHI (Hello projet de dépôt terraform).

Découverte et inventaire complets

Comme pour les privilèges des utilisateurs humains, la première étape est d’identifier/découvrir toutes les NHI dans votre infrastructure et d’évaluer leurs privilèges associés. Des outils comme (trouver exemple) peuvent aider à automatiser la découverte des comptes de service, tokens et identités machine dans les environnements cloud et on-premise.

Gestion centralisée des secrets

Utilisez des coffres-forts sécurisés comme Wallix Bastion ou OpenBAO Vault pour gérer les clés API, tokens et certificats. Ces plateformes fournissent le chiffrement, le contrôle d’accès et la journalisation d’audit pour tous les secrets.

Principe du moindre privilège

Assurez-vous que les NHI ne reçoivent que les permissions dont elles ont besoin, c’est assez évident mais toujours bon à mentionner, et implémentez des mécanismes d’authentification robustes et des politiques d’autorisation granulaires.

  1. Rotation régulière des secrets : des plateformes comme OpenBAO et WALLIX Vault supportent les politiques de rotation automatisée des secrets, garantissant que les identifiants sont régulièrement rafraîchis sans intervention manuelle (réduisant le risque de secrets à longue durée de vie).
  2. Surveillance et audit continus : implémentez des outils pour surveiller l’activité des NHI et détecter les anomalies.
  3. Automatisation du provisioning et deprovisioning : utilisez des processus automatisés pour créer et supprimer les NHI afin d’éviter les accès non gérés. La plupart des CI/CD peuvent supporter l’automatisation du cycle de vie des NHI via l’interconnexion avec un coffre-fort, des fonctions, plugins, ou de l’imagination.
  4. Adoption d’un cycle de vie des NHI : définissez et appliquez des politiques pour le cycle de vie complet des NHI de la création à la terminaison. Ajoutez un article clair dans votre politique de sécurité IT partagée avec tous les employés. Souvent, les solutions de coffres-forts fournissent des hooks de cycle de vie et un étiquetage de métadonnées pour suivre la propriété, l’objectif et l’expiration.
  5. Évaluations de sécurité régulières spécifiques aux NHI : ne vous concentrez pas uniquement sur les applications individuelles ou la sécurité globale de l’entreprise lors des évaluations de sécurité. Menez des audits ciblés et des tests de pénétration focalisés sur les NHI. Par exemple, testez la portée des tokens GitLab ou GitHub créés par les développeurs, souvent ceux-ci sont sur-permissionnés par défaut et rarement tournés.

Sécurité matérielle

Pour les identités non-humaines, utiliser une sécurité basée sur le matériel comme TPM 2.0 est une bonne pratique pour assurer la confiance et l’intégrité. TPM 2.0 stocke de manière sécurisée les clés cryptographiques, supporte le démarrage sécurisé et permet l’attestation d’appareil, aidant à vérifier que seules les NHI de confiance peuvent accéder aux systèmes ou données sensibles. Cela renforce la liaison d’identité et protège contre la manipulation au niveau matériel.

Conclusion

Les identités non-humaines sont devenues fondamentales pour les écosystèmes numériques modernes, alimentant l’automatisation, la capacité de montée en charge et l’intégration entre plateformes.

Cependant, avec leur présence croissante vient une augmentation parallèle du risque. Et nous n’avons même pas abordé le combo explosif des NHI et de l’IA (comme quand votre assistant IA dans VS Code a soudainement accès à tout votre code source plein de NHI…).

Gérer de manière sécurisée les NHI n’est plus optionnel ; c’est un impératif stratégique pour protéger les systèmes et données critiques, et encore une chose à ajouter sur la feuille de route sécuritaire critique.

En reconnaissant les défis uniques que présentent les NHI et en implémentant une gouvernance robuste, les organisations peuvent transformer une vulnérabilité potentielle en force. La découverte proactive, l’accès au moindre privilège, la gestion du cycle de vie et la surveillance continue ne sont pas seulement des bonnes pratiques, ce sont des défenses essentielles dans le paysage des menaces d’aujourd’hui.

Investir dans la sécurité des NHI aujourd’hui, c’est investir dans la résilience, la confiance et la sécurité de l’infrastructure numérique de demain.