Cloud-Fehlkonfiguration.

Cloud-Fehlkonfiguration ist die häufigste Ursache von Cloud-Datenpannen: Sie entsteht, wenn Administrator, Infrastructure-as-Code-Vorlage oder CI/CD-Pipeline einen Dienst entgegen den Sicherheitsgrundsätzen einrichten. Typische Beispiele sind öffentlich lesbare Objektspeicher, Security Groups, die 0.0.0.0/0 freigeben, fehlende Verschlüsselung, deaktiviertes Logging, Default-Credentials oder zu weite IAM-Trust-Policies. Weil Cloud-APIs Ressourcen mühelos in der Breite ausrollen, kann eine einzige fehlerhafte Vorlage denselben Fehler über Hunderte Accounts und Regionen replizieren.

Der Capital-One-Vorfall von 2019 ist der Paradefall: Eine fehlkonfigurierte Web Application Firewall war für Server-Side Request Forgery anfällig, wodurch der Angreifer den EC2-Instanz-Metadatendienst (IMDS) erreichte, die temporären Credentials der WAF-Rolle stahl und damit Daten aus über 700 S3-Buckets auflistete und kopierte — rund 106 Millionen Kundendatensätze. Capital One zahlte später eine Strafe von 80 Millionen US-Dollar an die US-OCC und legte Klagen für 190 Millionen bei. AWS' IMDSv2 (sitzungstokenbasiert, mit Hop-Limit) härtet genau diese SSRF-zu-Credentials-Kette ab.

Erkennung und Prävention basieren auf CSPM, IaC-Scanning (Checkov, tfsec), Policy-as-Code (OPA, AWS Config, Azure Policy), Least-Privilege-IAM, dem Blockieren öffentlichen Zugriffs auf Account-Ebene und kontinuierlichen Compliance-Checks, gekoppelt an Ticketing- und Remediation-Prozesse.

flowchart TD
  A[IaC-Vorlage / manuelle Änderung] --> B{Unsichere Einstellung?}
  B -->|Nein| OK[Konforme Baseline]
  B -->|Ja| C[Öffentlicher Bucket / offene SG / weite IAM]
  C --> D[Exponiert im Internet oder via SSRF]
  D --> E[Angreifer stiehlt Daten oder Credentials]
  C -. erkannt durch .-> F[CSPM / IaC-Scan / Policy-as-Code]
  F --> G[Auto-Remediation + Ticket]
  G --> OK