--- title: "Die ersten 24 Stunden mit dem Security Command Center: Was niemand sagt" description: "Was wirklich passiert, wenn du das Google Security Command Center zum ersten Mal öffnest: 764 Findings, einstellige Compliance — und ein ruhiger Plan, das Richtige zuerst zu beheben." author: Aleksei Aleinikov date: 2026-06-29 lang: de tags: [security, google-cloud, scc, security-command-center, cloud-security, gcp] canonical: https://www.alekseialeinikov.com/de/blog/topics/security/erste-24-stunden-google-cloud-security-command-center-2026 source: alekseialeinikov.com --- # Die ersten 24 Stunden mit dem Security Command Center: Was niemand sagt Du aktivierst das Security Command Center, wartest auf den ersten Scan und öffnest das Dashboard in der Erwartung einer ordentlichen grünen Checkliste. Stattdessen siehst du **764 Findings**, einen HIPAA-Score von **18%** und eine Wand aus Rot, die du gestern nicht angerichtet hast. Der Instinkt sagt: Panik oder Tab schließen. Beides ist falsch. Der erste Tag mit **SCC** geht nicht darum, alles zu beheben — sondern darum, das Rauschen lesen zu lernen, damit du das Richtige in der richtigen Reihenfolge fixt. ![Der Moment, in dem das Security Command Center seinen ersten Scan beendet und die Zahl größer ist als dein Team.](https://www.alekseialeinikov.com/blog/scc-first-24-hours-2026.webp) Das ist der Feldführer, den ich mir an Tag eins gewünscht hätte: wie man die Scores liest, warum die Zahlen erschrecken und die kurze Liste der Dinge, die zuerst wirklich zählen. ## Zuerst: Was ist das Security Command Center? Wenn du neu bei GCP bist: Das **Security Command Center (SCC)** ist das eingebaute Dashboard, das deine Cloud laufend scannt und zeigt, wo du exponiert bist. Es macht drei Dinge gleichzeitig: **Asset-Inventar** (was du hast), **Misconfig-Scanner** (Buckets, Firewalls, Service-Accounts) und **Compliance-Mapping** (CIS, ISO, HIPAA, PCI). Stell es dir als kostenlosen Rauchmelder vor, der genau in dem Moment losschreit, als du ihn eingeschaltet hast. Es kommt in zwei Stufen, und welche du hast, ändert das ganze Erlebnis: - **Standard** — kostenlos, auf jedem Projekt. Liefert Security Health Analytics (Misconfigs) und Basis-Compliance-Scores. Das sehen 90% der Einsteiger zuerst. - **Premium / Enterprise** — kostenpflichtig. Ergänzt Threat Detection, Attack-Path-Simulation und laufendes CIS-Scoring. Mit Standard sind die erschreckenden Zahlen *Konfig-Hygiene*, keine Live-Angriffe. Aktivieren ist ein Schalter in der Konsole (oder ein Befehl), dann wartest du auf den ersten Scan: ```bash # Security Health Analytics auf Org-Ebene aktivieren gcloud scc settings services enable \ --organization=ORG_ID \ --service=security-health-analytics ``` Gib ihm 10–30 Minuten, aktualisiere — und dann erscheint die 764. Alles Folgende ist, wie du ruhig bleibst. ## Warum die Zahlen erschreckend wirken Die Angst kommt aus einem Lesefehler. SCC zeigt dir keine 764 *Probleme*. Es zeigt 764 *Findings* — jedes Asset gegen jeden Detektor und jeden Standard geprüft, aufgefächert in eine Zeile pro Schnittmenge. Ein Fehler vervielfacht sich schnell: - Ein Default-Service-Account → markiert von CIS, Cloud Controls Matrix und ISO zugleich. - Ein öffentlicher Bucket → Public-Access-, fehlende Logging- und schwache Retention-Findings. - Eine offene Firewall-Regel → reißt mehrere Foundation-Benchmarks gleichzeitig. So lesen sich ein Dutzend echte Ursachen leicht als hunderte Findings. Die Aufgabe an Tag eins ist, diese Auffächerung wieder auf die wenigen Ursachen darunter zu reduzieren. ## Compliance-Scores sind eine Checkliste, keine Note Die erschreckendste Zahl — HIPAA bei 18% — ist die am meisten missverstandene. Der Prozentsatz heißt nicht „du bist zu 18% sicher". Er heißt „18% der HIPAA-Kontrollen, die SCC mappen kann, bestehen aktuell". Der Rest sind meist Kontrollen, für die du gar nicht im Geltungsbereich bist. Behandle jeden Standard als Liste benannter Kontrollen, nicht als Schulnote: - **CIS GCP Foundation** bei 66% ist deine echte Baseline — zuerst beheben. - **HIPAA / ISO 27001** zählen nur, wenn du ihnen tatsächlich unterliegst. - **CIS Kubernetes** bei 100% heißt: sauber — lass es in Ruhe. Wenn du kein Gesundheitsunternehmen bist, ist ein 18%-HIPAA-Score Information, kein Vorfall. ## Triage: Gruppieren, nicht scrollen Lies Findings nie als flache Liste. Gruppiere sie, und das Rauschen wird zur kurzen To-do-Liste. ```text # Nach Kategorie, Anzahl und Severity gruppieren — das ist dein echtes Backlog Kategorie Anzahl Severity PUBLIC_BUCKET_ACL 41 HIGH DEFAULT_SERVICE_ACCOUNT_USED 120 MEDIUM OPEN_FIREWALL 63 HIGH AUDIT_LOGGING_DISABLED 210 MEDIUM ``` 210 Logging-Findings sind ein Fix, 210-mal angewendet, nicht 210 Entscheidungen. Sortiere nach *Ursache*, nicht nach Zeilenzahl. ## Fix-Liste für Tag eins Ignoriere den langen Schwanz. Schließe am ersten Tag die billigsten Wege, die ein Angreifer wirklich nimmt: 1. **Öffentliche Exposition** — Buckets, IPs, weltoffene Firewall-Regeln. Das ist die Haustür. 2. **Identität** — Default- und überprivilegierte Service-Accounts killen; sonst hilft nichts, wenn Creds offen sind. 3. **Audit-Logging** — überall aktivieren, damit du später ermitteln kannst. 4. **Dann** von oben nach unten: Critical → High, Low ignorieren, bis der Rest sauber ist. Hol das Backlog per gcloud statt 764 Zeilen anzuklicken: ```bash gcloud scc findings list ORG_ID \ --filter="state=\"ACTIVE\" AND severity=\"CRITICAL\"" \ --format="table(category, resourceName)" ``` ## Die großen Drei konkret beheben Für Einsteiger ist die Lücke nie „was ist falsch“ — das sagte SCC bereits. Sondern „welcher Befehl schließt es“. Die drei Kategorien, die den Großteil der 764 ausmachen, mit Fix: **Öffentlicher Bucket.** Entferne den allUsers-Zugriff und aktiviere Uniform Access: ```bash gsutil iam ch -d allUsers gs://my-bucket gsutil ubla set on gs://my-bucket ``` **Offene Firewall (0.0.0.0/0).** Beende die weltoffene Regel und beschränke SSH auf einen bekannten Bereich: ```bash gcloud compute firewall-rules update allow-ssh \ --source-ranges=203.0.113.0/24 ``` **Default-/überprivilegierter Service-Account.** Nutze nicht die Auto-Compute-SA, sondern eine dedizierte mit minimalen Rechten: ```bash gcloud iam service-accounts create app-sa --display-name="App SA" gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:app-sa@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/storage.objectViewer" ``` Schließe diese drei und sieh die Zahl um hunderte fallen — jeder Fix räumt jeden Standard ab, der denselben Fehler referenzierte. ## Wie man ein Severity-Label liest Severity ist deine Prioritätsschlange. Einsteiger verbrennen Tag eins mit Medium-Rauschen — tu das nicht. | Severity | Bedeutet | Aktion an Tag eins | | --- | --- | --- | | **Critical** | Aktiver Weg zu Daten oder Vollkontrolle | Heute fixen | | **High** | Öffentliche Exposition / schwache Identität | Diese Woche fixen | | **Medium** | Hygiene (Logging, Defaults) | Sammelfix, meist eine Änderung | | **Low** | Best-Practice-Aufräumen | Ignorieren, bis der Rest sauber ist | ## Mute mit Begründung, nie still Die meisten der 764 sind akzeptiertes Risiko oder nicht zutreffend. Muten hält echtes Risiko sichtbar — aber mute mit Regel, nicht per Klick. Gemutete Findings zählen weiter in Compliance-Reports, der Audit-Trail bleibt intakt. ```bash gcloud scc muteconfigs create not-applicable-hipaa \ --organization=ORG_ID \ --filter="category=\"HIPAA\" AND resourceName:\"dev-project\"" \ --description="Dev-Projekt, nicht im HIPAA-Scope — geprüft 2026-06" ``` Ein mit Begründung gemutetes Finding ist Governance. Ein still gemutetes Finding ist ein künftiger Vorfall. ## Deine Checkliste für Tag eins Wenn du nur eins behältst, mach das in dieser Reihenfolge: 1. Tier prüfen — Standard heißt Konfig, kein Breach. 2. Findings nach Kategorie gruppieren; Zeilenzahl ignorieren. 3. Öffentliche Buckets und 0.0.0.0/0-Firewall-Regeln schließen. 4. Default-Service-Accounts durch Least-Privilege ersetzen. 5. Audit-Logging org-weit aktivieren. 6. Nicht zutreffende Standards mit Begründung muten. 7. Critical → High abarbeiten; Low für nächste Woche lassen. Das ist ein ruhiger erster Tag. Der Rest ist Iteration. ## Was niemand sagt Das Dashboard ist bewusst alarmierend gestaltet, damit du es nicht ignorierst. Aber die Zahl ist keine Note — sie ist die Auffächerung weniger echter Fehler. Behebe öffentliche Exposition und Identität, schalte Logging an, mute das Rauschen mit Begründung, und die Prozente steigen von selbst. Tag eins ist Triage, keine Operation. Gehärtete CI/CD und Supply-Chain-Kontrollen kommen danach — aber erst, wenn die Haustür zu ist.