Identités non humaines (NHI) expliquées et comment les sécuriser

La plupart des organisations ne peuvent pas produire un inventaire complet des identités non humaines (NHI) fonctionnant dans leur environnement. Les comptes de service, les clés API et les identifiants d'application s'accumulent dans Active Directory (AD) et sur les plateformes cloud, souvent sans propriété claire, objectif documenté ou cycle de révision défini.

Cette lacune présente un risque réel. Selon le Rapport sur les Tendances de la Cybersécurité Netwrix 2025, 46 % des organisations ont connu des compromissions de comptes l'année dernière, contre seulement 16 % en 2020. Les identités machine à machine, comme les comptes de service et les jetons, sont un facteur croissant dans cette tendance, et la plupart des équipes informatiques de taille intermédiaire n'ont pas la visibilité nécessaire pour les gérer efficacement.

Quelles sont les identités non humaines en cybersécurité et pourquoi sont-elles importantes ?

Les identités non humaines (NHI) sont des identifiants numériques qui permettent aux machines, applications et processus automatisés de s'authentifier et d'accéder aux ressources sans intervention humaine. Les comptes de service, les clés API, les identités gérées, les jetons OAuth et les agents d'IA relèvent tous de l'ombrelle NHI.

Leurs chiffres augmentent rapidement. Chaque ressource cloud, pipeline CI/CD, flux de travail d'automatisation et intégration IA crée de nouvelles NHI qui nécessitent des identifiants et des autorisations. Dans la plupart des organisations, les identités machines dépassent le nombre d'utilisateurs humains par un facteur de 10:1 ou plus.

Lorsque votre logiciel de sauvegarde se connecte à une base de données à 2 heures du matin, il ne tape pas de mot de passe. Il s'authentifie en utilisant un compte de service avec des identifiants stockés. C'est un NHI. Il en va de même pour la clé API que votre système de billetterie utilise pour extraire les données CRM, ou le token OAuth qui synchronise les dossiers des employés avec Entra ID.

Comme l'a noté Jeff Warren, Chief Product Officer chez Netwrix, dans le Rapport sur les tendances de la cybersécurité 2025, les attaques axées sur l'identité devraient dominer encore plus, avec "l'abus d'identités machine-à-machine comme les comptes de service et les jetons" parmi les vecteurs émergents.

Identités humaines vs. identités non humaines

Les identités humaines et non humaines diffèrent par la manière dont elles sont possédées, authentifiées, gérées et surveillées :

• Propriété: Les identités humaines ont des propriétaires clairs. Les NHI ont souvent une propriété partagée ou peu claire, rendant difficile l'application de la responsabilité.
• Authentification: Les humains utilisent des mots de passe combinés avec MFA. Les NHI utilisent des clés, des jetons et des certificats, et MFA ne s'applique pas.
• Cycle de vie : Les identités humaines suivent des processus pilotés par les ressources humaines (intégration, changements de rôle, départ). Les NHI sont créées ad hoc par des développeurs et des administrateurs, sans gestion de cycle de vie équivalente.
• Comportement : L'accès humain est interactif et variable. L'accès NHI est programmatique et répétitif, ce qui rend la détection des anomalies à la fois plus facile à établir comme référence et plus difficile à examiner à grande échelle.

Les politiques de mot de passe, MFA, SSO et les revues d'accès ne se traduisent pas bien en NHI. C'est pourquoi les identités machines nécessitent leur propre approche de gouvernance.

Le terme connexe « identité de machine » fait référence spécifiquement aux identités au niveau de l'infrastructure comme les serveurs, les VM et les certificats. NHI est plus large, couvrant ceux-ci plus les identifiants au niveau de l'application comme les clés API, les jetons et les bots.

Méthodes d'authentification d'identité non humaine

Les NHIs s'authentifient de manière programmatique plutôt que par connexion interactive, en utilisant quatre méthodes principales :

