Angriffsfläche der Cloud

In der Cloud schützt der Anbieter die Infrastruktur, während der Kunde für Konfiguration, Identität und Daten verantwortlich ist. Die meisten Sicherheitsverletzungen entstehen auf der Seite des Kunden.

• Der Anbieter aktualisiert Hypervisoren und gewährleistet die physische Sicherheit.
• Der Kunde ist für IAM-Richtlinien, Speicherberechtigungen und Netzwerkregeln verantwortlich.
• Fehlkonfigurationen und nicht eine Kompromittierung des Anbieters stellen das größte Risiko dar.

Die Cloud hat keinen traditionellen Netzwerkperimeter. Der Zugriff wird durch IAM gesteuert: Benutzer, Rollen, Richtlinien und Schlüssel. Ein offengelegter Zugriffsschlüssel kann ebenso großen Schaden anrichten wie ein gestohlenes Domain-Admin-Passwort.

• IAM-Richtlinien gewähren Aktionen für Ressourcen.
• Rollen ermöglichen es Diensten und Benutzern, temporäre Zugangsdaten anzunehmen.
• Identitäten mit übermäßigen Berechtigungen sind der wichtigste Vektor für Rechteausweitung.

Cloud-Zugangsdaten werden ständig offengelegt. Häufige Quellen sind:

• Zugriffsschlüssel, die in öffentliche Git-Repositorys eingecheckt wurden.
• Schlüssel, die fest in mobilen Apps, CI-Protokolle oder Container-Images einkodiert sind.
• Server-Side Request Forgery (SSRF), die den Metadatendienst erreicht.
• Eine zu weitreichende Weitergabe langlebiger Schlüssel statt kurzlebiger Rollen.

Jede Cloud-Instanz stellt einen Metadaten-Endpunkt bereit, der temporäre Anmeldedaten für Rollen ausgeben kann. Eine SSRF- oder RCE-Schwachstelle auf einer VM, die diesen Endpunkt erreicht, liefert häufig die Rolle der Instanz.

• Das AWS IMDS ist unter 169.254.169.254 erreichbar.
• IMDSv1 benötigt nur eine Anfrage und lässt sich über SSRF trivial missbrauchen.
• IMDSv2 erfordert ein Sitzungstoken (PUT, dann GET), wodurch viele SSRF-Angriffe abgewehrt werden.

Objektspeicher (S3, GCS, Azure Blob) ist eine wiederkehrende Ursache für Datenlecks.

• Buckets mit öffentlichem Lesezugriff geben vertrauliche Dateien preis.
• Buckets mit öffentlichem Schreibzugriff ermöglichen Manipulationen oder das Hosten von Schadsoftware.
• Zu weit gefasste Bucket-Richtlinien oder ACLs gewähren authentifizierten Benutzern Zugriff.
• Vorab signierte URLs mit langer Gültigkeit ermöglichen dauerhaft nutzbaren Zugriff.

Cloud-Netzwerkkontrollen (Security Groups, NSGs, Firewall-Regeln) lassen sich leicht zu weit öffnen.

• Datenbanken oder Admin-Ports sind für 0.0.0.0/0 erreichbar.
• Management-Planes (Kubernetes API, RDP, SSH) sind aus dem Internet erreichbar.
• Interne Dienste vertrauen der VPC implizit und verlangen keine Authentifizierung.

Serverless verlagert das Risiko, beseitigt es aber nicht. Funktionen, Warteschlangen und verwaltete Datenbanken besitzen jeweils eine Ausführungsidentität.

• Die Ausführungsrolle einer Lambda-Funktion kann übermäßig weitreichende Berechtigungen haben.
• Umgebungsvariablen enthalten häufig Geheimnisse, die bei einer Kompromittierung gelesen werden können.
• Eine Fehlkonfiguration der Ereignisquelle kann dazu führen, dass nicht vertrauenswürdige Eingaben privilegierte Funktionen auslösen.

Unterscheiden Sie die beiden Angriffsflächen:

• Control Plane: die Cloud-API (Ressourcen erstellen, IAM ändern, Konfigurationen lesen). Eine Kompromittierung betrifft das gesamte Konto.
• Data Plane: die Workloads selbst (Apps, VMs, Container).

Ein Zugriffspunkt in der Data Plane, der Anmeldedaten für die Control Plane liefert, ist die klassische Cloud-Privilegieneskalation.

Große Organisationen teilen Workloads auf viele Konten, Abonnements und Projekte auf.

• Kontoübergreifende Rollen mit schwachen Vertrauensrichtlinien ermöglichen laterale Bewegung.
• Ein Confused-Deputy-Problem in einer Integrationsrolle eines Drittanbieters kann missbraucht werden.
• Rollen auf Organisationsebene (z. B. OrganizationAccountAccessRole) sind besonders wertvoll.

Verteidiger verlassen sich auf cloudnative Protokolle. Angreifer versuchen, diese zu blenden.

• CloudTrail / Activity Log / Audit Logs protokollieren Aufrufe der Control Plane.
• Angreifer können Trails deaktivieren oder die Protokollübermittlung stoppen.
• GuardDuty / Security Command Center / Defender erkennen Anomalien.

Das Deaktivieren der Protokollierung ist selbst ein Ereignis mit hohem Signalwert, für das eine Warnung eingerichtet werden sollte.

Cloud-Pentests erfordern die Kenntnis und Genehmigung des Providers. Einige Aktionen (Denial-of-Service, bestimmte Scans) verstoßen gegen die Bedingungen des Providers. Bestätigen Sie stets den Kontobesitz, vereinbaren Sie den Schadensradius und bevorzugen Sie zunächst eine schreibgeschützte Enumeration.

Verwenden Sie ein dediziertes Testkonto oder eindeutig markierte Ressourcen und greifen Sie niemals auf Ressourcen außerhalb des dokumentierten Umfangs zu.

Überprüfen Sie Ihr Verständnis der Cloud-Angriffsfläche.

Sie haben die Cloud-Angriffsfläche erfasst.

• Fehlkonfigurationen auf Kundenseite machen den größten Teil des Cloud-Risikos aus.
• Die Identität ist der Perimeter; offengelegte Schlüssel und Rollen sind zentrale Angriffsvektoren.
• Der Metadatendienst verbindet Fehler in der Data Plane mit Cloud-Anmeldedaten.
• Fehlkonfigurationen von Speicher, Netzwerk und Protokollierung vervollständigen die Angriffsfläche.

Als Nächstes: Cloud-Ressourcen enumerieren, um diese Probleme zu finden.