Google ACE: Sicherheit, Compliance und Datenschutz — Lernleitfaden
Teil des Google Associate Cloud Engineer — 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 einem Modell der geteilten Verantwortung (Shared Responsibility Model) und einem Secure-by-Default- sowie Defense-in-Depth-Ansatz. Google sichert die physische Infrastruktur, die grundlegenden Dienste und die Standardverschlüsselung, während Sie für die Identitäts- und Zugriffsverwaltung, die Datenklassifizierung und -aufbewahrung, die Anwendungskonfigurationen und die Betriebsprozesse verantwortlich sind. Gestalten Sie über die gesamte Ressourcenhierarchie hinweg nach dem Prinzip der geringsten Rechte (Least Privilege), verwenden Sie Gruppen anstelle von Einzelpersonen, bevorzugen Sie verwaltete Identitäten und kurzlebige Anmeldedaten und implementieren Sie mehrschichtige Kontrollen, sodass der Ausfall einer einzelnen Kontrolle nicht zu einer Kompromittierung führt. Bauen Sie von Anfang an Observability- und Reaktions-Workflows auf, damit der Sicherheitsstatus kontinuierlich gemessen und verbessert werden kann.
Grundlagen der Identitäts- und Zugriffsverwaltung
- Geteilte Verantwortung und Prinzip der geringsten Rechte
- Organisieren Sie Projekte unter einer einzigen Organisation mit Ordnern, die Vertrauensgrenzen widerspiegeln. Wenden Sie Einschränkungen durch Organisationsrichtlinien an, um sichere Standardeinstellungen zu erzwingen (z. B. öffentliche IPs verbieten, Standorte einschränken, Erstellung von Dienstkontoschlüsseln verhindern).
- Weisen Sie IAM-Rollen Google Groups zu, nicht einzelnen Nutzern, und bevorzugen Sie vordefinierte Rollen gegenüber einfachen Rollen. Überprüfen Sie Rollenbindungen regelmäßig und entfernen Sie ungenutzte Berechtigungen.
Sorgen Sie für Überprüfbarkeit und Nachvollziehbarkeit. Für den administrativen Betriebssystemzugriff auf VMs verwenden Sie OS Login mit benutzerspezifischen SSH-Schlüsseln; weisen Sie Gruppen die Rollen roles/compute.osLogin oder roles/compute.osAdminLogin zu. Beispiel:
undefined
-
undefined
Häufige Fehlerquellen: Zuweisung der Rollen „Owner“ oder „Editor“ an Nutzer, Verwendung projektweiter SSH-Schlüssel und Erstellung langlebiger Dienstkontoschlüssel.
Schutz des Anwendungszugriffs mit BeyondCorp und Identity-Aware Proxy (IAP)
- IAP beendet den identitätsbasierten Zugriff an der Edge von Google für HTTPS-Anwendungen und für TCP-Weiterleitung (SSH/RDP), wodurch Anwendungen oder Bastion-Hosts nicht mehr im Internet exponiert werden müssen. Kombinieren Sie dies mit kontextsensitiven Zugriffsrichtlinien (Access Context Manager), um Gerätestatus, IP-Bereiche oder Nutzergruppen vorauszusetzen.
- Vorteile: zentralisierte Authentifizierung und Autorisierung (AuthN/Z), starke Nachvollziehbarkeit, reduzierte Angriffsfläche und vereinfachte Firewall-Richtlinie (eingehenden Verkehr ablehnen, außer für Load Balancer/IAP).
- Abwägungen: Eine Fehlkonfiguration kann Administratoren aussperren; halten Sie einen Notfallzugang (Break-Glass Path) bereit (eingeschränkter Projekt-Owner, Out-of-Band-Konsolenzugriff). Einige Legacy-Protokolle oder Nicht-HTTP-Dienste erfordern möglicherweise IAP-TCP-Weiterleitung oder alternative Kontrollen.
Dienstkonten und Workload Identity
- Bevorzugen Sie das Anfügen von Dienstkonten an Compute Engine, GKE mit Workload Identity, Cloud Run und Cloud Functions, damit Workloads automatisch kurzlebige Token erhalten. Vermeiden Sie das Einbetten von Schlüsseln; deaktivieren Sie die Erstellung von Dienstkontoschlüsseln per Organisationsrichtlinie. Fassen Sie den Geltungsbereich von IAM für Dienstkonten eng (Prinzip der geringsten Rechte).
- Fehlerquellen: zu weitreichende Zuweisung der Rolle roles/iam.serviceAccountUser, was Identitätsübernahme (Impersonation) ermöglicht; überprivilegierte Dienstkonten, die zu Zielen für Lateral Movement werden.
Datenschutz und Schlüsselverwaltung
- Verschlüsselung, Cloud KMS, CMEK und Envelope-Verschlüsselung
- Google verschlüsselt standardmäßig alle Daten im Ruhezustand (at rest) und während der Übertragung (in transit). Für zusätzliche Kontrolle und Funktionstrennung verwenden Sie vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) in Cloud KMS. Viele Dienste (BigQuery, Cloud Storage, Pub/Sub, Compute Engine-Laufwerke) unterstützen CMEK; die Dienste verwenden Envelope-Verschlüsselung, bei der Ihr CMEK die DEKs pro Objekt oder pro Chunk umschließt.
Planen Sie die Schlüsselhierarchie: Schlüsselbunde (Key Rings) pro Region, Kryptoschlüssel pro Datendomäne und eine Rotation alle 90–365 Tage je nach Risiko. Beispiel für eine Rotation:
undefined
Zugriffskontrolle: Weisen Sie Dienstkonten die Rolle Cloud KMS CryptoKey Encrypter/Decrypter nur für die benötigten Schlüssel zu. Überwachen Sie dies mit den Cloud KMS-Nutzungsprotokollen.
Fehlerquellen und Abwägungen: Das Deaktivieren oder Löschen eines CMEK macht abhängige Daten unlesbar; planen Sie Notfall-Runbooks, überprüfen Sie IAM vor einer Rotation doppelt und stellen Sie die Schlüsselverfügbarkeit über Deployments hinweg sicher. Erwägen Sie den External Key Manager, wenn Sie Schlüssel außerhalb von Google Cloud aufbewahren müssen; berücksichtigen Sie die zusätzliche Latenz und das Risiko externer Abhängigkeiten.
Secret Manager und die Beseitigung von hartcodierten Anmeldedaten
- Speichern Sie API-Schlüssel, DB-Passwörter und Token im Secret Manager mit automatischer Versionierung und IAM-basiertem Zugriff. Integrieren Sie die Rotation über Cloud Scheduler → Pub/Sub → Cloud Functions/Run, wodurch das Upstream-System aktualisiert und eine neue Secret-Version geschrieben wird. Anwendungen rufen Secrets beim Start oder bei Bedarf ab und cachen sie nur minimal.
- Best Practices: Committen Sie niemals Secrets in Code oder Images; vermeiden Sie die Ausgabe von Secrets in Protokollen; weisen Sie Workload-Identitäten die Rolle roles/secretmanager.secretAccessor zu; verwenden Sie Labels, um die Sensitivität zu kennzeichnen.
- Fehlerquellen: das Einbetten von Secrets in Umgebungsvariablen, die bei Abstürzen protokolliert werden; das Vergessen, nachgelagerte Apps nach einer Rotation zu aktualisieren; zu weitreichende IAM-Berechtigungen für Secrets.
Datenklassifizierung, -aufbewahrung und Datenschutz
- Klassifizieren Sie Daten (öffentlich, intern, vertraulich, reguliert) und versehen Sie Assets mit Labels. Verwenden Sie BigQuery-Sicherheit auf Spaltenebene und Zeilenzugriffsrichtlinien für eine feingranulare Kontrolle. Zur Erkennung und Maskierung verwenden Sie Sensitive Data Protection (DLP).
- Implementieren Sie die Aufbewahrung: Cloud Storage Object Lifecycle (altersbasierte Klassenübergänge, Löschen), Bucket-Aufbewahrungsrichtlinien mit Holds und TTLs für BigQuery-Tabellen oder -Partitionen. Richten Sie die Aufbewahrung an den rechtlichen Anforderungen aus; eine längere Aufbewahrung erhöht Risiko und Kosten.
- Datenschutz und Datenstandort (Residency): Schränken Sie Ressourcenstandorte mit Organisationsrichtlinien ein; wählen Sie zwischen multiregionalem und regionalem Speicher basierend auf Souveränitäts- und Latenzanforderungen. Erstellen Sie Nachweise mit Audit-Logs und SCC-Sicherheitsstatus-Dashboards.
Netzwerk- und Edge-Sicherheit
Tiefenverteidigung für Netzwerke
- Verwenden Sie VPC-Firewallregeln mit einem „Default Deny“-Ansatz (standardmäßig alles verweigern); erlauben Sie nur notwendige Quellbereiche und Ports. Bevorzugen Sie Private Google Access und Private Service Connect, um API-Traffic vom öffentlichen Internet fernzuhalten. Protokollieren Sie VPC Flow Logs und Firewall Rules Logging; überprüfen Sie Egress-Muster regelmäßig.
- Für die Steuerung des ausgehenden Verkehrs, verweigern Sie standardmäßig allen Egress-Traffic und erlauben Sie dann explizit notwendige Ziele über einen FQDN-Egress-Proxy oder NAT plus Proxy. Überwachen Sie Cloud NAT-Logs und konfigurieren Sie das DNS-Logging.
VPC Service Controls (VPC SC), Service-Perimeter und Zugriffsebenen
- Umschließen Sie unterstützte Google APIs (z. B. BigQuery, Storage, Pub/Sub) mit Service-Perimetern, um das Risiko der Datenexfiltration zu mindern, selbst wenn Anmeldeinformationen kompromittiert sind. Verwenden Sie den Access Context Manager, um Zugriffsebenen nach Benutzergruppe, IP oder Gerätestatus zu definieren und so kontextsensitive Richtlinien zu ermöglichen.
- Konfigurieren Sie bei Bedarf Egress-Regeln für legitime perimeterübergreifende Integrationen und Perimeter-Brücken. Testen Sie mit dem Dry-Run-Modus von VPC SC, um potenzielle Störungen vor der Durchsetzung aufzudecken.
- Fehlerszenarien: unbeabsichtigtes Blockieren von CI/CD- oder projektübergreifenden Jobs, Fehlschlagen von Drittanbieter-Integrationen oder Entwickler, die die Kontrollen mit nicht verwalteten Geräten umgehen. Dokumentieren Sie Ausnahmen und überprüfen Sie diese regelmäßig.
Cloud Armor, DDoS-Schutz und WAF-Regeln
- Das globale Edge-Netzwerk von Google bietet einen ständigen L3/L4-DDoS-Schutz. Cloud Armor fügt L7-Schutzmechanismen für externe HTTP(S)-Load-Balancer hinzu, einschließlich Ratenbegrenzung, geo-/IP-basiertem Zugriff, benutzerdefinierten Ausdrücken und vorkonfigurierten WAF-Regelsätzen.
- Beispiel für das Erstellen und Anhängen einer einfachen WAF:
- gcloud compute security-policies create web-waf
- gcloud compute security-policies rules create 1000 –security-policy=web-waf –expression=“evaluatePreconfiguredWaf(‘sqli-v33-stable’)” –action=deny-403 –preview
- Hängen Sie die Richtlinie an Ihren HTTPS-Load-Balancer-Backend-Service an.
- Best Practices: Starten Sie Regeln im Vorschaumodus, um False Positives zu reduzieren, fügen Sie Allow-Regeln für bekanntermaßen unbedenklichen Traffic hinzu und aktivieren Sie Adaptive Protection, falls verfügbar. Abwägungen: Cloud Armor wird bei HTTP(S)- und proxy-basierten Load Balancern durchgesetzt; Network Load Balancer und interne LBs erfordern andere Kontrollen.
Sicherheitsbetrieb und Compliance
Security Command Center (SCC) und Posture-Management
- Verwenden Sie SCC als Steuerungsebene für die Risikotransparenz. Die Standard-Stufe aggregiert Ergebnisse zu Fehlkonfigurationen und Schwachstellendaten; die Premium-Stufe fügt Bedrohungserkennungen (z. B. Event Threat Detection, VM and Container Threat Detection) und Einblicke in Angriffspfade hinzu.
- Triagieren Sie Ergebnisse nach Schweregrad, weisen Sie Verantwortliche zu und verfolgen Sie sie bis zur Behebung. Exportieren Sie Ergebnisse zur SIEM-Integration und als Nachweis nach BigQuery oder Pub/Sub. Messen Sie die Sicherheitslage kontinuierlich anhand der Unternehmensrichtlinien und richten Sie Benachrichtigungen für Regressionen ein.
Shielded VM, Secure Boot, vTPM, Integritätsüberwachung und OS-Härtung
- Aktivieren Sie Shielded VM-Funktionen, um Rootkits und Manipulationen beim Booten zu blockieren: Secure Boot, vTPM und Integritätsüberwachung zur Erkennung von Änderungen an Bootloadern und Kernel. Einige benutzerdefinierte Kernel oder unsignierte Module können bei Secure Boot fehlschlagen; validieren Sie Images vor der Aktivierung.
- Härten Sie das Betriebssystem mit OS Config für Patch-Compliance, an CIS ausgerichtete Baselines, minimale Pakete, passwortloses SSH und die Protokollierung von sudo- und auth-Ereignissen. Bevorzugen Sie IAP TCP-Weiterleitung für SSH und beschränken Sie den Ingress-Verkehr auf 0.0.0.0/0.
Forensische Protokollierung, Incident-Triage, Eindämmung und Behebung
- Protokollierung zur Ermöglichung von Forensik: Audit-Logs für Admin-Aktivitäten und Datenzugriffe, VPC Flow Logs, Firewall Rules Logging, Cloud DNS-Logs, Load-Balancer-Logs sowie Zugriffslogs für Cloud KMS und Secret Manager. Exportieren Sie die Logs in ein zentrales Log-Projekt und nach BigQuery mit angemessenen Aufbewahrungsfristen und Zugriffskontrollen.
- Playbook für Triage und Eindämmung:
- Validieren Sie Indikatoren mit SCC-Ergebnissen und korrelierten Logs.
- Dämmen Sie den Vorfall ein, indem Sie verdächtige Token widerrufen, kompromittierte Dienstkonten deaktivieren, ablehnende Firewall-Regeln hinzufügen oder Instanzen vorübergehend mit Tags isolieren.
- Sichern Sie Beweismittel: Erstellen Sie Snapshots von Festplatten, exportieren Sie Logs, erfassen Sie bei Bedarf den Arbeitsspeicher mit genehmigten Tools und dokumentieren Sie die Chain-of-Custody (Beweismittelkette).
- Beheben Sie den Vorfall: Rotieren Sie Secrets und Schlüssel, patchen Sie Schwachstellen, erstellen Sie Systeme aus bekanntermaßen guten Images neu, fügen Sie Erkennungsmechanismen hinzu, um ein Wiederauftreten zu verhindern, und führen Sie eine Post-Incident-Überprüfung durch, um die Kontrollen zu verstärken.
Praktisches Problemszenario
Nimbus Finance betreibt Web- und API-Workloads hinter externen HTTP(S)-Load-Balancern, verarbeitet regulierte Daten in BigQuery und Cloud Storage und gewährt Entwicklern Remote-Admin-Zugriff. Eine kürzlich durchgeführte Red-Team-Übung zeigte Risiken der Datenexfiltration durch kompromittierte Anmeldeinformationen und Lateral Movement auf. Das Betriebsteam muss den Zugriff härten, Daten schützen und die Erkennung verbessern, ohne die Bereitstellung zu stören.
- OS Login mit Admin-Zuordnung erzwingen
- Schritte: OS Login projektweit aktivieren;
compute.osAdminLoginzur Entwicklergruppe hinzufügen; projektweite SSH-Schlüssel entfernen. - Begründung: Benutzerspezifische SSH-Schlüssel und IAM-basierte Rollenzuweisungen ermöglichen eine klare Zuordnung und einen einfachen Widerruf. Die Beseitigung gemeinsam genutzter Schlüssel reduziert Lateral Movement.
- Remote-Zugriff mit IAP und kontextsensitivem Zugriff absichern
- Schritte: Die Admin-Benutzeroberfläche hinter einen durch IAP geschützten HTTPS-Load-Balancer stellen; Mitgliedschaft in der Ops-Gruppe und eine Unternehmens-IP/Geräte-Posture über den Access Context Manager erfordern.
- Begründung: Der Zero-Trust-Zugriff beseitigt die öffentliche Erreichbarkeit und erzwingt zentral Identitäts- und Gerätebedingungen, was das Risiko von Phishing und Credential-Stuffing reduziert.
- Cloud Armor WAF mit gestaffelter Durchsetzung implementieren
- Schritte: Eine Cloud Armor-Richtlinie erstellen; vorkonfigurierte WAF-Regeln für SQLi/XSS im Vorschaumodus aktivieren; eine Ratenbegrenzungsregel für /login hinzufügen; Logs überwachen; dann durchsetzen.
- Begründung: Der Vorschaumodus reduziert False Positives; gezielte Ratenbegrenzungen schwächen Credential-Stuffing und Bots ab, ohne den legitimen Datenverkehr zu beeinträchtigen.
- Datendienste in VPC Service Controls einbetten
- Schritte: Einen Service-Perimeter für BigQuery- und Cloud Storage-Projekte erstellen; Egress-Regeln für genehmigte CI/CD- und Analyse-Jobs definieren; Zugriffsebenen basierend auf Gruppe und Netzwerk erfordern.
- Begründung: Perimeter mindern die Datenexfiltration mit gültigen Anmeldeinformationen, indem sie einschränken, wo und wie auf geschützte Daten zugegriffen werden kann.
- CMEK mit Cloud KMS anwenden und Rotation planen
- Schritte: Regionale Schlüsselbunde und kryptografische Schlüssel für BigQuery und Storage erstellen; nur Dienstkonten die Rolle
roles/cloudkms.cryptoKeyEncrypterDecryptergewähren; einen 180-tägigen Rotationsplan festlegen; Schlüsselnutzungs-Logs überwachen. - Begründung: CMEK erzwingt eine Funktionstrennung und kontrollierte kryptografische Grenzen; die Rotation begrenzt den Explosionsradius (Blast Radius), falls ein Schlüssel kompromittiert wird.
- Secrets mit Secret Manager zentralisieren und Rotation automatisieren
- Schritte: Datenbank- und Drittanbieter-Token in den Secret Manager verschieben; Workloads den Zugriff nach dem Least-Privilege-Prinzip gewähren; einen Job mit Cloud Scheduler → Pub/Sub → Cloud Run implementieren, um Secrets zu rotieren und neue Versionen zu erstellen.
- Begründung: Beseitigt hartcodierte Anmeldeinformationen; Versionierung und Automatisierung gewährleisten eine vorhersagbare, prüfbare Rotation mit minimaler Ausfallzeit.
- Host-Sicherheit mit Shielded VM und OS-Härtung verstärken
- Schritte: Secure Boot, vTPM und Integritätsüberwachung auf allen Compute Engine-Instanzen aktivieren; passwortloses SSH erzwingen; OS Config verwenden, um wöchentlich zu patchen und CIS-Baselines anzuwenden.
- Begründung: Verhindert Manipulationen auf Boot-Ebene, erkennt Abweichungen (Drift) und reduziert die angreifbare Oberfläche auf Compute-Knoten.
- Beobachtbarkeit und Posture-Management mit SCC erhöhen
- Schritte: SCC Premium unternehmensweit aktivieren; Echtzeit-Benachrichtigungen an Pub/Sub konfigurieren; Ergebnisse und Logs nach BigQuery exportieren; Dashboards für wichtige KPIs erstellen (offene hohe Befunde, durchschnittliche Zeit bis zur Behebung).
- Begründung: Eine einheitliche Transparenz verkürzt die Zeitfenster von der Erkennung bis zur Reaktion und liefert Compliance-Nachweise.
- Ein Incident-Playbook vorbereiten und testen
- Schritte: Triage-Schritte, privilegierte Break-Glass-Konten und Eindämmungsmaßnahmen (IAM deaktivieren, Firewall-Isolierung, Token widerrufen) dokumentieren; vierteljährlich üben; Log-Aufbewahrung und Objektsperren im Beweismittel-Projekt erzwingen.
- Begründung: Eingeübte Arbeitsabläufe reduzieren Fehler unter Druck und wahren die forensische Integrität für die Ursachenanalyse und das regulatorische Berichtswesen.
- Änderungen validieren und Störungen minimieren
- Schritte: VPC SC Dry-Run und Cloud Armor-Vorschau verwenden, um Fehler zu erkennen; umgebungsweise mit Canaries ausrollen; einen Rollback-Plan und Änderungsfenster pflegen.
- Begründung: Ein kontrollierter Rollout mindert Verfügbarkeitsrisiken durch verschärfte Sicherheit und erreicht gleichzeitig die angestrebte Reduzierung des Exfiltrations- und Zugriffsrisikos.
← Überwachung · Alle Domänen · Zuverlässigkeit →
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →