DeployBot reçoit un jeton à longue durée de vie pour publier des artefacts issus du pipeline de build. Une tâche inscrit le jeton dans les journaux d’intégration continue (CI), un attaquant récupère ces journaux, et ce même jeton permet de publier avec succès un paquet interne depuis une nouvelle adresse IP. L’attaquant n’a eu besoin ni du mot de passe d’un employé, ni d’une page de hameçonnage, ni d’une session utilisateur ; il lui a suffi de disposer d’un identifiant (credential) représentant une entité automatisée.
Une identité non humaine correspond à l’entité (ou « principal ») à l’origine d’une charge de travail, d’un service, d’un pipeline, d’un appareil ou d’un agent automatisé. Dans cet environnement, DeployBot dispose de droits d’accès parce que les services en aval acceptent son jeton, et non parce qu’un humain valide une authentification multifacteur (MFA) à chaque requête. La question qui se pose aux équipes de défense est donc d’ordre opérationnel : comment accorder des droits à périmètre restreint, les renouveler sans interrompre la production et détecter une utilisation abusive si l’identifiant sort de son environnement d’exécution prévu ?
Le scénario de défaillance le plus simple implique une entrée unique et un résultat unique. DeployBot présente une copie de son jeton d’accès (bearer token) au registre d’artefacts ; ce dernier publie alors l’artefact car le jeton est toujours valide et confère les permissions nécessaires. Un jeton atteste de sa possession, mais pas de la légitimité de l’emplacement ou du processus l’ayant obtenu, à moins que la conception globale du système d’identité n’intègre des vérifications supplémentaires à cet égard.
Règle de délimitation Un identifiant non humain doit permettre d’identifier l’entité, limiter ses droits d’accès et rester observable après son émission.
La fuite du jeton est critique car DeployBot ne représente qu’un seul des chemins d’identité au sein de prod-gke-1. Le cluster Kubernetes exécute les services Orders API, Billing API et Inventory API. Parallèlement à ces services, SupportAgent interagit avec des outils de support approuvés, ETLBot importe des données, et DeployBot construit et publie des artefacts. Chaque entité génère une décision d’autorisation, un cycle de vie pour ses identifiants et des traces que les équipes de défense doivent conserver.
La surface d’attaque ne se limite pas au cluster. Les requêtes traversent diverses frontières : celle du cluster, celle du maillage de services (service mesh) entre les charges de travail, ainsi que les interfaces avec le registre d’artefacts, le coffre-fort de secrets, le fournisseur d’identité et serveur d’autorisation, et les API de fournisseurs SaaS externes. Un identifiant copié depuis un périmètre peut être accepté dans un autre si les politiques le considèrent comme une preuve suffisante, sans tenir compte de son émetteur, de son public cible, de la charge de travail associée, de sa source ou de l’action autorisée. L’environnement décrit ci-dessous offre une cible cohérente pour les mesures de contrôle ultérieures.
Suivons le parcours des identifiants et des jetons lorsqu’ils franchissent ces frontières :
Ce schéma illustre la manière dont les droits d’accès (l’autorité) se propagent via des jetons à travers plusieurs systèmes, alors que chaque système ne consigne qu’une partie de l’historique de la requête.
L’inventaire recensant tous les chemins de délégation d’autorité, il est possible de modéliser la défaillance avant de choisir une mesure de contrôle. Une clé API divulguée via un dépôt de code ou un journal d’intégration continue (CI) permet à un attaquant d’usurper l’identité du principal jusqu’à la révocation de la clé. Un secret client OAuth volé permet de générer de nouveaux jetons d’accès. Un jeton d’accès rejoué peut fonctionner depuis un réseau ou un environnement d’exécution non prévu. Bien que ces vecteurs de vol diffèrent, ils franchissent tous la même frontière : un acteur externe présente des identifiants destinés à une charge de travail (workload) contrôlée.
Une portée excessive modifie l’impact en cas de vol. Si un rôle SupportAgent permet à la fois de lire des données de facturation et d’appeler un outil de remboursement en vertu d’une autorisation large, une requête déclenchée par une invite (prompt) ou un composant compromis de l’agent peut entraîner une action dépassant les droits initialement prévus pour le demandeur. Il s’agit d’un problème de type « confused deputy » (mandataire abusé) : un service disposant d’une autorité légitime exécute une action pour le compte d’un appelant non fiable ou insuffisamment autorisé. Le contrôle ne se limite pas à un renforcement de l’authentification ; l’appel de l’outil nécessite une politique explicite liant le principal demandeur, la ressource cible et l’opération autorisée.
La rotation des identifiants peut entraîner une défaillance plus insidieuse. Un coffre-fort de secrets peut contenir un nouvel identifiant alors que ETLBot continue d’utiliser l’ancien secret mis en cache, ou bien un fournisseur SaaS en aval peut accepter les deux versions plus longtemps que prévu. La rotation n’est considérée comme terminée que lorsque l’ancien identifiant ne permet plus d’autoriser des requêtes et que la charge de travail a démontré sa capacité à utiliser le nouvel identifiant.
Le tableau ci-dessous associe chaque menace à une mesure de prévention et à une source de preuve :
Le tableau comparatif ci-dessous associe chaque type de défaillance liée aux identifiants à sa frontière, à la mesure de prévention correspondante et à la source de preuve associée.