Cloud-Pentest-Checkliste: AWS, Azure und Microsoft 365
Was ein Cloud-Pentest in AWS, Azure und Microsoft 365 abdecken muss: Identitäten, Storage, Netzwerk, Logging, Anbieterregeln und die häufigsten Fehlkonfigurationen.
Zyberum Security Team · Veröffentlicht am · 8 Min. Lesezeit
Ein Cloud-Pentest testet den Teil der Cloud, der dir gehört: Identitäten, Berechtigungen, Netzwerkregeln, Storage-Einstellungen, Workloads und Logging. Der Anbieter sichert Rechenzentrum und Hypervisor; alles oberhalb dieser Linie ist deine Konfiguration, und dort beginnt fast jeder Cloud-Einbruch. Diese Checkliste zeigt, was wir in einem Cloud-Pentest von AWS, Azure und Microsoft 365 abdecken und was wir am häufigsten finden.
Vor dem Test: Regeln und Vorbereitung
Regeln der Anbieter. AWS erlaubt Penetrationstests der gängigen Dienste (EC2, RDS, Lambda, API Gateway, CloudFront und weitere) ohne vorherige Genehmigung; Denial-of-Service-Tests, DNS Zone Walking und Flooding sind ausgeschlossen, DDoS-Simulationen brauchen einen eigenen Antrag. Microsoft veröffentlicht Rules of Engagement für seine Cloud-Dienste, die ohne Anmeldung gelten; DoS, Zugriff auf Daten anderer Kunden und Post-Compromise-Aktionen wie Lateral Movement innerhalb der Microsoft-Infrastruktur sind verboten. Wir prüfen beide Policies vor dem ersten Tag gegen den aktuellen Scope.
Was wir brauchen.
- Eine lesende Audit-Rolle (AWS
SecurityAudit, AzureReaderplusSecurity Reader, Microsoft 365 Global Reader) für die Konfigurationsprüfung. - Eine Liste der Accounts, Subscriptions und Tenants im Scope, jeweils mit Verantwortlichem.
- Einen Nutzer mit wenigen Rechten pro Rolle für die Angreifersicht von innen.
- Eine schriftliche Erlaubnis und einen Ansprechpartner für Findings, die sofort behandelt werden müssen.
Checkliste 1: Identitäten und Zugriff
Identität ist in der Cloud der Perimeter, und dort finden wir die kritischsten Probleme.
- Langlebige Access Keys für IAM-Nutzer, oft seit Monaten unbenutzt und manchmal in Repositories eingecheckt.
- Nutzer und Dienstkonten ohne Multi-Faktor-Authentifizierung, einschließlich Notfallkonten.
- Policies mit
"Action": "*"oderiam:PassRoleauf*, die eine Rechteausweitung zum Administrator erlauben. - Cross-Account-Vertrauen ohne
ExternalIdoder mit Wildcard-Principal. - In Entra ID: Legacy-Authentifizierung weiterhin erlaubt, womit Conditional Access umgangen wird; App-Zustimmung für alle Nutzer offen; privilegierte Rollen dauerhaft statt über Privileged Identity Management vergeben; Gastkonten mit mehr Rechten als beabsichtigt.
- Service Principals und Managed Identities mit Contributor auf der ganzen Subscription.
Checkliste 2: Storage und Daten
- S3-Buckets und Azure-Blob-Container mit öffentlichem Lese- oder Listenzugriff oder mit Policies, die jedem authentifizierten AWS-Account Zugriff geben.
- Shared Access Signatures (SAS) mit langer Laufzeit im Client-Code.
- Datenbank-Snapshots, AMIs und Disk-Images, die öffentlich oder accountübergreifend freigegeben sind.
- Backups im selben Account wie die Produktion, sodass eine kompromittierte Identität beides löscht.
- Fehlende Verschlüsselung at rest für Datenbanken mit personenbezogenen Daten oder Schlüssel, die außerhalb von Key Vault oder KMS verwaltet werden.
Checkliste 3: Compute und Netzwerk
- Security Groups und Network Security Groups offen für
0.0.0.0/0auf SSH, RDP, Datenbank- und Management-Ports. - EC2-Instanzen mit aktivem IMDSv1, sodass jede SSRF in einer Webanwendung Rollen-Zugangsdaten liefert.
- Geheimnisse in User Data, Umgebungsvariablen und Container-Definitionen.
- Container, die als Root oder im Privileged Mode laufen; Kubernetes-Dashboards und -APIs aus dem Internet erreichbar.
- Flache Netze: Produktion und Entwicklung in einem VPC oder VNet ohne Segmentierung.
- Serverless-Funktionen mit Berechtigungen weit über das hinaus, was sie aufrufen.
Checkliste 4: Logging und Erkennung
- CloudTrail nicht in jeder Region aktiv, oder Logs, die von denselben Identitäten gelöscht werden können, die sie überwachen.
- GuardDuty, Defender for Cloud oder das Unified Audit Log von Microsoft 365 abgeschaltet oder nie angesehen.
- Alarme, die niemand bekommt. Das testen wir: Wir lösen ein paar auffällige Aktionen aus und fragen, wer es bemerkt hat.
Checkliste 5: Besonderheiten in Microsoft 365
- Postfachregeln, die Mails nach außen weiterleiten, ein klassisches Zeichen für ein kompromittiertes Konto.
- Anonyme Freigabelinks in SharePoint und OneDrive ohne Ablauf.
- Externer Zugriff in Teams für beliebige Domains offen.
- Kein Conditional Access für nicht verwaltete Geräte, sodass ein gestohlenes Passwort vom Heim-PC reicht.
- Legacy-Protokolle (IMAP, POP, SMTP AUTH) weiterhin aktiv.
Die Findings, die wir am häufigsten sehen
| Finding | Typische Schwere | Warum es zählt |
|---|---|---|
| Admin-Rechte aus einer Identität mit wenigen Rechten erreichbar | Kritisch | Ein gephishter Entwickler übernimmt den Account |
| Öffentlicher Storage mit Kundendaten | Kritisch | Datenabfluss ganz ohne Exploit |
| IMDSv1 plus SSRF in einer Anwendung | Hoch | Aus einem Web-Bug werden Cloud-Zugangsdaten |
| Legacy-Authentifizierung in Entra ID erlaubt | Hoch | MFA und Conditional Access umgangen |
| Logs fehlen oder sind löschbar | Mittel | Vorfälle werden nicht gesehen oder lassen sich nicht untersuchen |
So testen wir
Ein Cloud-Pentest bei Zyberum kombiniert drei Sichten. Die Konfigurationsprüfung mit einer Audit-Rolle gegen die CIS Benchmarks und unsere eigenen Checks findet die Lücken in der gesamten Umgebung in wenigen Tagen. Die externe Sicht testet alles, was aus dem Internet erreichbar ist: exponierte Dienste, Storage, Webanwendungen und APIs. Die Assumed-Breach-Sicht startet mit einem Nutzer mit wenigen Rechten oder einem geleakten Key und versucht, Administrator, Daten und Produktion zu erreichen. Jedes Finding kommt mit der genauen Ressource, dem CVSS-Score, den Schritten zum Nachstellen und dem Fix, wo möglich als Policy-Snippet oder Konsoleneinstellung.
Was du zuerst tun solltest
- Erzwinge MFA für jede menschliche Identität und entferne langlebige Keys.
- Blockiere Legacy-Authentifizierung und verlange verwaltete Geräte für Microsoft 365.
- Schließe öffentlichen Storage und öffentliche Management-Ports; alarmiere, wenn einer aufgeht.
- Schalte die Logs ein, schütze sie und teste, ob jemand reagiert.
- Lass die Umgebung vor einer Migration oder einem Zertifizierungsaudit testen, nicht danach.
Mehr zu Umfang und Preisen unter Cloud-Pentest, oder buch ein kostenloses 15-Minuten-Gespräch.
FAQ
Häufig gestellte Fragen
Müssen wir AWS oder Microsoft vor einem Pentest fragen?
Für die gängigen Dienste nein. AWS listet die Dienste, die ohne vorherige Genehmigung getestet werden dürfen, und schließt Denial-of-Service und einige weitere Aktivitäten aus; Microsoft veröffentlicht Rules of Engagement, die ohne Anmeldung gelten. Beide verbieten Angriffe auf andere Mandanten und DoS. Wir prüfen die aktuelle Policy für jeden Scope, bevor wir starten.
Ist ein Cloud-Pentest eine Konfigurationsprüfung oder ein echter Angriff?
Beides, und genau das ist der Punkt. Wir lesen die Konfiguration mit einer Audit-Rolle, um die Lücken schnell zu finden, und nutzen die relevanten dann aus der Position eines externen Angreifers oder eines Nutzers mit wenigen Rechten aus, um die echte Auswirkung zu zeigen. Ein reiner Konfigurationsscan übersieht Ketten über mehrere Dienste.
Was deckt ein Cloud-Pentest nicht ab?
Den Anbieter. Hypervisor, physisches Rechenzentrum und die Steuerungsebene der Cloud liegen in der Verantwortung von AWS oder Microsoft und sind tabu. Der Test deckt alles ab, was du konfigurierst: Identitäten, Netzwerk, Storage, Workloads, Logging und die Anwendungen, die du betreibst.