Google PCA: Organisatieontwerp, IAM en Cloud Governance — Studiegids
Onderdeel van de Google Professional Cloud Architect — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.
Overzicht
Organisatieontwerp, IAM en governance vormen de basis waarop alle Google Cloud-architecturen draaien. Goede ontwerpen creëren duidelijke administratieve grenzen, minimaliseren de ‘blast radius’, maken ’least privilege’ mogelijk, beheersen de kosten en schalen operationeel over vele teams en omgevingen. Governance moet de nadruk leggen op vangrails in plaats van poorten: automatiseer standaardinstellingen die veilig, meetbaar en omkeerbaar zijn, terwijl de dagelijkse controle wordt gedelegeerd aan de teams die het dichtst bij de workload staan.
Resourcehiërarchie en Identiteitsfundamenten
Google Cloud-resources vormen een strikte boomstructuur: Organization → Folders → Projects → Resources (bijvoorbeeld Compute Engine-instances, buckets). IAM-beleidsregels en Organization Policy-constraints worden naar beneden in de boomstructuur overgeërfd.
Belangrijke ontwerpprincipes:
- Gebruik één enkele Organization om governance te centraliseren. Maak Folders op het hoogste niveau voor belangrijke administratieve grenzen (bijvoorbeeld business units, regio’s, of gereguleerd vs. niet-gereguleerd).
- Creëer binnen elke grens omgevings-Folders (prod, nonprod) om gedifferentieerd beleid toe te passen. Houd projecten waar mogelijk workload-specifiek en kortstondig (’ephemeral’) om de ‘blast radius’ te verkleinen en doorbelasting te vergemakkelijken.
- Overerving: ‘allow’-toekenningen accumuleren (unie van ‘allow’-bindings van voorouders en de node zelf). IAM Deny-beleidsregels hebben, indien gebruikt, voorrang en kunnen toegang blokkeren, zelfs als er een ‘allow’ bestaat. Vermijd het plaatsen van brede rollen hoog in de boomstructuur; de ‘blast radius’ is groot en moeilijk terug te draaien.
Identiteitsbronnen:
- Cloud Identity is het identiteitsplatform voor medewerkers. Integreer met uw enterprise IdP (SAML/OIDC) om authenticatie en de levenscyclus (in-, door- en uitstroom van personeel) te centraliseren. Gebruik Google Cloud Directory Sync voor synchronisatie van attributen en groepen indien nodig.
- Groepen zijn de primaire IAM-subjecten. Toegang op basis van groepen maakt schaalbare wijzigingen en auditeerbaar eigenaarschap mogelijk. Gebruik een ‘group-of-groups’-patroon (bijvoorbeeld net-admins, sec-admins, app-team-A) en beperk wie het groepslidmaatschap kan beheren.
- Service accounts vertegenwoordigen workloads. Geef de voorkeur aan service account impersonation met kortlevende credentials boven opgeslagen sleutels. Vermijd door gebruikers beheerde service account keys; behandel ze als uitzonderingen met strikte goedkeuringen en rotatie.
- Workload identity-patronen:
- GKE Workload Identity koppelt Kubernetes service accounts aan Google service accounts; dit elimineert de noodzaak voor credentials op node-niveau.
- Workload Identity Federation stelt externe identiteiten (on-prem, andere clouds, GitHub Actions) in staat om kortlevende Google-toegang te verkrijgen zonder sleutels. Gebruik scoping op pool/provider-niveau en attribuutcondities om de toegang te beperken.
Veelvoorkomende faalscenario’s en oplossingen:
- Het toekennen van primitieve rollen (Owner/Editor/Viewer) op Folder- of Organization-niveau leidt tot wijdverbreide overmatige privileges. Gebruik deze alleen in zeer beperkte ‘break-glass’-projecten.
- Wildgroei van groepen met onduidelijk eigenaarschap ondermijnt het principe van ’least privilege’. Dwing naamgeving, ‘purpose’-tags en metadata van de eigenaar af op groepen.
- Verweesde service accounts en verouderde bindings accumuleren risico. Plan periodieke access reviews en gebruik IAM Recommender om ongebruikte permissies te verminderen.
IAM-modellen, Rollen en Toegangsoperaties
Rollen en bindings:
- Vooraf gedefinieerde rollen zijn samengesteld voor specifieke services en zouden de standaardkeuze moeten zijn.
- Custom rollen vullen de gaten wanneer vooraf gedefinieerde rollen te grofmazig zijn. Bouw ze op vanuit de minimale set van permissies die als noodzakelijk zijn waargenomen; versiebeheer en test ze.
- Basisrollen (Viewer/Editor/Owner) zijn verouderd en te breed. Vermijd deze op Organization- en Folder-scopes. Gebruik Owner niet voor dagelijkse operaties; reserveer deze voor ‘break-glass’-scenario’s op platformniveau met sterke compenserende maatregelen.
- Conditionele rolbindings (IAM Conditions) beperken wanneer en waar een binding van toepassing is door gebruik te maken van attributen zoals
undefined
,
undefined
,
undefined
, of
undefined
. Gebruik condities voor tijdsgebonden toegang, op tags gebaseerde toegang tot productie, of locatiegebonden acties.
‘Least privilege’ en escalatie van privileges:
- Scheid ‘read’-, ‘operate’- en ‘administer’-taken. Netwerk-, security- en app-teams krijgen bijvoorbeeld verschillende rollen op verschillende scopes.
- Gebruik ‘just-in-time’-escalatie met Access Approval-workflows of ticket-gestuurde automatisering om tijdelijke rollen te binden via condities.
Deny-beleidsregels en risico’s:
- IAM Deny kan centraal risicovolle permissies blokkeren (bijvoorbeeld
undefined
). Deny heeft voorrang op allow en is van toepassing op de gehele sub-boomstructuur. Valideer grondig; verkeerd geconfigureerde denies kunnen automatisering buitensluiten of implementaties breken.
Auditeerbaarheid en reviews:
- Schakel Admin Activity logs in op Organization-niveau; deze worden standaard 400 dagen bewaard. Schakel voor gevoelige services Data Access logs in en stuur ze door naar BigQuery voor langdurige bewaring en auditing.
- Implementeer periodieke access reviews: inventariseer bindings met Cloud Asset Inventory, vergelijk met eigendomsregisters, verwijder ongebruikte rollen die door IAM Recommender worden voorgesteld, en verifieer de vervaldatum van uitzonderingen.
Handig voorbeeld (tijdsgebonden, op tag gebaseerde binding):
undefined
Financiële governance en leidraden voor organisatiebeleid
Factureringsarchitectuur:
- Centraliseer een of meer factureringsaccounts onder eigendom van de financiële afdeling. Gebruik alleen meerdere factureringsaccounts wanneer dit wettelijk of operationeel vereist is (bijvoorbeeld voor afzonderlijke entiteiten of resellermodellen).
- Koppel projecten aan factureringsaccounts via automatisering; sta handmatige koppeling buiten goedgekeurde workflows niet toe.
Doorbelasting en kostenzichtbaarheid:
- Gebruik labels en kostentoewijzingstags consistent. Labels zijn vrije-vorm metadata voor filteren en rapporteren; tags zijn hiërarchisch en bruikbaar in IAM Conditions en beleidsregels. Activeer kostentoewijzing voor geselecteerde tags zodat ze in factureringsexports verschijnen.
- Exporteer factureringsgegevens naar BigQuery voor analyse; bouw dashboards per eigenaar, kostenplaats en omgeving. Vereis dat elk project een verantwoordelijke eigenaar en een budget heeft.
Budgetten en anomaliedetectie:
- Maak budgetten met waarschuwingen op map- en projectniveau. Voeg programmatische reacties toe (bijvoorbeeld de on-call-engineer waarschuwen, tickets aanmaken of nieuwe quotumverhogingen uitschakelen) om uit de hand lopende uitgaven te beteugelen.
- Gebruik quota’s en toezeggingen (CUDs) die zijn afgestemd op het verwachte gebruik; monitor het gebruik.
Beperkingen van organisatiebeleid (standaard veilig):
- Dwing leidraden af op organisatie- of mapniveau en versoepel alleen waar gerechtvaardigd. Veelvoorkomende beperkingen:
- constraints/iam.disableServiceAccountKeyCreation = true
- constraints/compute.requireOsLogin = true
- constraints/compute.trustedImageProjects die VM-images beperken
- constraints/sql.restrictPublicIp = true
- constraints/storage.uniformBucketLevelAccess = true
- constraints/compute.disableSerialPortAccess = true
- Gebruik VPC Service Controls om het risico op data-exfiltratie voor ondersteunde services binnen gevoelige perimeters te verminderen.
Afhandeling van beleidsuitzonderingen:
- Uitzonderingen moeten aanvraagbaar, goedgekeurd, tijdgebonden en auditeerbaar zijn. Geef de voorkeur aan IAM Conditions om uitzonderingen te beperken op basis van tag/tijd. Controleer periodiek uitzonderingen en laat ze automatisch verlopen via policy-as-code-pipelines.
Voorbeeld van een Organization Policy (YAML) om serviceaccountsleutels uit te schakelen:
undefined
Pas vervolgens toe:
undefined
Landing Zones, Gedeelde Services, Automatisering en Operationele Modellen
Landing zone:
- Bied een vooraf ‘geharde’ (pre-hardened) baseline: Organization Policies, logging sinks, CMEK-strategie, Shared VPC’s, private DNS, Cloud NAT, Private Service Connect, audit- en security-projecten, en beperkte image-catalogi.
- Aparte host-projecten per omgeving voor Shared VPC. Netwerkbeheerders beheren de host-projecten; applicatieteams deployen in service-projecten die aan de juiste host gekoppeld zijn.
Project factory:
- Automatiseer het aanmaken van projecten met infrastructure-as-code. Creëer projecten met:
- Correcte plaatsing in een Folder en koppeling met facturering
- Vooraf gekoppelde groepen en rollen
- Standaard service accounts uitgeschakeld of beperkt
- Logging sinks naar centrale projecten en retentie-buckets
- Vooraf gedefinieerde budgetten, labels en tags
- Gebruik Terraform-modules of Cloud Config Controller om de factory te codificeren. Dwing beleidsvalidatie af in CI voordat wijzigingen worden toegepast.
Gedeelde services en isolatie:
- Centraliseer identiteit, netwerken, CI/CD, artifact registries en security-tooling in toegewijde projecten. Isoleer omgevingen per Folder en VPC; blokkeer laterale beweging met firewall policies, aparte service perimeters en afzonderlijke Cloud KMS-keyrings per omgeving.
- Gebruik Private Service Connect en producer-projecten om gedeelde services te publiceren naar consumers zonder publieke endpoints bloot te stellen.
Audit-logging en governance-automatisering:
- Stuur Admin Activity- en Data Access-logs naar een audit-project. Configureer log-buckets met CMEK en retentiebeleid dat is afgestemd op compliance-eisen.
- Gebruik Cloud Asset Inventory-feeds naar Pub/Sub plus Cloud Functions/Cloud Run om drift te detecteren (bijvoorbeeld openbare buckets) en automatisch te herstellen of tickets aan te maken.
- Policy-as-code stack:
- Org Policies en IAM als code opgeslagen in een repo
- Config Validator/Policy Controller voor KRM-resources
- Beleidscontroles vóór de deployment in CI/CD
- Geplande reconciler-jobs om de gewenste staat opnieuw toe te passen
Naamgeving van resources en tags:
- Dwing korte, leesbare naamgevingspatronen af die omgeving, app, regio en volgnummer coderen (bijvoorbeeld, appA-prd-usw2-web-01). Reserveer tags voor governance (env=prod, pii=true, owner=team-x). Valideer de aanwezigheid van vereiste labels/tags bij het aanmaken van een project.
Multi-team operaties en gedelegeerd beheer:
- Stel platform-, security- en netwerkteams in met duidelijk gedefinieerde scopes en rollen. Delegeer beheer op projectniveau aan applicatieteams binnen hun Folder-grens. Bied selfservice binnen kaders (guardrails) via catalogi en templates.
- Balanceer autonomie versus risico door beslissingen met een kleine ‘blast radius’ naar de teams te delegeren en beslissingen die veel projecten of gedeelde infrastructuur beïnvloeden te centraliseren.
Praktijkscenario
Contoso Retail is van plan om binnen drie maanden acht productteams te onboarden naar Google Cloud. Elk team heeft productie- en non-productieomgevingen, geïsoleerde netwerken, gecentraliseerde security-logging en kostentoerekening nodig. Het platformteam moet de wildgroei van service account keys voorkomen, VM-images beperken en tijdgebonden verhoogde toegang voor incident response mogelijk maken.
Aanpak:
- Zet de hiërarchie en folders op
- Maak Folders op het hoogste niveau voor afdelingen en geneste Folders voor productie en non-productie. Rationale: duidelijke administratieve grenzen maken gerichte kaders (guardrails) en budgetten mogelijk, terwijl gedelegeerd beheer aan productteams wordt toegestaan zonder rechten op organisatieniveau te verlenen.
- Implementeer een landing zone met Shared VPC
- Maak host-projecten voor productie- en non-productienetwerken die worden beheerd door het netwerkteam. Koppel de service-projecten van de teams via Shared VPC. Rationale: centraliseert routing, NAT en firewall-beleid terwijl workloads per project worden geïsoleerd; voorkomt ad-hoc netwerken die leiden tot wildgroei en inconsistente beveiliging.
- Implementeer kaders (guardrails) met organization policies
- Dwing beperkingen af: schakel het aanmaken van service account keys uit, vereis OS Login, beperk publieke IP’s voor Cloud SQL, beperk VM-images tot vertrouwde projecten en schakel uniforme toegang op bucket-niveau in. Rationale: ‘secure-by-default’ vermindert veelvoorkomende misconfiguraties; uitzonderingen kunnen waar nodig tijdgebonden zijn.
- Zet identiteit en groepen op
- Integreer Cloud Identity met de enterprise IdP; maak groepen voor de dev-, ops- en admin-persona’s van elk team en groepen op platformniveau voor netwerk-admins en sec-admins. Rationale: op groepen gebaseerd IAM is schaalbaar en sluit aan bij scheiding van verantwoordelijkheden (separation of duties); de levenscyclus volgt HR-gebeurtenissen.
- Definieer IAM met ’least privilege’ en voorwaardelijke escalatie
- Koppel vooraf gedefinieerde rollen aan groepen op Folder- of projectniveau; maak escalatie voor incident-response mogelijk via voorwaardelijke koppelingen (conditional bindings) die beperkt zijn tot resources met de ‘prod’-tag en na 24 uur verlopen. Rationale: ’least privilege’ voor dagelijkse werkzaamheden, met veilige, auditeerbare escalatie wanneer nodig.
- Bouw een ‘project factory’-pipeline
- Gebruik Terraform-modules om projecten te maken met de vereiste labels/tags (env, owner, cost-center), de facturering te koppelen, te koppelen aan de juiste Shared VPC, logging sinks naar een centraal audit-project te creëren en budgetten in te stellen. Rationale: consistente, conforme provisioning op schaal elimineert handmatige drift en versnelt de onboarding.
- Centraliseer audit-logging en access reviews
- Stuur Admin Activity- en Data Access-logs naar BigQuery met CMEK; plan maandelijkse queries om IAM-koppelingen (bindings) op te sommen en te vergelijken met groepseigendom en ’last-access’-data van IAM Recommender. Rationale: een duurzaam audittraject en continue ‘right-sizing’ van toegang verminderen risico en kosten.
- Kostenbeheer en -meldingen
- Activeer kostentoewijzingstags en -labels, exporteer factureringsgegevens naar BigQuery en stel budgetten per Folder en per project in met meldingen aan de financiële afdeling en teamleiders. Rationale: transparante doorbelasting (chargeback) stimuleert verantwoordelijkheid; vroege meldingen beperken uit de hand lopende uitgaven.
- Workload identity en sleutelloze automatisering
- Activeer voor GKE Workload Identity; voor externe CI (GitHub), stel Workload Identity Federation in met een scope die beperkt is tot specifieke repositories met voorwaarden. Rationale: elimineert langlevende sleutels en beperkt het gebruik tot de beoogde workloads.
- Uitzonderingsproces en automatisering
- Implementeer een aanvraagworkflow die via CI voorwaardelijke IAM-koppelingen (bindings) of tijdelijke beleidsversoepelingen met automatische vervaldatum creëert. Rationale: geeft teams meer mogelijkheden (empowers) zonder controle op te offeren; elke uitzondering is tijdgebonden en auditeerbaar.
Technische resultaten:
- Teams kunnen binnen 15 minuten zelf nieuwe projecten aanmaken met conforme standaardinstellingen.
- Door gebruikers beheerde service account keys zijn niet toegestaan; escalatie voor incident-response is tijdgebonden en beperkt op basis van tags.
- Kosten worden per team en omgeving geaggregeerd, met geautomatiseerde budgetten en meldingen bij afwijkingen.
- Audit-logs en access reviews valideren continu dat permissies en beleid overeenkomen met de intentie.
Alle domeinen · Compute →
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 →