Penetrationstests in der Public Cloud: Shared Responsibility, Regeln und Grenzen
Workloads in die Public Cloud zu verlagern verändert nicht nur den Betrieb, sondern auch das Testen. Ein Penetrationstest in AWS, Azure oder Google Cloud folgt anderen Regeln als im eigenen Rechenzentrum — denn die Infrastruktur gehört Ihnen nicht. Wer das ignoriert, riskiert im besten Fall einen wertlosen Test und im schlechtesten einen Verstoß gegen die Nutzungsbedingungen des Anbieters.
Die Servicemodelle bestimmen den Scope
Wie weit ein Test reichen darf, hängt vom Servicemodell ab:
- IaaS — Infrastrukturkomponenten (Server, Storage, Netzwerk): der größte testbare Bereich
- PaaS — Entwicklungs- und Laufzeitumgebungen auf der Infrastruktur des Anbieters
- SaaS — fertige Anwendungen: hier ist fast alles Sache des Anbieters
Das Modell der geteilten Verantwortung
Das Shared-Responsibility-Modell ist der Schlüsselbegriff. Anbieter und Nutzer teilen sich die Verantwortung für Sicherheit — und die Aufteilung verschiebt sich mit dem Servicemodell. Der Anbieter verantwortet die physische Sicherheit, die Hypervisor-Ebene und Compliance der Plattform. Sie verantworten Konfiguration, Identitäten, Zugriffssteuerung, Daten und alles, was Sie selbst betreiben.
Die unbequeme Wahrheit: Die überwiegende Mehrheit realer Cloud-Vorfälle entsteht nicht durch einen gehackten Hyperscaler, sondern durch Fehlkonfiguration auf der Kundenseite — offene Buckets, zu weite IAM-Rechte, exponierte Management-Schnittstellen.
Was beim Cloud-Pentest anders ist
- White-Box oder Grey-Box ist Standard, um nicht versehentlich auf Daten anderer Mandanten zuzugreifen.
- Die Nutzungsbedingungen des Anbieters sind verbindlich. AWS, Azure und GCP erlauben Tests heute weitgehend ohne vorherige Genehmigung — eine Benachrichtigung und das Einhalten der Regeln bleiben aber Pflicht.
- Cloud-spezifische Angriffstechniken unterscheiden sich vom klassischen Vorgehen: Privilege Escalation über IAM, Metadata-Services, Misconfiguration-Ketten statt Buffer Overflows.
Der wichtigste Schluss
Ein Cloud-Pentest beschränkt sich auf die Ebenen, die Sie kontrollieren — und genau dort liegt fast immer das reale Risiko. Nach jeder Migration und bei jeder wesentlichen Änderung gehört die eigene Cloud-Umgebung geprüft.
Wie Cloud Cape unterstützt
Wir testen Cloud-Umgebungen entlang des Shared-Responsibility-Modells — mit Fokus auf das, was Sie verantworten: IAM, Konfiguration, exponierte Dienste und Angriffspfade zwischen Cloud-Ressourcen. Wo kontinuierliche Überwachung sinnvoller ist als der periodische Test, verbinden wir das mit unserem Continuous Threat Exposure Management.
Sprechen Sie mit uns über Pentesting & Red Teaming — wir prüfen genau die Cloud-Ebenen, die Ihnen gehören.