Cloud Pentesting: Methodik für IAM, Workloads und Cross-Service-Angriffspfade

Was Cloud Pentesting unterscheidet

Ein Netzwerk-Pentest fragt, welche Hosts und Dienste erreichbar sind und wo die Segmentierung nicht hält. Ein Web- oder API-Pentest fragt, was eine Anwendung mit Eingaben, Sessions und Objektzugriffen tut. Ein Active-Directory-Pentest liest die Domäne als Berechtigungsgraph. Cloud Pentesting verschiebt den Schwerpunkt auf die Control Plane und die cloud-nativen Vertrauensbeziehungen - auf die Ebene, über die Identitäten, Ressourcen und Dienste erzeugt, verbunden und gesteuert werden. Control Plane, Data Plane, Workloads, Netzwerk und Anwendung sind dabei keine starre Hierarchie, sondern miteinander verbundene Ebenen. Breite Kontrolle über die Control Plane kann aber weitreichende Kontrolle über darunterliegende Ressourcen und Dienste ermöglichen - unabhängig davon, wie gut ein einzelner Host gehärtet ist.

Prüfgegenstand sind deshalb nicht in erster Linie Betriebssysteme, sondern: das Identity- und Access-Management mit seinen cloud-nativen Berechtigungsmodellen, Managed Services ohne eigenes Betriebssystem, Ressourcenbeziehungen, Workload-Identitäten, Cross-Service- und Cross-Account-Trust, Cloud-Netzwerkkontrollen und die vom Provider gezogenen Grenzen. Eine VM in der Cloud wird selbstverständlich auch als Host geprüft - aber das ist der Netzwerk-Teil, nicht der Cloud-Teil. Der Cloud-Teil beginnt dort, wo diese VM eine Identität trägt, mit der sie Cloud-Ressourcen aufrufen kann.

Die allgemeine Methodik - Scope, Phasen, Risikobewertung, Reporting - steht im Grundlagenartikel. Hier geht es um das cloud-spezifische Vorgehen. Der rote Faden:

Shared Responsibility als Scope-Frage

Shared Responsibility ist im Pentest kein Lehrbuchkapitel, sondern eine Scope-Entscheidung: Es trennt, was der Auftraggeber freigeben kann, von dem, was er gar nicht freigeben darf, weil es ihm nicht gehört. Die Linie verläuft nicht zwischen "Cloud" und "nicht Cloud", sondern durch jeden einzelnen Dienst - je weiter ein Dienst "managed" ist, desto mehr davon liegt beim Provider.

Große Provider veröffentlichen eigene Regeln für Sicherheitstests. Je nach Provider, Dienst und Testart können Tests ohne Vorabgenehmigung zulässig, auf bestimmte Services beschränkt oder genehmigungspflichtig sein; diese Regeln ändern sich, deshalb wird die jeweils aktuelle Provider-Policy vor jedem Engagement geprüft. Der Umgang mit Provider-Freigaben, geteilter Infrastruktur und Drittanbietern ist im Scope-Artikel ausführlich beschrieben, inklusive der Tabelle zu Cloud, SaaS und Managed Hosting. Hier gilt nur die praktische Konsequenz: Ein Cloud-Scope wird über Accounts, Subscriptions, Projekte und Tags definiert, nicht über IP-Adressen, die sich morgen ändern.

Ausgangslagen

Keine andere Zielklasse hängt so stark von der Startposition ab wie die Cloud. Von außen ist ein gut konfigurierter Account fast unsichtbar; mit einer einzigen niedrigen Identität ist ein großer Teil des Berechtigungsmodells lesbar. Die Ausgangslage bestimmt deshalb nicht nur, wie tief der Test geht, sondern welche Angriffsfläche überhaupt relevant wird. Sie gehört vor dem ersten API-Aufruf festgelegt und in den Rules of Engagement dokumentiert.

In der Praxis ist Assumed Breach oder eine Standard-Identität meist der ehrlichere Startpunkt als die reine Außensicht: Die interessanten Cloud-Schwächen liegen fast immer im Berechtigungsmodell, und das ist von außen nicht sichtbar. Ein externer Test bleibt sinnvoll, um exponierte Ränder und die Übergänge aus Web und API zu prüfen - aber er beantwortet eine andere Frage.

Cloud IAM als Berechtigungsgraph

Der methodische Kern ist derselbe Perspektivwechsel wie im Active-Directory-Pentest: weg von einzelnen Berechtigungszuweisungen, hin zu einem Graphen aus Knoten und Beziehungen. Rechte in der Cloud entstehen selten aus einer Policy allein; sie entstehen aus der Kette von Identität, annehmbarer Rolle, Ressourcen-Policy, Trust-Beziehung und dem, was auf der Ressource liegt. Ein Angriffspfad ist eine Kette erreichbarer Kanten von der Ausgangsposition zu einem kritischen Ziel. Die Begriffe heißen je Provider anders - Rolle, Service Principal, Service Account, Managed Identity -, die Mechanik dahinter ist dieselbe.

Der Schwerpunkt liegt auf den Kanten. Eine typische Kette, die in fast jeder Cloud-Umgebung in irgendeiner Form existiert:

Jede Kante für sich ist unauffällig: Rollen sollen angenommen werden, Buckets sollen gelesen werden, Konfigurationen enthalten Zugänge. Erst die Verkettung macht aus einer Standard-Identität den Zugriff auf das kritische Ziel. Werkzeuge, die Cloud-Berechtigungsgraphen modellieren, machen solche Ketten sichtbar; welche sich eignen und welche Spuren sie im Audit-Log hinterlassen, ordnet der Tools-Bereich ein. Die Bewertung, welche Kante real nutzbar und im Scope ist, bleibt Operator-Arbeit.

Effektive Berechtigungen

Keine einzelne Policy beantwortet die Frage, was eine Identität wirklich darf. Die effektive Berechtigung ist das Ergebnis mehrerer Ebenen, die sich gegenseitig erweitern, einschränken oder aufheben - und die Fehler liegen fast immer dort, wo zwei Ebenen anders zusammenwirken als gedacht.

Provider-spezifische Policy-Syntax ist für die Methodik unerheblich. Entscheidend ist, dass der Operator jede dieser Ebenen kennt, für die relevanten Identitäten nachvollzieht und die Frage "Was darf diese Identity auf dieser Ressource wirklich?" belegt - durch Lesen der Konfiguration, durch Simulation, wo der Provider sie anbietet, oder durch eine minimale Testabfrage.

Enumeration

Enumeration in der Cloud heißt, das Berechtigungs- und Ressourcenmodell zu rekonstruieren, bevor irgendetwas angegriffen wird. Anders als im Netz gibt es keinen Portscan, der die Landkarte liefert; die Landkarte ist die Antwort der Control Plane auf die Frage, was die aktuelle Identität sehen darf. Wie viel eine Standard-Identität lesen darf, ist dabei eine wichtige Beobachtung; zum Finding wird sie erst, wenn die Sichtbarkeit oder Berechtigung über den vorgesehenen Bedarf hinausgeht oder einen relevanten Folgepfad ermöglicht.

Eine große CLI-Befehlssammlung braucht es dafür nicht; jeder Provider bietet dieselben Lesezugriffe über API, CLI und Konsole, und Werkzeuge zur Inventarisierung sind im Tools-Bereich eingeordnet. Wichtig ist das Ergebnis: ein Modell aus Identitäten, Rollen, Ressourcen und Trusts, in dem sich Kanten nachvollziehen lassen. Die systematische Aufklärung des erreichten Umfelds entspricht der Taktik Discovery; in der Cloud ist sie fast vollständig lesend und hinterlässt trotzdem ein klares Muster im Audit-Log.

Storage

Storage ist der Klassiker des Cloud-Pentests - und der Bereich, in dem am häufigsten falsch bewertet wird. "Bucket öffentlich" ist noch kein Finding, sondern eine Beobachtung. Ein öffentlicher Bucket mit den statischen Assets einer Website ist beabsichtigt; ein intern breit lesbarer Bucket mit dem Terraform-State der Produktivumgebung ist ein Angriffspfad, obwohl er nie öffentlich war.

