Google PCD: Identität, Authentifizierung und Anwendungssicherheit — Lernleitfaden

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Überblick

Identität ist der neue Perimeter in der Google Cloud. Anwendungen müssen Prinzipale (Benutzer, Dienste) authentifizieren und sie für den Zugriff auf Daten und APIs nach dem Least-Privilege-Prinzip autorisieren, während gleichzeitig Secrets, Schlüssel und die Software-Lieferkette geschützt werden. Dieser Abschnitt beschreibt durchgängige Design- und Betriebspraktiken, die Google Cloud IAM, moderne Authentifizierungsprotokolle, Netzwerk- und API-Schutzmaßnahmen, Verschlüsselung, Logging und Reaktionsprozesse kombinieren. Der Schwerpunkt liegt auf kurzlebigen Anmeldedaten, zentralisierten Richtlinien und mehrschichtigen Kontrollen, die bei einem Ausfall sicher („fail-safe“) sind.

Identitäten, Authentifizierung und Zugriffskontrolle

IAM-Rollen und Service Accounts
- Nutzen Sie die Ressourcenhierarchie (Organisation > Ordner > Projekt) und vordefinierte Rollen anstelle von primitiven Rollen. Bevorzugen Sie benutzerdefinierte Rollen nur dann, wenn vordefinierte Rollen zu weitreichend sind.
- Weisen Sie Workloads Service Accounts (SAs) zu. Verwenden Sie nicht die Standard-SAs von Compute Engine oder App Engine wieder. Ein SA pro Workload-Grenze vereinfacht das Least-Privilege-Prinzip und die Rotation von Vertrauensstellungen.
- Setzen Sie das Least-Privilege-Prinzip durch, indem Sie die minimalen Berechtigungen auf dem engsten Ressourcenbereich gewähren.
- Impersonation: Bevorzugen Sie kurzlebige Anmeldedaten über den Service Account Token Creator, damit Menschen, CI/CD-Systeme oder andere Dienste temporären Zugriff erhalten können, ohne Schlüssel speichern zu müssen:
  - Vergeben Sie die Rolle roles/iam.serviceAccountTokenCreator für den Ziel-SA an die aufrufende Identität.
  - Beispiel: gcloud auth print-access-token –impersonate-service-account sa-ci@proj.iam.gserviceaccount.com
- Workload Identity
  - GKE: Verwenden Sie Workload Identity, um Kubernetes Service Accounts an Google Service Accounts zu binden; Tokens werden automatisch projiziert und ausgetauscht – keine JSON-Schlüssel erforderlich.
  - Externe Workloads: Nutzen Sie Workload Identity Federation, um OIDC/SAML-Anmeldedaten (z. B. von GitHub Actions oder aus On-Premises-Systemen) gegen Google-Zugriffstokens auszutauschen, ohne langlebige Schlüssel zu speichern.
- Fehlermodi und Kompromisse
  - Zu weitreichende Rollen oder Berechtigungen mit großem Geltungsbereich führen zu Lateral Movement. Fehlende Token-Creator-Berechtigungen blockieren Impersonation-Flows. JSON-Schlüsseldateien vergrößern den Schadensradius eines Sicherheitsvorfalls.
