Gérer le cycle de vie des identités non humaines dans les environnements modernes

Introduction : pourquoi le cycle de vie des identités non humaines mérite une attention particulière

Les identités non humaines (NHIs) couvrent toutes les informations d'identification ou constructions d'identité qui permettent à un système, une application ou un processus automatisé de s'authentifier et d'interagir avec d'autres ressources sans qu'un compte humain soit directement impliqué. Les NHIs incluent les comptes de service dédiés aux applications ou services, les clés API qui sont des jetons statiques pour accéder à des services externes, les jetons à courte durée de vie tels que les jetons OAuth ou JWT, et les informations d'identification d'automatisation utilisées dans les pipelines CI/CD, les outils de gestion de configuration ou les workflows RPA. Dans les organisations avec une infrastructure diversifiée et des routines d'automatisation complexes, les NHIs dépassent en nombre les utilisateurs humains par dix fois ou plus. Même une organisation de taille moyenne peut avoir des centaines de NHIs, et les grandes entreprises peuvent en avoir des milliers. Pour plus d'informations sur les types de NHI et les défis de sécurité, consultez notre article sur la non-human identity security.

La gestion du cycle de vie des identités humaines est bien établie et mature, où les workflows pilotés par les RH permettent à l'informatique de gérer la fourniture et la suppression des accès des employés entrants, déplacés et sortants avec des rôles RBAC et des revues d'accès périodiques. En revanche, les NHIs n'ont pas de structure de gestion définie. Ils sont souvent créés de manière ad hoc par les développeurs ou les équipes DevOps, se voient accorder des permissions excessives ou larges par commodité, laissés sans propriété documentée, et configurés avec des identifiants statiques qui changent rarement.

Sans gestion formelle du cycle de vie NHI, les organisations sont confrontées à trois défis :

• Prolifération des identités : Prolifération incontrôlée des NHIs dans l'infrastructure, rendant la gouvernance extrêmement difficile car vous ne pouvez pas examiner ni protéger ce que vous ne pouvez pas trouver.
• Identifiants orphelins : NHIs qui ont perdu leur propriétaire légitime ou leur raison d’être mais qui sont toujours actifs. Comme aucune équipe ne les utilise activement, ils restent un risque caché que les attaquants peuvent exploiter.
• Angles morts de la sécurité : Les NHIs restent généralement en dehors du périmètre de surveillance des outils de sécurité tels que SIEM ou SOAR, qui sont configurés pour détecter les activités suspectes des comptes humains. Les plateformes de gouvernance d'identité se concentrent également sur les comptes humains et n'incluent généralement pas les NHIs, ce qui laisse une surface d'attaque importante ouverte.

Cet article se concentre sur les cinq étapes du cycle de vie du NHI, de la découverte et la création jusqu’à la surveillance, la gestion des risques et la mise hors service sécurisée.

Définir les identités non humaines dans les écosystèmes informatiques actuels

Les identités non humaines (NHIs) sont des identités numériques attribuées aux machines, applications, services, conteneurs, scripts et processus automatisés qui fonctionnent de manière autonome. Sans interaction humaine, elles s’authentifient, obtiennent des autorisations spécifiques, accèdent aux ressources et exécutent des actions de manière programmatique au sein des systèmes informatiques. Par exemple, une application hébergée sur AWS peut utiliser un rôle IAM pour accéder aux fichiers de stockage, ou un microservice fonctionnant dans Kubernetes peut utiliser un compte de service pour communiquer avec d’autres services.

Les NHIs s'authentifient en utilisant des mécanismes adaptés aux machines tels que les clés API, les secrets partagés, les certificats, les jetons JWT ou OAuth, et les identités de charge de travail. Contrairement aux comptes humains, ils ne se connectent pas de manière interactive, n'utilisent pas de mots de passe au sens traditionnel, et reposent souvent sur des identifiants stockés. Parce qu'ils fonctionnent automatiquement, les NHIs peuvent exécuter des centaines ou des milliers d'actions à très grande vitesse et doivent être régis par les mêmes contrôles et normes de sécurité que les identités humaines.

