Best practice per la pianificazione di account e organizzazioni

Last reviewed 2023-02-27 UTC

Questo documento illustra le best practice per decidere quanti account Cloud Identity o Google Workspace, organizzazioni Google Cloud e account di fatturazione devi utilizzare. Il documento fornisce indicazioni su come identificare un progetto che soddisfi i tuoi requisiti di sicurezza e dell'organizzazione.

In Google Cloud, la gestione di identità e accessi si basa su due pilastri:

  • Gli account Cloud Identity e Google Workspace sono contenitori per utenti e gruppi. Questi account sono quindi fondamentali per autenticare gli utenti aziendali e gestire l'accesso alle risorse Google Cloud. Un account Cloud Identity o Google Workspace indica una directory di utenti, non un singolo account utente. Gli account utente individuali sono indicati come utenti o account utente.

  • Le organizzazioni sono container per progetti e risorse all'interno di Google Cloud. Le organizzazioni consentono di strutturare le risorse in modo gerarchico e sono fondamentali per una gestione centralizzata ed efficiente delle risorse.

Questo documento è destinato principalmente ai clienti che configurano ambienti aziendali.

Account Cloud Identity e Google Workspace

Google Workspace è una suite integrata di app cloud-native per la collaborazione e la produttività. Include strumenti che consentono di gestire utenti, gruppi e autenticazione.

Cloud Identity fornisce un sottoinsieme di funzionalità di Google Workspace. Come Google Workspace, Cloud Identity ti consente di gestire utenti, gruppi e autenticazione, ma non include tutte le funzionalità di collaborazione e produttività di Google Workspace.

Cloud Identity e Google Workspace condividono una piattaforma tecnica comune e utilizzano lo stesso set di API e strumenti amministrativi. I prodotti condividono il concetto di account come contenitore per utenti e gruppi. Questo contenitore è identificato da un nome di dominio come example.com. Per la gestione di utenti, gruppi e autenticazione, i due prodotti possono essere considerati equivalenti.

Combina Cloud Identity e Google Workspace in un unico account

Poiché Cloud Identity e Google Workspace condividono una piattaforma comune, puoi combinare l'accesso ai prodotti in un unico account.

Se amministri già un account Google Workspace e vuoi consentire a più utenti di utilizzare Google Cloud, potresti non voler assegnare a tutti gli utenti una licenza Google Workspace. In questo caso, aggiungi Cloud Identity Free al tuo account esistente. Puoi quindi configurare più utenti senza costi aggiuntivi e decidere quali utenti devono avere accesso a Google Workspace assegnando loro una licenza Google Workspace.

Analogamente, se amministri già un account Cloud Identity Free o Premium, puoi concedere a determinati utenti il diritto di utilizzare Google Workspace. Anziché creare account Google Workspace separati per questi utenti, puoi aggiungere Google Workspace a un account Cloud Identity esistente. Dopo che avrai assegnato la licenza Google Workspace agli utenti selezionati, questi potranno utilizzare le app di produttività e collaborazione.

Utilizza il minor numero possibile di account, ma il maggior numero possibile

Per consentire agli utenti di collaborare utilizzando Google Workspace e ridurre al minimo il sovraccarico amministrativo, conviene gestire tutti gli utenti tramite un singolo account Cloud Identity o Google Workspace e fornire un singolo account utente a ogni individuo. Questo approccio aiuta a garantire che impostazioni come i criteri relativi alle password, il Single Sign-On e la verifica in due passaggi vengano applicate in modo coerente a tutti gli utenti.

Nonostante questi vantaggi derivanti dall'utilizzo di un singolo account Cloud Identity o Google Workspace, puoi ottenere flessibilità e autonomia amministrativa utilizzando più account. Quando decidi il numero di account Cloud Identity o Google Workspace da utilizzare, considera tutti i requisiti che suggeriscono di utilizzare più account. Quindi utilizza il numero minore di account Cloud Identity o Google Workspace che soddisfa i tuoi requisiti.

Usa account separati per gestione temporanea e produzione

Per la maggior parte delle impostazioni configurabili in Cloud Identity e Google Workspace, puoi scegliere l'ambito a cui applicare ogni impostazione, ad esempio puoi specificare la località geografica per i tuoi dati in base all'utente, al gruppo o all'unità organizzativa. Quando prevedi di applicare una nuova configurazione, puoi scegliere inizialmente un ambito di dimensioni ridotte (ad esempio in base all'utente) e verificare se la configurazione soddisfa le tue aspettative. Dopo aver verificato la configurazione, puoi applicare la stessa impostazione a un insieme più ampio di gruppi o unità organizzative.