Benutzerauthentifizierung mit OAuth 2.0, OpenID Connect und Google Identity
- Für die Endbenutzer-Authentifizierung verwenden Sie OIDC mit Google als IdP oder einem Unternehmens-IdP; validieren Sie ID-Tokens serverseitig. Für den API-Zugriff verwenden Sie OAuth 2.0 Access Tokens mit den entsprechenden Scopes.
- Tokens validieren: Überprüfen Sie iss, aud, exp, iat und die Signatur mithilfe der JWKs des IdP; cachen Sie die JWKs und erzwingen Sie eine Schlüsselrotation.
- Für Mobile-/SPA-Backends bevorzugen Sie den Authorization Code Flow mit PKCE. Vermeiden Sie implizite Flows.
- Für die Service-zu-Service-Kommunikation verwenden Sie den OAuth 2.0 Service Account JWT Flow oder mTLS; vermeiden Sie statische API-Schlüssel.
- Beispiel (Token-Impersonation mit gcloud): gcloud auth application-default print-access-token –impersonate-service-account api-sa@p.iam.gserviceaccount.com
- Fehlermodi
  - Die Nichtvalidierung von aud/iss ermöglicht Token-Confusion-Angriffe. Das Akzeptieren abgelaufener Tokens oder die fehlende Rotation von JWKs erhöht das Risiko. Die Verwendung von Refresh Tokens in mobilen Apps legt langlebige Anmeldedaten offen.
Identity-Aware Proxy (IAP) für Browser-Zugriff
- Verwenden Sie IAP, um HTTP-Anwendungen auf Cloud Run, GKE oder Compute Engine abzusichern, ohne Authentifizierungslogik einbetten zu müssen. Erzwingen Sie für den Zugriff die Rolle „Nutzer von IAP-gesicherten Web-Apps“.
- Anwendungen erhalten einen signierten Header (x-goog-iap-jwt-assertion). Überprüfen Sie das JWT, um der Benutzeridentität und E-Mail-Adresse zu vertrauen; verlassen Sie sich zur Authentifizierung nicht auf X-Forwarded-*-Header.
- Häufige Fallstricke: Umgehungspfade, die nicht durch IAP geleitet werden, eine falsch konfigurierte Backend-Firewall oder das Vertrauen auf Client-IP-Header ohne die Integritätssicherung durch Cloud Load Balancing.

Secrets, Schlüssel und Verschlüsselung

Secret Manager
- Speichern Sie API-Schlüssel, Datenbankpasswörter und Webhook-Secrets im Secret Manager. Verlassen Sie sich auf Versionierung, IAM-Kontrollen und Audit-Logs.
- Zugriffsmuster
  - Beim Start abrufen und im Arbeitsspeicher zwischenspeichern; bei Signalen zur Secret-Änderung (Pub/Sub-Benachrichtigungen) aktualisieren.
  - Vermeiden Sie es, Secrets in Images oder Umgebungsvariablen „einzubacken“. Wenn Umgebungsvariablen verwendet werden, stellen Sie sicher, dass diese niemals protokolliert oder in Absturzberichte geschrieben werden.
- Rotation
  - Automatisieren Sie mit Cloud Scheduler + Cloud Functions/Run das Erstellen neuer Versionen, das Aktualisieren abhängiger Systeme und das Veraltenlassen alter Versionen.
  - Beispiel: gcloud secrets versions access latest –secret db-password
- Fehlermodi
  - Übermäßige Secret Manager-Aufrufe pro Anfrage erhöhen die Latenz und bergen das Risiko der Kontingentausschöpfung. Fehlende roles/secretAccessor-Berechtigungen verursachen 403-Fehler zur Laufzeit.
Cloud KMS und Anwendungsverschlüsselung
- Verwenden Sie Envelope-Verschlüsselung: Ein lokal generierter Datenverschlüsselungsschlüssel (DEK) verschlüsselt Daten; ein vom Kunden verwalteter Cloud KMS-Schlüssel (CMEK) verschlüsselt den DEK (KEK).
- Rotieren Sie Schlüssel regelmäßig; planen Sie die Neuverschlüsselung. Bevorzugen Sie beim Schreiben das Vorgehen „mit altem Schlüssel entschlüsseln, mit neuem verschlüsseln“; eine Massen-Neuverschlüsselung von Daten im Ruhezustand ist kostenintensiver.
- Aktivieren Sie CMEK für Dienste (BigQuery, GCS, Pub/Sub, Cloud SQL usw.), wenn dies aus Compliance-Gründen erforderlich ist. Bewahren Sie KMS-Schlüssel in derselben Region wie die Daten auf.
- Beispiel-CLI:
  - Verschlüsseln: gcloud kms encrypt –location=global –keyring=app-kr –key=data-key –plaintext-file=note.txt –ciphertext-file=note.txt.enc
  - Entschlüsseln: gcloud kms decrypt –location=global –keyring=app-kr –key=data-key –ciphertext-file=note.txt.enc –plaintext-file=note.txt
