Votre équipe sécurité surveille les comptes humains. Elle a déployé la MFA, activé les alertes sur les connexions suspectes, et forme les utilisateurs au phishing. Pendant ce temps, dans vos pipelines CI/CD, vos scripts d'automatisation et vos intégrations SaaS, des milliers d'identités sans visage accèdent à vos systèmes critiques — souvent avec des droits excessifs, des secrets jamais renouvelés, et sans aucune surveillance active. C'est là que les attaquants entrent.

L'explosion silencieuse des identités machines

Les identités machines — terme générique pour désigner les comptes de service, API keys, tokens OAuth, certificats TLS/mTLS, secrets CI/CD, et identités de workloads cloud — ont connu une croissance exponentielle ces cinq dernières années. Selon le rapport CyberArk 2026 sur la sécurité des identités, le ratio moyen entre identités machines et identités humaines dans les entreprises a atteint 45 pour 1. Pour une organisation de 500 employés, cela représente potentiellement 22 500 identités non humaines — et dans la majorité des cas, personne ne dispose d'un inventaire complet.

Cette prolifération est le résultat direct de plusieurs tendances qui se sont accélérées simultanément : la migration vers le cloud avec ses APIs omniprésentes, l'adoption du DevOps et des pipelines CI/CD automatisés, la multiplication des intégrations SaaS (chaque outil tiers nécessite des tokens d'accès), et plus récemment l'essor des agents IA qui communiquent avec des dizaines de services via des credentials programmés. Chaque nouveau service, chaque nouvelle intégration, chaque script d'automatisation crée une ou plusieurs identités supplémentaires.

Le problème n'est pas l'existence de ces identités — elles sont nécessaires au fonctionnement des systèmes modernes. Le problème est qu'elles sont gérées (ou plutôt non gérées) de façon radicalement différente des identités humaines. Un collaborateur qui quitte l'entreprise déclenche un processus de désactivation de compte. Une API key créée pour un projet pilote en 2023 et oubliée dans un dépôt GitHub peut rester active indéfiniment. Un certificat de service généré pour un environnement de test peut se retrouver en production sans jamais expirer.

En mission de pentest cloud en 2026, je trouve systématiquement des secrets exposés. Pas toujours dans des endroits évidents — parfois dans des variables d'environnement de fonctions Lambda oubliées, dans des métadonnées d'images Docker publiées, dans l'historique git d'un dépôt interne. La durée de vie moyenne d'un secret non renouvelé que je retrouve en audit dépasse 18 mois. Et ce secret reste valide des années.

Pourquoi les attaquants ciblent les identités machines en priorité

Du point de vue d'un attaquant, les identités machines présentent plusieurs avantages décisifs par rapport aux identités humaines comme vecteur d'accès initial.

Elles ne se déconnectent jamais. Un token d'accès humain expire après quelques heures d'inactivité, déclenche une re-authentification MFA, et peut être révoqué en quelques clics par le helpdesk. Une API key avec une durée de vie de 10 ans ne se déconnecte pas, ne présente pas de challenge MFA, et n'appartient à aucun utilisateur particulier qui recevrait une alerte si elle était utilisée depuis un pays inconnu.

Elles disposent souvent de droits excessifs. Quand un développeur crée une API key pour tester une intégration, il prend les droits les plus larges disponibles pour éviter les problèmes — et ces droits restent en place. Dans les pentests cloud que je conduis, je trouve régulièrement des tokens avec des droits admin sur des tenants entiers, créés pour une tâche ponctuelle il y a 18 mois. En SSPM, les findings de type « service account avec droits administrateur complets » représentent généralement 30 à 40 % des critiques identifiés.

Leur usage est difficile à distinguer du trafic légitime. Quand un attaquant utilise une API key compromise, ses requêtes arrivent avec les mêmes en-têtes HTTP, depuis des plages IP éventuellement légitimes, avec des patterns d'accès qui peuvent ressembler à ceux de l'automatisation légitime. Sans baseline comportementale spécifique par identité machine, la détection est extrêmement difficile.

Elles se propagent facilement. Un développeur colle une API key dans un fichier .env, commite par erreur, pousse sur GitHub. GitHub Secrets Scanning peut bloquer la propagation publique — mais pour les dépôts privés, la vigilance est moindre. Les secrets se retrouvent dans des tickets Jira, des canaux Slack, des pastes internes, des scripts partagés entre équipes. Chaque copie est un vecteur d'exposition supplémentaire.

Pour illustrer l'ampleur du phénomène : GitGuardian a détecté 12,8 millions de secrets exposés dans des dépôts publics GitHub en 2025, dont 37 % étaient encore valides 30 jours après leur exposition. Le délai médian de révocation par les développeurs alertés était de 27 jours — une fenêtre d'exploitation confortable pour tout attaquant qui surveille le flux de commits publics.

Les vecteurs d'exposition les plus fréquents en 2026

Dans ma pratique des audits de sécurité cloud et des tests de pénétration, voici les vecteurs que je rencontre le plus fréquemment :

Les dépôts Git — internes et externes

Le classique. Malgré les années de sensibilisation, les secrets dans le code source restent le vecteur le plus fréquent. Les .env committés accidentellement, les fichiers de configuration de déploiement contenant des clés en clair, les scripts d'administration avec des mots de passe hardcodés. Les outils comme truffleHog, gitleaks et Semgrep permettent de scanner l'historique complet d'un dépôt — y compris les commits où le secret a été « supprimé » mais reste dans l'historique git.

Les variables d'environnement des fonctions serverless

AWS Lambda, Google Cloud Functions, Azure Functions — les variables d'environnement sont le mécanisme standard pour injecter des secrets dans ces fonctions. Le problème : elles sont souvent visibles en clair dans la console de gestion cloud pour tout utilisateur disposant de droits de lecture sur la fonction, et elles apparaissent en clair dans les exports CloudFormation/Terraform si ceux-ci ne sont pas chiffrés.

Les images Docker publiées

Des secrets injectés lors du build Docker restent dans les layers de l'image si le Dockerfile n'est pas écrit correctement. Des images Docker contenant des credentials de base de données, des tokens d'API ou des certificats privés ont été trouvées dans des registries publics. La commande docker history permet d'inspecter chaque layer et d'en extraire les variables d'environnement définies à chaque étape du build.

Les pipelines CI/CD

GitHub Actions, GitLab CI, Jenkins, CircleCI — les secrets d'intégration continue ont un périmètre d'exposition particulier : ils sont accessibles par tous les workflows du dépôt, y compris ceux déclenchés par des pull requests de contributeurs externes sur les dépôts publics. Des attaques de type « malicious PR » ciblent spécifiquement les pipelines CI/CD pour exfiltrer les secrets d'environnement vers des webhooks contrôlés par l'attaquant.

Les métadonnées des instances cloud (IMDS)

Le service de métadonnées des instances (Instance Metadata Service) est disponible sur AWS, Azure et GCP. Il fournit aux applications tournant sur une instance les credentials temporaires associés au rôle IAM de l'instance. Depuis une SSRF ou un accès initial à l'instance, un attaquant peut récupérer ces credentials via un appel HTTP vers l'endpoint IMDS local. Ces credentials sont temporaires mais renouvelés automatiquement — et donnent accès à tous les services cloud auxquels le rôle a accès.

Les intégrations SaaS non révoquées

Chaque outil SaaS intégré à votre stack demande une autorisation OAuth ou une API key. Quand l'outil est abandonné ou l'abonnement non renouvelé, les tokens d'accès restent souvent actifs. Un attaquant qui compromet ce service tiers peut utiliser ces tokens actifs pour accéder à vos données. C'est une forme de risque de supply chain applicatif que peu d'organisations auditent régulièrement.

Construire un programme de gestion des identités machines

La bonne nouvelle : contrairement à certains problèmes de sécurité qui nécessitent des investissements massifs, la gestion des identités machines peut être significativement améliorée avec des processus et des outils souvent déjà disponibles dans l'organisation.

Phase 1 : l'inventaire — ne gérez pas ce que vous ne connaissez pas

La première étape, incontournable, est de construire un inventaire exhaustif de vos identités machines. Cela inclut : les comptes de service Active Directory/Entra ID, les API keys dans vos services cloud (AWS IAM, GCP Service Accounts, Azure Service Principals), les tokens OAuth dans vos plateformes SaaS, les secrets dans vos gestionnaires de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), et les certificats TLS/mTLS.

Pour chaque identité, l'inventaire doit documenter : le propriétaire fonctionnel (quelle application l'utilise), le propriétaire humain (qui est responsable), les permissions associées, la date de création, la date de dernière utilisation, et la date d'expiration si définie. Sans cette information, vous ne pouvez pas rationaliser, surveiller ou révoquer efficacement.

Phase 2 : le principe du moindre privilège, appliqué aux machines

Une fois l'inventaire constitué, l'audit des permissions révèle invariablement des droits excessifs. La remédiation suit le principe du moindre privilège : chaque identité machine ne doit disposer que des permissions strictement nécessaires à sa fonction, sur les ressources strictement nécessaires, pour la durée strictement nécessaire.

En pratique : remplacer les API keys avec droits admin par des tokens à portée limitée, utiliser les politiques IAM basées sur des conditions (adresse IP source, heure de la journée, tag de ressource), et mettre en place des tokens à durée de vie courte avec renouvellement automatique plutôt que des clés longue durée.

Phase 3 : la rotation automatique et la détection de secrets exposés

