Best practice per la pianificazione di account e organizzazioni

Last reviewed 2024-06-26 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 per identificare un design che soddisfi i tuoi requisiti di sicurezza e organizzativi.

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. I singoli account utente sono indicati come utenti o account utente.

  • Le organizzazioni sono contenitori per progetti e risorse all'interno di Google Cloud. Le organizzazioni consentono di strutturare le risorse in modo gerarchico e sono fondamentali per gestirle in modo centralizzato ed efficiente.

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

Account Cloud Identity e Google Workspace

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

Cloud Identity fornisce un sottoinsieme di funzionalità di Google Workspace. Come Google Workspace, Cloud Identity 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 insieme di API e strumenti di amministrazione. 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.

Combinare 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 già amministri 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 eseguire l'onboarding di altri utenti senza costi aggiuntivi e decidere quali utenti devono avere accesso a Google Workspace assegnando loro una licenza Google Workspace.

Analogamente, se gestisci già un account Cloud Identity Free o Premium, potresti voler 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 aver 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 tutti quelli necessari

Per consentire agli utenti di collaborare utilizzando Google Workspace e ridurre al minimo il carico amministrativo, è meglio gestire tutti gli utenti tramite un unico account Cloud Identity o Google Workspace e fornire un singolo account utente a ogni utente. Questo approccio contribuisce ad assicurare che impostazioni come criteri delle password, Single Sign-On e verifica in due passaggi siano applicate in modo coerente a tutti gli utenti.

Nonostante questi vantaggi dell'utilizzo di un singolo account Cloud Identity o Google Workspace, puoi ottenere flessibilità e autonomia amministrativa utilizzando più account. Quando decidi quanti account Cloud Identity o Google Workspace utilizzare, tieni conto di tutti i requisiti che suggeriscono l'utilizzo di più account. Quindi, utilizza il numero minimo di account Cloud Identity o Google Workspace che soddisfano i tuoi requisiti.

Utilizzare account separati per la gestione temporanea e la produzione

Per la maggior parte delle impostazioni che puoi configurare in Cloud Identity e Google Workspace, puoi scegliere l'ambito a cui applicare ogni impostazione. Ad esempio, puoi specificare la posizione geografica dei tuoi dati in base all'utente, al gruppo o all'unità organizzativa. Quando prevedi di applicare una nuova configurazione, puoi inizialmente scegliere un ambito ristretto (ad esempio per utente) e verificare se la configurazione soddisfa le tue aspettative. Dopo aver verificato la configurazione, puoi applicare la stessa impostazione a un insieme più grande 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'attivazione dell'accesso singolo è un'impostazione globale che si applica a tutti gli utenti, ad eccezione dei super amministratori.
  • A seconda dell'IdP esterno, la configurazione del provisioning degli utenti può anche avere un impatto globale. Una configurazione errata accidentale dell'IDP esterno potrebbe portare alla modifica, alla sospensione o addirittura all'eliminazione involontaria degli utenti.

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

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

Se hai istanze di staging e di produzione separate dell'IDP esterno, segui questi passaggi:

  • Integra l'account Cloud Identity o Google Workspace di staging con l'istanza IdP di staging.
  • Integra il tuo account Cloud Identity o Google Workspace di produzione con l'istanza IdP di produzione.

Ad esempio, supponiamo che tu voglia configurare la federazione con Active Directory e di avere una foresta Active Directory separata a scopo di test. In questo caso, integra l'account Cloud Identity o Google Workspace di staging con la foresta di staging e l'account Cloud Identity o Google Workspace di produzione con la foresta principale. Applica lo stesso approccio di mappatura per i domini DNS, gli utenti e i gruppi a entrambe le coppie di foreste/account, come mostrato nel seguente diagramma:

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

I domini e le foreste Active Directory di produzione e di staging potrebbero utilizzare domini DNS che non ti consentono di applicare lo stesso approccio di mappatura dei domini per la produzione e lo staging. In questo caso, valuta la possibilità di registrare altri domini con suffisso del nome principale dell'utente (UPN) nella foresta di staging.

