L'eterno problema di GCP: gli utenti non gestiti

Ripartiamo dall'inizio del primo scenario. La sua azienda ha le email su un server Exchange on-premise, su Microsoft 365 o magari su un servizio email di GoDaddy, ma ora nasce l'esigenza di gestire tutti gli account Google in un unico punto, per ottenere maggiore controllo e visibilità.

Magari anche per usare account aziendali su Google Analytics o YouTube e adottare l'SSO, in modo che, quando un utente viene disabilitato o eliminato dal suo sistema, sparisca anche da Google. Decide così di registrare il dominio aziendale con un account di abbonamento Google Corporate o Managed, come Google Workspace (in precedenza noto come G-Suite) o CloudIdentity.

Verifica il possesso del dominio e inizia a usare l'abbonamento. Vuole creare [email protected], ma quando prova il sistema le segnala che l'email è già in uso. Si ricordi della prima regola: può esserci un solo indirizzo email.

Risultato: ora ha un problema di account utente non gestiti duplicati\ in conflitto.

Ora ipotizziamo che lei sia il super admin dell'azienda per un account Google Workspace completamente gestito, e che un suo amministratore crei una regola di routing predefinita o una recipient address map dalla console di amministrazione Google dell'abbonamento Google Workspace, per inoltrare qualsiasi email diretta a [email protected] (indirizzo email privato).

Lo stesso amministratore va poi alla pagina di registrazione di un account utente non gestito e registra l'indirizzo email. L'email di verifica arriverà nella casella di posta aziendale, dove sarà possibile convalidarla.

A questo punto si ritrova con un account utente Google non gestito che, in teoria, può iscriversi a Google Analytics, creare canali YouTube con il dominio aziendale e persino ottenere accessi non autorizzati a GCP. Per peggiorare le cose, come admin non sa nulla di questo utente né può reimpostarne la password e così via.

Al momento Google non blocca la creazione di account personali o consumer tramite un suffisso di dominio registrato. Inoltre non esiste alcuna funzionalità nella console di amministrazione che permetta di impedirlo. Se contatta il supporto Google chiedendo esplicitamente di disattivare questa opzione per il suo account G-Suite Corporate o Google Workspace, non potrà farlo e non ci proverà.

La soluzione

Se ha un account Google Workspace (G-Suite), può creare un indirizzo catch-all seguendo questo link.

Un indirizzo catch-all garantisce che i messaggi inviati a un indirizzo email errato vengano comunque ricevuti da qualcuno all'interno dell'organizzazione, che potrà esaminarli e decidere come procedere. È utile per individuare gli utenti che provano ad attivare un account utente Google non gestito. Se però è un admin a impostare una regola di routing, per esempio con una "recipient address map", il catch-all non sarà d'aiuto.

La soluzione migliore, valida come workaround per qualsiasi sistema di posta, è semplicemente interrompere la comunicazione tra il processo di verifica e l'utente. Crei una regola di conformità dei contenuti con le seguenti condizioni (devono essere soddisfatte tutte — AND, non OR):

Direzione in entrata AND corpo del messaggio che corrisponde alla regex `^[0–9]{6}$` AND corpo del messaggio che contiene il testo \"Verify this email is yours\" AND oggetto che contiene il testo \"Verify your email address\" AND intestazione del mittente che contiene il testo \"[email protected]\".

Finché Google non modifica questi metadati, può stare tranquillo. Le consiglio inoltre di non rifiutare le email di verifica: cambi il destinatario impostando un admin, come per l'indirizzo catch-all, in modo da poterle monitorare ed evitare di scartare messaggi che soddisfano i criteri ma non rientrano in questo scenario.

Se necessario, può aggiungere ulteriori protezioni. In GCP è possibile impostare una policy di restrizione della condivisione per dominio: clicchi qui per scoprire come fare.

In questo modo gli utenti esterni al dominio non potranno essere autorizzati in IAM per i progetti dell'organizzazione. Tenga presente che la policy non si applica retroattivamente e che non potrà aggiungere utenti gmail.com ai suoi progetti: solo gli utenti gestiti all'interno del suo account Google Workspace o CloudIdentity potranno ricevere autorizzazioni IAM.

Come gestire gli account non gestiti

Innanzitutto, per eseguire le azioni che seguono dovrà disporre del ruolo di \"Super Admin\" nel suo account di abbonamento Google Workspace o CloudIdentity. Una volta effettuato l'accesso alla console di amministrazione, potrà aprire il \" Transfer tool for unmanaged users\".

Oppure dalla sezione \"Users\" cliccando su \"More\":

Aprendo lo strumento di trasferimento, potrebbe vedere l'elenco di tutti gli utenti non gestiti con account utente duplicati e in conflitto. Per ciascuno di essi può inviare un invito a trasferire l'account non gestito alla sua azienda. Una volta inviato l'invito, spetta alla persona (sempre che lo riceva davvero) accettare o rifiutare la richiesta di trasferimento.

Una volta accettato, lo username viene assegnato all'account aziendale e comparirà nell'elenco utenti. L'utente potrà continuare ad autenticarsi come prima, con la differenza che l'account sarà soggetto alle policy aziendali (2FA, servizi consentiti o vietati, timeout di sessione ecc.). Se l'utente aveva accesso a progetti GCP, potrà continuare a usarli.

In caso di mancata risposta o di rifiuto, può prendere alcuni provvedimenti (creare regole di routing che inoltrino i messaggi destinati a questi account utente alla casella di un admin), inviare nuovamente l'invito e accettarlo a nome dell'utente (lei è il proprietario del dominio e i record MX puntano all'account aziendale).

Le suggerisco di procedere con cautela e di provare a rintracciare il dipendente: magari si tratta di un ex collaboratore che ha semplicemente dimenticato di chiudere l'account o non ne era a conoscenza. In alternativa, può procedere direttamente con la creazione dell'utente.

Quando crea l'utente dalla console di amministrazione, le verrà mostrata una schermata che le chiederà se inviare un \"transfer invite\" all'utente o creare comunque l'utenza: quest'ultima opzione genererà una nuova identità gestita all'interno dell'abbonamento aziendale e rinominerà l'utente originale in qualcosa come \"username%[email protected]\".

Quando l'utente vorrà usare il proprio account per accedere a un servizio Google, gli verrà proposto di scegliere tra \"Work account\" — l'account che lei ha creato — e \"Personal account\" — ossia \"username%[email protected]\".

I dati dell'utente resteranno sull'account originale, mentre tutti i dati correlati come Google Analytics o canali YouTube rimarranno legati all'account personale. Quei dati non saranno accessibili dal nuovo username creato.

Tenga presente che l'API viene utilizzata anche quando si usa GCDS (Google Cloud Directory Sync) da MS-AD on-premise verso Google, l'auto-provisioning di utenti da MS-AAD (Microsoft Azure Active Directory) o soluzioni di terze parti come Okta. L'API non distingue tra account personali, consumer e non gestiti: si limita a creare automaticamente gli utenti, e l'utente personale non gestito viene rinominato senza che venga chiesto all'admin di effettuare prima il trasferimento.