Checkliste zur GCP-Sicherheitshärtung für kleine und mittlere Teams

Häufige GCP-Bedrohungspfade

Die meisten Cloud-Vorfälle beginnen mit einer kleinen Lücke bei Zuständigkeiten oder Konfiguration. Suchen Sie nach diesen Pfaden, bevor ein Angreifer es tut.

• Ein Nutzer, ein Dienstkonto oder eine Workload-Identität mit zu vielen Berechtigungen kann aus einem einzigen gestohlenen Anmeldedatum breiten Zugriff über mehrere Projekte hinweg machen.
• Ein offen erreichbarer Verwaltungsendpunkt, ein Debug-Port oder eine zu freizügige Firewallregel kann jede Kontrolle umgehen, die für normalen Anwendungs-Traffic gedacht ist.
• Ein öffentlicher Storage-Bucket oder eine zu weit gefasste signierte URL kann Kundendaten offenlegen, ohne dass die Anwendung sichtbar kompromittiert wird.
• Veraltete Workloads schaffen ein dauerhaftes Risiko, wenn alte Images, vergessene Namespaces, ungenutzte Dienstkonten und Ressourcen ohne Verantwortlichen weiterhin bereitgestellt werden können.
• Fehlende oder nur kurz aufbewahrte Audit-Nachweise erschweren es festzustellen, wer eine Richtlinie geändert hat, wann der Zugriff begann und welche Daten erreicht wurden.
• Ein ungetestetes Backup ist nur eine Hoffnung. Fehlgeschlagene Wiederherstellungen, unvollständige Aufbewahrung und nicht zugängliche Verschlüsselungsschlüssel können aus einem Sicherheitsereignis einen dauerhaften Verlust machen.

Identität und Zugriff

Behandeln Sie Identität als primäre Steuerungsebene. Jeder Mensch, jeder Automatisierungsprozess und jeder Workload sollte eine eigene Identität mit einem klar begrenzten Zweck haben.

Legen Sie die Ressourcengrenze explizit fest

Nutzen Sie die Organisation und Ordner für Leitplanken und trennen Sie Entwicklung, Staging und Produktion in eigene Projekte oder stärkere Vertrauensgrenzen. Wenden Sie Organisationsrichtlinien auf der höchsten praktikablen Ebene an, schränken Sie die Dienstnutzung ein und vermeiden Sie es, Produktionsprojekte für nicht zusammengehörige Produkte gemeinsam zu nutzen.

Gewähren Sie die minimale Rolle im engsten Geltungsbereich

Bevorzugen Sie vordefinierte oder benutzerdefinierte Rollen gegenüber weit gefassten einfachen Rollen, weisen Sie sie Gruppen und Workload-Identitäten zu und verwenden Sie IAM-Bedingungen, wo ein Ressourcenname oder Tag den Zugriff eingrenzen kann. Prüfen Sie ungenutzte Berechtigungen und entfernen Sie dauerhaften Produktionszugriff, der nur in einen Break-Glass-Prozess gehört.

Entfernen Sie langlebige Anmeldedaten

Verwenden Sie Workload Identity Federation for GKE, damit Pods kurzlebige Anmeldedaten ohne exportierte Dienstkontoschlüssel erhalten. Blockieren Sie das Erstellen und Hochladen von Schlüsseln nach Möglichkeit per Organisationsrichtlinie, inventarisieren Sie alle verbleibenden Schlüssel und richten Sie Benachrichtigungen für risikoreiche IAM-Änderungen in Cloud Audit Logs ein.

Netzwerk und Edge

Gehen Sie davon aus, dass irgendein Anwendungsfehler früher oder später über das Netzwerk erreichbar sein wird. Begrenzen Sie, worauf dieser Fehler zugreifen kann.

Verweigern Sie standardmäßig und geben Sie benannte Pfade frei

Verwenden Sie VPC-Firewallregeln nach dem Prinzip der geringsten Berechtigung und Kubernetes-NetworkPolicies für den Pod-Traffic. Trennen Sie Umgebungen in eigene Netzwerke, dokumentieren Sie jeden Ingress-Pfad und entfernen Sie weit gefasste Debug-Regeln, die Verwaltungsports oder alle Protokolle aus großen Adressbereichen zulassen.

Halten Sie Knoten und Steuerungsebenen privat

