Google ACE: Beveiliging, compliance en gegevensbescherming — Studiegids
Onderdeel van de Google Associate Cloud Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.
Overzicht
Beveiliging, compliance en gegevensbescherming op Google Cloud zijn gebaseerd op een model van gedeelde verantwoordelijkheid en een secure-by-default, defense-in-depth-aanpak. Google beveiligt de fysieke infrastructuur, fundamentele services en standaardversleuteling, terwijl u verantwoordelijk bent voor het beveiligen van identiteit en toegang, gegevensclassificatie en -retentie, applicatieconfiguraties en operationele processen. Ontwerp volgens het principe van ’least privilege’ over de gehele resourcehiërarchie, gebruik groepen in plaats van individuen, geef de voorkeur aan beheerde identiteiten en kortlevende credentials, en gebruik gelaagde controles zodat het falen van een enkele controle niet leidt tot een compromittering. Bouw vanaf het begin workflows voor observability en respons, zodat de ‘posture’ continu kan worden gemeten en verbeterd.
Basisprincipes van Identiteit en Toegang
- Gedeelde verantwoordelijkheid en ’least privilege’
- Organiseer projecten onder één organisatie met mappen die vertrouwensgrenzen weerspiegelen. Pas Organization Policy-beperkingen toe om veilige standaardinstellingen af te dwingen (bijvoorbeeld openbare IP’s weigeren, locaties beperken, het aanmaken van serviceaccount-sleutels voorkomen).
- Wijs IAM-rollen toe aan Google Groups, niet aan gebruikers, en geef de voorkeur aan vooraf gedefinieerde rollen boven basisrollen. Controleer rolbindingen regelmatig en verwijder ongebruikte rechten.
Zorg voor auditeerbaarheid en attributie. Gebruik voor admin OS-toegang tot VM’s OS Login met SSH-sleutels per gebruiker; wijs aan groepen de rollen roles/compute.osLogin of roles/compute.osAdminLogin toe. Voorbeeld:
undefined
-
undefined
Veelvoorkomende faalscenario’s: het toekennen van de ‘owner’- of ’editor’-rol aan gebruikers, het gebruik van projectbrede SSH-sleutels en het aanmaken van langlevende serviceaccount-sleutels.
Bescherming van applicatietoegang met BeyondCorp en Identity-Aware Proxy (IAP)
- IAP beëindigt identiteitsbewuste toegang aan de ’edge’ van Google voor HTTPS-apps en voor TCP-forwarding (SSH/RDP), waardoor het niet meer nodig is om apps of bastions bloot te stellen aan het internet. Combineer dit met contextbewuste toegangsbeleidsregels (Access Context Manager) om de ‘device posture’, IP-bereiken of gebruikersgroepen te vereisen.
- Voordelen: gecentraliseerde authN/Z, sterke attributie, een verkleind aanvalsoppervlak en vereenvoudigd firewallbeleid (inkomend verkeer weigeren, behalve voor de load balancer/IAP).
- Afwegingen: een misconfiguratie kan beheerders buitensluiten; zorg voor een ‘break-glass’-pad (een beperkte project-owner, out-of-band consoletoegang). Sommige legacy-protocollen of niet-HTTP-services vereisen mogelijk IAP TCP-forwarding of alternatieve controles.
Serviceaccounts en workload-identiteit
- Geef er de voorkeur aan om serviceaccounts te koppelen aan Compute Engine, GKE met Workload Identity, Cloud Run en Cloud Functions, zodat workloads automatisch kortlevende tokens verkrijgen. Vermijd het insluiten van sleutels; schakel het aanmaken van serviceaccount-sleutels uit met een org policy. Beperk de scope van IAM op serviceaccounts (principe van ’least privilege’).
- Faalscenario’s: het breed toekennen van de rol roles/iam.serviceAccountUser, wat ‘impersonation’ mogelijk maakt; overgeprivilegieerde serviceaccounts die doelwitten worden voor ’lateral movement’.
Gegevensbescherming en Sleutelbeheer
- Versleuteling, Cloud KMS, CMEK en ’envelope encryption’
- Google versleutelt standaard alle data ‘at rest’ en ‘in transit’. Gebruik voor extra controle en functiescheiding (‘segregation-of-duty’) Customer-Managed Encryption Keys (CMEK) in Cloud KMS. Veel services (BigQuery, Cloud Storage, Pub/Sub, Compute Engine-schijven) ondersteunen CMEK; services gebruiken ’envelope encryption’ waarbij uw CMEK de DEK’s per object of per ‘chunk’ omhult.
Plan de sleutelhiërarchie: ‘key rings’ per regio, cryptosleutels per datadomein en rotatie elke 90–365 dagen op basis van risico. Voorbeeld van rotatie:
undefined
Toegangscontrole: wijs serviceaccounts de rol Cloud KMS CryptoKey Encrypter/Decrypter alleen toe op de benodigde sleutels. Monitor met de gebruikslogs van Cloud KMS.
Faalscenario’s en afwegingen: het uitschakelen of verwijderen van een CMEK maakt afhankelijke data onleesbaar; plan ‘incident runbooks’, controleer IAM dubbel vóór rotatie en waarborg de beschikbaarheid van sleutels over deployments heen. Overweeg External Key Manager als u sleutels buiten Google Cloud moet bewaren; houd rekening met extra latency en het risico van externe afhankelijkheden.
Secret Manager en het elimineren van hardgecodeerde credentials
- Sla API-sleutels, DB-wachtwoorden en tokens op in Secret Manager met automatisch versiebeheer en op IAM gebaseerde toegang. Integreer rotatie via Cloud Scheduler → Pub/Sub → Cloud Functions/Run, die het bronsysteem bijwerkt en een nieuwe secret-versie schrijft. Applicaties halen secrets op bij het opstarten of ‘on demand’ en cachen deze minimaal.
- Best practices: commit nooit secrets naar code of images; vermijd het printen van secrets naar logs; wijs de rol roles/secretmanager.secretAccessor toe aan workload-identiteiten; gebruik labels om de gevoeligheid te taggen.
- Faalscenario’s: het insluiten van secrets in omgevingsvariabelen die bij crashes worden gelogd; vergeten om downstream-apps bij te werken na rotatie; te brede IAM-rechten op secrets.
Gegevensclassificatie, -retentie en privacy
- Classificeer data (openbaar, intern, vertrouwelijk, gereguleerd) en tag assets met labels. Gebruik BigQuery column-level security en row access policies voor fijnmazige controle. Gebruik voor detectie en maskering Sensitive Data Protection (DLP).
- Implementeer retentie: Cloud Storage Object Lifecycle (op leeftijd gebaseerde klasse-overgangen, verwijderen), bucket-retentiebeleid met ‘holds’ en TTL’s voor BigQuery-tabellen of -partities. Stem retentie af op wettelijke vereisten; een langere retentie verhoogt het risico en de kosten.
- Privacy en ‘residency’: beperk resourcelocaties met org policies; kies tussen multi-regionale en regionale opslag op basis van soevereiniteits- en latency-eisen. Lever bewijsmateriaal met auditlogs en SCC posture-dashboards.
Netwerk- en Edge-beveiliging
Diepgaande verdediging (defense in depth) voor netwerken
- Gebruik VPC-firewallregels met een ‘default deny’-houding; sta alleen noodzakelijke bronbereiken en poorten toe. Geef de voorkeur aan Private Google Access en Private Service Connect om API-verkeer van het openbare internet te houden. Log VPC Flow Logs en Firewall Rules Logging; controleer regelmatig egress-patronen.
- Voor uitgaande controle (outbound control), weiger alle egress en sta vervolgens expliciet de noodzakelijke bestemmingen toe via een FQDN egress-proxy of NAT plus proxy. Monitor Cloud NAT-logs en configureer DNS-logging.
VPC Service Controls (VPC SC), serviceperimeters en toegangsniveaus
- Plaats ondersteunde Google API’s (bijvoorbeeld BigQuery, Storage, Pub/Sub) binnen serviceperimeters om de risico’s van data-exfiltratie te beperken, zelfs als inloggegevens zijn gecompromitteerd. Gebruik Access Context Manager om toegangsniveaus te definiëren op basis van gebruikersgroep, IP of apparaatstatus (device posture), wat contextbewust beleid mogelijk maakt.
- Configureer egress-regels voor legitieme integraties over perimeters heen en perimeter-bruggen (perimeter bridges) wanneer dat nodig is. Test met de dry-run-modus van VPC SC om potentiële onderbrekingen aan het licht te brengen voordat de regels worden afgedwongen.
- Faalscenario’s: het onbedoeld blokkeren van CI/CD of projectoverschrijdende taken, het falen van integraties met derden, of ontwikkelaars die de beveiliging omzeilen met onbeheerde apparaten. Documenteer uitzonderingen en controleer deze regelmatig.
Cloud Armor, DDoS-bescherming en WAF-regels
- De wereldwijde edge van Google biedt altijd actieve (always-on) L3/L4 DDoS-bescherming. Cloud Armor voegt L7-beveiliging toe voor externe HTTP(S) load balancers, inclusief rate limiting, geo/IP-gebaseerde toegang, aangepaste expressies (custom expressions) en voorgeconfigureerde WAF-regelsets.
Voorbeeld van het aanmaken en koppelen van een basis-WAF:
undefined
-
undefined
- Koppel de policy aan de backend service van uw HTTPS load balancer.
- Best practices: start regels in preview-modus om false positives te verminderen, voeg ‘allow’-regels toe voor bekend, goedaardig verkeer en schakel adaptieve bescherming (adaptive protection) in indien beschikbaar. Afwegingen: Cloud Armor wordt afgedwongen op HTTP(S) en proxy-gebaseerde load balancers; network load balancers en interne LB’s vereisen andere beheersmaatregelen.
Security Operations and Compliance
Security Command Center (SCC) en beveiligingsstatusbeheer
- Gebruik SCC als het controlepaneel voor inzicht in risico’s. De Standard-tier verzamelt bevindingen over misconfiguraties en kwetsbaarheidsdata; de Premium-tier voegt daar dreigingsdetectie (bijvoorbeeld Event Threat Detection, VM and Container Threat Detection) en inzichten in aanvalspaden aan toe.
- Trieer bevindingen op ernst, wijs eigenaren toe en volg ze tot ze zijn opgelost. Exporteer bevindingen naar BigQuery of Pub/Sub voor SIEM-integratie en bewijsvoering. Meet continu de status ten opzichte van het organisatiebeleid en stel waarschuwingen in voor regressies.
Shielded VM, secure boot, vTPM, integriteitsmonitoring en OS-hardening
- Schakel Shielded VM-functies in om rootkits en manipulatie van het opstartproces te blokkeren: Secure Boot, vTPM en Integrity Monitoring om wijzigingen in bootloaders en de kernel te detecteren. Sommige custom kernels of niet-ondertekende modules kunnen Secure Boot laten mislukken; valideer images voordat u dit inschakelt.
- Verhard het besturingssysteem met OS Config voor patch-compliance, op CIS afgestemde baselines, minimale pakketten, SSH zonder wachtwoord en het loggen van sudo- en auth-gebeurtenissen. Geef de voorkeur aan IAP TCP-forwarding voor SSH en beperk ingress tot 0.0.0.0/0.
Forensische logging, incident-triage, indamming en herstel
- Logging om forensisch onderzoek mogelijk te maken: Admin Activity en Data Access audit logs, VPC Flow Logs, Firewall Rules Logging, Cloud DNS-logs, load balancer-logs en toegangslogs van Cloud KMS en Secret Manager. Exporteer naar een gecentraliseerd logproject en BigQuery met de juiste retentie- en toegangscontroles.
- Draaiboek voor triage en indamming:
- Valideer indicatoren met SCC-bevindingen en gecorreleerde logs.
- Dam in door verdachte tokens in te trekken, gecompromitteerde service accounts uit te schakelen, deny-firewallregels toe te voegen of instanties tijdelijk te isoleren met tags.
- Bewaar bewijsmateriaal: maak snapshots van schijven, exporteer logs, leg geheugen vast indien nodig met goedgekeurde tooling, en leg de chain-of-custody vast.
- Herstel: roteer secrets en sleutels, patch kwetsbaarheden, herbouw vanaf ‘known-good’ images, voeg detecties toe om herhaling te voorkomen en voer een post-incident review uit om de controles te versterken.
Praktisch Probleemscenario
Nimbus Finance draait web- en API-workloads achter externe HTTP(S)-load balancers, verwerkt gereguleerde data in BigQuery en Cloud Storage, en staat engineers externe admin-toegang toe. Een recente red-team-oefening toonde risico’s aan van data-exfiltratie via gecompromitteerde credentials en ’lateral movement’. Het operations-team moet de toegang verharden, data beschermen en de detectie verbeteren zonder de levering te verstoren.
- OS Login afdwingen met admin-attributie
- Stappen: Schakel OS Login projectbreed in; voeg compute.osAdminLogin toe aan de engineers-groep; verwijder projectbrede SSH-sleutels.
- Reden: Per-gebruiker SSH-sleutels en op IAM gebaseerde roltoewijzingen zorgen voor duidelijke attributie en eenvoudige intrekking. Het elimineren van gedeelde sleutels vermindert ’lateral movement’.
- Beveilig externe toegang met IAP en context-aware access
- Stappen: Plaats de admin-UI achter een HTTPS-load balancer die is beveiligd met IAP; vereis lidmaatschap van de ops-groep en een bedrijfs-IP/apparaatstatus via Access Context Manager.
- Reden: Zero-trust-toegang elimineert publieke blootstelling en dwingt centraal identiteits- en apparaatvoorwaarden af, wat het risico op phishing en credential stuffing vermindert.
- Implementeer Cloud Armor WAF met gefaseerde handhaving
- Stappen: Maak een Cloud Armor-policy; schakel voorgeconfigureerde WAF-regels voor SQLi/XSS in preview-modus in; voeg een rate-limiting-regel toe voor /login; monitor de logs; handhaaf vervolgens.
- Reden: Preview-modus vermindert false positives; gerichte rate limits beperken credential stuffing en bots zonder legitiem verkeer te schaden.
- Omsluit datadiensten met VPC Service Controls
- Stappen: Creëer een service perimeter voor BigQuery- en Cloud Storage-projecten; definieer egress-regels voor goedgekeurde CI/CD- en analytics-jobs; vereis toegangsniveaus op basis van groep en netwerk.
- Reden: Perimeters beperken data-exfiltratie met geldige credentials door te beperken waar en hoe beschermde data benaderd kan worden.
- Pas CMEK toe met Cloud KMS en plan rotatie
- Stappen: Creëer regionale key rings en crypto keys voor BigQuery en Storage; ken alleen aan service accounts de rol roles/cloudkms.cryptoKeyEncrypterDecrypter toe; stel een rotatieschema van 180 dagen in; monitor de logs over sleutelgebruik.
- Reden: CMEK dwingt scheiding van taken en gecontroleerde cryptografische grenzen af; rotatie beperkt de ‘blast radius’ als een sleutel wordt blootgesteld.
- Centraliseer secrets met Secret Manager en automatiseer rotatie
- Stappen: Verplaats database- en derde-partij-tokens naar Secret Manager; verleen ’least-privilege’-toegang aan workloads; implementeer een Cloud Scheduler → Pub/Sub → Cloud Run-job om secrets te roteren en nieuwe versies te creëren.
- Reden: Elimineert hardgecodeerde credentials; versioning en automatisering zorgen voor voorspelbare, auditeerbare rotatie met minimale downtime.
- Versterk host-beveiliging met Shielded VM en OS-hardening
- Stappen: Schakel Secure Boot, vTPM en Integrity Monitoring in op alle Compute Engine-instanties; dwing SSH zonder wachtwoord af; gebruik OS Config om wekelijks te patchen en CIS-baselines toe te passen.
- Reden: Voorkomt manipulatie op boot-niveau, detecteert afwijkingen en vermindert het aanvalsoppervlak op compute nodes.
- Verhoog de observeerbaarheid en het beveiligingsstatusbeheer met SCC
- Stappen: Schakel SCC Premium in voor de hele organisatie; configureer real-time notificaties naar Pub/Sub; exporteer bevindingen en logs naar BigQuery; bouw dashboards voor belangrijke KPI’s (aantal openstaande hoge bevindingen, gemiddelde tijd tot herstel).
- Reden: Gecentraliseerd inzicht verkort de tijd tussen detectie en respons en levert bewijs voor compliance.
- Bereid een incident-draaiboek voor en test het
- Stappen: Documenteer triage-stappen, geprivilegieerde ‘break-glass’-accounts en indammingsacties (IAM uitschakelen, isoleren met firewall, tokens intrekken); oefen per kwartaal; dwing logretentie en ‘object holds’ af in het bewijsproject.
- Reden: Ingeoefende workflows verminderen fouten onder druk en waarborgen de forensische integriteit voor hoofdoorzaakanalyse en rapportage aan regelgevende instanties.
- Valideer wijzigingen en minimaliseer verstoring
- Stappen: Gebruik de ‘dry run’-modus van VPC SC en de preview-modus van Cloud Armor om problemen te detecteren; rol uit per omgeving met canaries; onderhoud een rollback-plan en change windows.
- Reden: Een gecontroleerde uitrol beperkt de beschikbaarheidsrisico’s van aangescherpte beveiliging, terwijl de beoogde vermindering van exfiltratie- en toegangsrisico’s wordt bereikt.
← Monitoring · Alle domeinen · Betrouwbaarheid →
Oefen deze vragen → · Getimede oefening op 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.
Slaag voor je examen →