Attaques par confiance inter-comptes AWS : comment l'enchaînement de rôles atteint les actifs les plus critiques

Par l'équipe Pathbreak · 11 août 2026 · 6 min de lecture

Un AWS multi-comptes est la manière recommandée d'exploiter un grand parc, et les rôles IAM inter-comptes sont ce qui le relie. Un compte de sécurité lit les journaux de chaque compte de charge de travail. Un compte de services partagés déploie dans les autres. Un fournisseur endosse un rôle pour exécuter son produit. Tout cela, c'est la confiance inter-comptes qui fonctionne comme prévu.

C'est aussi la carte que suit un attaquant. Atterrir dans un compte, chercher un rôle que vous pouvez endosser dans le suivant, et recommencer. Cet article couvre la manière dont la confiance inter-comptes est détournée, comment l'enchaînement de rôles atteint les actifs les plus critiques, et comment briser le chemin avec un seul changement.

Comment fonctionne la confiance inter-comptes

Chaque rôle IAM a deux politiques. La politique de permissions dit ce que le rôle peut faire. La politique de confiance, la politique d'assume-role, dit qui est autorisé à le devenir. Pour entrer dans un rôle, un principal appelle sts:AssumeRole et obtient des identifiants temporaires, pour autant que la politique de confiance du rôle cible autorise ce principal et que l'appelant dispose de la permission sts:AssumeRole.

La politique de confiance contrôle qui peut entrer, de sorte que la sécurité inter-comptes dépend de la précision avec laquelle vous nommez les principaux que vous autorisez.

Là où la confiance dérape

Les principaux avec joker dans les politiques de confiance

La politique de confiance la plus dangereuse et la plus mal comprise est un principal avec joker. Une instruction qui autorise "Principal": { "AWS": "*" } avec "Action": "sts:AssumeRole" ne signifie pas n'importe quelle identité de votre compte. Elle ouvre le rôle à chaque compte AWS du monde. Il y a une seconde exigence, l'identité appelante doit aussi disposer de la permission sts:AssumeRole sur le rôle, mais c'est justement pourquoi le joker est un risque concret : un attaquant s'accorde cette permission dans son propre compte AWS, et fournit donc la seconde exigence gratuitement. Les équipes lisent le joker comme "tous les membres de mon équipe" et le mettent en production. Ce qu'elles ont publié, c'est un rôle que n'importe quel attaquant peut endosser depuis un compte qu'il contrôle. Sur un rôle doté de permissions significatives, cela donne tout ce que le rôle peut faire. Si vous avez vraiment besoin d'un principal large, contraignez-le avec une Condition telle que aws:PrincipalAccount ou aws:PrincipalOrgID, et mieux encore, nommez les ARN de rôle exacts que vous comptez approuver.

Le deputy confus sur les rôles tiers

Quand vous laissez un fournisseur SaaS endosser un rôle dans votre compte, ce fournisseur utilise un seul compte AWS pour servir de nombreux clients. Si votre politique de confiance ne nomme que le compte du fournisseur, un autre des clients de ce fournisseur pourrait l'amener à endosser votre rôle. Le correctif est un external ID, un secret partagé dans la condition, ou une condition aws:SourceArn ou aws:SourceAccount qui lie l'endossement à votre relation spécifique. Un rôle tiers sans l'un de ceux-ci est une exposition classique au deputy confus.

L'enchaînement de rôles à travers les comptes

Un seul saut atteint rarement l'objectif, de sorte que les chemins réels s'enchaînent. L'attaquant endosse un rôle dans le compte dev, qui se trouve être approuvé par un rôle dans le compte de services partagés, qui peut endosser un rôle en production, qui peut lire les identifiants de la base de données dans Secrets Manager. Quatre appels sts:AssumeRole légitimes, et un point d'ancrage dans le compte le moins important est devenu un accès aux données les plus importantes.

