Organizational unit, ereditarietà e release track

L’organizational unit (OU) è l’unità primaria per applicare policy differenziate ai servizi Google Workspace. Le impostazioni fluiscono per ereditarietà dalla OU parent verso le child: una child può sovrascrivere (override) un singolo setting, mentre gli altri restano “Inherited”. Spostare un utente in un’altra OU ne cambia immediatamente le policy. Quando serve applicare un’eccezione a un team distribuito su più OU si usano i configuration groups (Google Groups): l’override di gruppo ha precedenza sull’impostazione di OU per i soli membri. Regola pratica: OU per la struttura gerarchica stabile, gruppi per le eccezioni funzionali che tagliano la gerarchia.

Anche il release track si imposta per OU: Scheduled Release ritarda le nuove feature (utile per pilotarle su una OU di test), mentre Rapid Release le distribuisce subito.

Ruoli admin, Marketplace e Drive labels

La delega segue il principio del minimo privilegio. Oltre ai ruoli pre-built (Super Admin, User Management, Help Desk, Services Admin, Groups Admin) si creano custom admin role con privilegi granulari, assegnabili con scope limitato a una OU. Evita di distribuire il Super Admin: per resettare password o gestire utenti basta un ruolo più ristretto.

Per le app di terze parti, in Google Workspace Marketplace puoi consentire solo app allowlisted, oppure limitare l’accesso alle API tramite app access control basato su OAuth scope: le app non classificate restano bloccate finché non le marchi come Trusted o Blocked. Le Drive labels aggiungono metadata di classificazione ai file, sfruttabili da Drive DLP e nelle ricerche.

Configurazione e routing di Gmail

Il routing governa come la posta entra ed esce. Con lo split delivery una parte delle caselle vive su Google e un’altra su un server esterno, instradando per dominio o utente; il mail host / smart host definisce il server a cui inoltrare la posta in uscita. Le content compliance rule scansionano corpo e header e applicano azioni (reject, quarantine, modifica header, reroute) in base a pattern o dizionari: sono lo strumento per la moderazione dei contenuti. L’email delegation, configurabile per OU, permette a un utente di accedere alla casella di un collega senza condividerne la password.

Per l’accesso end-user scegli cosa abilitare per OU: il client web, POP/IMAP, oppure GWSMO (Google Workspace Sync for Microsoft Outlook) per chi resta su Outlook. Per ritenzione ed eDiscovery si usa Vault (retention e legal hold), non un backup: Vault non ripristina dati cancellati oltre la retention.

Spam control e sicurezza inbound

Lo spam control combina più leve. Approved senders / allowlist riducono i falsi positivi per mittenti fidati; la denylist blocca mittenti indesiderati. L’inbound gateway dichiara che la posta transita prima da un gateway esterno (es. un filtro anti-spam di terze parti), così Gmail legge correttamente l’IP originale e non tratta il gateway come mittente. L’IP allowlist fa bypassare il filtro spam agli IP indicati: da usare con cautela perché disattiva controlli. A monte, SPF/DKIM/DMARC e MTA-STS proteggono il dominio; l’admin quarantine trattiene per revisione manuale i messaggi che violano le rule. Il passing score dell’esame è 700/1000.

Trappole tipiche d’esame

  • Feature da abilitare a un team sparso su più OU → configuration group: l’override di Google Groups vince sulle OU per i soli membri; creare una nuova OU rompe la gerarchia organizzativa.
  • Reset password/gestione utenti senza pieni poteri → custom role scoped a OU: assegnare Super Admin è overprivilege; serve un ruolo granulare limitato.
  • Mettere l’anti-spam di terze parti davanti a Gmail → inbound gateway: l’IP allowlist bypassa il filtro e non preserva l’IP originale; l’inbound gateway sì.
  • “Ripristinare” email cancellate → non è Vault: Vault serve retention/legal hold/eDiscovery, non recupera dati eliminati oltre la retention; valuta policy di retention preventive.
  • Alcune caselle su Google, altre su server legacy → split delivery: il dual delivery consegna a entrambi i sistemi (duplica), lo split delivery instrada selettivamente.
  • Testare i nuovi rilasci prima del rollout generale → Scheduled Release su OU pilota: Rapid Release non dà finestra di test.