Google PCA: Sicherheit, Compliance und Datenschutzarchitektur — Lernleitfaden

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Teil des Google Professional Cloud Architect — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Sicherheit, Compliance und Datenschutz in Google Cloud basieren auf geteilter Verantwortung (Shared Responsibility) und tiefengestaffelter Verteidigung (Defense in Depth). Google sichert die zugrunde liegende Infrastruktur, während Sie für die Architektur sicherer Identitäten, Netzwerke, Anwendungen und Datenverarbeitung verantwortlich sind. Übernehmen Sie Zero Trust als Leitmodell: Vertrauen Sie dem Netzwerk niemals implizit, überprüfen Sie kontinuierlich Identität und Kontext und setzen Sie das Prinzip der geringsten Rechte (Least Privilege) strikt durch. Entwerfen Sie für den Kompromittierungsfall (Design for Compromise): Gehen Sie davon aus, dass Anmeldeinformationen offengelegt, Endpunkte sondiert und interne Dienste missbraucht werden können. Kompensieren Sie dies mit mehrschichtigen Kontrollen (präventiv, detektiv, reaktiv), starker Kryptografie und Schlüsselverwaltung, robuster Überwachung und geübter Reaktion auf Vorfälle (Incident Response).

Abwägungen sind unvermeidlich. Strengere Kontrollen können die Latenz, die betriebliche Komplexität und die Kosten erhöhen. Ihre Architektur sollte Risiken explizit gegen Benutzerfreundlichkeit und Leistung abwägen und dabei die nachweisbare Compliance und Forensik-Bereitschaft gewährleisten.

Identitäts- und Zugriffsarchitektur

• Prinzipien und Modell

  • Prinzip der geringsten Rechte (Least Privilege) als Standard: Vergeben Sie die kleinstmögliche Menge an Berechtigungen, die zur Erledigung einer Aufgabe erforderlich ist, und bevorzugen Sie vordefinierte oder benutzerdefinierte Rollen gegenüber primitiven Rollen (Owner, Editor, Viewer).
  • Funktionstrennung (Separation of Duties): Teilen Sie Rollen auf zwischen Buildern (CI/CD), Deployern, Betreibern und Sicherheitspersonal. Verwenden Sie Break-Glass-Konten mit strengen Kontrollen und Protokollierung für Notfälle.
  • Durchsetzung von Zero Trust: Nutzen Sie kontextsensitiven Zugriff (Context-Aware Access), um Benutzer, Gerät, Standort und Risiko zu überprüfen, fordern Sie starke MFA und bewerten Sie den Sitzungskontext kontinuierlich.
  • Organisationsrichtlinien (Organization Policy) und IAM Deny: Kodifizieren Sie Leitplanken (z. B. Erstellung von Service-Account-Schlüsseln verbieten, Domain-Freigaben einschränken) und verwenden Sie Deny-Richtlinien, um nicht verhandelbare Grenzen durchzusetzen.

• IAM-Implementierung und Service-Account-Strategie

  • Etablieren Sie ein hierarchiegesteuertes Zugriffsmodell: Ordner spiegeln Geschäftsbereiche oder Umgebungen (Prod, Non-Prod) wider; Projekte isolieren den Schadensradius (Blast Radius) und die Abrechnung; Service Accounts (SAs) repräsentieren Workloads.
  • Ein Workload, ein Service Account: Vermeiden Sie die gemeinsame Nutzung von SAs für nicht zusammengehörige Dienste. Binden Sie Berechtigungen an den Bereitstellungskontext (Projekt) und den Ressourcenkontext.
  • Bevorzugen Sie kurzlebige Anmeldeinformationen über Service Account Impersonation und Workload Identity Federation. Deaktivieren Sie benutzerverwaltete Service-Account-Schlüssel; falls unvermeidbar, isolieren Sie deren Verwendung, rotieren Sie sie häufig und überwachen Sie sie mit Audit-Logs.
  • Verwenden Sie Access Boundaries, um zur Anfragezeit einzuschränken, worauf ein impersonierter SA zugreifen kann (z. B. Beschränkung auf bestimmte GCS-Objektpfade), um den Schadensradius selbst bei Missbrauch eines privilegierten SAs einzudämmen.
  • Bedingtes IAM (Conditional IAM): Wenden Sie Bedingungen auf Ressourcenebene an (Zeit, IP, Prinzipalattribute), um den Zugriff einzuschränken. Beispiel: Produktionszugriff nur aus den IP-Bereichen des Unternehmens und während der Änderungsfenster erlauben.

