Une population d’identités souvent invisible
Lorsqu’on parle de gestion des identités et des accès (IAM), on pense d’abord aux utilisateurs : collaborateurs, administrateurs, clients. Pourtant, dans un système d’information bancaire ou assurantiel, une autre population d’identités opère en permanence, souvent plus nombreuse et moins maîtrisée : les identités machine, ou identités non humaines (non-human identities, NHI).
Comptes de service, clés d’API, jetons d’accès, certificats, secrets applicatifs, robots logiciels (RPA), pipelines d’intégration et de déploiement continu (CI/CD) : ces identités permettent aux applications, aux services et aux automatismes de s’authentifier et de communiquer entre eux. Elles sont au cœur des architectures modernes — cloud, microservices, API, automatisation — et dépassent fréquemment, en volume, les identités humaines.
Or l’essentiel des efforts IAM porte encore sur l’humain : cycle de vie RH, authentification forte, revues d’accès. Les identités machine, elles, sont souvent créées au fil de l’eau, mal inventoriées, sur-permissionnées et rarement soumises à une rotation rigoureuse. Elles constituent de ce fait un vecteur d’attaque et de latéralisation majeur, et un angle mort de nombreuses politiques de sécurité. Cet article propose un panorama opérationnel de ces risques et des bonnes pratiques pour les traiter.
Qu’est-ce qu’une identité machine ?
Une identité non humaine est une identité numérique utilisée par une entité logicielle — application, service, API, robot, système automatisé, et désormais agent d’IA — pour accéder à des ressources protégées. À l’image d’un utilisateur qui s’authentifie avec un mot de passe, une identité machine s’authentifie généralement à l’aide d’un secret : clé d’API, jeton, certificat, identifiant applicatif.
Un point est essentiel à comprendre : les identités machine et humaines sont interdépendantes. Une identité machine compromise peut donner accès à des systèmes également utilisés par des humains, et la compromission d’un compte humain peut exposer des secrets d’identités machine. La sécurité des unes ne peut donc pas être pensée indépendamment des autres.
Pourquoi les identités machine sont-elles un angle mort ?
Plusieurs facteurs expliquent que ces identités échappent souvent au niveau de contrôle appliqué aux utilisateurs.
D’abord, leur prolifération. Chaque application, intégration, script ou pipeline peut générer une ou plusieurs identités et plusieurs secrets. Leur nombre croît avec l’adoption du cloud, des API et de l’automatisation, souvent plus vite que la capacité à les recenser.
Ensuite, l’absence de propriétaire naturel. Une identité humaine suit un cycle de vie piloté par les RH (arrivée, mobilité, départ). Une identité machine est souvent créée par une équipe de développement ou d’exploitation pour un besoin technique, sans processus de fin de vie clair, ni responsable identifié dans la durée.
Enfin, des caractéristiques propres : les identités machine ne bénéficient généralement pas d’authentification forte, leurs secrets sont parfois codés en dur dans du code ou des fichiers de configuration, et elles sont difficiles à instrumenter et à surveiller. Le résultat est une asymétrie : des dispositifs matures pour l’humain, et un traitement souvent artisanal pour la machine.
Des incidents qui illustrent le risque
Plusieurs incidents publics récents montrent comment une identité machine mal gérée peut devenir le point de départ d’une compromission. Ils sont d’ailleurs documentés dans les travaux de l’OWASP sur le sujet.
En janvier 2024, lors de l’attaque attribuée au groupe « Midnight Blizzard » contre Microsoft, les attaquants ont exploité une ancienne application OAuth — une identité non humaine non gérée — disposant de privilèges étendus, pour passer d’un environnement de test à l’environnement de production et exfiltrer des messages et documents.
En novembre 2023, une compromission a touché le système de support d’Okta via un compte de service, dont les identifiants avaient été enregistrés par un employé sur un compte personnel. En octobre 2024, la plateforme de support de l’Internet Archive a été compromise via des jetons d’accès non renouvelés (unrotated tokens), soulignant l’importance de la rotation des secrets.
Ces exemples partagent un même schéma : une identité machine oubliée, sur-permissionnée ou dotée d’un secret jamais renouvelé devient un point d’entrée ou de persistance.
Les risques principaux
Pour structurer ces risques, un référentiel fait aujourd’hui référence : l’OWASP Non-Human Identities Top 10 (2025), qui identifie et classe les principaux risques associés aux identités non humaines, à partir de brèches réelles, de vulnérabilités publiques et d’enquêtes sectorielles. On peut en retenir plusieurs familles, directement pertinentes pour la finance.
La première est la prolifération et l’absence d’inventaire. Des comptes de service dormants ou orphelins, des identités non désactivées après la fin de leur usage (improper offboarding), subsistent et restent exploitables. On ne protège pas ce que l’on ne voit pas.
La deuxième est l’exposition des secrets. Des secrets codés en dur, ou divulgués via des dépôts de code, des journaux ou des fichiers de configuration (secret leakage), offrent des identifiants directement réutilisables. Les pipelines CI/CD sont particulièrement concernés, avec des identifiants statiques parfois exposés dans les référentiels ou les configurations cloud.
La troisième est la longévité des secrets. Des secrets à longue durée de vie, jamais expirés ni renouvelés (long-lived secrets), prolongent indéfiniment la fenêtre d’exploitation en cas de fuite.
La quatrième est le sur-permissionnement. Des identités machine dotées de droits excessifs par rapport à leur besoin réel (overprivileged NHI) amplifient l’impact d’une compromission et facilitent la latéralisation.
La cinquième est la dépendance aux tiers. Des applications tierces ou des intégrations disposant d’accès aux données sensibles (vulnerable third-party NHI) élargissent la surface d’attaque et créent des risques de chaîne d’approvisionnement.
À cela s’ajoutent la réutilisation d’une même identité dans plusieurs contextes et le manque d’isolation entre environnements, qui aggravent la propagation d’une compromission.
Pourquoi c’est particulièrement sensible dans la finance
Les établissements financiers cumulent les facteurs de risque. Leurs systèmes reposent massivement sur des comptes de service, des intégrations par API, des robots RPA, des pipelines d’automatisation, des environnements cloud et un grand nombre de prestataires. Les chaînes d’accès entre applications, entre le SI et les prestataires, et entre environnements sont nombreuses et parfois mal cartographiées.
Or ces identités donnent souvent accès à des systèmes critiques : traitement des paiements, back-office, données clients, systèmes de messagerie et de validation. Une identité machine sur-permissionnée devient alors un levier de latéralisation vers ces actifs sensibles. Le risque n’est donc pas seulement technique : il touche des fonctions critiques, avec des enjeux de fraude, de continuité et de conformité.
Cette dimension rejoint les attentes réglementaires en matière de gestion des accès. DORA, en particulier, impose une gestion structurée du risque lié aux technologies de l’information et de la communication, incluant le contrôle des accès et la maîtrise des dépendances vis-à-vis des prestataires. Les identités machine, souvent au cœur de ces intégrations, entrent pleinement dans ce périmètre.
Bonne pratique : inventorier et découvrir
La première étape est la découverte. Il est impossible de sécuriser des identités que l’on ne recense pas. Un inventaire des identités machine et des secrets — comptes de service, clés, jetons, certificats, secrets applicatifs, identités de pipelines et d’intégrations — constitue le socle de toute démarche.
Cet inventaire doit aller au-delà d’une simple liste : il s’agit d’attribuer un propriétaire à chaque identité, de documenter son usage, de la classer selon sa criticité, et d’identifier les identités dormantes ou orphelines à désactiver. Sans cette visibilité, les autres contrôles restent partiels.
Bonne pratique : gestion centralisée des secrets
Les secrets ne devraient jamais être codés en dur dans du code ou des fichiers de configuration. Une gestion centralisée des secrets — via des coffres-forts dédiés (vaults) — permet de les stocker de manière protégée, de contrôler leur accès, et de les injecter au moment de l’exécution plutôt que de les disséminer.
Plusieurs pratiques renforcent cette approche : privilégier des secrets dynamiques et de courte durée de vie plutôt que des identifiants statiques, mettre en place une détection des secrets exposés (secret scanning) dans les dépôts de code et les chaînes CI/CD, et éviter la duplication des secrets entre applications et environnements.
Bonne pratique : moindre privilège et rotation
Le principe de moindre privilège s’applique aux identités machine comme aux humaines : chaque identité ne devrait disposer que des droits strictement nécessaires à sa fonction, sur un périmètre limité. Le sur-permissionnement, fréquent par facilité ou par héritage, doit être réduit par des revues régulières.
La rotation des secrets est tout aussi essentielle : renouveler régulièrement clés, jetons et certificats limite la fenêtre d’exploitation en cas de fuite. Lorsque c’est possible, les mécanismes de fédération d’identité de charge de travail (workload identity) et l’usage d’identifiants éphémères, par exemple via OpenID Connect, permettent de réduire, voire de supprimer, le recours à des clés statiques longue durée — à condition de valider correctement les jetons et les conditions d’accès.
Bonne pratique : détection d’usage anormal et gouvernance
Comme pour les identités humaines, la surveillance de l’usage des identités machine permet de détecter les comportements anormaux : accès inhabituels, pics d’activité, usage depuis un emplacement ou à un horaire atypique, tentative d’élévation de privilèges. Cette détection suppose une journalisation exploitable et une intégration au dispositif de supervision (SOC).
Au-delà des contrôles techniques, la clé est la gouvernance. Il s’agit d’instaurer un cycle de vie complet pour les identités machine — création encadrée, attribution d’un propriétaire, revue périodique, désactivation en fin d’usage —, à l’image de ce qui existe pour les utilisateurs. Cette gouvernance dédiée, articulée avec la gouvernance des identités humaines, transforme une gestion artisanale en un dispositif maîtrisé et auditable.
Articulation avec DORA et la résilience
La maîtrise des identités machine n’est pas seulement une bonne pratique de sécurité : elle contribue à la résilience opérationnelle et à la conformité. Un inventaire à jour, des accès au moindre privilège, une rotation effective et une détection des usages anormaux produisent des contrôles auditables, directement utiles dans le cadre de DORA et des exigences de gestion des accès et du risque lié aux prestataires.
La dimension tierce est particulièrement importante. Les identités machine sont souvent le support des intégrations avec des prestataires et des services externes. Les maîtriser, c’est aussi mieux maîtriser les dépendances et la surface d’attaque associée, dans une logique cohérente avec la gestion du risque lié aux prestataires TIC.
Perspective Forum des Compétences
Les identités machine constituent un angle mort structurel de la sécurité des systèmes d’information financiers. Leur volume, leur criticité et leur faible niveau de gouvernance en font l’un des vecteurs de compromission et de latéralisation les plus sous-estimés, alors même que les efforts IAM restent largement centrés sur l’humain.
Le traitement de ce risque ne repose pas sur un outil unique, mais sur une discipline de cycle de vie : inventorier et découvrir, centraliser et protéger les secrets, appliquer le moindre privilège, faire tourner les secrets, détecter les usages anormaux et instaurer une gouvernance dédiée. Les incidents publics récents rappellent qu’une seule identité oubliée, sur-permissionnée ou dotée d’un secret jamais renouvelé peut suffire à ouvrir une brèche.
Pour les banques et les assurances, l’enjeu est d’accorder aux identités machine la même rigueur qu’aux identités humaines. Le point de départ est presque toujours le même : retrouver la visibilité. On ne protège que ce que l’on voit — et, dans beaucoup d’organisations, une part importante des identités machine reste, aujourd’hui encore, invisible.
Sources publiques utilisées
Cet article s’appuie sur des travaux et référentiels publics reconnus en matière de sécurité des identités non humaines et des accès :
- OWASP, Non-Human Identities Top 10 – 2025, qui identifie et classe les principaux risques associés aux identités non humaines (dont la désactivation incomplète, la fuite de secrets, le sur-permissionnement, les secrets à longue durée de vie, les dépendances tierces et les configurations de déploiement cloud non sécurisées), et documente plusieurs incidents publics illustratifs (Microsoft « Midnight Blizzard » en janvier 2024, Okta en novembre 2023, Internet Archive en octobre 2024).
- ANSSI, recommandations relatives à l’administration sécurisée des systèmes d’information et à la gestion des comptes à privilèges et des secrets (principes de moindre privilège, séparation et protection des comptes d’administration, gestion des secrets et des identifiants).
- Cloud Security Alliance (CSA), publications et travaux relatifs à la sécurité des identités non humaines et à la gestion des secrets.
- Règlement (UE) 2022/2554 (DORA), pour ses dispositions relatives à la gestion du risque lié aux technologies de l’information et de la communication, au contrôle des accès et au risque lié aux prestataires