Les NHIs sont essentiels dans l'infrastructure informatique complexe d'aujourd'hui. Les organisations modernes doivent adopter des architectures de déploiement cloud-native, et les microservices ainsi que les pratiques DevOps nécessitent une communication machine-à-machine comme base.

• Interaction avec l’API : Les applications modernes dépendent fortement des API. Les applications communiquent avec les bases de données, les passerelles de paiement, les services de stockage, les outils de surveillance et les plateformes SaaS tierces en utilisant des API. Chacune de ces interactions est alimentée par un NHI et nécessite une authentification.
• DevOps et pipelines CI/CD : Les pipelines d’intégration continue et de déploiement continu automatisent la construction, les tests et les déploiements des logiciels. Ces pipelines utilisent des agents NHI pour s’authentifier auprès des dépôts de code source, des registres d’artefacts, des plateformes de conteneurs, des environnements cloud pour le déploiement, et des outils de notification. Chaque interaction nécessite une authentification avec un NHI distinct, et ces identités disposent souvent de permissions élevées.
• Cloud workloads : Les environnements cloud natifs créent et détruisent dynamiquement des workloads tels que des machines virtuelles, des conteneurs, des fonctions serverless et des pods Kubernetes. Ces workloads reçoivent des NHIs assignés pour accéder au stockage, interroger des bases de données et accéder aux services de messagerie. Tous ces NHIs créés, modifiés et retirés nécessitent une gestion du cycle de vie avec une visibilité appropriée.
• Tâches planifiées et automatisation : Au-delà du cloud et de DevOps, les environnements informatiques traditionnels dépendent également des NHIs pour les traitements par lots, les scripts planifiés, les tâches de synchronisation des données, les services de sauvegarde et les agents de surveillance. Ces tâches d'automatisation s'exécutent sous des comptes de service avec des privilèges élevés et ne sont pas souvent renouvelées, surveillées ou correctement restreintes.

Types courants d’identités non humaines que les organisations gèrent

Comptes de service et identités d'application : Ces identités sont des comptes dédiés et non interactifs créés spécifiquement pour les applications, services et processus afin de s'authentifier et d'accéder aux ressources en toute sécurité. Par exemple, une application de paie se connectant à une base de données SQL pour accéder aux données des employés en utilisant un compte de service garantit la continuité indépendamment des changements de personnel. Il s'agit généralement d'identifiants ou de clés fixes qui sont rarement modifiés, accumulent souvent des privilèges excessifs au fil du temps et sont fréquemment partagés entre plusieurs applications et environnements.

Clés API, jetons et certificats : Ces identités sont utilisées dans les interactions machine-à-machine. Plutôt que de se connecter avec un nom d’utilisateur et un mot de passe, les applications et services utilisent ces identités pour s’identifier de manière sécurisée. Les clés API sont souvent des chaînes secrètes statiques émises par un service (comme AWS, Entra ID ou Stripe) pour identifier et autoriser une application appelante. OAuth ou JSON Web Tokens (JWT) sont des jetons à courte durée de vie délivrés après un événement d’authentification qui accordent l’accès à quiconque les détient sans vérification supplémentaire. Les certificats basés sur PKI sont utilisés pour l’authentification TLS mutuelle, la signature de code et la communication dans un maillage de services. Bien que ces certificats aient une date d’expiration, les certificats non gérés sont une cause majeure de pannes de service.

Identités des charges de travail cloud et des conteneurs : Les NHIs sont attribuées dynamiquement aux machines virtuelles, conteneurs, fonctions serverless et pods Kubernetes. Ces charges de travail interagissent entre elles ainsi qu'avec d'autres plateformes cloud ou infrastructures sur site. Bien que les identités gérées réduisent le besoin de secrets codés en dur, les permissions mal configurées associées aux rôles IAM utilisés par ces charges de travail sont des cibles privilégiées pour les attaquants.

Identités DevOps, CI/CD et automatisation : Les environnements DevOps dépendent fortement des identités d'automatisation. Les outils de pipeline CI/CD comme Jenkins, GitHub Actions, GitLab CI et CircleCI nécessitent des identifiants pour extraire le code, pousser des artefacts, déployer dans des environnements cloud et mettre à jour l'infrastructure. Les outils d'infrastructure en tant que code comme Terraform et Ansible requièrent des identifiants de fournisseurs cloud avec des permissions étendues. En cas de compromission, ces identités d'automatisation peuvent fournir aux attaquants un contrôle immédiat sur les environnements de production.

