Google Cloud absichern: die 5 Bausteine in der richtigen Reihenfolge

Die Google Cloud absichern heißt: fünf Bereiche in einer festen Reihenfolge abarbeiten — erst die IAM-Rechte und die Zwei-Faktor-Anmeldung, dann das Logging, danach die Firewall auf „standardmäßig alles blocken“, anschließend die Verschlüsselung und zuletzt die Dauerüberwachung. In dieser Folge schließt du die häufigsten Fehlkonfigurationen zuerst — und sperrst dich unterwegs nicht selbst aus dem eigenen Projekt aus.

Was sich seit 2024 geändert hat

Wenn du eine ältere Anleitung im Kopf hast, sind drei Punkte inzwischen anders:

• Zwei-Faktor-Anmeldung ist keine freiwillige Härtung mehr. Google hat im November 2024 angekündigt, MFA für alle Google-Cloud-Konten verpflichtend zu machen, gestaffelt bis Ende 2025 — zuerst für Passwort-Logins, zuletzt auch für föderierte Anmeldungen über einen externen Identitätsanbieter (Cybersecurity Dive).
• Neue Organisationen starten härter. Für alle Google-Cloud-Organisationen, die ab dem 3. Mai 2024 angelegt wurden, erzwingt Google sieben Sicherheits-Organisationsrichtlinien von sich aus. Ältere Organisationen bekommen diese Voreinstellung nicht nachträglich — dort musst du selbst nachziehen.
• Die Firewall hat einen Nachfolger bekommen. Neben den klassischen VPC-Firewallregeln gibt es die Firewall-Policies der Cloud NGFW (Next Generation Firewall). Sie fassen Regeln zu einem Objekt zusammen, das für mehrere Netzwerke gleichzeitig gilt.

In dieser Reihenfolge solltest du die Google Cloud absichern

Die Reihenfolge ist kein Geschmacksthema. Rechte und Protokolle zuerst, weil sie nichts kaputtmachen können; Netzwerk-Sperren später, weil genau dort der Zugang verloren geht, wenn man sich vertut:

1. IAM-Rechte zusammenstreichen und Dienstkonten aufräumen.
2. Zwei-Faktor-Anmeldung für alle Konten erzwingen, zuerst für Administratoren.
3. Logging aktivieren: Audit-Logs und VPC-Flow-Logs nach Cloud Logging.
4. Firewall auf Default-Deny umstellen — mit gesichertem Verwaltungszugang.
5. Verschlüsselung prüfen, danach Security Command Center und Organisationsrichtlinien als Dauerlauf.

Schritt 1: IAM-Rechte auf das Nötigste zusammenstreichen

IAM (Identity and Access Management) regelt, welche Person und welcher Dienst auf welche Ressource zugreifen darf. Die Vorgabe von Google ist eindeutig: keine Basisrollen vergeben, solange es eine Alternative gibt, sondern die engste passende vordefinierte oder eine eigene Rolle (Google-Dokumentation zu IAM).

• Basisrollen aussortieren. „Inhaber“, „Bearbeiter“ und „Betrachter“ (Owner/Editor/Viewer) gelten projektweit für fast alle Dienste. Ein Konto mit „Bearbeiter“ kann in den meisten Diensten Ressourcen anlegen und löschen — das ist für den Produktivbetrieb zu grob.
• Rollen-Empfehlungen auswerten. Der IAM-Recommender vergleicht vergebene Rechte mit der tatsächlichen Nutzung und schlägt engere Rollen vor. Der bequemste Einstieg in gewachsene Berechtigungen, weil du nicht raten musst, was gebraucht wird.
• Rollen an Gruppen statt an Personen. Wer die Firma verlässt, wird aus einer Gruppe entfernt — sonst musst du Rechte in jedem Projekt einzeln suchen.
• Dauer-Admin durch Zeitfenster ersetzen. Mit dem Privileged Access Manager beantragt jemand erhöhte Rechte für eine feste Dauer; nach Ablauf entzieht Google die Rolle automatisch und der Vorgang steht im Audit-Log. Das ersetzt den einen Account, der „für alle Fälle“ Inhaber ist.

Dienstkonten und Schlüsseldateien

Ein Dienstkonto (Service Account) ist ein technisches Konto für Programme und virtuelle Maschinen — kein Mensch meldet sich damit an. Der Klassiker beim Aufräumen ist das Standard-Dienstkonto, das bei der Projekterstellung die Editor-Rolle mitbekommen hat und inzwischen in drei Pipelines hängt: erst die tatsächliche Nutzung ansehen, dann kürzen, sonst steht die Automatisierung.

Drei Regeln, die aus der Google-Dokumentation kommen und nicht verhandelbar sind:

