Google PCA: Design organizzativo, IAM e governance del cloud — Guida allo studio

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

Fa parte della Google Professional Cloud Architect — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La progettazione dell’organizzazione, IAM e la governance stabiliscono le fondamenta su cui si basano tutte le architetture Google Cloud. Una buona progettazione crea confini amministrativi chiari, minimizza il raggio d’impatto, abilita il principio del privilegio minimo, controlla i costi e scala operativamente su più team e ambienti. La governance dovrebbe enfatizzare i guardrail piuttosto che i cancelli: automatizzare le impostazioni predefinite affinché siano sicure, misurabili e reversibili, delegando al contempo il controllo quotidiano ai team più vicini al carico di lavoro.

Gerarchia delle Risorse e Fondamenti dell’Identità

Le risorse di Google Cloud formano un albero gerarchico rigido: Organizzazione → Cartelle → Progetti → Risorse (ad esempio, istanze Compute Engine, bucket). Le policy IAM e i vincoli dei Criteri dell’organizzazione vengono ereditati lungo l’albero.

Principi chiave di progettazione:

• Utilizzare una singola Organizzazione per centralizzare la governance. Creare Cartelle di primo livello per i principali confini amministrativi (ad esempio, business unit, regioni o ambienti regolamentati e non).
• All’interno di ogni confine, creare Cartelle per gli ambienti (prod, nonprod) per applicare policy differenziate. Mantenere i progetti con uno scope limitato al carico di lavoro ed effimeri, ove possibile, per ridurre il raggio d’impatto e facilitare l’addebito dei costi (chargeback).
• Ereditarietà: le concessioni di autorizzazione si accumulano (unione dei binding di autorizzazione degli antenati e del nodo). Le policy di negazione (Deny) di IAM, se utilizzate, hanno la precedenza e possono bloccare l’accesso anche in presenza di un’autorizzazione. Evitare di assegnare ruoli ampi in alto nella gerarchia; il raggio d’impatto è vasto e difficile da annullare.

Fonti di identità:

• Cloud Identity è il piano di identità per la forza lavoro. Integrare con il proprio IdP aziendale (SAML/OIDC) per centralizzare l’autenticazione e il ciclo di vita degli utenti (assunzioni, trasferimenti e cessazioni). Utilizzare Google Cloud Directory Sync per la sincronizzazione di attributi e gruppi, se necessario.
• I Gruppi sono i soggetti principali di IAM. L’accesso basato sui gruppi consente modifiche scalabili e una proprietà verificabile. Utilizzare un pattern a gruppi di gruppi (ad esempio, net-admins, sec-admins, app-team-A) e limitare chi può gestire l’appartenenza ai gruppi.
• Gli account di servizio rappresentano i carichi di lavoro. Preferire l’impersonificazione di account di servizio con credenziali a breve termine rispetto alle chiavi archiviate. Evitare le chiavi di account di servizio gestite dall’utente; trattarle come eccezioni con approvazioni rigorose e rotazione.
• Pattern di identità per i carichi di lavoro:
  • GKE Workload Identity collega gli account di servizio Kubernetes agli account di servizio Google, eliminando le credenziali a livello di nodo.
  • Workload Identity Federation consente a identità esterne (on-prem, altri cloud, GitHub Actions) di ottenere accessi a breve termine a Google senza chiavi. Utilizzare lo scoping a livello di pool/provider e le condizioni sugli attributi per limitare l’accesso.

Modalità di fallimento comuni e mitigazioni:

• La concessione di ruoli primitivi (Proprietario/Editor/Visualizzatore) a livello di Cartella o Organizzazione porta a un eccesso di privilegi pervasivo. Utilizzarli solo in progetti di emergenza (break-glass) con uno scope molto ristretto.
• La proliferazione di gruppi con proprietà poco chiara compromette il principio del privilegio minimo. Imporre convenzioni di denominazione, tag di scopo e metadati sul proprietario per i gruppi.
• Gli account di servizio orfani e i binding obsoleti accumulano rischi. Pianificare revisioni periodiche degli accessi e utilizzare IAM Recommender per ridurre le autorizzazioni non utilizzate.

Modelli IAM, Ruoli e Operazioni di Accesso

Ruoli e binding:

• I ruoli predefiniti sono curati per servizi specifici e dovrebbero essere la scelta predefinita.
• I ruoli personalizzati colmano le lacune quando i ruoli predefiniti sono troppo generici. Costruirli partendo dal set minimo di autorizzazioni osservate come necessarie; gestirne le versioni e testarli.
• I ruoli di base (Visualizzatore/Editor/Proprietario) sono legacy ed eccessivamente ampi. Evitarli a livello di Organizzazione e Cartella. Non usare il ruolo Proprietario per le operazioni quotidiane; riservarlo per scenari di emergenza (break-glass) della piattaforma con forti controlli compensativi.
• I binding di ruolo condizionali (Condizioni IAM) limitano quando e dove un binding si applica utilizzando attributi come resource.name, resource.matchTag, request.time o request.auth.audiences. Utilizzare le condizioni per l’accesso a tempo limitato, l’accesso a produzione basato su tag o azioni limitate per località.

Privilegio minimo ed elevazione dei privilegi:

• Separare i compiti di “lettura”, “operatività” e “amministrazione”. Ad esempio, i team di rete, sicurezza e applicativi ottengono ruoli distinti su scope distinti.
• Utilizzare l’elevazione dei privilegi just-in-time con i flussi di lavoro di Access Approval o l’automazione basata su ticket per assegnare ruoli a tempo limitato tramite condizioni.

Policy di negazione (Deny) e rischi:

• IAM Deny può bloccare centralmente autorizzazioni rischiose (ad esempio, resourcemanager.projects.delete). La negazione (Deny) prevale sull’autorizzazione (allow) e si applica all’intero sottoalbero. Validare attentamente; una policy di negazione mal configurata può bloccare l’automazione o interrompere i deployment.

Verificabilità e revisioni:

• Abilitare i log delle Attività di amministrazione a livello di Organizzazione; per impostazione predefinita, vengono conservati per 400 giorni. Per i servizi sensibili, abilitare i log di Accesso ai dati e instradarli verso BigQuery per la conservazione a lungo termine e l’auditing.
• Implementare revisioni periodiche degli accessi: enumerare i binding con Cloud Asset Inventory, confrontarli con i registri di proprietà, rimuovere i ruoli non utilizzati suggeriti da IAM Recommender e verificare la scadenza delle eccezioni.

Esempio utile (binding con scope basato su tag e limiti di tempo):

undefined

Governance finanziaria e guardrail delle policy dell’organizzazione

Architettura di fatturazione:

• Centralizzare uno o più account di fatturazione sotto la responsabilità del dipartimento finanziario (Finance). Utilizzare più account di fatturazione solo quando richiesto per motivi legali o operativi (ad esempio, entità separate o modelli di rivendita).
• Collegare i progetti agli account di fatturazione tramite automazione; non consentire il collegamento manuale al di fuori dei flussi di lavoro approvati.

Riaddebito e visibilità dei costi:

• Utilizzare etichette (label) e tag di allocazione dei costi in modo coerente. Le etichette sono metadati a formato libero per il filtraggio e la reportistica; i tag sono gerarchici e utilizzabili nelle IAM Conditions e nelle policy. Abilitare l’allocazione dei costi per i tag selezionati affinché appaiano nelle esportazioni di fatturazione.
• Esportare i dati di fatturazione in BigQuery per l’analisi; creare dashboard per proprietario (owner), centro di costo e ambiente. Richiedere che ogni progetto abbia un proprietario responsabile e un budget.

Budget e rilevamento delle anomalie:

• Creare budget con avvisi (alert) a livello di cartella (Folder) e di progetto. Aggiungere reazioni programmatiche (ad esempio, notificare il personale di reperibilità, aprire ticket o disabilitare nuovi aumenti di quota) per contenere la spesa fuori controllo.
• Utilizzare quote e commitment (CUD) in linea con l’utilizzo previsto; monitorare l’utilizzo.

Vincoli delle policy dell’organizzazione (secure-by-default):

• Applicare i guardrail a livello di organizzazione o cartella (Folder) e allentarli solo dove giustificato. Vincoli comuni:
  • constraints/iam.disableServiceAccountKeyCreation = true
  • constraints/compute.requireOsLogin = true
  • constraints/compute.trustedImageProjects che limita le immagini VM
  • constraints/sql.restrictPublicIp = true
  • constraints/storage.uniformBucketLevelAccess = true
  • constraints/compute.disableSerialPortAccess = true
