Provisioning e deprovisioning degli account

Il ciclo di vita di un utente Google Workspace copre le operazioni CRUD sull’oggetto account. In fase di provisioning hai tre approcci: creazione individuale dalla Admin console (adatta a pochi account eccezionali), creazione bulk via upload CSV (decine o centinaia di utenti one-shot), e provisioning automatizzato tramite Admin SDK / Directory API o GCDS (flusso continuo agganciato a una source of truth). Il criterio di scelta è il volume e la ripetitività: se la sorgente è un HR system o un directory server, l’automazione è l’unica opzione sostenibile.

Ogni utente vive dentro una organizational unit (OU): la OU determina quali policy e servizi l’account eredita. Le operazioni di editing più frequenti sono rename (cambio nome/cognome, con eventuale cambio di primary email), reset password, forzatura del cambio password al prossimo login, e gestione degli alias (indirizzi aggiuntivi che consegnano alla stessa mailbox, senza creare un secondo account).

Il deprovisioning (offboarding) ha tre stati distinti da non confondere: suspend blocca l’accesso ma conserva dati e licenza (reversibile, ideale per assenze o indagini); delete rimuove l’account (recuperabile entro circa 20 giorni con recover, dopodiché è definitivo); tra i due va sempre gestito il trasferimento della ownership dei dati (Drive, Calendar) verso un altro utente prima della cancellazione, altrimenti i file di proprietà dell’utente cancellato vengono persi.

Ruoli amministrativi: default e custom

Google Workspace offre ruoli admin predefiniti (Super Admin, User Management Admin, Groups Admin, Help Desk Admin, Services Admin, ecc.) e la possibilità di creare custom admin roles combinando privilegi granulari. Il principio guida è il least privilege: non assegnare Super Admin quando basta un ruolo delegato. I ruoli custom si possono inoltre scope-are per OU o per gruppo, così un delegato amministra solo la propria filiale o dipartimento senza toccare l’intero tenant. La revoca degli accessi fuori policy (privilegi non più giustificati, admin dormienti) va effettuata rimuovendo l’assegnazione del ruolo, non sospendendo l’account: la sospensione blocca l’utente ma non ridimensiona i suoi privilegi in caso di riattivazione.

Google Groups nel lifecycle

I Google Groups sono lo strumento per gestire accessi e distribuzione a livello di collezione anziché per singolo utente. Distingui i tipi: gruppi come mailing list, security groups (usati per assegnare permessi e policy), dynamic groups (membership calcolata su attributi/OU, si aggiorna da sola), e gruppi mappati dall’identità esterna. Assegnare licenze, condivisioni e Context-Aware Access a un gruppo invece che a singoli utenti riduce drasticamente l’onere di manutenzione durante join e leave.

Google Cloud Directory Sync (GCDS)

GCDS sincronizza gli oggetti identità DA un server LDAP o Active Directory VERSO Google Workspace. È fondamentale ricordare la direzione one-way: Google è sempre la destinazione, mai la sorgente; GCDS non riscrive nulla nell’AD on-prem. Sincronizza utenti, gruppi, OU, alias, contatti condivisi e alcuni attributi di profilo. Opera per confronto e riconciliazione: legge lo stato LDAP, lo confronta con Google e applica creazioni/aggiornamenti/eliminazioni secondo le regole configurate. Prevede una simulation mode (dry-run) e produce log di audit per verificare gli effetti prima di applicarli. GCDS non è un IdP e non gestisce l’autenticazione runtime (quella è compito di SSO/SAML); si limita al provisioning dell’anagrafica.

Trappole tipiche d’esame

  • Cancellare un utente senza perdere i suoi file → transfer ownership prima del delete: in offboarding trasferisci Drive/Calendar a un altro utente, poi elimina; il recover funziona solo entro la finestra di circa 20 giorni.
  • “L’utente è in aspettativa, blocca l’accesso ma conserva tutto” → suspend, non delete: suspend è reversibile e mantiene dati e licenza; delete no.
  • GCDS deve aggiornare l’Active Directory dai dati Google → impossibile: GCDS è one-way verso Google; per il flusso inverso serve un altro strumento, non GCDS.
  • “Recuperare email/file cancellati definitivamente” → non è compito di Vault: Vault fa retention/legal hold/eDiscovery, non è un backup che ripristina dati eliminati oltre la finestra di recover.
  • Delegare l’help desk senza dare pieni poteri → custom role con scope su OU/gruppo: assegna privilegi minimi e limitane l’ambito, non concedere Super Admin.
  • Revocare privilegi a un admin fuori policy → rimuovi il ruolo, non sospendere l’account: la sospensione blocca il login ma i privilegi restano pronti a riattivarsi; togli l’assegnazione del ruolo.