Google PCA: Beveiliging, Compliance en Gegevensbeschermingsarchitectuur — Studiegids

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

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

Overzicht

Beveiliging, compliance en gegevensbescherming in Google Cloud zijn gebouwd op gedeelde verantwoordelijkheid en ‘defense in depth’. Google beveiligt de onderliggende infrastructuur, terwijl jij veilige identiteiten, netwerken, applicaties en gegevensverwerking ontwerpt. Hanteer Zero Trust als leidend model: vertrouw het netwerk nooit impliciet, verifieer continu de identiteit en context, en dwing ’least privilege’ strikt af. Ontwerp met het oog op compromittering: ga ervan uit dat inloggegevens kunnen lekken, endpoints kunnen worden onderzocht en interne services kunnen worden misbruikt. Compenseer met meerdere controles (preventief, detectief, responsief), sterke cryptografie en sleutelbeheer, robuuste monitoring en geoefende incidentrespons.

Afwegingen zijn onvermijdelijk. Sterkere controles kunnen de latentie, operationele complexiteit en kosten verhogen. Je architectuur moet expliciet de risico’s afwegen tegen bruikbaarheid en prestaties, met behoud van aantoonbare compliance en gereedheid voor forensisch onderzoek.

Identiteits- en Toegangsarchitectuur

• Principes en model

  • Standaard ’least privilege’: ken de kleinst mogelijke set permissies toe die nodig is om een taak uit te voeren, en geef de voorkeur aan vooraf gedefinieerde rollen of aangepaste rollen boven primitieve rollen (Owner, Editor, Viewer).
  • Scheiding van taken: verdeel rollen over ‘builders’ (CI/CD), ‘deployers’, ‘operators’ en beveiliging. Gebruik ‘break-glass’-accounts met sterke controles en logging voor noodgevallen.
  • Handhaving van Zero Trust: gebruik contextbewuste toegang om gebruiker, apparaat, locatie en risico te verifiëren; vereis sterke MFA; en evalueer continu de sessiecontext.
  • Organization Policy en IAM Deny: leg ‘guardrails’ vast in code (bijvoorbeeld het verbieden van het aanmaken van serviceaccount-sleutels, het beperken van het delen van domeinen) en gebruik ‘deny policies’ om niet-onderhandelbare grenzen af te dwingen.

• IAM-implementatie en serviceaccountstrategie

  • Stel een hiërarchie-gestuurd toegangsmodel op: mappen weerspiegelen bedrijfsonderdelen of omgevingen (prod, non-prod); projecten isoleren de ‘blast radius’ en facturering; serviceaccounts (SA’s) vertegenwoordigen workloads.
  • Eén workload, één serviceaccount: vermijd het delen van SA’s tussen ongerelateerde services. Koppel permissies aan de deployment-scope (project) en resource-scope.
  • Geef de voorkeur aan kortlevende credentials via Service Account Impersonation en Workload Identity Federation. Schakel door de gebruiker beheerde serviceaccount-sleutels uit; als dit onvermijdelijk is, isoleer het gebruik, roteer ze frequent en monitor met auditlogs.
  • Gebruik Access Boundaries om te beperken waartoe een geïmpersoneerde SA toegang heeft op het moment van de aanvraag (bijvoorbeeld, beperk GCS-objectpaden), waardoor de ‘blast radius’ wordt beperkt, zelfs als een geprivilegieerde SA wordt misbruikt.
  • Conditional IAM: pas voorwaarden op resourceniveau toe (tijd, IP, principal-attributen) om de toegang te beperken. Voorbeeld: sta productietoegang niet toe, behalve vanaf IP-reeksen van het bedrijf en tijdens ‘change windows’.