• Öffentliche Ressourcen: Buckets, Objekte, Shares und Snapshots, die ohne Authentisierung erreichbar sind - prüfen, was dort liegt und ob es dort liegen soll.
• Falsch gesetzte Zugriffsrechte: Ressourcen-Policies, die "allen authentifizierten Nutzern" oder ganzen Accounts Zugriff geben.
• Interne Buckets, Objekte, Shares: nicht öffentlich, aber für zu viele interne Identitäten lesbar - der häufigste Fall in realen Umgebungen.
• Backups und Snapshots: enthalten oft das, was in der Quelle gut geschützt ist, mit schwächeren Rechten.
• Konfigurationen: Infrastructure-as-Code-Zustände, Deployment-Beschreibungen, Umgebungsdateien.
• Secrets in Storage: Keys, Tokens, Zertifikate in Objekten, die "nur intern" sind.
• Schreibrechte als Angriffspfad: Wer ein Skript, ein Image oder ein Deployment-Artefakt verändern darf, das später von einer privilegierten Workload ausgeführt wird, braucht keine Rechte auf der Workload selbst.
• Hosting- und Deployment-Artefakte: statische Sites, Build-Outputs, Container-Images, Funktions-Pakete - Lese- und Schreibrechte je getrennt bewerten.

Für jede Storage-Ressource werden dieselben vier Fragen gestellt: Was liegt dort? Wer kann zugreifen? Welche Rechte bestehen - lesen, auflisten, schreiben, löschen? Führt die Ressource zu weiteren Credentials oder Systemen? Erst die Antworten ergeben die Bewertung; die Bewertungsmatrix dafür steht im Abschnitt zu Secrets, weil beide Fragen zusammengehören.

Compute und Workloads

Workloads sind im Cloud-Pentest in erster Linie Träger von Identität. Eine virtuelle Maschine wird auf Host-Ebene mit der Netzwerk-Methodik geprüft, eine Anwendung darauf mit der Web- oder API-Methodik. Cloud-spezifisch ist die Frage: Welche Identität verwendet dieser Workload, welche Credentials sind von ihm aus erreichbar, welche Cloud-Ressourcen kann er aufrufen, und welche Rolle spielt er damit in einem Angriffspfad?

Kubernetes-Interna - RBAC, ServiceAccounts, Pod Security, Namespace-Isolation - werden hier bewusst nicht vertieft; ein Container ist in diesem Artikel nur ein Workload, der eine Cloud-Identität tragen kann. Die Cluster-Ebene ist Gegenstand eines eigenen, später folgenden Deep-Dives.

Metadata Services und Workload Credentials

Der wichtigste cloud-spezifische Übergang ist der vom Workload zur Control Plane. Er läuft über einen provider- und dienstspezifischen Metadata-, Identity- oder Credential-Endpunkt: eine Schnittstelle, die in der Regel workload-lokal ist, also nur aus dem Workload-Kontext erreichbar, und dem Workload seine Identität, seine Konfiguration und meist kurzlebige Credentials für die zugewiesene Rolle liefert. Manche Dienste nutzen dafür einen Metadata Service, andere eigene Identity-Endpunkte oder Credential-Provider der Laufzeit; auch die Schutzmechanismen unterscheiden sich. VM, Container, Function und App Service teilen deshalb nicht zwingend denselben Mechanismus - gemeinsam ist ihnen das Prinzip. Das ist Design und notwendig - Workloads müssen ohne fest eingebaute Secrets mit Cloud-Diensten sprechen können. Die Kernaussage: Eine Workload besitzt oder erhält eine Cloud-Identität; kann ein Angreifer diese Identität aus dem Workload-Kontext missbrauchen, entsteht der Übergang zur Control Plane.

Das Beispiel zeigt nur das Prinzip und keine Ausnutzungskette. Der Operator prüft nicht nur, ob ein Endpunkt erreichbar ist, sondern entscheidet entlang mehrerer Fragen: Welcher Endpunkt und welcher Diensttyp ist das überhaupt? Welche Request-Voraussetzungen gelten - Header, Token, Session-Mechanismen? Welche Netzwerk-, Hop- oder Proxy-Schutzmaßnahmen greifen davor? Liefert der Endpunkt überhaupt Credentials oder nur Konfiguration? Welche Identität liefert er, und was darf diese effektiv? Und: Wer kann im Workload Requests auslösen, die der Workload gar nicht stellen wollte?

