Das Fehlkonfigurationsproblem
Cloud-Umgebungen sind komplex. AWS allein bietet über 200 Services mit tausenden Konfigurationsoptionen. Azure und GCP stehen dem kaum nach. Jede dieser Optionen ist eine potenzielle Schwachstelle — und die Angriffsoberfläche wächst mit jedem neuen Service, jedem neuen Konto, jedem neuen Deployment.
Die überwiegende Mehrheit aller Cloud-Sicherheitsvorfälle geht auf Fehlkonfigurationen zurück — nicht auf Zero-Day-Exploits oder raffinierte Angriffe. Die häufigste Ursache ist nicht mangelndes Know-how, sondern fehlende Sichtbarkeit: Teams wissen schlicht nicht, was in ihren Umgebungen konfiguriert ist.
Ein Beispiel aus der Praxis: Ein mittelständisches Unternehmen nutzt drei AWS-Accounts mit Dutzenden aktiver Services. Im Rahmen eines Assessments finden wir regelmäßig weit über hundert Fehlkonfigurationen — darunter etliche mit kritischem Risiko. Manuell ist das nicht beherrschbar.
Was ist CSPM?
Cloud Security Posture Management (CSPM) automatisiert die kontinuierliche Erkennung und Behebung von Fehlkonfigurationen in Cloud-Umgebungen. Im Kern vergleicht ein CSPM-Tool den Ist-Zustand Ihrer Infrastruktur mit definierten Soll-Konfigurationen — und schlägt Alarm, wenn Abweichungen auftreten.
Kernfunktionen
| Funktion | Beschreibung | Nutzen |
|---|---|---|
| Continuous Assessment | Automatische Prüfung gegen CIS Benchmarks, AWS Well-Architected und herstellerspezifische Best Practices | Konfigurationsfehler werden innerhalb von Minuten erkannt, nicht erst beim nächsten Audit |
| Drift Detection | Erkennung von Konfigurationsänderungen in Echtzeit | Unautorisierte Änderungen — ob durch Fehler oder Angriff — werden sofort sichtbar |
| Auto-Remediation | Automatische oder geführte Behebung von Findings | Kritische Fehlkonfigurationen werden geschlossen, bevor sie ausgenutzt werden |
| Compliance Mapping | Zuordnung zu Frameworks wie ISO 27001, BSI C5, TISAX, SOC 2 | Audit-Readiness wird zum Dauerzustand statt zum Projektmarathon |
| Asset Inventory | Vollständige Erfassung aller Cloud-Ressourcen über Accounts und Regionen hinweg | Schluss mit Schatten-IT und vergessenen Testumgebungen |
Abgrenzung zu CWPP und CNAPP
CSPM wird häufig mit verwandten Begriffen verwechselt. CWPP (Cloud Workload Protection Platform) schützt Workloads zur Laufzeit — also Container, VMs und Serverless-Funktionen. CNAPP (Cloud-Native Application Protection Platform) ist der Oberbegriff, der CSPM, CWPP und weitere Disziplinen wie Code Security unter einem Dach vereint. CSPM fokussiert sich gezielt auf die Konfigurationsebene — und ist damit die Grundlage, auf der alles andere aufbaut.
Die Top-5 Fehlkonfigurationen
Die folgenden fünf Fehlkonfigurationen finden wir in nahezu jedem Cloud-Assessment. Sie sind nicht theoretisch — sie sind der Standardzustand in Unternehmen, die keine systematische Posture-Prüfung betreiben.
1. Öffentlich zugängliche Storage-Buckets
Betroffene Services: AWS S3, Azure Blob Storage, Google Cloud Storage
Was passiert: Ein Storage-Bucket wird mit öffentlichem Lesezugriff konfiguriert — oft versehentlich während der Entwicklung oder durch eine fehlerhafte Bucket Policy. Sensible Daten wie Kundendaten, Backups oder interne Dokumente werden damit frei im Internet zugänglich.
Realer Impact: Der Capital One Breach 2019 wurde durch eine Fehlkonfiguration ermöglicht, die Zugriff auf S3-Daten von über 100 Millionen Kunden erlaubte. Selbst heute finden Sicherheitsforscher regelmäßig exponierte Buckets mit sensiblen Unternehmensdaten.
Remediation:
- S3 Block Public Access auf Account-Ebene aktivieren — nicht nur auf Bucket-Ebene
- Bucket Policies regelmäßig mit
aws s3api get-bucket-policy-statusprüfen - CSPM-Regel: Jeder Bucket mit
"Effect": "Allow"und"Principal": "*"wird sofort geflaggt - Für legitimen öffentlichen Zugriff (z.B. statische Assets) ein dediziertes Konto mit strikten Policies verwenden
2. Überprivilegierte IAM-Rollen
Betroffene Services: AWS IAM, Azure RBAC, GCP IAM
Was passiert: Service Accounts und Rollen erhalten AdministratorAccess oder vergleichbare Vollzugriffe, weil es schneller geht als granulare Policies zu schreiben. Diese Rechte werden nach der initialen Einrichtung nie wieder eingeschränkt.
Realer Impact: Bei einem kompromittierten Service Account mit Admin-Rechten erhält der Angreifer sofort Vollzugriff auf alle Ressourcen im Account. Lateral Movement wird trivial, und der Blast Radius eines einzelnen Incidents umfasst die gesamte Umgebung.
Remediation:
- Least Privilege konsequent umsetzen: IAM Access Analyzer (AWS) oder Azure AD Access Reviews nutzen, um tatsächlich verwendete Berechtigungen zu ermitteln
- Unused Permissions identifizieren: Rechte, die in den letzten 90 Tagen nicht genutzt wurden, systematisch entfernen
- Permission Boundaries für alle Service-Rollen definieren
- CSPM-Regel: Jede IAM-Rolle mit
"Action": "*"oder"Resource": "*"wird als kritisch eingestuft
3. Fehlende Encryption at Rest
Betroffene Services: RDS, DynamoDB, EBS Volumes, Azure SQL, GCS
Was passiert: Datenbanken und Storage-Volumes werden ohne Verschlüsselung bereitgestellt. Bei EBS Volumes ist Encryption nicht standardmäßig aktiviert — wer es nicht explizit einschaltet, speichert Daten im Klartext.
Realer Impact: Ohne Encryption at Rest kann ein Angreifer mit physischem Zugriff oder durch einen Snapshot-Leak direkt auf die Rohdaten zugreifen. In regulierten Branchen (Finanz, Gesundheit) ist fehlende Verschlüsselung zudem ein Compliance-Verstoß, der zu erheblichen Bußgeldern führt.
Remediation:
- Default Encryption für EBS auf Account-Ebene aktivieren (
aws ec2 enable-ebs-encryption-by-default) - Für RDS und DynamoDB Encryption bei der Erstellung erzwingen — nachträgliche Aktivierung erfordert eine Migration
- AWS KMS Customer Managed Keys (CMK) für sensible Workloads verwenden, um Schlüsselrotation und Zugriff granular zu steuern
- CSPM-Regel: Jede Datenbank und jedes Volume ohne aktive Encryption wird als High-Risk Finding gemeldet
4. Offene Security Groups und Netzwerk-ACLs
Betroffene Services: AWS Security Groups, Azure NSGs, GCP Firewall Rules
Was passiert: Ingress-Regeln erlauben Zugriff von 0.0.0.0/0 auf Management-Ports wie SSH (22), RDP (3389) oder Datenbankports (3306, 5432). Häufig werden diese Regeln zum Debugging eingerichtet und anschließend vergessen.
Realer Impact: Offene Management-Ports sind der einfachste Einstiegspunkt für automatisierte Angriffe. Botnets scannen kontinuierlich nach offenen SSH- und RDP-Ports. Ein schwaches Passwort oder eine ungepatchte Instanz genügt, und der Angreifer hat einen Foothold in Ihrem Netzwerk.
Remediation:
- SSH und RDP niemals direkt aus dem Internet erreichbar machen — stattdessen AWS Systems Manager Session Manager, Azure Bastion oder einen VPN-Zugang verwenden
- Security Groups nach dem Whitelist-Prinzip konfigurieren: nur explizit benötigte Quell-IPs und Ports erlauben
- VPC Flow Logs aktivieren und regelmäßig auf unerwartete Verbindungen analysieren
- CSPM-Regel: Jede Ingress-Regel mit Source
0.0.0.0/0auf Ports unter 1024 erzeugt ein kritisches Finding
5. Deaktiviertes Logging und Monitoring
Betroffene Services: AWS CloudTrail, Azure Activity Log, GCP Audit Logs, VPC Flow Logs
Was passiert: Logging-Services werden deaktiviert — manchmal bewusst zur Kosteneinsparung, häufiger durch Versäumnis bei der Account-Einrichtung. Ohne Logs gibt es keine Möglichkeit, einen Incident nachzuvollziehen oder verdächtige Aktivitäten zu erkennen.
Realer Impact: Wenn ein Angreifer in eine Umgebung ohne aktives Logging eindringt, operiert er im Blindflug — für die Verteidiger. Es gibt keine Möglichkeit zu erkennen, welche Daten kompromittiert wurden, wie der Angreifer eingedrungen ist oder ob er sich Persistenz eingerichtet hat. Die Incident-Response wird zum Ratespiel.
Remediation:
- CloudTrail in allen Regionen aktivieren — Angreifer nutzen gezielt Regionen, in denen kein Logging aktiv ist
- Multi-Account Logging mit einer zentralen Log-Organisation einrichten (AWS Organizations Trail)
- Log-Daten in einen separaten, schreibgeschützten Account exportieren, damit Angreifer sie nicht löschen können
- Alerting auf kritische API-Calls konfigurieren:
DeleteTrail,StopLogging,PutBucketPolicymit"Principal": "*" - CSPM-Regel: Jeder Account ohne aktives CloudTrail erzeugt ein sofortiges Critical Finding
CSPM-Lösung evaluieren und auswählen
Nicht jedes CSPM-Tool ist für jede Umgebung geeignet. Die folgenden Kriterien helfen bei der Bewertung.
Entscheidende Auswahlkriterien
Multi-Cloud-Fähigkeit: Wenn Sie AWS, Azure und GCP parallel betreiben, brauchen Sie ein Tool, das alle drei Plattformen mit gleicher Tiefe abdeckt. Manche Lösungen sind stark auf AWS optimiert und behandeln Azure nur oberflächlich — prüfen Sie die Regel-Abdeckung pro Cloud im Detail.
Policy-Customization: Vorgefertigte CIS-Benchmarks sind ein guter Startpunkt, aber jede Organisation hat eigene Anforderungen. Ihr CSPM muss Custom Policies unterstützen — idealerweise als Code (z.B. Rego, Python), damit sie versioniert und getestet werden können.
Remediation-Optionen: Unterscheiden Sie zwischen Tools, die nur Findings liefern, und solchen, die aktive Remediation anbieten. Auto-Remediation klingt attraktiv, birgt aber Risiken: Eine automatisch geschlossene Security Group kann eine Produktionsanwendung lahmlegen. Bewerten Sie, ob das Tool geführte Remediation mit Approval-Workflows unterstützt.
Integration in bestehende Workflows: Das beste CSPM-Tool ist wertlos, wenn die Findings niemand bearbeitet. Prüfen Sie die Integration in Ihr Ticketing-System (Jira, ServiceNow), Ihre Kommunikationsplattform (Slack, Teams) und Ihr SIEM. Findings müssen dort ankommen, wo Ihre Teams arbeiten.
Laufende Kosten und Lizenzmodell: CSPM-Lösungen werden typischerweise pro Cloud-Ressource oder pro Account lizenziert. Bei schnell wachsenden Umgebungen können die Kosten überraschend steigen. Klären Sie vorab, wie sich die Kosten bei Skalierung entwickeln.
Marktübersicht
| Kategorie | Beispiele | Stärke |
|---|---|---|
| Cloud-native | AWS Security Hub, Azure Defender for Cloud, GCP Security Command Center | Tiefe Integration in die eigene Plattform, kein zusätzlicher Agent |
| Third-Party | Wiz, Orca Security, Prisma Cloud, Lacework | Multi-Cloud aus einer Konsole, agentless Scanning |
| Open Source | Prowler, ScoutSuite, CloudSploit | Kostenlos, flexibel, gut für initiale Assessments |
Für Unternehmen mit einer einzigen Cloud-Plattform können die nativen Tools ausreichend sein. Sobald Multi-Cloud-Umgebungen oder komplexe Compliance-Anforderungen hinzukommen, überwiegen die Vorteile einer dedizierten Third-Party-Lösung.
CSPM in der DevOps-Pipeline — Shift Left
Die wirkungsvollste Strategie gegen Cloud-Fehlkonfigurationen ist, sie gar nicht erst in die Produktion gelangen zu lassen. Durch die Integration von CSPM-Checks in die CI/CD-Pipeline werden Konfigurationsfehler dort erkannt, wo sie entstehen — im Code.
Infrastructure as Code scannen
Wenn Ihre Infrastruktur als Terraform, CloudFormation oder Pulumi definiert ist, können Sie Fehlkonfigurationen erkennen, bevor eine einzige Ressource provisioniert wird. Tools wie Checkov, tfsec oder KICS analysieren IaC-Templates gegen dieselben Regeln, die Ihr CSPM in der Laufzeitumgebung prüft.
Ein praktisches Beispiel: Ein Entwickler definiert eine Security Group in Terraform mit Ingress von 0.0.0.0/0 auf Port 22. Der Checkov-Scan in der CI/CD-Pipeline erkennt die Fehlkonfiguration und blockiert den Merge Request — mit einer konkreten Fehlermeldung und einem Link zur Remediation-Dokumentation.
Policy as Code
Der Shift-Left-Ansatz funktioniert am besten, wenn Sicherheitsrichtlinien als Code definiert sind:
- Open Policy Agent (OPA) mit Rego-Policies für plattformübergreifende Regelwerke
- AWS Service Control Policies (SCPs) als Guardrails auf Organisationsebene
- Azure Policy und GCP Organization Policies für plattformspezifische Einschränkungen
Der Vorteil: Policies durchlaufen denselben Review- und Testprozess wie Anwendungscode. Änderungen sind nachvollziehbar, versioniert und reproduzierbar.
Die Feedback-Schleife schließen
Die effektivste CSPM-Implementierung verbindet Laufzeit-Findings mit dem Entwicklungsprozess:
- CSPM erkennt eine Fehlkonfiguration in der Produktionsumgebung
- Automatisch wird eine entsprechende IaC-Policy erstellt oder aktualisiert
- Künftige Deployments werden gegen die neue Policy geprüft
- Dieselbe Fehlkonfiguration kann nicht erneut eingeführt werden
So wird aus reaktiver Fehlerbehebung ein systematischer Lernprozess, der die Sicherheit Ihrer Umgebung kontinuierlich verbessert.
Wie wir Cloud-Fehlkonfigurationen systematisch eliminieren
Fehlkonfigurationen aufzulisten ist einfach — sie nachhaltig zu beseitigen erfordert Kontext, Priorisierung und Integration in bestehende Prozesse. Genau hier setzen wir an.
Multi-Cloud Visibility schaffen
Wir verbinden Ihre AWS-, Azure- und GCP-Umgebungen zu einer einheitlichen Sicht. Sie sehen auf einen Blick, welche Ressourcen existieren, wie sie konfiguriert sind und wo Risiken liegen — über alle Accounts, Subscriptions und Projekte hinweg. Schluss mit blinden Flecken durch vergessene Testumgebungen oder Schatten-Accounts.
Risiken priorisieren statt Alerts stapeln
Ein CSPM-Tool, das 500 Findings meldet, ohne sie zu priorisieren, erzeugt Alert Fatigue statt Sicherheit. Wir korrelieren Findings mit dem tatsächlichen Risiko: Ist die betroffene Ressource aus dem Internet erreichbar? Enthält sie sensible Daten? Gibt es einen bekannten Exploit-Pfad? So konzentrieren sich Ihre Teams auf die Findings, die wirklich zählen.
Custom Policies für Ihre Anforderungen
CIS Benchmarks sind ein solider Startpunkt — aber jede Organisation hat spezifische Anforderungen, die über Standard-Regelwerke hinausgehen. Wir entwickeln Custom Policies, die Ihre internen Richtlinien, branchenspezifische Vorgaben und individuelle Architekturentscheidungen abbilden.
Integration in bestehende Workflows
CSPM-Findings werden in Ihre bestehenden SIEM/SOAR-Workflows, Ticketing-Systeme und Kommunikationskanäle integriert. Kritische Findings erzeugen automatisch Incidents, moderate Findings werden als Tasks priorisiert. Ihre Teams arbeiten in den Tools, die sie kennen — ohne eine zusätzliche Konsole, die niemand regelmäßig prüft.
Regelmäßige Posture Reviews
Einmal einrichten und vergessen funktioniert nicht. In quartalsweisen Reviews analysieren wir die Entwicklung Ihrer Security Posture, identifizieren Trends und passen Policies an veränderte Anforderungen an. Sie erhalten einen konkreten Bericht mit priorisierten Empfehlungen — kein 200-seitiges PDF, sondern ein fokussierter Maßnahmenplan.
Fazit
Cloud-Fehlkonfigurationen sind kein Randproblem — sie sind die Ursache der überwältigenden Mehrheit aller Cloud-Sicherheitsvorfälle. CSPM ist die Grundlage, um diese Risiken systematisch zu erkennen, zu priorisieren und zu eliminieren. Die Kombination aus kontinuierlichem Monitoring in der Laufzeitumgebung und Shift-Left-Prüfungen in der CI/CD-Pipeline schafft eine Verteidigung in der Tiefe, die manuelle Reviews und punktuelle Audits nicht leisten können.
Cloud-Risiken erkennen, bevor sie zum Incident werden. In einem Cloud Security Assessment analysieren wir Ihre AWS-, Azure- und GCP-Umgebungen auf Fehlkonfigurationen, überprivilegierte Rollen und fehlende Sicherheitskontrollen — und liefern einen priorisierten Maßnahmenplan, mit dem Ihr Team sofort handlungsfähig ist. Jetzt Erstgespräch vereinbaren.