Eigenes CSPM auf GCP bauen: Security Command Center vs. Open Source

Du holst ein Angebot für eine kommerzielle CSPM-Plattform für deine Google-Cloud-Landschaft ein, und die Zahl kommt mit mehr Nullen zurück als deine monatliche Cloud-Rechnung. Dabei kostet das eigentliche Problem — ein öffentlicher Bucket, ein Service-Account mit Owner, eine weltweit offene Firewall — nichts zu finden und fünf Minuten zu beheben.

Was die Sales-Folien verschweigen: Auf GCP hast du das meiste von CSPM bereits — kostenlos — und alles, was fehlt, lässt sich mit Open-Source-Tools bauen. Du brauchst keine sechsstellige Plattform, um zu wissen, ob deine Cloud sicher konfiguriert ist.

Das ist der Feldführer, den ich mir vor diesem Sales-Call gewünscht hätte: was CSPM wirklich ist, die zwei ehrlichen Wege dorthin auf GCP und wie du entscheidest, welcher — oder welche Mischung — zu deinem Team passt.

Zuerst: Was ist CSPM eigentlich?

CSPM — Cloud Security Posture Management — ist ein schicker Name für eine simple Aufgabe: laufend prüfen, ob deine Cloud sicher gebaut ist. Es scannt deine Konfiguration gegen bekannte Soll-Zustände und Compliance-Standards und reicht dir dann die Liste dessen, was falsch ist: öffentlicher Speicher, offene Firewalls, unverschlüsselte Disks, überprivilegierte Identitäten, deaktiviertes Logging.

Eine Verwechslung sollte man gleich an Tag eins ausräumen:

• CSPM ist Posture. “Ist meine Cloud sicher konfiguriert?” Es findet Fehlkonfigurationen, bevor sie missbraucht werden.
• Threat Detection ist Laufzeit. “Greift mich gerade jemand an?” Es liest Logs und Verhalten, um laufende Angriffe zu erkennen.

CSPM ist die verschlossene Tür; Threat Detection ist der Alarm, der losgeht, wenn jemand das Schloss knackt. In diesem Artikel geht es um die Tür. Auf GCP bekommst du sie auf zwei Arten.

Weg 1: Die eingebaute Baseline (Security Command Center)

Wenn du auf GCP bist, hast du bereits eine CSPM-Engine ungenutzt herumstehen: Security Command Center (SCC). Die kostenlose Standard-Stufe erledigt die Kern-Posture-Aufgabe auf jedem Projekt — Asset-Inventur, Fehlkonfigurations-Detektoren (Security Health Analytics) und Compliance-Mapping auf CIS, ISO, PCI und mehr.

Das Einschalten ist ein einziger Schalter:

# Security Health Analytics auf Org-Ebene aktivieren
gcloud scc settings services enable \
  --organization=ORG_ID \
  --service=security-health-analytics

Warte den ersten Scan ab, und du bekommst eine native Posture-Sicht, die kein externes Tool erreicht — denn SCC sieht deine Ressourcen genau so, wie Google sie sieht, ohne API-Verzögerung und ohne fehlende Dienste. Hol dir das echte Backlog direkt aus der CLI:

gcloud scc findings list ORG_ID \
  --filter="state=\"ACTIVE\" AND severity=\"HIGH\"" \
  --format="table(category, resourceName)"

Wo Standard endet: kein Threat Detection (das ist Premium), kein Multi-Cloud, und die Detektoren sind fix — “markiere jeden Bucket ohne unser Pflicht-Label data-owner” lässt sich nicht einfach ergänzen. Für einen reinen GCP-Betrieb, der eine schnelle, verlässliche Baseline will, reicht das oft. Für alles jenseits der Ränder baust du selbst.

Wenn du SCC noch nie geöffnet hast, starte mit Die ersten 24 Stunden mit dem Security Command Center — es führt durch den erschreckenden ersten Scan, bevor du es erweiterst.

Weg 2: Der Selbstbau-Stack (Open Source)

Wenn SCCs feste Detektoren oder die GCP-only-Sicht nicht reichen, gibt dir ein Open-Source-Stack CSPM, das du vollständig kontrollierst. Drei Tools decken fast jeden Bedarf ab, und sie lassen sich kombinieren:

Prowler — der schnellste Weg zu einem Compliance-Report. Zeig ihn auf ein Projekt, und er fährt hunderte Checks gegen CIS, ISO und PCI:

# Ein Befehl, ein voller CIS-gemappter Posture-Report für ein GCP-Projekt
prowler gcp --project-ids my-project \
  --compliance cis_3.0_gcp \
  --output-formats html json