Diese letzte Frage ist der Übergang aus dem Web-Pentest: Eine serverseitige Anwendung, die URLs von Nutzern abruft - Bildimport, Webhook, PDF-Erzeugung -, kann zum Zugang zum Metadata-Endpunkt werden. Die Mechanik und Verifikation von SSRF gehört in den Web-Pentesting-Artikel; hier ist SSRF nur der Übergabepunkt, an dem aus einer Anwendungsschwäche eine Cloud-Identität wird. Kurzlebige Credentials mindern das Risiko, heben es aber nicht auf: Innerhalb ihrer Gültigkeit tragen sie die vollen Rechte der Rolle, und ein Angreifer, der den Weg einmal kennt, holt sich neue. Wo erbeutete Credentials anschließend verarbeitet werden, berührt die Taktik Credential Access.

Secrets

Secrets liegen in der Cloud an mehr Orten, als die meisten Teams im Blick haben: Umgebungsvariablen von Functions und App Services, Deployment-Konfigurationen, Parameter- und Secret-Stores, Container-Images, Skripte in Storage, CI-Artefakte, Init-Skripte und User Data von Instanzen, Snapshots. Der Pentest sucht sie nicht, um sie zu sammeln, sondern um ihre Reichweite zu bewerten. Ein vorhandenes Secret ist nicht automatisch ein kritischer Fund.

Dieselbe Matrix gilt für Storage-Funde: Nicht die Tatsache, dass etwas lesbar ist, bestimmt die Severity, sondern Gültigkeit, Rechte, Scope, Rotation, Reichweite und Folgepfad dessen, was gelesen werden kann. Der Nachweis bleibt minimal - belegt wird, dass ein Secret erreichbar ist und welche Rechte es trägt, nicht, was sich damit alles anstellen ließe.

Cloud Network Controls

Cloud-Netzwerke stellen dieselbe Frage wie die Segmentierungsprüfung im Netzwerk-Pentest: Erreichbar und wirklich getrennt sind zwei verschiedene Dinge. Die Werkzeuge heißen anders - Security Groups, NSG-ähnliche Regeln, Network ACLs, VPC/VNet, Peering, Private und Public Endpoints, Routing -, aber der Befund entsteht genauso: Quelle, Ziel, Weg, erwartetes Verhalten, tatsächliches Verhalten. Die zentrale Frage lautet: Welche Vertrauensgrenze existiert tatsächlich?

Die Prüfung wird als Trust-Matrix festgehalten - das direkte Pendant zur Segmentierungs-Matrix des Netzwerktests:

Ein wichtiger Unterschied zum klassischen Netz: Viele Cloud-Dienste sind über die Control Plane erreichbar, ohne ein einziges Paket durch ein Kundennetz zu schicken. Ein Storage-Bucket oder ein Secret-Service kennt keine Security Group; seine Grenze ist IAM plus die Frage, ob ein öffentlicher Endpunkt existiert. Netzwerkkontrollen und Berechtigungen müssen deshalb zusammen gelesen werden - eine Vertrauensgrenze, die nur auf einer der beiden Ebenen existiert, ist keine.

Managed Services

Managed Services werden im Pentest anders behandelt als klassische Server, weil es keinen Host gibt, den man übernehmen könnte. Es gibt keinen Patchstand, keine Shell, keinen Dienst-Exploit. "Zugriff" bedeutet hier ausschließlich: eine Identität darf über die Control Plane oder den Datenpfad mit dem Dienst sprechen, und das Netz lässt es zu. Der Prüfgegenstand ist damit die Kombination aus IAM, Resource Policy, Netzanbindung, Trust und den Daten dahinter - und die Folgepfade, die der Dienst eröffnet.

Das Muster wiederholt sich: Die gefährlichen Rechte sind selten die Datenrechte, sondern die Konfigurationsrechte - Code aktualisieren, Policy ändern, Identität zuweisen, Snapshot exportieren. Sie wirken wie Datenzugriff, stehen aber in der Policy unter unauffälligeren Namen. Eine Service-Enzyklopädie braucht es nicht; das Prüfschema aus Zugriff, IAM, Netzwerk, Trust, Daten und Folgepfad gilt für jeden Managed Service.