Agents IA et identités de systèmes autonomes : À mesure que les organisations adoptent l'automatisation pilotée par l'IA à un rythme plus rapide, une nouvelle catégorie de NHI émerge. Ces agents IA et identités de systèmes autonomes représentent des copilotes IA interagissant avec les systèmes d'entreprise, des bots intelligents effectuant des tâches opérationnelles, des modèles d'apprentissage automatique accédant aux pipelines de données, et des bots d'automatisation des processus robotiques (RPA) remplissant des formulaires et transformant des données. Les organisations doivent être prudentes lors du déploiement de ces agents IA et doivent définir un système de gestion du cycle de vie des identités qui contrôle et surveille la portée des accès avec une piste d'audit.

Identités humaines vs non humaines : une comparaison du cycle de vie

Les identités humaines et non humaines nécessitent toutes deux une gouvernance ; cependant, leurs cycles de vie diffèrent fondamentalement en termes de structure, de propriété, de profil de risque et de comportement opérationnel. Les processus IAM traditionnels ont été conçus principalement pour les utilisateurs humains, et lorsqu'ils sont appliqués tels quels aux NHIs, ils échouent souvent à fournir un contrôle adéquat.

Les flux de travail IAM traditionnels sont conçus autour du cycle de vie de l'emploi humain. Ils supposent une propriété claire du compte et que le statut RH déclenche des événements. Les NHI ne suivent pas ces modèles et nécessitent une gestion du cycle de vie spécialement conçue car ils n'ont pas de dossier RH, pas de manager, pas d'événements de connexion interactifs et pas de calendrier naturel de départ.

Ce que le cycle de vie de l’identité non humaine inclut réellement

Les NHIs nécessitent une gestion structurée du cycle de vie comme les utilisateurs humains, mais la gestion doit s'adapter à des scénarios tels que l'automatisation, la communication machine à machine et la scalabilité à grande vitesse. Voici les cinq étapes critiques du cycle de vie des NHI :

Gérer les NHIs avec une approche par cycle de vie garantit qu'aucun angle mort en matière de sécurité n'est présent. Chaque étape fonctionne comme un contrôle de sécurité : l'absence de découverte conduit à des identités fantômes, une provision faible conduit à une escalade de privilèges, l'absence de surveillance signifie que les compromissions restent non détectées, l'absence de rotation des identifiants signifie qu'une clé divulguée accorde un accès persistant, et l'absence de mise hors service laisse des identifiants orphelins créant des portes dérobées persistantes non détectées.

Étape 1 : découverte et inventaire des identités non humaines

La découverte est la première étape cruciale dans la gestion des identités non humaines, car la première règle en matière de sécurité est « vous ne pouvez pas protéger ce que vous ne pouvez pas voir ». Avant qu'une gouvernance, une politique ou un contrôle de sécurité puisse être appliqué, les organisations doivent établir un inventaire complet, précis et continuellement mis à jour de chaque NHI dans leur environnement.

Ce que la découverte nécessite

Analyse continue : Les NHIs ne sont pas statiques. Les développeurs provisionnent des comptes de service à la demande, les pipelines CI/CD génèrent des jetons à durée de vie courte, et les charges de travail cloud-native créent de nouvelles identités de manière dynamique. Un audit ponctuel capture un instantané qui devient obsolète presque immédiatement. Une découverte efficace nécessite une analyse continue et automatisée qui s’exécute selon un calendrier ou en fonction d’événements, détectant les identités nouvellement créées dès leur apparition.

Couverture inter-environnements : Les organisations modernes opèrent dans des environnements hybrides et multi-cloud. La découverte doit scanner en continu les annuaires sur site tels que Active Directory, les systèmes IAM cloud dans AWS, Azure et GCP, les plateformes SaaS, les systèmes d’orchestration de conteneurs et les coffres-forts de secrets. Si la découverte est limitée à un ou deux environnements seulement, une grande partie de la surface d’attaque NHI restera invisible.

