Google ACE: Gerarchia delle risorse, IAM e amministrazione della fatturazione — Guida allo studio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Panoramica

La gerarchia delle risorse, la gestione di identità e accessi (IAM) e l’amministrazione della fatturazione costituiscono il piano di controllo (control plane) delle operazioni su Google Cloud. Una progettazione resiliente inizia con una gerarchia chiara (organizzazione, cartelle, progetti) per definire l’ambito delle policy e delle responsabilità; applica il principio del privilegio minimo (least-privilege) in IAM con un’amministrazione centrata sui gruppi e credenziali a breve durata per i workload; utilizza budget, esportazioni ed etichette per l’attribuzione dei costi; e impone la governance con le policy dell’organizzazione e un audit logging completo. L’eccellenza operativa si ottiene standardizzando l’ereditarietà, centralizzando la fatturazione e i log, e utilizzando l’impersonificazione del service account anziché chiavi a lunga durata. Questa sezione descrive i costrutti fondamentali, il loro uso previsto e le modalità di fallimento comuni da evitare.

Gerarchia delle Risorse e Modello di Identità

Gerarchia delle risorse
- Organizzazione: Nodo radice, creato con Cloud Identity o Google Workspace. Possiede le policy globali (IAM, policy dell’organizzazione, tag).
- Cartelle (Folders): Raggruppamento opzionale per dipartimenti, ambienti (es. dev, prod) o applicazioni. Utili per l’amministrazione delegata e per definire l’ambito delle policy.
- Progetti: Confine amministrativo per risorse, API, quote, IAM e associazione alla fatturazione. La maggior parte delle risorse Google Cloud sono figlie dei progetti.
- Ereditarietà: Le policy IAM e le policy dell’organizzazione vengono ereditate dall’alto verso il basso (top-down). Le negazioni (deny) e i vincoli ai livelli superiori hanno la precedenza. Pianificare il posizionamento (organizzazione → cartelle → progetti) per minimizzare le eccezioni e le necessità di break-glass.
Principal
- Account Google (utenti), gruppi Google, service account e identità esterne tramite Workload Identity Federation.
- I gruppi Google dovrebbero essere la destinazione principale dei binding per l’accesso umano, al fine di semplificare le modifiche al ciclo di vita e le revisioni.
- I service account rappresentano applicazioni o servizi; preferire l’identità del workload (workload identity) alle chiavi.
Identità dei workload
- In Google Cloud: GCE/GAE/Cloud Run/GKE utilizzano il server di metadati per emettere token a breve durata per il service account associato.
- Al di fuori di Google Cloud: Workload Identity Federation mappa le identità esterne (OIDC/SAML/AWS) a service account senza utilizzare chiavi statiche.
Compromessi di progettazione e modalità di fallimento
- La proliferazione di progetti senza una struttura di cartelle causa duplicazione e deviazione (drift) delle policy.
- Assegnare ruoli direttamente agli utenti aumenta il lavoro manuale ripetitivo (toil); preferire i binding basati su gruppi.
- L’uso del service account di default di Compute Engine con permessi ampi aumenta il rischio; creare service account con privilegi minimi (least-privileged) per ogni workload.
- Posizionare un progetto nella cartella sbagliata causa l’ereditarietà di policy errate; usare i tag o spostare i progetti con attenzione tramite un processo di change control.

Ruoli IAM e Progettazione delle Policy

Tipi di ruoli
- Ruoli di base (Viewer, Editor, Owner): Ampi, legacy. Da evitare, se non per scenari di break-glass strettamente controllati.
- Ruoli predefiniti: Curati per ogni servizio; da preferire per la maggior parte dei casi d’uso.
- Ruoli personalizzati: Aggregazione di permessi con ambito a livello di organizzazione o progetto per esigenze specifiche.
- Ruoli condizionali: Le IAM Conditions (CEL) aggiungono contesto come il nome della risorsa, la cartella, i tag o l’orario; utilizzare per limitare ruoli potenti.
Principi delle policy
- Privilegio minimo (Least privilege): Concedere solo il ruolo minimo nell’ambito più ristretto possibile (risorsa/progetto/cartella).
- Separazione dei compiti (Separation of duties): Suddividere le responsabilità (es. amministratore di rete vs. amministratore della sicurezza vs. amministratore della fatturazione). Non associare le azioni di deploy e di approvazione a un unico principal.
- Consapevolezza dell’ereditarietà: Un binding a livello di organizzazione/cartella influisce su tutti i discendenti; documentare il raggio d’impatto (blast radius) previsto prima di applicarlo.
Policy di negazione (Deny)
- IAM Deny blocca esplicitamente i permessi anche se concessi altrove; da usare per implementare misure di protezione (guardrail) (es. negare iam.serviceAccountKeys.create).
- La negazione (Deny) ha la precedenza; assicurarsi di avere processi documentati di break-glass con eccezioni a tempo.
Esempi
- Copiare un ruolo personalizzato da dev a prod:

undefined

Concedere a un gruppo i permessi di amministratore SSH con OS Login:

undefined

Modalità di fallimento
- Il ruolo Editor concesso a livello di organizzazione o cartella si propaga involontariamente a tutti i progetti.
- I ruoli condizionali con condizioni troppo restrittive possono interrompere le automazioni in modo silente; testare con il Policy Troubleshooter prima del rollout.
- I ruoli personalizzati non vengono aggiornati con i nuovi permessi; revisionarli periodicamente.

Fatturazione e Amministrazione dei Costi

Account di fatturazione e associazione
- Un progetto deve essere collegato a un solo account di fatturazione per poter utilizzare servizi fatturabili.
- Ruoli: Il Billing Account Administrator gestisce l’account e i metodi di pagamento; il Billing Account User collega i progetti; il Project Billing Manager gestisce il collegamento di un progetto alla fatturazione.
- Centralizzare su un account di fatturazione aziendale; migrare i progetti aggiornando la loro associazione di fatturazione.
Budget, avvisi e attribuzione
- I budget generano avvisi, non limiti di spesa (spend caps). Utilizzare la correzione programmatica (programmatic remediation) con Pub/Sub e Cloud Functions/Cloud Run se è necessario imporre un blocco.
- Esportare i dati di fatturazione su BigQuery per analisi dei costi e previsioni giornaliere/mensili; combinarli con le etichette (label) e i tag delle risorse per l’attribuzione.
- Etichette (Labels) e tag: Standardizzare le chiavi (es. cost_center, env, app). La mancanza di etichette riduce l’accuratezza dell’attribuzione.
Analisi dei costi
- Usare l’esportazione verso BigQuery per calcolare previsioni continue (rolling forecast) per SKU/servizio con SQL. Eseguire join con i metadati delle risorse (es. etichette di GCE) per una reportistica granulare.
- Per l’analisi multi-progetto, aggregare i dati da tutte le esportazioni dei progetti o esportare tutto verso un unico dataset centralizzato.
Errori comuni
- Budget non configurati per i nuovi progetti; stabilire una policy per creare automaticamente i budget alla creazione di un progetto.
- L’assenza di un’esportazione verso BigQuery limita la visione storica; abilitarla il prima possibile per costruire uno storico.
- L’uso di carte di credito personali sui progetti frammenta la responsabilità; consolidare tutto sotto l’account di fatturazione aziendale con profili di pagamento e IAM appropriati.
- Le anomalie di costo nei progetti di servizi condivisi richiedono l’uso di tag e una policy di riaddebito (cross-charging).

Autenticazione e Pattern di Accesso per Workload Sicuri

Impersonificazione dell’account di servizio
- Preferire l’impersonificazione rispetto alle chiavi. Assegnare il ruolo roles/iam.serviceAccountTokenCreator a un’identità chiamante; il chiamante ottiene token di breve durata per agire come l’account di servizio.
- Esempio: gcloud auth print-access-token
  –impersonate-service-account sa-deployer@PROJECT_ID.iam.gserviceaccount.com