A differenza della maggior parte delle impostazioni, l'integrazione di un account Cloud Identity o Google Workspace con un provider di identità (IdP) esterno ha un impatto globale:

  • L'abilitazione del Single Sign-On è un'impostazione globale che si applica a tutti gli utenti tranne i super amministratori.
  • A seconda dell'IdP esterno, anche la configurazione del provisioning degli utenti può avere un impatto globale. Un errore di configurazione accidentale nell'IdP esterno potrebbe portare inavvertitamente alla modifica, alla sospensione o all'eliminazione degli utenti.

Per mitigare questi rischi, crea account Cloud Identity o Google Workspace separati di gestione temporanea e produzione:

  • Utilizza l'account di gestione temporanea per verificare eventuali modifiche rischiose alla configurazione prima di applicare la stessa modifica all'account di produzione.
  • Crea alcuni utenti di test negli account temporanei che tu e altri amministratori potete utilizzare per verificare le modifiche alla configurazione. Ma non concedere ai tuoi utenti l'accesso all'account di gestione temporanea.

Se hai istanze di gestione temporanea e produzione separate del tuo IdP esterno, segui questi passaggi:

  • Integrare il tuo account Cloud Identity o Google Workspace temporaneo con la tua istanza IdP di gestione temporanea.
  • Integra il tuo account Cloud Identity o Google Workspace di produzione con la tua istanza IdP di produzione.

Ad esempio, supponi di configurare la federazione con Active Directory e di avere una foresta di Active Directory separata a scopo di test. In questo caso, integrerai il tuo account Cloud Identity o Google Workspace di gestione temporanea con la foresta di gestione temporanea e l'account Cloud Identity o Google Workspace di produzione con la foresta principale. Applica lo stesso approccio di mappatura per domini DNS, utenti e gruppi a entrambe le coppie foresta/account, come mostrato nel seguente diagramma:

Approccio alla mappatura di Active Directory per domini, utenti e gruppi DNS.

I domini e le foreste di Active Directory di produzione e gestione temporanea potrebbero utilizzare domini DNS che non consentono di applicare lo stesso approccio di mappatura del dominio per la gestione temporanea e la produzione. In questo caso, valuta la possibilità di registrare più domini con suffisso UPN (User Principal Name) nella foresta temporanea.

Allo stesso modo, se prevedi di configurare la federazione con Azure Active Directory, ti consigliamo di adottare il seguente approccio:

  • Integrare l'account Cloud Identity o Google Workspace di gestione temporanea con un tenant di Azure Active Directory in gestione temporanea.
  • Integra l'account Cloud Identity o Google Workspace di produzione con il tenant principale di Azure Active Directory.

Applica lo stesso approccio di mappatura per domini DNS, utenti e gruppi a entrambe le coppie tenant/account:

Approccio alla mappatura di Azure Active Directory per domini, utenti e gruppi DNS.

I tenant di Azure Active Directory di produzione e gestione temporanea potrebbero utilizzare domini DNS che non consentono di applicare lo stesso approccio di mappatura del dominio per la gestione temporanea e la produzione. In questo caso, valuta la possibilità di aggiungere un altro dominio al tenant gestione temporanea.

Utilizzare domini DNS separati tra gli account Cloud Identity e Google Workspace

Quando aggiungi per la prima volta un dominio come example.com al tuo account Cloud Identity o Google Workspace, devi verificare che il dominio sia di tua proprietà. Dopo aver aggiunto e verificato un dominio, puoi aggiungere sottodomini come marketing.example.com e finance.example.com senza dover verificare ogni sottodominio singolarmente.

Tuttavia, se aggiungi sottodomini senza verificarli tutti, possono verificarsi dei conflitti se hai un altro account Cloud Identity o Google Workspace che utilizza già questo sottodominio. Per evitare conflitti, usa domini separati per ciascun account. Ad esempio, se hai bisogno di due account Cloud Identity o Google Workspace, evita di utilizzare due domini in cui un dominio è un sottodominio dell'altro. Usa invece due domini che non siano sottodomini di un altro. Questa pratica si applica al dominio principale e ai domini secondari.

Non separare Google Workspace e Google Cloud

