Cloud Security Posture Management (CSPM) bewertet die Konfiguration der Cloud-Steuerungsebene (Control Plane) im Hinblick auf festgelegte Sicherheitsanforderungen. In AWS, Azure und Google Cloud hilft CSPM dabei festzustellen, ob Ressourcen, Identitäten und Einstellungen auf Kontoebene dem definierten Sicherheitsstatus entsprechen. Es analysiert keine Nutzdaten von Anwendungspaketen und ersetzt auch nicht die Erkennung aktiver Angriffe zur Laufzeit.
CSPM-Tools arbeiten in der Regel ohne Agenten. Sie nutzen Anmeldeinformationen mit Lesezugriff, um die APIs der jeweiligen Anbieter aufzurufen, ein Ressourceninventar zu erstellen und dieses anhand von Regeln zu überprüfen. Beispiele hierfür sind AWS Config und Security Hub, Microsoft Defender for Cloud, Google Security Command Center sowie Open-Source-Scanner wie Prowler und Steampipe. Wenn eine Ressource eine dieser Regeln nicht erfüllt, meldet das Tool das Ergebnis als Finding (Befund).
Ein Finding ist eine Aussage über einen beobachtbaren Konfigurationszustand, etwa die Zugriffseinstellung einer Speicherressource oder die einer Identität zugewiesene Berechtigung. Sein Wert hängt von den Nachweisen ab, die der CSPM-Prozess auslesen kann, sowie von der Regel, die zur Interpretation dieser Nachweise verwendet wird.
Wir können nun die Anbietergrenzen und Nachweisquellen nachvollziehen, die bei einer CSPM-Bewertung zum Einsatz kommen.
Konfigurationsnachweise beschreiben den Zustand, den die Steuerungsebene (Control Plane) des Anbieters zum Zeitpunkt der Datenerfassung meldet. Aktivitätsprotokolle liefern eine Historie von Verwaltungsaktionen, etwa wenn ein Akteur (Principal) eine Richtlinie ändert oder eine Ressource erstellt. Bei AWS sind dies AWS Config und CloudTrail, bei Azure der Azure Resource Graph und das Activity Log, und bei Google Cloud das Cloud Asset Inventory sowie die Cloud Audit Logs. Zusammengenommen können diese Quellen belegen, dass eine Einstellung existiert, und möglicherweise aufzeigen, wer sie geändert hat; sie beweisen jedoch weder, dass eine Anwendungsanfrage erfolgreich war, noch dass auf Daten zugegriffen wurde oder ein Netzwerkpaket sicher war.
[Quellen][/Quellen]
Configuration Drift (Konfigurationsabweichung) bezeichnet die Differenz zwischen der genehmigten oder erwarteten Konfiguration und der aktuell beobachteten Konfiguration. Eine solche Abweichung kann durch eine manuelle Änderung, einen Automatisierungsfehler, ein Deployment-Rollback (das einen älteren Wert wiederhergestellt hat) oder eine außerhalb des vorgesehenen Bereitstellungsprozesses erstellte Ressource entstehen. CSPM erkennt die Abweichung nur, wenn die Ressource im Inventar erfasst ist und entsprechende Nachweise vorliegen.
[Quellen][/Quellen]
Grenzen der Nachweisführung Ein CSPM-Befund stellt einen Konfigurationszustand innerhalb des Verantwortungsbereichs des Anbieters fest. Er belegt für sich genommen weder die Ausnutzbarkeit einer Schwachstelle noch geschäftliche Auswirkungen oder einen erfolgreichen Zugriff.
[Quellen][/Quellen]
Ein Befund kann ein False Positive (falsch-positives Ergebnis) sein, wenn die ausgewertete Regel ein Problem meldet, obwohl der beobachtete Zustand den geltenden Anforderungen entspricht. So könnte beispielsweise eine zu allgemein formulierte Regel einen Endpunkt markieren, der zum Internet hin offen ist – dies jedoch bewusst und geschützt durch Sicherheitsmechanismen, die von der Regel nicht berücksichtigt werden. Die sicherste Vorgehensweise besteht darin, die Anforderungen, den Zweck der Ressource, den Expositions-Pfad und kompensierende Kontrollmechanismen zu überprüfen, bevor Änderungen an der Produktionskonfiguration vorgenommen werden.
[Quellen][/Quellen]
Fehlende Leseberechtigungen führen zum gegenteiligen Problem. Wenn die CSPM-Identität eine Ressource nicht auflisten, eine Richtlinie nicht abrufen oder eine relevante Einstellung nicht prüfen kann, ist die Bewertung möglicherweise unvollständig, anstatt ein eindeutiges Ergebnis zu liefern. Eine nicht verwaltete Ressource hat praktisch dieselben Auswirkungen, wenn sie außerhalb der Konten, Abonnements, Projekte oder des Inventarbereichs liegt, die bewertet werden.
[Quellen][/Quellen]
Auch das Modell der geteilten Verantwortung setzt Grenzen. Der Cloud-Anbieter betreibt den zugrundeliegenden Dienst, während der Kunde für Entscheidungen wie Identitätszuweisung, Netzwerkexposition, Ressourcenrichtlinien und Konfiguration des Datenzugriffs verantwortlich bleibt. Ein erfolgreich bestandener Sicherheitscheck (Posture Check) überträgt diese Verantwortung nicht und belegt auch nicht die Wirksamkeit aller vom Kunden verwalteten Kontrollmechanismen.
[Quellen][/Quellen]
Entscheidungsregel Werten Sie das Ausbleiben von Befunden nur dann als aussagekräftig, wenn zuvor der Geltungsbereich, die Berechtigungen zur Datenerfassung, die Anwendbarkeit der Regeln sowie der Zeitrahmen der Nachweiserhebung bestätigt wurden.
Wir verwenden eine bewusst klein gehaltene Workload namens orders-api. Sie stellt einen Anwendungsdienst dar, der auf Port 8080 auf Anfragen wartet und Bestelldaten in einer für den jeweiligen Anbieter nativen Objektspeicher-Ressource ablegt. Jede Version verbleibt innerhalb der Grenzen ihres jeweiligen Anbieters; es wird also davon ausgegangen, dass weder Identitäten noch Speicherberechtigungen oder Sicherheitsbefunde von einer Cloud in eine andere übertragen werden.
In AWS nutzt orders-api die Rolle orders-api-role und den Bucket orders-data-s3. In Azure verwendet sie die verwaltete Identität orders-api-mi und das Speicherkonto ordersdatast. In der Google Cloud kommen das Dienstkonto orders-api-sa und der Bucket orders-data-gcs zum Einsatz. Diese Bezeichner sind fiktiv, doch das damit veranschaulichte Abgrenzungsprinzip lässt sich wiederverwenden.
Wir können untersuchen, wie die jeweilige Workload-Identität auf die Ressourcen ihres eigenen Anbieters beschränkt bleibt.