Best practice per l'utilizzo di Google Gruppi

Questo documento descrive alcune best practice per l'utilizzo di Google Gruppi per gestire l'accesso alle risorse di Google Cloud con Identity and Access Management (IAM).

Tipi di gruppi

I tipi di gruppi elencati qui sono un modo per pensare, utilizzare e gestire Gruppi Google. Questi tipi di gruppi non sono impostati da nessun attributo del gruppo Google. Tuttavia, l'utilizzo di questi tipi di gruppi nel tuo approccio complessivo alla gestione dei gruppi Google può aiutarti a evitare alcuni errori comuni di sicurezza.

Questo documento utilizza i seguenti tipi di gruppi:

  • Gruppi organizzativi

    I gruppi di organizzazioni rappresentano sottoinsiemi della struttura di un'organizzazione e solitamente provengono dai dati delle risorse umane. Potrebbero essere basati su reparto, struttura di generazione di report, posizione geografica o altri raggruppamenti organizzativi.

    I membri di un gruppo organizzativo cambiano quando un dipendente entra nell'organizzazione, si trasferisce in un altro reparto o lascia l'organizzazione.

    La struttura complessiva dei gruppi organizzativi può cambiare quando l'attività si riorganizza. Una riorganizzazione potrebbe comportare la creazione di nuovi gruppi o il ritiro di quelli esistenti.

    Alcuni esempi di gruppi di organizzazioni includono org.marketing-fte, org.finance-all, org.msmith-reports, org.apac-all e org.summer-interns.

    I gruppi di organizzazioni vengono in genere utilizzati per le comunicazioni via email.

  • Gruppi di collaborazione

    I gruppi di collaborazione rappresentano gruppi di lavoro, membri di progetti o utenti che vogliono collaborare a un progetto o discutere di un argomento specifico.

    La struttura dei gruppi di collaborazione non è collegata a nessuna struttura organizzativa. Spesso vengono creati in modo autonomo e ad hoc.

    L'appartenenza ai gruppi di collaborazione può essere illimitata, consentendo a chiunque nell'organizzazione di partecipare. In alternativa, un gruppo di collaborazione può essere autogestito, il che significa che alcuni membri possono decidere chi altro includere nel gruppo.

    Alcuni esempi di gruppi di collaborazione includono collab.security-discuss e collab.website-relaunch.

    I gruppi di collaborazione vengono in genere utilizzati per le comunicazioni via email.

  • Gruppi di accesso

    I gruppi di accesso vengono utilizzati esclusivamente per fornire l'accesso. Rappresentano le funzioni lavorative e vengono utilizzati per semplificare l'assegnazione dei ruoli necessari per svolgere queste funzioni. Anziché concedere i ruoli ai singoli principali, li concedi al gruppo e poi gestisci l'appartenenza al gruppo.

    La struttura dei gruppi di accesso è influenzata dalla struttura delle risorse o dei workload della tua organizzazione. Il deployment di una nuova risorsa o workload potrebbe richiedere la creazione di nuovi gruppi di accesso.

    L'appartenenza ai gruppi di accesso è generalmente controllata da uno o più proprietari del gruppo, che invitano gli utenti al gruppo o approvano le richieste di appartenenza al gruppo.

    Alcuni esempi di gruppi di accesso sono access.prod-firewall-admins, access.finance-datamart-viewers e access.billing-dashboard-users.

    I gruppi di accesso vengono utilizzati solo per fornire l'accesso. Non vengono utilizzati per scopi di comunicazione.

  • Gruppi di applicazione

    I gruppi di applicazione sono simili ai gruppi di accesso, tranne per il fatto che vengono utilizzati per applicare i criteri di limitazione dell'accesso anziché per fornire l'accesso.

    La struttura dei gruppi di applicazione è in genere influenzata da una combinazione di requisiti di conformità e struttura organizzativa.

    L'appartenenza a un gruppo di applicazione delle norme viene in genere determinata da un insieme di regole predefinite che esaminano il livello di autorizzazione, la località o il ruolo di un utente nell'organizzazione.

    Alcuni esempi di gruppi di applicazione includono enforcement.users-in-restricted-locations, enforcement.fedramp-low e enforcement.sso-users.

    I gruppi di applicazione vengono utilizzati solo per applicare i criteri di limitazione dell'accesso. Non vengono utilizzati per scopi di comunicazione.