• Fehlermodi und Abwägungen

  • Überprivilegierte Rollen (z. B. Editor auf Projektebene) erhöhen das Risiko; bevorzugen Sie granulare Rollen und validieren Sie diese über Policy Analyzer.
  • Die unkontrollierte Verbreitung von Service-Account-Schlüsseln in CI/CD und lokalen Skripten ist ein häufiger Angriffsvektor; bei der Verwendung von Impersonation müssen einige ältere Tools möglicherweise angepasst werden.
  • IAM Deny-Richtlinien sind mächtig, können aber bei der Fehlersuche schwierig sein; führen Sie Änderungen schrittweise und getestet in Nicht-Produktionsumgebungen mit expliziten Probeläufen (Dry Runs) ein.

Beispiel (Impersonation ohne Schlüsselerstellung):

• gcloud auth print-access-token –impersonate-service-account=svc-ci@proj.iam.gserviceaccount.com

Datenschutz und Kryptografie

• Cloud KMS und Schlüsselverwaltungsmodelle
  • Native Verschlüsselung von Daten im Ruhezustand (at-rest) ist Standard. Für zusätzliche Kontrolle verwenden Sie vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) mit Diensten wie BigQuery, Cloud Storage, Compute Engine-Disks, Pub/Sub und persistenten GKE-Volumes.
  • Entwerfen Sie eine Schlüsselhierarchie nach Umgebung und Datendomäne. Verwenden Sie separate Keyrings pro Standort und separate Schlüssel pro Anwendung oder Dataset, um den Schadensradius zu begrenzen.
  • Rotation: Aktivieren Sie die geplante Rotation und nehmen Sie ältere Schlüsselversionen für Anwendungen mittels Envelope-Verschlüsselung ordnungsgemäß außer Betrieb. Validieren Sie die Kompatibilität der Konsumenten, bevor Sie die Rotationsfrequenz erhöhen.
  • External Key Manager (EKM) und External Key Access (EKA) platzieren Schlüssel außerhalb von Google Cloud zur Einhaltung regulatorischer Vorgaben. Die Nachteile umfassen zusätzliche Latenz und die Abhängigkeit von der Verfügbarkeit externer HSMs; planen Sie für den Betrieb im eingeschränkten Modus.
  • Erzwingen Sie das IAM-Prinzip der geringsten Rechte (Least Privilege) für CryptoKeys. Nutzen Sie Audit-Logs auf Schlüsselebene als Nachweis für Zugriffe.

Beispiel (CMEK mit Rotation):

• gcloud kms keyrings create app-ring –location=us-central1

• gcloud kms keys create data-key –keyring=app-ring –location=us-central1 –purpose=encryption –rotation-period=90d

• Verschlüsselung auf Anwendungsebene

  • Verwenden Sie Envelope-Verschlüsselung (z. B. mit Tink), um sensible Felder auf der Anwendungsebene zu verschlüsseln. Dies ermöglicht selektiven Zugriff und die Isolation von Mandantendaten. Leiten Sie pro Mandant eigene Schlüssel ab, um mandantenübergreifende Auswirkungen zu minimieren.
  • Validieren Sie die Integrität (AEAD), um Manipulation und Replay-Angriffe zu verhindern.