Cartographie des attributs : La découverte ne consiste pas seulement à répertorier les identités ; elle doit également capturer le contexte complet de chaque identité afin d'appliquer les contrôles de sécurité et de gouvernance. Cela inclut la cartographie des attributs clés pour chaque NHI, tels que l'équipe ou l'individu propriétaire de l'identité, la fonction métier qu'elle remplit, les systèmes ou services qui en dépendent, et la date de la dernière rotation des identifiants.

Défis courants de découverte

1. Contrairement aux identités humaines centralisées dans un système RH ou un fournisseur d'identité principal, les NHI vivent rarement en un seul endroit. Elles existent dans les consoles IAM des plateformes cloud, les configurations locales des comptes de service sur les serveurs, les secrets stockés dans des coffres-forts, et les clés API intégrées dans les fichiers de configuration ou les dépôts de code. Cette dispersion des identités rend difficile l'obtention d'un inventaire précis sans outils spécialisés de gestion des NHI.
2. Contrairement aux identités humaines qui se synchronisent depuis les systèmes RH vers un annuaire centralisé, les NHI n'ont généralement pas de système d'origine faisant autorité. Plusieurs identités peuvent remplir la même fonction, les identités orphelines restent actives après la mise hors service des applications, et des identifiants en double existent dans différents environnements. Les équipes de sécurité doivent agréger et corréler les données provenant de plusieurs sources pour construire une plateforme d'inventaire unifiée.
3. L'une des situations les plus difficiles dans la découverte NHI est celle des identités fantômes. Les développeurs et les ingénieurs DevOps créent fréquemment des identités pour des corrections rapides, des tests et des déploiements rapides en dehors des processus formels de provisionnement. Ces identités manquent de documentation et de périmètre appropriés, ce qui les rend à haut risque et difficiles à découvrir.

Étape 2 : approvisionnement sécurisé et attribution des accès

La première ligne de défense est la phase de provisionnement. La manière dont les NHIs sont créés détermine leur profil de risque tout au long de leur cycle de vie. Si une identité dispose de permissions excessives non documentées et sans propriétaire clair, cela devient un risque pouvant persister pendant des années sans être détecté.

Meilleures pratiques de provisionnement

Standardiser les workflows de création : Chaque NHI doit être créé via un processus prédéfini et répétable, et l'accès doit être conforme aux modèles de contrôle d'accès basé sur les rôles ou basé sur les attributs. Cela signifie établir des modèles approuvés pour les types d'identité courants tels que les comptes de service, les clés API et les jetons de pipeline CI/CD afin de garantir qu'aucun NHI n'entre dans l'environnement en dehors d'une politique de gouvernance.

Appliquez le principe du moindre privilège dès le départ : L'un des plus grands risques dans la provision NHI est d'accorder un accès large pendant la phase de développement qui devient permanent en production. Le moindre privilège doit être appliqué au moment de la création de l'identité : définissez précisément les systèmes et exigences API, évaluez soigneusement les permissions à accorder, évitez les permissions génériques dans les politiques IAM cloud, et commencez par un accès minimal.

Attribuer la propriété : Chaque NHI doit être lié à un individu, un rôle ou une équipe afin d’établir une propriété claire. La propriété doit être mise à jour régulièrement dans la Change Management Database (CMDB) et les plateformes IAM afin que toute modification requise soit consultée et approuvée par le propriétaire. Si le propriétaire quitte l’organisation, la propriété doit être réattribuée immédiatement.

Définir des dates d'expiration : De nombreux NHIs sont créés pour des projets temporaires, des migrations, des environnements de test, des intégrations de fournisseurs et des tâches d'automatisation à court terme, mais ils sont rarement désactivés après que le besoin a expiré. Assignez un temps de vie (TTL) à chaque NHI. Lorsqu'il expire, le propriétaire doit revoir le besoin, et si ce n'est pas approuvé, le NHI doit être automatiquement supprimé du système.

Pièges de provisionnement à éviter