Se utilizzi già Google Workspace, ad alcuni utenti del tuo account Google Workspace potrebbero essere stati concessi privilegi di super amministratore in modo che possano eseguire attività amministrative.

Agli utenti con privilegi di super amministratore viene concessa implicitamente l'autorizzazione a modificare il criterio IAM (Identity and Access Management) del nodo organizzazione. Questa autorizzazione consente ai super amministratori di assegnarsi il ruolo di amministratore dell'organizzazione o qualsiasi altro ruolo nell'organizzazione Google Cloud. L'accesso come super amministratore a un account Cloud Identity o Google Workspace consente anche a un utente di eliminare l'account, l'organizzazione Google Cloud associata e tutte le relative risorse. Bisogna quindi presumere che i super amministratori abbiano accesso completo a tutte le risorse dell'organizzazione.

Il fatto che i super amministratori siano anche amministratori dell'organizzazione potrebbe rappresentare un problema di sicurezza se gli amministratori esistenti di Google Workspace sono un insieme diverso di utenti rispetto agli utenti che saranno responsabili della gestione dell'organizzazione Google Cloud. In questo caso, potresti decidere di creare un account Cloud Identity separato dedicato a Google Cloud per limitare l'accesso dei super amministratori di Google Workspace alle risorse Google Cloud. La separazione di Google Workspace e Google Cloud può avere diverse conseguenze indesiderate.

Ad esempio, puoi provare a creare utenti separati nell'account Cloud Identity e poi a limitare l'accesso agli utenti dell'organizzazione Google Cloud all'account Cloud Identity. In questo modo il deployment di Google Cloud e Google Workspace sono completamente isolati. Tuttavia, la duplicazione degli utenti influisce negativamente sia sull'esperienza utente sia sull'overhead amministrativo. Inoltre, non potresti ricevere email di notifica inviate da Google Cloud perché il dominio utilizzato da Cloud Identity deve essere diverso da quello utilizzato per Google Workspace e pertanto non è adatto per il routing delle email.

Se invece fai riferimento agli utenti dall'account Google Workspace della tua organizzazione Google Cloud, comprometti l'isolamento tra Google Workspace e Google Cloud:

Fare riferimento agli utenti dell'account Google Workspace della tua organizzazione Google Cloud.

I super amministratori di Google Workspace possono utilizzare la delega a livello di dominio per impersonare qualsiasi utente dello stesso account Google Workspace. Un super amministratore non autorizzato potrebbe utilizzare i propri privilegi elevati per riottenere l'accesso a Google Cloud.

Un approccio più efficace rispetto all'utilizzo di account separati è quello di separare le responsabilità tra gli amministratori di Google Workspace e di Google Cloud al fine di ridurre il numero di super amministratori:

Proteggi il tuo IdP esterno quando utilizzi il Single Sign-On

Cloud Identity e Google Workspace ti consentono di configurare il Single Sign-On con il tuo IdP esterno come Active Directory, Azure Active Directory o Okta, solo per citarne alcuni. Se il Single Sign-On è abilitato, Cloud Identity e Google Workspace considerano attendibile l'IdP esterno per autenticare gli utenti per conto di Google.

L'attivazione del Single Sign-On offre diversi vantaggi:

  • Gli utenti possono utilizzare le proprie credenziali esistenti per accedere ai servizi Google.
  • Gli utenti non dovranno inserire nuovamente la propria password se hanno già una sessione di accesso.
  • Puoi applicare criteri di autenticazione a più fattori coerenti alle tue applicazioni e a tutti i servizi Google.

Tuttavia, l'attivazione del Single Sign-On comporta anche dei rischi. Quando il Single Sign-On è abilitato e un utente deve essere autenticato, Cloud Identity o Google Workspace lo reindirizzano al tuo IdP esterno. Dopo l'autenticazione dell'utente, l'IdP restituisce a Google un'asserzione SAML che dichiara l'identità dell'utente. L'asserzione SAML è firmata. Pertanto, Google può verificare l'autenticità dell'asserzione SAML e verificare che sia stato utilizzato il provider di identità corretto. Tuttavia, Cloud Identity o Google Workspace non hanno modo di verificare che l'IdP abbia preso la decisione di autenticazione corretta e abbia indicato correttamente l'identità dell'utente.

