AWS Angriffe auf kontenübergreifendes Vertrauen: Wie Role Chaining die Crown Jewels erreicht

Vom Pathbreak-Team · 11. August 2026 · 6 Min. Lesezeit

AWS mit mehreren Konten ist die empfohlene Art, eine große Umgebung zu betreiben, und kontenübergreifende IAM-Rollen sind das, was sie zusammenhält. Ein Security-Konto liest Logs aus jedem Workload-Konto. Ein Shared-Services-Konto deployt in andere. Ein Anbieter übernimmt eine Rolle, um sein Produkt zu betreiben. All das ist kontenübergreifendes Vertrauen, das wie vorgesehen funktioniert.

Es ist auch die Karte, der ein Angreifer folgt. Landen Sie in einem Konto, suchen Sie nach einer Rolle, die Sie im nächsten übernehmen können, und wiederholen Sie das. Dieser Beitrag behandelt, wie kontenübergreifendes Vertrauen missbraucht wird, wie Role Chaining die Crown Jewels erreicht und wie man den Pfad mit einer einzigen Änderung unterbricht.

Wie kontenübergreifendes Vertrauen funktioniert

Jede IAM-Rolle hat zwei Policies. Die Permission-Policy sagt, was die Rolle tun kann. Die Trust-Policy, die Assume-Role-Policy, sagt, wer sie werden darf. Um in eine Rolle zu wechseln, ruft ein Principal sts:AssumeRole auf und erhält temporäre Zugangsdaten, solange die Trust-Policy der Zielrolle diesen Principal zulässt und der Aufrufer die sts:AssumeRole-Berechtigung hat.

Die Trust-Policy steuert, wer hineinkommt, sodass kontenübergreifende Sicherheit davon abhängt, wie präzise Sie die Principals benennen, die Sie zulassen.

Wo Vertrauen schiefgeht

Wildcard-Principals in Trust-Policies

Die gefährlichste und am meisten missverstandene Trust-Policy ist ein Wildcard-Principal. Eine Anweisung, die "Principal": { "AWS": "*" } mit "Action": "sts:AssumeRole" zulässt, bedeutet nicht jede Identität in Ihrem Konto. Sie öffnet die Rolle für jedes AWS-Konto der Welt. Es gibt eine zweite Voraussetzung, die aufrufende Identität muss ebenfalls die sts:AssumeRole-Berechtigung auf der Rolle haben, aber genau deshalb ist der Wildcard ein praktisches Risiko: ein Angreifer gewährt sich diese Berechtigung in seinem eigenen AWS-Konto selbst, sodass er die zweite Voraussetzung gratis mitbringt. Teams lesen den Wildcard als "jeder in meinem Team" und liefern ihn aus. Was sie veröffentlicht haben, ist eine Rolle, die jeder Angreifer aus einem von ihm kontrollierten Konto übernehmen kann. Bei einer Rolle mit relevanten Berechtigungen gibt das alles her, was die Rolle tun kann. Wenn Sie wirklich einen breiten Principal brauchen, schränken Sie ihn mit einer Condition wie aws:PrincipalAccount oder aws:PrincipalOrgID ein, und besser noch, benennen Sie die exakten Rollen-ARNs, denen Sie vertrauen wollen.

Der Confused Deputy bei Rollen von Drittanbietern

Wenn Sie einem SaaS-Anbieter erlauben, eine Rolle in Ihrem Konto zu übernehmen, nutzt dieser Anbieter ein AWS-Konto, um viele Kunden zu bedienen. Wenn Ihre Trust-Policy nur das Konto des Anbieters benennt, könnte ein anderer Kunde des Anbieters ihn dazu verleiten, Ihre Rolle zu übernehmen. Die Lösung ist eine External ID, ein geteiltes Geheimnis in der Condition, oder eine aws:SourceArn- oder aws:SourceAccount-Condition, die die Übernahme an Ihre spezifische Beziehung bindet. Eine Drittanbieter-Rolle ohne eine solche ist eine klassische Confused-Deputy-Exposure.

Role Chaining über Konten hinweg

Ein Sprung erreicht selten das Ziel, also verketten reale Pfade. Der Angreifer übernimmt eine Rolle im Dev-Konto, der zufällig eine Rolle im Shared-Services-Konto vertraut, die eine Rolle in der Produktion übernehmen kann, die die Datenbank-Zugangsdaten im Secrets Manager lesen kann. Vier legitime sts:AssumeRole-Aufrufe, und ein Fuß in der Tür im unwichtigsten Konto ist zum Zugriff auf die wichtigsten Daten geworden.

