Handbuch

GKE-Workloads müssen auf GCP-APIs zugreifen können, ohne Dienstkontoschlüssel zu verwalten.

→Workload Identity auf dem GKE-Cluster aktivieren und konfigurieren. Kubernetes-Dienstkonten (KSA) Google-Dienstkonten (GSA) zuordnen.

Warum: Eliminiert das Risiko kompromittierter Dienstkontoschlüssel durch die Verwendung kurzlebiger, automatisch rotierender Anmeldeinformationen, die von KSA-Tokens abgeleitet sind.

Referenz↗

Zugriff auf interne Webanwendungen aus jedem Netzwerk basierend auf Benutzeridentität und Gerätezustand ermöglichen, ohne VPN.

→Identity-Aware Proxy (IAP) mit Access Context Manager verwenden. Zugriffsebenen basierend auf IP, Gerätezustand (via Endpoint Verification) und Benutzeridentität definieren.

Warum: Verschiebt die Zugriffskontrolle vom Netzwerkperimeter auf einzelne Benutzer und Geräte und setzt Zero-Trust-Prinzipien durch.

Referenz↗

Eine CI/CD-Pipeline (z. B. GitHub Actions, GitLab) muss auf GCP-Ressourcen zugreifen, ohne langlebige Anmeldeinformationen zu verwenden.

→Workload Identity Federation verwenden. Einen Anbieterpool für den externen IdP (z. B. GitHub OIDC) erstellen und Attributbedingungen konfigurieren, um den Zugriff auf bestimmte Repositories oder Branches zu beschränken.

Warum: Schlüssellose Authentifizierung für externe Workloads. Das externe System stellt sein eigenes Token bereit, das gegen ein kurzlebiges GCP-Token ausgetauscht wird.

IAM-Sicherheitsrichtlinien organisationsweit durchsetzen, z. B. die Erstellung von Dienstkontoschlüsseln verhindern oder IAM-Berechtigungen auf bestimmte Domänen beschränken.

→Organization Policy-Einschränkungen wie `iam.disableServiceAccountKeyCreation` und `iam.allowedPolicyMemberDomains` verwenden.

Warum: Organisation Policies werden vererbt und können von Projektbesitzern nicht überschrieben werden, was eine konsistente Sicherheitshaltung gewährleistet.

Ein Benutzer benötigt temporären, auditierbaren und genehmigungsbasierten Administratorzugriff auf eine Produktionsumgebung für einen Vorfall.

→Privileged Access Manager (PAM) für Just-in-Time (JIT)-Zugriff verwenden. Der Benutzer beantragt eine bestimmte Rolle für einen begrenzten Zeitraum, was einen Genehmigungsworkflow durchläuft.

Warum: Eliminiert dauerhafte Privilegien, ein großes Sicherheitsrisiko. Der Zugriff ist zeitlich begrenzt, begründet und vollständig auditiert.

Mehrere Teams teilen sich einen GKE-Cluster. Jedes Team darf nur Ressourcen innerhalb seines eigenen Namespace verwalten.

→Die IAM-Rolle `roles/container.clusterViewer` auf Projektebene zuweisen. Kubernetes RBAC `Role` und `RoleBinding` innerhalb jedes Namespace verwenden, um spezifische Berechtigungen (z. B. Bearbeiten, Anzeigen) zu erteilen.

Warum: Trennung der Authentifizierung auf Cluster-Ebene (IAM) von der Autorisierung auf Namespace-Ebene (Kubernetes RBAC), wodurch eine fein granulare, mandantenfähige Kontrolle ermöglicht wird.

APIs müssen mit kurzlebigen Anmeldeinformationen anstelle von statischen Schlüsseln aufgerufen werden.

→Dienstkonto-Impersonation verwenden. Einem Principal die Rolle `roles/iam.serviceAccountTokenCreator` für ein Ziel-Dienstkonto gewähren, um kurzlebige OAuth 2.0-Zugriffstoken zu generieren.

Warum: Vermeidet die Verteilung und Verwaltung langlebiger Schlüssel. Tokens laufen automatisch ab (Standard 1 Stunde), was das Risiko im Falle einer Kompromittierung reduziert.