• Basé sur un token : clés API, tokens porteurs et tokens JWT
• Basé sur une clé : clés SSH et clés de compte de service
• Basé sur des certificats : Certificats X.509 et TLS mutuel (mTLS)
• Fédération d'identité de charge de travail : Mécanismes natifs du cloud tels que les rôles AWS IAM, les identités gérées Azure et les comptes de service GCP

Le risque critique dans les quatre est que MFA et SSO ne s'appliquent pas. Lorsqu'une identité est compromise, il n'y a pas de second facteur pour empêcher l'exploitation, et l'attaquant hérite de tout accès que cette identité détient.

Types courants d'identités non humaines

Comprendre les différents types de NHI dans votre environnement est la première étape pour les gérer efficacement. Les catégories suivantes représentent les identités non humaines les plus courantes que vous rencontrerez dans des environnements sur site et cloud.

1. Comptes de service et identités d'application

Les comptes de service sont des comptes spécialisés qui permettent aux applications d'effectuer des tâches sans identifiants humains. Votre logiciel de sauvegarde en utilise un pour accéder aux bases de données SQL Server, et vos outils de surveillance les utilisent pour collecter des données de performance. Dans les environnements AD, ceux-ci sont identifiés par l'attribut ServicePrincipalName (SPN).

Le principal défi de sécurité est que les mots de passe changent rarement. La meilleure pratique moderne consiste à migrer vers Comptes de Service Gérés par Groupe (gMSAs), qui fournissent une gestion automatique des mots de passe via Active Directory et éliminent l'intervention manuelle de l'administrateur.

Les identités des applications étendent ce concept aux environnements cloud natifs, où les plateformes cloud attribuent des identités dédiées aux applications pour accéder aux API, bases de données et autres ressources cloud.

2. Clés API et secrets

Les clés API et les secrets remplissent la même fonction de base : ils permettent à un système de s'authentifier auprès d'un autre sans intervention humaine. Ils sont intégrés dans des outils internes, des intégrations SaaS et des connexions à des services tiers pour accorder un accès programmatique sans nécessiter qu'une personne se connecte.

That third-party category is broader than most teams realize. When a printer communicates with its manufacturer for supply monitoring, or when manufacturing equipment sends telemetry to an OEM for remote maintenance, those connections rely on API keys or embedded credentials that authenticate across organizational boundaries. These vendor-managed NHIs often fall outside standard identity governance because they're provisioned by the vendor, not by your IT team.

Le défi dans tout cela est leur nature statique. Contrairement aux mots de passe liés aux comptes utilisateurs, les clés API n'expirent pas par défaut dans la plupart des systèmes et ont tendance à se retrouver dans des fichiers de configuration, des dépôts de code, des variables d'environnement et même des journaux de discussion.

Il en va de même pour les secrets stockés dans des coffres ou des fichiers de configuration, y compris les mots de passe, les chaînes de connexion et les clés de chiffrement. Ces identifiants présentent le même risque d'accès que n'importe quelle clé API, mais reçoivent souvent moins d'attention.

Une fois divulguées, n'importe lesquelles de ces informations d'identification sont immédiatement exploitables, et les organisations ne savent souvent pas qu'une a été exposée jusqu'à ce qu'elle ait déjà été utilisée. Lorsque l'information d'identification compromise appartient à une intégration tierce, le rayon d'explosion s'étend au-delà de votre environnement dans les relations avec les fournisseurs régies par des cadres comme NIS2 et DORA, qui imposent tous deux des contrôles de risque de chaîne d'approvisionnement pour les dépendances de services numériques.

3. Identités gérées

Les identités gérées représentent l'approche moderne de Microsoft pour l'authentification NHI dans Azure. Les identités gérées assignées par le système sont directement liées à des ressources Azure spécifiques et éliminent la nécessité de stocker complètement les identifiants. Les identités gérées assignées par l'utilisateur peuvent être partagées entre plusieurs ressources.

