Eine EC2-Instanzrolle ist auf `*:*` (Vollzugriff/Admin) gesetzt, „damit es läuft". Warum ist das gefährlich und was tust du?
Kurzantwort
Eine überprivilegierte Instanzrolle macht jeden Fehler auf Anwendungsebene – insbesondere ein SSRF, das den Instance-Metadata-Service erreicht – zur vollständigen Konto-Übernahme, weil der Angreifer die Anmeldedaten der Rolle erbt. Ersetze den Wildcard durch die minimalen Aktionen und Ressourcen-ARNs, die die Workload tatsächlich nutzt, und erzwinge IMDSv2, um den Metadaten-Endpunkt zu härten. Ein VPC schränkt IAM überhaupt nicht ein. Eine einzelne Deny-Regel ist Whac-A-Mole und lässt alles andere erlaubt. Ein Load Balancer ist für den Schadensradius der Anmeldedaten irrelevant.
Dieses Szenario prüft, ob ein Senior-Engineer den Schadensradius versteht: Die Frage ist nicht, ob die Instanz erreichbar ist, sondern was ein Angreifer erhält, sobald er irgendeinen Fuß in die Tür bekommt. Eine *:*-Rolle bedeutet, dass ein einziger Bug gleich dem gesamten Konto ist.
Warum Least Privilege die Antwort ist
Die Anmeldedaten einer Instanzrolle stehen allem zur Verfügung, was auf der Instanz läuft (oder sie zu einer Aktion zwingen kann). Der klassische Pfad ist SSRF: Eine Anwendung, die sich dazu verleiten lässt, eine Anfrage an http://169.254.169.254/... zu stellen, gibt die temporären Anmeldedaten der Rolle zurück. Ist die Rolle Admin, kontrolliert der Angreifer nun das gesamte Konto – jeden Bucket lesen, Benutzer anlegen, Logging deaktivieren und weiterpivotieren. Die Rolle auf die konkreten Aktionen und Ressourcen-ARNs der Workload einzuschränken bewirkt, dass selbst ein perfektes SSRF nur das liefert, was diese eine Workload ohnehin durfte. IMDSv2 (Token-basiert, mit Hop-Limit) zu erzwingen macht den Metadaten-Endpunkt zudem deutlich schwerer per SSRF erreichbar.
Warum die Distraktoren scheitern
- „In Ordnung, solange es in einem VPC ist.“ Ein VPC ist Netzwerk-Isolation; es schränkt IAM nicht ein. Die gestohlenen Anmeldedaten funktionieren gegen die öffentlichen AWS-API-Endpunkte, egal wo die Instanz liegt.
- Eine Deny-Regel hinzufügen. Eine einzelne riskante Aktion zu verbieten lässt tausende andere privilegierte Aktionen erlaubt. Least Privilege ist eine Allow-Liste, kein Whac-A-Mole.
- Hinter einen Load Balancer stellen. Ein Load Balancer ändert, wie Traffic die App erreicht; an dem, was die geleakte Anmeldung tun kann, ändert er nichts.
Worauf Interviewer achten
SSRF + den Metadaten-Service als realistischen Exploit-Pfad zu nennen, auf Allow-Listen-basiertem Least Privilege statt Deny-Flickwerk zu bestehen und IMDSv2 als Defense in Depth hinzuzufügen. Ein Senior-Kandidat erwähnt zudem, wie man die minimale Policy sicher ableitet – etwa in einem Nicht-Prod-Konto mit IAM Access Analyzer oder CloudTrail-gestützter Policy-Generierung, bevor man verschärft.
Wahrscheinliche Anschlussfragen
- Wie exfiltriert ein SSRF gegen den Metadaten-Service genau die Rollen-Anmeldedaten, und wie bricht IMDSv2 diese Kette?
- Wie würdest du die minimale Policy ableiten, ohne die Workload zu zerstören?
- Worin unterscheidet sich der Schadensradius einer überprivilegierten Rolle von dem eines überprivilegierten Benutzers?