Assegna un nome ai gruppi in base al tipo

Per aiutarti a seguire le best practice nel resto di questo documento, utilizza nomi di gruppo che ti consentano di determinare il tipo di gruppo dal nome. Puoi utilizzare una convenzione di denominazione o domini secondari.

Convenzione di denominazione

Ecco un esempio di convenzione di denominazione per rendere visibile il tipo di gruppo:

  • Gruppi di organizzazioni: org.GROUP_NAME@example.com. Ad esempio, org.finance-all@example.com.

  • Gruppi di collaborazione: collab.TEAM_NAME@example.com. Ad esempio, collab.msmiths-team@example.com.

  • Gruppi di accesso: access.JOB_FUNCTION@example.com. Ad esempio, access.billing-dashboard-users@example.com.

  • Gruppi di applicazione: enforcement.GROUP_DESCRIPTION@example.com. Ad esempio, enforcement.sso-users@example.com.

Adotta la convenzione più adatta alla tua organizzazione e supportata dal software di gestione dei gruppi. L'utilizzo di un prefisso consente di ordinare alfabeticamente i gruppi in base alla funzione, ma alcuni sistemi di gestione dei gruppi, come Groups for Business, supportano solo i suffissi. Se non puoi utilizzare i prefissi, puoi utilizzare suffissi o domini secondari.

Domini secondari

Come alternativa alle convenzioni di denominazione, puoi utilizzare domini secondari per incorporare il tipo di gruppo nel nome, ad esempio access.example.com. I domini secondari che sono un sottodominio di un dominio verificato non richiedono la verifica e non devono esistere nel DNS. Inoltre, non creando record DNS Mail Exchange (MX) per i domini secondari, puoi bloccare l'arrivo delle email in entrata ai gruppi non destinati alla comunicazione.

Regole di nidificazione

I diversi tipi di gruppi hanno regole diverse per quanto riguarda la nidificazione (accettazione di un gruppo come membro).

Regole di nidificazione per i gruppi di organizzazioni

È consigliabile nidificare i gruppi di organizzazioni in modo che riflettano l'organigramma. Questo approccio prevede che ogni dipendente sia incluso in un gruppo e che i gruppi si includano a vicenda. Ad esempio, il gruppo org.finance-all potrebbe contenere come membri i gruppi org.finance-us, org.finance-germany e org.finance-australia.

Puoi aggiungere gruppi di organizzazioni come membri a qualsiasi altro tipo di gruppo. Questa operazione può essere molto più semplice rispetto all'aggiunta di ogni membro di un gruppo organizzativo a un altro gruppo.

Non aggiungere altri tipi di gruppi come membri a un gruppo dell'organizzazione. Non utilizzare gruppi di accesso, applicazione o collaborazione all'interno di una gerarchia organizzativa.

Regole di nidificazione per i gruppi di collaborazione

Ogni gruppo di collaborazione deve avere un insieme ben definito di criteri che determinano la modalità di aggiunta dei membri. Se due gruppi di collaborazione rispettano gli stessi criteri di appartenenza, possono essere nidificati. Tuttavia, l'organizzazione gerarchica dei gruppi di collaborazione con criteri di appartenenza diversi può consentire l'inclusione di membri che non soddisfano i criteri di appartenenza di un gruppo. Esamina attentamente le norme relative all'appartenenza prima di nidificare i gruppi di collaborazione.

I gruppi di collaborazione possono avere gruppi di organizzazioni come membri.

Regole di nidificazione per i gruppi di accesso

In genere, non è consigliabile nidificare i gruppi di accesso. L'organizzazione gerarchica dei gruppi di accesso può rendere difficile determinare chi ha accesso a quali risorse. Inoltre, la nidificazione di gruppi di accesso con criteri di accesso diversi potrebbe consentire agli entità di bypassare criteri di appartenenza ai gruppi di accesso rigorosi.

I gruppi di accesso possono avere gruppi di organizzazioni come membri.

Regole di nidificazione per i gruppi di applicazione

Non nidificare i gruppi di applicazione. L'organizzazione gerarchica dei gruppi di applicazione può complicare la determinazione del motivo per cui a un'entità viene negato l'accesso. Inoltre, l'organizzazione gerarchica dei gruppi di applicazione con criteri di adesione diversi potrebbe causare l'applicazione di limitazioni indesiderate ad alcuni principi.

