Ein Unternehmen aus dem Logistikbereich hatte seinen jährlichen Sicherheits-Audit im Oktober bestanden. Compliance-Score: 94 von 100. Keine kritischen Findings. Drei Monate später wurde ein S3-Bucket öffentlich zugänglich gefunden, der Kundendaten enthielt. Der Bucket war nach dem Audit angelegt worden. Er war nie Teil eines Scans gewesen.
Das ist kein Zufall und kein Versagen eines einzelnen Entwicklers. Es ist ein strukturelles Problem: Compliance-Prüfungen messen den Sicherheitszustand zu einem bestimmten Zeitpunkt. Cloud-Infrastruktur ist dynamisch und verändert sich täglich.
Was Cloud Security Posture Management ist
CSPM – Cloud Security Posture Management – ist eine Kategorie von Tools und Prozessen, die die Cloud-Infrastruktur kontinuierlich gegen Sicherheits- und Compliance-Anforderungen überprüfen. Nicht einmal jährlich, nicht quartalsweise, sondern permanent und automatisiert.
Die bekanntesten Anbieter sind AWS Security Hub (für AWS-native Umgebungen), Microsoft Defender for Cloud (für Azure und Multi-Cloud), Wiz, Lacework und Orca Security. Die Tools unterscheiden sich in Abdeckung, Tiefe und Kosten erheblich – aber das Grundprinzip ist dasselbe: Konfigurationsänderungen werden in Echtzeit oder in kurzen Intervallen erkannt und gegen ein Policy-Framework bewertet.
CSPM ist damit nicht dasselbe wie ein Compliance-Audit-Tool. Es ist kein Reporting-Mechanismus für den Vorstand. Es ist ein operatives Sicherheitswerkzeug.
Der Unterschied zwischen Compliance und Sicherheit
Compliance bedeutet, dass eine Infrastruktur zu einem Prüfungszeitpunkt definierte Anforderungen erfüllt. CIS Benchmarks, ISO 27001, BSI IT-Grundschutz, SOC 2 – diese Frameworks definieren, was “sicher genug” bedeutet, und ermöglichen externe Bestätigung dieses Zustands.
Das Problem: Zwischen zwei Prüfungen passiert in Cloud-Umgebungen sehr viel. Ressourcen werden erstellt, Konfigurationen geändert, Berechtigungen angepasst. Ein S3-Bucket, der heute versehentlich öffentlich gestellt wird, erscheint im nächsten Jahresaudit nicht – weil das nächste Audit zehn Monate entfernt ist.
Sicherheit hingegen ist kein Zustand, sondern ein kontinuierlicher Prozess. Konfigurationsdrift – die schleichende Abweichung der tatsächlichen Infrastruktur vom definierten Sollzustand – ist eines der häufigsten Einfallstore für Incidents in Cloud-Umgebungen. Nicht Angriffe auf Software-Schwachstellen, sondern falsch konfigurierte Ressourcen, die für Insider oder Außenstehende zugänglich sind.
Typische Risikoszenarien in der Praxis
Wir sehen in Cloud-Umgebungen regelmäßig ähnliche Konfigurationsfehler, die ohne kontinuierliches Monitoring lange unentdeckt bleiben:
Zu weitreichende IAM-Berechtigungen. Service-Accounts oder Nutzer-Rollen, die ursprünglich für eine spezifische Aufgabe erstellt wurden, sammeln über die Zeit Berechtigungen an. Das Prinzip der minimalen Rechte – Least Privilege – existiert auf dem Papier, wird aber in der Praxis selten systematisch durchgesetzt. Tools wie AWS IAM Access Analyzer oder Azures Privileged Identity Management helfen, sind aber kein Ersatz für kontinuierliche Policy-Enforcement.
Öffentlich zugängliche Storage-Ressourcen. S3-Buckets, Azure Blob Storage, Google Cloud Storage Buckets – sie sind per Default private, aber eine einzelne Konfigurationsänderung macht sie zugänglich. Das passiert in Entwicklungsumgebungen bewusst, wird nach dem Test nicht zurückgesetzt, und die Konfiguration driftet in Richtung Produktion.
Unverschlüsselte Daten-Stores. In vielen Umgebungen gibt es Ressourcen, die nach Compliance-Anforderung verschlüsselt sein müssten – aber in einer Testumgebung ohne Encryption angelegt und dann in eine andere Umgebung kopiert wurden.
Ungepatchte Instanzen. Security-Gruppen und Netzwerkkonfigurationen sind ein häufiges CSPM-Finding, aber die eigentliche Schwachstelle liegt oft auf der Betriebssystemebene: Instanzen, die seit Wochen oder Monaten kein Patch-Management durchlaufen haben.
Was ein realistischer Ansatz ausmacht
CSPM ist ein Werkzeug, kein Ersatz für eine Sicherheitsstrategie. Wer ein CSPM-Tool einführt und erwartet, dass damit alle Probleme verschwinden, wird von der Flut an Findings überrollt. Typische Erstinstallationen zeigen hunderte bis tausende von Findings – eine Zahl, die kein Team ad hoc abarbeiten kann.
Der sinnvolle Einstieg ist nicht “alle Findings beheben”, sondern Priorisierung nach Risiko und Exponierung. Findings in Produktionsumgebungen mit Kundendaten haben andere Priorität als Findings in isolierten Entwicklungsumgebungen. Öffentlich zugängliche Ressourcen haben andere Dringlichkeit als interne Konfigurationsfehler.
Praktisch bewährt hat sich ein dreistufiger Ansatz: Erstens eine Baseline-Analyse, die den tatsächlichen Sicherheitszustand der Umgebung zeigt – nicht geschönt. Zweitens die Definition von Policies, die für das eigene Unternehmen tatsächlich relevant sind, statt einen Compliance-Framework-Standard 1:1 zu übernehmen. Drittens die Integration von CSPM-Alerts in bestehende Incident-Prozesse, sodass kritische Findings nicht in einem Dashboard warten, das niemand täglich anschaut.
Der letzte Punkt ist der häufigste Fallstrick. Ein CSPM-Tool, dessen Findings in einem separaten Interface auflaufen und nicht in die bestehenden Arbeitsabläufe integriert sind, wird nach drei Monaten nicht mehr aktiv genutzt. Die Findings akkumulieren, niemand fühlt sich zuständig, und der Mehrwert des Tools ist verloren.
Cloud-Sicherheit ist operativ. Sie entsteht nicht durch eine jährliche Prüfung, sondern durch kontinuierliche Aufmerksamkeit – mit den richtigen Werkzeugen, den richtigen Prozessen und klarer Verantwortlichkeit.