• Secret Manager und Lebenszyklus von Secrets

  • Speichern Sie Anmeldeinformationen, Token und API-Schlüssel als versionierte Secrets; niemals in Images, Git oder Instanz-Metadaten. Weisen Sie dem Laufzeit-Dienstkonto IAM-Berechtigungen auf Secret- oder Projektebene zu.
  • Rotation: Automatisieren Sie die Rotation mithilfe von durch Pub/Sub ausgelösten Cloud Functions/Cloud Run, um eine neue Version zu erstellen, abhängige Systeme zu aktualisieren und alte Versionen zu widerrufen. Ersetzen Sie langlebige DB-Passwörter bevorzugt durch IAM-basierte Datenbankauthentifizierung oder kurzlebige Token.
  • Konfigurationssicherheit: Trennen Sie nicht geheime Konfigurationen (ConfigMap, Umgebungsvariablen) von Secrets. Verhindern Sie die Offenlegung von Secrets in Protokollen und Fehlermeldungen.

Beispiel (neue Secret-Version hinzufügen):

• gcloud secrets versions add db-password –data-file=password.txt –secret=db-password

• Compute-Härtung und Confidential Computing

  • Shielded VMs: Aktivieren Sie Secure Boot, vTPM und Integritätsüberwachung zum Schutz vor Bootkits und Rootkits. Erzwingen Sie dies über Organisationsrichtlinien und validieren Sie es in CI/CD-Pipelines.
  • Confidential VMs: Die standardmäßige Speicherverschlüsselung schützt Daten während der Verarbeitung (in-use) mit minimalen Konfigurationsänderungen; bewerten Sie die Leistungsauswirkungen bei Workloads mit hohem Durchsatz und hoher Krypto-Last.
  • Gehärtete Images: Beginnen Sie mit von Google optimierten oder CIS-gehärteten Baselines; verwalten Sie das Patching mit OS Config und deaktivieren Sie unnötige Pakete und Ports.

Netzwerk- und Edge-Sicherheit

• Netzwerksegmentierung und Egress-Kontrolle

  • Segmentieren Sie nach Ebene und Sensibilität mithilfe separater VPCs, Subnetze und hierarchischer Firewall-Richtlinien. Kombinieren Sie identitätsbasierte Firewall-Tags mit Service-zu-Service-Einschränkungen (z. B. GKE NetworkPolicy), um Ost-West-Kontrollen durchzusetzen.
  • Kontrollieren Sie den Egress-Verkehr mit Cloud NAT, DNS-Richtlinien und eingeschränktem Private Google Access, um die Datenexfiltration zu minimieren. Verwenden Sie explizite Egress-Allowlists und Proxy-Inspektion, wo dies gerechtfertigt ist.

• VPC Service Controls (VPC SC)

  • Erstellen Sie Dienst-Perimeter um Projekte, die relevante Daten enthalten, um die Exfiltration von Daten über von Google verwaltete APIs (GCS, BigQuery, Secret Manager, Pub/Sub usw.) zu verhindern.
  • Zugriffsebenen: Definieren Sie kontextbezogene Bedingungen (Benutzeridentität, IP-Bereiche, Device Posture), die erfüllt sein müssen, um auf Dienste innerhalb des Perimeters zuzugreifen.
  • Verwenden Sie Perimeter-Bridges für kontrollierte Workflows über mehrere Perimeter hinweg und Egress-Regeln, um Ziele einzuschränken. Testen Sie im Dry-Run-Modus, um eine Unterbrechung von Pipelines zu vermeiden.
  • Einschränkungen: Schützt den Verkehr zu Compute Engine-IPs nicht direkt; ergänzen Sie dies durch Firewall- und Egress-Kontrollen. Einige Tools und hybride Muster erfordern möglicherweise perimeterfähige Dienstkonten und Private Service Connect zu eingeschränkten VIPs.

