Le glissement des privilèges dans les identités non humaines (NHI) est un risque de sécurité critique dans les environnements modernes en nuage. À mesure que les organisations développent l'automatisation à l'aide de comptes de service, d'API et d'agents d'IA avec des identifiants de machine, ces identités obtiennent souvent beaucoup plus d'autorisations que nécessaire. Il en résulte une surface d'attaque élargie qui compromet l'application du principe de moindre privilège de l'entreprise Zero Trust.
Pour y remédier, un écosystème de sécurité des identités applique dynamiquement le principe du moindre privilège, ajuste en permanence les autorisations en fonction du contexte et aide les entreprises à réduire l'exposition aux risques de sécurité à la vitesse de la machine.
Qu’est-ce qu’une identité non humaine ?
Une identité non humaine (NHI) est une identité numérique utilisée par les applications, les services et les charges de travail automatisées pour s'authentifier et accéder aux ressources. Les NHI comprennent les comptes de service, les clés API, les jetons OAuth, les certificats et les identités de charge de travail utilisées par les conteneurs et les applications sans serveur.
Dans de nombreuses entreprises, les INSA sont désormais plus nombreuses que les identités humaines. Selon le rapport 2025 State of Secrets Sprawl Report de GitGuardian, 70% des secrets divulgués restent actifs deux ans après leur divulgation. Sans une gouvernance cohérente, ces identités deviennent difficiles à suivre, à contrôler et à sécuriser, ce qui en fait un point d'entrée fréquent pour les brèches de la chaîne logistique.
Contrairement aux identités humaines, les identités non humaines ne s’authentifient pas de manière interactive. Ils fonctionnent par programmation et continue, souvent sans supervision directe après leur création.
Pourquoi les NHI créent des risques uniques pour la sécurité
Création de grande quantité
Les INSA sont créées en grand nombre dans des environnements cloud natif. Chaque microservice, intégration, pipeline CI/CD et workflow d'automatisation nécessite généralement ses propres identifiants. Lorsque ces identités fantômes prennent de l'ampleur, elles contournent souvent les processus traditionnels d'Identity Governance et Administration (IGA).
Absence de gestion du cycle de vie des utilisateurs
Étant donné que les INSA ne suivent pas les déclencheurs traditionnels du cycle de vie (par exemple, les mises à jour des systèmes de ressources humaines), elles peuvent persister indéfiniment en tant qu'identités « zombies » après la fin du projet qu'elles soutenaient. Souvent dépourvues d'authentification multifacteur (MFA), les INSA peuvent être vulnérables aux attaques par le biais de secrets exposés, de clés API volées ou de comptes de service compromis. Le manque de visibilité rend les autorisations excessives difficiles à détecter sans outils spécialisés de détection et de réponse aux menaces liées à l'identité (ITDR).
Qu'est-ce que le glissement de privilège dans les identités non humaines ?
Le glissement de privilèges se produit lorsqu'une identité non humaine accumule au fil du temps des autorisations qui dépassent ses exigences fonctionnelles. Les dettes de sécurité sont souvent contractées pour augmenter la vitesse. C'est le cas lorsqu'un large accès est accordé pendant le développement ou le déploiement pour réduire les frictions, mais qu'il n'est pas réduit une fois que la charge de travail est stable.
Au fil du temps, les autorisations s'étendent aux environnements, aux services cloud et aux data stores. L'identité continue de fonctionner, mais son accès ne reflète plus son rôle prévu ou son profil de risque en temps réel.
Pourquoi le principe du moindre privilège est-il difficile à appliquer aux identités des machines ?
Le principe du moindre privilège exige que chaque identité n'ait que l'accès nécessaire à l'accomplissement de sa fonction. Si ce principe est fondamental pour la sécurité des identités, son application aux identités non humaines est complexe d'un point de vue opérationnel.
Le contrôle d'accès traditionnel basé sur les rôles (RBAC) a été conçu pour des utilisateurs humains dont les fonctions et les rôles sont stables. Le contrôle d’accès basé sur les rôles statique est trop grossier pour les charges de travail éphémères en nuage. Les charges de travail des machines nécessitent souvent des autorisations très précises qui changent en fonction de l'état de déploiement, de l'environnement et du comportement en cours d'exécution. En conséquence, les organisations s'appuient souvent sur des rôles grossiers qui introduisent des privilèges permanents inutiles.
Comment les identités non humaines surautorisées facilitent les attaques
Lorsqu'une identité non humaine est compromise, l'impact dépend des autorisations qu'elle détient. Les identifiants sur-permissionnés permettent aux attaquants d'accéder à plusieurs systèmes dans le cadre des accès accordés, y compris l'infrastructure cloud, les bases de données et les API internes.
Étant donné que les identités non humaines utilisent souvent des identifiants de longue durée et ne reposent pas sur une authentification multifacteur interactive, les attaquants peuvent maintenir un accès persistant avec une détection minimale si l'ITDR n'est pas en place.
Déplacement latéral
Un compte de service compromis avec un accès intercomptes ou interenvironnements peut permettre aux attaquants de passer des systèmes de développement aux systèmes de production ou de se déplacer latéralement entre différents fournisseurs de cloud. Une clé API avec un accès Kubernetes à l'échelle de l'organisation permet de traverser des charges de travail et des espaces de noms isolés.
Exposition des données
Les systèmes nationaux d'assurance maladie aux autorisations excessives créent des risques liés au chevauchement des autorisations. Un compte de service disposant d’un accès en lecture au stockage chiffré et de la possibilité de récupérer les clés de chiffrement peut déchiffrer les données protégées. Les identifiants qui permettent de lister les ressources et de lire les métadonnées peuvent être utilisés par des attaquants pour associer l’infrastructure et identifier des cibles de grande valeur.
Contrôle des infrastructures
Les comptes de service disposant d'autorisations pour l'infrastructure cloud peuvent permettre aux attaquants de modifier les configurations de sécurité, de créer des portes dérobées ou de provisionner des ressources malveillantes. Un identifiant d’orchestration de conteneur compromis peut déployer des mineurs de cryptomonnaie ou modifier des images pour inclure des logiciels malveillants, faisant ainsi apparaître l’activité comme une automatisation légitime.
Pourquoi les environnements en nuage font-ils l'objet d'un détournement de privilèges ?
Le glissement des privilèges dans les identités non humaines est rarement intentionnel. Il émerge de modèles opérationnels communs.
- Réutilisation des identifiants sans examen : Les identifiants sont créés une fois et réutilisés sans examen régulier ni rotation.
- Provisionnement automatisé, nettoyage manuel : le provisionnement est automatisé, mais le déprovisionnement est manuel ou incomplet, ce qui conduit à des identités « zombies ».
- Création de Shadow IT : Les développeurs créent des identités directement dans les plateformes cloud et les outils SaaS en dehors du périmètre de sécurité central.
- Propriété imprécise : La propriété est vague, ce qui conduit à des identifiants orphelins ou dormants.
En l'absence d'une Identity Governance centralisée, ces conditions font de l'accès excessif l'état par défaut.
Qu’est-ce qu’un écosystème de sécurité des identités ?
Une écosystème de sécurité des identités est une approche architecturale axée sur l'identité qui unifie l'Identity Governance, l'authentification et l'autorisation des identités humaines et non humaines. En tant que solution à la fragmentation de l'identité, il comble le fossé entre les outils IAM et PAM, en fournissant une politique centralisée et un contexte d'identité tout en appliquant les décisions d'accès dans les environnements distribués en nuage.
Plutôt que de s'appuyer sur des autorisations statiques, un écosystème de sécurité des identités peut évaluer en permanence l'identité, le contexte et le risque pour prendre des décisions en matière d'accès.
Comment un écosystème de sécurité des identités applique le principe du moindre privilège
Accès en flux tendu (JIT) pour les identités non humaines.
Un écosystème de sécurité des identités peut permettre l'accès JIT en accordant des autorisations uniquement lorsqu'une charge de travail en a besoin, pour la durée de la tâche. Une fois l'exécution terminée, le tissu est configuré pour déclencher une révocation automatique, réduisant ainsi le privilège permanent.
Autorisation en fonction du contexte
Les décisions d'autorisation intègrent le contexte de l'identité et les signaux environnementaux, tels que l'identité de la charge de travail, l'environnement cloud, les conditions réseau et l'état d'exécution. L'accès n'est autorisé que si ces conditions répondent aux exigences de la politique.
Défis de l'architecture maillée de cybersécurité
Dans une architecture maillée de cybersécurité (CSMA), les contrôles de sécurité sont répartis entre plusieurs environnements, ce qui crée des lacunes en matière de visibilité. Chaque plateforme applique les autorisations localement sans corréler les permissions sur l'ensemble du réseau ; ainsi, un compte de service unique peut accumuler des privilèges excessifs sur plusieurs systèmes, créant un risque global qu'aucun point de contrôle unique ne détecte. Un écosystème de sécurité des identités agit comme une couche d'identités dans un cadre CSMA, facilitant l'intégration de signaux d'identité partagés et d'une logique de politique conçue pour soutenir une application plus cohérente dans des environnements disparates.
Vérification continue
L'accès peut être évalué tout au long de l'exécution, pas seulement lors de l'authentification initiale. Si une identité non humaine s'écarte du comportement attendu ou si son profil de risque change, l'accès peut être restreint ou révoqué conformément à la politique.
Politiques d'accès adaptative
Les politiques s'ajustent dynamiquement en réponse aux signaux de risque. Par exemple, si une charge de travail s'exécute sur une image vulnérable ou dans un environnement mal configuré, ses autorisations peuvent être automatiquement réduites jusqu'à ce que le problème soit résolu.
Zero Trust pour les identités non humaines
Ce modèle applique les principes de Zero Trust à l'accès aux machines. Les politiques peuvent être définies pour que les demandes fassent l'objet d'une vérification cryptographique, comme la fédération des identités de charge de travail (WIF) ou l'OIDC, afin de réduire la dépendance aux secrets à longue durée de vie avant que l'accès ne soit accordé.
Gouverner la sécurité des identités non humaines à grande échelle
Le glissement des privilèges n'est pas seulement un problème de configuration. Il s'agit d'un défi de gouvernance. Alors que les identités non humaines continuent de proliférer, les organisations ont besoin de contrôles centrés sur l'identité qui englobent la découverte, la gestion du cycle de vie des utilisateurs et l'application des règles d'accès.
Un écosystème de sécurité des identités aide les organisations à identifier les identités non humaines non gérées, à ajuster les autorisations en fonction de l'utilisation réelle et à appliquer de manière centralisée le principe du moindre privilège en continu dans les environnements cloud et SaaS.
Foire aux questions (FAQ)
Qu'est-ce que le glissement de privilège dans les identités non humaines ?
L’extension des privilèges dans les identités non humaines se produit lorsque les identifiants de machine accumulent au fil du temps des autorisations qui dépassent leurs besoins opérationnels, souvent en raison d’un accès étendu accordé pendant le développement et qui n’est jamais révoqué.
Pourquoi les identités non humaines représentent-elles un risque pour la sécurité ?
Les identités non humaines fonctionnent en continu, s'appuient souvent sur des identifiants de longue durée et sont rarement réexaminées. En cas de compromission ou d'autorisation excessive, ils peuvent fournir un accès permanent sans déclencher les contrôles de sécurité traditionnels axés sur l'humain.
Quelle est la principale différence entre le risque humain et le risque lié aux identités non humaines ?
Les identités non humaines manquent de signaux comportementaux interactifs. Contrairement aux êtres humains dont la connexion peut être contestée par l'authentification multifacteur ou vérifiée par des anomalies de localisation, l'accès programmatique d'une identité non humaine est souvent binaire sur le plan fonctionnel. Les INSA possèdent ou non le secret, ce qui fait de l'autorisation continue un élément essentiel d'une défense viable.
Qu'est-ce que le contrôle des accès au moindre privilège pour les identités non humaines ?
Le contrôle des accès au moindre privilège consiste à n’accorder aux identités non humaines que les permissions nécessaires à l’exécution d’une tâche spécifique, pour la durée la plus courte possible et dans des conditions contextuelles validées dynamiquement.
Pourquoi le contrôle d’accès basé sur les rôles (RBAC) peut être insuffisant pour les identités non humaines
Le système de contrôle d’accès basé sur les rôles a été conçu pour des utilisateurs humains ayant des rôles stables. Les INSA nécessitent des autorisations granulaires et dynamiques (via ABAC ou PBAC) qui varient en fonction des conditions de déploiement et d'exécution, ce qui rend les rôles statiques trop permissifs.
Comment un écosystème de sécurité des identités peut-il réduire la dérive des privilèges ?
Un écosystème de sécurité des identités réduit la dérive des privilèges en permettant l'accès JIT, l'autorisation contextuelle et la vérification continue, afin que les autorisations soient accordées uniquement en cas de besoin et ajustées en fonction de l'évolution du contexte des risques.
Réduisez l’extension des privilèges dans les identités non humaines (NHIs) grâce à un écosystème de sécurité des identités.
Découvrez comment l'Okta Platform peut étendre la gouvernance des identités aux identités non humaines, fournir une visibilité sur les comptes de services non gérés, gérer les cycles de vie des identifiants et soutenir l’application du principe du moindre privilège dans les environnements cloud et SaaS. En appliquant une sécurité axée sur l'identité aux INSA, les organisations peuvent réduire leur surface d'attaque tout en soutenant l'automatisation moderne.
En savoir plus