Analogamente, se prevedi di configurare la federazione con Azure Active Directory, è meglio seguire il seguente approccio:

  • Integra l'account Cloud Identity o Google Workspace di staging con un tenant Azure Active Directory di staging.
  • Integra l'account Cloud Identity o Google Workspace di produzione con il tuo tenant Azure Active Directory principale.

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

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

I tenant di Azure Active Directory di produzione e di staging potrebbero utilizzare domini DNS che non ti consentono di applicare lo stesso approccio di mappatura dei domini per l'ambiente di staging e di produzione. In questo caso, ti consigliamo di aggiungere un dominio aggiuntivo al tuo tenant di staging.

Utilizzare domini DNS indipendenti 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 di possederlo. 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 singolarmente, possono verificarsi conflitti se hai un altro account Cloud Identity o Google Workspace che utilizza già questo sottodominio. Per evitare questi conflitti, ti consigliamo di utilizzare domini distinti per ogni account. Ad esempio, se hai bisogno di due account Cloud Identity o Google Workspace, cerca di evitare di utilizzare due domini in cui uno è un sottodominio dell'altro. Utilizza invece due domini che non sono sottodomini di un altro. Questa prassi 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 per consentirgli di svolgere attività amministrative.

Agli utenti con privilegi di super amministratore viene concessa implicitamente l'autorizzazione per modificare il criterio IAM (Identity and Access Management) del nodo dell'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 super amministratore a un account Cloud Identity o Google Workspace consente inoltre a un utente di eliminare l'account, l'organizzazione Google Cloud associata e tutte le relative risorse. Devi quindi assumere che i super amministratori abbiano accesso completo a tutte le risorse all'interno di un'organizzazione.

Il fatto che i super amministratori siano anche amministratori dell'organizzazione potrebbe rappresentare un problema di sicurezza se gli amministratori Google Workspace esistenti sono un insieme di utenti diverso da quello degli utenti che saranno incaricati di gestire la tua organizzazione Google Cloud. In questo caso, puoi 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. Se separi Google Workspace e Google Cloud, potresti riscontrare diverse conseguenze impreviste.

Ad esempio, puoi provare a creare utenti separati nell'account Cloud Identity e poi limitare l'accesso agli utenti dell'organizzazione Google Cloud all'account Cloud Identity. In questo modo, l'implementazione di Google Cloud e Google Workspace sarà completamente isolata. Tuttavia, la duplicazione degli utenti influisce negativamente sia sull'esperienza utente sia sugli oneri amministrativi. Inoltre, non potresti ricevere le email di notifica inviate da Google Cloud perché il dominio utilizzato da Cloud Identity deve essere diverso da quello utilizzato per Google Workspace e quindi non è adatto per l'indirizzamento delle email.

Se fai riferimento agli utenti dell'account Google Workspace nella tua organizzazione Google Cloud, metti in discussione l'isolamento tra Google Workspace e Google Cloud:

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

I super amministratori di Google Workspace possono utilizzare la delega a livello di dominio per rubare l'identità di qualsiasi utente nello stesso account Google Workspace. Un super amministratore malintenzionato potrebbe utilizzare i suoi privilegi elevati per riottenere l'accesso a Google Cloud.

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

Proteggere l'IdP esterno quando si utilizza il Single Sign-On

Cloud Identity e Google Workspace ti consentono di configurare il Single Sign-On con il tuo provider di identità esterno, ad esempio Active Directory, Azure Active Directory o Okta (solo per citarne alcuni). Se il Single Sign-On è abilitato, Cloud Identity e Google Workspace ritengono 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 devono inserire di nuovo le proprie password se hanno già una sessione di accesso esistente.
  • 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 ti espone anche a rischi. Quando il Single Sign-On è attivo e un utente deve essere autenticato, Cloud Identity o Google Workspace reindirizza l'utente al tuo provider di identità esterno. Dopo aver autenticato l'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 dichiarato correttamente l'identità dell'utente.

Se Single Sign-On è abilitato, la sicurezza e l'integrità complessive del tuo 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 uno dei seguenti elementi è configurato in modo non sicuro:

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