Se è abilitato il Single Sign-On, la sicurezza e l'integrità complessive del deployment di Google dipendono dalla sicurezza e dall'integrità del tuo IdP. Il tuo account Cloud Identity o Google Workspace e tutte le risorse che si basano sugli utenti gestiti dall'account sono a rischio se una delle seguenti opzioni è configurata in modo non sicuro:

  • L'IdP stesso
  • Le macchine su cui è in esecuzione il provider
  • Il database di utenti da cui il provider recupera le informazioni sugli utenti
  • Qualsiasi altro sistema da cui dipende il provider

Per evitare che il Single Sign-On diventi un collegamento debole nella tua strategia di sicurezza, assicurati che l'IdP e tutti i sistemi da cui dipende siano configurati in modo sicuro:

  • Limita il numero di utenti con accesso amministrativo al tuo IdP o a uno qualsiasi dei sistemi su cui fa affidamento il provider.
  • Non concedere agli utenti l'accesso amministrativo a questi sistemi a cui non concedi anche privilegi di super amministratore in Cloud Identity o Google Workspace.
  • Non utilizzare il Single Sign-On se hai dubbi sui controlli di sicurezza in atto per il tuo IdP esterno.

Accesso sicuro alle zone DNS

Gli account Cloud Identity e Google Workspace sono identificati da un nome di dominio DNS principale. Quando crei un nuovo account Cloud Identity o Google Workspace, devi verificare la proprietà del dominio DNS creando un record DNS speciale nella zona DNS corrispondente.

L'importanza del DNS e l'impatto sulla sicurezza complessiva del deployment di Google va oltre il processo di registrazione:

  • Google Workspace si basa sui record MX DNS per il routing delle email. Modificando questi record MX, un utente malintenzionato potrebbe riuscire a indirizzare le email a un server diverso e ottenere l'accesso a informazioni sensibili.

  • Se un utente malintenzionato è in grado di aggiungere record alla zona DNS, potrebbe essere in grado di reimpostare la password di un utente super amministratore e di ottenere l'accesso all'account.

Per evitare che il DNS diventi un collegamento debole nella tua strategia di sicurezza, assicurati che il server DNS sia configurato in modo sicuro:

  • Limita il numero di utenti che hanno accesso amministrativo al server DNS che gestisce il dominio principale utilizzato per Cloud Identity o Google Workspace.

  • Non concedere a utenti l'accesso amministrativo al server DNS a cui non intendi concedere anche i privilegi di super amministratore in Cloud Identity o Google Workspace.

  • Se prevedi di eseguire il deployment su Google Cloud di un carico di lavoro con requisiti di sicurezza che non sono soddisfatti dalla tua infrastruttura DNS esistente, valuta la possibilità di registrare per quel carico di lavoro un nuovo dominio DNS che utilizzi server DNS separati o un servizio DNS gestito.

Esporta gli audit log in BigQuery

Cloud Identity e Google Workspace gestiscono più audit log per tenere traccia delle modifiche alla configurazione e di altre attività che potrebbero essere pertinenti per la sicurezza del tuo account Cloud Identity o Google Workspace. La tabella seguente riassume questi audit log.

Log Attività acquisite
Amministratore Azioni eseguite nella Console di amministrazione Google
Accedi Tentativi di accesso al tuo dominio riusciti, non riusciti e sospetti
Token Istanze di autorizzazione o revoca dell'accesso ad applicazioni web o per dispositivi mobili di terze parti
Gruppi Modifiche ai gruppi e alle iscrizioni ai gruppi

Puoi accedere a questi audit log tramite la Console di amministrazione o l'API Reports. Per la maggior parte degli audit log, i dati vengono conservati per 6 mesi.

Se operi in un settore regolamentato, la conservazione dei dati di audit per 6 mesi potrebbe non essere sufficiente. Per conservare i dati per un periodo di tempo più lungo, configura gli audit log da esportare in BigQuery.

Per limitare il rischio di accesso non autorizzato agli audit log esportati, utilizza un progetto Google Cloud dedicato per il set di dati BigQuery. Per proteggere i dati di controllo da manomissioni o eliminazioni, concedi l'accesso al progetto e al set di dati con il minimo dei privilegi.

Gli audit log di Cloud Identity e Google Workspace sono complementari dei log di Cloud Audit Logs. Se utilizzi BigQuery anche per raccogliere gli audit log di Cloud e altri audit log specifici dell'applicazione, puoi associare gli eventi di accesso alle attività eseguite da un utente in Google Cloud o nelle tue applicazioni. La correlazione dei dati di audit tra più origini può aiutarti a rilevare e analizzare le attività sospette.

