Best practice per l'utilizzo di Google Gruppi

Questo documento descrive alcune best practice per l'utilizzo dei gruppi Google per gestire l'accesso alle Cloud de Confiance by S3NS risorse con Identity and Access Management (IAM).

Tipi di gruppi

I tipi di gruppi elencati qui sono un modo per pensare, utilizzare e gestire i gruppi Google. Questi tipi di gruppi non sono impostati da alcun attributo di gruppo Google. Tuttavia, l'utilizzo di questi tipi di gruppi nell'approccio generale alla gestione dei gruppi Google può aiutarti a evitare alcuni problemi di sicurezza comuni.

Questo documento utilizza i seguenti tipi di gruppi:

  • Gruppi organizzativi

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

    I membri di un gruppo organizzativo cambiano quando un dipendente entra a far parte dell'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 gruppi esistenti.

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

    I gruppi organizzativi vengono in genere utilizzati per la comunicazione 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 ad alcuna struttura organizzativa. Spesso vengono creati in modo autonomo e ad hoc.

    L'iscrizione ai gruppi di collaborazione può essere senza restrizioni, 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 la comunicazione via email.

  • Gruppi di accesso

    I gruppi di accesso vengono utilizzati al solo scopo di fornire l'accesso. Rappresentano le funzioni lavorative e vengono utilizzati per semplificare l'assegnazione dei ruoli necessari per svolgere queste funzioni. Anziché concedere ruoli alle singole entità, concedi ruoli 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 di un nuovo 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 a farne parte o approvano le loro richieste di adesione.

    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 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 policy di limitazione dell'accesso anziché 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 è in genere determinata da un insieme di regole predefinite che esaminano il livello di autorizzazione, la posizione 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 le policy di limitazione dell'accesso. Non vengono utilizzati per scopi di comunicazione.

Assegna ai gruppi nomi che riflettano il loro 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 organizzativi: 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 forzata: 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 ordina 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 i suffissi o i domini secondari.

Domini secondari

In alternativa alle convenzioni di denominazione, puoi utilizzare i domini secondari per incorporare il tipo di gruppo nel nome, ad esempio access.example.com. I domini secondari che sono sottodomini di un dominio verificato non richiedono la verifica e non devono esistere nel DNS. Inoltre, se non crei record MX (Mail Exchange) DNS per i domini secondari, puoi bloccare la ricezione di email in entrata da gruppi non destinati alla comunicazione.

Regole di nidificazione

I diversi tipi di gruppi hanno regole diverse per stabilire se è consentito l'annidamento (accettare un gruppo come membro).

Regole di nidificazione per i gruppi organizzativi

L'incorporamento di gruppi organizzativi per riflettere l'organigramma è una best practice. 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 i gruppi org.finance-us, org.finance-germany e org.finance-australia come membri.

Puoi aggiungere gruppi organizzativi a qualsiasi altro tipo di gruppo come membri. 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 a un gruppo organizzativo come membro. Non utilizzare gruppi di accesso, applicazione o collaborazione come parte di una gerarchia organizzativa.

Regole di nidificazione per i gruppi di collaborazione

Ogni gruppo di collaborazione deve avere un insieme ben definito di norme che determinano come vengono aggiunti i membri. Se due gruppi di collaborazione seguono le stesse norme di appartenenza, possono essere nidificati. Tuttavia, la nidificazione di gruppi di collaborazione con criteri di iscrizione diversi può consentire ai membri che non soddisfano i criteri di iscrizione di un gruppo di diventare membri. Esamina attentamente 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 devi nidificare i gruppi di accesso. L'annidamento dei gruppi di accesso può rendere difficile determinare chi ha accesso a quali risorse. Inoltre, l'annidamento di gruppi di accesso con criteri di accesso diversi potrebbe consentire alle entità di aggirare i criteri di iscrizione al gruppo rigidi.

I gruppi di accesso possono avere come membri gruppi organizzativi.

Regole di nidificazione per i gruppi di applicazione

Non nidificare i gruppi di applicazione. Il raggruppamento dei gruppi di applicazione può rendere difficile determinare il motivo per cui a un'entità viene negato l'accesso. Inoltre, il raggruppamento di gruppi di applicazione con criteri di appartenenza diversi potrebbe causare l'applicazione di restrizioni indesiderate ad alcuni principal.

I gruppi di applicazione possono avere gruppi organizzativi come membri.

Gestire i gruppi organizzativi

Segui queste best practice per gestire i gruppi organizzativi.

Provisioning da un'unica fonte attendibile

Poiché i gruppi organizzativi si basano sui dati delle risorse umane, è consigliabile provisionarli esclusivamente da un sistema informativo delle risorse umane o da una fonte attendibile esterna, ad esempio un provider di identità (IdP) esterno o un sistema di gestione delle identità come Sailpoint, Okta o Entra ID.