• Edge- und Anwendungsschutz

  • Cloud Armor: Schützen Sie HTTP(S)-Anwendungen hinter dem globalen externen Load Balancer mit L3/L4/L7-DDoS-Abwehr, IP-Allow/Deny-Listen, geobasierten Kontrollen und Ratenbegrenzung.
  • WAF-Regeln: Wenden Sie vorkonfigurierte verwaltete Regeln und benutzerdefinierte Signaturen für die OWASP Top 10 an; optimieren Sie diese, um False Positives zu reduzieren. Hängen Sie sie pro Backend-Dienst an, um Richtlinien je nach API-Version oder App-Komponente anzupassen.
  • API-Schutz: Schalten Sie APIs einen API Gateway oder Apigee vor für Authentifizierung, Kontingente, Schemavalidierung und Bedrohungserkennung; integrieren Sie Cloud Armor zur Durchsetzung am Edge; ziehen Sie gegebenenfalls reCAPTCHA Enterprise und Bot-Kontrollen in Betracht.
  • Nachteile: Eine tiefere Inspektion kann die Latenz erhöhen und zu operativem Rauschen führen. Stellen Sie Regeln im Vorschaumodus bereit, überwachen Sie die Protokolle und setzen Sie sie schrittweise durch.

Sicherheitsbetrieb, Überwachung und Compliance

• Security Command Center (SCC) und Bedrohungserkennung

  • SCC aggregiert Asset-Inventar und Ergebnisse über Projekte und Organisationen hinweg. Nutzen Sie es, um den Sicherheitsstatus als Baseline festzulegen (öffentliche Buckets, offene Firewall-Regeln), Abweichungen zu verfolgen und Workflows zur Problembehebung zu steuern.
  • Die Premium-Bedrohungserkennung umfasst Event Threat Detection, VM Threat Detection und Container Threat Detection, um Malware, Cryptomining und anomales Verhalten zu identifizieren.
  • Integrieren Sie Ergebnisse in Ticketing- und SOAR-Pipelines; definieren Sie Unterdrückungs-/Ausnahmerichtlinien mit Ablaufdatum, um Alert-Müdigkeit zu vermeiden.

• Schwachstellen- und Artefaktsicherheit

  • Verwenden Sie Artifact Analysis, um Container-Images auf CVEs zu scannen; setzen Sie Richtlinien zur Bereitstellungszeit mit Binary Authorization und signierten Attestierungen aus der CI durch.
  • Patch-Management über OS Config; überwachen Sie Expositionsfenster und automatisieren Sie Rollouts mit Canaries.

• Audit-Logs, Datenschutz und Nachweise

  • Cloud Audit Logs stellen standardmäßig Logs zu Admin-Aktivitäten und Systemereignissen bereit; Datenzugriffs-Logs können pro Dienst aktiviert werden und sind kostenpflichtig. Leiten Sie Logs zur Analyse an BigQuery und zur unveränderlichen Aufbewahrung und für Legal Holds an Cloud Storage weiter.
  • Datenklassifizierung: Verwenden Sie Cloud DLP, um PII zu entdecken und zu klassifizieren, Labels und Tags anzuwenden und Schutzstufen zuzuordnen (CMEK, VPC SC, Confidential VMs).
  • Datenschutz und Datenresidenz: Schränken Sie Standorte über Organisationsrichtlinien ein; stimmen Sie CMEK- und Speicherstandorte auf regulatorische Anforderungen ab.
  • Legal Holds und Aufbewahrung: Aktivieren Sie Bucket-Aufbewahrungsrichtlinien und -Holds; verwenden Sie bei Bedarf Object Versioning. Dokumentieren Sie die Beweismittelkette (Chain of Custody) für forensische Images und Logs, um gerichtsverwertbare Beweise zu erstellen.

• Incident Response und forensische Bereitschaft

  • Bereiten Sie Runbooks, Zugriffspfade und Automatisierungen vor. Stellen Sie sicher, dass die Einsatzkräfte über Zugriff mit den geringsten Rechten (Least-Privilege) verfügen und das Auditing in der gesamten Organisation, den Ordnern und Projekten aktiviert ist.
  • Eindämmung: Isolieren Sie Instanzen, indem Sie sie aus Load Balancern entfernen, Firewall-Regeln für ausgehenden Verkehr (Deny Egress) anwenden oder Projekte in strengere Organisationsrichtlinien verschieben; deaktivieren Sie kompromittierte Service Accounts und rotieren Sie Secrets und Schlüssel.
  • Forensik: Erstellen Sie Snapshots von Festplatten und exportieren Sie Images für die Offline-Analyse; sichern Sie Logs durch Exporte. Verwenden Sie gegebenenfalls Packet Mirroring. Vermeiden Sie die Veränderung von Beweismitteln; arbeiten Sie mit Kopien.
  • Wiederherstellung: Erstellen Sie Systeme aus vertrauenswürdigen Images neu, stellen Sie Secrets wieder her und validieren Sie sie mit Smoke- und Sicherheitstests. Führen Sie Post-Incident-Reviews durch und lassen Sie die Erkenntnisse in Leitplanken und Erkennungsmechanismen einfließen.

Praktisches Problemszenario

NimbusPay, ein Fintech-SaaS, muss PCI-gekennzeichnete Daten über mandantenfähige Microservices auf Google Cloud verarbeiten, die Datenresidenz in der EU durchsetzen, sich vor Angriffen auf der API-Ebene schützen und auditierbare Nachweise der Kontrollen erbringen. Sie werden eine neue v2-API einführen, während v1 unter demselben Hostnamen aktiv bleibt.

Vorgehensweise:

1. Projekte und Identitäten partitionieren

• Erstellen Sie separate Projekte pro Umgebung und Microservice-Tier (Ingest, Processing, Reporting). Weisen Sie jedem Dienst einen eindeutigen Workload Service Account zu. Begründung: Isoliert den Schadensradius („Blast Radius“) und ordnet das Prinzip der geringsten Rechte (Least Privilege) diskreten Workloads zu.

2. Zero Trust und Least Privilege durchsetzen

• Vergeben Sie vordefinierte/benutzerdefinierte Rollen an Service Accounts und DevOps-Gruppen; wenden Sie bedingtes IAM an, um den Produktionszugriff auf Unternehmens-IPs und -Zeiten zu beschränken. Begründung: Reduziert laterale Bewegungen und versehentliche Änderungen.

3. Statische Service Account Keys entfernen

• Deaktivieren Sie benutzerverwaltete SA-Schlüssel über eine Organisationsrichtlinie. Verwenden Sie Service Account Impersonation für CI/CD und den Betrieb; wenden Sie Access Boundaries an, um die GCS-Pfade pro Mandant zu begrenzen. Begründung: Eliminiert einen häufigen Vektor für den Diebstahl von Anmeldedaten und schränkt den Datenzugriff ein, selbst wenn Tokens gestohlen werden.

4. Daten mit CMEK und regionalen Kontrollen schützen

• Erstellen Sie Cloud KMS-Schlüsselbunde und -Schlüssel in den Regionen europe-west; aktivieren Sie CMEK für BigQuery-Datasets, GCS-Buckets und Persistent Disks. Konfigurieren Sie die geplante Rotation und die Versionsüberwachung. Begründung: Nachweisbare kryptografische Kontrolle, die auf die EU-Datenresidenz und PCI abgestimmt ist.

5. Verschlüsselung auf Anwendungsebene für Kartendaten einführen

• Verwenden Sie Envelope Encryption (Tink AEAD) mit mandantenspezifischen Datenschlüsseln, die von CMEK umschlossen (wrapped) sind; speichern Sie nur Chiffretext in Datenbanken. Begründung: Schutz auf Feldebene und minimierter Umfang bei der Incident-Triage.

