Cloud Penetrationstest: AWS, Azure, GCP & Kubernetes im Fokus

Cloud Computing ist heute integraler Bestandteil moderner Unternehmens-IT. Gleichzeitig wächst die Angriffsfläche: Fehlkonfigurierte S3-Buckets, überprivilegierte IAM-Rollen, offene Kubernetes-API-Server - die Bedrohungsszenarien sind vielfältig und unterscheiden sich fundamental von klassischen On-Premise-Umgebungen. Dieser Artikel erklärt, was einen Cloud Penetrationstest ausmacht, welche Regelwerke gelten und welche typischen Schwachstellen Pentester in AWS, Azure, GCP und Kubernetes-Clustern finden.

Einen professionellen Cloud-Pentest bietet AWARE7 unter Cloud Security.

Warum Cloud-Pentests anders sind als klassische Pentests

Bei einem klassischen Penetrationstest gegen eine On-Premise-Infrastruktur gelten im Wesentlichen zwei Parteien: der Auftraggeber und das Pentest-Unternehmen. In Cloud-Umgebungen kommt eine dritte Partei hinzu: der Cloud-Anbieter. Dessen Nutzungsbedingungen definieren verbindlich, welche Tests erlaubt sind - unabhängig davon, was der Auftraggeber genehmigt.

Ein weiterer struktureller Unterschied liegt im Shared-Responsibility-Modell. Die zugrundeliegende Infrastruktur der großen Cloud-Provider ist in der Regel sicher - die Anbieter investieren erhebliche Ressourcen in interne und externe Pentests sowie Bug-Bounty-Programme. Google hat seit 2010 über 21 Millionen Dollar an Bug-Bounty-Hunter ausgezahlt. Die Verantwortung für die Konfiguration dieser Infrastruktur liegt jedoch beim Kunden. Genau hier setzen Cloud-Pentests an.

Das Shared-Responsibility-Modell variiert je nach Service-Modell:

• IaaS (Infrastructure as a Service): Der Kunde kontrolliert Betriebssystem, Anwendungen und Daten. Der Pentest kann deutlich aggressiver durchgeführt werden.
• PaaS (Platform as a Service): Die Plattformschicht liegt beim Anbieter. Der Pentest fokussiert auf Anwendungslogik und Konfiguration.
• SaaS (Software as a Service): Nur Konfiguration und Zugriffsrechte sind kundenseitig - der Pentest-Scope ist entsprechend eingeschränkt.

Ebenso relevant ist der Cloud-Typ: In einer Public Cloud teilen sich viele Kunden dieselbe Infrastruktur, was DDoS-Tests grundsätzlich ausschließt. Eine Virtual Private Cloud (VPC) ist eine isolierte Umgebung innerhalb einer öffentlichen Cloud, die nur für eine bestimmte Organisation bereitsteht. Eine hybride Cloud kombiniert private und öffentliche Anteile, was den Pentest-Scope besonders komplex macht.

Testansätze im Cloud-Kontext

AWARE7 unterscheidet drei Ansätze:

• Black Box / Testing gegen die Cloud: Getestet werden Applikationen, die als Cloud-Anwendung gehostet sind - klassische Webapplikationsvektoren, fehlkonfigurierte Nutzerberechtigungen oder falsch konfigurierte Speicherinstanzen wie S3-Buckets oder EC2-Metadaten.
• Grey Box / Testing in der Cloud: Systeme, die nicht öffentlich zugänglich sind (z. B. hinter einer Firewall). Dem Tester werden häufig gültige Zugänge zum Backend bereitgestellt, um zu prüfen, was ein Angreifer mit kompromittierten Zugangsdaten erreichen kann.
• White Box / Testing der Konsole: Die Konfiguration der Cloud-Umgebung wird überprüft - welche Nutzer welche Rechte haben, ob Zugangskontrollen korrekt gesetzt sind. So lassen sich Privilege-Escalation-Vektoren und Informationslecks effizient schließen.

Scoping und Regelwerke der Cloud-Anbieter