Non consentire modifiche al gruppo

Non aggiungere o rimuovere manualmente utenti da un gruppo organizzativo e non consentire agli utenti di rimuovere se stessi da un gruppo organizzativo.

Evita di utilizzare i gruppi organizzativi 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 organizzativo probabilmente comporterà che alcuni membri del gruppo abbiano un accesso superiore a quello di cui hanno effettivamente bisogno.

Inoltre, può verificarsi un ritardo tra il momento in cui vengono apportate modifiche 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é crearne uno nuovo, anche se questi gruppi esistenti contengono persone che non hanno bisogno di accedere alla risorsa.

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

Non consentire service account e utenti esterni nei gruppi organizzativi

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, quindi non c'è motivo per cui debbano essere membri di un gruppo organizzativo. Se integri la tua forza lavoro esterna nel tuo account Google Workspace o Cloud Identity, questi utenti vengono considerati interni e possono essere inclusi nei gruppi della tua organizzazione.

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

Gestire i gruppi di collaborazione

Segui queste 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. Consente agli utenti di utilizzare Google Gruppi per creare, sfogliare e partecipare a 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 agli utenti di creare gruppi in Cloud Identity.

Forzare un suffisso per i gruppi di collaborazione

Se utilizzi Groups for Business, configuralo per imporre un suffisso. Ciò è particolarmente importante se consenti a tutti di creare nuovi gruppi 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 organizzativo che sta per essere sottoposto a provisioning da una fonte esterna. Questo scenario potrebbe consentire al creator del gruppo di collaborazione con nome falso di aumentare i propri privilegi.

Non utilizzare i gruppi di collaborazione per controllo dell'accesso dell'accesso

I gruppi di collaborazione sono pensati per avere un controllo dell'accesso blando e in genere non seguono un ciclo di vita ben definito. Questo li rende adatti alla collaborazione, ma non al controllo dell'accesso.

Se hai seguito rigorosamente una convenzione di denominazione per i tuoi gruppi di collaborazione, puoi creare un vincolo della policy dell'organizzazione personalizzato per impedire che ai gruppi di collaborazione vengano concessi ruoli IAM.

Allo stesso modo, se esegui il provisioning e la gestione dei gruppi di collaborazione esternamente, non eseguirne il provisioning in Cloud Identity, in quanto ciò consentirebbe di utilizzarli in modo improprio per scopcontrollo dell'accessolo dell'accesso.

Gestire i gruppi di accesso

Segui queste best practice per gestire i gruppi di accesso.

Selezionare 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 misure di sicurezza che implementino i seguenti controlli:

  • Quali membri di quale gruppo organizzativo possono iscriversi a un gruppo di accesso

  • Quali requisiti devono essere soddisfatti per consentire a un utente di entrare a far parte di un gruppo

    Ad esempio, gli utenti devono fornire una giustificazione?

  • Durata massima dell'iscrizione al gruppo

  • Se l'abbonamento deve essere approvato e da chi

  • Supporto per traccia di audit

Uno strumento che soddisfa questi requisiti sono i gruppi JIT.

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

Crea un gruppo di accesso per ogni funzione lavorativa e concedi l'accesso a tutte le risorse necessarie agli utenti che svolgono quella funzione. Poi, puoi aggiungere gli utenti con quella funzione lavorativa al gruppo per concedere loro l'accesso di cui hanno bisogno, invece di assegnare gli stessi ruoli a ogni singolo utente.

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

Utilizzare i gruppi di accesso per un workload specifico

Il riutilizzo dei gruppi di accesso per più workload comporta un numero eccessivo di autorizzazioni e una maggiore complessità amministrativa.

Rimuovere le barriere alla creazione di gruppi di accesso per i proprietari dei workload

Per ridurre la tentazione di riutilizzare un gruppo di accesso esistente, rendi i gruppi di accesso semplici da creare e gestire. I proprietari dei workload devono essere in grado di creare gruppi di accesso in modalità self-service, con il supporto di una denominazione corretta.

Consentire agli utenti di trovare e unirsi ai gruppi di accesso

Se gli utenti possono scoprire i gruppi di accesso esistenti e unirsi a quelli di cui hanno bisogno, sarà meno probabile che accumulino privilegi non necessari. Se necessario, puoi utilizzare una procedura di invito o approvazione per controllare chi può entrare a far parte del gruppo.

Consentire la scadenza automatica degli abbonamenti per impostazione predefinita

