Proteggere l’accesso significa rispondere a quattro domande: come l’utente dimostra chi è, che cosa succede se perde quel fattore, da dove può entrare e quanto potere ha chi amministra. Nella console sono quattro sezioni diverse, e conoscerne i percorsi vale metà del dominio.

Password e recupero dell’account

Le policy delle password stanno in Menu > Security > Authentication > Password management. Qui decidi lunghezza minima e massima, entro l’intervallo consentito di 8-100 caratteri, e attivi Enforce strong password, che valuta la robustezza anche rispetto a password comuni e già compromesse. La casella decisiva è Enforce password policy at next sign-in: senza di essa la regola vale solo per le password future, e chi ne ha una debole continua a usarla. La scadenza è disattivata per impostazione predefinita e si può portare a 90 o 180 giorni; togliendo Allow password reuse si impedisce il riciclo. Un limite ricorrente: le policy non si applicano alle password impostate con caricamento massivo, Directory API o strumenti di sincronizzazione. Lo stato di robustezza si legge in Reporting, nei report sugli account.

Il recupero si configura in Menu > Security > Authentication > Account recovery. Possono auto-recuperarsi utenti e amministratori non super admin, purché abbiano un numero di telefono o un indirizzo email di recupero registrato; chi ha la verifica in due passaggi attiva può usare solo l’email di recupero. La funzione non è disponibile con SSO o Password Sync, e i super administrator seguono una procedura dedicata. Quando un account viene compromesso o cessa, rimuovere le informazioni di recupero o sospendere l’utente è parte della bonifica: quei recapiti restano utilizzabili per un certo tempo.

Distribuire la verifica in due passaggi senza chiudere fuori nessuno

Il percorso è Menu > Security > Authentication > 2-step verification e la sequenza consigliata è: comunicare, permettere l’attivazione volontaria, guidare l’iscrizione, misurare l’avanzamento nei report e solo alla fine imporre. L’imposizione ha tre stati — disattivata, attiva subito, oppure attiva a partire da una data scelta, con un ritardo di 24-48 ore prima che diventi effettiva. Per i nuovi assunti si concede un new user enrollment period, da 1 giorno a 6 mesi, mentre il grace period riguarda chi ha perso la chiave di sicurezza e deve ripiegare sui backup code.

I metodi non sono equivalenti: security key e passkey offrono la stessa protezione contro il phishing, il Google prompt e l’app Google Authenticator vengono dopo, i codici via SMS o telefonata sono quelli che Google scoraggia. Il criterio di imposizione riflette la scala: qualsiasi metodo, tutti tranne i codici via SMS o telefonata, oppure solo security key. L’opzione Allow user to trust the device evita la richiesta sui dispositivi noti, ma è sconsigliata se le persone cambiano spesso postazione. Per non bloccare nessuno, la tecnica è mettere chi non si è ancora iscritto in un configuration group dove l’imposizione è disattivata — con un’avvertenza: una policy di 2SV impostata su una unità organizzativa figlia prevale sempre sul gruppo di configurazione.

Applicare le policy a utenti e gruppi

Le unità organizzative restano l’impianto principale e le impostazioni scendono per ereditarietà. Il configuration group copre le eccezioni che non coincidono con l’organigramma: le sue impostazioni prevalgono su quelle dell’unità organizzativa e un utente può appartenere a più gruppi. Non c’è fusione né somma di permessi: vince un gruppo solo, quello più in alto nell’ordine di priorità.

Context-aware access e durata delle sessioni

Il context-aware access aggiunge alla domanda “chi sei” quella “in quali condizioni stai entrando”. Si costruiscono access level basati su intervalli di indirizzi IP, area geografica, sistema operativo e device policy — cifratura del disco, blocco schermo, appartenenza al parco aziendale — poi si assegnano alle app per unità organizzativa o per gruppo. È il meccanismo giusto quando la richiesta è “Drive solo da dispositivi gestiti e cifrati” oppure “niente accesso da fuori rete aziendale”. Due dettagli: sui servizi core la condizione viene rivalutata durante la sessione, mentre per le app SAML il controllo avviene al momento dell’accesso; e servono edizioni specifiche: Enterprise, Frontline ed Education Standard e Plus, Enterprise Essentials Plus, Cloud Identity Premium.

La durata della sessione web si imposta in Menu > Security > Access and data control > Google Session control: il predefinito è 14 giorni, si può accorciare oppure togliere del tutto. Vale per le proprietà web raggiunte da browser, non per le app mobili native di Gmail o Calendar. Alla scadenza compare la pagina di riautenticazione.

Ruoli amministrativi e delega

I ruoli si gestiscono in Menu > Account > Admin roles e si assegnano dalla scheda utente, in Directory > Users, alla voce Admin roles and privileges. Il Super Admin è l’unico che può creare ruoli, gestire altri amministratori, ripristinare utenti eliminati e accettare i termini di servizio: si assegna con parsimonia. Fra i ruoli predefiniti, il Groups Admin governa i gruppi; l’User Management Admin crea, rinomina, elimina utenti e ne resetta le password ma non può toccare account amministrativi né assegnare privilegi; l’Help Desk Admin resetta solo le password degli utenti non amministratori; il Services Admin cura le impostazioni dei servizi. Quando il ruolo lo consente, lo si limita a una o più unità organizzative con Edit accanto ad All organizational units: è così che si delega l’help desk di una sede senza consegnargli il resto del tenant.