I gruppi di applicazione possono avere gruppi di organizzazioni come membri.

Gestire i gruppi di organizzazioni

Utilizza le seguenti best practice per gestire i gruppi dell'organizzazione.

Esegui il provisioning da un'unica fonte attendibile

Poiché i gruppi organizzativi si basano sui dati delle risorse umane, è meglio eseguire il provisioning di questi gruppi esclusivamente da un sistema informativo delle risorse umane o da un'origine attendibile esterna, ad esempio un fornitore di servizi di identità (IdP) esterno o un sistema di governance delle identità come Sailpoint, Okta o Entra ID.

Non consentire modifiche al gruppo

Non aggiungere o rimuovere manualmente gli utenti da un gruppo dell'organizzazione e non consentire agli utenti di rimuoversi da un gruppo dell'organizzazione.

Evita di utilizzare gruppi di organizzazioni per fornire l'accesso alle risorse

Raramente tutti gli utenti di un gruppo organizzativo hanno bisogno dello stesso livello di accesso alle risorse. Per questo motivo, la concessione dell'accesso a un gruppo di organizzazioni è probabile che comporti che alcuni membri del gruppo abbiano più accesso di quanto effettivamente necessario.

Inoltre, può esserci un ritardo tra il momento in cui le modifiche vengono apportate in un IdP esterno e il momento in cui vengono propagate a Cloud Identity, in base alla frequenza di sincronizzazione dall'IdP esterno a Cloud Identity. Questo ritardo può portare alla proliferazione di autorizzazioni in eccesso. Ad esempio, potrebbe indurre i proprietari delle risorse a concedere l'accesso a gruppi esistenti anziché creare un nuovo gruppo, anche se questi gruppi esistenti contengono persone che non hanno bisogno di accedere alla risorsa.

Se devi fornire l'accesso utilizzando un gruppo dell'organizzazione, aggiungi il gruppo dell'organizzazione come membro di un gruppo di accesso anziché concedere l'accesso direttamente e concedi solo i ruoli con autorizzazioni limitate, ad esempio Visualizzatore organizzazione. In caso contrario, utilizza i gruppi di accesso per fornire l'accesso alle risorse.

Non consentire account di servizio e utenti esterni nei gruppi dell'organizzazione

Non includere gli account di servizio nei gruppi di organizzazioni, perché non rappresentano persone.

Gli utenti esterni, ovvero quelli di un altro account Google Workspace o Cloud Identity, in genere non fanno parte della tua organizzazione, pertanto non c'è motivo che siano membri di un gruppo dell'organizzazione. Se li onboarding nel tuo account Google Workspace o Cloud Identity, vengono considerati utenti interni e possono essere inclusi nei gruppi dell'organizzazione.

Utilizza i gruppi di sicurezza Cloud Identity e le limitazioni di gruppo per applicare queste regole.

Gestire i gruppi di collaborazione

Utilizza le seguenti best practice per gestire i gruppi di collaborazione.

Utilizzare Groups for Business per gestire i gruppi di collaborazione

Se utilizzi Google Workspace, puoi utilizzare Groups for Business per gestire i gruppi di collaborazione. In questo modo, gli utenti possono utilizzare Google Gruppi per creare, sfogliare e partecipare ai gruppi. Devi configurare Groups for Business per consentire agli utenti di creare nuovi gruppi di collaborazione.

Disattivare Groups for Business se non lo utilizzi

Se utilizzi Cloud Identity, ma non Google Workspace, non c'è motivo di avere gruppi di collaborazione in Cloud Identity, quindi è meglio disattivare Gruppi per le aziende per impedire ai tuoi utenti di creare gruppi in Cloud Identity.

Forzare un suffisso per i gruppi di collaborazione

Se utilizzi Groups for Business, configuralo in modo da applicare un suffisso. Questo è particolarmente importante se consenti a tutti di creare nuovi gruppi di Groups for Business.

L'applicazione di un suffisso impedisce agli utenti di creare un gruppo con un nome che entra intenzionalmente in conflitto con un gruppo di accesso o un gruppo di organizzazioni di cui sta per essere eseguito il provisioning da un'origine esterna. Questo scenario potrebbe consentire al creator del gruppo di collaborazione con nome falso di eseguire la riassegnazione dei propri privilegi.