- Verwenden Sie sorgfältig geprüfte Krypto-Bibliotheken (z. B. Tink), um Implementierungsfehler zu vermeiden.
- Fehlermodi
  - Inkompatible Standorte verhindern die Verwendung von CMEK. Eine KMS-Entschlüsselung pro Anfrage erhöht die Latenz; cachen Sie DEKs im Arbeitsspeicher und berücksichtigen Sie dabei die Schlüsselrotation. Fehlende roles/cloudkms.cryptoKeyEncrypterDecrypter-Berechtigungen führen zu 403-Fehlern.

Autorisierung, APIs und Perimetersicherheit

Anwendungsautorisierung
- Rollenbasierte Prüfungen: einfach, schnell, aber grob. Attributbasierte Zugriffskontrolle (ABAC) verwendet Benutzerattribute, Ressourcenattribute und Kontext (Zeit, Gerätestatus) für feingranulare Entscheidungen.
- Zentralisieren Sie die Richtlinienauswertung oder verwenden Sie einen Sidecar/OPA; propagieren Sie Identitäts- und Mandanten-Claims konsistent durch Microservices.
- Mandantenfähigkeitsmuster (Multi-Tenancy)
  - Betten Sie die tenant_id in Authentifizierungs-Token ein und erzwingen Sie sie in jedem Datenzugriffspfad; verwenden Sie Row-Level-Filtering oder separate Datensätze pro Mandant für eine strikte Isolation.
  - Ziehen Sie mandantenspezifische Service Accounts oder KMS-Schlüssel in Betracht, wenn eine regulatorische Isolation erforderlich ist.
- Fehlermodi
  - Unsichere direkte Objektreferenzen (IDOR) aufgrund fehlender Mandantenprüfungen. Abweichende Autorisierungslogik zwischen den Diensten, die zu einer inkonsistenten Durchsetzung führt.
Sicheres API-Design
- Validieren und normalisieren Sie alle Eingaben; weisen Sie übergroße Payloads zurück. Erzwingen Sie strikte Content-Types. Führen Sie ein Threat-Modeling für Datei-Uploads durch; verwenden Sie signierte URLs für große Objekte.
- Ratenbegrenzung und Kontingente: Verwenden Sie Cloud Armor Ratenbegrenzung oder Apigee, um Missbrauch und 429-Fehler zu mitigieren. Implementieren Sie exponentielles Backoff mit Jitter auf den Clients.
- CORS
  - Geben Sie minimale Access-Control-Allow-*-Header zurück; vermeiden Sie Wildcard-Origins bei Anfragen mit Anmeldeinformationen. Preflight-Caching reduziert die Latenz.
- CSRF-Abwehrmaßnahmen
  - Bevorzugen Sie zustandslose APIs mit Bearer-Token in Authorization-Headern. Bei Cookie-basierten Sitzungen verwenden Sie SameSite=strict oder lax, sichere Cookies und ein CSRF-Token (Double-Submit oder Synchronizer).
- Beispiel (Cloud Armor Regel):
  - gcloud compute security-policies rules create 1000 –security-policy web-policy –expression “request.path.matches(’/api/’)” –action rate_based_ban –rate-limit-threshold-count 100 –rate-limit-threshold-interval-sec 60
- Fehlermodi
  - Naive IP-basierte Begrenzung kann mit IPv6 oder Proxys umgangen werden. Übermäßig freizügiges CORS ermöglicht das Abfließen von Tokens. Fehlende CSRF-Token bei Cookies ermöglichen Session Riding.