La rotation manuelle des secrets ne fonctionne pas à l'échelle. Les gestionnaires de secrets modernes (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) permettent la rotation automatique des credentials avec notification aux applications concernées. La mise en place de cette rotation automatique est l'un des contrôles à meilleur ROI en matière d'identités machines.

En parallèle, le scanning continu des dépôts de code source pour détecter les secrets exposés accidentellement est désormais une pratique standard. GitHub Advanced Security et GitLab Ultimate incluent cette fonctionnalité nativement. Pour les équipes sans ces outils, truffleHog et gitleaks sont des alternatives open source efficaces intégrables dans les pipelines CI/CD pour bloquer les commits contenant des secrets.

Phase 4 : la surveillance comportementale des identités machines

Un token compromis utilisé par un attaquant génère des patterns d'accès différents du token légitime : horaires inhabituels, adresses IP nouvelles, volumes de requêtes anormaux, accès à des ressources inhabituelles. La surveillance comportementale des identités machines — via les logs CloudTrail/Activity Log analysés par un SIEM ou un CSPM — permet de détecter ces anomalies.

La clé est d'établir une baseline par identité machine : à quelles heures accède-t-elle normalement ? Depuis quelles IPs ? Quels services appelle-t-elle ? Toute déviation significative doit générer une alerte. Cette approche comportementale compense l'impossibilité d'appliquer une MFA traditionnelle aux identités machines.

Mon avis d'expert

En 2026, la question n'est plus de savoir si votre organisation a des identités machines mal gérées — c'est garanti. La question est de savoir combien d'entre elles sont actuellement utilisées par des attaquants que vous n'avez pas détectés. Dans la quasi-totalité des tests d'intrusion cloud que je conduis, j'obtiens un accès significatif via des secrets exposés dans les 2 premières heures — avant même d'avoir essayé d'exploiter une CVE. Le périmètre réseau est surveillé, les identités humaines bénéficient de la MFA, mais les identités machines restent un angle mort systémique. C'est là que se gagne ou se perd la bataille en 2026.

Ce que ça change pour les RSSI en 2026

La gestion des identités machines n'est plus un sujet optionnel ou « pour plus tard ». Plusieurs évolutions réglementaires et de marché en font une priorité de gouvernance.

Le référentiel NIS2 impose aux entités essentielles et importantes une gestion formalisée des accès privilégiés, qui couvre désormais explicitement les comptes de service et les accès non humains. Les audits de conformité NIS2 commenceront à sanctionner l'absence de programme dédié aux identités machines dès 2026-2027 dans les premiers pays ayant transposé la directive.

DORA, applicable au secteur financier depuis janvier 2025, exige une cartographie des dépendances applicatives et des accès inter-systèmes — ce qui implique de facto un inventaire des identités machines gérant ces connexions. Les premières inspections sectorielles révèlent des lacunes importantes dans ce domaine.

Côté assurance cyber, les questionnaires des assureurs intègrent de plus en plus des questions sur la gestion des accès machines. Les organisations incapables de démontrer un programme structuré voient leurs primes augmenter ou leurs couvertures restreintes.

Enfin, l'émergence des agents IA autonomes dans les infrastructures d'entreprise crée une nouvelle catégorie d'identités machines particulièrement sensibles : des agents qui accèdent à des données, exécutent des actions et appellent des APIs tierces avec des credentials dédiés. Sécuriser ces agents — et les secrets qu'ils utilisent — est déjà un enjeu pour les organisations pionnières en 2026 et deviendra universel dans les 18 prochains mois.

Conclusion : commencez par l'inventaire, aujourd'hui

Le programme de gestion des identités machines n'est pas un projet à 18 mois. La première étape — l'inventaire — peut être lancée cette semaine avec les outils que vous avez déjà. Requêtez votre console AWS IAM pour lister les access keys et leur date de dernière utilisation. Parcourez votre tenant Entra ID pour identifier les Service Principals et leurs permissions. Scannez vos dépôts git avec truffleHog. Ce premier inventaire, même imparfait, vous donnera une image de votre exposition réelle que vous n'avez probablement jamais eue.

Ensuite, priorisez la remédiation par criticité : les secrets avec droits admin, les tokens jamais utilisés depuis plus de 90 jours, les credentials exposés dans des dépôts accessibles à des tiers. Chaque secret révoqué ou remplacé est une porte fermée que vous avez peut-être laissée ouverte depuis des années.

Les attaquants savent déjà que vos identités machines sont votre angle mort. La question est de savoir combien de temps vous allez leur laisser cet avantage.

Besoin d'un regard expert sur votre sécurité ?

Ayi NEDJIMI réalise des audits d'identités machines et des tests de pénétration cloud pour identifier vos expositions réelles avant qu'un attaquant ne le fasse.

Prendre contact