Chiavi e rotazione
- Evitare le chiavi gestite dall’utente. Se necessario, archiviarle in Secret Manager, ruotarle almeno ogni 90 giorni, monitorarne l’utilizzo e limitarle con VPC Service Controls e CMEK.
- Applicare vincoli per bloccare la creazione di chiavi: constraints/iam.disableServiceAccountKeyCreation = true
OS Login e SSH
- Utilizzare OS Login con ruoli IAM basati su gruppi (compute.osLogin, compute.osAdminLogin). Ogni utente carica la propria chiave SSH pubblica nel proprio account Google per un accesso attribuibile. Audit tramite i log di Admin Activity e Data Access.
- Evitare di includere chiavi SSH condivise nelle immagini.
Workload Identity Federation
- Per ambienti on-premise o altri cloud, configurare la federazione delle identità per concedere l’accesso a Google Cloud senza creare chiavi, riducendo il rischio di esfiltrazione dei dati.
Modalità di fallimento e mitigazioni
- L’archiviazione di chiavi in repository o variabili CI/CD porta a compromissioni; passare all’impersonificazione o alla federazione.
- Gli account di servizio predefiniti con ruoli ampi sono rischiosi; limitarli con il vincolo constraints/iam.allowedPolicyMemberDomains e rimuovere i ruoli primitivi.
- La mancanza di scope su istanze GCE legacy può bloccare l’accesso alle API; preferire l’uso di ruoli IAM per singola API insieme alle credenziali predefinite dell’applicazione (default application credentials).

Governance, policy dell’organizzazione, audit e risoluzione dei problemi

Policy e vincoli dell’organizzazione
- Applicare guardrail utilizzando i vincoli: non consentire IP esterni sulle VM, limitare le regioni, impedire la creazione di chiavi, limitare i servizi consentiti, richiedere l’accesso uniforme a livello di bucket, limitare la condivisione di domini.
- Indirizzare tramite la gerarchia delle risorse e perfezionare con i tag per eccezioni specifiche dell’ambiente.
Cloud Identity e ciclo di vita
- Cloud Identity fornisce la directory degli utenti, il SSO e i ruoli amministrativi. Delegare in modo granulare (ad es. Group Admin, User Management Admin) e automatizzare i flussi di lavoro di joiner-mover-leaver per aggiornare l’appartenenza ai gruppi e gli accessi.
- Utilizzare Access Approvals e Access Transparency per gli ambienti sensibili.
Logging di audit
- I log di Admin Activity e System Event sono sempre attivi; i log di Data Access devono essere abilitati esplicitamente e possono comportare costi.
- Centralizzare instradando i sink aggregati da cartelle/organizzazione a un progetto di sicurezza. Proteggere con CMEK e accesso limitato.
- Monitorare i log di Policy Denied per rilevare conflitti con le policy dell’organizzazione.
Toolkit per la risoluzione dei problemi multi-progetto
- Policy Troubleshooter: Diagnostica perché un accesso è consentito o negato, considerando le policy IAM e di negazione effettive.
- Cloud Asset Inventory: Esegue query sui binding IAM e sulla cronologia delle policy a livello di organizzazione/cartelle/progetti. Esempio:

undefined

Logs Explorer: Filtra per principal, metodo e risorsa per tracciare le azioni tra i progetti.
Configurazioni di gcloud per il cambio di contesto dell’operatore:

undefined

Modalità di fallimento comuni: policy dell’organizzazione in conflitto che bloccano i deployment, mancanza di log di Data Access che ostacolano le indagini e permessi IAM concessi allo scope sbagliato. Stabilire runbook e anteprime pre-modifica per ridurre il MTTR degli incidenti.

Scenario pratico

Aurelia Retail consolida più team e progetti dopo un’acquisizione. Deve centralizzare la fatturazione, applicare un’amministrazione IAM e SSH coerente su centinaia di VM di Compute Engine e stabilire una governance con il minimo impatto operativo.

Creare un account di fatturazione aziendale e collegare i progetti

Motivazione: Un unico account di fatturazione centralizza metodi di pagamento, crediti e budget. Concedere il ruolo Billing Account User a un gruppo di migrazione dei progetti e Project Billing Manager ai team lead per ricollegare i progetti senza concedere privilegi eccessivi.
Azione: Nella console, creare l’account di fatturazione. Per ogni progetto, aggiornare la sua associazione di fatturazione. Abilitare immediatamente l’esportazione della fatturazione verso BigQuery in un progetto di analisi centralizzato.

Standardizzare la gerarchia delle risorse con cartelle e tag