• Faalmodi en afwegingen

  • Rollen met te veel rechten (bijv. Editor op projectniveau) verhogen het risico; geef de voorkeur aan granulaire rollen en valideer via ‘policy analyzers’.
  • Wildgroei van serviceaccount-sleutels in CI/CD en lokale scripts is een veelvoorkomende aanvalsvector; met ‘impersonation’ moeten sommige legacy tools mogelijk worden aangepast.
  • IAM Deny-policies zijn krachtig maar kunnen moeilijk te troubleshooten zijn; faseer en test wijzigingen in een niet-productieomgeving met expliciete ‘dry runs’.

Voorbeeld (impersonation zonder sleutels aan te maken):

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

Gegevensbescherming en Cryptografie

• Cloud KMS en modellen voor sleutelbeheer
  • Standaard wordt versleuteling-at-rest (’native encryption’) toegepast. Gebruik voor extra controle Customer-Managed Encryption Keys (CMEK) met services zoals BigQuery, Cloud Storage, Compute Engine-disks, Pub/Sub en GKE persistent volumes.
  • Ontwerp een sleutelhiërarchie per omgeving en datadomein. Gebruik aparte keyrings per locatie en aparte sleutels per applicatie of dataset om de ‘blast radius’ te beperken.
  • Rotatie: schakel geplande rotatie in en faseer oudere sleutelversies geleidelijk uit met ’envelope-versleuteling’ voor applicaties. Valideer de compatibiliteit van de consumenten voordat de rotatiefrequentie wordt verhoogd.
  • External Key Manager (EKM) en External Key Access (EKA) plaatsen sleutels buiten Google Cloud voor controle vanuit regelgeving. De nadelen zijn extra latency en afhankelijkheid van de beschikbaarheid van externe HSM’s; maak een plan voor operaties in een ‘degraded mode’.
  • Dwing het ’least privilege’-principe van IAM af op CryptoKeys. Gebruik auditlogs op sleutelniveau als bewijs voor toegang.

Voorbeeld (CMEK met rotatie):

undefined

undefined

• Versleuteling op applicatieniveau

  • Gebruik ’envelope-versleuteling’ (bijvoorbeeld met Tink) om gevoelige velden op de applicatielaag te versleutelen, wat selectieve toegang en isolatie van tenant-data mogelijk maakt. Leid per-tenant sleutels af om de impact tussen tenants te minimaliseren.
  • Valideer de integriteit (AEAD) om manipulatie (’tampering’) en ‘replay’-aanvallen te voorkomen.

• Secret Manager en de levenscyclus van secrets

  • Sla credentials, tokens en API-sleutels op als geversioneerde secrets; nooit in images, Git of instance metadata. Ken IAM-rechten toe op secret- of projectniveau aan het runtime serviceaccount.
  • Rotatie: automatiseer met door Pub/Sub getriggerde Cloud Functions/Cloud Run om een nieuwe versie te maken, afhankelijke systemen bij te werken en oude versies in te trekken. Geef de voorkeur aan het vervangen van langlevende databasewachtwoorden door IAM-gebaseerde database-authenticatie of kortlevende tokens.
  • Configuratiebeveiliging: scheid niet-geheime configuratie (ConfigMap, omgevingsvariabelen) van secrets. Voorkom dat secrets zichtbaar worden in logs en foutmeldingen.

Voorbeeld (nieuwe secret-versie toevoegen):

undefined

• Verharding van compute en confidential computing
  • Shielded VM’s: schakel secure boot, vTPM en integriteitsmonitoring in om te beschermen tegen bootkits en rootkits. Dwing dit af via een organization policy en valideer in CI/CD-pipelines.
  • Confidential VM’s: geheugenversleuteling beschermt standaard data-in-use met minimale configuratiewijzigingen; evalueer de prestatie-impact voor workloads met hoge doorvoer en veel cryptografische operaties.
  • Verharde images: start vanaf door Google geoptimaliseerde of CIS-verharde basisimages; beheer patches met OS Config en schakel onnodige packages en poorten uit.

Netwerk- en Edge-beveiliging

• Netwerksegmentatie en egress-controle

  • Segmenteer per tier en gevoeligheid met behulp van aparte VPC’s, subnets en hiërarchische firewall-beleidsregels. Combineer identiteitsbewuste firewall-tags met service-naar-service beperkingen (bijvoorbeeld GKE NetworkPolicy) om east-west-controles af te dwingen.
  • Beheer egress met Cloud NAT, DNS-beleid en beperkte Private Google Access om data-exfiltratie te minimaliseren. Gebruik expliciete egress-allowlists en proxy-inspectie waar dit gerechtvaardigd is.

• VPC Service Controls (VPC SC)

  • Bouw serviceperimeters rond projecten die de betreffende data hosten om exfiltratie via door Google beheerde API’s (GCS, BigQuery, Secret Manager, Pub/Sub, etc.) te beperken.
  • Toegangsniveaus: definieer contextuele voorwaarden (gebruikersidentiteit, IP-ranges, ‘device posture’) waaraan moet worden voldaan om toegang te krijgen tot services binnen de perimeter.
  • Gebruik ‘perimeter-bruggen’ voor gecontroleerde multi-perimeter workflows en egress-regels om bestemmingen te beperken. Test met de dry-run-modus om te voorkomen dat pipelines breken.
  • Beperkingen: beschermt niet direct het verkeer naar Compute Engine IP’s; vul aan met firewall- en egress-controles. Sommige tools en hybride patronen vereisen mogelijk perimeter-bewuste serviceaccounts en Private Service Connect naar beperkte VIP’s.

• Edge- en applicatiebescherming

  • Cloud Armor: verdedig HTTP(S)-applicaties achter de global external load balancer met L3/L4/L7 DDoS-mitigatie, IP allow/deny-lijsten, geografisch gebaseerde controles en rate limiting.
  • WAF-regels: pas vooraf geconfigureerde, beheerde regels en aangepaste signatures toe voor de OWASP Top 10; stem deze af om ‘false positives’ te verminderen. Koppel per backend service om beleid op maat te maken per API-versie of applicatiecomponent.
  • API-bescherming: plaats API’s achter API Gateway of Apigee voor authenticatie, quota, schemavalidatie en dreigingsdetectie; integreer Cloud Armor voor handhaving aan de edge; overweeg waar nodig reCAPTCHA Enterprise en bot-controles.
  • Afwegingen: diepere inspectie kan latency en operationele ‘ruis’ toevoegen. Plaats regels eerst in de preview-modus, monitor de logs en voer ze progressief in.

Security Operations, Monitoring en Compliance

• Security Command Center (SCC) en threat detection

  • SCC aggregeert asset-inventaris en bevindingen over projecten en organisaties heen. Gebruik het om de uitgangspositie (posture) te bepalen (publieke buckets, open firewall-regels), afwijkingen (drift) te volgen en herstelworkflows aan te sturen.
  • Premium threat detection omvat Event Threat Detection, VM Threat Detection en Container Threat Detection om malware, cryptomining en afwijkend gedrag te identificeren.
  • Integreer bevindingen met ticketing- en SOAR-pipelines; definieer onderdrukkings-/uitzonderingsbeleid met een vervaldatum om alert-moeheid te voorkomen.

• Kwetsbaarheids- en artefactbeveiliging

  • Gebruik Artifact Analysis om container-images te scannen op CVE’s; dwing beleid af tijdens de implementatie (deploy-time) met Binary Authorization en ondertekende attesten (attestations) vanuit CI.
  • Patchbeheer via OS Config; monitor blootstellingsvensters (exposure windows) en automatiseer rollouts met canaries.