Per evitare che l'accesso singolo diventi un punto debole nella tua strategia di sicurezza, assicurati che l'IdP e tutti i sistemi di cui dipende siano configurati in modo sicuro:

  • Limita il numero di utenti con accesso amministrativo alla tua IdP o a uno dei sistemi su cui si basa il fornitore.
  • Non concedere l'accesso amministrativo a questi sistemi a utenti a cui non conferiresti anche i privilegi di super amministratore in Cloud Identity o Google Workspace.
  • Non utilizzare il Single Sign-On se hai dubbi sui controlli di sicurezza applicati al tuo provider di identità esterno.

Proteggi l'accesso alle tue 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 tuo deployment di Google vanno oltre la procedura di registrazione:

  • Google Workspace si basa su record MX DNS per instradare le email. Modificando questi record MX, un malintenzionato potrebbe essere in grado di indirizzare le email a un altro server e ottenere l'accesso a informazioni sensibili.

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

Per evitare che il DNS diventi un punto debole nella tua strategia di sicurezza, assicurati che il tuo 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 l'accesso amministrativo al server DNS a nessun utente a cui non conferiresti anche i privilegi di super amministratore in Cloud Identity o Google Workspace.

  • Se prevedi di eseguire il deployment di un workload su Google Cloud con requisiti di sicurezza non soddisfatti dall'infrastruttura DNS esistente, ti consigliamo di registrare per il workload un nuovo dominio DNS che utilizzi server DNS separati o un servizio DNS gestito.

Esportare i log di controllo in BigQuery

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

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

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

Se operi in un settore regolamentato, la conservazione dei dati di controllo per 6 mesi potrebbe non essere sufficiente. Per conservare i dati per un periodo di tempo più lungo, configura i log di controllo in modo che vengano esportati in BigQuery.

Per limitare il rischio di accesso non autorizzato ai log di controllo 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 in base al principio del privilegio minimo.

Gli audit log di Cloud Identity e Google Workspace sono complementari ai log degli audit cloud. Se utilizzi BigQuery anche per raccogliere gli audit log di Cloud e altri audit log specifici per l'applicazione, puoi correlare gli eventi di accesso alle attività eseguite da un utente in Google Cloud o nelle tue applicazioni. La possibilità di correlare i dati di controllo in più origini può aiutarti a rilevare e analizzare 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 licenza Google Workspace. Alcuni log, come i log di controllo Drive e Dispositivi mobili, vengono esportati per gli utenti che dispongono di 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, con il nodo dell'organizzazione come principale. Le organizzazioni sono associate a un account Cloud Identity o Google Workspace e prendono il nome dal nome di dominio principale dell'account associato. Un'organizzazione viene creata automaticamente quando un utente dell'account Cloud Identity o Google Workspace crea il primo progetto.

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

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

La flessibilità di fare riferimento agli utenti di diversi account Cloud Identity o Google Workspace ti consente di differenziare il modo in cui gestisci gli account e le organizzazioni. Puoi separare la decisione su quanti account Cloud Identity o Google Workspace ti servono per gestire gli utenti dalla decisione su quante organizzazioni ti servono per gestire le risorse.

Il numero di organizzazioni che crei e le relative finalità possono incidere profondamente sulla tua strategia di sicurezza, sull'autonomia dei tuoi team e reparti e sulla coerenza ed efficienza della tua amministrazione.

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

Utilizza il minor numero possibile di organizzazioni, ma tutte quelle necessarie

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

Al contrario, puoi ottenere maggiore flessibilità e autonomia amministrativa utilizzando più organizzazioni. Le sezioni seguenti descrivono quando potresti avere bisogno di questa flessibilità o autonomia aggiuntiva.

In ogni caso, quando decidi quante organizzazioni utilizzare, tieni conto di tutti i requisiti che suggeriscono di utilizzare più organizzazioni. Utilizza quindi il numero minimo di organizzazioni che soddisfano i tuoi requisiti.

Utilizzare le organizzazioni per delimitare l'autorità amministrativa

All'interno di una gerarchia di risorse, puoi concedere autorizzazioni a livello di risorsa, progetto o cartella. Il livello più alto a cui puoi concedere autorizzazioni a un utente è l'organizzazione.

