Amazon Web Services (AWS) gilt als einer der weltweit führenden Anbieter von Cloud-Infrastrukturen und -dienstleistungen. Die Sicherheit seiner Plattform gehört zu den obersten Prioritäten des Unternehmens. Doch überraschenderweise hat ein von AWS entwickeltes Sicherheitswerkzeug, das eigentlich dazu gedacht ist, das Risiko bei der Verwaltung von Zugriffsrechten zu minimieren, unbeabsichtigte Sicherheitslücken geschaffen. Die Analyse dieses Tools, bekannt als Account Assessment für AWS Organizations, zeigt ein komplexes Sicherheitsdilemma auf, das viele Organisationen betrifft und zur Entwicklung besserer Sicherheitspraktiken zwingt. Das Herzstück des Problems liegt in der Art und Weise, wie das Tool implementiert und bereitgestellt wurde.
Das Tool wurde entworfen, um AWS-Konten innerhalb einer Organisation zentral zu überprüfen, indem es die Berechtigungen und Ressourcenrichtlinien analysiert. Anwender sollten so einen besseren Überblick über Cross-Account-Zugriffe erhalten – eine der komplexesten und häufig problematischen Sicherheitsaspekte in Multi-Account-Umgebungen. Ironischerweise führte die von AWS vorgegebene Empfehlung zur Bereitstellung des „Hub“-Rollenstapels in einem nicht sicherheitskritischen Konto dazu, dass die Vertrauensbeziehungen zwischen Konten unsicher wurden. Diese Empfehlung sah vor, den Hub-Stack ausschließlich in einem Mitgliedskonto der Organisation zu installieren, jedoch nicht im Management-Konto, das normalerweise die höchste Sicherheitsstufe besitzt und Zugriffe zentral verwaltet. Die Folge dieser Vorgehensweise war, dass das Hub-Account in einem Konto mit vergleichsweise schwächeren Sicherheitskontrollen eingerichtet wurde, etwa einem Entwicklungs- oder Sandbox-Konto.
Diese Wahl führte dazu, dass über den Hub eine Vertrauensbrücke zwischen schwächer geschützten und hochsensiblen Umgebungen entstand. In der Praxis bedeutet das, dass ein Angreifer, der es schafft, sich Zugang zu einer weniger sicheren Umgebung, etwa einem Entwicklungs-Konto, zu verschaffen, über das Hub-Rollenmodell direkten Zugriff auf wesentlich sensiblere Konten wie Produktions- oder Management-Konten gewinnen kann. Aufgrund der umfangreichen Rechte, die das Tool für seine Analyse benötigt, konnten so privilegierte Aktionen übernommen, sensible IAM-Rollen ausgespäht und Datenquellen wie S3-Buckets oder Secrets-Manager-Informationen eingesehen werden. Zudem waren auch kryptografische Schlüssel in den Zugriff involviert, was das Risiko von weiterführenden Angriffen und Privilegienerweiterungen verstärkte. Eine besonders beunruhigende Erkenntnis dieses Problems ist, dass es sich nicht um eine individuelle Fehlkonfiguration einzelner Kunden handelt, sondern um eine durch die AWS-Dokumentation praktisch vorgegebene und somit von vielen Anwendern unbewusst übernommene Praxis.
Die Anleitung verfügte zu keinem Zeitpunkt über eine explizite Warnung vor den sicherheitstechnischen Konsequenzen der empfohlenen Bereitstellungsstrategie. Diese Lücke offenbart, dass technologische Werkzeuge allein nicht ausreichen, sondern gerade auch klare, sicherheitsorientierte Dokumentationen und Vorgehensweisen unerlässlich sind. Die Entdeckung dieses Problems erfolgte durch eine Sicherheitsexpertengruppe, die beim Überprüfen eines eskalierenden Berechtigungsrisikos feststellte, dass die Rollenstruktur auf eine Fehlkonfiguration zurückzuführen ist, die durch das AWS-Tool eingeführt wurde. Ihre Untersuchung zeigte, dass sofortige Maßnahmen notwendig waren und die Sicherheitskommunikation an AWS weitergeleitet wurde. In reagierender Weise nach Rücksprache und Prüfung der vorgebrachten Erkenntnisse änderte AWS im Januar 2025 die Dokumentation.
Fortan wurde empfohlen, den Hub-Stack ausschließlich in einem Konto mit Sicherheitslevel wie dem Management-Konto zu installieren, sprich in einem gesicherten Infrastruktur- oder DevOps-Konto. Die damit verbundenen Empfehlungen für betroffene Organisationen sind vielschichtig. Zunächst sollten Unternehmen ihre Kontenstruktur untersuchen und vorhandene Deployments des Account Assessment Tools überprüfen, um festzustellen, ob eine unsichere Implementierung vorliegt. Dies lässt sich über eine manuelle Inspektion der IAM-Rollen oder automatisierte Abfragen über die AWS CLI durchführen. Insbesondere das Vorhandensein von Rollen, die mit „ScanSpokeResource“ oder „AccountAssessment-Spoke-ExecutionRole“ im Namen gekennzeichnet sind, weist auf eine Installation hin.
Wurde die unsichere Konfiguration vor dem 28. Januar 2025 vorgenommen und nicht angepasst, besteht dringender Handlungsbedarf. Die Empfehlung lautet, das Tool zu deinstallieren oder zumindest in einem hochgesicherten Konto neu bereitzustellen. Die Migration sollte sorgfältig geplant sein, um keine weiteren Angriffsflächen zu öffnen. Dabei sind CloudFormation-Stacks zu entfernen und die Berechtigungen restriktiver zu gestalten.
Für viele Unternehmen bedeutet dies eine Gelegenheit zur Überprüfung und Verbesserung der gesamten Multi-Account-Sicherheitsarchitektur. Zugriffswege sollten klar strukturiert und strikt nach dem Prinzip der geringsten Privilegien ausgestaltet sein. Zudem zeigt der Fall exemplarisch, wie wichtig die Sensibilisierung für Vertrauensbeziehungen innerhalb der AWS-Umgebung ist und dass selbst große Anbieter nicht frei von Konfigurationsfehlern sind. Abschließend lässt sich sagen, dass die AWS Account Assessment Tool Problematik ein lehrreiches Beispiel für die Herausforderungen moderner Cloud-Sicherheitsstrategien darstellt. Automatisierte Werkzeuge können helfen, Risiken zu erkennen und zu reduzieren, doch sind sie gleichzeitig selbst potenzielle Sicherheitsfaktoren, wenn sie nicht verantwortungsvoll implementiert und dokumentiert werden.
Unternehmen sollten stets eine ganzheitliche Herangehensweise verfolgen, die technische Aspekte mit organisatorischen Kontrollen und sachkundiger Dokumentation vereint. Darüber hinaus unterstreicht dieser Fall die Bedeutung transparenter Kommunikation zwischen Sicherheitsforschern, Anbietern und Kunden. Die schnelle Reaktion von AWS und die Anpassung der Dokumentation zeigen, dass Kooperationen essenziell sind, um Sicherheitslücken schnell zu schließen und Vertrauen in Cloud-Services zu stärken. Für Organisationen im AWS-Ökosystem ist es daher empfehlenswert, kontinuierlich Sicherheitsreports und Updates zu verfolgen, um auf dem neuesten Stand zu bleiben und potenzielle Risiken frühzeitig zu erkennen und zu beheben. Die Auseinandersetzung mit solchen Problemen fördert die Entwicklung eines tieferen Verständnisses für die Dynamik von Cloud-Sicherheitsarchitekturen und sensibilisiert für die Komplexität von Zugriffskontrollen sowie Vertrauensbeziehungen.
Mit zunehmender Verbreitung von Multi-Account-Setups und immer umfangreicheren Sicherheitsanforderungen wird eine solche proaktive Haltung immer entscheidender für den Schutz sensibler Unternehmensdaten und die Sicherstellung der Compliance. In Summe zeigt die Analyse des Account Assessment Tools von AWS, wie kritische Sicherheitsrisiken auch durch etablierte Anbieter und deren Werkzeuge entstehen können. Die Erkenntnisse aus diesem Fall bieten wertvolle Anhaltspunkte für Unternehmen, ihre Implementierungen zu hinterfragen, Sicherheitsprozesse zu verbessern und eine robustere Cloud-Sicherheitsstrategie zu etablieren.