• Auditlogs, privacy en bewijsmateriaal

  • Cloud Audit Logs leveren standaard Admin Activity- en System Event-logs; Data Access-logs kunnen per service worden ingeschakeld en zijn tegen betaling. Routeer logs naar BigQuery voor analyses en naar Cloud Storage voor onveranderlijke retentie (immutable retention) en juridische bewaring (legal hold).
  • Dataclassificatie: gebruik Cloud DLP om PII te ontdekken en te classificeren, labels en tags toe te passen en te koppelen aan beschermingsniveaus (CMEK, VPC SC, Confidential VMs).
  • Privacy en dataresidentie: beperk locaties via organisatiebeleid; stem CMEK- en opslaglocaties af op wettelijke vereisten.
  • Juridische bewaring (legal holds) en retentie: schakel bucket-retentiebeleid en -holds in; gebruik Object Versioning waar nodig. Documenteer de chain of custody voor forensische images en logs om verdedigbaar bewijsmateriaal te produceren.

• Incidentrespons en forensische paraatheid

  • Bereid runbooks, toegangspaden en automatisering voor. Zorg ervoor dat responders toegang hebben met minimale rechten (least-privileged access) en dat auditing is ingeschakeld voor de organisatie, mappen en projecten.
  • Inperking (containment): isoleer instanties door ze uit load balancers te verwijderen, deny egress firewall-regels toe te passen of projecten te verplaatsen naar een strenger organisatiebeleid; schakel gecompromitteerde serviceaccounts uit en rouleer secrets en sleutels.
  • Forensisch onderzoek: maak snapshots van schijven en exporteer images voor offline analyse; bewaar logs via exports. Gebruik packet mirroring waar van toepassing. Vermijd het aanpassen van bewijsmateriaal; werk vanuit kopieën.
  • Herstel: herbouw vanaf vertrouwde images, hydrateer secrets opnieuw en valideer met smoke- en securitytests. Voer post-incident reviews uit en koppel de lessen terug naar guardrails en detectiesystemen.

Praktisch Probleemscenario

NimbusPay, een fintech SaaS, moet PCI-gelabelde data verwerken in multi-tenant microservices op Google Cloud, dataresidentie in de EU afdwingen, beschermen tegen aanvallen op de API-laag en auditeerbaar bewijs van controles produceren. Ze zullen een nieuwe v2 API uitrollen terwijl v1 live blijft onder dezelfde hostnaam.

Aanpak:

1. Projecten en identiteiten partitioneren

• Maak afzonderlijke projecten per omgeving en microservice-laag (ingest, processing, reporting). Wijs een uniek workload serviceaccount toe per service. Rationale: isoleert de blast radius en koppelt least privilege aan afzonderlijke workloads.

2. Zero Trust en least privilege afdwingen

• Wijs vooraf gedefinieerde/aangepaste rollen toe aan serviceaccounts en devops-groepen; pas conditionele IAM toe om productietoegang te beperken tot bedrijfs-IP’s en kantooruren. Rationale: vermindert laterale verplaatsing (lateral movement) en onbedoelde wijzigingen.

3. Statische serviceaccount-sleutels verwijderen

• Schakel door de gebruiker beheerde SA-sleutels uit via organisatiebeleid. Gebruik Service Account Impersonation voor CI/CD en operationele taken; pas Access Boundaries toe die GCS-paden per tenant beperken. Rationale: elimineert een veelvoorkomende vector voor het lekken van credentials en beperkt datatoegang, zelfs als tokens worden gestolen.

4. Data beschermen met CMEK en regionale controles

• Maak Cloud KMS-keyrings en -sleutels aan in europe-west-regio’s; schakel CMEK in voor BigQuery-datasets, GCS-buckets en Persistent Disks. Configureer geplande rotatie en versiebewaking. Rationale: aantoonbare cryptografische controle die is afgestemd op EU-residentie en PCI.

5. Applicatielaag-encryptie toepassen voor kaartgegevens

• Gebruik envelope-encryptie (Tink AEAD) met per-tenant datasleutels die ‘gewrapt’ zijn door CMEK; sla alleen ciphertext op in databases. Rationale: bescherming op veldniveau en een geminimaliseerde scope tijdens incident triage.

6. Secrets centraliseren en automatisch rouleren