• Keine automatische Rollenvergabe an Standard-Dienstkonten. Die Organisationsrichtlinie dafür heißt constraints/iam.automaticIamGrantsForDefaultServiceAccounts und ist in Organisationen ab dem 3. Mai 2024 bereits aktiv.
• Schlüsseldateien vermeiden. Google rät ausdrücklich von Dienstkonto-Schlüsseln ab, wenn es eine Alternative gibt — sie laufen nicht ab und landen erfahrungsgemäß irgendwann in einem Repository. Die Richtlinien disableServiceAccountKeyCreation und disableServiceAccountKeyUpload unterbinden sie organisationsweit.
• Für Workloads außerhalb von Google Cloud stattdessen Workload Identity Federation nutzen: Der externe Dienst weist seine eigene Identität nach und bekommt ein kurzlebiges Token statt einer dauerhaften Schlüsseldatei.

Schritt 2: Zwei-Faktor-Anmeldung für alle

Ein gestohlenes Passwort allein reicht dann nicht mehr für die Anmeldung. Google beziffert den Anteil der Cloud-Nutzer, die vor der Umstellung ausschließlich mit Passwort gearbeitet haben, auf rund 30 Prozent — daher die Pflicht. Praktisch heißt das: Administratoren zuerst umstellen, Hardware-Sicherheitsschlüssel oder Passkeys den SMS-Codes vorziehen und für jedes Konto einen zweiten Faktor hinterlegen, bevor der erste verloren geht. Notfall-Codes gehören an einen Ort außerhalb der Cloud, die du gerade absicherst.

Schritt 3: Logging aktivieren, bevor du etwas zumachst

Ohne Protokolle merkst du einen Vorfall erst, wenn Daten fehlen. Zwei Quellen sind Pflicht:

• Cloud Audit Logs halten fest, wer welche Aktion ausgeführt hat. Die Admin-Activity-Logs schreibt Google ohne Zutun mit. Die Data-Access-Logs — also lesende Zugriffe auf Daten — musst du überwiegend selbst einschalten, und genau die brauchst du hinterher, um zu beantworten, ob jemand etwas gesehen hat.
• VPC-Flow-Logs zeichnen die Netzwerkverbindungen zwischen Instanzen auf. Protokolliere bewusst erlaubten und abgelehnten Verkehr: Erst das vollständige Bild zeigt, wer regelmäßig an einer geschlossenen Tür rüttelt.

Beides fließt in Cloud Logging zusammen. Denk an die Aufbewahrung: Log-Einträge verschwinden nach Ablauf der Aufbewahrungsfrist des jeweiligen Log-Buckets — wenn du längere Nachweise brauchst, richte vorher einen Log-Sink nach Cloud Storage oder BigQuery ein.

Schritt 4: Firewall auf Default-Deny — mit gesichertem Rückweg

Ein VPC (Virtual Private Cloud) ist dein abgeschottetes virtuelles Netzwerk. Eingehender Verkehr ist dort ohnehin implizit gesperrt; das Problem sind die mitgelieferten Regeln des automatisch angelegten „default“-Netzwerks, die SSH, RDP und ICMP aus dem gesamten Internet erlauben. Genau diese Regeln sind bei vielen Projekten die weit offene Tür.

Vorher absichern: Bevor du Port 22 dichtmachst, muss der administrative Ersatzweg stehen und getestet sein — sonst schließt du dich selbst aus. Der saubere Weg ist der Identity-Aware Proxy (IAP): Er baut einen verschlüsselten Tunnel zur VM, die dafür gar keine öffentliche IP-Adresse braucht. Nötig ist eine Firewallregel, die eingehenden Verkehr aus dem Bereich 35.235.240.0/20 auf Port 22 (SSH) beziehungsweise 3389 (RDP) erlaubt (Google-Dokumentation zu IAP TCP-Forwarding). Wer darüber verbinden darf, steuerst du anschließend per IAM statt per IP-Adresse.

Danach gilt der Rest:

• Nur gezielt öffnen, was gebraucht wird — für eine Webanwendung meist ausschließlich TCP 443.
• Erlaubende Regeln auf einzelne Maschinen begrenzen, indem du als Ziel das Dienstkonto oder ein Netzwerk-Tag der VM angibst, statt das ganze Subnetz freizugeben.
• Vor dem Aufräumen die Firewall Insights im Network Intelligence Center ansehen: Sie zeigen ungenutzte und von anderen Regeln verdeckte Einträge — die kannst du am gefahrlosesten zuerst entfernen.
• Für mehrere Projekte lohnt der Umstieg auf Firewall-Policies statt einzelner VPC-Regeln. Eine VPC-Firewallregel gilt immer nur für ein Netzwerk, eine Netzwerk-Firewall-Policy lässt sich an mehrere Netzwerke hängen und als Paket aktualisieren; hierarchische Policies setzen Leitplanken auf Organisations- oder Ordnerebene, die ein einzelnes Projekt nicht aufweichen kann (Google-Dokumentation zu Firewall-Policies). Die kostenpflichtige Enterprise-Stufe der Cloud NGFW ergänzt Angriffserkennung, TLS-Inspektion sowie Filter nach Domainnamen und Herkunftsland.

Schritt 5: Verschlüsselung — meistens schon erledigt