Non utilizzare i gruppi di collaborazione per controllo dell'accesso

I gruppi di collaborazione hanno un controllo dell'accesso dell'accesso meno stringente e in genere nonseguono un ciclo di vita ben definito. Ciò li rende ideali per la collaborazione, ma non per controllo dell'accesso.

Se hai seguito rigorosamente una convenzione di denominazione per i gruppi di collaborazione, puoi creare una limitazione delle norme dell'organizzazione personalizzata per impedire di assegnare ai gruppi di collaborazione i ruoli IAM.

Analogamente, se esegui il provisioning e gestisci i gruppi di collaborazione esternamente, non eseguirne il provisioning in Cloud Identity, in quanto potrebbero essere utilizzati impropriamente ai fini del controllo dell'accesso dell'accesso.

Gestire i gruppi di accesso

Utilizza le seguenti best practice per gestire i gruppi di accesso.

Seleziona lo strumento giusto per gestire i gruppi di accesso

Poiché i gruppi di accesso sono gestiti dai proprietari dei workload, utilizza uno strumento adatto al self-service. Lo strumento deve consentire agli utenti di trovare i gruppi di accesso esistenti e applicare i seguenti controlli di sicurezza:

  • Chi (membri di quale gruppo organizzativo) è idoneo a partecipare a un gruppo di accesso

  • Quali requisiti devono essere soddisfatti per consentire a un utente di partecipare a un gruppo

    Ad esempio, gli utenti devono fornire una motivazione?

  • Durata massima dell'iscrizione al gruppo

  • Se l'abbonamento deve essere approvato e da chi

  • Supporto per l'audit trail

Uno strumento che soddisfa questi requisiti è JIT Groups.

Utilizzare i gruppi di accesso per modellare le funzioni di lavoro e concedere l'accesso alle risorse

Crea un gruppo di accesso per ogni funzione di lavoro e concedigli l'accesso a tutte le risorse di cui hanno bisogno gli utenti di quella funzione. Poi, puoi aggiungere al gruppo gli utenti con quella funzione lavorativa per concedergli l'accesso di cui hanno bisogno anziché concedere gli stessi ruoli a ogni singolo utente.

Puoi utilizzare un singolo gruppo di accesso per fornire l'accesso a più risorse o persino a più progetti. Tuttavia, assicurati che ogni membro del gruppo abbia bisogno dell'accesso concesso al gruppo. Se alcuni utenti non hanno bisogno dell'accesso aggiuntivo, crea un nuovo gruppo di accesso e concedi l'accesso aggiuntivo a questo gruppo.

Utilizzare i gruppi di accesso per un carico di lavoro specifico

Il riutilizzo dei gruppi di accesso per più carichi di lavoro comporta un numero eccessivo di autorizzazioni e una complessità di amministrazione.

Rimuovere gli ostacoli alla creazione di gruppi di accesso per i proprietari dei carichi di lavoro

Per ridurre la tentazione di riutilizzare un gruppo di accesso esistente, semplifica la creazione e la gestione dei gruppi di accesso. I proprietari dei carichi di lavoro devono essere in grado di creare gruppi di accesso in modalità self-service, con il supporto della denominazione corretta.

Consentire agli utenti di trovare e iscriversi ai gruppi di accesso

Se gli utenti possono scoprire i gruppi di accesso esistenti e partecipare a quelli di cui hanno bisogno, è meno probabile che accumulino privilegi non necessari. Se necessario, puoi utilizzare una procedura di invito o approvazione per controllare chi può partecipare al gruppo.

Lasciare che gli abbonamenti scadano automaticamente per impostazione predefinita

Richiedi agli utenti di partecipare di nuovo a un gruppo di accesso o di estendere l'abbonamento dopo un determinato periodo di tempo. Questa pratica aggiunge intenzionalmente complessità per rimanere membro di un gruppo di accesso e crea un incentivo a far scadere le iscrizioni non necessarie. Questa best practice è fondamentale per raggiungere lo scopo di Zero Standing Privileges (ZSP) ed è particolarmente importante per gli utenti esterni.