Un utente a cui è stato assegnato il ruolo di Amministratore organizzazione a livello di organizzazione ha il controllo completo sull'organizzazione, sulle sue risorse e sui suoi 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 funzionalità di un Amministratore organizzazione#39;organizzazione sono limitate all'organizzazione, che rappresenta l'ambito ultimo dell'autorità amministrativa:

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

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

  • Se la tua azienda è organizzata per funzioni, potresti avere un unico dipartimento incaricato di supervisionare tutti i deployment di Google Cloud.
  • Se la tua azienda è organizzata per divisioni o possiede una serie di società controllate autonome, potrebbe non esserci un unico reparto responsabile.

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

Se hai a che fare con più reparti indipendenti, provare a centralizzare l'amministrazione utilizzando una singola organizzazione potrebbe causare problemi:

  • Se designi un singolo reparto per gestire l'organizzazione, potresti dover fare i conti con la resistenza di altri reparti.
  • Se consenti a più team o reparti di essere comproprietari di un'unica organizzazione, potrebbe essere difficile mantenere una gerarchia delle risorse coerente e assicurarti che i criteri IAM e quelli dell'organizzazione vengano utilizzati in modo coerente nelle risorse.

Per evitare questo tipo di problemi, utilizza più organizzazioni e crea strutture di cartelle separate in ogni organizzazione. Se utilizzi organizzazioni separate, stabilisci dei confini tra diversi gruppi di utenti amministrativi, definendo così la loro autorità amministrativa.

Utilizzare un'organizzazione di staging separata

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

Esistono degli svantaggi nell'avere criteri che si applicano a molti progetti e risorse. Qualsiasi modifica al criterio stesso o alla gerarchia delle risorse a cui si applica il criterio potrebbe avere conseguenze di vasta portata e indesiderate. Per ridurre questo rischio, è meglio testare le modifiche ai criteri prima di applicarle nell'organizzazione principale.

Ti consigliamo di creare un'organizzazione di staging separata. Questa organizzazione ti consente di 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, come livelli di accesso e criteri.

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