Gespeicherte Daten verschlüsselt Google standardmäßig, ohne dass du etwas konfigurierst. Interessant wird es erst, wenn Vorgaben verlangen, dass der Schlüssel nachweislich dir gehört: Dann verwaltest du ihn mit CMEK (Customer-Managed Encryption Keys) im Cloud Key Management Service selbst und entscheidest, wann er rotiert oder zurückgezogen wird. Der Preis dafür ist Verantwortung — ein versehentlich deaktivierter oder gelöschter Schlüssel macht die zugehörigen Daten unlesbar. Bevor du CMEK produktiv einschaltest, gehört ein geprüftes Backup dazu.

Dauerbetrieb: Security Command Center und Organisationsrichtlinien

Konfiguration ist kein einmaliger Akt, sondern verrutscht mit jedem neuen Projekt. Zwei Bordmittel halten dagegen:

• Security Command Center sammelt Fehlkonfigurationen und Schwachstellen an einer Stelle. Die Standard-Stufe kostet nichts und deckt die Grundlagen ab; Premium ergänzt Bedrohungserkennung, Angriffspfade und Compliance-Berichte. Beachte die Umstellung: Die Enterprise-Stufe wird laut Google am 21. Mai 2027 abgeschaltet, betroffene Organisationen wechseln danach automatisch auf Premium (Google-Dokumentation zu den Service-Stufen).
• Organisationsrichtlinien verhindern Fehler, statt sie zu melden. Klassiker sind die erzwungene einheitliche Zugriffssteuerung auf Storage-Buckets, das Verbot von Dienstkonto-Schlüsseln und die Beschränkung, welchen Identitäten überhaupt Rechte gegeben werden dürfen. In Organisationen, die vor Mai 2024 entstanden sind, lohnt ein gezielter Abgleich mit dieser Standardliste.

Wenn danach immer noch etwas offen ist

Drei Lücken überleben die fünf Schritte regelmäßig:

• Öffentliche Storage-Buckets. Ein Bucket, in dessen Berechtigungen allUsers oder allAuthenticatedUsers steht, ist aus dem Internet erreichbar — unabhängig von jeder Firewallregel. Prüfe das getrennt vom Netzwerkteil.
• Alte Schlüsseldateien. Das Verbot neuer Schlüssel entwertet vorhandene nicht. Bestehende JSON-Schlüssel auflisten, Nutzung prüfen, ersetzen, löschen.
• Geerbte Rechte von oben. Rechte auf Organisations- oder Ordnerebene wirken in jedes darunterliegende Projekt. Wer nur im Projekt sucht, sieht sie nicht — schau bei einer unerklärlichen Berechtigung immer eine Ebene höher.

Warum Fehlkonfiguration und nicht der Angreifer das Kernproblem ist

In der Cloud teilen sich Anbieter und Kunde die Verantwortung: Google sichert Rechenzentren, Hardware und Virtualisierung, du sicherst Identitäten, Rechte, Netzwerk und Daten. Kaputt geht es fast immer auf deiner Hälfte, und zwar durch Bequemlichkeit — eine Basisrolle „für den Moment“, ein offener Port „nur zum Testen“, ein Dienstkonto-Schlüssel im Repository. Solche Zustände sind für Angreifer billig zu finden, weil sie sich automatisiert im großen Stil scannen lassen.

Der wirksamste Hebel ist deshalb nicht das nächste Sicherheitsprodukt, sondern eine Konfiguration, die Fehler von vornherein unmöglich macht: Organisationsrichtlinien als Leitplanke, zeitlich befristete Rechte statt Dauer-Admin und Protokolle, die den Rest sichtbar machen. Wer die Google Cloud absichern will, arbeitet genau daran — und wiederholt den Durchgang einmal pro Quartal, weil Projekte sich weiterentwickeln.

Häufige Fragen

Wie sichere ich meine Google Cloud am schnellsten ab?

In dieser Reihenfolge: IAM-Rechte kürzen, Zwei-Faktor-Anmeldung erzwingen, Logging aktivieren, Firewall auf Default-Deny umstellen, danach Verschlüsselung und Dauerüberwachung. Rechte und Logs zuerst, weil sie nichts abschalten können.

Ist Zwei-Faktor-Anmeldung in der Google Cloud Pflicht?

Ja. Google hat im November 2024 angekündigt, MFA für alle Google-Cloud-Konten verbindlich zu machen – gestaffelt bis Ende 2025, zuerst für Passwort-Logins, zuletzt auch für föderierte Anmeldungen.

Warum soll ich keine Basisrollen wie „Inhaber“ vergeben?

Basisrollen gelten projektweit für fast alle Dienste und sind damit viel zu breit. Google rät ausdrücklich davon ab, solange eine engere vordefinierte oder eigene Rolle möglich ist.

Wie erlaube ich SSH, ohne Port 22 ins Internet zu öffnen?

Über den Identity-Aware Proxy. Dafür eine Firewallregel anlegen, die eingehenden Verkehr aus 35.235.240.0/20 auf Port 22 (SSH) bzw. 3389 (RDP) erlaubt. Die VM braucht dann keine öffentliche IP-Adresse.

Kostet das Security Command Center etwas?

Die Standard-Stufe ist kostenlos und deckt die Konfigurationsprüfung ab. Premium kostet extra und bringt Bedrohungserkennung. Die Enterprise-Stufe wird am 21. Mai 2027 abgeschaltet.