Un rôle d'instance EC2 est configuré sur `*:*` (administrateur complet) « pour que ça marche ». Pourquoi est-ce dangereux et que faites-vous ?
Réponse courte
Un rôle d'instance surprivilégié transforme la moindre faille applicative — notamment une SSRF atteignant le service de métadonnées d'instance — en prise de contrôle complète du compte, car l'attaquant hérite des identifiants du rôle. Remplacez le wildcard par les seules actions et ARN de ressources réellement utilisés par la charge de travail, et imposez IMDSv2 pour durcir le point de terminaison de métadonnées. Un VPC ne contraint en rien l'IAM. Une seule règle de refus relève du jeu de la taupe et laisse tout le reste autorisé. Un répartiteur de charge n'a aucun rapport avec la portée d'impact de l'identifiant.
Ce scénario vérifie si un ingénieur senior comprend la portée d'impact : la question n'est pas de savoir si l'instance est joignable, mais ce qu'un attaquant obtient dès qu'il prend n'importe quel point d'appui. Un rôle *:* signifie qu'un seul bug équivaut à tout le compte.
Pourquoi le moindre privilège est la réponse
Les identifiants d'un rôle d'instance sont accessibles à tout ce qui s'exécute sur l'instance (ou peut la forcer à agir). Le chemin classique est la SSRF : une application que l'on peut tromper pour qu'elle envoie une requête vers http://169.254.169.254/... renverra les identifiants temporaires du rôle. Si le rôle est administrateur, l'attaquant contrôle désormais l'ensemble du compte — lire chaque bucket, créer des utilisateurs, désactiver la journalisation et pivoter. Réduire le rôle aux actions et ARN de ressources spécifiques utilisés par la charge de travail fait qu'une SSRF même parfaite ne donne que ce que cette charge pouvait déjà faire. Imposer IMDSv2 (à base de jeton, avec une limite de saut) rend le point de terminaison de métadonnées bien plus difficile à atteindre par SSRF.
Pourquoi les distracteurs échouent
- « Correct tant que c'est dans un VPC. » Un VPC est une isolation réseau ; il ne contraint pas l'IAM. Les identifiants volés fonctionnent contre les points de terminaison publics de l'API AWS, peu importe où se trouve l'instance.
- Ajouter une règle de refus. Refuser une seule action risquée laisse des milliers d'autres actions privilégiées autorisées. Le moindre privilège est une liste d'autorisations, pas un jeu de la taupe.
- La placer derrière un répartiteur de charge. Un répartiteur de charge modifie la façon dont le trafic atteint l'application ; il ne change rien à ce que l'identifiant fuité peut faire.
Ce que recherchent les examinateurs
Nommer la SSRF + le service de métadonnées comme chemin d'exploitation réaliste, insister sur un moindre privilège en liste d'autorisations plutôt que des correctifs de refus, et ajouter IMDSv2 en défense en profondeur. Un candidat senior mentionne aussi comment dériver la politique minimale en toute sécurité — par exemple en exécutant dans un compte hors production avec IAM Access Analyzer ou une génération de politique pilotée par CloudTrail avant de resserrer.
Questions de suivi probables
- Comment une SSRF contre le service de métadonnées exfiltre-t-elle exactement les identifiants du rôle, et comment IMDSv2 brise-t-il cette chaîne ?
- Comment dériveriez-vous la politique minimale sans casser la charge de travail ?
- Quelle est la différence de portée d'impact entre un rôle surprivilégié et un utilisateur surprivilégié ?