Google PCD: Identiteit, authenticatie en applicatiebeveiliging — Studiegids

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

Onderdeel van de Google Professional Cloud Developer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Identiteit is de nieuwe perimeter op Google Cloud. Applicaties moeten principals (gebruikers, services) authenticeren en autoriseren voor toegang met minimale rechten (least-privilege) tot data en API’s, terwijl secrets, sleutels en de software supply chain beschermd worden. Dit gedeelte beschrijft end-to-end ontwerp- en operationele praktijken die Google Cloud IAM, moderne authenticatieprotocollen, netwerk- en API-verdediging, encryptie, logging en responsprocessen combineren. De nadruk ligt op kortlevende credentials, gecentraliseerd beleid en gelaagde controles die veilig falen (‘fail safely’).

Identiteiten, Authenticatie en Toegangscontrole

IAM-rollen en service accounts
- Gebruik de resourcehiërarchie (organisatie > map > project) en vooraf gedefinieerde rollen in plaats van primitieve rollen. Geef alleen de voorkeur aan aangepaste rollen wanneer vooraf gedefinieerde rollen te breed zijn.
- Wijs service accounts (SA’s) toe aan workloads. Hergebruik niet de standaard Compute Engine of App Engine SA’s. Eén SA per workload-grens vereenvoudigt het principe van minimale rechten en de rotatie van vertrouwen.
- Dwing minimale rechten af door de minimale set permissies toe te kennen op de kleinst mogelijke resource-scope.
- Impersonatie: Geef de voorkeur aan kortlevende credentials via de Service Account Token Creator om mensen, CI/CD of andere services tijdelijke toegang te geven zonder sleutels op te slaan:
  - Ken de rol roles/iam.serviceAccountTokenCreator op de doel-SA toe aan de aanroepende identiteit.
  - Voorbeeld:

undefined

Workload Identity
- GKE: Gebruik Workload Identity om Kubernetes service accounts te binden aan Google service accounts; tokens worden automatisch geprojecteerd en uitgewisseld—geen JSON-sleutels.
- Externe workloads: Gebruik Workload Identity Federation om OIDC/SAML-credentials (bijvoorbeeld van GitHub Actions of on-prem) uit te wisselen voor Google-toegangstokens zonder langlevende sleutels op te slaan.
Faalmodi en afwegingen
- Te brede rollen of toekenningen met een te ruime scope leiden tot laterale beweging. Ontbrekende Token Creator-rechten blokkeren impersonatie-flows. JSON-sleutelbestanden vergroten de ‘blast radius’ van een datalek.
Gebruikersauthenticatie met OAuth 2.0, OpenID Connect en Google Identity
- Gebruik voor authenticatie van eindgebruikers OIDC met Google als IdP of een bedrijfs-IdP; valideer ID-tokens server-side. Gebruik voor API-toegang OAuth 2.0-toegangstokens met de juiste scopes.
- Valideer tokens: verifieer iss, aud, exp, iat en de handtekening met behulp van de JWK’s van de IdP; cache JWK’s en dwing sleutelrotatie af.
- Geef voor backends van mobiele apps/SPA’s de voorkeur aan de Authorization Code flow met PKCE. Vermijd impliciete flows.
- Gebruik voor service-naar-servicecommunicatie de OAuth 2.0 Service Account JWT-flow of mTLS; vermijd statische API-sleutels.
- Voorbeeld (token-impersonatie met gcloud):

undefined

Faalmodi
- Het niet valideren van aud/iss maakt ’token confusion’-aanvallen mogelijk. Het accepteren van verlopen tokens, of het niet roteren van JWK’s, verhoogt het risico. Het gebruik van refresh tokens in mobiele apps stelt langlevende credentials bloot.
Identity-Aware Proxy (IAP) voor browsertoegang
- Gebruik IAP om HTTP-applicaties op Cloud Run, GKE of Compute Engine te beveiligen zonder authenticatielogica in te bouwen. Dwing de rol “IAP-secured Web App User” af voor toegang.
- Applicaties ontvangen een ondertekende header (x-goog-iap-jwt-assertion). Verifieer de JWT om de identiteit en het e-mailadres van de gebruiker te vertrouwen; vertrouw niet op X-Forwarded-* voor authenticatie.
- Veelvoorkomende valkuilen: bypass-paden die niet via IAP worden gerouteerd, een verkeerd geconfigureerde backend-firewall, of het vertrouwen op client-IP-headers zonder de integriteit van Cloud Load Balancing.

Secrets, Sleutels en Encryptie

