Un inventaire IAM ne répond pas à la bonne question
Dans un seul compte, demander qui peut faire quoi est déjà difficile. Dans AWS Organizations, la question change de forme: qui peut atteindre quoi, via quels rôles, depuis quel compte, avec quel résultat pratique.
Des politiques documentées, des permissions attachées et des trust policies existent. Ce qui manque souvent est le graphe des chemins effectifs entre elles. Un sts:AssumeRole bien intentionné dans un compte membre peut être le prochain saut depuis une identité que personne n’a revue comme un tout.
Le risque n’apparaît pas toujours comme une politique JSON surdimensionnée. Il apparaît comme une chaîne.
Pourquoi les organisations multi-comptes cachent des chemins
AWS Organizations introduit une confiance structurelle: rôles d’accès cross-account, comptes de management, SCP, administrateurs délégués, Identity Center, Access Analyzer à l’échelle de l’org. Chaque pièce a du sens seule. Ensemble elles définissent un périmètre rarement dessiné en entier.
Schémas fréquents dans les revues:
- trust policies larges ou conditions faibles entre comptes
- jump roles utilisés par pipelines ou vendors qui accumulent de la portée
- privilèges du compte de management non soumis aux mêmes SCP que les membres
- chemins qui n’apparaissent que lorsque l’inventaire IAM est combiné aux relations d’organisation
Sans cette carte, les équipes sécurité répondent par des contrôles locaux. Un attaquant, ou un auditeur, pense en routes.
Ce que contribue STRAP
STRAP est du tooling interne TechRebel pour analyser les chemins d’attaque à l’échelle d’une organisation AWS. Nous l’utilisons dans les engagements de sécurité cloud et le mettons à disposition des clients lorsque le problème est de comprendre l’accès effectif au-delà d’un seul compte.
Il ne remplace pas IAM Access Analyzer ni un inventaire de politiques. Il complète ces sources par une lecture orientée chemins: d’identité à identité, de compte à compte, jusqu’aux privilèges qui comptent pour le métier.
La sortie utile n’est pas une liste infinie de findings. C’est un ensemble priorisé de routes qui expliquent comment quelqu’un avec un point d’appui en un lieu peut en atteindre un autre.
Comment cela s’inscrit dans un engagement
Dans le travail AWS & Cloud Security nous partons généralement de trois couches:
- posture et couverture (comptes, régions, logging, contrôles de base)
- accès effectif (rôles, trusts, chemins cross-account)
- priorisation (quelles routes comptent et quelles remédiations sont réalistes)
STRAP alimente surtout la deuxième. Il aide à passer de « nous avons beaucoup de politiques » à « voici les routes à couper en premier ».
Ce que nous ne promettons pas
Aucun outil ne supprime la complexité d’une grande organisation AWS. STRAP n’invente pas une posture sécurisée à lui seul. Il dépend d’un périmètre de lecture convenu et de credentials, de la qualité de l’inventaire et de décisions humaines sur ce qu’il faut corriger.
Sa valeur est de rendre visibles des chemins que la conception compte par compte tend à laisser hors radar.
Pour revoir l’accès effectif dans votre organisation AWS, planifiez une réunion ou voyez plus de contexte sur Research.