Cloud-Pentest: AWS, Azure und GCP sicher pruefen 2026

Klassische Pentest-Methoden funktionieren in der Cloud nur halb. Ein AWS-Konto hat keine "Server, die man scannt" — es hat Tausende verteilte Services, Hunderte IAM-Rollen, dutzende Regionen, jede mit eigenen Berechtigungs-Edge-Cases. Ein Cloud-Pentest ist die spezialisierte Pruefung dieser Architektur.

Dieser Leitfaden erklaert, was Cloud-Pentests unterscheidet, was Provider erlauben und worauf Sie bei AWS, Azure, GCP und Kubernetes besonders achten muessen.

Was Cloud-Pentests von klassischen Pentests unterscheidet

Provider-Regeln (kritisch)

Nicht alles ist erlaubt. Stand 2026:

AWS

• Erlaubt ohne Voranmeldung: Pentests gegen eigene Ressourcen in EC2, RDS, NAT Gateway, ELB, Lambda, S3, API Gateway u.a.
• Verboten: DDoS, DNS-Hijacking, Port-Flooding, Pruefung von Diensten, die Sie nicht besitzen
• Pre-Approval erforderlich: simulated-events bei Route 53, simuliertes Phishing gegen SES
• Vollstaendige Liste: AWS Customer Support Policy for Penetration Testing

Azure

• Erlaubt: Pentests gegen Microsoft-Online-Dienste in Ihrem Tenant — keine Vorabgenehmigung mehr noetig (seit 2017)
• Verboten: DDoS, Tests gegen Azure-Infrastruktur (z.B. Hypervisor), Tests gegen andere Tenants
• Penetration Testing Rules of Engagement dokumentieren den genauen Scope

Google Cloud

• Erlaubt: Tests in eigenen Projekten ohne Voranmeldung
• Verboten: DDoS, Tests gegen GCP-Infrastruktur, Phishing gegen Google-Mitarbeiter
• Acceptable Use Policy definiert Grenzen

Kubernetes

• Provider-Regeln gelten weiter, aber Kubernetes selbst hat keine Restriktionen — alles in Ihrem Cluster ist Ihr Spielfeld

Praktischer Tipp: auch wenn Voranmeldung nicht mehr noetig ist, schicken Sie eine kurze Notification an den Provider-Account-Manager mit Test-Zeitfenster — vermeidet Misverstaendnisse mit Anti-Abuse-Systemen.

Cloud-Pentest-Methodik

Schritt 1: Konfigurations-Audit (CSPM)

Erste Stufe ist immer ein automatisiertes Konfigurations-Audit. Werkzeuge:

• AWS: Prowler, ScoutSuite, AWS Security Hub, AWS Config
• Azure: ScoutSuite, Microsoft Defender for Cloud, PowerZure
• GCP: ScoutSuite, gcp_scanner, Forseti
• Multi-Cloud: Wiz, Orca, Lacework, Steampipe

Findings: oeffentliche S3-Buckets, ueberprivilegierte IAM-Rollen, fehlende MFA, abgelaufene Zertifikate, unverschluesselte Datenbanken.

Schritt 2: IAM-Analyse

Die Cloud-Sicherheit steht und faellt mit IAM:

• Inline-Policies analysieren (oft zu permissiv)
• Service-Account-Keys (sollten nicht existieren)
• Trust Policies und Cross-Account-Access
• Privilege-Escalation-Pfade (Tools: PMapper, IAMSpy, BloodHound for AWS)

Klassische Cloud-Privilege-Escalations:

• iam:PassRole + lambda:CreateFunction = Eskalation auf Rolle X
• iam:PutUserPolicy auf eigenen User
• sts:AssumeRole mit zu offener Trust Policy

Schritt 3: Aktive Ausnutzung

Nicht nur "ist konfiguriert", sondern "wird tatsaechlich ausgenutzt":

• Pacu (AWS) — automatisierte Eskalations-Pfadsuche
• MicroBurst (Azure) — Powershell-basiert, gut gegen App-Services
• Stormspotter (Azure) — Graph-basierte Visualisierung von Beziehungen

Schritt 4: Persistence

Wie wuerde ein Angreifer im Cloud-Konto bleiben?