La configurazione dell'esportazione in BigQuery richiede una licenza Google Workspace Enterprise. Dopo aver configurato i log di controllo principali, questi vengono esportati per tutti gli utenti, inclusi quelli senza una licenza Google Workspace. Determinati log, come i log di controllo di Drive e dei dispositivi mobili, vengono esportati per gli utenti che hanno almeno una licenza Google Workspace Business.

Se utilizzi Cloud Identity Free per la maggior parte dei tuoi utenti, puoi comunque eseguire l'esportazione in BigQuery aggiungendo Google Workspace Enterprise al tuo account Cloud Identity esistente e acquistando licenze Google Workspace per un insieme selezionato di amministratori.

Organizzazioni

Le organizzazioni ti consentono di organizzare le risorse in una gerarchia di progetti e cartelle, dove il nodo organizzazione è il nodo organizzazione principale. Le organizzazioni sono associate a un account Cloud Identity o Google Workspace e derivano dal nome del dominio principale dell'account associato. Un'organizzazione viene creata automaticamente quando un utente dell'account Cloud Identity o Google Workspace crea un primo progetto.

Ogni account Cloud Identity o Google Workspace può avere una sola organizzazione. In realtà, non è possibile creare un'organizzazione senza un account corrispondente. Nonostante questa dipendenza, puoi concedere agli utenti di account diversi l'accesso alle risorse di una singola organizzazione:

Concedere agli utenti di più account l'accesso alle risorse.

La flessibilità di fare riferimento a utenti di diversi account Cloud Identity o Google Workspace ti consente di separare il modo in cui tratti account e organizzazioni. Puoi separare la decisione sul numero di account Cloud Identity o Google Workspace di cui hai bisogno per gestire i tuoi utenti dalla decisione sul numero di organizzazioni di cui hai bisogno per gestire le tue risorse.

Il numero di organizzazioni che crei e i relativi scopi possono influire profondamente sulla tua strategia di sicurezza, sull'autonomia dei team e dei reparti e sulla coerenza e sull'efficienza dell'amministrazione.

Le seguenti sezioni descrivono le best practice per decidere quante organizzazioni utilizzare.

Utilizzare il maggior numero possibile di organizzazioni, ma quante ne è necessario

La gerarchia delle risorse di un'organizzazione consente di ridurre lo sforzo di gestione dei criteri IAM e dei criteri dell'organizzazione sfruttando l'ereditarietà. Configurando i criteri a livello di cartella o organizzazione, ti assicuri che i criteri vengano applicati in modo coerente in una sottogerarchia di risorse ed eviti operazioni di configurazione ripetitive. Per ridurre al minimo il sovraccarico amministrativo, consigliamo di utilizzare il minor numero possibile di organizzazioni.

Al contrario, utilizzando più organizzazioni, puoi ottenere maggiore flessibilità e autonomia amministrativa. Le sezioni seguenti descrivono i casi in cui potresti richiedere questa maggiore flessibilità o autonomia.

In ogni caso, al momento di decidere quante organizzazioni utilizzare, considera tutti i requisiti che suggeriscono l'utilizzo di più organizzazioni. Poi utilizza il numero minore di organizzazioni che soddisfano i tuoi requisiti.

Utilizzare le organizzazioni per definire l'autorità amministrativa

All'interno di una gerarchia di risorse, puoi concedere le autorizzazioni a livello di risorsa, progetto o cartella. Il livello finale al quale puoi concedere le autorizzazioni di un utente è l'organizzazione.

Un utente a cui è stato assegnato il ruolo Amministratore organizzazione a livello di organizzazione ha il controllo completo sull'organizzazione, sulle relative risorse e sui criteri IAM. Un amministratore dell'organizzazione può assumere il controllo di qualsiasi risorsa all'interno dell'organizzazione ed è libero di delegare l'accesso amministrativo a qualsiasi altro utente.

Tuttavia, le capacità di un Amministratore organizzazione sono limitate all'organizzazione, rendendo quest'ultima l'ambito finale dell'autorità amministrativa:

  • Un amministratore dell'organizzazione non può accedere alle risorse di altre organizzazioni, a meno che non venga concessa esplicitamente l'autorizzazione.
  • Nessun utente esterno all'organizzazione può sottrarre il controllo a un Amministratore organizzazione dell'organizzazione.

