Cloud Penetration Testing · Moritz Samrock

Cloud Penetration Testing ist das autorisierte Sicherheitstesten von Cloud-Umgebungen – AWS, Azure, GCP oder Multi-Cloud-Architekturen – mit dem Ziel, Fehlkonfigurationen, ausnutzbare Schwachstellen und architektonische Mängel zu identifizieren, die spezifisch für cloudnative Infrastruktur sind. Anders als beim klassischen Netzwerk-Pentest muss ein Cloud-Pentest das Shared-Responsibility-Modell, providerspezifische Dienste und die einzigartigen Angriffsflächen berücksichtigen, die durch IAM, Metadaten-Services, Serverless Functions und Container-Orchestrierung entstehen.

Cloud-Umgebungen verlagern den Perimeter von Netzwerkgrenzen auf Identity and Access Management. IAM wird damit zur primären Angriffsfläche. Ein Cloud-Pentest untersucht diese Fläche systematisch, zusammen mit Storage-Exposition, Compute-Schwachstellen und dem weitverzweigten Netz vernetzter Cloud-nativer Dienste.

Wer beauftragt diesen Test?

Cloud Penetration Tests werden von CISOs, Cloud-Architekten, DevOps- und Platform-Engineering-Leads sowie Compliance-Teams beauftragt. Organisationen, die SOC-2-, ISO-27001- oder PCI-DSS-Audits durchlaufen, benötigen häufig cloudspezifische Penetrationstests als Nachweis der Kontrollwirksamkeit. Typische Auftraggeber sind Unternehmen, die in die Cloud migrieren, Multi-Cloud-Strategien verfolgen oder cloudnative Plattformen mit kundenorientierten Workloads betreiben.

Ziel des Tests

Ziel ist die Identifikation ausnutzbarer Schwachstellen in der Cloud-Infrastruktur, bevor Angreifer sie finden. Dies umfasst die Validierung der IAM-Policy-Wirksamkeit, das Testen der Netzwerksegmentierung innerhalb der Cloud-Umgebung, die Bewertung des Datenexpositionsrisikos durch Storage-Dienste und APIs, die Evaluierung der Sicherheit von Serverless- und Container-Workloads sowie die Prüfung, ob Logging, Monitoring und Alerting zur Erkennung von Exploitation ausreichen.

Was wird getestet?

Getestet wird die gesamte Bandbreite cloudspezifischer Angriffsflächen: IAM – übermäßig permissive Policies, ungenutzte Rollen, Cross-Account-Role-Assumption-Ketten, Federation-Fehlkonfigurationen und Privilege Escalation über Cloud-native Services (z. B. iam:PassRole + Lambda in AWS). Storage – öffentliche S3-Buckets, Azure-Blob-Container, GCS-Objekte und fehlende Verschlüsselung. Compute – EC2/VM-Metadaten-Service-Exploitation (IMDS v1 SSRF zur Credential-Exfiltration), Container-Escape-Pfade, Kubernetes-RBAC-Fehlkonfigurationen. Serverless – Lambda/Cloud-Functions-Secrets in Umgebungsvariablen, überprivilegierte Ausführungsrollen, Event Injection. Networking – Security-Group- und Firewall-Regelfehlkonfigurationen, VPC-Peering-Exposition, Transit-Gateway-Vertrauensbeziehungen. Logging und Monitoring – fehlende CloudTrail-, Azure-Activity-Log- oder GCP-Audit-Log-Abdeckung, deaktivierte Alerts.

Übliche Schwachstellen und Findings

Übermäßig permissive IAM-Policies mit administrativem Zugriff für Service Accounts
Öffentliche S3-Buckets oder Azure-Blob-Container mit exponierten sensiblen Daten
IMDS v1 aktiviert, was SSRF-zu-Credential-Theft-Angriffsketten ermöglicht
Fehlkonfigurierte Security Groups mit uneingeschränktem eingehendem Zugriff
Ungenutzte, aber aktive Access Keys und Service-Account-Credentials
Cross-Account-Role-Assumption-Ketten, die unbeabsichtigte Vertrauenspfade schaffen
Lambda-Umgebungsvariablen mit Klartext-Secrets
Fehlende oder unvollständige CloudTrail- und Audit-Logging-Konfigurationen
Unverschlüsselte Daten at rest in Storage- und Datenbankdiensten
Privilege Escalation über Cloud-natives Service-Chaining (z. B. SSM, STS oder Managed-Identity-Abuse)