6. Secrets zentralisieren und automatisch rotieren

• Speichern Sie DB-Anmeldedaten und API-Tokens im Secret Manager mit dienstspezifischem IAM. Implementieren Sie durch Pub/Sub ausgelöste Rotations-Jobs, die neue Versionen erstellen und Deployments aktualisieren. Wechseln Sie, wo möglich, zur IAM-DB-Authentifizierung für Cloud SQL. Begründung: Auditierbarer Lebenszyklus von Secrets mit minimaler Ausfallzeit.

7. Netzwerke segmentieren und Egress-Verkehr kontrollieren

• Verwenden Sie hierarchische Firewall-Richtlinien, um Web→API→DB-Flüsse zu erzwingen; verbieten Sie Web→DB direkt. Aktivieren Sie Cloud NAT mit Egress-Allowlists und Private Google Access (restricted) für Google-APIs. Begründung: Schränkt Ost-West-Bewegungen ein und blockiert nicht genehmigte Exfiltration.

8. Datendienste mit VPC Service Controls umschließen

• Platzieren Sie BigQuery-, GCS- und Secret Manager-Projekte in einem Service Perimeter; definieren Sie Zugriffsebenen, die eine Unternehmens-IP und verwaltete Geräte erfordern. Testen Sie mit einem Dry-Run und setzen Sie die Richtlinie dann durch. Begründung: Mildert die Datenexfiltration durch gestohlene Tokens oder falsch konfigurierte Clients.

9. Den Edge und die APIs sichern

• Schalten Sie dem globalen HTTPS Load Balancer verwaltete Regeln von Cloud Armor und Rate Limiting vor. Verwenden Sie pfadbasiertes Routing, um /v1 und /v2 auf separate Backend-Dienste zu trennen und wenden Sie pro Version maßgeschneiderte WAF-Richtlinien an. Integrieren Sie Apigee für Authentifizierung, Quotas und Schemavalidierung. Begründung: Mehrschichtiger API-Schutz, reibungsloser Übergang von v1 zu v2 und minimierte False Positives.

10. Compute-Ressourcen härten und Artefakte attestieren

• Aktivieren Sie Shielded VMs und Confidential VMs für Verarbeitungsknoten; verwenden Sie CIS-gehärtete Basis-Images. Scannen Sie Images in der Artifact Registry und fordern Sie signierte Attestierungen mit Binary Authorization für GKE. Begründung: Schützt die Boot-Kette und Daten während der Nutzung (Data-in-Use) und setzt Vertrauen in die Lieferkette (Supply Chain) durch.

11. Sicherheitsstatus und Bedrohungen mit SCC überwachen

• Aktivieren Sie SCC Premium, um riskante Konfigurationen und Laufzeitbedrohungen zu erkennen; integrieren Sie es für SLAs in das Ticketing-System. Unterdrücken Sie akzeptierte Risiken mit Ablaufdaten. Begründung: Kontinuierliche Gewährleistung und ein umsetzbares Signal.

12. Protokollieren, aufbewahren und Nachweise erbringen

• Leiten Sie Logs zu Admin-Aktivitäten, Datenzugriff und VPC-Flow-Logs an BigQuery und Cloud Storage mit Aufbewahrungsrichtlinien und Legal Holds weiter. Kennzeichnen Sie Datasets mit Residenz- und Sensitivitäts-Labels. Begründung: Unterstützt Untersuchungen und externe Audits mit bereichsbezogenem Zugriff.

13. Incident Response und Forensik vorbereiten

• Erstellen Sie Runbooks, um kompromittierte Dienste zu isolieren, indem Sie Projekte in einen Quarantäne-Ordner mit strengeren Richtlinien verschieben, beteiligte SAs deaktivieren und Snapshots von

← Vernetzung · Alle Domänen · Zuverlässigkeit →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Google durchsuchen →