Il numero giusto di organizzazioni da utilizzare dipende dal numero di gruppi indipendenti di utenti amministrativi nella tua azienda:

  • Se la tua azienda è organizzata per funzione, potresti avere un singolo reparto che si occupa della supervisione di tutti i deployment Google Cloud.
  • Se la tua azienda è organizzata per divisione o è proprietaria di una serie di consociate gestite autonomamente, potrebbe non esserci un solo reparto responsabile.

Se un singolo reparto è incaricato della supervisione dei deployment di Google Cloud, è preferibile utilizzare un singolo nodo organizzazione Google Cloud. All'interno dell'organizzazione, utilizza le cartelle per strutturare le risorse e assegnare diversi livelli di accesso ad altri team e reparti.

Se hai a che fare con più reparti indipendenti, cercare di centralizzare l'amministrazione utilizzando un'unica organizzazione potrebbe causare problemi:

  • Se designi un singolo reparto per la gestione dell'organizzazione, potresti riscontrare resistenza da altri reparti.
  • Se consenti a più team o reparti di essere co-proprietari di una singola organizzazione, potrebbe essere difficile mantenere una gerarchia delle risorse coerente e garantire che i criteri IAM e i criteri dell'organizzazione vengano utilizzati in modo coerente in tutte le risorse.

Per evitare questo tipo di problema, utilizza più organizzazioni e crea strutture di cartelle separate in ogni organizzazione. Utilizzando organizzazioni separate, puoi stabilire dei confini tra i diversi gruppi di utenti amministrativi, delineando così la loro autorità amministrativa.

Utilizza un'organizzazione temporanea separata

Per garantire la coerenza ed evitare operazioni di configurazione ripetitive, organizza i progetti in una gerarchia di cartelle e applica criteri IAM e dell'organizzazione a livello di cartella o organizzazione.

Esiste uno svantaggio di avere criteri che si applicano a molti progetti e risorse. Qualsiasi modifica al criterio stesso o alla gerarchia delle risorse a cui si applica potrebbe avere conseguenze di vasta portata e indesiderate. Per mitigare questo rischio, ti consigliamo di testare le modifiche ai criteri prima di applicarle nell'organizzazione principale.

Ti consigliamo di creare un'organizzazione temporanea separata. Questa organizzazione ti aiuta a testare le modifiche alla gerarchia delle risorse, i criteri IAM, i criteri dell'organizzazione o altre configurazioni che hanno un potenziale impatto a livello di organizzazione, ad esempio livelli di accesso e criteri.

Per garantire che i risultati dei test o degli esperimenti condotti nell'organizzazione temporanea si applichino anche all'organizzazione di produzione, configura l'organizzazione temporanea in modo che utilizzi la stessa struttura di cartelle dell'organizzazione principale, ma solo con un numero limitato di progetti. In qualsiasi momento, i criteri IAM e dell'organizzazione nell'organizzazione temporanea devono corrispondere ai criteri dell'organizzazione di produzione o riflettere la versione successiva dei criteri che intendi applicare all'organizzazione di produzione.

Come illustrato nel seguente diagramma, utilizzi il tuo account Cloud Identity o Google Workspace gestione temporanea come base per l'organizzazione temporanea. Puoi utilizzare l'account di gestione temporanea (o l'IdP esterno con cui è integrato l'account di gestione temporanea) per creare utenti di test dedicati e una struttura di gruppo che rispecchi i gruppi che utilizzi nell'account Cloud Identity o Google Workspace di produzione. Puoi quindi utilizzare questi utenti e gruppi di test dedicati per testare i criteri IAM senza influire sugli utenti esistenti.

Utilizzo del tuo account come base per la gestione temporanea.

Evita di utilizzare un'organizzazione di test separata

Per ogni carico di lavoro di produzione di cui prevedi di eseguire il deployment su Google Cloud, probabilmente sono necessari uno o più ambienti di test, che i tuoi team di sviluppo e DevOps possono utilizzare per convalidare le nuove release.

Dal punto di vista della sicurezza, per evitare che release non testate influiscano accidentalmente sui carichi di lavoro di produzione, è consigliabile separare in modo pulito gli ambienti di test dagli ambienti di produzione. Analogamente, i due tipi di ambienti hanno requisiti diversi per i criteri IAM. Ad esempio, per garantire a sviluppatori e tester la flessibilità di cui hanno bisogno, i requisiti di sicurezza per gli ambienti di test potrebbero essere notevolmente più larghi rispetto a quelli degli ambienti di produzione.