Tuttavia, non applicare questa regola agli account di servizio, perché la rimozione degli account di servizio da un gruppo di accesso può comportare interruzioni del servizio.

Assegna a ogni gruppo proprietari designati

Ogni gruppo di accesso deve avere uno o più proprietari designati. In questo modo si favorisce un senso di responsabilità per l'appartenenza al gruppo. I proprietari possono essere la stessa persona o lo stesso team che possiede il carico di lavoro associato al gruppo.

Limitare la visibilità dei gruppi di accesso

Non rendere visibili i gruppi di accesso nella directory Gruppi. Dovrebbero essere rilevabili nel tuo strumento di gestione dei gruppi di accesso. Inoltre, consenti solo ai membri del gruppo di vedere chi sono gli altri membri. Queste pratiche impediscono ai malintenzionati di ottenere informazioni preziose.

Limitare i membri esterni

Poiché i limiti dei criteri di condivisione con restrizioni al dominio (DRS) si applicano ai gruppi, ma non ai membri del gruppo, i gruppi di accesso che consentono membri esterni possono creare una scappatoia che mina la DRS.

Utilizza i gruppi di sicurezza Cloud Identity e le limitazioni dei gruppi per consentire o meno i membri esterni per i gruppi di accesso. Inoltre, ti consigliamo di utilizzare una convenzione di denominazione speciale, ad esempio external.access.GROUP_NAME@example.com, per i gruppi di accesso che consentono membri esterni.

Gestire i gruppi di applicazione

Utilizza le seguenti best practice per gestire i gruppi di applicazione.

Seleziona lo strumento giusto per gestire i gruppi di applicazione

Poiché l'appartenenza ai gruppi di applicazione delle norme si basa sulle regole dell'organizzazione e viene utilizzata per applicare limitazioni di sicurezza, non consentire ai membri di disattivare o rimuovere l'appartenenza a un gruppo di applicazione delle norme.

L'utilizzo dei gruppi dinamici ti consente di automatizzare il provisioning dei gruppi di applicazione. Se utilizzi un IdP esterno, utilizza i gruppi dinamici forniti dall'IdP e poi esegui il provisioning in Cloud Identity. Tieni presente che l'utilizzo di un IdP esterno può comportare un ritardo per gli aggiornamenti dei criteri.

Se non puoi utilizzare i gruppi dinamici, ti consigliamo di utilizzare Terraform o un altro strumento di Infrastructure as Code (IaC) per eseguire il provisioning dei gruppi di applicazione. Se utilizzi la IaC per creare gruppi di applicazione, assicurati di non concedere accesso eccessivamente ampio alla pipeline.

Utilizzare i gruppi di applicazione per i controlli di autenticazione e controllo dell'accesso obbligatori

Utilizza i gruppi di accesso per applicare il controllo dell'accesso obbligatorio. Google Cloud supporta controllo dell'accesso dell'accesso obbligatorio con una serie di servizi e strumenti, tra cui:

I gruppi di applicazione vengono utilizzati anche per applicare controlli di autenticazione come l'assegnazione del profilo SAML o la verifica in due passaggi (V2P).

Poiché tutti questi controlli limitano le funzionalità o rimuovono l'accesso, i gruppi di applicazione sono la scelta giusta.

Non consentire agli utenti di uscire da un gruppo di applicazione

Consentire agli utenti di uscire da un gruppo di applicazione delle norme va contro i principi del controllo dell'accesso obbligatorio. Per impedire agli utenti di uscire dal gruppo, utilizza l'API Groups Settings per impostare la proprietà whoCanLeaveGroup su NONE_CAN_LEAVE.

Best practice per gli IdP esterni

Se utilizzi un IdP esterno per l'autenticazione, può essere utile utilizzarlo anche per il provisioning dei gruppi di organizzazioni e dei gruppi di applicazione.

Evita di utilizzare un'origine esterna per i gruppi di accesso

È possibile gestire i gruppi di accesso nell'IdP esterno e eseguirne il provisioning in Cloud Identity, ma questo approccio presenta diversi svantaggi:

  • Ritardi nel provisioning

    Potrebbero essere necessarie diverse ore prima che le modifiche apportate all'IDP esterno vengano applicate al gruppo di accesso.

  • Rischio di divergenza

    Alcune IdP non esercitano un controllo autorevole sui gruppi. Ad esempio, potrebbe non eliminare un gruppo in Cloud Identity dopo averlo eliminato esternamente o eliminare attivamente i membri del gruppo esistenti in Cloud Identity, ma non nell'IdP.

    Le discrepanze possono causare il mantenimento dell'accesso da parte degli utenti a funzionalità di cui non hanno bisogno e fornire informazioni errate su chi ha accesso. Inoltre, può complicare la creazione dei gruppi di accesso.