Cependant, les identités gérées ne résolvent le problème que dans l'écosystème Azure. Les organisations fonctionnant dans des environnements hybrides ont toujours besoin de visibilité sur les comptes de service sur site et les identifiants multiplateformes que les identités gérées ne couvrent pas.

4. Jetons OAuth

Tokens OAuth permettent un accès délégué entre les applications. Lorsque votre plateforme RH synchronise les données des employés avec votre fournisseur d'identité, ou lorsque votre outil de reporting extrait des enregistrements d'un CRM SaaS, ces connexions s'appuient sur des tokens de rafraîchissement OAuth pour maintenir un accès persistant.

Ces jetons ont souvent une durée de vie plus longue que prévu et s'accumulent dans vos intégrations SaaS à mesure que les équipes connectent davantage d'outils.

5. Identités de charge de travail et de conteneurs dans le cloud

Les identités de charge de travail englobent les identifiants attribués aux applications conteneurisées, aux fonctions sans serveur et aux charges de travail cloud. Vos déploiements Kubernetes, Azure Container Instances et fonctions AWS Lambda nécessitent tous des identifiants pour accéder à d'autres services.

Les plateformes cloud attribuent des identités à ces charges de travail, y compris les VM, les conteneurs, les fonctions sans serveur et les pods Kubernetes, pour accéder aux ressources cloud, au stockage et aux API. Ces identités de charge de travail sont créées et détruites rapidement, dépassant souvent la capacité des équipes de sécurité à les suivre.

6. Identités des machines et des dispositifs

Les machines physiques et virtuelles, les appareils IoT et les composants d'infrastructure portent tous leurs propres identités. Les certificats authentifient fréquemment ces identités de machine, créant une couche de gouvernance NHI qui se chevauche mais s'étend au-delà des identifiants au niveau des applications. À mesure que l'adoption de l'IoT augmente, cette population d'identités augmente également.

7. Bots et agents IA

Les bots et agents IA représentent la catégorie la plus récente et à la croissance la plus rapide d'identités non humaines. Par exemple :

• Microsoft Copilot a besoin d'accéder à vos fichiers et à votre e-mail pour être utile
• Les bots d'automatisation des processus robotiques (RPA) ont besoin de références pour interagir avec les applications professionnelles
• Les bots CI/CD ont besoin d'accès pour déployer du code
• Les outils d'orchestration et les agents IA fonctionnent comme des identités non humaines, souvent avec un large accès pour permettre des flux de travail d'automatisation

Chacun d'eux crée des relations d'identité qui nécessitent la même gouvernance que tout autre NHI, mais ils sont souvent provisionnés rapidement par des équipes commerciales sans examen de sécurité.

Le risque supplémentaire est que les outils d'IA interagissent avec des dépôts de code et des environnements de développement. Cela peut involontairement exposer des identifiants dans les invites, les sorties et les journaux, créant des vecteurs de fuite que le scan traditionnel des secrets ne détecte pas toujours.

Chacun de ces types d'identité nécessite des approches de gestion différentes, mais tous partagent des défis de gouvernance communs : suivi de la propriété, rotation des identifiants et désactivation lorsqu'ils ne sont plus nécessaires.

Comment découvrir des identités non humaines dans votre environnement

Avant de pouvoir gouverner les NHI, vous devez les trouver. Un processus de découverte structuré vous aide à comprendre l'ampleur du problème, mais la plupart des organisations réalisent rapidement que les approches manuelles ne font qu'effleurer la surface.

Commencez avec votre fournisseur d'identité

Interrogez Active Directory pour les comptes avec des Noms de Principaux de Service, des comptes de service gérés de manière autonome et des comptes de service gérés par groupe.

Pour les environnements cloud, tirez un inventaire des principaux services, des enregistrements d'applications et des identités gérées à partir de la console d'administration de votre fournisseur d'identité. Concentrez-vous sur quatre attributs pour chaque identité : quelle application l'utilise, quelles informations d'identification elle détient, quels ressources elle peut accéder et qui la possède.

