Il modello IAM e la resource hierarchy

Cloud IAM risponde alla domanda “chi (identity) può fare cosa (role) su quale risorsa”, e non va mai ragionato sulla singola risorsa isolata. Le policy di allow si applicano lungo la resource hierarchy (organization → folder → project → resource) e sono ereditate verso il basso: un ruolo concesso a livello di organization vale su ogni progetto sottostante. Questa ereditarietà è la chiave per capire perché un utente “ha troppo”: spesso il binding non è sul progetto, ma su una folder o sull’organization. Il principio guida è il least privilege: concedere il minimo indispensabile, preferibilmente a gruppi anziché a singoli account, e sfruttare la gerarchia per applicare controlli in modo scalabile invece di ripeterli progetto per progetto.

Tipi di ruolo: basic, predefined, custom

I basic roles (Owner, Editor, Viewer) sono legacy e troppo ampi: Owner e Editor concedono migliaia di permessi cross-service e violano quasi sempre il least privilege in produzione. I predefined roles sono curati e mantenuti da Google, granulari per servizio (es. un ruolo di sola lettura su uno storage bucket) e sono la scelta di default nella maggior parte degli scenari. I custom roles servono quando nessun predefined combacia: si compone un set esatto di permessi, ma il costo è operativo (li mantieni tu, e non si aggiornano da soli quando Google aggiunge nuovi permessi ai servizi). Regola d’esame: parti dai predefined, passa ai custom solo se devi ritagliare permessi che nessun predefined offre.

Deny policy e IAM Conditions

Le IAM deny policy definiscono permessi esplicitamente negati: vengono valutate prima delle allow e un explicit deny vince sempre su qualsiasi allow, anche su Owner. Sono lo strumento per imporre un divieto trasversale (es. “nessuno può cancellare risorse di produzione”) indipendentemente dai ruoli concessi altrove. Le IAM Conditions aggiungono condizioni ai binding di allow (o alle deny) basate su attributi: tipo/nome della risorsa, data e ora (accesso temporaneo), attributi della richiesta. Servono per un controllo fine — es. concedere un ruolo solo su risorse con un certo prefisso, o solo entro una finestra temporale — senza creare custom role dedicati.

Organization policy come guardrail

Le organization policy (Org Policy Service) sono guardrail preventivi applicati lungo la resource hierarchy tramite constraint (es. limitare le region consentite, bloccare service account key esterne, restringere il domain sharing). Punto critico e ricorrente: le org policy restringono, non concedono mai accessi. Non sostituiscono IAM — definiscono cosa è permesso configurare, mentre IAM definisce chi può agire. Ereditano verso il basso e possono essere ereditate o sovrascritte a livello di folder/project secondo le regole di merge del constraint. Insieme a IAM realizzano la difesa in profondità: IAM per l’autorizzazione, Org Policy per i limiti strutturali.

Policy Intelligence

La suite Policy Intelligence aiuta a ridurre i permessi eccessivi su scala. Lo IAM Recommender analizza l’uso reale (tramite i log) e suggerisce di sostituire ruoli sovradimensionati con ruoli meno privilegiati o custom. Il Policy Analyzer risponde a “chi ha accesso a cosa” interrogando i binding lungo la gerarchia. Il Policy Troubleshooter spiega perché un principal ha o non ha un permesso su una risorsa, ricostruendo il percorso di allow/deny e le condizioni valutate — è lo strumento da citare quando lo scenario è “l’accesso è negato/concesso inaspettatamente, perché?”.

Trappole tipiche d’esame

  • Un utente ha troppi permessi ma il binding non è sul progetto → resource hierarchy: controlla i binding ereditati da folder e organization, non solo quelli del singolo progetto.
  • Serve vietare un’azione a tutti, Owner inclusi → IAM deny policy: un explicit deny vince su qualsiasi allow; i basic role non lo bypassano.
  • “Impedisci la creazione di risorse fuori dalle region UE” → organization policy: è un guardrail preventivo, non un ruolo IAM; ricorda che restringe ma non concede accesso.
  • Accesso temporaneo o limitato a risorse con un certo prefisso → IAM Conditions: condizioni su tempo/attributo, non un custom role dedicato.
  • “Ridurre permessi eccessivi già concessi” → IAM Recommender: basato sull’uso reale; Policy Analyzer serve invece a mappare chi-ha-cosa.
  • “Perché questo accesso è negato/concesso?” → Policy Troubleshooter: diagnostica il singolo binding; non confonderlo con Analyzer (inventario) o Recommender (right-sizing).