• Rogue IAM-User mit Admin-Rights
• Lambda-Backdoors mit Trigger
• Service-Principal-Backdoors in Azure
• OAuth-App mit Tenant-weiten Berechtigungen

Schritt 5: Datenexfiltration (simuliert)

• S3/Blob-Storage durchgreifen
• Datenbank-Snapshots in Angreifer-Konto kopieren
• Logging und Monitoring umgehen — wird CloudTrail/Activity Log alarmiert?

Container und Kubernetes

Eigene Pruefdimension — viele Cloud-Pentests umfassen das automatisch:

Container-Image-Scan

• Bekannte CVEs in Base-Images
• Hardcoded Credentials in Images
• Privilegierte Container, fehlende User-Namespaces
• Tools: Trivy, Grype, Snyk Container

Kubernetes-Cluster-Pruefung

• RBAC-Misconfigurations (cluster-admin zu freigiebig)
• Pod Security Standards (kein "privileged: true" ohne Grund)
• Network Policies vorhanden? Default-deny?
• Secrets in etcd verschluesselt?
• Service-Mesh-Konfiguration (mTLS aktiv?)
• Tools: kube-bench, kube-hunter, Peirates

Container-Escape-Tests

Versuche, aus einem Pod auf den Worker-Node oder Control-Plane zu eskalieren — typische Vektoren: hostPath-Mounts, capabilities, Docker-Socket-Mount.

Typische Findings 2026

Aus Cloud-Pentest-Berichten letzter Quartale die haeufigsten:

Cloud-Pentest und Compliance

NIS2 Art. 21

Fuer Unternehmen mit cloud-zentrischer IT: Cloud-Pentest ist Mindeststandard zur Wirksamkeitsbewertung.

DORA

Finanzinstitute, die Cloud nutzen, fallen unter strenge Outsourcing-Anforderungen (Art. 28-30) — Cloud-Pruefungen sind verpflichtend.

ISO 27001:2022

Annex A 5.23 (Cloud-Sicherheit) und A 8.8 erwarten Cloud-spezifische Pruefungen.

BSI C5

Fuer Cloud-Anbieter: BSI C5-Audit umfasst Cloud-Pentest-Anforderungen.

TISAX (Automotive)

Cloud-Pruefung wird bei TISAX-AL3-Audits explizit verlangt.

Kosten

Best Practices fuer regelmaessige Cloud-Pruefung

1. CSPM kontinuierlich — taeglich, nicht jaehrlich. Tools wie Wiz/Orca laufen permanent.
2. IaC-Scans im CI/CD — Terraform/CloudFormation vor Apply pruefen (Checkov, tfsec).
3. Manueller Pentest jaehrlich — fuer Privilege-Escalation und Logikfehler, die CSPM nicht findet.
4. Container-Image-Scan im Build — kein Image ohne Scan ins Registry.
5. Cloud-Inventar pflegen — was Sie nicht kennen, koennen Sie nicht schuetzen.

Wie Matproof unterstuetzt

Matproof kombiniert Cloud-CSPM-Funktionen mit aktivem Pentest in einer Plattform:

• AWS-, Azure-, GCP-Konfigurationsscans kontinuierlich
• IAM-Privilege-Escalation-Tests automatisiert plus menschliche Verifikation
• Kubernetes-Cluster-Pruefung (kube-bench-Style + manuelle Tiefe)
• Compliance-Mapping auf NIS2, DORA, ISO 27001, BSI C5, TISAX
• CI/CD-Integration fuer Container-Image-Scans

Mehr zur Plattform | Kostenloser Pentest-Check

Fazit

Cloud-Pentests sind kein "Add-on" zum klassischen Pentest — sie sind eine eigene Disziplin mit eigener Methodik, eigenen Tools und (kritisch) eigenen Provider-Regeln. Wer 2026 Cloud betreibt und nur klassische Pentests macht, deckt 60-70% der real ausnutzbaren Angriffsflaeche nicht ab.

Der wichtigste Hebel ist IAM-Pruefung. Alle anderen Cloud-Findings (oeffentliche Buckets, fehlende Verschluesselung) sind unangenehm — aber Privilege Escalation in IAM ist die Kategorie, ueber die echte Datenpannen passieren.

Weiter lesen: API-Pentest Leitfaden | Schwachstellenmanagement | Pentest-Kosten Deutschland