Best practice per l'utilizzo di Google Gruppi

Questo documento descrive alcune best practice per l'utilizzo di Gruppi Google per gestire l'accesso alle risorse 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 dell'organizzazione cambiano quando un dipendente entra a far parte del gruppo. si sposta in un altro reparto o lascia l'organizzazione.

    La struttura complessiva dei gruppi organizzativi può cambiare quando l'attività si riorganizza. Una riorganizzazione può comportare la creazione di nuovi gruppi oppure i gruppi esistenti verranno ritirati.

    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ò autogestito, vale a dire che alcuni membri possono decidere chi altri includere il gruppo.

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

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

  • Gruppi di accesso

    I gruppi di accesso vengono utilizzati al solo scopo di fornire l'accesso. Loro rappresentano le mansioni lavorative e sono utilizzati per semplificare l'assegnazione dei ruoli necessarie per svolgere queste mansioni lavorative. 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 carichi di lavoro 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ù gruppi proprietari, che invitano gli utenti a unirsi al gruppo o approvano gli utenti richieste a unisciti al gruppo.

    Alcuni esempi di gruppi di accesso includono 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 ai fini della comunicazione.

  • Gruppi di applicazione delle norme

    I gruppi di applicazione delle norme sono simili ai gruppi di accesso, ad eccezione del fatto che sono utilizzati per applicare criteri di limitazione dell'accesso invece di fornire l'accesso.

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

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

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

    I gruppi di applicazione forzata 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 seguire le best practice riportate nel resto di questo documento, utilizza che ti consentono di determinare il tipo di un gruppo a partire dal suo nome. Puoi 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 delle norme: enforcement.GROUP_DESCRIPTION@example.com. Ad esempio, enforcement.sso-users@example.com.

Adotta la convenzione adatta alla tua organizzazione e che supportate dal software di gestione dei gruppi. L'uso di un prefisso mette in ordine alfabetico i gruppi per funzione, ma alcuni sistemi di gestione dei gruppi, come Groups for Business, assistenza solo suffissi. Se non puoi utilizzare i prefissi, puoi utilizzare suffissi o domini secondari.

Domini secondari

In alternativa alle convenzioni di denominazione, puoi utilizzare i domini secondari per incorporare digita il nome del gruppo, 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 la nidificazione (accettazione di un gruppo come membro).

Regole di nidificazione per i gruppi di organizzazioni

Nidificare i gruppi organizzativi affinché rispecchino il tuo organigramma è una best practice. Questo significa che ogni dipendente è incluso in un gruppo e poi in un gruppo si includiamo 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 organizzativi a qualsiasi altro tipo di gruppo come membri della community. Questa operazione può essere molto più semplice rispetto all'aggiunta di ogni membro di un gruppo organizzativo a un altro gruppo.

Non aggiungere come membro nessun altro tipo di gruppo 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, la nidificazione di gruppi di collaborazione con norme di iscrizione diverse possono consentire agli abbonati che non soddisfano i criteri di appartenenza di un gruppo diventano membri. Consulta le norme relative all'abbonamento prima di nidificare i gruppi di collaborazione.

I gruppi di collaborazione possono avere gruppi organizzativi come membri.

Regole di nidificazione per i gruppi di accesso

In genere, non è consigliabile nidificare i gruppi di accesso. I gruppi di accesso nidificati possono rendere è difficile determinare chi ha accesso a determinate risorse. Inoltre, la nidificazione di gruppi di accesso con criteri di accesso diversi potrebbe consentire alle entità di bypassare il livello di accesso ai criteri di appartenenza ai gruppi.

I gruppi di accesso possono avere gruppi organizzativi 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 norme di adesione diverse 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 su dati delle risorse umane, è preferibile fornire a questi gruppi esclusivamente un sistema informatico per le risorse umane; da una fonte attendibile esterna, ad esempio un provider di identità esterno (IdP) 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 organizzativo.

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, è probabile che la concessione dell'accesso a un gruppo organizzativo in modo che alcuni membri del gruppo abbiano più accesso di quello che in realtà necessaria.

Inoltre, potrebbe verificarsi un ritardo tra il momento in cui vengono apportate modifiche a un all'IdP e alla loro propagazione a Cloud Identity, in base frequenza di sincronizzazione dall'IdP esterno a Cloud Identity. Questo ritardo può portare alla proliferazione di autorizzazioni in eccesso. Ad esempio, i proprietari delle risorse potrebbero decidere di concedere l'accesso a gruppi esistenti anziché crearne uno nuovo, se i gruppi esistenti contengono persone che non hanno bisogno di accedere alla risorsa.

Se devi fornire l'accesso utilizzando un gruppo organizzativo, aggiungi l'organizzazione gruppo come membro di un gruppo di accesso, invece di concedere l'accesso direttamente, e Concedere solo 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 organizzativi, 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 dei gruppi per applicare queste regole.

Gestire i gruppi di collaborazione

Utilizza le best practice riportate di seguito per gestire i tuoi gruppi di collaborazione.

Utilizza 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, è meglio disabilita Groups for Business per impedire agli 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 Groups for Business gruppi.

L'applicazione di un suffisso impedisce agli utenti di creare un gruppo con un nome che si scontra intenzionalmente con un gruppo di accesso o un gruppo organizzativo 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 il controllo degli accessi

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

Se hai seguito rigorosamente una convenzione di denominazione per i gruppi di collaborazione, puoi creare un vincolo dei criteri dell'organizzazione personalizzato 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.

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 carichi di lavoro, utilizza uno strumento adatto a 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 affinché un utente possa unirsi 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 audit trail

Uno strumento che soddisfa questi requisiti è JIT Groups.

Utilizza i gruppi di accesso per creare modelli di mansioni lavorative e concedere l'accesso alle risorse

Crea un gruppo di accesso per ogni ruolo professionale e concedigli l'accesso a tutti di cui hanno bisogno gli utenti di quella funzione professionale. 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 la complessità dell'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 poter creare i gruppi di accesso in modo self-service, con il supporto di una 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

Richiedere agli utenti di iscriversi nuovamente a un gruppo di accesso o di estendere l'appartenenza dopo un un 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 ciascun gruppo i 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 altri ne sono membri. Questi 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.

Utilizzare i gruppi di sicurezza di Cloud Identity e limitazioni di gruppo 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 delle norme

Poiché l'appartenenza ai gruppi di applicazione delle norme si basa sull'organizzazione di regole e usate per applicare limitazioni di sicurezza, non consentire disattivare o rimuovere il proprio account da un gruppo di applicazione delle norme.

L'uso dei gruppi dinamici consente di per 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ò introdurre dell'aggiornamento delle norme.

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 il controllo dell'accesso obbligatorio con una serie di servizi e strumenti, tra cui:

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

Poiché questi controlli limitano tutte le funzionalità o rimuovono l'accesso, sono la scelta giusta.

Non consentire agli utenti di uscire da un gruppo di applicazione

Consentire agli utenti di abbandonare un gruppo di applicazione delle norme va contro i principi di un 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 ed eseguirne il provisioning 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

    Alcuni IdP non assumono il controllo autorevole dei 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.

    La divergenza può indurre gli utenti a conservare l'accesso di cui non hanno bisogno e informazioni errate su chi ha accesso. Inoltre, può complicare la creazione dei gruppi di accesso.

Per evitare queste insidie, usa gli IdP esterni per eseguire il provisioning solo delle risorse aziendali gruppi di applicazione delle norme e usare uno strumento come Gruppi JIT per gestire l'accesso gruppi direttamente in Cloud Identity.

Utilizza un dominio secondario se stai eseguendo 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 IdP ti consentono di aggirare questo problema consentendoti di ricavare uno pseudo indirizzo email dal nome del gruppo, ad esempio usando 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 quel 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 rendendo della pipeline per il proprietario 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. Creare 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 Autore gruppo.

  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.

Controlla le modifiche alle iscrizioni

L'aggiunta o la rimozione di un membro di un gruppo organizzativo, di un gruppo di accesso o di può influire sulle risorse a cui ha accesso il membro, perciò è importante tenere un audit trail che tenga traccia di queste modifiche.

Richiedere giustificazioni per l'inclusione nei gruppi di accesso

Per rendere più utili i dati di monitoraggio, richiedi agli utenti di fornire una la giustificazione quando entrano a far parte di un gruppo o chiedono di iscriversi a un gruppo e una 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 possono gestire questi audit log come gli altri log di Google Cloud, tra cui l'impostazione di avvisi o l'uso di informazioni ed eventi di sicurezza esterni di grandi dimensioni (SIEM).