• Permissions excessives : Sous la pression des délais, les équipes accordent souvent des permissions excessives « juste pour que ça fonctionne ». Ces permissions excessives sont rarement réduites une fois que tout fonctionne et créent des chemins cachés d’escalade de privilèges pouvant devenir des opportunités de mouvement latéral ou de graves violations de conformité.
• Copier les autorisations à partir des NHIs existants : Lors de la création d'une nouvelle identité, il est plus facile de copier les autorisations à partir de celles existantes, à condition que ce soit la méthode approuvée. Cependant, cela crée des problèmes tels que l'héritage d'autorisations obsolètes ou excessives qui n'ont jamais été formellement approuvées.
• Création de NHIs sans documentation ni responsabilité : Lorsque des NHIs sont créés sans documentation et que l'inventaire n'est pas mis à jour, les équipes de sécurité ne peuvent pas les inclure dans leur périmètre, les évaluations des risques deviennent obsolètes, et il n'y a aucun plan de réponse aux incidents ni de mise hors service.

Étape 3 : surveillance continue et supervision comportementale

Une fois qu'un NHI est provisionné, le travail de sécurité ne s'arrête pas. Il se déplace vers une surveillance continue, pas seulement des revues d'accès statiques périodiques, mais une surveillance de l'utilisation des permissions et de l'évolution des rôles et permissions au fil du temps. La surveillance continue garantit que ce que fait un NHI correspond à ce qu'il devrait faire, et si des écarts sont détectés, l'investigation et la remédiation peuvent empêcher que ces écarts ne deviennent un incident.

Que surveiller

Modèles d'utilisation : Comprendre et surveiller la fréquence et le contexte dans lesquels un NHI fonctionne constitue la base pour comprendre les risques associés. Un NHI est-il actif quotidiennement ou seulement pendant les derniers jours de la semaine ou du mois ? S'il traite 100 requêtes par heure, quelle est la cause d'un pic soudain à 10 000 requêtes ? Un pic de fréquence d'utilisation ou de volume d'appels en dehors de la fenêtre d'exploitation habituelle peut indiquer une compromission ou une utilisation abusive. Si un NHI n'est pas actif pendant une longue période, cela peut indiquer un service désaffecté dont les identifiants n'ont jamais été révoqués.

Portée d'accès : Surveiller ce qu'un NHI accède, comme les ressources, les API, les magasins de données ou les services, est essentiel pour la visibilité et pour s'assurer que le comportement réel à l'exécution correspond à la conception d'accès prévue. Même si un NHI fonctionne normalement, un accès excessif constitue un risque potentiel. La visibilité sur la portée d'accès doit inclure une revue périodique des accès, les affectations de rôles et une évaluation des risques basée sur la criticité de l'accès.

Modifications inhabituelles : Tout changement d’accès, en particulier ceux inattendus ou non autorisés, doit constituer un signal d’alarme pour les équipes de sécurité. Cela inclut les nouvelles affectations de rôle, les pièces jointes de politique, les modifications d’appartenance à un groupe ou les octrois d’accès secrets qui ne faisaient pas partie d’un processus de gestion des changements. Étant donné que les NHIs ne peuvent pas initier eux-mêmes des demandes, un changement d’accès inattendu doit être considéré comme une activité malveillante possible, un abus interne ou une mauvaise configuration de l’automatisation, et doit être investigué rapidement.

Dérive des permissions : Au fil du temps, les NHIs ont tendance à accumuler des permissions pour différentes tâches ou projets temporaires et obtiennent plus d’accès que prévu initialement. Les causes courantes incluent l’expansion des projets, l’accès temporaire ajouté pour le dépannage qui n’a jamais été retiré, et les changements d’héritage de rôle dus à une imbrication complexe des groupes. La dérive des permissions doit être surveillée rigoureusement en comparant les permissions actuelles aux modèles de permissions de référence.

Journalisation et conformité

Les journaux d'activité NHI ne sont pas optionnels ; ils sont aussi cruciaux que les journaux d'activité humaine pour les exigences de conformité, la préparation aux audits et la réponse aux incidents. Des cadres tels que PCI DSS, HIPAA, SOC 2 et GDPR exigent la traçabilité, la responsabilité et les pistes d'audit des accès au système, qu'il s'agisse d'un compte humain ou d'une identité non humaine.

