Google Cloud sicher konfigurieren: IAM, Firewall & Logging

Eine sichere Cloud Sicherheitskonfiguration in der Google Cloud steht auf fünf Säulen: Zugriffsrechte nach dem Prinzip der minimalen Berechtigung (IAM), Zwei-Faktor-Anmeldung für alle Konten, eine Firewall, die standardmäßig alles blockt, lückenloses Logging und Verschlüsselung. Wer in dieser Reihenfolge vorgeht – erst Rechte und Logs, dann Netzwerk und Verschlüsselung – schließt die häufigsten Lücken mit dem geringsten Aufwand zuerst.

Die fünf Bausteine einer sicheren Konfiguration

Die meisten Cloud-Pannen entstehen nicht durch ausgefeilte Angriffe, sondern durch Fehlkonfiguration: zu weit vergebene Rechte, offene Ports, fehlende Protokolle. Genau hier setzen die folgenden fünf Bereiche an. Sie bauen aufeinander auf – jeder einzelne senkt das Risiko spürbar.

• IAM (Identity and Access Management): Wer darf was?
• Netzwerk & Firewall: Welcher Datenverkehr ist überhaupt erlaubt?
• Logging: Was passiert in meinem Projekt – und wer hat es getan?
• Verschlüsselung: Sind die Daten auch im Ruhezustand geschützt?
• Überwachung: Werde ich gewarnt, wenn etwas falsch konfiguriert ist?

Baustein 1: Zugriffsrechte nach dem Least-Privilege-Prinzip

IAM (Identity and Access Management) regelt in der Google Cloud, welche Person oder welcher Dienst auf welche Ressource zugreifen darf. Der wichtigste Grundsatz lautet Least Privilege – jeder bekommt genau die Rechte, die er für seine Aufgabe braucht, und keine mehr.

Konkret heißt das:

• Basisrollen meiden. Die alten Rollen „Inhaber“, „Bearbeiter“ und „Betrachter“ (Owner/Editor/Viewer) sind viel zu breit – Google selbst rät für den Produktivbetrieb davon ab. Nutze stattdessen die vordefinierten Rollen, die genau zu einem Dienst passen, oder baue benutzerdefinierte Rollen.
• IAM Recommender nutzen. Dieses Bordmittel wertet die tatsächliche Zugriffshistorie aus und schlägt vor, zu großzügige Rollen durch engere zu ersetzen. Ein guter Startpunkt, um über Jahre gewachsene Rechte aufzuräumen.
• Zwei-Faktor-Anmeldung erzwingen. Aktiviere die Bestätigung in zwei Schritten (MFA) für alle Konten, vor allem für Administratoren. Ein gestohlenes Passwort allein reicht dann nicht mehr aus.
• Zeitlich begrenzte Rechte. Statt dauerhafte Admin-Rechte zu vergeben, lohnt sich ein Freigabe-Workflow, bei dem erhöhte Rechte nur für wenige Stunden und mit Genehmigung gelten.

Dienstkonten gesondert absichern

Ein Dienstkonto (Service Account) ist ein technisches Konto, mit dem sich Programme und virtuelle Maschinen anmelden – nicht ein Mensch. Solche Konten sind ein beliebtes Angriffsziel, weil sie oft zu viele Rechte haben. Zwei verifizierte Regeln aus der Google-Dokumentation: Vergib niemals automatisch Rollen an die Standard-Dienstkonten, und verlasse dich beim Anhängen eines Dienstkontos an eine VM nicht auf die alten Zugriffsbereiche (access scopes), sondern steuere die Rechte über IAM. Für Workloads außerhalb von Google empfiehlt sich Workload Identity Federation – damit lassen sich langlebige Schlüsseldateien vermeiden.

Baustein 2: Netzwerk und Firewall

Ein VPC (Virtual Private Cloud) ist dein abgeschottetes, virtuelles Netzwerk in der Google Cloud. Über Firewallregeln entscheidest du, welcher Datenverkehr hinein- und herausdarf. Die Grundregel hier:

• Standardmäßig alles blocken und nur gezielt das freigeben, was wirklich gebraucht wird – begrenzt auf die nötigen Protokolle und Ports. Für eine Webanwendung ist das meist nur TCP 443 (verschlüsseltes HTTPS).
• Kein offener SSH-Zugang ins Internet. Administrativen Zugriff (z. B. SSH auf Port 22) nur über einen Sprungserver (Bastion Host) oder den Identity-Aware Proxy zulassen, nicht von überall.
• Allow-Regeln eingrenzen. Erlaubende Regeln lassen sich auf bestimmte VMs beschränken, indem man das Dienstkonto der Maschine angibt – statt pauschal das ganze Netz freizugeben.
• Zusätzliche Schutzschichten: Cloud Armor (Schutz vor Überlastungsangriffen), VPC Service Controls, Private Google Access und Cloud NAT helfen, das Netzwerk weiter abzuschotten.

Baustein 3: Logging – wissen, was passiert

Ohne Protokolle bemerkst du einen Vorfall erst, wenn es zu spät ist. Zwei Quellen sind besonders wichtig: Die Cloud Audit Logs halten fest, wer welche Aktion in deinem Projekt ausgeführt hat. Die VPC Flow Logs zeichnen die Netzwerkverbindungen zwischen den Instanzen auf – ideal, um einen Angriff im Nachhinein nachzuvollziehen.

Leite beide Quellen nach Cloud Logging und protokolliere bewusst sowohl erlaubten als auch abgelehnten Datenverkehr. Erst dieses vollständige Bild zeigt ungewöhnliche Muster, bevor daraus ein echtes Problem wird.

Baustein 4: Verschlüsselung

Eine gute Nachricht vorweg: Google verschlüsselt gespeicherte Daten („at rest“) standardmäßig, ohne dass du etwas tun musst. Für höhere Anforderungen – etwa wenn Compliance-Vorgaben das verlangen – kannst du die Schlüssel selbst verwalten (CMEK, vom Kunden verwaltete Schlüssel). Damit behältst du die Kontrolle darüber, wann und ob ein Schlüssel zurückgezogen wird.

Baustein 5: Laufende Überwachung

Konfiguration ist kein einmaliger Akt. Das Security Command Center fasst Fehlkonfigurationen und Schwachstellen zentral zusammen und zeigt dir, wo dein Projekt verwundbar ist. Mit Organisationsrichtlinien (Org Policies) legst du verbindliche Leitplanken fest – etwa, dass keine öffentlich erreichbaren Speicher-Buckets erstellt werden dürfen. So lassen sich Fehler schon im Vorfeld verhindern, statt sie hinterher zu suchen.

In welcher Reihenfolge umsetzen?

Für den schnellsten Sicherheitsgewinn bei wenig Aufwand hat sich diese Reihenfolge bewährt:

1. IAM-Rechte aufräumen und Zwei-Faktor-Anmeldung erzwingen.
2. Logging (Audit Logs + Flow Logs) aktivieren und nach Cloud Logging leiten.
3. Firewall auf Default-Deny umstellen und nur nötige Ports öffnen.
4. Verschlüsselung prüfen, bei Bedarf eigene Schlüssel (CMEK) einrichten.
5. Security Command Center und Organisationsrichtlinien als Dauerüberwachung aufsetzen.

Häufige Fragen

Was bedeutet eine sichere Google-Cloud-Konfiguration?

Sie ruht auf fünf Säulen: minimale Zugriffsrechte (IAM), Zwei-Faktor-Anmeldung, eine Firewall mit Default-Deny, lückenloses Logging und Verschlüsselung. Zusammen schließen sie die häufigsten Fehlkonfigurationen.

Warum sollte ich keine Basisrollen wie „Inhaber“ vergeben?

Die Basisrollen Inhaber, Bearbeiter und Betrachter sind viel zu breit. Google rät im Produktivbetrieb davon ab – nutze vordefinierte oder benutzerdefinierte Rollen, die nur die wirklich nötigen Rechte enthalten.

Welche Firewallregel ist in Google Cloud am wichtigsten?

Standardmäßig allen Datenverkehr blocken und nur gezielt freigeben, was gebraucht wird – meist nur TCP 443 für HTTPS. Administrativen SSH-Zugang nie offen ins Internet, sondern über einen Bastion Host oder IAP.

Wie aktiviere ich Logging in der Google Cloud?

Leite die Cloud Audit Logs (wer hat was getan) und die VPC Flow Logs (Netzwerkverbindungen) nach Cloud Logging. Protokolliere dabei sowohl erlaubten als auch abgelehnten Verkehr für ein vollständiges Bild.

Muss ich meine Daten in der Cloud selbst verschlüsseln?

Google verschlüsselt gespeicherte Daten standardmäßig. Für höhere Anforderungen kannst du mit CMEK eigene Schlüssel verwalten und so selbst kontrollieren, wann ein Schlüssel zurückgezogen wird.