Netzwerksteuerungen und Datenperimeter
- Verwenden Sie hierarchische Firewall-Richtlinien und VPC-Firewallregeln; erlauben Sie die Zustandsprüfungen (Health Checks) der Google Front Ends, wenn diese sich hinter einem HTTP(S) Load Balancing befinden.
- Beispiel:
  - gcloud compute firewall-rules create allow-lb –network prod –allow tcp:80,tcp:443 –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
- Cloud Armor bietet WAF, Bot-Abwehr und Geo-/IP-Einschränkungen; passen Sie Regeln an und überprüfen Sie False Positives.
- Private Service Access bietet private IP-Konnektivität zu von Google verwalteten Diensten (z. B. Cloud SQL, Memorystore); vermeiden Sie öffentlichen Egress und IP-Allow-Listen.
- VPC Service Controls reduzieren das Risiko der Datenexfiltration durch die Erstellung von Perimetern um unterstützte Dienste; kombinieren Sie sie mit dem Access Context Manager für Geräte-/Standortkontext.
- Fehlermodi
  - Fehlkonfigurierte Perimeter blockieren CI/CD oder unterbrechen Service-zu-Service-Aufrufe. Fehlende PSA-Zuweisungen verhindern die Anbindung privater IPs. Übermäßig strenge WAF-Regeln können zu Verfügbarkeitsvorfällen führen.

Supply-Chain-Sicherheit, Protokollierung und Reaktion

Software-Supply-Chain-Sicherheit
- Speichern Sie Artefakte in Artifact Registry; erzwingen Sie Schwachstellenscans. Lassen Sie Builds bei hohen/kritischen CVEs fehlschlagen, wobei Ausnahmen von der Richtlinie nachverfolgt werden.
- Pinnen Sie Abhängigkeiten und Basis-Images; vermeiden Sie „latest“. Generieren und verifizieren Sie SBOMs. Verwenden Sie Binary Authorization, um signierte Images vor dem Deployment vorauszusetzen.
- Signieren Sie Images mit Cosign und zeichnen Sie die Herkunft (Provenance) auf; übernehmen Sie SLSA-konforme Build-Praktiken. Verwenden Sie Workload Identity Federation für die CI, um JSON-Schlüssel zu eliminieren.
- Fehlermodi
  - Nicht gepinnte Abhängigkeiten ziehen anfällige Versionen nach. Das Überspringen der Herkunftsprüfung ermöglicht die Manipulation von Images. Das Speichern von Registry-Anmeldedaten oder Service-Account-Schlüsseln in CI-Logs legt Geheimnisse offen.