Come mostra il seguente diagramma, dal punto di vista della configurazione vuoi mantenere i tuoi ambienti di test simili il più possibile agli ambienti di produzione. Qualsiasi divergenza aumenta il rischio che un deployment che funziona correttamente in un ambiente di test abbia esito negativo quando viene eseguito in un ambiente di produzione.

Mantenere gli ambienti di test simili agli ambienti di produzione.

Per trovare un equilibrio tra mantenere gli ambienti isolati e coerenti, utilizza le cartelle all'interno della stessa organizzazione per gestire gli ambienti di test e di produzione:

  • Applica tutti i criteri IAM o dell'organizzazione comuni a tutti gli ambienti a livello di organizzazione (o utilizzando una cartella padre comune).
  • Utilizza le singole cartelle per gestire i criteri IAM e quelli dell'organizzazione che differiscono tra tipi di ambienti diversi.

Non utilizzare la tua organizzazione temporanea per gestire gli ambienti di test. Gli ambienti di test sono fondamentali per la produttività dei team di sviluppo e DevOps. La gestione di questi ambienti nell'ambiente di gestione temporanea limiterebbe la tua possibilità di utilizzare l'organizzazione di gestione temporanea per sperimentare e testare le modifiche ai criteri; qualsiasi modifica di questo tipo potrebbe interrompere il lavoro di questi team. In breve, se utilizzi un'organizzazione temporanea per gestire gli ambienti di test, si mina lo scopo dell'organizzazione temporanea.

Utilizza un'organizzazione separata per sperimentare

Per ottenere il massimo da Google Cloud, consenti ai team di sviluppo, DevOps e operativi di familiarizzare con la piattaforma ed espandere la propria esperienza eseguendo tutorial. Incoraggiali a sperimentare con nuove funzionalità e servizi.

Utilizza un'organizzazione separata come ambiente sandbox per supportare questi tipi di attività sperimentali. Utilizzando un'organizzazione separata, puoi evitare che gli esperimenti siano vincolati a criteri, configurazione o automazione che utilizzi nell'organizzazione di produzione.

Evita di utilizzare la tua organizzazione temporanea per la sperimentazione. L'ambiente gestione temporanea deve utilizzare criteri IAM e dell'organizzazione simili a quelli dell'organizzazione di produzione. Pertanto, è probabile che l'ambiente di gestione temporanea sia soggetto alle stesse limitazioni dell'ambiente di produzione. Allo stesso tempo, allentare norme per consentire gli esperimenti comprometterebbe lo scopo dell'organizzazione temporanea.

Per evitare che la tua organizzazione sperimentale venga disorganizzata, che generi costi eccessivi o diventi un rischio per la sicurezza, definisci in che modo i team sono autorizzati a utilizzare l'organizzazione e chi è responsabile della gestione dell'organizzazione. Inoltre, valuta la possibilità di configurare l'automazione per eliminare automaticamente risorse o addirittura interi progetti dopo un determinato numero di giorni.

Come illustrato nel seguente diagramma, quando crei un'organizzazione per l'esperimento, devi prima creare un account Cloud Identity dedicato. Puoi quindi utilizzare gli utenti esistenti del tuo account Cloud Identity o Google Workspace principale per concedere agli utenti l'accesso all'organizzazione sperimentale.

Organizzazione dell'esperimento.

Per gestire l'account Cloud Identity aggiuntivo, devi avere almeno un account utente super amministratore nell'account Cloud Identity. Per informazioni su come proteggere gli account utente super amministratore, vedi Best practice per gli account super amministratore.

Utilizzare la condivisione limitata al dominio per applicare le relazioni di attendibilità

I criteri IAM consentono di aggiungere come membro qualsiasi identità Google valida. Ciò significa che quando modifichi il criterio IAM di una risorsa, di un progetto, di una cartella o di un'organizzazione, puoi aggiungere membri da origini diverse, tra cui:

  • Gli utenti dell'account Cloud Identity o Google Workspace a cui è associata l'organizzazione, nonché gli account di servizio della stessa organizzazione
  • Utenti di altri account Cloud Identity o Google Workspace
  • Account di servizio di altre organizzazioni
  • Account utente consumer, inclusi gmail.com utenti e account consumer che utilizzano un indirizzo email aziendale