Ce qui rend l'enchaînement dangereux, c'est que chaque saut est autorisé, rien n'est exploité, et les identifiants sont temporaires et attendus. Pour CloudTrail, cela ressemble à des rôles qui font leur travail. La seule façon de voir le danger est de regarder la chaîne entière d'un coup et de se demander où elle aboutit, plutôt que de juger chaque relation de confiance isolément.

AWS ajoute bien des frictions. Les sessions de rôles enchaînées sont plafonnées à une heure et ne peuvent pas être renouvelées par un enchaînement supplémentaire. Cela limite la durée de vie des sessions, mais cela ne ferme pas le chemin.

Pourquoi les frontières de compte paraissent plus sûres qu'elles ne le sont

Les équipes traitent la frontière de compte comme une frontière de sécurité, et c'en est une bonne pour le rayon d'impact. L'ennui, c'est que les rôles inter-comptes sont délibérément percés au travers, et que chacun est examiné isolément par celui qui possède ce compte, de sorte que personne n'examine la chaîne dans son ensemble. La relation de confiance commode de l'équipe dev et le rôle partagé de l'équipe plateforme sont chacun raisonnables, et ensemble ils forment une route qu'aucune des deux équipes ne peut voir depuis sa position. L'examen isolé manque les chemins inter-comptes pour la même raison qu'il manque l'escalade IAM. Le risque réside dans la façon dont les rôles se connectent, et examiner un rôle à la fois ne le montre jamais.

Les outils qui le cartographient

Les outils fondés sur les graphes aident. PMapper et Cartography peuvent modéliser les rôles et les relations de confiance à travers les comptes, et AWS IAM Access Analyzer signale les accès externes à vos rôles, y compris la confiance inter-comptes que vous avez pu oublier. Ceux-ci vous donnent des liens candidats. La question restante est de savoir lesquelles de ces chaînes candidates se résolvent, tous les sauts, toutes les conditions, toutes les politiques de permissions en vigueur, jusqu'à quelque chose qui vous importe. Un lien de confiance qui ne mène vers rien de sensible est du bruit, et une chaîne de quatre sauts jusqu'à vos données de production est celle que vous devez corriger.

Comment briser la chaîne

Comme pour tout chemin, couper un seul lien suffit. Remplacez les principaux de compte racine dans les politiques de confiance par des ARN de rôle exacts. Exigez un external ID ou une condition aws:SourceArn sur chaque rôle tiers. Supprimez la confiance inter-comptes qui ne sert plus à rien, les rôles de fournisseurs dormants sont une trouvaille courante. Là où vous le pouvez, utilisez des service control policies pour empêcher des catégories entières de comptes d'endosser des rôles sensibles. Puis alertez sur les appels AssumeRole vers les rôles critiques provenant de sources inattendues.

Le jugement à porter, c'est de savoir quel lien couper. Le bon lien sectionne la route de l'attaquant sans toucher à quoi que ce soit de légitime, et le mauvais casse un pipeline. Cela exige de savoir où mène chaque chaîne.

Comment Pathbreak l'aborde

Pathbreak construit le graphe de confiance complet à travers vos comptes AWS et le traite comme un seul espace connecté, à la manière d'un attaquant. Il résout chaque saut AssumeRole par rapport aux politiques de confiance, politiques de permissions et conditions réelles, puis confirme quelles chaînes atteignent les actifs les plus critiques tels que les données de production, les sauvegardes ou la gestion de l'organisation. Il fonctionne en lecture seule, de sorte que cartographier votre confiance n'y touche jamais.

Pour chaque chaîne qui se résout, Pathbreak montre les sauts et pointe vers le seul lien de confiance qui le brise, généralement une politique de confiance trop large ou un rôle de fournisseur oublié. Vous pouvez voir les chaînes que nous couvrons sur la page chemins d'attaque, les mécanismes sur comment ça marche, et la manière dont nous gérons l'accès au moindre privilège sur la page Confiance et sécurité. Pour savoir comment le même raisonnement s'applique à l'intérieur d'un seul compte, voyez notre article sur l'escalade de privilèges IAM AWS.

Questions fréquentes