Motivazione: Posizionare i progetti in cartelle di ambiente (prod, nonprod) supporta l’ereditarietà dei guardrail e le eccezioni mirate. I tag consentono di applicare le policy dell’organizzazione in modo granulare senza duplicare le gerarchie di cartelle.
Azione: Creare cartelle per prod e nonprod; spostare i progetti di conseguenza. Definire i tag env=prod|nonprod e gli identificatori delle applicazioni.

Implementare IAM basato su gruppi con il principio del privilegio minimo e la separazione dei compiti

Motivazione: I gruppi semplificano il ciclo di vita e l’audit. Suddividere i ruoli tra addetti al deployment, alla sicurezza e amministratori di rete riduce il raggio d’impatto (blast radius).
Azione: Creare gruppi Google per app-operators, net-admins, sec-admins e billing-managers. Associare i ruoli predefiniti a livello di cartella/progetto secondo necessità; evitare i ruoli di base (basic roles).

Applicare l’amministrazione SSH basata su OS Login

Motivazione: Le chiavi SSH individuali associate agli account utente forniscono un accesso attribuibile e revocabile. I ruoli di OS Login gestiscono gli account Linux tramite IAM, eliminando le chiavi condivise.
Azione: In ogni progetto, abilitare i metadati di OS Login. Concedere il ruolo compute.osAdminLogin al gruppo ops-admins. Esempio:

undefined

Sostituire le chiavi degli account di servizio con l’impersonificazione

Motivazione: Le credenziali a breve durata mitigano il rischio di esfiltrazione delle chiavi e semplificano la rotazione. I log di audit registrano chi ha impersonificato chi, migliorando la tracciabilità.
Azione: Concedere il ruolo roles/iam.serviceAccountTokenCreator alle identità dei runner CI/CD sugli account di servizio dei carichi di lavoro. Rimuovere le chiavi gestite dall’utente e applicare una policy dell’organizzazione per bloccare la creazione di nuove chiavi.

Applicare le policy dell’organizzazione come guardrail

Motivazione: I vincoli impediscono configurazioni rischiose in tutti i progetti, consentendo al contempo eccezioni basate su tag dove giustificato.
Azione: Applicare vincoli per non consentire IP esterni in produzione, limitare le regioni a quelle approvate e disabilitare la creazione di chiavi per gli account di servizio. Usare i tag per consentire eccezioni per progetti specifici con approvazioni documentate.

Stabilire una governance dei costi

Motivazione: I budget avvisano i proprietari prima che si superi la spesa; l’esportazione su BigQuery consente l’attribuzione e la previsione. Etichette e tag mappano la spesa delle risorse ai centri di costo.
Azione: Creare budget per cartella e per le applicazioni principali con notifiche Pub/Sub. Applicare policy sulle etichette tramite i template di deployment e la validazione delle policy nella CI.

Centralizzare l’audit e accelerare la risoluzione dei problemi

Motivazione: La centralizzazione dei log e l’inventario degli asset a livello di organizzazione accelerano le indagini e la reportistica di conformità.
Azione: Creare sink aggregati verso un progetto di sicurezza con bucket protetti da CMEK. Abilitare i log di Data Access per i servizi critici (Cloud Storage, BigQuery). Usare Cloud Asset Inventory per scansionare regolarmente i binding IAM. Formare gli operatori sull’uso di Policy Troubleshooter in caso di fallimento dell’accesso e di Logs Explorer per tracciare Admin Activity/Data Access.

Rendere operative le modifiche con anteprime e rollout graduale

Motivazione: Validare gli effetti delle policy IAM e dell’organizzazione prima di applicarle riduce le interruzioni di servizio.
Azione: Testare le policy IAM e dell’organizzazione prima in ambiente nonprod. Utilizzare esecuzioni di prova (dry-run) e simulazioni di policy dove disponibili. Per l’automazione del deployment, implementare canary release e piani di ripristino (backout).

Questo approccio produce una fatturazione e una visione dei costi centralizzate, un’amministrazione SSH attribuibile tramite OS Login, un IAM basato sul principio del privilegio minimo con impersonificazione, controlli preventivi robusti tramite le policy dell’organizzazione e funzionalità di audit e risoluzione dei problemi solide nel nuovo ambiente multi-progetto.

Tutti i domini · Compute Engine e operazioni sulle macchine virtuali →

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