Cloud Custodian — Policy-as-Code, die remediieren kann, nicht nur berichten. Du schreibst Regeln in YAML, und Custodian setzt sie durch:

# c7n-gcp: Buckets finden, die öffentlichen Zugriff erlauben
policies:
  - name: gcs-no-public-buckets
    resource: gcp.bucket
    filters:
      - type: iam-policy
        key: "bindings[?members[?contains(@, 'allUsers')]]"
        value: present

Steampipe — frage deine Cloud wie eine SQL-Datenbank ab und schreibe Posture-Checks als SELECT:

-- Jeder Bucket in der Org, der weltweit lesbar ist
select name, location
from gcp_storage_bucket
where iam_policy -> 'bindings' @> '[{"members":["allUsers"]}]';

Der Haken ist genau das, was die Grafik sichtbar macht: ein Tool ist noch kein System. Damit das dauerhaft läuft, verpackst du es in eine Pipeline — Cloud Asset Inventory als Quelle, ein Scanner auf Cloud Run, ausgelöst per Cloud Scheduler, Findings über Pub/Sub, Ergebnisse landen in BigQuery oder Slack. Diese Pipeline ist mächtig und portabel, aber du baust, betreibst und wartest sie selbst.

Der ehrliche Vergleich

Kein Weg ist “besser”. Sie optimieren für unterschiedliche Zwänge, und die richtige Antwort hängt davon ab, welcher Zwang gerade drückt.

Lies die Matrix nach deinem Druckpunkt:

• Du willst bis zum Mittag eine GCP-Baseline. SCC Standard. Ein Schalter, native Abdeckung, keine Pipeline.
• Du fährst auch AWS und Azure. Open Source. Prowler und Custodian sprechen alle drei Clouds aus einem Regelsatz.
• Du hast organisationsspezifische Regeln (“jeder Prod-Bucket braucht ein data-owner-Label”). Open Source — SCCs Detektoren sind fix; Custodian und Steampipe lassen dich eigene schreiben und versionieren.
• Du brauchst auditierbare Policy-as-Code. Open Source, in Git, reviewt wie jeder andere Code.
• Du willst die Config-Sicherheits-Hälfte, ohne etwas zu zahlen oder zu bauen. SCC Standard, Punkt.

Du musst dich gar nicht entscheiden

Das Framing “SCC vs. Open Source” verkauft Artikel, aber in Produktion ist der starke Zug beides. Lass Security Command Center den dauerhaft aktiven nativen Boden sein — es ist kostenlos, sieht GCP perfekt und kostet dich einen einzigen Schalter. Ergänze dann Open-Source-Scanner nur für die Lücken, die SCC wirklich lässt: Multi-Cloud-Abdeckung, eigene Organisations-Policy und portable Regeln in der Versionsverwaltung.

Diese Schichtung gibt dir eine verlässliche Baseline, die du nicht bauen musstest, plus genau die eigene Tiefe, die du brauchst — ohne für die 80%, die du schon hattest, eine Plattform zu bezahlen.

Der Teil, der wirklich zählt

Egal welchen Weg du wählst — behalte im Kopf, wofür CSPM da ist. Das Dashboard ist nicht das Produkt. Hunderte Findings in einer Konsole, die niemand mit einer Aktion verdrahtet hat, sind keine Sicherheit — sie sind eine sehr detaillierte Art, sich schlecht zu fühlen.

Der Wert liegt im Remediation-Loop: Ein Finding wird zu einem Ticket, einem Fix oder einer Auto-Remediation, und der nächste Scan bestätigt, dass es weg ist. SCC gibt dir diesen Loop nativ; Cloud Custodian gibt ihn dir als Code. Bau, was passt — aber bau den Loop, nicht nur den Scanner.

Das Fazit

CSPM auf GCP kauft man nicht — man setzt es zusammen. Security Command Center Standard ist eine kostenlose, native Baseline, die die meisten Teams heute einschalten sollten. Ein Open-Source-Stack aus Prowler, Cloud Custodian und Steampipe deckt die Multi-Cloud-, Eigenregel- und Policy-as-Code-Bedarfe ab, die SCC nicht abdeckt. Eine bezahlte Plattform rechnet sich erst, wenn du im echten Maßstab über viele Clouds und Accounts hinweg bist.

Starte mit dem kostenlosen Schalter. Ergänze Open Source dort, wo es wehtut. Verdrahte den Remediation-Loop. Das ist CSPM — von dir gebaut, zum Preis der Compute, auf der es läuft.