La possibilità di fare riferimento a utenti provenienti da origini diverse è utile per scenari e progetti in cui è necessario collaborare con affiliati o altre aziende. Nella maggior parte degli altri casi, è meglio vincolare i criteri IAM in modo da consentire solo l'accesso ai membri provenienti da origini attendibili.

Utilizza la condivisione limitata al dominio per definire un insieme di account Cloud Identity o Google Workspace attendibili da cui vuoi consentire l'aggiunta di membri ai criteri IAM. Definisci questo criterio dell'organizzazione a livello di organizzazione (in modo che si applichi a tutti i progetti) o in una cartella vicino alla parte superiore della gerarchia delle risorse (per consentire l'esenzione di determinati progetti).

Se utilizzi organizzazioni e account Cloud Identity o Google Workspace distinti per separare gli ambienti di gestione temporanea, produzione ed sperimentazione, utilizza i criteri di condivisione limitati al dominio per applicare la segregazione come indicato nella tabella seguente:

organizzazione Account Cloud Identity o Google Workspace attendibile
Gestione temporanea Gestione temporanea
Production Production
Esperimenti Production

Utilizzare nomi di dominio neutri per le organizzazioni

Le organizzazioni sono identificate da un nome di dominio DNS come example.com. Il nome di dominio deriva dal nome di dominio principale dell'account Cloud Identity o Google Workspace associato.

Se esiste un nome di dominio DNS canonico utilizzato nella tua azienda, utilizza quel dominio come dominio principale nel tuo account di produzione Cloud Identity o Google Workspace. L'utilizzo del nome DNS canonico garantisce che i dipendenti possano riconoscere facilmente il nome del nodo organizzazione.

Se la tua azienda ha più società controllate o possiede vari brand, potrebbe non esistere un nome di dominio canonico. Anziché scegliere arbitrariamente uno dei domini esistenti, valuta la possibilità di registrare un nuovo dominio DNS neutro e dedicato all'utilizzo da parte di Google Cloud. Utilizzando un nome DNS neutro, eviti di esprimere una preferenza per un brand, una società controllata o un reparto specifico all'interno della tua azienda, il che potrebbe influire negativamente sull'adozione del cloud. Aggiungi gli altri domini specifici del brand come domini secondari in modo che possano essere utilizzati negli ID utente e per il Single Sign-On.

Utilizzare gli account di fatturazione nelle organizzazioni Google Cloud

Gli account di fatturazione definiscono chi paga per un determinato insieme di risorse Google Cloud. Sebbene gli account di fatturazione possano esistere all'esterno di un'organizzazione Google Cloud, sono solitamente associati a un'organizzazione.

Quando gli account di fatturazione sono associati a un'organizzazione, vengono considerati una sottorisorsa dell'organizzazione e sono soggetti ai criteri IAM definiti all'interno dell'organizzazione. Soprattutto, questo significa che puoi utilizzare i ruoli IAM di fatturazione per definire quali utenti o gruppi sono autorizzati ad amministrare o utilizzare un account.

Un utente a cui è stato concesso il ruolo Billing Account User può collegare un progetto a un account di fatturazione, di conseguenza le risorse vengono fatturate a questo account. Il collegamento di un progetto a un account di fatturazione funziona all'interno della stessa organizzazione, ma anche tra più organizzazioni.

Se ti rivolgi a più organizzazioni, puoi sfruttare il fatto che gli account di fatturazione possono essere utilizzati in più organizzazioni. In questo modo puoi decidere quanti account di fatturazione ti servono, indipendentemente dal numero di organizzazioni che ti servono.

Il numero corretto di account di fatturazione dipende esclusivamente dai tuoi requisiti commerciali o contrattuali, come la valuta, il profilo pagamenti e il numero di fatture separate di cui hai bisogno. Come hai fatto con account e organizzazioni, per ridurre al minimo la complessità, devi utilizzare il numero minimo di account di fatturazione che soddisfi i tuoi requisiti.

Per suddividere i costi maturati in più organizzazioni, configura il tuo account di fatturazione in modo da esportare i dati di fatturazione in BigQuery. Ogni record esportato in BigQuery contiene non solo il nome e l'ID del progetto, ma anche l'ID dell'organizzazione a cui è associato il progetto (nel campo project.ancestry_numbers).

Passaggi successivi