Ein Auftragnehmer benötigt Zugriff auf bestimmte Ressourcen, aber der Zugriff muss nach 30 Tagen automatisch ablaufen.

→Die erforderliche IAM-Rolle mit einer zeitbasierten IAM-Bedingung gewähren, z. B. `request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`.

Warum: Automatisiert den Entzug des Zugriffs, vermeidet manuelle Bereinigung und stellt sicher, dass der Zugriff nicht unbeabsichtigt verlängert wird.

Nur Container-Images zulassen, die von der CI/CD-Pipeline signiert wurden, um in Produktions-GKE-Clustern bereitgestellt zu werden.

→Binary Authorization implementieren. Eine Attestierung in der CI-Pipeline erstellen, um Images zu signieren. Eine Binary Authorization-Richtlinie auf dem GKE-Cluster konfigurieren, um diese Attestierung zu verlangen.

Warum: Erzwingt eine sichere Software-Lieferkette, indem verhindert wird, dass ungeprüfte oder manipulierte Images in der Produktion ausgeführt werden.

Referenz↗

Berechtigungen für Ressourcen basierend auf ihren zugewiesenen Tags gewähren, nicht auf einzelnen Ressourcennamen.

→IAM-Bedingungen mit Ressourcen-Tag-Ausdrücken verwenden, wie `resource.matchTag("123456789/env", "prod")`.

Warum: Ermöglicht skalierbare, attributbasierte Zugriffskontrolle (ABAC). Berechtigungen sind dynamisch und werden automatisch angewendet, sobald Ressourcen getaggt werden.

Einem Service-Projekt erlauben, VMs in einem Shared VPC-Hostprojekt bereitzustellen, ohne Netzwerkadministratorrechte zu gewähren.

→Im Hostprojekt dem Dienstkonto des Service-Projekts die Rolle `roles/compute.networkUser` für die spezifischen Subnetze gewähren, die es verwenden muss.

Warum: Folgt dem Prinzip der geringsten Rechte. Service-Projekte können das Netzwerk nutzen, aber nicht ändern (z. B. Firewall-Regeln ändern), was zentral verwaltet bleibt.

Ein Benutzer mit `storage.admin` kann keinen Bucket erstellen. Sie müssen die Ursache ermitteln.

→Suchen Sie nach einer IAM Deny Policy auf einer höheren Ebene (Ordner, Organisation), die die Berechtigung `storage.buckets.create` verweigert.

Warum: IAM Deny Policies überschreiben immer alle Allow Policies. Dies ist ein leistungsstarkes Werkzeug zur Durchsetzung nicht verhandelbarer Sicherheitsgrenzen.

SSO für lokale Active Directory-Benutzer aktivieren, um auf die Google Cloud-Konsole zuzugreifen.

→Google Cloud Directory Sync (GCDS) verwenden, um Identitäten mit Cloud Identity zu synchronisieren. Föderation (SAML) zwischen Cloud Identity und AD FS (oder einem anderen IdP) konfigurieren.

Warum: Hält AD als primäre Quelle für Identitäten, während Benutzern eine nahtlose, föderierte SSO-Erfahrung geboten wird.

Daten in GCP verschlüsseln, aber die Verschlüsselungsschlüssel dürfen das lokale HSM niemals verlassen.

→Cloud External Key Manager (EKM) verwenden. Dies ermöglicht GCP-Diensten, Schlüssel von einem externen Schlüsselverwaltungssystem für CMEK-Operationen zu verwenden.

Warum: Bietet maximale Kontrolle und erfüllt strenge Anforderungen an die Datenhoheit, indem Schlüsselmaterial außerhalb von Google Cloud verbleibt.

Referenz↗

Automatisch sensible Daten (PII, PHI) in allen Cloud Storage- und BigQuery-Assets finden und klassifizieren.

→Cloud Data Loss Prevention (DLP)-Erkennungsscans konfigurieren. Die Ergebnisse können Data Catalog automatisch mit Tags befüllen.

Warum: Bietet eine automatisierte Dateninventarisierung und -klassifizierung, die die Grundlage für Datengovernance- und Schutzrichtlinien bildet.