Sicherheitsprotokollierung und -überwachung
- Aktivieren Sie Admin Activity und Data Access Audit Logs für kritische Projekte und Dienste. Leiten Sie Logs an ein dediziertes Projekt mit eingeschränktem Zugriff weiter.
- Erstellen Sie Cloud Logging-Metriken für Authentifizierungsfehler, Berechtigungsverweigerungen und Fehler bei der Richtlinienauswertung; alarmieren Sie über Cloud Monitoring.
- Beispiel (Idee für eine benutzerdefinierte Zählmetrik): Zählen Sie die Raten von 401/403-Fehlern auf /api/* und alarmieren Sie bei Abweichungen von der Baseline.
- Bedrohungs-Triage und -Behebung
  - Verwenden Sie Security Command Center, um Ergebnisse (Findings) zu aggregieren; erstellen Sie Playbooks für Schlüsselszenarien (Offenlegung von Schlüsseln, Brute-Force-Angriffe, anomale IAM-Änderungen).
  - Automatisieren Sie gängige Behebungsmaßnahmen (Tokens widerrufen, Schlüssel deaktivieren, Geheimnisse rotieren, Service Accounts unter Quarantäne stellen).
- Datenschutzbewusstes Design
  - Minimieren Sie personenbezogene Daten (PII); tokenisieren Sie, wo immer möglich. Schwärzen Sie sensible Werte aus Logs; verwenden Sie Cloud DLP zur Klassifizierung. Wenden Sie Richtlinien für minimale Aufbewahrungsdauer und regionale Speicherung an.
- Fehlermodi
  - Das Deaktivieren von Data Access Logs verhindert die Erkennung von Datenexfiltration. Labels mit hoher Kardinalität führen zu Kostenexplosionen. Das Protokollieren von Geheimnissen schafft eine dauerhafte Gefährdung.

Praktisches Problemszenario

Acme Retail erstellt ein mandantenfähiges Analyseportal auf Cloud Run mit einem React-Frontend, einer Python-API und BigQuery-Datasets pro Mandant. Die Anforderungen umfassen SSO für Mitarbeiter und Kunden, Mandantenisolierung, Verwaltung von Geheimnissen und Schlüsseln, privaten Datenbankzugriff, WAF und Ratenbegrenzung sowie eine starke CI/CD-Sicherheitsaufstellung ohne langlebige Schlüssel.

Ansatz:

Identitäten und Least Privilege etablieren

Erstellen Sie ein dediziertes Google Service Account pro Microservice (api-sa, ingest-sa). Weisen Sie Rollen mit den geringsten Rechten (Least Privilege) auf Projekt- oder Dataset-Ebene zu (z. B. roles/bigquery.dataEditor für Mandanten-Datasets).
Begründung: Pro-Service-SAs grenzen den Blast Radius ein und vereinfachen die Rotation; eng gefasste Rollen reduzieren laterale Bewegungen.

Workload Identity Federation für CI/CD verwenden

Konfigurieren Sie GitHub Actions OIDC, um die Identität von deployer-sa über roles/iam.workloadIdentityUser und roles/iam.serviceAccountTokenCreator anzunehmen (Impersonation). Stellen Sie mit den angenommenen Tokens auf Cloud Run bereit.
Begründung: Entfernt JSON-Schlüssel aus der CI; kurzlebige Anmeldedaten reduzieren das Diebstahlrisiko.

Frontend- und Benutzerauthentifizierung

Konfigurieren Sie IAP auf dem HTTPS Load Balancer vor den Cloud Run-Diensten. Integrieren Sie Google als IdP für Mitarbeiter und den Kunden-IdP über Föderation. Beschränken Sie den Zugriff mit der Rolle „IAP-secured Web App User“ auf autorisierte Gruppen.
Begründung: Zentralisierte Authentifizierung für Browser-Anwendungen; keine Authentifizierungslogik in den Diensten; SSO-Unterstützung.

IAP-Identität in der API validieren

Überprüfen Sie den x-goog-iap-jwt-assertion-Header in der API; erzwingen Sie das Vorhandensein eines tenant_id-Claims (zugeordnet aus einer Gruppe oder einem benutzerdefinierten Claim).
Begründung: Starke Identitätsgarantie durch IAP; das Einbetten des Mandantenkontexts in jede Anfrage stellt eine konsistente nachgelagerte Autorisierung sicher.

Mandantenfähige Autorisierung implementieren

Speichern Sie Richtlinien pro Mandant und ordnen Sie Benutzer Rollen zu (Viewer, Analyst, Admin). Prüfen Sie bei jeder Anfrage die Rolle und ABAC-Bedingungen (Übereinstimmung der tenant_id, Feature-Flags).
Begründung: Kombiniert die Einfachheit von RBAC mit der Flexibilität von ABAC; eliminiert IDOR durch Erzwingen des Mandanten-Scopings.

Geheimnisse und Datenbankzugriff

Speichern Sie DB-Passwörter und API-Token von Drittanbietern in Secret Manager; gewähren Sie die Rolle roles/secretmanager.secretAccessor nur dem API-SA. Greifen Sie beim Start auf Geheimnisse zu und aktualisieren Sie diese bei Rotationsbenachrichtigungen über Pub/Sub.
Begründung: Keine hartcodierten Anmeldedaten; überprüfbarer Zugriff; rechtzeitige Rotation ohne Neustarts.

Datenverschlüsselung und CMEK

Erstellen Sie einen Cloud KMS Keyring und Schlüssel pro Umgebung. Aktivieren Sie CMEK für BigQuery-Datasets und Cloud Storage-Buckets. Verwenden Sie Envelope-Verschlüsselung für alle in der Anwendung gespeicherten sensiblen Blobs.
Begründung: Vom Kunden verwaltete Schlüssel (Customer-Managed Keys) erfüllen Compliance-Anforderungen und ermöglichen eine Funktionstrennung.

Private Konnektivität und Service-Perimeter

Verwenden Sie Private Service Access für die private IP von Cloud SQL. Erstellen Sie einen VPC Service Controls-Perimeter für das Projekt, das BigQuery und GCS hostet; fügen Sie Access Context-Richtlinien für den Zugriff durch Unternehmensadministratoren hinzu.
Begründung: Eliminiert öffentliche Egress-Pfade; reduziert das Risiko der Datenexfiltration.

API-Sicherheit, Ratenbegrenzung, CORS und CSRF

Wenden Sie eine Cloud Armor-Sicherheitsrichtlinie mit verwalteten WAF-Regeln und Ratenbegrenzung auf den externen HTTP(S)-LB an; passen Sie Allow-Listen für Partner-IPs an. Konfigurieren Sie striktes CORS (explizite Origins) für die API und verwenden Sie Authorization Bearer-Token; Cookies werden nicht genutzt.
Begründung: Mindert OWASP Top 10-Risiken und Missbrauch; verhindert das Abfließen von Anmeldedaten über verschiedene Ursprünge (Cross-Origin); vermeidet CSRF durch den Verzicht auf Cookies.

Härtung der Lieferkette (Supply Chain)

Speichern Sie Images in Artifact Registry. Aktivieren Sie Schwachstellenscans und lassen Sie Builds bei kritischen CVEs fehlschlagen. Signieren Sie Images mit Cosign und erzwingen Sie Binary Authorization, um Acme-Signaturen in der Produktion vorauszusetzen.
Begründung: Verhindert die Ausführung ungeprüfter Artefakte; bewahrt die Herkunft (Provenance).

Protokollierung, Überwachung und Alarme

Aktivieren Sie Audit Logs und leiten Sie diese an ein zentralisiertes Projekt weiter. Erstellen Sie log-basierte Metriken für Spitzen bei 401/403-Fehlern, permissionDenied von BigQuery und Zugriffen auf Secret Manager. Alarmieren Sie bei Anomalien und richten Sie Cloud Monitoring Uptime-Checks für die öffentlichen Endpunkte ein.
Begründung: Früherkennung von Authentifizierungsfehlern und Missbrauch; Verfügbarkeitsüberwachung.

Incident-Playbooks und Rotationsübungen

Dokumentieren Sie die Schritte zum Widerrufen kompromittierter SAs (Deaktivieren, Schlüssel rotieren, Tokens ungültig machen), zum Rotieren von Geheimnissen und zur Neuverschlüsselung mit neuen KMS-Versionen. Testen Sie dies vierteljährlich.
Begründung: Eine vorbereitete, wiederholbare Reaktion minimiert Ausfallzeiten und die Gefährdung von Daten.

Dieses Design gewährleistet kurzlebige, verifizierbare Identitäten bei jedem Schritt, eine konsistente mandantenfähige Autorisierung, geschützte Geheimnisse und Schlüssel, private Datenpfade und eine gehärtete Lieferkette, ergänzt durch Beobachtbarkeits- und Reaktions-Workflows, die das System widerstandsfähig gegenüber Angriffen und im Routinebetrieb halten.

← Anwendungsdaten · Alle Domänen · Continuous Delivery →

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