Le cycle de vie des identités non humaines (identité non humaine) est la gestion de bout en bout des identités non humaines et des identifiants qui les représentent, depuis leur création jusqu'à leur déclassement. Cela inclut le provisionnement sécurisé, la gouvernance des accès, la surveillance continue et le retrait contrôlé des comptes de service, des clés API, des jetons, des certificats et des agents d'IA.
Pourquoi la gestion du cycle de vie des utilisateurs de l'identité non humaine est importante
Les recherches menées dans le domaine de l'identité montrent que les identités non humaines sont aujourd'hui par un facteur de 50 plus nombreuses que les utilisateurs humains dans les environnements d'entreprise moyens. Pourtant, de nombreuses organisations gèrent ces identifiants après coup, voire pas du tout.
Le problème vient de la façon dont les identités des machines sont créées. Les employés entrent dans les organisations par le biais de systèmes de ressources humaines qui déclenchent des workflows de provisionnement, des examens d'accès et des processus d'offboarding. Les identifiants machine apparaissent lorsqu'un développeur met en place une infrastructure, lorsque les pipelines CI/CD déploient du code ou lorsque des scripts d'automatisation ont besoin d'un accès. Souvent, il n'existe pas de processus cohérent de monitorage du cycle de vie de ces identifiants, ni de déclencheur fiable pour les retirer lorsqu'elles ne sont plus nécessaires.
Cette lacune crée une exposition persistante aux risques de sécurité. Selon le Top 10 des identités non humaines de l'OWASP, l' offboarding inadéquat se classe systématiquement parmi les risques les plus critiques. Les comptes de service conservent l'accès à la production plusieurs mois après leur expiration prévue. Les clés d'API restent dans les référentiels de code abandonnés, et les identifiants provisionnés pour des projets temporaires restent actifs indéfiniment.
Qu'est-ce qui différencie les identifiants des machines ?
Les identités non humaines ne disposent pas des contrôles de sécurité qui protègent les utilisateurs humains :
- Authentification multifacteur (authentification multifacteur) : Au lieu de l'authentification multifacteur interactive, la gestion de l'identité non humaine repose sur des contrôles non interactifs, tels que l'authentification par certificat et la fédération des identités de charge de travail. Dans certains environnements, une attestation basée sur le matériel ou la plateforme vérifie l’intégrité d’une charge de travail avant d’en autoriser l’accès.
- Examens d'accès programmés : Les employés sont souvent soumis à des certifications trimestrielles, mais les identifiants des machines font rarement l'objet d'un examen formel. Les autorisations identité non humaine peuvent s'accumuler au fil du temps, entraînant un accès surpriviliégié (identité non humaine5:2025).
- Points d'arrêt naturels : L'accès humain prend fin lorsque l'emploi prend fin. Les identifiants des machines n'ont pas de déclencheur équivalent. Lorsqu'un projet se termine, les identifiants associés restent souvent actifs en tant qu'« identifiants zombies ».
Le fossé du cycle de vie : identités humaines et non humaines
Les approches traditionnelles de gestion des identités et des accès (IAM) n'ont pas été conçues pour les identifiants des machines. Voici comment ils se comparent :
Aspect | Cycle de vie de l'identité humaine | Cycle de vie de l'identité non humaine |
|---|---|---|
Déclencheur de création | Le système RH provisionne | Les développeurs ou les scripts créent des identifiants à la demande |
Évaluations des accès | Les certifications trimestrielles sont requises. | Rarement révisées ; les autorisations persistent |
Cessation d'activité | Automatique en cas de cessation d'emploi | Pas de déclencheur ; identifiants oubliés |
Authentication | Authentification multifacteur (FIDO, biométrie) | mTLS, authentification basée sur des certificats, fédération des identités de charges de travail et rotation automatisée des identifiants |
Gestion des identités de la charge de travail : une approche spécialisée
La gestion des identités de charges de travail (WIM) s’adresse à un sous-ensemble spécifique d’identités non humaines. Le cycle de vie des identités non humaines (NHI) englobe tous les identifiants machine (y compris les clés API statiques pour les SaaS tiers). WIM cible les identités attribuées aux composants logiciels en cours d'exécution, tels que les conteneurs, les machines virtuelles et les fonctions sans serveur.
Les plateformes WIM découvrent en permanence les identités des charges de travail au fur et à mesure de leur création et appliquent des politiques de moindre privilège dans des environnements dynamiques. C'est particulièrement essentiel dans les clusters Kubernetes, où les pods montent et descendent en charge automatiquement, ou dans les architectures sans serveur, où les fonctions peuvent n'exister que pendant quelques secondes.
Les quatre phases du cycle de vie des identité non humaine
Une gestion efficace du cycle de vie des utilisateurs lie la durée de vie de chaque identifiant à son objectif.
Phase 1 : découverte et évaluation
Avant de gérer les identités des machines, les équipes sécurité ont besoin d'une visibilité complète. Ce processus de découverte doit être exécuté en continu pour prendre en compte les identifiants que les développeurs créent quotidiennement.
Inventaire des efforts de découverte :
- Comptes de service sur les plateformes IAM cloud et Active Directory
- Clés et jetons API dans le code source, les outils CI/CD et les postes de travail des développeurs
- Identités de charge de travail pour les conteneurs, Kubernetes et les ressources serverless
- Identifiants d'intégration, y compris les applications OAuth et les webhooks tiers.
Phase 2 : gestion active et gouvernance
La découverte conduit à l'implémentation de contrôles axés sur la politique :
- Embarquer l'identité dans l'infrastructure en tant que code (IaC) : la définition d'un compte de service dans la même configuration (par exemple, Terraform) qui crée l'application garantit que l'identité est révoquée automatiquement lorsque la ressource est détruite.
- Remplacez les secrets statiques par des identifiants dynamiques : La transition vers des identifiants éphémères, délivrés juste à temps via la fédération des identités ou l’échange de tokens, garantit l’expiration automatique de l’accès.
- Imposer une responsabilité explicite : chaque identité de machine nécessite un « sponsor » humain désigné (généralement un ingénieur DevOps ou de plateforme) chargé de son cycle de vie.
- Standardiser les flux de travail d’approvisionnement : les contrôles d’approbation automatisés empêchent la prolifération incontrôlée des identifiants. Lorsqu’un développeur demande un nouveau compte de service via IAC, des politiques automatisées évaluent la demande par rapport aux standards de l’organisation avant son approvisionnement.
- Mettez en œuvre l'automatisation de l'application de la politique en tant que code : les moteurs de politique évaluent en permanence les identités des machines pour garantir la conformité. Si les autorisations d'un compte de service dépassent la portée approuvée, la correction automatisée révoque les privilèges excédentaires.
Phase 3 : surveillance continue et application
Le comportement de la machine est programmatique et prévisible. Les anomalies servent de signaux de sécurité pour la mise en œuvre automatisée :
- Cycles de rotation automatisés : Les identifiants doivent être rafraîchis automatiquement selon des calendriers adaptés à leur profil de risque, sans interruption de service.
- Détection des anomalies comportementales : Les réponses déclenchées par le système sont activées lorsqu'un compte de service accède à une nouvelle région cloud ou utilise une quantité inhabituellement élevée de données.
- Pistes d'audit complètes : le processus de cycle de vie enregistre chaque événement, depuis la création et l'approbation jusqu'à toutes les tentatives d'accès et la désactivation. Cela permet de soutenir les enquêtes médico-légales et les mandats de conformité tels que SOC 2, ISO 27001 et HIPAA lorsque des informations de santé protégées sont impliquées.
Phase 4 : Correction et désactivation
La phase finale consiste à mettre hors service les identités de manière sécurisée afin de réduire la surface d’attaque :
- Suspension en cas d’inactivité : le système désactive automatiquement les identifiants qui n’ont pas été authentifiés dans un délai défini (par exemple, 30 jours).
- Protocoles de sécurité « Brownout » : Avant la suppression définitive, ce processus met en œuvre une période de quarantaine temporaire de 24 heures pour s'assurer qu'il n'y a pas de dépendances critiques.
- Automatisation de la résolution des incidents : Si l’identité d’une machine est en compromission, des workflows automatisés assurent instantanément la rotation des secrets ou le passage à une identité de charge de travail de secours, permettant de maintenir la continuité du service tout en isolant la menace.
Assurer le respect des exigences de conformité
La gestion du cycle de vie des identités non humaines répond directement à de multiples exigences de conformité :
- Certification de l'accès : Des examens trimestriels automatisés présentent l'identité de chaque machine à son propriétaire désigné en vue d'une recertification. Les propriétaires doivent confirmer que l'identifiant est toujours nécessaire et qu'il est à privilèges, ou autoriser sa mise hors service.
- Application du principe du moindre privilège : une évaluation continue des politiques permet de garantir que seules les autorisations minimales nécessaires sont accordées. Les alertes automatisées signalent les dérives de privilèges avant même que les auditeurs ne puissent les découvrir.
- Préparation à l’audit : Une journalisation complète fournit aux auditeurs les preuves nécessaires : qui a créé chaque identifiant, à quoi il donne accès, quand les autorisations ont changé et pourquoi cet identifiant existe encore.
- Regulatory reporting: Les rapports automatisés démontrent la conformité avec les frameworks, notamment SOC 2 (contrôles des accès), ISO 27001 (gestion des identités), GDPR (suivi de l'accès aux données) et HIPAA (exigences en matière de piste d'audit).
Alignement sur les frameworks de sécurité
Les cadres industriels reconnaissent de plus en plus que les identités non humaines nécessitent une gouvernance spécialisée :
- Architecture Zero Trust du NIST (SP 800-207) : Le modèle Zero Trust considère que les entités non humaines (NPE) nécessitent la même vérification continue que les utilisateurs humains. La localisation du réseau ne constitue pas une base de confiance. Toutes les demandes d'accès doivent être authentifiées et autorisées en fonction du contexte actuel.
- Contrôles du CIS (version 8.1) : La version 8.1 du Center for Internet Security (CIS) intègre la fonction « Gouverner » pour mettre l'accent sur la gestion active des comptes. Le contrôle 5.1 exige spécifiquement l'établissement d'un inventaire des comptes, tandis que le contrôle 5.3 impose la désactivation des comptes inactifs afin de réduire la surface d'attaque.
- La structure d'identité et la sécurité axée sur l'identité : Gartner préconise de traiter l'identité comme une structure unifiée qui englobe les utilisateurs humains, les identifiants des machines et les agents d'intelligence artificielle, avec une application cohérente des politiques pour tous les types d'identité.
Foire aux questions (FAQ)
En quoi la gestion du cycle de vie des utilisateurs de l'identité non humaine diffère-t-elle de la gestion des secrets ?
La gestion des secrets concerne le stockage sécurisé (l'endroit où se trouve la clé). La gestion du cycle de vie des utilisateurs des INSA fait référence à la gouvernance (pourquoi la clé existe, qui la possède et quand elle doit être supprimée).
Les machines peuvent-elles utiliser l'authentification multifacteur ?
Au lieu de l’authentification multifacteur interactive, les machines utilisent l’authentification basée sur des certificats (mTLS), une attestation matérielle ou une fédération d’identités de charge de travail basée sur OIDC, où l’environnement fournit une preuve d’identité signée cryptographiquement.
À qui appartient la gestion des identités des machines ?
La propriété s’étend généralement au DevOps (création), à la politique de sécurité et à l’ingénierie de plateforme (infrastructure). L’approche la plus efficace consiste à attribuer un « sponsor » humain spécifique à chaque identifiants.
Sécurisation des identités non humaines à grande échelle
La plateforme d’identité Okta étend la gestion du cycle de vie des utilisateurs et l’application des politiques aux identifiants des machines, tout comme aux utilisateurs humains. La découverte automatisée, la gouvernance basée sur des politiques et la surveillance continue protègent les identités non humaines dans les environnements cloud, SaaS et hybrides.
