Angriffspfadanalyse vs. Angriffspfadvalidierung in AWS

Vom Pathbreak-Team · 22. Oktober 2026 · 8 Min. Lesezeit

Die Angriffspfadanalyse findet die Ketten aus Berechtigungen, Vertrauensbeziehungen und Expositionen, über die ein Angreifer in AWS von einem Einstiegspunkt zu einem Ziel gelangen könnte. Die Angriffspfadvalidierung prüft jede dieser Ketten gegen die Autorisierung, die AWS bei jedem Aufruf auswertet, und behält die Ketten, die funktionieren.

Statt einer Liste von 3,000 isolierten Problemen liefert die Analyse Ketten: Diese öffentliche Instanz hält diese Rolle, diese Rolle kann jene Rolle an Lambda übergeben, jene Rolle ist ein Administrator. Die meisten Cloud-Security-Plattformen bieten inzwischen eine Form davon an, und gegenüber nach Schweregrad sortierten Listen ist das ein großer Fortschritt.

Die Validierung ist der Schritt nach der Analyse. In AWS ist das eine schwierigere Frage, als sie aussieht, weil an jeder Entscheidung mehrere Arten von Policies beteiligt sind, und die beiden Antworten gehen weiter auseinander, als die meisten Teams erwarten.

Was die Angriffspfadanalyse leistet

Die Analyse beginnt mit einem Inventar: Principals, Rollen, Policies, Vertrauensbeziehungen, Compute, Storage und die Netzwerkkanten dazwischen. Sie baut einen Graphen und durchsucht ihn dann nach Routen, die bei etwas Sensiblem enden, einer Administratorrolle, einer Produktionsdatenbank, einem Bucket mit Kundendaten. Jeder Hop ist eine bekannte Technik. iam:PassRole zusammen mit lambda:CreateFunction ist ein Hop. sts:AssumeRole in ein vertrauendes Konto ist ein Hop. Eine öffentliche Function URL ist ein Einstiegspunkt.

Das Ergebnis ist eine Menge von Kandidatenpfaden. Es sind Kandidaten, weil der Graph aus den Policy-Dokumenten gebaut wurde, wie sie geschrieben stehen, und eine Identity Policy für sich genommen nicht verrät, was AWS entscheiden wird, wenn der Aufruf erfolgt.

Wo die Analyse endet

AWS wertet jeden API-Aufruf gegen mehrere Dokumente gleichzeitig aus, und jedes einzelne davon kann aus einem Allow ein Deny machen. Ein Pfad, der im Graphen existiert, kann durch jedes der folgenden blockiert werden:

• Service Control Policies. Eine SCP auf der Organisationseinheit kann lambda:CreateFunction für die gesamte OU verweigern, und keine Identity Policy darin kann das außer Kraft setzen.
• Permission Boundaries. Eine Boundary auf dem Quell-Principal begrenzt, was dessen Identity Policies gewähren können. Fehlt iam:PassRole in der Boundary, scheitert die Übergabe, obwohl die Identity Policy sie erlaubt.
• Trust Policies. Die Zielrolle muss dem Service oder Principal vertrauen, auf den der Hop angewiesen ist. Eine Rolle, die lambda.amazonaws.com nicht vertraut, lässt sich nicht an Lambda übergeben, ganz gleich, was der Aufrufer besitzt.
• Resource Policies. Der Bucket, der Schlüssel, die Queue oder die Funktion am Ende des Pfads hat eine eigene Policy, und die kann den Principal verweigern, als der die Kette dort ankommt.
• Condition Keys. iam:PassedToService, aws:SourceAccount, aws:PrincipalOrgID und die sts:ExternalId-Prüfung engen eine Berechtigung ein, die in der Aktionsliste breit aussieht.
• Explizite Denies. Ein Deny-Statement an irgendeiner Stelle der Auswertung gewinnt gegen jedes Allow, und es steht oft in einer anderen Policy als der, die der Graph gelesen hat.

Jedes einzelne dieser Dokumente zu lesen ist einfach. Die Arbeit besteht darin, alle zusammen aufzulösen, in der Reihenfolge, in der AWS es tut, für jeden Schritt jeder Kette, und genau dieser Schritt trennt einen Kandidatenpfad von einem bewiesenen. Lässt man ihn aus, ist die Liste lang, und ein großer Teil davon würde schon beim ersten Aufruf scheitern.

So validieren Sie einen Cloud-Angriffspfad in AWS

Nehmen wir eine verbreitete Kette. Eine CI-Rolle namens ci-deploy besitzt iam:PassRole auf eine Rolle namens data-pipeline, dazu lambda:CreateFunction und lambda:InvokeFunction. Die Rolle data-pipeline hat AdministratorAccess. Im Graphen ist das ein Pfad mit zwei Hops von der CI-Rolle zum Administrator: eine Funktion mit angehängter Rolle data-pipeline erstellen, sie aufrufen, und der Code der Funktion läuft als Administrator.

Die Analyse markiert den Pfad als erreichbar. Die Validierung geht ihn dann Prüfung für Prüfung durch:

1. Erlaubt die Identity Policy von ci-deploy iam:PassRole auf den ARN von data-pipeline oder auf einen Wildcard, der ihn abdeckt? Ja, auf arn:aws:iam::*:role/data-*.
2. Wird die Übergabe durch iam:PassedToService eingeschränkt? Es ist keine Condition vorhanden, also wird jeder Service akzeptiert.
3. Vertraut die Trust Policy von data-pipeline dem Service lambda.amazonaws.com? Ja, die Rolle wurde für eine Lambda-basierte Pipeline angelegt.
4. Verweigert eine SCP auf der OU des Kontos lambda:CreateFunction oder iam:PassRole? Die OU hat eine SCP, und sie verweigert keines von beiden.
5. Schließt eine Permission Boundary auf ci-deploy eine der beiden Aktionen aus? Die Rolle hat keine Boundary.
6. Erreicht die Ausführung der Funktion etwas Relevantes? data-pipeline ist ein Administrator, die Antwort lautet also: alles im Konto, und über zwei kontoübergreifende Vertrauensbeziehungen zwei weitere Konten.

Jede Prüfung ist bestanden, der Pfad ist also bewiesen. Es wurde keine Funktion erstellt und nichts aufgerufen. Jeder Schritt hat dieselben Dokumente aufgelöst, die AWS auflösen würde, in derselben Reihenfolge, und dieselbe Entscheidung geliefert. Das bedeutet Validierung in der Control Plane. Der Exploit ist eine Berechtigung, also ist der Beweis das Ergebnis der Autorisierung.

Der Fix ergibt sich aus Schritt zwei. Die engste Änderung besteht darin, der PassRole-Berechtigung iam:PassedToService hinzuzufügen, damit nur der vorgesehene Service die Rolle erhalten kann, oder den Wildcard-ARN durch die eine Rolle zu ersetzen, die CI braucht. Nach der Änderung laufen dieselben sechs Prüfungen erneut, und Schritt zwei schlägt fehl. Der Pfad ist weg, und die Bestätigung wird neben dem Finding festgehalten. Der Karteneintrag zu dieser Kette enthält die CloudTrail-Events und die vollständige Beschreibung.

Ist die Validierung von Angriffspfaden in der Produktion sicher?

Ja, wenn die Validierung schreibgeschützt läuft. Pathbreak verbindet sich über eine schreibgeschützte IAM-Rolle mit minimalen Rechten, die Sie anlegen und jederzeit widerrufen können. Jeder Aufruf ist ein Lesezugriff (Get, List und Describe), und die Autorisierung für jeden Schritt wird aus den Policy-Dokumenten aufgelöst, die diese Aufrufe zurückgeben. Es wird keine Funktion erstellt, keine Rolle im Pfad übernommen und keine Ressource geändert, sodass Produktions-Workloads unverändert weiterlaufen.

Die Rollensitzung und ihre Lesezugriffe erscheinen in CloudTrail als Management-Events unter der Pathbreak-Rolle, was die Aktivität leicht prüfbar macht. Pathbreak liest Konfiguration, auch an den Stellen, an denen Zugangsdaten häufig offenliegen, etwa in Instanz-User-Data, Umgebungsvariablen von Funktionen und Stack-Outputs. Den Inhalt von Objektspeichern oder Datenbanken liest Pathbreak nicht.

Die schreibgeschützte Validierung beantwortet für jeden Schritt eine Frage: Würde AWS diesen Aufruf für diesen Principal autorisieren? Sie testet keinen Anwendungscode, keine Exploits gegen laufende Hosts und nicht, ob Erkennung und Reaktion einen Angreifer bemerken würden. Das deckt ein manuelles AWS-Sicherheitsassessment ab, und Pathbreak läuft ergänzend dazu. Manche Tools validieren, indem sie Angriffsschritte in der Umgebung ausführen, und dieser Vergleich zeigt, wann welcher Ansatz passt.

Warum der Unterschied entscheidet, was Sie zuerst beheben

Pfade nach Auswirkung zu sortieren funktioniert nur, wenn die Pfade real sind. Eine Liste, die bewiesene Ketten mit Ketten mischt, die eine SCP bereits blockiert, treibt Teams zu Arbeit, die nichts verändert. Im Pathbreak-Laborkonto lieferte die Analyse 4,942 Kandidatenpfade. Nach Validierung und Sortierung nach Blast Radius beseitigte ein einziges Deny auf einer Rolle 3,893 der 4,087 verbleibenden Pfade, und zwei Änderungen zusammen beseitigten 80 Prozent des Risikos im Konto. Diese Reihenfolge wird erst sichtbar, wenn jeder Pfad gegen die tatsächliche Autorisierung aufgelöst wurde.

Wie Pathbreak vorgeht

Pathbreak baut den Graphen, leitet daraus Kandidatenketten ab und validiert dann jede Kette Ende zu Ende, indem es die Autorisierung auflöst, die AWS auswerten würde: Identity und Resource Policies, Trust Policies, SCPs, Boundaries und Conditions. Der Zugriff ist schreibgeschützt, und nichts wird ausgeführt. Jeder validierte Pfad wird danach sortiert, was er erreicht, und kommt mit der konkreten Änderung, die ihn unterbricht. Nachdem die Änderung ausgerollt ist, wird der Pfad erneut ausgewertet und das Ergebnis festgehalten, sodass der Fix mit Belegen bestätigt ist.

Häufig gestellte Fragen