• Utilizzare VPC Service Controls per ridurre il rischio di esfiltrazione dei dati per i servizi supportati attraverso perimetri sensibili.

Gestione delle eccezioni alle policy:

• Le eccezioni devono essere richiedibili, approvate, limitate nel tempo e auditabili. Preferire le IAM Conditions per definire l’ambito delle eccezioni per tag/tempo. Riconciliare periodicamente le eccezioni e farle scadere automaticamente tramite pipeline di policy-as-code.

Esempio di Organization Policy (YAML) per disabilitare le chiavi degli account di servizio:

• name: organizations/1234567890/policies/iam.disableServiceAccountKeyCreation spec: rules:
  • enforce: true Quindi applicare: gcloud org-policies set-policy policy.yaml

Landing Zone, Servizi Condivisi, Automazione e Modelli Operativi

Landing zone:

• Fornire una baseline pre-configurata e sicura: Organization Policies, sink di logging, strategia CMEK, Shared VPC, DNS privato, Cloud NAT, Private Service Connect, progetti di audit e sicurezza, e cataloghi di immagini con restrizioni.
• Separare i progetti host per ogni ambiente per lo Shared VPC. Gli amministratori di rete controllano i progetti host; i team applicativi effettuano il deploy nei progetti di servizio collegati all’host corretto.

Fabbrica di progetti:

• Automatizzare la creazione dei progetti con l’infrastruttura-come-codice. Generare progetti con:
  • Posizionamento corretto nella Folder e collegamento alla fatturazione
  • Gruppi e ruoli pre-associati
  • Account di servizio predefiniti disabilitati o con restrizioni
  • Sink di logging verso progetti centrali e bucket di retention
  • Budget, etichette e tag predefiniti
• Usare moduli Terraform o Cloud Config Controller per codificare la fabbrica. Applicare la validazione delle policy nella CI prima di implementare le modifiche.

Servizi condivisi e isolamento:

• Centralizzare identità, networking, CI/CD, registri degli artefatti e strumenti di sicurezza in progetti dedicati. Isolare gli ambienti per Folder e VPC; bloccare i movimenti laterali con policy firewall, perimetri di servizio separati e keyring di Cloud KMS distinti per ambiente.
• Usare Private Service Connect e progetti producer per pubblicare servizi condivisi ai consumer senza esporre endpoint pubblici.

Logging di audit e automazione della governance:

• Indirizzare i log di Admin Activity e Data Access a un progetto di audit. Configurare i bucket di log con CMEK e policy di retention in linea con la conformità.
• Usare i feed di Cloud Asset Inventory verso Pub/Sub più Cloud Functions/Cloud Run per rilevare deviazioni (ad esempio, bucket pubblici) e auto-remediare o aprire ticket.
• Stack di policy-come-codice:
  • Org Policies e IAM come codice archiviati in un repository
  • Config Validator/Policy Controller per risorse KRM
  • Controlli delle policy pre-deployment in CI/CD
  • Job di riconciliazione pianificati per riapplicare lo stato desiderato

Nomenclatura delle risorse e tag:

• Applicare schemi di nomenclatura brevi e leggibili che codifichino ambiente, app, regione e sequenza (ad esempio, appA-prd-usw2-web-01). Riservare i tag per la governance (env=prod, pii=true, owner=team-x). Validare la presenza di etichette/tag richiesti alla creazione del progetto.

Operatività multi-team e amministrazione delegata:

• Stabilire team di piattaforma, sicurezza e rete con ambiti e ruoli chiaramente definiti. Delegare l’amministrazione a livello di progetto ai team applicativi entro i confini della loro Folder. Fornire self-service entro barriere di protezione (guardrail) tramite cataloghi e template.
• Bilanciare autonomia e rischio spingendo le decisioni con un basso raggio d’impatto verso i team e centralizzando le decisioni che influenzano molti progetti o l’infrastruttura condivisa.

Scenario Pratico

Contoso Retail pianifica di integrare otto team di prodotto in Google Cloud entro tre mesi. Ogni team necessita di ambienti di produzione e non, networking isolato, logging di sicurezza centralizzato e responsabilità sui costi. Il team di piattaforma deve prevenire la proliferazione incontrollata delle chiavi degli account di servizio, limitare le immagini delle VM e abilitare un accesso con privilegi elevati a tempo per la risposta agli incidenti.

Approccio:

1. Stabilire la gerarchia e le Folder

