Sécurité des identités non humaines : clés API, comptes de service et identifiants de charges de travail en 2026

Réponse courte : la sécurité des identités non humaines est la discipline qui consiste à savoir quelles machines, applications, pipelines et agents peuvent agir dans votre environnement. En 2026, beaucoup de compromissions n'ont pas besoin d'un mot de passe humain, parce qu'une clé API, un compte de service ou un jeton de charge de travail dispose déjà de l'accès que les attaquants recherchent.

Les programmes d'identité humaine ont mûri. Les organisations déploient SSO, MFA, accès conditionnel, posture des équipements et détection des connexions à risque. Pendant ce temps, les identités logicielles se sont multipliées en silence. Chaque job CI, chaque runner Terraform, chaque charge de travail Kubernetes, chaque pipeline de données, chaque bot de supervision, chaque webhook, chaque connecteur SaaS et chaque agent IA a besoin d'un moyen de s'authentifier.

Ces identités portent souvent de larges privilèges. Elles ont aussi tendance à être désordonnées. Certaines sont créées dans l'urgence d'une mise en production et ne sont jamais revues. Certaines sont partagées par plusieurs services. Certaines disposent de privilèges d'administration parce que personne ne connaissait le périmètre minimal nécessaire. Certaines résident dans des fichiers .env, des images de conteneurs, des logs de build ou de vieux portables. Certaines fonctionnent encore des années après l'arrêt du projet qui les a créées.

Les attaquants l'ont bien compris. Si voler le mot de passe d'un utilisateur déclenche le MFA et les contrôles de risque, voler un jeton de service peut se révéler plus simple.

Le problème de la prolifération des identités non humaines

Les identités non humaines comprennent :

• Les clés API.
• Les comptes de service cloud.
• Les identités de charges de travail.
• Les jetons de comptes de service Kubernetes.
• Les jetons de déploiement CI/CD.
• Les applications OAuth et les enregistrements d'applications.
• Les clés SSH utilisées par l'automatisation.
• Les identifiants de bases de données.
• Les secrets de webhooks.
• Les certificats et clés privées.
• Les identifiants d'outils utilisés par les agents IA.

Leur point commun : un logiciel s'en sert pour agir. Cette action peut être en lecture seule, ou bien déployer du code, créer de l'infrastructure, accéder à des données clients, envoyer des e-mails, interroger des logs ou appeler des services d'IA facturés.

Le problème de prolifération apparaît quand les équipes de sécurité ne peuvent plus répondre à des questions élémentaires : qui est propriétaire de cette clé ? Quel système l'utilise ? À quoi donne-t-elle accès ? Quand a-t-elle été utilisée pour la dernière fois ? Où est-elle stockée ? Que se passe-t-il si on la révoque ?

Pourquoi les attaquants adorent les identités non humaines

Les identités non humaines sont attirantes parce qu'elles peuvent être à durée de vie longue et peu surveillées. Un compte utilisateur peut déclencher des alertes de connexion interactive. Un compte de service, lui, s'authentifie discrètement via une API des milliers de fois par jour. Un usage malveillant peut se dissimuler dans le bruit de l'automatisation.

Beaucoup d'identifiants non humains contournent aussi les contrôles utilisateur habituels. Le MFA ne s'applique pas à une clé API. La conformité des équipements ne s'applique pas à un jeton CI. Une réinitialisation de mot de passe ne fait pas tourner un secret codé en dur.

Les attaquants peuvent trouver ces identifiants via des dépôts publics, la compromission de dépôts privés, des paquets malveillants, l'exposition de logs de build, le phishing de développeurs, des malwares infostealer, l'abus du service de métadonnées cloud et des intégrations SaaS aux permissions trop larges.

Le résultat est un accès direct. Un jeton CI dérobé peut publier une release backdoorée. Un compte de service cloud peut lire des buckets de stockage. Une clé d'API IA peut permettre le LLMjacking. Un secret de webhook peut permettre à un attaquant d'usurper des événements de confiance.

Commencez par construire un inventaire

On ne gouverne pas des identités qu'on ne voit pas. Commencez par collecter les données d'identités non humaines depuis chaque plan de contrôle :

• IAM cloud et clés d'accès.
• Clés de déploiement et installations d'applications sur la gestion de code source.
• Variables CI/CD et identifiants des runners.
• Gestionnaires de secrets.
• Clusters Kubernetes.
• Autorisations d'applications OAuth SaaS.
• Passerelles API.
• Bases de données.
• Outils de supervision et de journalisation.

Pour chaque identité, consignez le propriétaire, la finalité métier, l'environnement, les permissions, la date de création, la dernière utilisation, l'état de rotation et le lieu de stockage. Les identités sans propriétaire doivent être traitées comme un risque. Les identités inutilisées doivent être désactivées avant de devenir des portes dérobées mystérieuses.

Ne réduisez pas l'inventaire à un exercice de tableur. Les données changent en permanence. Mettez en place une découverte récurrente et des alertes sur les nouvelles identités.

Conception des permissions

Le moindre privilège semble une évidence, mais il est rarement appliqué à l'automatisation. Les équipes accordent souvent de larges permissions parce que le pipeline doit livrer aujourd'hui. Des mois plus tard, cette permission devient un risque invisible.

Concevez les identités autour de tâches précises. Un job de build qui publie des artefacts n'a pas besoin d'accéder à la base de données de production. Une intégration de supervision qui lit des métriques n'a pas besoin d'un accès en écriture à l'IAM. Un crawler qui vérifie la réputation de domaines n'a pas besoin d'accéder à la facturation client.

Séparez les environnements. Les identifiants de développement ne doivent pas accéder à la production. Les identifiants de production ne doivent pas être disponibles dans des notebooks locaux. L'automatisation de secours (break-glass) doit être soumise à une approbation stricte et à une journalisation.

Utilisez des identifiants à durée de vie courte quand c'est possible. La fédération d'identité de charge de travail, les identités managées et l'échange de jetons réduisent le rayon d'impact des clés statiques fuitées. Les identifiants statiques doivent être renouvelés régulièrement et strictement cadrés.

Stockage et gestion des secrets

Les secrets doivent résider dans un gestionnaire de secrets, pas dans le code source, les images de conteneurs, la messagerie, les tickets ou les pages de wiki. Le principe est simple ; c'est l'application qui est difficile.

Utilisez le secret scanning sur les dépôts, les logs CI, les images de conteneurs et les outils collaboratifs. Bloquez les commits contenant des secrets. Faites tourner automatiquement les identifiants exposés. Traitez toute exposition publique comme une compromission, même si les logs ne montrent aucun usage.

Soyez prudent avec les systèmes de build. Les environnements CI affichent souvent les variables pendant le débogage ou transmettent des secrets à des actions tierces. Vérifiez ce que ces actions peuvent lire. Épinglez les dépendances. Limitez les secrets disponibles pour les pull requests issues de forks.

Pour plus de détails, voir CI/CD : les secrets dans les pipelines et Paquets npm malveillants.

Superviser l'usage des identités non humaines

Surveillez les identités non humaines par leur comportement, pas seulement par leur existence. Parmi les alertes utiles :

• Première utilisation d'un nouveau compte de service.
• Utilisation depuis un nouvel ASN, une nouvelle région ou une nouvelle plage IP.
• Utilisation en dehors des fenêtres de déploiement attendues.
• Événements de refus d'accès suivis d'un accès réussi.
• Appels API vers des ressources que l'identité n'a jamais touchées.
• Hausse soudaine du volume ou du coût.
• Accès depuis des proxys connus, des VPN, Tor ou des infrastructures malveillantes.
• Identité longtemps inutilisée redevenue soudainement active.

Reliez les logs à leurs propriétaires. Une alerte qui dit « service-account-prod-17 utilisé depuis une nouvelle IP » est bien moins utile que « l'identité du job d'export de facturation, détenue par l'équipe Data Platform, a été utilisée depuis un hôte cloud inhabituel ».

La threat intelligence améliore le tri. Si l'IP source est une infrastructure abusive connue, la priorité de l'incident change immédiatement.

Playbook de réponse

Lorsqu'un identifiant non humain est suspecté compromis :

1. Désactivez-le ou faites-en la rotation.
2. Identifiez tous les systèmes qui en dépendent.
3. Passez en revue les logs d'audit pour les actions réalisées par cette identité.
4. Vérifiez si les permissions permettaient un mouvement latéral.
5. Recherchez l'identifiant dans les dépôts, les logs, les images et les postes des développeurs.
6. Remplacez les secrets statiques par une identité à durée de vie courte lorsque c'est réaliste.
7. Ajoutez de la détection pour les identités similaires.

Ne faites pas tourner uniquement la clé évidente. Si une clé a fuité via un pipeline, d'autres clés stockées de la même façon peuvent aussi être exposées.

Modèle de maturité

Un programme d'identités non humaines de base commence par la découverte. L'organisation sait lister ses clés API, comptes de service, enregistrements d'applications, jetons CI et identités de charges de travail. Elle sait repérer les identifiants inutilisés et les supprimer. Elle sait faire tourner rapidement les secrets exposés.

Le niveau suivant est la propriété. Chaque identité a une équipe nommée, une finalité métier, un environnement et un niveau de risque. Les nouvelles identités exigent un propriétaire dès leur création. Les identifiants sans propriétaire sont bloqués ou expirés automatiquement. Les revues d'accès incluent les identités machine, pas seulement les collaborateurs.

Le troisième niveau est l'application de politiques. Les secrets statiques sont remplacés par de l'identité de charge de travail lorsque c'est possible. Les permissions à haut risque exigent une approbation. Les secrets ne sont pas exposés à des étapes de build non fiables. Les systèmes sensibles exigent des équipements managés, des réseaux attendus et des jetons à durée de vie courte.

Le niveau avancé est la détection comportementale. L'organisation comprend l'usage normal de chaque identité et alerte quand il change. Les comptes de service sont surveillés pour de nouvelles IP sources, de nouvelles API, un volume inhabituel et des infrastructures suspectes. Les équipes de réponse peuvent révoquer, faire tourner et redéployer sans deviner quel système va casser.

Questions à poser pour chaque compte de service

Posez ces questions lors des revues :

• Qui est propriétaire de cette identité ?
• Quel système l'utilise ?
• Quel processus métier tombe si on la désactive ?
• Quelles permissions exactes détient-elle ?
• Quand a-t-elle été utilisée pour la dernière fois ?
• Où l'identifiant est-il stocké ?
• Peut-elle être remplacée par une identité de charge de travail ?
• Depuis quels emplacements réseau devrait-elle être utilisée ?
• Quels logs attestent de son activité ?
• Quel est le processus de rotation ?

Si l'équipe ne sait pas répondre, l'identité constitue un risque. Cela ne veut pas dire qu'il faut la supprimer immédiatement, mais qu'elle doit être priorisée pour investigation.

CI/CD et identités non humaines

Les systèmes CI/CD sont des concentrateurs d'identités non humaines. Ils détiennent souvent des identifiants cloud, des jetons de registres de paquets, des clés de signature, des identifiants de déploiement et des webhooks de messagerie. Une dépendance malveillante ou un runner compromis peut transformer ces secrets en chemin d'attaque.

Séparez les étapes d'installation, de build, de test, de publication et de déploiement. L'étape d'installation des dépendances ne doit pas disposer des identifiants de déploiement en production. Les pull requests issues de forks non fiables ne doivent pas recevoir de secrets. Les runners doivent être isolés, éphémères et journalisés. L'accès réseau sortant doit être contrôlé, en particulier pendant l'installation des dépendances.

Utilisez des identités différentes pour des dépôts et des environnements différents. Un jeton dédié à un projet ne doit pas pouvoir en déployer un autre. Un pipeline de préproduction ne doit pas lire les secrets de production. Un build de documentation ne doit pas disposer de privilèges d'administration cloud.

Mesurer les progrès

Suivez des métriques concrètes : nombre de clés statiques actives, nombre d'identités sans propriétaire, pourcentage d'identités inutilisées depuis 30 ou 90 jours, âge médian des identifiants, nombre d'identités disposant de privilèges d'administration, nombre de secrets trouvés dans les dépôts et délai de rotation après exposition.

Ces métriques aident la direction à percevoir le programme comme une réduction de risque plutôt qu'un simple nettoyage. L'objectif n'est pas un inventaire parfait dès le premier jour. L'objectif est une réduction régulière des identifiants inconnus, surprivilégiés et à durée de vie longue.

Plan de mise en œuvre sur 90 jours

Le premier mois, concentrez-vous sur la découverte et la suppression. Extrayez les listes d'identités depuis les plateformes cloud, la gestion de code source, le CI/CD, Kubernetes, les gestionnaires de secrets et les applications SaaS. Après validation, désactivez les identifiants manifestement inutilisés, expirés, dupliqués ou sans propriétaire. Ajoutez des étiquettes de propriétaire, d'environnement et de finalité aux identités restantes.

Le deuxième mois, réduisez les privilèges. Priorisez les identités disposant d'un accès administrateur, d'un accès production, de permissions de lecture des secrets, de droits de publication de paquets et de droits de déploiement. Scindez les identités partagées par application. Déplacez les secrets du code et des logs CI vers des coffres de secrets managés. Configurez des alertes sur la création de nouvelles clés et sur la première utilisation depuis une infrastructure inhabituelle.

Le troisième mois, modernisez les identifiants les plus à risque. Remplacez les clés statiques par de la fédération d'identité de charge de travail ou de l'identité managée lorsque c'est possible. Ajoutez de l'élévation just-in-time pour les rares tâches d'administration. Instaurez une revue d'accès trimestrielle qui inclut les identités non humaines. Testez un scénario de compte de service compromis et mesurez le temps nécessaire pour révoquer, faire tourner et redéployer en toute sécurité.

Culture de la propriété

Les identités non humaines deviennent souvent risquées parce que personne ne s'en sent responsable. Faites de la propriété une exigence d'ingénierie. Un nouveau compte de service ne devrait pas être approuvé s'il n'a pas une équipe propriétaire, une finalité documentée, une date de revue et un plan de démantèlement. Quand les équipes livrent de l'automatisation, elles doivent aussi livrer le cycle de vie des accès.

La propriété doit survivre aux réorganisations. Quand une équipe change de nom, fusionne ou arrête un projet, ses identités machine doivent être revues au même titre que ses dépôts et ses ressources cloud. Beaucoup d'identifiants dangereux ne sont pas créés avec malveillance ; ils le deviennent parce que leurs propriétaires ont disparu.

La propriété du cycle de vie est le contrôle qui empêche cette situation de devenir la norme.

Ce qu'il faut retenir côté threat intelligence

Les identités non humaines deviennent le tissu conjonctif de l'infrastructure moderne. Elles deviennent aussi un raccourci pour les attaquants afin de contourner les contrôles de sécurité pensés pour les humains.

isMalicious aide en enrichissant les IP et domaines qui apparaissent dans les logs d'API, les rappels CI, le trafic de webhooks et les événements d'audit cloud. Quand un compte de service agit depuis une infrastructure suspecte, le contexte de réputation aide les intervenants à distinguer l'automatisation attendue d'un abus d'identifiants.