Serverless

Functions verdienen einen eigenen Blick, weil sie das Cloud-Prinzip auf die Spitze treiben: kein Host, dafür eine Identität, ein Trigger und ein Stück Code, das im Namen dieser Identität mit anderen Diensten spricht. Der Pentest betrachtet nicht die einzelne "Function-Misconfiguration", sondern den Pfad, der durch die Function läuft.

• Function Identity: Welche Rolle trägt die Function, und ist sie auf das beschränkt, was der Code tatsächlich aufruft? Functions sind häufig überprivilegiert, wenn Rollen für erste Integrationen breit vergeben und später nicht verengt werden - und schon eine einzelne Function ruft oft mehrere Managed Services auf.
• Trigger: Wer darf die Function auslösen - ein öffentlicher HTTP-Endpunkt, eine Queue, ein Storage-Event, ein Zeitplan? Jeder Trigger ist ein Eingangspunkt mit eigener Vertrauensannahme.
• Input: Was die Function mit ihrem Input tut, ist Web- und API-Methodik. Cloud-spezifisch ist, dass der Input aus einem anderen Dienst stammen kann, dem die Function blind vertraut.
• Secrets und Rollen: Umgebungsvariablen, eingebundene Secret-Referenzen, annehmbare Rollen.
• Cross-Service-Aufrufe: Welche Dienste ruft die Function auf, und was darf sie dort über den Zweck hinaus?

Ein typischer Serverless-Pfad: Ein Storage-Event triggert eine Function, die Objekte verarbeitet; wer ein Objekt in diesen Bucket schreiben darf, steuert damit den Input einer Function, die mit einer breiten Rolle läuft. Das Schreibrecht auf den Bucket war für sich genommen harmlos.

Misconfiguration vs. exploitable path

Cloud-Scanner liefern Hunderte Fehlkonfigurationen. Ein Pentest liefert die wenigen davon, die einen Pfad ergeben. Der Unterschied liegt in vier Fragen, die zwischen der Konfiguration und ihrer Bewertung liegen: Ist die Ressource von der relevanten Position aus erreichbar? Welche Position muss ein Angreifer dafür bereits haben? Was ist das effektive Recht - nicht das in der Policy, sondern das nach allen Ebenen? Und welcher Impact folgt daraus?

Dieselbe Konfiguration erscheint in der Tabelle zweimal mit verschiedenem Ergebnis - das ist der Kern. Für öffentliche Endpunkte und Ressourcen gilt dabei immer dieselbe Reihenfolge: Ist die Öffentlichkeit vorgesehen? Welche Aktion ist ohne Authentisierung möglich? Welche Daten oder Funktionen sind exponiert? Entsteht daraus ein relevanter Pfad? Erst ein Nein auf die erste oder ein Ja auf die letzte Frage macht daraus ein Finding. Nicht die Fehlkonfiguration wird bewertet, sondern der Pfad, den sie von einer konkreten Position aus ermöglicht. Wie aus technischer Schwere, Exposure, Voraussetzungen und Impact eine nachvollziehbare Einstufung wird, vertieft der Deep-Dive Risikobewertung und CVSS; dieser Artikel baut keine eigene Scoring-Methode.

Privilege Paths und Capability Chains

Klassische Privilege Escalation heißt: mehr Rechte auf demselben System. Cloud-Pfade sind breiter. Sie entstehen aus Fähigkeiten, die für sich genommen nichts mit "Rechteausweitung" zu tun haben, in Kombination aber genau das bewirken. Der Operator denkt deshalb in Capability Chains: Welche Fähigkeit habe ich, welche Fähigkeit eröffnet sie, und wo endet die Kette?

Keiner dieser Mechanismen ist ein Fehler; alle sind legitime Cloud-Funktionen. Zum Pfad werden sie, wenn eine Identität eine Fähigkeit besitzt, die sie für ihren Zweck nicht braucht, und diese Fähigkeit eine mächtigere eröffnet. Die Domänen-Form dieser Logik beschreibt der AD-Artikel unter Privilege Mapping; die allgemeine Taktik liegt in der Payload-Sammlung unter Privilege Escalation.

Cross-Service Attack Path

Alles bisher Beschriebene läuft in einem Pfad zusammen, der mehrere Dienste und mehrere Vertrauensannahmen durchquert. Das folgende Beispiel ist ein vereinfachtes, providerneutrales Szenario - fiktiv, aber in dieser Form typisch. Welche Bedingungen den Abruf von Workload-Credentials ermöglichen, ist provider- und konfigurationsabhängig; nicht jede SSRF gegen einen Metadata-Endpunkt liefert Credentials.

Jedes Glied bekommt seine eigene Finding-Severity, und keines davon ist für sich "Kritisch": Eine SSRF ohne internen Impact, ein unter bestimmten Bedingungen abrufbarer Metadata-Endpunkt, ein Leserecht auf einen internen Bucket, ein zu breiter Trust, ein unnötiges Export-Recht. Das Pfadrisiko entsteht aus der Verkettung und wird separat ausgewiesen - genauso, wie es der Deep-Dive zu Pentest Reporting für Angriffspfade vorsieht und die Risikobewertung als Pfadrisiko von der Finding-Severity trennt. Die Einzel-Findings werden nicht künstlich hochgestuft, damit der Pfad "passt"; umgekehrt wird der Pfad nicht heruntergestuft, nur weil seine Glieder einzeln mittel sind.

Auffällig ist, dass der Pfad die Datenbank nie über das Netz berührt. Er läuft vollständig über die Control Plane - und genau das unterscheidet einen Cloud-Angriffspfad von einem internen Netzwerkpfad. Jede Segmentierung um die Datenbank herum wäre korrekt gewesen und hätte nichts verhindert.

Cross-Account und Cross-Tenant Trust

Account- und Mandantengrenzen gelten als Sicherheitsgrenzen, und sie sind es auch - solange niemand sie bewusst geöffnet hat. In realen Umgebungen sind sie fast immer geöffnet: für Partner, Dienstleister, SaaS-Werkzeuge, Organisationsverwaltung und Föderation. Der Pentest fragt nicht, ob Trusts existieren, sondern was sie tatsächlich erlauben und ob die Gegenseite diesen Vertrauensvorschuss verdient.

Federation ist dabei bewusst nur als Eintrittspunkt in den Cloud-IAM-Graphen behandelt: Welche Cloud-Rolle eine föderierte Identität bekommt, ist Cloud-Pentesting. Ob der Identity Provider selbst, seine Protokolle, SSO, MFA oder Conditional Access sauber arbeiten, ist eine eigene Zielklasse und wird in einem späteren Deep-Dive zum Identity Pentesting vertieft.

Cloud, Netzwerk, Active Directory und Identity

Vier Zielklassen, die sich berühren, aber unterschiedliche Fragen beantworten. Die Grenze sauber zu ziehen verhindert, dass ein Cloud-Pentest zum Netzwerktest mit anderen Begriffen wird oder sich in Identity-Tiefe verliert, die ihm nicht gehört.

Zwei Grenzen gelten zusätzlich. Cloud Identity vs. Identity Pentesting: Dieser Artikel prüft Cloud-IAM-Rollen, Cloud-Ressourcenrechte, Workload-Identitäten, Resource Policies und Cloud-Trust-Beziehungen. Identity Provider, SSO, OAuth/OIDC, SAML, MFA, Federation, Conditional Access und Entra als Identity-Plattform werden hier nur als Eintrittspunkt berührt und später in einem eigenen Deep-Dive behandelt. Cloud vs. Kubernetes: Managed Kubernetes ist in diesem Artikel eine Cloud-Ressource mit Node- und Workload-Rollen, Cloud-IAM-Anbindung und einer Metadata-/Workload-Identity-Schnittstelle. Kubernetes RBAC, ServiceAccounts, Pod Security, Admission, Namespace-Isolation und Cluster-Privilege-Escalation folgen in einem eigenen Deep-Dive.

Minimaler Nachweis

Im Cloud-Pentest ist der minimale Nachweis nicht nur Professionalität, sondern Betriebsschutz. Eine vollständige Ausnutzung kann produktive Dienste stören, Daten verändern, dauerhafte Spuren im Berechtigungsmodell hinterlassen und Kosten verursachen - und sie bringt keinen zusätzlichen Erkenntniswert, sobald das effektive Recht belegt ist.

• Keine großen Datenmengen herunterladen - ein einzelnes, unkritisches Objekt belegt den Zugriff.
• Keine produktiven Ressourcen löschen oder stoppen.
• Keine produktiven Rollen oder Policies dauerhaft ändern.
• Keine neuen langlebigen Credentials erzeugen, wenn der Nachweis anders möglich ist; wenn doch, dokumentiert und sofort widerrufen.
• Keine Ressourcen erzeugen, die Kosten verursachen, ohne ausdrückliche Freigabe.
• Keine produktiven Workloads stören - kein Neustart, kein Code-Update, keine Konfigurationsänderung an laufenden Diensten.

Der Beweis läuft stattdessen über die effektiven Rechte (Policy-Auswertung, Simulation, wo der Provider sie anbietet), eine minimale Objektabfrage, eine vom Auftraggeber bereitgestellte Testressource, ein kontrolliertes Read oder Write auf genau diese Testressource oder eine temporäre, dokumentierte und sofort rückgängig gemachte Änderung. Was davon erlaubt ist und welche Ressourcen dafür vorgesehen sind, steht in den Rules of Engagement; ohne diese Festlegung bleibt der Nachweis lesend.

Operator-Entscheidungsmatrix

Dieselbe Beobachtung führt je nach Umgebung zu einer anderen richtigen Entscheidung. Die Matrix macht die wiederkehrenden Schritte explizit: Beobachtung, Hypothese, minimale Verifikation, Stop Condition, Evidenz.

Die Leitlinie ist dieselbe wie im Netzwerk- und AD-Test: so viel Nachweis wie nötig, so wenig Eingriff wie möglich. In der Cloud kommt hinzu, dass fast jede Aktion im Audit-Log des Auftraggebers landet - das ist gut für die Evidenz und erfordert, dass der Operator seine Aktionen zeitlich protokolliert, damit sie sich später zuordnen lassen.

Nachweis und Reporting

Die Berichtsstruktur, das Finding-Template und die Darstellung von Angriffspfaden vertieft der Deep-Dive zu Pentest Reporting; hier geht es nur um das, was ein Cloud-Finding zusätzlich dokumentieren muss, damit es reproduzierbar und zuordenbar ist.

Secrets, Tokens und Account-Kennungen Dritter werden im Bericht redigiert; Zeitstempel bleiben vollständig, weil sie die Brücke zum Audit-Log des Auftraggebers sind.

Risikobewertung

Für Cloud-Findings gilt die Bewertungsmethodik aus dem Deep-Dive Risikobewertung und CVSS unverändert; eine eigene Scoring-Methode braucht die Cloud nicht. Besonders stark wirken hier die Unterscheidung zwischen technischer Misconfiguration und effektivem Risiko, die Exposure (Internet, Account-intern, nur aus dem Workload), die Voraussetzungen (welche Position, welche Rolle), der Pfadbezug und der Business Impact des erreichten Ziels. Eine Wildcard-Policy auf einer Rolle, die niemand annehmen kann, ist technisch dieselbe Konfiguration wie auf einer Rolle, die jeder annehmen darf - und ein völlig anderes Risiko.

Remediation

Die Behebung folgt der Ursache, nicht dem Symptom: Least Privilege auf Identitäts- und Rollenebene, Trusts auf konkrete Principals und Bedingungen verengen, Secrets rotieren und aus Code, Images und Storage entfernen, Exposure reduzieren, wo Öffentlichkeit nicht vorgesehen ist, Netzwerkgrenzen dort setzen, wo IAM allein die Grenze ist, Workload-Identitäten auf den tatsächlichen Bedarf beschneiden und Metadata-Endpunkte härten. Wie Maßnahmen nach Pfadwirkung priorisiert, kompensierende Kontrollen von echter Behebung getrennt und Befunde im Retest verifiziert werden, beschreibt der Deep-Dive Remediation und Retest.

Logging und Deconfliction

Cloud-Audit-Logs sind im Pentest zweierlei: Evidenz und Deconfliction-Grundlage. Fast jede Control-Plane-Aktion - Rolle annehmen, Objekt lesen, Policy abfragen - wird protokolliert. Das erlaubt dem Auftraggeber, jede Testaktion nachzuvollziehen, und verpflichtet den Operator, seine Aktionen mit Zeit, Quelle und Identität so zu protokollieren, dass ein SOC sie von einem echten Angreifer unterscheiden kann. Vor dem Test wird geklärt, ob der Verteidiger eingeweiht ist und wie der Abgleich läuft; der Ablauf dafür steht im Scope-Artikel.

Typische Fehler

• Cloud wie ein Netz testen: Portscans gegen Cloud-IPs und Host-Härtung prüfen, aber den IAM-Graphen nie anschauen - die Control Plane bleibt ungeprüft.
• Scanner-Output als Pentest: Hunderte Misconfigurations abliefern, ohne eine einzige in einen Pfad zu übersetzen.
• Policies einzeln lesen: Eine Policy als harmlos bewerten, ohne Rollen, Vererbung, Resource Policies und Trusts einzurechnen.
• "Bucket öffentlich" als Finding: Ohne zu prüfen, was drin liegt und wohin es führt.
• Metadata-Endpunkt ignorieren: Eine SSRF als Web-Finding abschließen, ohne den Übergang in die Cloud-Identität zu prüfen.
• Kurzlebige Credentials unterschätzen: "Läuft eh in einer Stunde ab" - innerhalb dieser Stunde mit vollen Rechten.
• Trusts als gegeben hinnehmen: Cross-Account- und Drittanbieter-Rollen nicht auf ihre tatsächliche Reichweite prüfen.
• Managed Services wie Hosts behandeln: Nach Exploits suchen, wo die einzige Angriffsfläche IAM, Netz und Konfiguration ist.
• Zu viel beweisen: Daten exportieren, Rollen ändern, Ressourcen anlegen - Betriebsrisiko und Kosten ohne Erkenntnisgewinn.
• Scope über IPs definieren: Cloud-Ressourcen wechseln Adressen; der Scope gehört über Accounts, Projekte und Tags festgelegt.
• Identity- und Kubernetes-Tiefe vermischen: IdP-Protokolle oder Cluster-RBAC in den Cloud-Test ziehen, statt sie als eigene Zielklassen sauber zu übergeben.

Häufige Fragen

Ist Cloud Pentesting dasselbe wie ein Cloud Security Assessment?

Nein. Ein Assessment prüft Konfigurationen gegen Best Practices und Standards und liefert eine Liste von Abweichungen. Ein Cloud-Pentest prüft, welche dieser Abweichungen von einer konkreten Ausgangsposition aus zu einem belegten Angriffspfad führen - und bewertet den Pfad, nicht die Liste.

Brauche ich Cloud-Credentials für den Test?

Für einen aussagekräftigen Test fast immer. Von außen sind nur exponierte Ränder sichtbar; das Berechtigungsmodell, in dem die eigentlichen Schwächen liegen, ist erst mit einer Identität lesbar. Üblich ist eine Standard-Identität oder eine Assumed-Breach-Position, ergänzt um eine externe Sicht auf die öffentlichen Übergänge.

Sollte ich AWS, Azure und GCP getrennt testen?

Die Methodik ist providerübergreifend: IAM-Graph, effektive Rechte, Metadata, Storage, Trust und Netzgrenzen gibt es überall, nur unter anderen Namen. Provider-spezifisch sind Policy-Syntax, Dienstnamen und einzelne Eigenheiten - die gehören in spätere Vertiefungen, nicht in die Grundmethodik.

Warum ist der Metadata-Endpunkt so wichtig?

Weil er der Punkt ist, an dem eine Anwendungs- oder Host-Schwäche zu einer Cloud-Identität wird. Eine SSRF, die keine Workload-Identität erreicht, ist ein Web-Finding; eine, die unter den gegebenen Bedingungen Workload-Credentials liefert, ist der Einstieg in die Control Plane. Welche Voraussetzungen der Endpunkt verlangt und was die gelieferte Rolle darf, entscheidet über den Unterschied zwischen "mittel" und "Pfad zum kritischen Ziel".