Per evitare questi problemi, utilizza le IdP esterne per eseguire il provisioning solo dei gruppi di applicazione e di organizzazione e uno strumento come JIT Groups per gestire i gruppi di accesso direttamente in Cloud Identity.

Utilizza un dominio secondario se esegui la mappatura dei gruppi per nome

Cloud Identity identifica i gruppi in base all'indirizzo email, ma i gruppi nell'IDP esterno potrebbero non avere un indirizzo email.

Molti provider di servizi di identità ti consentono di aggirare il problema ricavando un indirizzo email pseudo dal nome del gruppo, ad esempio utilizzando my-group@example.com. Questo metodo funziona, ma può portare a collisioni se l'indirizzo email è già utilizzato da un gruppo o un utente diverso. Nel peggiore dei casi, questa collisione dei nomi potrebbe essere sfruttata da un malintenzionato per creare gruppi di sicurezza che si spacciano per un altro tipo di gruppo meno esaminato.

Per evitare il rischio di collisioni, utilizza un dominio secondario dedicato per i gruppi di cui esegui il provisioning dall'origine esterna, ad esempio groups.example.com.

Evita di concedere il ruolo Amministratore di Gruppi alle pipeline di deployment

Se utilizzi IaC per gestire i gruppi (ad esempio Terraform), la pipeline di deployment deve disporre delle autorizzazioni necessarie per svolgere la sua attività. Il ruolo Amministratore di gruppi autorizza la creazione di gruppi, ma consente anche a qualsiasi entità con questo ruolo di gestire tutti i gruppi nell'account Cloud Identity.

Puoi limitare l'accesso concesso a una pipeline creando un account di servizio con una sola autorizzazione (la possibilità di creare un gruppo) e poi impostando la pipeline come proprietaria di qualsiasi gruppo creato. In questo modo, la pipeline può gestire qualsiasi gruppo che crea e creare altri gruppi, senza autorizzarla a gestire alcun gruppo che non ha creato.

I passaggi riportati di seguito illustrano questo approccio:

  1. Crea un ruolo amministrativo personalizzato che includa solo l'autorizzazione di creazione del gruppo dell'API Admin.

    Assegna a questo ruolo un nome descrittivo, ad esempio Creatore di gruppi.

  2. Crea un account di servizio e assegnagli il ruolo Creatore gruppo.

  3. Utilizza l'account di servizio per la pipeline e passa il flag WITH_INITIAL_OWNER al momento della creazione del gruppo.

Utilizza Cloud Logging per controllare e monitorare i gruppi.

Logging ti consente di raccogliere, monitorare e analizzare l'attività di gruppo.

Controllare le modifiche all'abbonamento

L'aggiunta o la rimozione di un membro di un gruppo organizzativo, di un gruppo di accesso o di un gruppo di applicazione può influire sulle risorse a cui ha accesso il membro, pertanto è importante mantenere una traccia di controllo che monitori queste modifiche.

Richiedere giustificazioni per l'inclusione nei gruppi di accesso

Per rendere più utili i dati di monitoraggio, chiedi agli utenti di fornire una giustificazione quando si uniscono a un gruppo o ne richiedono l'accesso e registra la giustificazione. Se è presente una procedura di approvazione, registra i dettagli di chi ha approvato la richiesta.

Questi metadati aggiuntivi possono aiutarti in un secondo momento ad analizzare il motivo per cui un utente è stato aggiunto a un gruppo e, per estensione, il motivo per cui gli è stato concesso l'accesso a determinate risorse.

Attivare la condivisione degli audit log di Cloud Identity

Configura Cloud Identity per instradare i log a Cloud Logging in modo da poter gestire questi log di controllo come gli altri log di Google Cloud , incluso l'impostazione di avvisi o l'utilizzo di un sistema di gestione degli eventi e delle informazioni di sicurezza (SIEM) esterno.