• Traçabilité : Chaque action automatisée doit être attribuable à une identité spécifique afin que la propriété puisse être établie.
• Preuves d'audit : Les organisations doivent pouvoir démontrer qui a accédé aux systèmes sensibles, quand l'accès a eu lieu, quelles actions ont été effectuées et si l'accès était autorisé.
• Enquête sur les incidents : Lors des enquêtes judiciaires sur les violations de sécurité, les journaux d’identité aident à déterminer si les identifiants ont été compromis, à tracer les mouvements latéraux, à établir l’étendue de l’exfiltration des données et à construire une chronologie claire pour reconstituer les événements de l’attaque.

Étape 4 : gestion des risques liés aux identifiants

Les secrets à longue durée de vie sont l’un des aspects les plus dangereux de la sécurité des identités non humaines et représentent un risque systémique. Contrairement aux identifiants humains où les changements de mot de passe sont imposés par la politique et où la MFA ajoute une couche supplémentaire de sécurité, les identifiants NHI restent souvent statiques pendant des mois voire des années. Si ces identifiants sont divulgués, ils restent activement exploitables jusqu’à ce que les autorisations soient explicitement révoquées ou que l’identité soit supprimée.

Pourquoi la rotation est importante

Exposition non détectée : Les identifiants peuvent être divulgués via les journaux, les environnements de développement ou des techniques sophistiquées sans déclencher aucune alarme. Si un secret est accidentellement commité dans Git, exposé via un bucket de stockage cloud mal configuré, ou extrait de la mémoire ou des journaux, les attaquants obtiennent un accès persistant et les organisations n’ont aucune idée qu’une compromission a déjà eu lieu.

La rotation limite le rayon d'impact : La rotation agit comme une limite de temps sur la compromission possible. En changeant fréquemment les identifiants, les attaquants avec un accès silencieux sont automatiquement révoqués. Par exemple, si une clé est tournée toutes les 24 heures, une clé volée devient inutile le lendemain. Un jeton à courte durée de vie valable 15 minutes limite l'exposition à seulement 15 minutes. Le principe est simple : plus un secret vit longtemps, plus la probabilité qu'il ait été exposé via un vecteur d'attaque non détecté est grande.

Conformité et gouvernance : Les cadres modernes de sécurité et de conformité exigent explicitement des contrôles de gestion des identifiants et ne considèrent plus la rotation des identifiants comme un simple avantage, mais comme un contrôle obligatoire. Les auditeurs ont besoin de preuves de la fréquence de rotation des identifiants des comptes de service, de savoir si la rotation est automatisée et de ce qui se passe lorsqu’un secret est exposé.

Bonnes pratiques de rotation

Définir les politiques de rotation : La rotation manuelle des identifiants n'est pas fiable par conception, car les équipes peuvent oublier ou ne pas avoir de responsabilité claire. Une politique de rotation formelle doit définir quels identifiants doivent être renouvelés, la durée de vie maximale par type d'identifiant, qui est responsable de la rotation et quels outils doivent être utilisés. La rotation pilotée par la politique garantit la cohérence dans des environnements divers et crée une piste d'audit claire.

Définir les calendriers de rotation : Toutes les informations d'identification ne présentent pas le même niveau de risque, et la fréquence de rotation doit être définie en conséquence. Les comptes de service à privilèges élevés doivent être renouvelés quotidiennement ou hebdomadairement, les clés API cloud avec des permissions larges doivent être renouvelées hebdomadairement ou mensuellement, et les jetons d'accès utilisateur doivent être de courte durée (valables pour quelques minutes, pas des jours). L'objectif est de faire de la rotation un processus en arrière-plan plutôt qu'un contrôle d'urgence périodique.

Répondez immédiatement aux expositions :La rotation ne doit pas seulement être basée sur le temps ; elle doit également être déclenchée par des événements basés sur une surveillance continue. Les organisations doivent disposer d’un processus défini pour la gestion des incidents de credentials qui se déclenche immédiatement lorsqu’une compromission est suspectée ou confirmée. Lorsqu’une exposition est détectée, un processus automatisé doit révoquer le credential compromis, générer un nouveau secret, mettre à jour tous les services dépendants, et enregistrer et notifier les parties prenantes.