Ein Analyseteam muss Daten mit PII abfragen, sollte aber die rohen sensiblen Werte nicht sehen. Referentielle Integrität muss gewahrt bleiben.

→Eine Cloud DLP-De-Identifikationsvorlage mit deterministischer Verschlüsselung oder kryptografischem Hashing verwenden.

Warum: Transformiert sensible Daten in Pseudonyme. Deterministische Methoden stellen sicher, dass die gleiche Eingabe immer die gleiche Ausgabe erzeugt, was Verknüpfungen und Aggregationen ermöglicht.

Ein Compliance-Framework (z. B. für Finanzdienstleistungen) erfordert, dass Verschlüsselungsschlüssel durch ein FIPS 140-2 Level 3 zertifiziertes HSM geschützt werden.

→Cloud KMS mit einem Schutzlevel von HSM verwenden. Dadurch werden Schlüssel innerhalb eines verwalteten Hardware-Sicherheitsmoduls erstellt.

Warum: Erfüllt hohe Compliance-Anforderungen durch die Verwendung dedizierter, zertifizierter Hardware für die Schlüsselverwaltung, ohne die physischen HSMs verwalten zu müssen.

Sicherstellen, dass neue Ressourcen (z. B. GCS-Buckets, BigQuery-Datasets) immer mit vom Kunden verwalteten Schlüsseln (CMEK) verschlüsselt werden, nicht mit von Google verwalteten Schlüsseln.

→Die Organization Policy `constraints/gcp.restrictNonCmekServices` anwenden.

Warum: Bietet eine präventive Kontrolle, die bestimmte Dienste zur Verwendung von CMEK zwingt und so eine konsistente Datenschutzhaltung gewährleistet.

Daten müssen aus rechtlichen oder Compliance-Gründen für eine bestimmte Aufbewahrungsfrist in einem unveränderlichen (WORM - Write-Once-Read-Many) Zustand gespeichert werden.

→Einen Cloud Storage-Bucket mit einer Aufbewahrungsrichtlinie konfigurieren und Bucket Lock aktivieren.

Warum: Bucket Lock macht die Aufbewahrungsrichtlinie unumkehrbar und stellt sicher, dass Objekte, selbst von Administratoren, weder gelöscht noch geändert werden können, bis die Aufbewahrungsfrist endet.

In Secrets gespeicherte Datenbank-Anmeldeinformationen der Anwendung müssen automatisch rotiert werden, ohne Ausfallzeiten der Anwendung zu verursachen.

→Secret Manager mit konfigurierter automatischer Rotation verwenden. Die Rotation löst eine Cloud Function aus, die das Passwort in der Datenbank aktualisiert und eine neue Secret-Version erstellt.

Warum: Verwaltete, automatisierte Rotation reduziert das Risiko der Kompromittierung von Anmeldeinformationen. Anwendungen referenzieren die `latest`-Version, um das neue Secret nahtlos zu übernehmen.

Eine Workload verarbeitet hochsensible Daten, und die Daten müssen auch im Arbeitsspeicher (in-use) verschlüsselt bleiben.

→Vertrauliches Computing nutzen, indem die Workload auf Confidential VMs bereitgestellt wird.

Warum: Bietet hardwarebasierte Speicherverschlüsselung, die Daten vor dem Hypervisor und anderen VMs schützt. Attestierung verwenden, um die Integrität der Umgebung zu überprüfen.

Zugriff auf bestimmte sensible Spalten in einer BigQuery-Tabelle einschränken, ohne separate Ansichten zu erstellen.

→BigQuery-Spaltenebenen-Sicherheit verwenden. Data Catalog-Richtlinien-Tags auf sensible Spalten anwenden und die Rolle "Fine-Grained Reader" auf diese Richtlinien-Tags autorisierten Benutzern/Gruppen gewähren.

Warum: Erzwingt fein granularen Zugriff direkt auf die Tabelle, was skalierbarer und besser verwaltbar ist als die Pflege mehrerer autorisierter Ansichten.