Secret Manager
- Sla API-sleutels, DB-wachtwoorden en webhook-secrets op in Secret Manager. Vertrouw op versiebeheer, IAM-controles en auditlogs.
- Toegangspatronen
  - Haal op bij het opstarten en cache in het geheugen; ververs bij signalen van secret-wijzigingen (Pub/Sub-notificaties).
  - Vermijd het ‘inbakken’ van secrets in images of omgevingsvariabelen. Als omgevingsvariabelen worden gebruikt, zorg er dan voor dat ze nooit worden gelogd of in crashrapporten terechtkomen.
- Rotatie
  - Automatiseer met Cloud Scheduler + Cloud Functions/Run om nieuwe versies aan te maken, afhankelijke systemen bij te werken en oude versies te markeren als verouderd (‘deprecate’).
  - Voorbeeld:

undefined

Faalmodi
- Buitensporige Secret Manager-aanroepen per request voegen latency toe en riskeren het uitputten van quota’s. Ontbrekende roles/secretAccessor-rechten veroorzaken runtime 403-fouten.
Cloud KMS en applicatie-encryptie
- Gebruik envelope-encryptie: een lokaal gegenereerde data encryption key (DEK) versleutelt data; een door de klant beheerde sleutel (CMEK) in Cloud KMS versleutelt de DEK (KEK).
- Roteer sleutels regelmatig; plan voor her-encryptie. Geef de voorkeur aan ‘oud ontsleutelen, nieuw versleutelen’ bij schrijfacties; bulk her-encryptiejobs voor data-at-rest zijn duurder.
- Activeer CMEK voor services (BigQuery, GCS, Pub/Sub, Cloud SQL, etc.) wanneer dit vereist is door compliance. Bewaar KMS-sleutels in dezelfde regio als de data.
- Voorbeeld CLI:
  - Versleutelen:

undefined

- Ontsleutelen:

undefined

Gebruik goed doorgelichte cryptobibliotheken (bijvoorbeeld Tink) om implementatiefouten te voorkomen.
Faalmodi
- Locatie-mismatches verhinderen het gebruik van CMEK. Per-request KMS-ontsleuteling voegt latency toe; cache DEK’s in het geheugen met bewustzijn van rotatie. Ontbrekende roles/cloudkms.cryptoKeyEncrypterDecrypter-rechten leiden tot 403-fouten.

Autorisatie, API’s en Perimeterbeveiliging

Applicatieautorisatie
- Rolgebaseerde controles: eenvoudig, snel, maar grofmazig. Attribute-based access control (ABAC) gebruikt gebruikersattributen, resource-attributen en context (tijd, apparaatstatus) voor fijnmazige beslissingen.
- Centraliseer de evaluatie van beleid of gebruik een sidecar/OPA; propageer identiteits- en tenant-claims consistent door microservices.
- Multi-tenancy patronen
  - Neem tenant_id op in auth-tokens en dwing dit af in elk pad voor gegevenstoegang; gebruik filtering op rijniveau of aparte datasets per tenant voor strikte isolatie.
  - Overweeg per-tenant serviceaccounts of KMS-sleutels als isolatie vanwege regelgeving vereist is.
- Faalscenario’s
  - Onveilige directe objectreferenties (IDOR) door ontbrekende tenant-controles. Uiteenlopende autorisatielogica tussen services die inconsistente handhaving veroorzaakt.
Veilig API-ontwerp
- Valideer en normaliseer alle invoer; weiger te grote payloads. Dwing sterke content-types af. Maak een threat model voor het uploaden van bestanden; gebruik signed URL’s voor grote objecten.
- Rate limiting en quota’s: gebruik Cloud Armor rate limiting of Apigee om misbruik en 429-fouten te beperken. Implementeer exponential backoff met jitter aan de clientzijde.
- CORS
  - Retourneer minimale Access-Control-Allow-*; vermijd wildcard-origins bij requests met credentials. Preflight-caching vermindert de latentie.
- CSRF-verdediging
  - Geef de voorkeur aan stateless API’s met bearer tokens in Authorization-headers. Gebruik voor op cookies gebaseerde sessies SameSite=strict of lax, secure cookies en een CSRF-token (double-submit of synchronizer).
