Best practice per la pianificazione di account e organizzazioni

Last reviewed 2024-06-26 UTC

Questo documento presenta le best practice per decidere quanti account Cloud Identity o Google Workspace, organizzazioni e account di fatturazione devi utilizzare. Google Cloud Il documento fornisce indicazioni per identificare una progettazione che soddisfi i 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 tue risorseGoogle Cloud . Un account Cloud Identity o Google Workspace indica una directory di utenti, non un account utente individuale. Gli account utente individuali sono denominati 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 gestire le risorse in modo centralizzato ed efficiente.

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 ti consentono di gestire utenti, gruppi e autenticazione.

Cloud Identity offre un sottoinsieme delle 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 insieme 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.

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

Allo stesso modo, se amministri 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 possono 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 sovraccarico amministrativo, è consigliabile gestire tutti gli utenti tramite un unico account Cloud Identity o Google Workspace e fornire un unico account utente a ogni persona. Questo approccio contribuisce a garantire che le impostazioni come le policy per le password, il Single Sign-On e la verifica in due passaggi vengano applicate in modo coerente a tutti gli utenti.

Nonostante questi vantaggi dell'utilizzo di un unico 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, considera tutti i requisiti che suggeriscono di utilizzare più account. Poi utilizza il numero più piccolo di account Cloud Identity o Google Workspace che soddisfi 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 in cui deve essere applicata ogni impostazione. Ad esempio, puoi specificare la posizione geografica dei dati per utente, per gruppo o per unità organizzativa. Quando prevedi di applicare una nuova configurazione, puoi inizialmente scegliere un ambito ridotto (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ù 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'attivazione del Single Sign-On è 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ò avere anche un impatto globale. Una configurazione errata accidentale nel provider di identità esterno potrebbe comportare la modifica, la sospensione o persino l'eliminazione involontaria degli utenti.

Per mitigare questi rischi, utilizza account Cloud Identity o Google Workspace di staging e produzione separati:

  • Utilizza l'account di staging per verificare eventuali modifiche alla 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. ma non concedere ai tuoi utenti l'accesso all'account di staging.

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

  • Integra il tuo 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 la tua istanza IdP di produzione.

Ad esempio, supponi di voler 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 a domini DNS, utenti e gruppi per entrambe le coppie di foreste/account, come mostrato nel seguente diagramma:

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

Le foreste e i domini Active Directory di produzione e staging potrebbero utilizzare domini DNS che non consentono di applicare lo stesso approccio di mappatura dei domini per staging e produzione. In questo caso, valuta la possibilità di registrare più domini suffisso del nome principale utente (UPN) nella foresta di staging.

Analogamente, se prevedi di configurare la federazione con Azure Active Directory, è consigliabile adottare 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 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 Azure Active Directory di produzione e staging potrebbero utilizzare domini DNS che non consentono di applicare lo stesso approccio di mappatura dei domini per staging e produzione. In questo caso, valuta la possibilità di aggiungere un dominio aggiuntivo al tenant di staging.

Utilizzare domini DNS disgiunti tra 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 essere il proprietario del dominio. 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, possono verificarsi conflitti se hai un altro account Cloud Identity o Google Workspace che utilizza già questo sottodominio. Per evitare questi conflitti, preferisci utilizzare domini disgiunti 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 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 per consentire loro di svolgere attività amministrative.

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

Il fatto che i super amministratori siano anche amministratori dell'organizzazione potrebbe essere un problema di sicurezza se gli amministratori di Google Workspace esistenti sono un insieme di utenti diverso da quelli che si occuperanno della gestione della tua organizzazioneGoogle Cloud . In questo caso, potresti decidere di creare un account Cloud Identity separato dedicato a Google Cloudper limitare l'accesso dei super amministratori Google Workspace alle risorseGoogle Cloud . La separazione di Google Workspace e Google Cloud può avere diverse conseguenze impreviste.

Ad esempio, potresti 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, la tua Google Cloud implementazione e Google Workspace saranno completamente isolate. Tuttavia, la duplicazione degli utenti influisce negativamente sia sull'esperienza utente sia sul sovraccarico 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 dell'account Google Workspace nella tua organizzazioneGoogle Cloud , comprometti 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 impersonare 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 è quello di separare le responsabilità tra Google Workspace e gli Google Cloud amministratori per ridurre il numero di super amministratori:

Proteggere l'IdP esterno quando utilizzi Single Sign-On

Cloud Identity e Google Workspace ti consentono di configurare il Single Sign-On con il tuo IdP esterno, ad esempio Active Directory, Azure Active Directory o Okta (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 devono inserire di nuovo le 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 dei rischi. Quando il Single Sign-On è attivato e un utente deve essere autenticato, Cloud Identity o Google Workspace reindirizza l'utente al tuo IdP esterno. Dopo l'autenticazione dell'utente, l'IdP restituisce a Google un'asserzione SAML che indica 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 possono verificare che l'IdP abbia preso la decisione di autenticazione corretta e abbia dichiarato correttamente l'identità dell'utente.

Se è attivato Single Sign-On, 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 fornitore
  • Il database utenti da cui il fornitore recupera le informazioni sugli utenti
  • Qualsiasi altro sistema da cui dipende il fornitore

Per evitare che il Single Sign-On diventi un punto debole della tua postura di sicurezza, assicurati che il tuo 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 si basa il provider.
  • Non concedere l'accesso amministrativo a questi sistemi a nessun utente a cui non concederesti anche i privilegi di super amministratore in Cloud Identity o Google Workspace.
  • Non utilizzare Single Sign-On se non hai la certezza dei controlli di sicurezza in vigore per il tuo IdP esterno.

Accesso sicuro 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 della tua implementazione di Google vanno oltre la procedura di registrazione:

  • Google Workspace si basa sui record MX DNS per il routing delle email. Se vengono modificati, un malintenzionato potrebbe essere in grado di indirizzare le email a un altro server e accedere a informazioni sensibili.

  • Se un malintenzionato è in grado di aggiungere record alla zona DNS, potrebbe quindi 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 della tua postura di sicurezza, assicurati che il server DNS sia configurato in modo sicuro:

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

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

  • Se prevedi di eseguire il deployment di un workload su Google Cloud che ha requisiti di sicurezza che non sono soddisfatti dalla tua infrastruttura DNS esistente, valuta la possibilità di registrare per quel 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 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 seguente tabella riepiloga 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 ad 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 audit per 6 mesi potrebbe non essere sufficiente. Per conservare i dati per un periodo di tempo più lungo, configura l'esportazione dei log di controllo 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 audit da manomissioni o eliminazioni, concedi l'accesso al progetto e al set di dati in base al principio del privilegio minimo.

I log di controllo di Cloud Identity e Google Workspace sono complementari ai log di Cloud Audit Logs. Se utilizzi anche BigQuery per raccogliere i log di Cloud Audit Logs e altri log di controllo specifici dell'applicazione, puoi correlare gli eventi di accesso alle attività che un utente ha eseguito 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 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. Alcuni log, come i log di controllo Drive e Mobile, vengono esportati per gli utenti che dispongono almeno di una licenza Google Workspace Business.

Se utilizzi Cloud Identity Free per la maggior parte degli utenti, puoi esportare comunque 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 consentono di organizzare le risorse in una gerarchia di progetti e cartelle, con il nodo organizzazione come radice. Le organizzazioni sono associate a un account Cloud Identity o Google Workspace e derivano 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 un 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 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 necessari per gestire gli utenti dalla decisione sul numero di organizzazioni necessarie per gestire le risorse.

Il numero di organizzazioni che crei e i loro scopi possono influire profondamente sulla tua postura 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 consente di ridurre lo sforzo di gestione dei criteri IAM e delle policy dell'organizzazione sfruttando l'ereditarietà. Configurando i criteri a livello di cartella o organizzazione, ti assicuri che vengano applicati in modo coerente a una gerarchia secondaria di risorse ed eviti un lavoro di configurazione ripetitivo. Per ridurre al minimo l'overhead amministrativo, è consigliabile utilizzare il minor numero possibile di organizzazioni.

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

In ogni caso, quando decidi quante organizzazioni utilizzare, tieni conto di tutti i requisiti che suggeriscono di utilizzarne più di una. Poi utilizza il numero più piccolo di organizzazioni che soddisfa i tuoi requisiti.

Utilizzare le organizzazioni per delineare l'autorità amministrativa

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

Un utente a cui è stato assegnato il ruolo di Amministratore organizzazione a livello di organizzazione ha il controllo completo dell'organizzazione, delle sue risorse e delle sue policy 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 è l'ambito ultimo dell'autorità amministrativa:

  • Un amministratore dell'organizzazione non può accedere a nessuna risorsa in altre organizzazioni, a meno che non gli venga concessa esplicitamente l'autorizzazione.
  • Nessun utente esterno all'organizzazione può sottrarre il controllo a un Amministratore organizzazionee dell'organizzazione.

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

  • Se la tua azienda è organizzata per funzione, potresti avere un unico dipartimento incaricato di supervisionare tutte le Google Cloud implementazioni.
  • Se la tua azienda è organizzata per divisione o possiede una serie di filiali gestite autonomamente, potrebbe non esserci un unico reparto responsabile.

Se un singolo reparto è responsabile della supervisione Google Cloud delle implementazioni, è meglio utilizzare un singolo nodo Google Cloud dell'organizzazione. 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, il tentativo di centralizzare l'amministrazione utilizzando una sola organizzazione potrebbe causare attrito:

  • Se designi un unico reparto per gestire l'organizzazione, potresti incontrare resistenza da parte di altri reparti.
  • Se consenti a più team o reparti di condividere la proprietà di una singola organizzazione, potrebbe essere difficile mantenere una gerarchia delle risorse coerente e garantire che le policy IAM e le policy dell'organizzazione vengano utilizzate in modo coerente in tutte le risorse.

Per evitare questo tipo di attrito, utilizza più organizzazioni e crea strutture di cartelle separate in ogni organizzazione. Utilizzando organizzazioni separate, stabilisci i limiti tra diversi gruppi di utenti amministrativi, delineando 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 le policy IAM e le policy dell'organizzazione a livello di cartella o organizzazione.

Lo svantaggio di avere criteri che si applicano a molti progetti e risorse è che Qualsiasi modifica al criterio stesso o alla gerarchia delle risorse a cui si applica potrebbe avere conseguenze di vasta portata e indesiderate. Per ridurre questo rischio, è consigliabile testare le modifiche ai criteri prima di applicarle nella tua organizzazione principale.

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

Per garantire che i risultati dei test o degli esperimenti condotti nell'organizzazione di staging si applichino anche all'organizzazione di produzione, configura l'organizzazione di staging in modo che utilizzi la stessa struttura di cartelle dell'organizzazione principale, ma con un numero ridotto 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 mostra il 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 il provider di identità esterno con cui è integrato l'account di staging) per creare utenti di test dedicati e una struttura di gruppo che rispecchi i gruppi utilizzati 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 lo staging.

Evita di utilizzare un'organizzazione di test separata

Per ogni workload di produzione che prevedi di eseguire il deployment su Google Cloud, probabilmente hai bisogno di 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 le release non testate influiscano accidentalmente sui carichi di lavoro di produzione, è consigliabile separare chiaramente gli ambienti di test da quelli di produzione. Allo stesso modo, i due tipi di ambienti hanno requisiti diversi per i criteri IAM. Ad esempio, per consentire a sviluppatori e tester la flessibilità di cui hanno bisogno, i requisiti di sicurezza per gli ambienti di test potrebbero essere molto meno rigidi di quelli degli ambienti di produzione.

Come mostra il seguente diagramma, dal punto di vista della configurazione, devi 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 riesca quando viene eseguito il deployment in un ambiente di produzione.

Mantenere gli ambienti di test simili agli ambienti di produzione.

Per trovare un equilibrio tra l'isolamento e la coerenza degli ambienti, utilizza le cartelle all'interno della stessa organizzazione per gestire gli ambienti di test e produzione:

  • Applica tutti i criteri IAM o dell'organizzazione comuni tra gli ambienti a livello di organizzazione (o utilizzando una cartella principale comune).
  • Utilizza le singole cartelle per gestire le policy IAM e le policy 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 sperimentare e testare le modifiche alle policy; 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, comprometti lo scopo dell'organizzazione di staging.

Utilizzare un'organizzazione separata per gli esperimenti

Per ottenere il massimo da Google Cloud, invita i tuoi team di sviluppo, DevOps e operazioni a familiarizzare con la piattaforma ed espandere la loro esperienza eseguendo i tutorial. Incoraggiali a sperimentare nuove funzionalità e servizi.

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

Evita di utilizzare la tua organizzazione di staging per gli esperimenti. L'ambiente di gestione temporanea deve utilizzare IAM e norme dell'organizzazione simili a quelle dell'organizzazione di produzione. Pertanto, è probabile che l'ambiente di staging sia soggetto alle stesse limitazioni dell'ambiente di produzione. Allo stesso tempo, il rilassamento delle norme per consentire gli esperimenti minerebbe lo scopo della tua organizzazione di staging.

Per evitare che la tua organizzazione sperimentale diventi disorganizzata, generi costi eccessivi o diventi un rischio per la sicurezza, emetti linee guida che definiscano come i team sono autorizzati a utilizzare l'organizzazione e chi è responsabile della sua manutenzione. Inoltre, valuta la possibilità di configurare l'automazione per eliminare automaticamente le risorse o anche interi progetti dopo un determinato numero di giorni.

Come mostra il seguente diagramma, quando crei un'organizzazione per fare esperimenti, devi prima creare un account Cloud Identity dedicato. Quindi, utilizza gli utenti esistenti del tuo account Cloud Identity o Google Workspace principale per concedere agli utenti l'accesso all'organizzazione sperimentale.

Organizzazione degli esperimenti.

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 Best practice per gli account super amministratore.

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

I criteri IAM consentono di aggiungere qualsiasi identità Google valida come membro. Ciò significa che quando modifichi il criterio IAM di una risorsa, di un progetto, di una cartella o di un'organizzazione, puoi aggiungere membri provenienti 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 a utenti di origini diverse è utile per scenari e progetti in cui devi collaborare con affiliati o altre società. Nella maggior parte degli altri casi, è meglio limitare i criteri IAM in modo che consentano solo i membri di origini attendibili.

Utilizza la condivisione con limitazioni del 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 a livello di cartella vicino alla parte superiore della gerarchia delle risorse (per consentire l'esenzione di determinati progetti).

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

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

Utilizzare nomi di dominio neutri per le organizzazioni

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

Se nella tua azienda viene utilizzato un nome di dominio DNS canonico, utilizza questo dominio come dominio principale nel tuo account Cloud Identity o Google Workspace di produzione. Utilizzando il nome DNS canonico, ti assicuri che i dipendenti possano riconoscere facilmente il nome del nodo dell'organizzazione.

Se la tua azienda ha diverse filiali o possiede una varietà di brand diversi, 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 account di fatturazione in più Google Cloud organizzazioni

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, sono più comunemente associati a un'organizzazione. Google Cloud

Quando gli account di fatturazione sono associati a un'organizzazione, vengono considerati una risorsa secondaria dell'organizzazione e sono soggetti ai criteri IAM definiti all'interno dell'organizzazione. Ancora più importante, ciò significa che puoi utilizzare i ruoli IAM per la 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, facendo 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 diverse.

Se utilizzi più organizzazioni, puoi sfruttare il fatto che gli account di fatturazione possono essere utilizzati in più organizzazioni. In questo modo puoi decidere il numero di account di fatturazione necessari 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 hai fatto con gli account e le 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 accumulati in più organizzazioni, configura il tuo account di fatturazione per 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