Étape 5 : mise hors service et désactivation des identités non humaines

La mise hors service est souvent la phase la plus négligée du cycle de vie des identités non humaines. Alors que les organisations se concentrent sur la fourniture et la surveillance, la suppression des NHI se fait généralement lors de campagnes informelles ou pas du tout. En conséquence, de nombreux NHI orphelins restent dans le système en tant que comptes fantômes qui créent une surface d'attaque cachée.

Identification des NHIs pour la mise hors service

La mise hors service efficace commence par la visibilité. Les organisations doivent détecter de manière proactive les NHIs qui ne devraient plus exister.

Identités inutilisées : De nombreux NHIs sont créés pour des projets à court terme, des intégrations temporaires, des environnements de test ou des initiatives de migration. Une fois ces projets terminés, ces NHIs restent dans le système avec des identifiants valides. Il devrait y avoir une politique qui évalue quand un NHI n’est plus utilisé, par exemple en l’absence d’événements d’authentification pendant des périodes définies (30, 60 ou 90 jours).

Identités orphelines : Les NHIs deviennent orphelines lorsque leurs propriétaires ou équipes responsables quittent l’organisation, sont réaffectés à d’autres projets, ou lorsque les applications pour lesquelles le NHI a été créé sont retirées sans nettoyage des NHI. Sans propriétaire, personne ne peut examiner les droits d’accès, renouveler les identifiants ou surveiller les activités anormales. Les identités orphelines sont particulièrement dangereuses car elles semblent légitimes dans les systèmes mais ne bénéficient d’aucune supervision.

Identités dupliquées : Dans les environnements DevOps décentralisés, plusieurs équipes peuvent créer des identités distinctes pour des tâches identiques, ce qui entraîne des comptes de service redondants, des clés API qui se chevauchent ou plusieurs identifiants avec des droits d'accès similaires. Les identités dupliquées augmentent la complexité et le risque car les pistes d'audit deviennent plus difficiles à maintenir et la révocation de l'accès d'une identité n'élimine pas le risque d'accès.

Processus de mise hors service sécurisée

Supprimer un NHI sans validation minutieuse est en soi un risque. Cela peut casser des applications ou des services dépendants en production. Le processus de mise hors service doit être effectué de manière systématique.

1. Identifier et profiler : Utilisez des outils de découverte automatisés pour signaler les identités basées sur l'inactivité ou l'absence d'un propriétaire valide, que l'application ou le service associé soit retiré, ou si le NHI est confirmé comme une identité dupliquée. Les NHIs identifiés doivent être envoyés pour examen aux propriétaires d'applications, aux équipes de sécurité et DevOps.
2. Vérification des dépendances : Avant de désactiver ou de supprimer un NHI, vérifiez qu'il ne prend pas en charge activement des tâches en arrière-plan, des tâches d'automatisation planifiées, des intégrations tierces, des processus de reprise après sinistre ou des systèmes hérités. Les vérifications des dépendances nécessitent l'examen des journaux d'authentification, la vérification des configurations CI/CD, l'analyse des modèles d'infrastructure en tant que code et la consultation des propriétaires d'applications.
3. Désactiver avant de supprimer :Ne jamais supprimer immédiatement. La meilleure pratique consiste à procéder par étapes : désactiver d'abord la capacité d'authentification, surveiller les échecs ou erreurs système, laisser une période de grâce définie (7 à 30 jours), puis supprimer définitivement si aucun impact ne survient. Cela permet aux équipes de valider tout impact et facilite un retour rapide en arrière.
4. Suppression du document à des fins d'audit : Une fois toutes les phases de mise hors service terminées, effectuez une suppression définitive et assurez-vous que cette action est enregistrée dans les journaux de la plateforme SIEM pour la traçabilité de l'audit. Documentez les informations nécessaires, y compris le nom de l'identité avec son identifiant unique, les systèmes et privilèges associés, la raison de la suppression, les détails du processus de révision et d'approbation, ainsi que la date de suppression.

Pièges courants dans la gestion du cycle de vie NHI

Comment Netwrix prend en charge la gestion du cycle de vie NHI