Come mostrato nel seguente diagramma, utilizzi il tuo account Cloud Identity o Google Workspace di staging come base per l'organizzazione di staging. Utilizzi l'account di staging (o l'IDP esterno con cui è integrato) per creare utenti di test dedicati e una struttura di gruppo che rispecchi i gruppi che utilizzi nel tuo 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.

Utilizzare il tuo account come base per l'implementazione.

Evita di utilizzare un'organizzazione di test separata

Per ogni carico di lavoro di produzione che prevedi di eseguire su Google Cloud, probabilmente hai bisogno di uno o più ambienti di test che i tuoi team di sviluppo e DevOps possano utilizzare per convalidare le nuove release.

Dal punto di vista della sicurezza, per evitare che le release non testate influiscano accidentalmente sui carichi di lavoro di produzione, devi separare nettamente gli ambienti di test dagli ambienti di produzione. Analogamente, i due tipi di ambienti hanno requisiti diversi per i criteri IAM. Ad esempio, per concedere a sviluppatori e tester la flessibilità di cui hanno bisogno, i requisiti di sicurezza per gli ambienti di test potrebbero essere notevolmente meno stringenti di quelli degli ambienti di produzione.

Come mostrato nel seguente diagramma, dal punto di vista della configurazione, è consigliabile mantenere gli ambienti di test il più simili possibile agli ambienti di produzione. Qualsiasi divergenza aumenta il rischio che un deployment che ha funzionato correttamente in un ambiente di test non vada a buon fine quando viene eseguito in un ambiente di produzione.

Mantieni gli ambienti di test simili a quelli 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 eventuali criteri IAM o criteri dell'organizzazione comuni a tutti gli ambienti a livello di organizzazione (o utilizzando una cartella principale comune).
  • Utilizza le singole cartelle per gestire i criteri IAM e quelli dell'organizzazione che differiscono tra i diversi tipi di ambienti.

Non utilizzare la tua organizzazione di staging 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 staging limiterebbe la tua capacità di utilizzare l'organizzazione di staging per eseguire esperimenti e testare le modifiche ai criteri. Qualsiasi modifica di questo tipo potrebbe interrompere il lavoro di questi team. In breve, se utilizzi un'organizzazione di staging per gestire gli ambienti di test, ne minimizzerai lo scopo.

Utilizzare un'organizzazione separata per le sperimentazioni

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

Utilizza un'organizzazione separata come ambiente sandbox per supportare questi tipi di attività sperimentali. Utilizzando un'organizzazione separata, puoi mantenere gli esperimenti indipendenti da criteri, configurazioni o automazioni che utilizzi nella tua organizzazione di produzione.

Evita di utilizzare la tua organizzazione di staging per gli esperimenti. L'ambiente di gestione temporanea deve utilizzare i criteri IAM e dell'organizzazione simili a quelli dell'organizzazione di produzione. Pertanto, l'ambiente di staging è probabilmente soggetto alle stesse limitazioni dell'ambiente di produzione. Allo stesso tempo, l'allentamento delle norme per consentire gli esperimenti minerebbe lo scopo della tua organizzazione di staging.

Per evitare che l'organizzazione sperimentale diventi disorganizzata, generi costi eccessivi o rappresenti un rischio per la sicurezza, emetti linee guida che definiscano in che modo i team possono utilizzare l'organizzazione e chi è responsabile della sua gestione. Inoltre, ti consigliamo di configurare l'automazione per eliminare automaticamente le risorse o persino interi progetti dopo un determinato numero di giorni.

Come mostrato nel seguente diagramma, quando crei un'organizzazione per gli esperimenti, devi prima creare un account Cloud Identity dedicato. Poi, utilizza 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 disporre di almeno un account utente super amministratore nell'account Cloud Identity. Per informazioni su come proteggere questi account utente super amministratore, consulta le best practice per gli account super amministratore.

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

I criteri IAM ti 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:

  • Utenti dell'account Cloud Identity o Google Workspace a cui è associata l'organizzazione, nonché 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 gli utenti gmail.com e gli account consumer che utilizzano un indirizzo email aziendale

La possibilità di fare riferimento agli utenti di origini diverse è utile per scenari e progetti in cui devi collaborare con affiliati o altre aziende. Nella maggior parte degli altri casi, è meglio limitare i criteri IAM in modo da consentire solo gli utenti 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 nella parte superiore della gerarchia delle risorse (per consentire l'esenzione di determinati progetti).

Se utilizzi account Cloud Identity o Google Workspace e organizzazioni distinti per separare gli ambienti di staging, di produzione e di sperimentazione, utilizza i criteri di condivisione con limitazioni al dominio per applicare la separazione come indicato nella tabella seguente:

Organizzazione Account Cloud Identity o Google Workspace attendibile
Gestione temporanea Gestione temporanea
Produzione Produzione
Esperimenti Produzione

Utilizza nomi di dominio neutri per le organizzazioni

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

Se esiste un nome di dominio DNS canonico utilizzato in tutta l'azienda, utilizzalo come dominio principale nel tuo account Cloud Identity o Google Workspace di produzione. Se utilizzi il nome DNS canonico, assicurarti che i dipendenti possano riconoscere facilmente il nome del nodo dell'organizzazione.

Se la tua azienda ha diverse filiali o possiede una serie di brand diversi, potrebbe non esserci un nome di dominio canonico. Anziché scegliere arbitrariamente uno tra i domini esistenti, ti consigliamo di registrare un nuovo dominio DNS neutro e dedicato all'utilizzo da parte di Google Cloud. Se utilizzi un nome DNS neutro, eviterai di esprimere una preferenza per un brand, una filiale 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 l'accesso singolo.

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 al di fuori di un'organizzazione Google Cloud, in genere sono associati a un'organizzazione.

Quando gli account di fatturazione sono associati a un'organizzazione, sono considerati una risorsa secondaria dell'organizzazione e sono soggetti ai criteri IAM definiti al suo interno. Soprattutto, 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 assegnato il ruolo Billing Account User può collegare un progetto a un account di fatturazione, in modo che le risorse vengano fatturate a questo account. Il collegamento di un progetto a un account di fatturazione funziona all'interno della stessa organizzazione, ma anche tra organizzazioni.

Se utilizzi 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.

Il numero corretto di account di fatturazione dipende esclusivamente dai tuoi requisiti commerciali o contrattuali come valuta, profilo pagamenti e numero di fatture separate di cui hai bisogno. Come per gli account e le organizzazioni, per ridurre al minimo la complessità, ti consigliamo di utilizzare il minor numero di account di fatturazione possibile per soddisfare 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