• Creare Folder di primo livello per i dipartimenti e Folder annidate per produzione (prod) e non produzione (nonprod). Logica: confini amministrativi chiari consentono barriere di protezione e budget mirati, abilitando al contempo l’amministrazione delegata ai team di prodotto senza concedere permessi a livello di organizzazione.

2. Implementare una landing zone con Shared VPC

• Creare progetti host per le reti di produzione e non produzione, gestiti dal team di rete. Collegare i progetti di servizio dei team tramite Shared VPC. Logica: centralizza il routing, il NAT e le policy firewall, isolando al contempo i carichi di lavoro per progetto; previene il networking ad hoc che porta a una proliferazione incontrollata e a una sicurezza incoerente.

3. Implementare barriere di protezione con le Organization Policy

• Applicare vincoli: disabilitare la creazione di chiavi per gli account di servizio, richiedere OS Login, limitare gli IP pubblici per Cloud SQL, limitare le immagini VM a progetti fidati e abilitare l’accesso uniforme a livello di bucket. Logica: un approccio “secure-by-default” riduce le errate configurazioni ad alta frequenza; le eccezioni possono essere limitate nel tempo dove necessario.

4. Impostare identità e gruppi

• Integrare Cloud Identity con l’IdP aziendale; creare gruppi per le diverse figure (dev, ops, admin) di ogni team e gruppi a livello di piattaforma per network-admin e sec-admin. Logica: l’IAM basato su gruppi è scalabile e si allinea con la separazione dei compiti; il ciclo di vita segue gli eventi delle risorse umane (HR).

5. Definire l’IAM con il principio del privilegio minimo e l’elevazione condizionale

• Associare ruoli predefiniti a gruppi a livello di Folder o di progetto; abilitare l’elevazione dei privilegi per la risposta agli incidenti tramite associazioni condizionali limitate a risorse con tag “prod” e con scadenza dopo 24 ore. Logica: privilegio minimo per le operazioni quotidiane, con un’escalation sicura e verificabile quando necessario.

6. Costruire una pipeline per la fabbrica di progetti

• Usare moduli Terraform per creare progetti con le etichette/tag richiesti (env, owner, cost-center), collegare la fatturazione, associarli allo Shared VPC corretto, creare sink di logging verso un progetto di audit centrale e impostare i budget. Logica: il provisioning coerente e conforme su larga scala elimina le deviazioni manuali e accelera l’onboarding.

7. Centralizzare il logging di audit e le revisioni degli accessi

• Indirizzare i log di Admin Activity e Data Access a BigQuery con CMEK; pianificare query mensili per enumerare le associazioni IAM e confrontarle con l’appartenenza ai gruppi e i dati di ultimo accesso da IAM Recommender. Logica: una traccia di audit duratura e un dimensionamento corretto e continuo degli accessi riducono rischi e costi.

8. Governance dei costi e avvisi

• Abilitare tag ed etichette per l’allocazione dei costi, esportare i dati di fatturazione su BigQuery e impostare budget per Folder e per progetto con notifiche al reparto finanziario e ai team lead. Logica: il chargeback trasparente promuove la responsabilità; gli avvisi precoci limitano la spesa fuori controllo.

9. Workload Identity e automazione senza chiavi

• Per GKE, abilitare Workload Identity; per CI esterne (GitHub), configurare Workload Identity Federation con ambito limitato a repository specifici tramite condizioni. Logica: elimina le chiavi a lunga durata e vincola l’utilizzo ai carichi di lavoro previsti.

10. Processo di eccezione e automazione

• Implementare un flusso di richiesta che crei associazioni IAM condizionali o allentamenti temporanei delle policy con scadenza automatica tramite CI. Logica: dà potere ai team senza sacrificare il controllo; ogni eccezione è limitata nel tempo e verificabile.

Risultati tecnici:

• I team creano nuovi progetti in modalità self-service in meno di 15 minuti con impostazioni predefinite conformi.
• Non sono consentite chiavi di account di servizio gestite dall’utente; l’elevazione dei privilegi per la risposta agli incidenti è limitata nel tempo e basata su tag.
• I costi sono aggregati per team e ambiente, con budget automatizzati e avvisi di anomalia.
• I log di audit e le revisioni degli accessi validano continuamente che i permessi e le policy corrispondano all’intento.

Tutti i domini · Compute →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Google →