Ablauf eines Cloud Penetrationstests

Ein Cloud Penetrationstest folgt einem strukturierten Engagement-Prozess, der an den Cloud-Kontext angepasst ist:

Interesse und Erstanfrage – der Auftraggeber nimmt Kontakt auf, häufig getrieben durch Compliance-Anforderungen, eine bevorstehende Cloud-Migration oder ein Architecture Review. Erstgespräch zum Verständnis der Kundenziele – der Testanbieter trifft sich mit Cloud-Architekten und Sicherheitsverantwortlichen, um den Cloud-Footprint zu verstehen: genutzte Provider, Account-Struktur, Workload-Typen und Compliance-Treiber. Angebotserstellung und Freigabe – der Anbieter erstellt ein Angebot mit Methodik, Ziel-Accounts und Services, Zeitplan und Kosten. Das Angebot berücksichtigt die Pentest-Richtlinien der Cloud-Provider. Scope-Definition – beide Seiten einigen sich auf Ziel-Accounts, Regionen, Services und etwaige Ausschlüsse (z. B. Produktionsdatenbanken, Shared-Tenancy-Grenzen). Providerspezifische Test-Richtlinien werden geprüft: AWS erlaubt die meisten Tests ohne vorherige Benachrichtigung, Azure und GCP haben eigene Regeln. Letter of Engagement – die formale Autorisierung wird unterzeichnet und deckt explizit cloudspezifische Aktivitäten wie Credential-Harvesting aus Metadaten-Services und Cross-Account-Tests ab. Erstellung weiterer Freigaben – Cloud-Provider-Benachrichtigungen werden eingereicht, wo erforderlich. SaaS-Integrationen im Scope können separate Autorisierung erfordern. Bereitstellung von Informationen – je nach Ansatz stellt der Auftraggeber Account-IDs, IAM-Policies, Architekturdiagramme oder Read-only-Zugangsdaten bereit (Gray-Box) oder gibt für eine Black-Box-Bewertung keine Informationen heraus. Kick-Off Call – das Testteam, Cloud-Architekten und Sicherheits-Stakeholder stimmen Zeitpläne, Notfallkontakte und den Prozess für die Handhabung kritischer Findings während des Tests ab. Durchführung – das Team testet systematisch über IAM-, Storage-, Compute-, Serverless- und Networking-Schichten. Kritische Findings wie exponierte Daten oder Credential-Leakage werden sofort über den vereinbarten Eskalationspfad gemeldet. Sammlung und Bewertung der Schwachstellen – alle Findings werden mit Nachweisen dokumentiert, nach Schweregrad und Ausnutzbarkeit bewertet und im Kontext des Shared-Responsibility-Modells eingeordnet. Erstellung des Abschlussberichts – ein umfassender Bericht enthält Executive Summary, Finding-für-Finding-Detail mit Behebungsempfehlungen und eine priorisierte Roadmap für CSPM-Verbesserungen. Vorstellung in einer Präsentation – die Ergebnisse werden Sicherheits- und Cloud-Engineering-Stakeholdern präsentiert. Projektabschluss – Retesting-Zeitfenster werden vereinbart und Empfehlungen für die laufende Posture-Management-Praxis dokumentiert.

Wer sollte diesen Test wann durchführen lassen?

Jede Organisation, die Workloads in der Cloud betreibt, sollte Cloud Penetration Testing beauftragen. Kritische Zeitpunkte sind vor größeren Cloud-Migrationen, nach signifikanten Architekturänderungen (neue Accounts, VPC-Restrukturierung, Kubernetes-Adoption), jährlich im Rahmen von Compliance-Programmen (SOC 2, ISO 27001, PCI DSS) und nach Sicherheitsvorfällen, die Cloud-Infrastruktur betreffen. Organisationen in regulierten Branchen oder mit sensiblen Kundendaten sollten Cloud-Pentesting als wiederkehrende Basisaktivität behandeln, nicht als einmalige Prüfung.