Développez votre couche de code et d'automatisation

Travaille avec ton équipe DevOps pour identifier les identifiants stockés dans les configurations de pipeline CI/CD, les modèles d'infrastructure en tant que code et les variables d'environnement. Les outils de scan de dépôt peuvent signaler les identifiants codés en dur et les clés API engagées dans le contrôle de version. C'est souvent là que se trouvent les NHI les plus non suivis.

Auditez vos intégrations SaaS

Examinez les autorisations OAuth et les connexions API dans vos applications SaaS. De nombreuses organisations découvrent des dizaines de jetons OAuth actifs provenant d'intégrations qui ont été mises en place il y a des mois ou des années par des personnes qui ont depuis quitté l'équipe ou l'entreprise.

Documentez ce que vous trouvez

Pour chaque NHI que vous découvrez, enregistrez le propriétaire (une personne, pas une équipe), la justification commerciale, le type de crédentiel et l'état de rotation, et la dernière fois que quelqu'un a validé qu'il est toujours nécessaire. Cet inventaire devient la base de tout ce qui suit.

Une mise en garde importante : la découverte manuelle vous donne un instantané à un moment donné, pas un inventaire vivant. Les environnements changent quotidiennement, et une exportation trimestrielle ne capturera pas le compte de service que quelqu'un a créé mardi dernier.

La découverte continue et automatisée est ce qui sépare les organisations qui connaissent leur population NHI de celles qui pensent simplement le faire.

Comment sécuriser et gouverner les identités non humaines

La gestion des identités non humaines (NHIM) est la pratique de découvrir, gouverner et sécuriser les identités des machines que la gestion des identités traditionnelle (IAM) et le Privileged Access Management (PAM) n'étaient pas conçus pour gérer.

Cela signifie gouverner l'accès sans acteur humain, gérer des identifiants qui ne peuvent pas utiliser MFA et suivre la propriété des identités créées par des développeurs et de l'automatisation plutôt que par des processus RH.

Une fois que vous avez identifié ce qui existe dans votre environnement, la gouvernance garantit qu'il reste sous contrôle. Une sécurité NHI efficace considère les identités des machines comme des citoyens de première classe dans votre programme de sécurité des identités, avec des politiques définies pour chaque étape de leur cycle de vie.

Voici à quoi cela ressemble en pratique :

• Attribuez un propriétaire à chaque NHI lors de sa création : Aucune identité ne devrait exister sans un individu nommé (pas une liste de distribution, pas un alias d'équipe) responsable de son accès et de son cycle de vie. Faites de la propriété un champ obligatoire dans votre processus de provisionnement.
• Appliquez le principe du moindre privilège dès le premier jour : Accordez uniquement les autorisations spécifiques dont chaque NHI a besoin pour sa fonction, limitées au niveau de ressource le plus étroit possible. Évitez les autorisations à l'échelle de l'abonnement ou du domaine pour les comptes de service qui n'ont besoin d'accéder qu'à une seule application.
• Automatisez la rotation des identifiants lorsque cela est possible : les gMSA gèrent cela automatiquement pour les charges de travail AD sur site. Pour les principaux de service cloud et les clés API, intégrez la rotation dans vos pipelines de déploiement ou utilisez une solution de gestion des secrets.

La bonne cadence dépend du type de crédentiel et du risque d'exposition, car des cadres majeurs comme NIST, CIS, et PCI DSS ne mandatent pas de période de rotation universelle pour les comptes privilégiés.

• Surveillez les anomalies comportementales : Un compte de service qui accède soudainement à des ressources en dehors de son modèle normal, ou une clé API qui s'authentifie depuis un emplacement inconnu, devrait déclencher une alerte. Concentrez-vous sur la surveillance des écarts par rapport aux lignes de base établies plutôt que d'essayer de revoir chaque événement.
• Désactiver agressivement : Les NHI obsolètes sont l'une des faiblesses les plus exploitables dans n'importe quel environnement. Intégrez des déclencheurs de désactivation dans votre processus : si une identité ne s'est pas authentifiée depuis 90 jours, signalez-la pour révision. Si le propriétaire ne peut pas le justifier, désactivez-la. Si personne ne le remarque pendant 30 jours de plus, supprimez-la.
• Certifier l'accès selon un calendrier récurrent : Exiger que les propriétaires de NHI revalident que chaque identité a toujours besoin de ses autorisations actuelles. Les examens annuels sont un point de départ, mais trimestriels sont meilleurs pour les identités privilégiées.

Ces contrôles correspondent directement aux exigences déjà intégrées dans les principaux cadres de conformité :

• Le niveau 2 du CMMC nécessite un contrôle d'accès et une gestion des comptes pour toutes les identités, y compris celles non humaines
• Les critères de service de confiance SOC 2 nécessitent des contrôles d'accès qui s'étendent aux identités non humaines
• La HIPAA impose des pistes de vérification pour tous les accès aux Informations de Santé Protégées, y compris les accès par des processus automatisés et des comptes de service
• La NIS2 (UE) exige aux organisations de gérer les risques de la chaîne d'approvisionnement ICT, y compris les identifiants de services tiers et les identités gérées par des fournisseurs qui accèdent à votre environnement
• DORA (secteur financier de l'UE) impose la gestion des risques liés aux tiers ICT avec des exigences spécifiques pour surveiller et gouverner les dépendances des services numériques, y compris les identités des machines utilisées par ces services

Si vous construisez la gouvernance NHI, vous construisez simultanément des preuves de conformité.

Comment Netwrix soutient la sécurité des identités non humaines

Chaque pratique de gouvernance ci-dessus dépend d'une chose : savoir quelles identités non humaines existent dans votre environnement et ce qu'elles font. C'est le fossé que la plupart des organisations ont du mal à combler par elles-mêmes, et c'est là que Netwrix entre en jeu.

La plateforme Netwrix 1Secure fournit une visibilité continue sur la posture d'identité dans Active Directory et les environnements cloud. Pour les identités non humaines spécifiquement, elle met en évidence les comptes inactifs, les comptes obsolètes et les configurations d'accès excessivement permissives qui violent la politique organisationnelle, offrant aux équipes de sécurité une image de l'état actuel plutôt qu'un instantané trimestriel.

Là où les requêtes manuelles vous donnent une exportation à un moment donné, 1Secure maintient une vue continue à mesure que de nouvelles identités sont créées et que les existantes changent.

Pour Active Directory spécifiquement, Netwrix Auditor suit les modifications des comptes de service, surveille les événements d'authentification et audite les modifications de la stratégie de groupe, comblant les lacunes de visibilité laissées ouvertes par les outils natifs.

Lorsque quelqu'un crée un nouveau compte de service, change son appartenance à un groupe ou tente une connexion interactive, Auditor le signale. Les équipes peuvent commencer à répondre aux questions d'audit concernant l'activité de NHI avec des rapports lisibles par l'homme qui se mappent directement aux cadres de conformité tels que HIPAA, SOC 2 et CMMC.

Pour les identités non humaines privilégiées qui nécessitent un accès élevé, Netwrix Privilege Secure élimine les privilèges permanents grâce à une provisionnement juste à temps avec enregistrement complet des sessions pour les pistes d'audit. Au lieu que les comptes de service détiennent un accès administratif persistant 24 heures sur 24, Privilege Secure accorde des autorisations élevées uniquement lorsque cela est nécessaire et les révoque automatiquement lorsque la tâche est terminée.

Prêt à combler le fossé de visibilité sur les identités non humaines ?Réservez une démo pour voir comment Netwrix fonctionne dans votre environnement.