Bevor ein Cloud-Pentest beginnt, muss der Scope präzise definiert sein - und zwar unter Berücksichtigung der Richtlinien des jeweiligen Anbieters. Ein Verstoß gegen diese Richtlinien kann zum Ausschluss aus dem Dienst führen.

Grundsätzlich verboten bei allen Anbietern:

• DDoS-Angriffe (Denial of Service)
• Port Flooding
• Tests gegen geteilte Infrastruktur, die nicht dem eigenen Account gehört

Vom Anbieter erlaubt (kundeneigene Ressourcen):

• Tests gegen eigene EC2-Instanzen, S3-Buckets, IAM-Schlüssel
• Tests gegen eigene Azure Virtual Machines, App Services
• Tests gegen eigene GKE/EKS/AKS-Cluster und die darauf laufenden Workloads

Der erhöhte Planungs- und Durchführungsaufwand bei Cloud-Pentests ergibt sich genau aus dieser Konstellation: Neben der Abstimmung mit dem Kunden muss stets auf die Anforderungen der unterschiedlichen Cloud-Anbieter eingegangen werden.

AWS Penetrationstest

Was AWS erlaubt und verbietet

Amazon erlaubt Pentests auf kundeneigenen Ressourcen ausdrücklich. Testbar sind insbesondere:

• EC2-Instanzen (Elastic Compute Cloud) - vollständig testbar, inklusive Anwendungs-APIs, virtuellen Maschinen und laufenden Anwendungen
• S3-Buckets - Berechtigungskonfiguration, öffentliche Zugänglichkeit, Bucket-Policies
• IAM-Schlüssel - Berechtigungsumfang, Rotation, Exponierung
• Anwendungen auf EC2 - klassische Web-App-Vektoren

Nicht testbar sind die physische Hardware in AWS-Rechenzentren, EC2-Umgebungen von Partnern oder Dienstleistern außerhalb der eigenen administrativen Kontrolle sowie Amazon RDS in bestimmten Konfigurationen. Tests im Bereich Stabilität und Erreichbarkeit - also DoS-Szenarien - sind ausdrücklich verboten.

Typische Findings bei AWS

AWS-Pentests drehen sich weniger um klassisches Hacking als um Konfigurationsfehler. Die häufigsten Findings:

Fehlkonfigurierte S3-Buckets: Öffentlich zugängliche Buckets mit sensiblen Daten - Konfigurationsdateien, Backups, interne Dokumente - gehören zu den häufigsten und folgenreichsten Cloud-Findings. S3-Buckets haben sich als primäres Angriffsziel etabliert.

Überprivilegierte IAM-Rollen: IAM-Schlüssel mit zu weit gefassten Berechtigungen, die im Schadensfall einem Angreifer weitreichenden Zugang zur gesamten AWS-Umgebung ermöglichen.

Exponierte Metadaten-Endpunkte: Der Instance Metadata Service (IMDS) unter 169.254.169.254 liefert bei fehlender IMDSv2-Erzwingung IAM-Credentials der Instance-Role - ein häufiger Pivoting-Vektor nach einer initialen Kompromittierung.

Unsichere EC2-Konfigurationen: Security Groups mit zu offenen Regeln, fehlende Verschlüsselung von EBS-Volumes, ungepatchte Betriebssysteme auf EC2-Instanzen.

Da AWS auf dem SaaS-Prinzip basiert - Kunden mieten eine Umgebung, werden aber nicht Eigentümer der physischen Infrastruktur - liegt die Sicherheitsverantwortung für die eigene Konfiguration vollständig beim Kunden. Hilfreiche hauseigene Lösungen wie der Amazon Inspector bieten ein automatisiertes Schwachstellenmanagement, ersetzen aber keinen manuellen Pentest durch erfahrene Tester.

Azure Penetrationstest

Microsoft erlaubt das Testing von Azure-Produkten ohne gesonderte Voranmeldung. Portscans gegen virtuelle Azure-Instanzen sind dabei ausdrücklich erlaubt - ein Unterschied zu einigen anderen Anbietern. DoS-Tests bleiben auch hier verboten.

Typische Findings bei Azure-Pentests:

Azure Active Directory / Entra ID: Fehlkonfigurierte Conditional-Access-Policies, zu weitreichende Gastbenutzer-Berechtigungen, schwache MFA-Konfigurationen oder unsichere App-Registrierungen mit übermäßigen API-Berechtigungen.

Blob Storage: Ähnlich wie S3-Buckets bei AWS sind öffentlich zugängliche Azure Blob Storage-Container ein häufiger Befund. Fehlende Private Endpoints oder unsichere Shared-Access-Signatures (SAS) erweitern die Angriffsfläche.

Azure RBAC-Fehlkonfigurationen: Zu weitreichende Rollen-Zuweisungen, insbesondere Contributor- oder Owner-Rechte auf Subscription-Ebene für Dienstkonten oder automatisierte Prozesse.

Unsichere App Services und Function Apps: Fehlende Authentifizierung, exponierte Debugging-Endpunkte oder unsichere Umgebungsvariablen mit Secrets in Plaintext.

GCP Penetrationstest

Google Cloud Platform (GCP) erlaubt Sicherheitstests gegen eigene Ressourcen ohne gesonderte Genehmigung, sofern die Google Cloud Acceptable Use Policy eingehalten wird. DoS-Tests sind auch hier ausgeschlossen.

Typische Findings bei GCP-Pentests:

Service Account Missbrauch: Überprivilegierte Service Accounts mit Project-Owner-Rechten, exportierte Service-Account-Keys in Code-Repositories oder CI/CD-Pipelines, fehlende Rotation.

GCS Buckets (Google Cloud Storage): Ähnlich wie bei AWS S3 und Azure Blob Storage sind fehlerhafte Bucket-IAM-Policies ein häufiger Befund - insbesondere allUsers- oder allAuthenticatedUsers-Berechtigungen.

GKE (Google Kubernetes Engine) Cluster: Öffentlich erreichbare API-Server ohne Authorisierungs-Kontrollen, fehlende Workload Identity-Konfiguration oder überprivilegierte Node-Service-Accounts.

Compute Engine Metadaten-Endpunkt: Der GCP-Metadaten-Server unter metadata.google.internal liefert OAuth-Tokens für die Node-Service-Accounts - ein direkter Pivoting-Pfad bei kompromittierten Containern.

Kubernetes Penetrationstest

Kubernetes ist heute die Standard-Plattform für Container-Orchestrierung in Unternehmen - und damit ein primäres Angriffsziel. Ein K8s-Cluster verbindet oft Hunderte von Microservices, Secrets, Cloud-Credentials und privilegierten Workloads. Ein einziger unsicherer Pod kann zur vollständigen Cluster-Kompromittierung führen.

Angriffsfläche eines Kubernetes-Clusters

Die relevanten Komponenten und ihre Ports:

Control Plane:

• kube-apiserver (Port 6443) - zentraler Angriffspunkt, alle Cluster-Operationen laufen hierüber
• etcd (Port 2379) - enthält alle Kubernetes-Secrets des Clusters im Klartext, sofern kein Encryption at Rest konfiguriert ist
• kube-scheduler (Port 10259), kube-controller (Port 10257)

Worker Nodes:

• kubelet API (Port 10250) - direkter Pod-Zugriff, in älteren Konfigurationen ohne Authentifizierung erreichbar
• Container Runtime (Docker, containerd, CRI-O)

Externe Angriffsfläche:

• API-Server öffentlich erreichbar? (GKE, EKS, AKS haben das teilweise standardmäßig)
• Kubernetes Dashboard ohne Authentifizierung
• NodePort-Services (Ports 30000-32767) auf allen Nodes
• Prometheus/Grafana-Monitoring-Endpunkte mit Cluster-Informationen

Phase 1: Cluster-Enumeration

Ein Kubernetes-Pentest beginnt mit der Prüfung auf anonymen Zugriff am API-Server. Ein 403 Forbidden bestätigt die Existenz des Servers; in schlecht konfigurierten Clustern ist vollständiger anonymer Zugriff möglich. Die Kubelet-API (Port 10250) listet in manchen Konfigurationen alle Pods eines Nodes ohne Authentifizierung auf. Ist etcd ohne TLS erreichbar, sind alle Kubernetes-Secrets des Clusters im Klartext abrufbar.