Deaktivieren Sie externe IP-Adressen auf GKE-Knoten. Bevorzugen Sie den DNS-basierten privaten Endpunkt der Steuerungsebene und beschränken Sie ihn mit autorisierten Netzwerken, wenn ein IP-Endpunkt unvermeidbar ist. Geben Sie Workloads einen gezielten Pfad für ausgehenden Traffic statt breiten Internetzugriffs.

Veröffentlichen Sie nur bewusst gewählte öffentliche Dienste

Stellen Sie Anwendungen über ein geprüftes Gateway oder einen Load Balancer bereit, nicht über zufällig erreichbare Pod- oder Knotenadressen. Terminieren Sie TLS mit verwalteten Zertifikaten, schränken Sie Ingress-Hosts und -Pfade ein, setzen Sie Anfrage- und Ratenlimits und schützen Sie Verwaltungsoberflächen durch identitätsbasierten Zugriff.

Daten und Secrets

Schützen Sie Daten im Ruhezustand, bei der Übertragung und während der Nutzung, und weisen Sie dann nach, dass Sie sie wiederherstellen können. Die Datenerkennung gehört zur Kontrolle dazu.

Verhindern Sie versehentlichen öffentlichen Zugriff

Erzwingen Sie die Verhinderung des öffentlichen Zugriffs und den einheitlichen Zugriff auf Bucket-Ebene in Cloud Storage. Klassifizieren Sie Buckets nach Vertraulichkeit, schränken Sie den Zugriff auf Objekte und Schlüssel ein, aktivieren Sie das Logging für besonders wertvolle Daten und verwenden Sie vom Kunden verwaltete Verschlüsselungsschlüssel, wo Ihr Risiko- oder Compliance-Modell dies erfordert.

Halten Sie Secrets aus Images und Quellcode heraus

Speichern Sie Anmeldedaten in Secret Manager und gewähren Sie Zugriff für eine bestimmte Workload-Identität und Secret-Version. Rotieren Sie Secrets gezielt, kopieren Sie sie nicht in Git oder Container-Images und betrachten Sie gewöhnliche Kubernetes Secrets nicht als vollständige Schutzgrenze.

Testen Sie die Wiederherstellung, nicht nur die Erstellung von Backups

Legen Sie Ziele für Wiederherstellungspunkt und Wiederherstellungszeit (RPO/RTO) fest, bewahren Sie Kopien außerhalb der Fehlerdomain der Produktion auf und schützen Sie den Zugriff auf Backups und Verschlüsselungsschlüssel vor der Workload-Identität. Stellen Sie regelmäßig nach Zeitplan in einer isolierten Umgebung wieder her, prüfen Sie die Daten und dokumentieren Sie die benötigte Zeit und alle manuellen Schritte.

GKE-Härtung

GKE sichert die verwaltete Steuerungsebene, doch Clusterkonfiguration, Namespaces, Admission-Richtlinien und Workloads bleiben in Ihrer Verantwortung.

Machen Sie Namespaces zur verbindlichen Isolationsgrenze

Trennen Sie Teams und Umgebungen in Namespaces oder Cluster, binden Sie dort eng gefasste Kubernetes-RBAC-Rollen und wenden Sie Ressourcenkontingente und NetworkPolicies an. Vermeiden Sie clusterweiten Schreibzugriff für die Anwendungsbereitstellung und geben Sie jedem Workload ein eigenes Dienstkonto, wenn er eine eigene Identität benötigt.

Lassen Sie nur Images und Konfigurationen zu, denen Sie vertrauen

Erzwingen Sie den Pod Security-Standard „Restricted“ oder gleichwertige Policy Controller-Regeln. Stellen Sie Images über unveränderliche Digests bereit, scannen Sie sie auf Sicherheitslücken, verwenden Sie Binary Authorization, wo die Herkunft wichtig ist, und lehnen Sie unerwarteten Hostzugriff, Rechteausweitung und cluster-admin-Bindungen ab.

Entfernen Sie unnötige Container-Berechtigungen

Führen Sie Container als Nicht-Root-Benutzer aus, entfernen Sie Linux-Capabilities, verwenden Sie nach Möglichkeit ein schreibgeschütztes Root-Dateisystem und wenden Sie das seccomp-Profil RuntimeDefault an. Mounten Sie das Dienstkonto-Token nur bei Bedarf, vermeiden Sie privilegierte Container und Host-Namespaces, halten Sie das Dienstkonto der Knoten minimal und verwenden Sie Shielded Nodes zusammen mit Container-Optimized OS.

