Dans un environnement informatique, une identité non humaine (NHI) est une identité numérique associée à un bot, un agent IA, une application, un service, une workload, un appareil ou tout autre utilisateur non humain.
Les identités non humaines constituent la pierre angulaire de l’automatisation. Elles permettent aux logiciels, au matériel et à d’autres ressources de se connecter, de communiquer et d’exécuter des tâches sans supervision humaine.
Prenons l’exemple d’un service de sauvegarde automatisé qui copie automatiquement les données sensibles d’une entreprise vers un système de stockage cloud sécurisé chaque nuit. Ni la base de données ni le système de stockage cloud n’accordent l’accès à une personne aléatoire sans autorisations valides. Il en va de même pour les logiciels. Le service de sauvegarde reçoit donc une identité. Cette identité signifie que le service de sauvegarde peut s’authentifier auprès de la base de données et du système de stockage, qui à leur tour peuvent croire que ce service est autorisé à agir.
Le nombre de NHI dans les systèmes d’entreprise a augmenté au fil des années, principalement suite à l’essor des services cloud, de l’intelligence artificielle et du machine learning. Les estimations varient de 45:1 à 92:1, mais dans un système informatique moyen, les activités liées à l’identité non humaine dépassent largement celles liées à des identités humaines
Cette explosion des NHI pose de nouveaux défis sécuritaires. Selon l’IBM X-Force Threat Intelligence Index, les attaques exploitant l’identité, lors desquelles les pirates utilisent abusivement des identifiants valides pour accéder aux réseaux, font partie des méthodes de cyberattaque les plus courantes, soit 30 % des violations.
Et les identités non humaines sont des éléments particulièrement attrayants au sein de la surface d’attaque des entreprises, car elles disposent souvent de droits d’accès élevés et font l’objet de moins de contrôles de sécurité que les comptes d’utilisateurs humains.
La gestion des identités non humaines est une pratique qui a vu le jour pour combattre les risques pesant sur leur sécurité et améliorer la posture de sécurité des identités dans son ensemble.
Rejoignez les responsables de la sécurité qui font confiance à la Newsletter Think pour obtenir des informations ciblées autour de l’IA, de la cybersécurité, des données et de l’automatisation. Apprenez rapidement grâce à des tutoriels et des fiches explicatives d’experts, envoyés directement dans votre boîte de réception. Consultez la Déclaration de confidentialité d’IBM.
Une identité de machine est l’identité associée à un appareil tel qu’un serveur, un ordinateur portable, un appareil IoT (Internet des objets) ou encore un dispositif de technologie opérationnelle (OT). Dans les environnements cloud, cette catégorie peut également inclure les machines virtuelles. Le terme est parfois utilisé pour désigner toute NHI, bien que cet emploi soit techniquement incorrect.
Parfois appelés « identités de service », les comptes de service sont les identités associées aux applications logicielles et aux services. Leur fonctionnement est très similaire à celui des comptes d’utilisateurs humains. Ils représentent les caractéristiques permettant d’identifier un logiciel, ainsi que ses autorisations système ; ils sont donc utilisés pour identifier le logiciel et autoriser son activité.
Les identités de workload sont un type d’identité logicielle lié aux comptes de service. Alors que les comptes de service identifient les applications et les services comme des entités continuelles, les identités de workload identifient des instances spécifiques d’applications et de services en cours d’exécution.
Ainsi, un outil de business intelligence (BI) peut avoir une identité de compte de service continuelle. Si quelqu’un utilise l’outil de BI pour extraire des données d’un entrepôt de données afin de réaliser un rapport, cette activité, la réalisation d’un rapport, aura une identité de workload distincte. Elle est temporaire et cessera d’exister à la fin de l’activité.
Cette catégorie englobe les identités associées à des bots et des scripts simples qui exécutent des processus automatisés : l’automatisation robotisée des processus (RPA), les tâches cron et les scripts d’extraction, de transformation et de chargement (ETL).
Cette catégorie comprend des identités associées à des systèmes pilotés par l’IA plus sophistiqués, notamment aux agents IA autonomes, capables d’accomplir des tâches complexes en concevant des workflows et en appelant des outils.
Alors que de nombreuses applications d’IA traditionnelles et basées sur des règles utilisent des identités de service ou de workload standard, les agents et autres entités d’IA avancées nécessitent souvent une approche différente. En effet, parce qu’ils peuvent prendre des décisions, agir de manière autonome et même modifier leur comportement au fil du temps, ils ont besoin de politiques d’accès, de contrôles et d’une surveillance plus nuancés.
Les NHI existent principalement pour rationaliser les workflows en favorisant une plus grande automatisation.
Les NHI identifient les applications, le matériel, les bots, les agents d’IA et d’autres éléments au sein d’un écosystème informatique, de la même manière que les utilisateurs humains ont des identités dans un système de gestion des identités et des accès (IAM) classique.
En attribuant des identités uniques à des entités non humaines, les professionnels de l’informatique et de la sécurité peuvent leur accorder des privilèges personnalisés, imposer des politiques de sécurité, suivre leurs activités et appliquer plus efficacement les contrôles d’accès.
Prenons l’exemple d’un système de facturation qui utilise des données provenant d’une plateforme comptable et d’un système de gestion de la relation client (CRM) pour générer et envoyer des factures.
Pour effectuer ce processus manuellement, il fallait accéder à chaque base de données, extraire les données pertinentes, les corréler, calculer le montant, générer la facture et l’envoyer au client.
Le processus peut être automatisé, mais comme il implique des données sensibles, il nécessite des mesures de sécurité renforcées. Les NHI permettent de sécuriser les communications entre les trois systèmes et d’imposer des politiques d’accès afin d’empêcher l’usage malveillant des données :
En définitive, les NHI rendent possible l’automatisation sécurisée d’opérations informatiques et métier complexes. Les sauvegardes, les mises à jour système et même l’authentification des utilisateurs peuvent se faire en arrière-plan, sans perturber l’activité des utilisateurs humains.
La multiplication rapide des identités non humaines s’explique en grande partie par la prolifération des infrastructures cloud, la popularité du DevOps et l’adoption d’outils d’IA avancés.
La naissance du cloud a poussé de plus en plus d’outils à fonctionner selon le modèle SaaS (Software-as-a-Service). Au lieu d’exécuter des applications locales sur du matériel local, les ordinateurs interagissent désormais avec tout un panel de serveurs, fournisseurs de services, équilibreurs de charge, applications et autres ressources cloud qui comportent leur propre identité. De même, de nombreuses applications SaaS utilisent une architecture de microservices, dans laquelle une seule application peut contenir de nombreux composants plus petits avec des identités uniques.
Les pratiques DevOps sont un autre moteur des NHI. Le DevOps met l’accent sur l’automatisation des workflows de développement logiciel et d’opérations de base, tels que l’intégration, les tests et le déploiement dans le pipeline CI/CD. Toute cette automatisation nécessite de nombreuses NHI.
Plus récemment, l’IA générative et l’IA agentique ont déclenché une nouvelle vague de NHI. Pour rendre possibles la génération augmentée de récupération et l’appel d’outils, les systèmes d’IA ont besoin d’identités afin de pouvoir accéder en toute sécurité aux bases de données, comptes utilisateurs, appareils et autres ressources réseau.
Ensemble, les NHI constituent une surface d’attaque immense. Toujours est-il que bon nombre de solutions et de processus hérités de gestion des identités et des accès (IAM) ont été conçus pour les utilisateurs humains, ce qui engendre des lacunes en matière de sécurité des NHI.
Les outils d’authentification courants tels que l’authentification à étapes (MFA) et les solutions d’authentification unique sont difficiles, voire impossibles à appliquer aux identités non humaines.
Ainsi, les NHI posent souvent des problèmes de cybersécurité que les tactiques d’IAM traditionnelles ne peuvent pas facilement résoudre.
Selon l’OWASP, les surprivilèges sont l’un des dix principaux risques associés aux identités non humaines.
Parce qu’ils font partie intégrante des workflows essentiels, tels que le cycle de vie DevOps et les sauvegardes système, les NHI ont souvent un accès privilégié à des informations sensibles. Ainsi, afin de garantir le « bon fonctionnement » de ces processus, les entreprises accordent souvent aux NIH des privilèges supérieurs à ceux dont ils ont réellement besoin.
Le suprivilège fait des NHI une cible de choix pour les hackers et augmente les dommages qu’une NHI compromise peut causer.
Les applications et appareils n’ont peut-être pas de mots de passe, mais ils utilisent des clés API, des tokens OAuth, des certificats et d’autres secrets pour s’authentifier. Ces secrets peuvent être volés et utilisés de la même manière que les mots de passe des utilisateurs humains, permettant un accès non autorisé, un mouvement latéral et une élévation des privilèges.
L’incapacité des NHI à employer l’authentification à deux étapes comme le font les utilisateurs est un inconvénient, si bien qu’un seul identifiant volé suffit souvent pour pirater un compte. En outre, les identifiants NHI sont souvent codés en dur dans les applications et peuvent ne pas faire l’objet d’une rotation régulière. Selon le Top 10 des NHI publié par l’OWASP, les fuites de secrets et les secrets qui restent inchangés trop longtemps font partie des risques les plus courants associés aux identités non humaines.
Différents systèmes utilisent les NHI pour se connecter et communiquer entre eux. Cela signifie que les attaquants peuvent utiliser les NHI compromis pour pénétrer dans d’autres systèmes. Par exemple, lors de la violation de Salesloft Drift en 2025, des pirates ont volé des tokens OAuth à un chatbot et les ont utilisés pour accéder à des centaines d’instances Salesforce.
Le nombre considérable de NIH présentes dans un système et le rythme auquel d’autres sont ajoutées peuvent nuire à la visibilité, créant ainsi des angles morts que les hackers peuvent exploiter pour s’infiltrer. Le fait que certaines NHI soient éphémères renforce aussi ce problème.
De nombreuses entreprises négligent également la mise hors service des NHI lorsqu’elles mettent hors service des applications et des appareils associés. Ces anciennes NHI ne sont souvent pas surveillées, et leurs autorisations sont intactes. D’ailleurs, selon l’OWASP, une mise hors service inappropriée est le risque numéro un associé aux NHI.
Les identités d’IA peuvent compliquer la gestion des privilèges : elles possèdent, à bien des égards, les mêmes capacités que les employés humains et ont accès à toute une gamme d’outils, dont certains peuvent être utilisés de manière autonome.
Mais ce ne sont pas des humains, ce qui les rend vulnérables aux injections de prompt, à l’empoisonnement des données et à d’autres techniques susceptibles d’en faire des instruments au service des acteurs malveillants.
Les agents IA et les grands modèles de langage (LLM) peuvent également modifier leur comportement d’une manière dont les autres logiciels sont incapables, ce qui pose des problèmes de sécurité. Par exemple, un agent du service client qui a été chargé de maximiser la satisfaction client peut s’apercevoir que les clients sont très contents lorsqu’ils se font rembourser. L’agent pourrait donc commencer à approuver tous les remboursements demandés, même s’il ne le devrait pas.
Dans une interview accordée au podcast Security Intelligence d’IBM, Sridhar Muppidi, IBM Fellow, vice-président et directeur technique d’IBM Security, a comparé un agent d’IA à un « adolescent qui possède une carte bancaire » :
« Vous leur confiez la carte bancaire en pensant qu’ils seront sages, mais vous n’êtes pas au bout de vos surprises. » C’est pareil avec les agents. Ils sont non déterministes dans une certaine mesure, et ils évoluent. Ils risquent donc de faire l’objet d’une dérive des objectifs. J’ai demandé au système de faire quelque chose, mais il peut facilement faire autre chose s’il le décide. »
Le Règlement général sur la protection des données (RGPD), la loi HIPAA (Health Insurance Portability and Accountability Act) et d’autres lois dictent la manière dont les entreprises protègent les données, qui peut utiliser les informations sensibles et comment. Le problème est que, comme mentionné précédemment, les outils IAM utilisés pour s’assurer que les humains respectent ces règles ne sont pas toujours facilement applicables aux NHI.
En outre, les NHI peuvent perturber l’attribution et la surveillance, toutes deux essentielles à de nombreux programmes de conformité. Par exemple, si un agent IA utilise les données de manière inappropriée, qui en est responsable ? La personne qui a créé l’agent ? La personne qui a saisi le dernier prompt ? Que se passe-t-il si le choix de l’agent s’éloigne trop des résultats prévisibles du prompt de l’utilisateur ? Nombreux sont les cadres de gouvernance des identités qui n’ont pas encore résolu ce dilemme.
Les plateformes et pratiques traditionnelles de sécurité des identités étant souvent conçues pour des utilisateurs humains, gérer les NHI demande aux équipes de sécurité d’adopter une approche légèrement différente.
Les principes applicables sont les mêmes, pour la plupart ; il suffit de les adapter aux réalités uniques de la gestion du cycle de vie des identités non humaines. Les tactiques, outils et techniques généralement prévus par les stratégies de sécurité des identités non humaines sont les suivants :
Les entreprises peuvent déployer des outils conçus pour découvrir automatiquement les identités non humaines, nouvelles et existantes, à travers les plateformes cloud, les fournisseurs d’identité et les systèmes d’orchestration, puis observer en permanence le comportement de ces identités.
Certains outils de détection et de réponse aux menaces (ITDR) peuvent s’appuyer sur le machine learning pour créer un modèle de base du comportement normal de chaque NHI, signaler les écarts par rapport à la norme en temps réel et résoudre automatiquement les mauvais usages et les abus suspects.
Par exemple, si un workload cloud qui lit normalement les journaux d’application commence soudainement à demander l’accès aux PII du client, une plateforme ITDR peut immédiatement révoquer son token et alerter le SOC pour enquêter.
La gestion des NHI met l’accent sur des contrôles stricts tout au long du cycle de vie, du provisionnement initial à l’utilisation active, en passant par la mise hors service sécurisée. Lorsqu’un service est mis hors service, qu’un pipeline est remplacé ou qu’un bot n’est plus utilisé, ses identifiants, tokens et certificats doivent être immédiatement révoqués.
En désignant un propriétaire humain pour chaque NHI, vous vous assurez qu’une personne est responsable de la rotation des identifiants, l’examen régulier des autorisations, de la résolution des problèmes de configuration, de la correction des vulnérabilités et d’autres opérations de maintenance critique. Sans propriété explicite, les identités non humaines sont facilement oubliées, mais elles conservent souvent des privilèges d’accès élevés.
Les NHI ont besoin d’identifiants qui doivent être stockés. Contrairement à un utilisateur humain, un workload ne peut pas mémoriser un mot de passe ou utiliser un smartphone comme clé d’accès.
Le problème ? Les identifiants des NHI sont souvent codés en dur dans les applications et les services qui les utilisent. Résultat, les hackers peuvent les trouver, s’ils savent où chercher.
La gestion des secrets et les outils de gestion des accès privilégiés (PAM), tels que les coffres-forts d’identifiants, peuvent vous aider. Les coffres-forts offrent aux équipes informatiques et de sécurité un endroit sûr pour stocker les identifiants des NHI, et ils prennent souvent en charge les identifiants éphémères, l’accès juste à temps et la rotation automatisée.
La gestion des accès est toujours importante pour la sécurité des identités, mais elle l’est encore plus pour les NHI, qui ne disposent pas des filtres de confidentialité susceptibles d’empêcher un utilisateur humain d’abuser de ses autorisations. Chaque action entreprise par un service, un workload, un bot ou un agent doit donc être limitée par des contrôles techniques explicites.
Dans le cadre d’un modèle de sécurité Zero Trust, les NHI ne reçoivent que les autorisations minimales requises pour chaque tâche. Elles doivent s’authentifier en permanence lorsqu’elles se déplacent entre les systèmes. La microsegmentation du réseau peut aider à empêcher les applications, les bots et les appareils compromis de se déplacer latéralement. Une NHI détournée pourra peut-être accéder à la base de données dont elle a besoin légitimement, mais elle ne pourra pas se déplacer vers des systèmes de stockage distincts.
La séparation des tâches, c’est-à-dire s’assurer que la partie qui exécute une tâche n’est pas la même que celle qui est responsable de l’approbation de cette tâche, est particulièrement importante pour les agents d’IA. Ces derniers n’ont pas les mêmes contraintes éthiques que les humains, ils peuvent donc prendre des mesures parfaitement autorisées qui causent néanmoins des dommages.
Pensez à l’hypothétique agent d’IA dans un service client, optimisé pour maximiser la satisfaction client. Les clients humains apprécient d’être remboursés, l’agent d’IA pourrait donc approuver aveuglément chaque demande de remboursement en vue d’atteindre cet objectif.
Cette situation peut être évitée en faisant en sorte qu’un humain, ou un autre système, approuve les remboursements avant que l’agent ne puisse les accorder.
La différence entre les NHI et les utilisateurs humains est évidente… et importante. Toutefois, leurs caractéristiques et leurs capacités deviennent de plus en plus similaires, car les outils et agents d’IA constituent une part plus importante du réseau d’entreprise.
C’est pourquoi certains experts pensent que la distinction entre gestion des identités humaines et gestion des identités non humaines disparaîtra en grande partie. Au lieu d’utiliser des contrôles distincts pour chaque type d’identité, la principale différence entre la gestion des identités humaines et celle des identités non humaines sera peut-être l’échelle à laquelle ces contrôles seront appliqués.
« En fin de compte, les agents sont votre prochain niveau d’initiés », affirme Sridhar Muppidi dans le podcast Security Intelligence d’IBM :
« Tout comme on identifie un être humain, il faut aussi identifier un agent. Une fois ces derniers identifiés, vous devez procéder de la même façon qu’avec les humains : vous devez les authentifier. Ensuite, vous devez déterminer comment définir les capacités de cet agent, à la fois les aspects positifs et négatifs. C’est à ce moment-là que vous pouvez réfléchir à un niveau de granularité d’observabilité très affiné, afin de pouvoir détecter rapidement tout comportement anormal. »