Netwrix Identity Manager fournit un cadre complet de gouvernance et d'administration des identités (IGA) qui gère les comptes humains et les identités non humaines sur une seule plateforme avec des processus automatisés de cycle de vie. Netwrix Identity Manager construit un référentiel d'identité centralisé qui inclut tous les types d'identités pour créer un inventaire unifié servant de base à la gestion du cycle de vie des identités.

Découverte et inventaire : Tous les types d'identité, y compris les NHI, sont synchronisés dans un référentiel centralisé de Identity Management qui offre une visibilité et réduit la prolifération des identités. Les connecteurs extraient les données d'identité et d'habilitation de différents annuaires (Active Directory, Microsoft Entra ID) et applications métier, intégrant les NHI dans le périmètre de gouvernance aux côtés des identités humaines.

Provisionnement contrôlé : Un flux de travail de provisionnement standardisé est défini pour chaque identité, réduisant le provisionnement ad hoc avec des permissions excessives. Des flux de travail basés sur des politiques sont déclenchés lorsqu'une création d'identité est demandée, appliquant les principes du moindre privilège pour ne provisionner que l'accès requis par le rôle de l'identité. Le contrôle d'accès basé sur les rôles garantit que les identités ne reçoivent que les permissions appropriées à leur fonction.

Surveillance et révision continues : Netwrix Identity Manager suit les droits, les événements de changement et le statut de conformité pour toutes les identités qu’il gère. Il offre des capacités intégrées de campagnes de certification d’accès avec des analyses de risque pour détecter lorsque les NHIs accumulent des permissions excessives et surveille les modèles d’accès et l’utilisation des ressources. Il aide à détecter les identités dormantes ou orphelines, la prolifération des privilèges et les violations de la séparation des tâches pour les identités humaines et non humaines.

Correction et nettoyage des accès : Netwrix Identity Manager permet aux organisations d’analyser les autorisations de chaque identité par rapport aux règles de la politique. Les NHIs qui n’ont plus besoin d’accès ou qui disposent d’autorisations dépassant ce que la politique autorise peuvent être signalés pour correction. Des règles peuvent être définies pour identifier les comptes inutilisés qui ne se sont pas connectés pendant une période donnée (comme 90 jours), les NHIs orphelins dont le propriétaire est absent, ou les autorisations excessives révélées lors de la certification des accès.

Clôture du cycle de vie : Netwrix Identity Manager automatise les phases de provisionnement, de mise à jour et de suppression avec des workflows complets qui prennent en charge les processus joiner-mover-leaver (JML). Lorsqu'une application ou un service est retiré, qu'un projet se termine ou qu'un propriétaire humain part ou passe au projet suivant, Netwrix Identity Manager s'assure que les NHIs associés voient leurs permissions révoquées puis finalement supprimées.

Conclusion : de la prolifération des identités au contrôle du cycle de vie

Dans l'infrastructure informatique moderne, les identités non humaines sont devenues le type d'identité dominant et ne vont pas disparaître. Elles se multiplient de manière exponentielle. Chaque nouveau mécanisme d'automatisation, charge de travail cloud et agent IA augmente l'empreinte toujours croissante des NHI. Le passage d'une conception d'application monolithique aux microservices signifie plusieurs identités pour chaque sous-service communiquant avec d'autres services. Les charges de travail cloud telles que les machines virtuelles, les fonctions serverless, les conteneurs et les services gérés nécessitent tous plus de NHI. Les pipelines DevOps dépendent fortement des service principals, des jetons de déploiement, des intégrations Git, des identifiants API et des agents de build. Les NHI dépassent désormais en nombre les identités humaines dans un rapport de 10 pour 1, et ce ratio continue d'augmenter.

La gestion du cycle de vie des NHI transforme les NHI d’un risque croissant en une catégorie d’actifs gouvernée et permet aux organisations de gérer les NHI avec des contrôles plus efficaces nécessaires à l’échelle et à l’impact qu’ils représentent. En abordant chaque étape (découverte, provisionnement, surveillance, rotation et mise hors service), les organisations peuvent réduire la prolifération des identités, appliquer le principe du moindre privilège et combler les lacunes de sécurité que l’IAM traditionnel ne peut pas traiter pour les NHI.