- Voorbeeld (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
- Faalscenario’s
  - Naïeve IP-gebaseerde limiting kan worden omzeild met IPv6 of proxy’s. Te permissieve CORS maakt het lekken van tokens mogelijk. Ontbrekende CSRF-tokens bij cookies maken session riding mogelijk.
Netwerkcontroles en dataperimeter
- Gebruik hiërarchisch firewallbeleid en VPC-firewallregels; sta health checks van Google Front Ends toe wanneer deze zich achter HTTP(S) Load Balancing bevinden.
- Voorbeeld:
  - 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 biedt WAF, bot-verdediging en geo/IP-restricties; stem regels af en controleer op false positives.
- Private service access biedt private IP-connectiviteit met door Google beheerde services (bijvoorbeeld Cloud SQL, Memorystore); vermijd publieke egress en IP-allowlists.
- VPC Service Controls verminderen het risico op data-exfiltratie door perimeters te creëren rond ondersteunde services; combineer met Access Context Manager voor apparaat-/locatiecontext.
- Faalscenario’s
  - Verkeerd geconfigureerde perimeters blokkeren CI/CD of verbreken service-naar-service calls. Ontbrekende PSA-allocaties verhinderen de koppeling van private IP’s. Te strikte WAF-regels kunnen beschikbaarheidsincidenten veroorzaken.

Beveiliging van de Toeleveringsketen, Logging en Respons

Beveiliging van de softwaretoeleveringsketen
- Sla artefacten op in Artifact Registry; dwing kwetsbaarheidsscans af. Laat builds mislukken bij hoge/kritieke CVE’s, met bijgehouden uitzonderingen op het beleid.
- Pin afhankelijkheden en basis-images; vermijd “latest”. Genereer en verifieer SBOM’s. Gebruik Binary Authorization om ondertekende images te vereisen vóór de implementatie.
- Onderteken images met Cosign en leg de herkomst vast; pas SLSA-conforme build-praktijken toe. Gebruik Workload Identity Federation voor CI om JSON-sleutels te elimineren.
- Faalscenario’s
  - Niet-gepinde afhankelijkheden halen kwetsbare releases binnen. Het overslaan van herkomstregistratie maakt het mogelijk om met images te knoeien. Het opslaan van registry-credentials of serviceaccount-sleutels in CI-logs lekt geheimen.
Beveiligingslogging en -monitoring
- Schakel Admin Activity en Data Access Audit Logs in voor kritieke projecten en services. Stuur logs door naar een speciaal project met beperkte toegang.
- Maak Cloud Logging-metrics aan voor authenticatiefouten, geweigerde permissies en fouten bij beleidsevaluatie; alarmeer via Cloud Monitoring.
- Voorbeeld (idee voor een aangepaste counter-metric): Tel het aantal 401/403-fouten op /api/* en alarmeer bij afwijkingen van de baseline.
- Dreigingstriage en -herstel
  - Gebruik Security Command Center om bevindingen te verzamelen; maak draaiboeken voor belangrijke scenario’s (gelekte sleutels, brute force, afwijkende IAM-wijzigingen).
  - Automatiseer veelvoorkomende herstelacties (tokens intrekken, sleutels uitschakelen, geheimen roteren, serviceaccounts in quarantaine plaatsen).
- Privacybewust ontwerp
  - Minimaliseer PII (persoonlijk identificeerbare informatie); tokeniseer waar mogelijk. Redigeer gevoelige waarden uit logs; gebruik Cloud DLP voor classificatie. Pas beleid toe voor minimale retentie en regionale opslag.
- Faalscenario’s
  - Het uitschakelen van Data Access-logs maakt detectie van data-exfiltratie onmogelijk. Labels met een hoge kardinaliteit laten de kosten exploderen. Het loggen van geheimen creëert een duurzame blootstelling.

Praktisch Probleemscenario

Acme Retail bouwt een multi-tenant analyseportaal op Cloud Run met een React-frontend, een Python-API en BigQuery-datasets per tenant. De vereisten omvatten SSO voor medewerkers en klanten, tenant-isolatie, beheer van geheimen en sleutels, private databasetoegang, WAF en rate limiting, en een sterke CI/CD-aanpak zonder langlevende sleutels.

Aanpak:

Identiteiten en ’least privilege’ vaststellen

Maak een specifieke Google-serviceaccount per microservice (api-sa, ingest-sa). Ken ’least-privilege’-rollen toe op project- of datasetniveau (bijvoorbeeld roles/bigquery.dataEditor op tenant-datasets).
Reden: Serviceaccounts per service beperken de ‘blast radius’ en vereenvoudigen rotatie; rollen met een beperkte scope verminderen laterale beweging.

Workload Identity Federation gebruiken voor CI/CD

Configureer GitHub Actions OIDC om deployer-sa te imiteren via roles/iam.workloadIdentityUser en roles/iam.serviceAccountTokenCreator. Implementeer naar Cloud Run met geïmiteerde tokens.
Reden: Verwijdert JSON-sleutels uit CI; kortlevende credentials verminderen het risico op diefstal.

Frontend en gebruikersauthenticatie

Configureer IAP op de HTTPS Load Balancer voor de Cloud Run-services. Integreer Google als IdP voor medewerkers en de IdP van de klant via federatie. Beperk de toegang met de rol “IAP-secured Web App User” tot geautoriseerde groepen.
Reden: Gecentraliseerde authenticatie voor browser-apps; geen authenticatielogica in de services; ondersteuning voor SSO.

IAP-identiteit valideren in de API

Verifieer de x-goog-iap-jwt-assertion-header in de API; dwing de aanwezigheid van een tenant_id-claim af (gemapt vanuit een groep of een aangepaste claim).
Reden: Sterke identiteitsgarantie van IAP; het inbedden van tenant-context in elk verzoek zorgt voor consistente autorisatie verderop in de keten.

Tenant-bewuste autorisatie implementeren

Sla beleidsregels per tenant op en map gebruikers aan rollen (viewer, analyst, admin). Controleer bij elk verzoek de rol en ABAC-voorwaarden (tenant_id-match, feature flags).
Reden: Combineert de eenvoud van RBAC met de flexibiliteit van ABAC; elimineert IDOR door tenant-scoping af te dwingen.

Geheimen en databasetoegang

Sla DB-wachtwoorden en API-tokens van derden op in Secret Manager; ken de rol roles/secretmanager.secretAccessor alleen toe aan de API SA. Benader geheimen bij het opstarten en ververs ze bij rotatienotificaties via Pub/Sub.
Reden: Geen hardgecodeerde credentials; auditeerbare toegang; tijdige rotatie zonder herstarts.

Data-encryptie en CMEK

Maak een Cloud KMS-keyring en sleutels per omgeving. Schakel CMEK in op BigQuery-datasets en Cloud Storage-buckets. Gebruik ’envelope encryption’ voor alle gevoelige blobs die in de applicatie worden opgeslagen.
Reden: Door de klant beheerde sleutels voldoen aan compliance-eisen en bieden scheiding van taken.

Private connectiviteit en service-perimeter

Gebruik ‘private service access’ voor een privaat IP-adres van Cloud SQL. Maak een VPC Service Controls-perimeter voor het project dat BigQuery en GCS host; voeg Access Context-beleid toe voor toegang door bedrijfsbeheerders.
Reden: Elimineert publieke uitgaande paden; vermindert het risico op data-exfiltratie.

API-beveiliging, rate limiting, CORS en CSRF

Pas een Cloud Armor-beveiligingsbeleid toe met beheerde WAF-regels en rate limiting op de externe HTTP(S) LB; stem allowlists af op IP-adressen van partners. Configureer strikte CORS (expliciete origins) voor de API en gebruik ‘Authorization bearer tokens’; cookies worden niet gebruikt.
Reden: Vermindert risico’s van de OWASP Top 10 en misbruik; voorkomt het lekken van credentials tussen verschillende origins; vermijdt CSRF door geen cookies te gebruiken.

Versterking van de toeleveringsketen

Sla images op in Artifact Registry. Schakel kwetsbaarheidsscans in en laat builds mislukken bij kritieke CVE’s. Onderteken images met Cosign en dwing Binary Authorization af om Acme-handtekeningen te vereisen in productie.
Reden: Voorkomt dat niet-geverifieerde artefacten worden uitgevoerd; behoudt de herkomst.

Logging, monitoring en alarmering

Schakel Audit Logs in en stuur ze door naar een gecentraliseerd project. Maak op logs gebaseerde metrics voor pieken in 401/403-fouten, ‘permissionDenied’ vanuit BigQuery en toegang tot Secret Manager. Alarmeer bij afwijkingen en stel Cloud Monitoring uptime-checks in voor de publieke endpoints.
Reden: Vroegtijdige detectie van authenticatiefouten en misbruik; monitoring van de beschikbaarheid.

Incident-draaiboeken en rotatie-oefeningen

Documenteer de stappen om gecompromitteerde SA’s in te trekken (uitschakelen, sleutels roteren, tokens ongeldig maken), geheimen te roteren en opnieuw te versleutelen met nieuwe KMS-versies. Test dit per kwartaal.
Reden: Een voorbereide, herhaalbare respons minimaliseert downtime en blootstelling van data.

Dit ontwerp zorgt voor kortlevende, verifieerbare identiteiten bij elke stap, consistente tenant-bewuste autorisatie, beschermde geheimen en sleutels, private datapaden en een versterkte toeleveringsketen, met observeerbaarheids- en responsworkflows die het systeem veerkrachtig houden onder aanval en tijdens routineoperaties.

← Applicatiedata · Alle domeinen · Continuous Delivery →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →