Demandez à une organisation combien elle compte de collaborateurs : la réponse est immédiate. Demandez combien elle compte de comptes de service, de jetons applicatifs et de clés d'API actifs : la réponse est une estimation, souvent basse.
Cette population échappe à tous les processus, pour une raison simple : elle n'est créée par aucune embauche, ne quitte l'organisation avec personne, et n'a jamais oublié son mot de passe. Elle n'appelle donc jamais le support, seul mécanisme qui révèle habituellement l'existence d'un compte.
Une frontière conceptuelle avant les contrôles
Un facteur d'authentification humain cherche à établir une intention : cette personne veut-elle cette opération, en connaissance de ce qu'elle engage ? Cette question n'a pas de sens pour un traitement automatisé. Un script ne veut rien ; il exécute.
La conséquence est nette et rarement énoncée : toute la doctrine de la preuve d'intention — le contexte affiché, le consentement éclairé, la résistance à la persuasion — est hors sujet ici. Elle ne s'applique pas mal, elle ne s'applique pas du tout.
Ce qui la remplace n'est pas une preuve plus faible, c'est un objet différent : puisqu'il n'y a pas d'intention à vérifier, la sécurité repose entièrement sur la contrainte de périmètre et sur le cycle de vie. Un compte de service correctement gouverné est un compte qui ne peut pas faire autre chose que ce pour quoi il existe, et qui cesse d'exister quand ce besoin cesse.
Le cas des agents logiciels qui agissent au nom d'un utilisateur est différent, parce qu'une intention humaine s'y trouve quelque part : il est traité dans agents autonomes et identité machine.
Ce qui authentifie ces identités, et ce qui casse
| Type | Ce qui l'authentifie | Ce qui casse en pratique |
|---|---|---|
| Compte de service dans l'annuaire | mot de passe, souvent sans expiration | privilèges accumulés, mot de passe connu de plusieurs équipes |
| Clé d'API | un secret statique | présence dans le code, dans un historique, dans un ticket |
| Jeton OAuth applicatif | secret client | portée trop large, absence de révocation testée |
| Certificat client | clé privée | expiration non surveillée, renouvellement manuel oublié |
| Identité fournie par la plateforme | attestation courte, non stockable | dépendance à un environnement d'exécution unique |
La dernière ligne est la seule qui supprime le problème du secret plutôt que de le déplacer : quand l'environnement d'exécution atteste lui-même l'identité du traitement, il n'y a plus de valeur durable à voler. C'est la direction à privilégier quand elle est disponible.
Quatre contrôles qui produisent un effet
- Un inventaire avec un propriétaire nommé. Une personne, pas une équipe. Un compte sans propriétaire identifiable est un compte à fermer : l'expérience montre que personne ne réclame ceux qui servent encore, et que ceux qui ne servent plus ne manquent à personne.
- Un périmètre minimal et explicite. La question utile n'est pas « ce compte a-t-il trop de droits ? » mais « quelles opérations exactes doit-il pouvoir faire ? ». La première invite à un arbitrage sans fin, la seconde produit une liste.
- Une échéance, donc une rotation. Un secret sans date de fin est un secret permanent. La rotation n'a pas besoin d'être fréquente pour être utile : elle doit surtout être éprouvée, car une rotation jamais exécutée échouera le jour où elle est nécessaire.
- Aucun secret durable dans le code. Cette règle est ancienne et systématiquement contournée sous pression de délai. La parade réaliste n'est pas la discipline, c'est de rendre le bon chemin plus rapide que le mauvais.
Les deux confusions coûteuses
L'emprunt par un humain est le cas le plus fréquent et le plus dommageable : un administrateur utilise l'identité applicative pour dépanner. L'action devient inimputable, et tout dossier de preuve ultérieur est inexploitable. La règle doit être technique, non déclarative : un compte de service ne doit pas pouvoir ouvrir de session interactive.
L'action sur un parcours humain est le cas inverse. Un traitement automatisé qui modifie des coordonnées bancaires ou élève des privilèges exécute une opération qui, faite par une personne, exigerait une preuve d'intention. Le contrôle se déplace alors en amont : qui a validé la règle d'automatisation, quand, et cette validation est-elle tracée ? C'est là que la question de l'intention réapparaît, non sur l'exécution mais sur la décision d'automatiser.
Ce que la réglementation en dit
Ni NIS2 (directive (UE) 2022/2555) ni DORA (règlement (UE) 2022/2554) ne consacrent de disposition propre aux identités machine. Toutes deux attendent une maîtrise démontrable des accès, ce qui inclut ces comptes sans les nommer. En audit, la question prend une forme concrète : produire la liste des comptes techniques disposant de privilèges élevés, avec leur propriétaire et la date de dernière rotation.
Le Cyber Resilience Act (règlement (UE) 2024/2847) est plus directement pertinent pour les éditeurs : l'interdiction du mot de passe par défaut vise précisément les identités préconfigurées dans les produits.
Ce que ces contrôles ne règlent pas
Ils ne détectent pas l'usage anormal d'un compte légitime. Un secret volé, employé depuis un environnement plausible et dans le périmètre autorisé, ne se distingue pas d'un usage normal. Cela suppose un contrôle d'une autre nature — la surveillance du comportement — dont la valeur dépend de la qualité de la base de référence.
Ils ne réduisent pas non plus le risque le plus banal : un compte technique surdimensionné parce que personne n'a eu le temps d'établir la liste minimale au moment du déploiement. C'est un problème de délai de projet, pas de sécurité, et il se traite au moment où le projet est planifié — voir où passe réellement le temps d'un déploiement.
Enfin, ils laissent entière la question des accès humains, où la preuve d'intention reste le sujet : ce qu'établit le 4ᵉ facteur cognitif n'a pas d'équivalent ici, et ne prétend pas en avoir.
FAQ
Faut-il de la MFA sur un compte de service ?
La question est mal posée : un second facteur suppose un porteur. L'équivalent utile est une authentification liée à l'environnement d'exécution — l'identité attestée par la plateforme — plutôt qu'un secret partagé. Là où ce n'est pas disponible, la rotation et la restriction de périmètre remplacent le facteur manquant.
Comment inventorier sans outil dédié ?
Par les journaux plutôt que par les annuaires : lister les identités qui se sont authentifiées sur les quatre-vingt-dix derniers jours donne un état réel, là où l'annuaire donne un état déclaré. L'écart entre les deux listes est l'information la plus utile de l'exercice.
Un secret dans un gestionnaire de secrets est-il suffisant ?
C'est nécessaire et insuffisant. Le gestionnaire protège le stockage ; il ne réduit ni le périmètre du compte, ni sa durée de vie, ni le nombre de personnes autorisées à le lire. Ces trois paramètres restent à décider.
Que faire des comptes dont personne ne connaît l'usage ?
Les désactiver plutôt que les supprimer, sur une fenêtre annoncée, et observer. C'est la seule méthode qui produise une réponse fiable, et elle exige d'accepter un incident possible — arbitrage à documenter avant, pas à improviser pendant.
Aller plus loin : pilier : authentification cognitive · authentifier les tiers et prestataires · accès à privilèges et PAM · principes du Zero Trust