• Sla DB-credentials en API-tokens op in Secret Manager met per-service IAM. Implementeer door Pub/Sub getriggerde rotatie-jobs die nieuwe versies aanmaken en implementaties bijwerken. Schakel waar mogelijk over op IAM DB-authenticatie voor Cloud SQL. Rationale: auditeerbare levenscyclus van secrets met minimale downtime.

7. Netwerken segmenteren en egress controleren

• Gebruik hiërarchisch firewall-beleid om web→API→DB-stromen af te dwingen; verbied web→DB rechtstreeks. Schakel Cloud NAT in met egress allowlists en Private Google Access (restricted) voor Google API’s. Rationale: beperkt oost-west verkeer (east-west movement) en blokkeert niet-goedgekeurde exfiltratie.

8. Dataservices ‘wrappen’ met VPC Service Controls

• Plaats BigQuery-, GCS- en Secret Manager-projecten in een service perimeter; definieer toegangsniveaus (access levels) die een bedrijfs-IP en beheerde apparaten vereisen. Testen met een dry-run, daarna afdwingen. Rationale: vermindert data-exfiltratie via gestolen tokens of verkeerd geconfigureerde clients.

9. De edge en API’s beveiligen

• Plaats Cloud Armor met beheerde regels en rate limiting voor de globale HTTPS load balancer. Gebruik path-based routing om /v1 en /v2 te scheiden naar afzonderlijke backend-services en pas op maat gemaakte WAF-beleidsregels per versie toe. Integreer Apigee voor authenticatie, quota’s en schemavalidatie. Rationale: gelaagde API-bescherming, een soepele v1→v2-transitie en geminimaliseerde false positives.

10. Compute harden en artefacten attesteren

• Schakel Shielded VMs en Confidential VMs in voor verwerkingsnodes; gebruik CIS-geharde basis-images. Scan images in Artifact Registry, vereis ondertekende attesten met Binary Authorization voor GKE. Rationale: beschermt de boot chain en data-in-use, en dwingt vertrouwen in de supply chain af.

11. Posture en dreigingen monitoren met SCC

• Schakel SCC Premium in om risicovolle configuraties en runtime-dreigingen te detecteren; integreer met een ticketingsysteem voor SLA’s. Onderdruk geaccepteerde risico’s met vervaldatums. Rationale: continue zekerheid (assurance) en een bruikbaar signaal.

12. Loggen, bewaren en bewijsmateriaal produceren

• Routeer Admin Activity-, Data Access- en VPC Flow Logs naar BigQuery en Cloud Storage met retentiebeleid en juridische bewaring (legal holds). Tag datasets met residentie- en gevoeligheidslabels. Rationale: ondersteunt onderzoeken en externe audits met beperkte (scoped) toegang.

13. Incidentrespons en forensisch onderzoek voorbereiden

• Maak runbooks om gecompromitteerde services te isoleren door projecten te verplaatsen naar een quarantainemap met strenger beleid, de betreffende SA’s uit te schakelen en snapshots van schijven te maken voor offline analyse. Rationale: snelle inperking (containment) met behoud van bewijsmateriaal.

Korte commando’s die de uitrol ondersteunen:

• gcloud kms keyrings create pci-ring –location=europe-west1
• gcloud kms keys create tenant-wrap –keyring=pci-ring –location=europe-west1 –purpose=encryption –rotation-period=90d
• gcloud access-context-manager levels create corp-devices –title=corp-devices –basic-level-spec=‘ipSubnetworks: [“203.0.113.0/24”]’

Met deze stappen bereikt NimbusPay gelaagde bescherming (identiteit, crypto, netwerk en edge), verifieerbare compliance, een gecontroleerde API-evolutie onder één hostnaam, en paraatheid om incidenten te detecteren, in te perken en ervan te herstellen.

← Netwerken · Alle domeinen · Betrouwbaarheid →

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

Blader door Google →