Sensible Daten in einem GCS-Bucket schützen, selbst wenn IAM-Berechtigungen falsch konfiguriert sind und öffentlichen Zugriff gewähren.

→Objekte mit einem Customer-Managed Encryption Key (CMEK) verschlüsseln und den Zugriff auf diesen Schlüssel in Cloud KMS streng kontrollieren.

Warum: Erstellt ein Zwei-Schlüssel-System. Ein Angreifer benötigt Berechtigungen sowohl für das GCS-Objekt ALS AUCH für den KMS-Schlüssel, um die Daten zu entschlüsseln, was eine Tiefenverteidigung bietet.

Versehentliches oder böswilliges sofortiges Löschen kritischer Cloud KMS-Schlüssel verhindern.

→Beim Erstellen des Schlüssels die Eigenschaft `destroy_scheduled_duration` auf einen Wert wie 30 Tage konfigurieren.

Warum: Erzwingt eine Wartezeit, bevor ein Schlüssel dauerhaft gelöscht wird, und bietet ein Zeitfenster zur Wiederherstellung nach versehentlichem Löschen.

Eine rechtliche Anforderung, zu beweisen, dass eine Datei in Cloud Storage seit dem Hochladen nicht verändert wurde.

→Nach dem Herunterladen den MD5- oder CRC32C-Hash der Datei neu berechnen und mit dem im Cloud Storage-Objekt-Metadaten gespeicherten Hash vergleichen.

Warum: Bietet kryptografischen Nachweis der Objektintegrität. Cloud Storage berechnet und speichert diese Hashes beim Hochladen automatisch.

Verhindern, dass Daten von einem sensiblen Projekt in einen öffentlichen Bucket kopiert werden, selbst durch einen Benutzer mit der Rolle `owner`.

→Das sensible Projekt innerhalb eines VPC Service Controls-Perimeters platzieren. Dies beschränkt die Datenbewegung auf andere Projekte außerhalb des Perimeters.

Warum: VPC Service Controls fungieren als datenzentrierte Firewall, die IAM-Berechtigungen für den Datenabfluss überschreibt und einen leistungsstarken Schutz gegen Exfiltration bietet.

Referenz↗

Eine öffentlich zugängliche Webanwendung vor volumetrischen DDoS-Angriffen und gängigen Web-Exploits (z. B. SQLi, XSS) schützen.

→Die Anwendung hinter einem Global External HTTP(S) Load Balancer platzieren und eine Cloud Armor-Sicherheitsrichtlinie mit vorkonfigurierten WAF-Regeln anhängen.

Warum: Der Load Balancer absorbiert DDoS-Angriffe am Google-Edge. Cloud Armor bietet eine verwaltete Web Application Firewall, um OWASP Top 10-Bedrohungen zu blockieren.

Ein Dedicated Interconnect wird für die Verbindung zwischen On-Premise und GCP verwendet, aber der Datenverkehr muss aus Compliance-Gründen verschlüsselt werden.

→Einen HA VPN-Tunnel über die Cloud Interconnect VLAN-Attachments konfigurieren.

Warum: Kombiniert die hohe Bandbreite und geringe Latenz einer dedizierten Verbindung mit der IPsec-Verschlüsselung eines VPNs.

Lokale Systeme müssen Google APIs (z. B. BigQuery, GCS) aufrufen, ohne das öffentliche Internet zu durchqueren.

→Private Google Access für lokale Hosts konfigurieren. Cloud Interconnect oder VPN verwenden und DNS so konfigurieren, dass `*.googleapis.com` auf den eingeschränkten VIP-Bereich aufgelöst wird.

Warum: Hält den Datenverkehr zu Google-Diensten im privaten Google-Netzwerk, was die Sicherheit erhöht und möglicherweise die Ausgangskosten senkt.

Gegenseitiges TLS (mTLS) für die gesamte Dienst-zu-Dienst-Kommunikation innerhalb eines GKE-Clusters erzwingen.

→Anthos Service Mesh (oder Istio) bereitstellen und strenge mTLS-Peer-Authentifizierung für die relevanten Namespaces aktivieren.

Warum: Verschlüsselt und authentifiziert automatisch den gesamten Datenverkehr innerhalb des Meshs und erreicht so ein Zero-Trust-Netzwerkmodell ohne Änderungen am Anwendungscode.

Eine Consumer-VPC muss privat auf einen Dienst (z. B. eine interne API) zugreifen, der in einer Producer-VPC läuft, ohne Peering oder öffentliche IPs zu verwenden.

→Der Produzent veröffentlicht den Dienst mithilfe von Private Service Connect. Der Konsument erstellt einen Endpunkt in seiner VPC, der privat zum Dienst weiterleitet.

Warum: Entkoppelt die Netzwerkkonnektivität vom Dienstzugriff. Dies ist der moderne, skalierbare Weg, um privaten Zugriff auf Dienste über VPCs und Organisationen hinweg bereitzustellen.

Einen GKE-Cluster bereitstellen, bei dem Knoten keine öffentlichen IPs haben und die Steuerungsebene nicht dem Internet ausgesetzt ist.

→Einen privaten GKE-Cluster erstellen. Private Google Access auf dem Subnetz für den Knoten-Zugriff auf GCP-APIs aktivieren. Master authorized networks konfigurieren, um den Zugriff auf die Steuerungsebene auf bestimmte IPs (z. B. Unternehmensnetzwerk) zu beschränken.

Warum: Reduziert die Angriffsfläche des Clusters erheblich, indem öffentliche Endpunkte für Knoten und Steuerungsebene entfernt werden.

In einem GKE-Cluster dürfen Pods für einen `frontend`-Dienst nur mit Pods für einen `backend`-Dienst kommunizieren, und nichts anderem.

→Kubernetes NetworkPolicy-Ressourcen erstellen. Eine Ingress-Richtlinie auf die `backend`-Pods anwenden, die Datenverkehr nur von `frontend`-Pods zulässt, basierend auf Pod-Labels.

Warum: Bietet Firewall-Funktionen auf Pod-Ebene innerhalb des Clusters und ermöglicht ein Netzwerkmodell der geringsten Rechte für Microservices.

VMs ohne externe IPs müssen auf das Internet zugreifen. Der gesamte ausgehende Datenverkehr muss von einem kleinen Satz vorhersehbarer IP-Adressen stammen, um von Dritten zugelassen zu werden.

→Cloud NAT für das Subnetz konfigurieren, das die VMs enthält.

Warum: Bietet verwaltete Netzwerkadressübersetzung für internetgebundenen Datenverkehr von privaten Instanzen, mit zentralisierter Protokollierung und IP-Zuweisung.

Eine grundlegende Firewall-Regel organisationsweit durchsetzen, z. B. alle SSH-Verbindungen aus dem Internet verweigern, die von Projektteams nicht überschrieben werden kann.

→Eine hierarchische Firewall-Richtlinie auf Organisations- oder Ordnerebene mit einer Ablehnungsregel für Port 22 von `0.0.0.0/0` mit hoher Priorität erstellen.

Warum: Hierarchische Richtlinien werden vor VPC-Level-Regeln ausgewertet, was zentralen Sicherheitsteams ermöglicht, nicht verhandelbare Netzwerksicherheitsvorkehrungen durchzusetzen.

Interne Hostnamen innerhalb einer VPC auflösen, ohne Abfragen an öffentliche DNS-Server preiszugeben.

→Eine private verwaltete Cloud DNS-Zone für Ihre internen Domänen konfigurieren und sie Ihrer VPC zuordnen.

Warum: Bietet autoritatives DNS für interne Ressourcen innerhalb des VPC-Netzwerks, was Sicherheit und Verwaltbarkeit verbessert.

Wenn das Security Command Center eine Bedrohung (z. B. Kryptomining) erkennt, die betroffene VM automatisch isolieren.

→SCC so konfigurieren, dass Findings in einem Pub/Sub-Thema veröffentlicht werden. Eine Cloud Function auslösen, die das Finding empfängt und die Netzwerk-Tags der VM ändert, um eine vorkonfigurierte "Quarantäne"-Firewall-Regel anzuwenden.

Warum: Ermöglicht eine nahezu echtzeitnahe, automatisierte Reaktion auf Vorfälle, wodurch die Zeit, die ein Angreifer in der Umgebung hat, reduziert wird.

Audit-Logs von allen Projekten in der Organisation sammeln und für 7 Jahre in einem unveränderlichen Format zur Compliance speichern.

→Einen Log-Sink auf Organisationsebene zu einem Cloud Storage-Bucket erstellen. Den Ziel-Bucket mit einer 7-Jahres-Aufbewahrungsrichtlinie und Bucket Lock konfigurieren.

Warum: Ein aggregierter Sink zentralisiert Logs. Bucket Lock stellt sicher, dass die Logs manipulationssicher sind und strenge Compliance-Aufbewahrungsanforderungen erfüllen.

Eine VM wird als kompromittiert verdächtigt. Sie muss sofort offline genommen werden, aber Beweismittel müssen für die forensische Analyse erhalten bleiben.

→Die VM-Instanz stoppen (um die Aktivität zu unterbrechen) und sofort einen Snapshot ihrer persistenten Festplatte erstellen. Anschließend mit Firewall-Regeln isolieren.

Warum: Das Stoppen der Instanz enthält die Bedrohung, während der Snapshot eine Momentaufnahme der Festplatte für die Analyse erstellt, ohne das Risiko einer Beweismittelmanipulation.

Erkennen, wenn ein Dienstkonto von einem ungewöhnlichen geografischen Standort verwendet wird oder abnormale Aktivitäten durchführt.

→Security Command Center Premium Tier aktivieren, das Event Threat Detection umfasst. Dieser Dienst analysiert Logs auf anomales Verhalten.

Warum: Nutzt Googles Bedrohungsdaten und maschinelles Lernen, um Bedrohungen zu erkennen, die mit regelbasierten Warnungen schwer zu finden sind, wie z. B. kompromittierte Anmeldeinformationen.

Ein zentrales Sicherheitsteam muss Sicherheitsignale von GCP, AWS und lokalen Systemen auf einer einzigen Plattform analysieren und korrelieren.

→Alle relevanten Logs und Telemetriedaten in Chronicle Security Operations (SIEM) aufnehmen.

Warum: Chronicle ist ein Cloud-natives SIEM, das für die Analyse im Petabyte-Bereich entwickelt wurde, mit integrierten Parsern und Erkennungsregeln für Multi-Cloud- und Hybrid-Umgebungen.

Erkennen, wenn von Terraform verwaltete GCP-Ressourcen manuell über die Konsole geändert werden, wodurch eine Konfigurationsdrift entsteht.

→Einen Cloud Asset Inventory Feed konfigurieren, um Asset-Änderungsbenachrichtigungen in Echtzeit an ein Pub/Sub-Thema zu senden. Ein Dienst kann diese Änderungen dann mit dem Terraform-Zustand vergleichen.

Warum: Bietet Echtzeit-Transparenz über alle Ressourcenänderungen und ermöglicht die automatische Erkennung von Out-of-Band-Modifikationen.

Eine Organisation hat Tausende von SCC-Findings und muss sich auf diejenigen konzentrieren, die das unmittelbarste Risiko für kritische Assets darstellen.

→Attack Path Simulation in SCC Premium verwenden. Hochwertige Assets definieren, und die Simulation identifiziert und priorisiert Findings, die einen direkten Pfad zu diesen Assets bilden.

Warum: Verschiebt die Priorisierung von Schwachstellen-basierter zu Risikobasierter Priorisierung. Es hebt toxische Kombinationen von Findings hervor, die ein Angreifer ausnutzen könnte.

Böswillige Aktivitäten in einem laufenden GKE-Container erkennen, wie z. B. eine unerwartete Shell oder eine Reverse-Shell-Verbindung.

→Container Threat Detection im Security Command Center aktivieren.

Warum: Bietet Laufzeit-Transparenz über das Containerverhalten und erkennt Bedrohungen, die das Schwachstellen-Scanning (das vor der Laufzeit stattfindet) nicht erkennen kann.

Eine Netzwerkforensik-Untersuchung erfordert das Erfassen und Analysieren des vollständigen Paketinhaltes des Datenverkehrs zwischen zwei spezifischen VMs.

→Packet Mirroring konfigurieren, um Datenverkehr von den Quell-VMs zu klonen und an eine Collector-VM zu senden, die Inspektionswerkzeuge wie Wireshark oder Zeek ausführt.

Warum: Bietet vollständige Paketerfassung für die Tiefenanalyse, im Gegensatz zu VPC Flow Logs, die nur Metadaten enthalten.

Unsichere Terraform-Konfigurationen (z. B. öffentliche GCS-Buckets) von der Bereitstellung verhindern.

→Ein statisches Analyse-Sicherheitstestwerkzeug (SAST) wie `tfsec` oder Checkov in die CI/CD-Pipeline integrieren. Den Build fehlschlagen lassen, wenn Sicherheitsverletzungen gefunden werden.

Warum: Implementiert "Shift-Left"-Sicherheit, indem Fehlkonfigurationen vor der Bereitstellung abgefangen werden, wodurch der Bedarf an reaktiver Fehlerbehebung reduziert wird.

Ein Unternehmen muss aus Compliance-Gründen sicherstellen, dass bestimmte Daten und deren Verarbeitung nur in EU-Regionen erfolgen dürfen.

→Die Organization Policy-Einschränkung `gcp.resourceLocations` anwenden, die nur bestimmte EU-Regionen zulässt.

Warum: Dies ist eine technische, präventive Kontrolle, die die Datenresidenz auf der Ebene der Ressourcenerstellung durchsetzt, was für Vorschriften wie die DSGVO erforderlich ist.

Ein Finanzinstitut verlangt, dass Google-Supportmitarbeiter eine explizite, zeitlich begrenzte Genehmigung erhalten müssen, bevor sie für einen Supportfall auf ihre Daten zugreifen.

→Access Approval aktivieren und Genehmiger konfigurieren. Alle Zugriffsanfragen von Google generieren eine Anfrage, die genehmigt werden muss.

Warum: Bietet kundenkontrollierten Zugriff auf Google-Administratoren, eine Schlüsselanforderung für stark regulierte Branchen.

Ein Auditor muss genau überprüfen, welche Aktionen Google-Mitarbeiter durchgeführt haben, als ihnen Zugriff auf Ihre Umgebung gewährt wurde.

→Access Transparency-Logs aktivieren und überprüfen. Diese Logs bieten eine nahezu Echtzeit-Übersicht der von Google-Mitarbeitern durchgeführten Aktionen.

Warum: Bietet einen unveränderlichen Audit-Trail der Google-Administratoraktionen, der Transparenz bietet und Compliance-Anforderungen unterstützt.

Die GCP-Umgebung kontinuierlich auf Konfigurationen überwachen, die einen spezifischen Compliance-Standard wie PCI DSS oder HIPAA verletzen.

→Security Health Analytics im Security Command Center verwenden, wobei der relevante Compliance-Standard im Dashboard aktiviert ist.

Warum: Automatisiert Compliance-Prüfungen anhand von Branchen-Benchmarks, bietet kontinuierliche Transparenz und generiert Findings für erkannte Fehlkonfigurationen.

Ein Auditor fordert Googles SOC 2 Typ II Bericht und die PCI DSS Konformitätsbescheinigung an.

→Den Compliance Reports Manager in der Google Cloud Console verwenden, um Audit-Berichte und Zertifizierungen abzurufen und herunterzuladen.

Warum: Bietet ein Self-Service-Portal für Kunden, um die notwendige Compliance-Dokumentation zur Unterstützung ihrer eigenen Audit-Prozesse zu erhalten.

Eine US-Regierungsbehörde muss eine Workload bereitstellen, die die FedRAMP High Compliance-Anforderungen erfüllt.

→Die Anwendung in einer Assured Workloads-Umgebung bereitstellen, die für das FedRAMP High Compliance-Regime konfiguriert ist.

Warum: Assured Workloads wendet automatisch die notwendigen Kontrollen und Schutzmaßnahmen (z. B. Datenstandort, Beschränkungen des Personalzugriffs) an, um spezifische Compliance-Standards zu erfüllen.