Was das Verketten gefährlich macht, ist, dass jeder Sprung autorisiert ist, nichts ausgenutzt wird und die Zugangsdaten temporär und erwartet sind. Für CloudTrail sieht es aus, als täten Rollen ihre Arbeit. Die einzige Möglichkeit, die Gefahr zu sehen, ist, die gesamte Kette auf einmal zu betrachten und zu fragen, wo sie endet, statt jede Vertrauensbeziehung für sich zu beurteilen.

AWS fügt durchaus Reibung hinzu. Verkettete Rollensitzungen sind auf eine Stunde begrenzt und können nicht durch weiteres Verketten erneuert werden. Das begrenzt die Sitzungsdauer, aber es schließt den Pfad nicht.

Warum Kontengrenzen sicherer wirken, als sie sind

Teams behandeln die Kontengrenze als Sicherheitsgrenze, und sie ist eine gute für den Blast Radius. Das Problem ist, dass kontenübergreifende Rollen absichtlich durch sie hindurchgebohrt werden, und jede wird isoliert von demjenigen geprüft, dem dieses Konto gehört, sodass niemand die Kette als Ganzes prüft. Die bequeme Vertrauensbeziehung des Dev-Teams und die geteilte Rolle des Plattform-Teams sind jede für sich vernünftig, und zusammen bilden sie eine Route, die keines der beiden Teams von seinem Standpunkt aus sehen kann. Eine isolierte Prüfung übersieht kontenübergreifende Pfade aus demselben Grund, aus dem sie IAM-Eskalation übersieht. Das Risiko liegt darin, wie die Rollen zusammenhängen, und eine Rolle nach der anderen zu prüfen zeigt das nie.

Tools, die es kartieren

Graphbasierte Tools helfen. PMapper und Cartography können Rollen und Vertrauensbeziehungen über Konten hinweg modellieren, und AWS IAM Access Analyzer meldet externen Zugriff auf Ihre Rollen, einschließlich kontenübergreifenden Vertrauens, das Sie vielleicht vergessen haben. Diese geben Ihnen Kandidatenkanten. Die verbleibende Frage ist, welche dieser Kandidatenketten sich auflösen, alle Sprünge, alle Conditions, alle in Kraft befindlichen Permission-Policies, zu etwas, das Ihnen wichtig ist. Eine Trust-Edge, die ins Nichts Sensibles führt, ist Rauschen, und eine Vier-Sprung-Kette zu Ihren Produktionsdaten ist die, die Sie beheben müssen.

Wie man die Kette unterbricht

Wie bei jedem Pfad genügt es, eine Kante zu durchtrennen. Ersetzen Sie Root-Konto-Principals in Trust-Policies durch exakte Rollen-ARNs. Fordern Sie eine External ID oder eine aws:SourceArn-Condition bei jeder Drittanbieter-Rolle. Löschen Sie kontenübergreifendes Vertrauen, das keinen Zweck mehr erfüllt, ruhende Anbieter-Rollen sind ein häufiger Fund. Wo Sie können, nutzen Sie Service Control Policies, um ganze Klassen von Konten daran zu hindern, sensible Rollen zu übernehmen. Alarmieren Sie dann bei AssumeRole-Aufrufen in kritische Rollen aus unerwarteten Quellen.

Die Ermessensentscheidung ist, welche Kante zu durchtrennen ist. Die richtige Kante durchtrennt die Route des Angreifers, ohne etwas Legitimes zu berühren, und die falsche bricht eine Pipeline. Das erfordert zu wissen, wohin jede Kette führt.

Wie Pathbreak es angeht

Pathbreak baut den vollständigen Trust-Graphen über Ihre AWS-Konten hinweg und behandelt ihn als einen zusammenhängenden Raum, so wie es ein Angreifer tut. Es löst jeden AssumeRole-Sprung gegen die realen Trust-Policies, Permission-Policies und Conditions auf und bestätigt dann, welche Ketten Crown Jewels wie Produktionsdaten, Backups oder Organisationsverwaltung erreichen. Es arbeitet read-only, sodass das Kartieren Ihres Vertrauens es nie berührt.

Für jede Kette, die sich auflöst, zeigt Pathbreak die Sprünge und weist auf die eine Trust-Edge hin, die sie unterbricht, meist eine zu breite Trust-Policy oder eine vergessene Anbieter-Rolle. Die Ketten, die wir abdecken, sehen Sie auf der Seite Angriffspfade, die Mechanik unter So funktioniert es und wie wir mit Least-Privilege-Zugriff umgehen, auf der Seite Trust und Sicherheit. Wie dieselbe Logik innerhalb eines einzigen Kontos gilt, sehen Sie in unserem Beitrag über AWS IAM Privilege Escalation.

Häufig gestellte Fragen