Phase 2: RBAC-Analyse und Privilege Escalation

RBAC-Fehlkonfigurationen sind die häufigsten Kubernetes-Findings:

Wildcard-Berechtigungen: ClusterRoles mit apiGroups: ["*"], resources: ["*"], verbs: ["*"] - vollständige Cluster-Kontrolle für jeden zugeordneten Service Account.

Pod-Erstellung gleich Cluster-Admin: Wer Pods erstellen und das privileged-Flag setzen darf, kann das Host-Filesystem mounten und beliebige Befehle auf dem Node als Root ausführen.

Secrets lesen gleich alle Credentials: Wer Secrets im Cluster lesen darf, erhält API-Keys, Datenbankpasswörter, TLS-Zertifikate und OAuth-Tokens aller Namespaces.

Impersonation: Wer die impersonate-Berechtigung hat, kann als beliebiger Nutzer oder Service Account auftreten - bis hin zum cluster-admin.

Phase 3: Container Escape

Ein privilegierter Container kann auf alle Host-Devices zugreifen:

• Privileged + hostPath: Das Host-Root-Filesystem kann direkt gemountet werden (/dev/sda1). Angreifer können die Host-Crontab bearbeiten oder SSH-Keys hinterlegen - Persistence auf Node-Ebene.
• hostPID: true: Über nsenter kann eine Root-Shell im Host-Namespace geöffnet werden.
• hostNetwork: true: Der Container sieht alle Host-Netzwerkinterfaces und kann direkt auf den Cloud-Metadaten-Endpunkt 169.254.169.254 zugreifen - und damit IAM-Credentials der Node-Role abrufen.
• Docker-Socket gemountet: /var/run/docker.sock innerhalb eines Containers entspricht Root-Zugriff auf den Node.

Phase 4: Laterale Bewegung im Cluster

Nach einer initialen Kompromittierung suchen Angreifer nach Wegen, sich horizontal im Cluster zu bewegen:

• Service-Discovery über Kubernetes DNS (<service-name>.<namespace>.svc.cluster.local) zur Identifikation interner Dienste
• Secrets aus anderen Namespaces stehlen, sofern ClusterRoles mit secrets/get vorhanden
• Bei EKS: Node-IAM-Role via Instance Metadata Service abrufen und AWS-Credentials des Worker-Nodes nutzen
• Bei GKE: GCP OAuth-Token des Node-Service-Accounts über den GCP-Metadaten-Server abrufen

Kubernetes-Härtung

Die wichtigsten Schutzmaßnahmen:

• API-Server absichern: Anonymen Zugriff deaktivieren (--anonymous-auth=false), RBAC erzwingen (--authorization-mode=Node,RBAC), Audit-Log aktivieren
• Pod Security Standards (PSS): Namespaces mit restricted-Policy verhindern privilegierte Container, hostPath-Mounts sowie hostPID/hostNetwork/hostIPC - und damit die meisten Container-Escape-Techniken
• Network Policies (Zero Trust): Default-Deny für alle Namespaces, dann explizite Allow-Policies für benötigte Kommunikation
• RBAC Least Privilege: Service Accounts ohne unnötige Rechte, automountServiceAccountToken: false wenn nicht benötigt, nur spezifische Ressourcen und Verbs freigeben
• Secrets verschlüsseln: Encryption at Rest für etcd konfigurieren
• Container-Image-Security: Keine :latest-Tags, Non-root User, Vulnerability-Scanning mit Trivy oder Grype im CI/CD

Empfohlene Tools für kontinuierliche K8s-Sicherheit: kube-bench (CIS Kubernetes Benchmark), Falco (Runtime-Detection), OPA/Gatekeeper (Policy-Enforcement), kube-score (YAML-Analyse vor Deployment).

Typische Schwachstellen in Cloud-Umgebungen

Anbieterübergreifend zeigen sich beim Cloud-Pentest wiederkehrende Schwachstellenklassen:

Fehlkonfigurierte Speicher-Services: Öffentlich zugängliche S3-Buckets, Azure Blob Container oder GCS-Buckets mit sensiblen Daten sind konsistent die häufigsten und folgenreichsten Findings. 85 % der 2019 verursachten Datendiebstähle waren auf Fehlkonfigurationen zurückzuführen.

Überprivilegierte Identitäten: IAM-Rollen, Service Accounts und Managed Identities mit zu weitreichenden Berechtigungen - das Principle of Least Privilege wird in der Praxis häufig nicht konsequent umgesetzt.

Exponierte Metadaten-Endpunkte: Der Cloud-Metadaten-Service (IMDS bei AWS, äquivalente Endpunkte bei GCP und Azure) ist ein zentraler Pivoting-Vektor: Er liefert temporäre Credentials, die einem Angreifer nach einer initialen Kompromittierung Zugang zur gesamten Cloud-Umgebung ermöglichen können.

Fehlende Verschlüsselung: Unverschlüsselte Daten at Rest (EBS-Volumes, etcd-Inhalte), unsichere Übertragung interner Services oder fehlende TLS-Verifizierung zwischen Cluster-Komponenten.

Unsichere CI/CD-Pipelines: Secrets in Umgebungsvariablen, überprivilegierte Deployment-Service-Accounts, fehlende Supply-Chain-Security (unsigned Images, kein Vulnerability-Scanning).

Abhängigkeit von Diensten: Der AWS-Vorfall von 2017 zeigt exemplarisch, dass ein einziger falscher Befehl zahlreiche abhängige Dienste vom Netz nehmen kann. Pentests decken auch solche Abhängigkeiten und fehlende Resilience-Maßnahmen auf.

FAQ

Benötige ich eine Genehmigung des Cloud-Anbieters für einen Pentest? Für Tests gegen kundeneigene Ressourcen - EC2-Instanzen, S3-Buckets, eigene VMs - ist in der Regel keine gesonderte Genehmigung erforderlich. AWS, Azure und GCP erlauben diese Tests in ihren Nutzungsbedingungen. DoS-Tests und Tests gegen geteilte Infrastruktur sind jedoch bei allen Anbietern verboten.

Was ist der Unterschied zwischen einem Cloud-Pentest und einem Cloud-Security-Audit? Ein Pentest simuliert aktiv Angriffe gegen die Umgebung und versucht, Schwachstellen auszunutzen. Ein Security-Audit überprüft Konfigurationen, Richtlinien und Berechtigungskonzepte ohne aktive Exploitation. Beide Ansätze ergänzen sich; AWARE7 kombiniert je nach Anforderung beide Methoden.

Kann ein Cloud-Pentest die Verfügbarkeit meiner Dienste beeinträchtigen? Bei korrekter Abstimmung und Einhaltung der Anbieter-Richtlinien ist das Risiko minimal. DoS-Tests werden grundsätzlich nicht durchgeführt. Dennoch empfiehlt sich die Durchführung außerhalb der Hauptgeschäftszeiten und mit definierten Rollback-Plänen.

Wie lange dauert ein Cloud-Penetrationstest? Die Dauer hängt vom Scope ab. Ein fokussierter AWS-Test einer mittelgroßen Umgebung (10-20 Services) dauert typischerweise 3-5 Tage. Ein umfassendes Cloud-Security-Assessment inklusive Kubernetes-Cluster kann 1-2 Wochen in Anspruch nehmen.

Was kostet ein Cloud-Pentest? Die Kosten variieren erheblich je nach Scope, Tiefe und Anzahl der zu testenden Services. Für eine konkrete Einschätzung Ihrer Cloud-Umgebung empfehlen wir eine kostenlose Erstberatung.

Welche Cloud-Plattformen testet AWARE7? AWARE7 führt Penetrationstests für AWS, Azure, GCP sowie Kubernetes-Cluster durch - unabhängig ob On-Premise (K3s, OpenShift), in der Cloud (EKS, GKE, AKS) oder in hybriden Umgebungen. Mehr Informationen unter Cloud Security.