Richiedi agli utenti di rientrare in un gruppo di accesso o di estendere la propria iscrizione dopo un periodo di tempo. Questa pratica aggiunge intenzionalmente attrito per rimanere membro di un gruppo di accesso e crea un incentivo a lasciare scadere le iscrizioni non necessarie. Questa best practice è fondamentale per raggiungere l'obiettivo di Zero Standing Privileges (ZSP) ed è particolarmente importante per gli utenti esterni.

Non applicare questa regola ai service account, perché la rimozione dei service account da un gruppo di accesso può causare interruzioni del servizio.

Assegna a ogni gruppo proprietari designati.

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

Limitare la visibilità dei gruppi di accesso

Non rendere visibili i gruppi di accesso nella directory Gruppi. (Dovrebbero essere individuabili nello strumento di gestione dei gruppi di accesso.) Inoltre, consenti solo ai membri del gruppo di vedere chi altro è membro. Queste pratiche impediscono ai malintenzionati di ottenere informazioni preziose.

Limitare i membri esterni

Poiché i vincoli dei criteri di condivisione con limitazioni del 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 vietare ai membri esterni di accedere ai gruppi di accesso. Inoltre, valuta la possibilità 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

Segui queste best practice per gestire i gruppi di applicazione.

Selezionare lo strumento giusto per gestire i gruppi di applicazione

Poiché l'appartenenza ai gruppi di applicazione è basata su regole organizzative e viene utilizzata per applicare restrizioni di sicurezza, non consentire ai membri di disattivare o rimuovere la propria appartenenza a un gruppo di applicazione.

L'utilizzo dei gruppi dinamici 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ò introdurre un ritardo per gli aggiornamenti delle policy.

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

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

Utilizza i gruppi di applicazione per applicare il controllo dell'accesso obbligatorio.Cloud de Confiance supporta controllo 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 di profili 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 è contrario ai principi del controllo dell'accessoo 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 i provider di identità esterni

Se utilizzi un IdP esterno per l'autenticazione, può essere utile utilizzare lo stesso IdP anche per il provisioning di gruppi organizzativi e gruppi di applicazione.

Evita di utilizzare una fonte esterna per i gruppi di accesso

È possibile gestire i gruppi di accesso nel provider di identità 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 al provider di identità esterno vengano applicate nel 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 che è stato eliminato esternamente oppure eliminare attivamente i membri del gruppo esistenti in Cloud Identity ma non nel provider di identità.

    La divergenza può causare il mantenimento dell'accesso da parte degli utenti che non ne hanno bisogno e fornisce loro informazioni errate su chi ha accesso. Inoltre, può complicare la creazione di gruppi di accesso.

Per evitare questi problemi, utilizza IdP esterni per eseguire il provisioning solo dei gruppi organizzativi e di applicazione e utilizza 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 nel tuo IdP esterno potrebbero non avere un indirizzo email.

Molti IdP ti consentono di aggirare questo problema derivando un pseudo indirizzo email dal nome del gruppo, ad esempio utilizzando my-group@example.com. Questo funziona, ma può causare conflitti quando questo indirizzo email è già utilizzato da un altro gruppo o utente. Nel peggiore dei casi, questo conflitto di denominazione potrebbe essere sfruttato da un malintenzionato per creare gruppi di sicurezza che si spacciano per un altro tipo di gruppo meno esaminato.

Per evitare il rischio di conflitti, utilizza un dominio secondario dedicato per i gruppi di cui esegui il provisioning dalla fonte esterna, ad esempio groups.example.com.

Evita di concedere il ruolo di 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 rendendo la pipeline proprietaria di qualsiasi gruppo creato. In questo modo, la pipeline può gestire qualsiasi gruppo che crea e crearne altri, senza autorizzazione a gestire gruppi che non ha creato.

I passaggi seguenti descrivono questo approccio:

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

    Assegna a questo ruolo un nome descrittivo, ad esempio Creatore del gruppo.

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

  3. Utilizza il 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 tuoi gruppi.

Logging ti consente di raccogliere, monitorare e analizzare l'attività del 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 il membro ha accesso, pertanto è importante tenere traccia di queste modifiche.

Richiedere motivazioni per l'accesso ai gruppi di accesso

Per rendere più utili i dati di monitoraggio, richiedi agli utenti di fornire una giustificazione quando si uniscono a un gruppo o richiedono di farne parte e registra la giustificazione. Se è presente una procedura di approvazione, registra i dettagli del log relativi a 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, di conseguenza, il motivo per cui gli è stato concesso l'accesso a determinate risorse.

Attiva la condivisione dei log di controllo di Cloud Identity

Configura Cloud Identity per indirizzare i log a Cloud Logging in modo da poter gestire questi audit log allo stesso modo degli altri log Cloud de Confiance , inclusa la configurazione di avvisi o l'utilizzo di un sistema di gestione degli eventi e delle informazioni di sicurezza (SIEM) esterno.