Erkennung und Wiederherstellung

Kontrollen versagen. Verlassen Sie sich auf Nachweise und eingeübte Abläufe, nicht auf die Zuversicht, dass niemand einen Fehler gemacht hat.

Sammeln Sie die Nachweise, die Sie brauchen werden

Bewahren Sie Cloud Audit Logs sowie GKE-System- und Workload-Logs an einem zentralen Ziel auf, mit einer Aufbewahrungsdauer, die Ihren Untersuchungsanforderungen entspricht. Aktivieren Sie Audit-Logs zum Datenzugriff gezielt für sensible Daten, beschränken Sie den Zugriff auf Logs und protokollieren Sie administrative Änderungen an IAM, Firewall, Speicher und Clusterkonfiguration.

Benachrichtigen Sie bei sicherheitsrelevanten Änderungen

Richten Sie Benachrichtigungen ein für öffentlich zugänglichen Speicher, weitreichende Firewall- oder IAM-Änderungen, unerwartete Dienstkontoschlüssel, Admission-Ablehnungen, offengelegte Steuerungsebenen, wiederholte Authentifizierungsfehler, deaktiviertes Logging, fehlgeschlagene Backups und ablaufende Zertifikate. Leiten Sie jede Benachrichtigung an einen Verantwortlichen weiter, zusammen mit den Schritten, um sie zu bestätigen oder zu verwerfen.

Üben Sie die Reaktion

Schreiben Sie kurze Runbooks für geleakte Anmeldedaten, öffentlich gewordene Daten, kompromittierte Workloads und verlorene Regionen oder Projekte. Halten Sie fest, wer die Eindämmung autorisieren darf, wie Zugriff widerrufen, Beweise gesichert und der Dienst wiederhergestellt wird. Testen Sie die Runbooks mit den Personen, die sie anwenden werden.

Eine priorisierte Checkliste für 30, 60 und 90 Tage

Wenn Sie von einer unvollständigen Baseline ausgehen, ordnen Sie die Arbeit so, dass zuerst die Angriffsfläche verringert wird und spätere Überprüfungen wiederholbar werden.

Tage 1 bis 30: Schließen Sie die offensichtlichen Pfade

Inventarisieren Sie Projekte und Verantwortliche, entfernen Sie ungenutzte und langlebige Anmeldedaten, bestätigen Sie das Audit-Logging, blockieren Sie öffentliche Buckets, prüfen Sie die weitreichendsten Firewallregeln und IAM-Berechtigungen, identifizieren Sie Backup-Lücken in der Produktion und beheben Sie jeden öffentlichen Endpunkt ohne Verantwortlichen. Weisen Sie jedem Befund einen Verantwortlichen und ein Fälligkeitsdatum zu.

Tage 31 bis 60: Machen Sie die Baseline wiederholbar

Überführen Sie Netzwerk-, Identitäts- und Workload-Konfiguration in geprüfte Infrastructure as Code und GitOps-Bereitstellung. Führen Sie Workload Identity, private Knoten, Pod Security mit dem Standard „Restricted“, Prüfungen auf vertrauenswürdige Images, zentrale Logs und Benachrichtigungen für die wichtigsten Änderungen ein.

Tage 61 bis 90: Weisen Sie die Wirksamkeit nach und erhalten Sie sie

Führen Sie Wiederherstellungstests und eine Tabletop-Übung zu einem Sicherheitsvorfall durch, prüfen Sie privilegierte Zugriffe und das Ablaufen von Ausnahmen, scannen Sie Images und Abhängigkeiten erneut, stellen Sie sicher, dass Verantwortliche die Benachrichtigungen erhalten, und messen Sie die verbleibenden Lücken. Nehmen Sie die Prüfungen in einen wiederkehrenden Überprüfungszyklus auf, bevor die Nachweise veralten.

Nutzen Sie diese Checkliste als Ausgangspunkt. Snow Tree kann die Baseline im Rahmen des Betriebs einer verwalteten Plattform oder eines gezielten Beratungsprojekts umsetzen.

Verwaltete Plattform · Beratung

Offizielle Referenzen

Nutzen Sie die aktuellen Empfehlungen von Google als maßgebliche technische Quelle, wenn sich Plattformstandards oder Produktfunktionen ändern.

• Google Cloud: Best Practices zum Härten Ihres GKE-Clusters
• Google Cloud: Best Practices für die GKE-Sicherheit