Best practice per la pianificazione di account e organizzazioni

Last reviewed 2024-06-26 UTC

Questo documento presenta le best practice per decidere quanti Cloud Identity o Google Workspace le organizzazioni Google Cloud e gli account di fatturazione che devi utilizzare. La documento fornisce indicazioni su come identificare un progetto che soddisfi le tue esigenze di sicurezza e requisiti 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. Gli account utente individuali sono definiti come utenti o account utente.

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

Questo documento è rivolto principalmente ai clienti che stanno configurando 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 tutti 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 container è identificato da un nome di dominio come example.com. Per la gestione utenti, gruppi e autenticazione, i due prodotti possono essere considerati equivalenti.

Combina Cloud Identity e Google Workspace in un unico account

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

Se amministri già un account Google Workspace e vuoi attivare utenti di utilizzare Google Cloud, è probabile che tu non voglia assegnare a tutti gli utenti licenza Google Workspace. In questo caso, aggiungi Cloud Identity Free al tuo account esistente. Puoi quindi inserire più utenti senza costi aggiuntivi e decidere quali dovrebbero avere accesso a Google Workspace assegnando loro una licenza Google Workspace.

Allo stesso modo, se amministri già Cloud Identity Free o Premium di destinazione, è consigliabile concedere a determinati utenti il diritto di utilizzare Google Workspace. Invece di creare un ambiente Google Workspace separato account per questi utenti, puoi aggiungi Google Workspace a un account Cloud Identity esistente. Dopo aver assegnato la licenza Google Workspace agli utenti selezionati Gli utenti possono usare 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 amministrativo, è meglio gestire tutti gli utenti tramite un'unica un account Cloud Identity o Google Workspace e fornire un singolo account utente a ogni singolo 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 tranne ai 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 mitigare questi rischi, crea gestione temporanea e produzione Account Cloud Identity o Google Workspace:

  • Utilizza l'account 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 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 disponi di istanze di gestione temporanea e di produzione separate dell'IdP esterno, segui questi passaggi:

  • Integra Cloud Identity o Google Workspace per la gestione temporanea con la tua istanza IdP di gestione temporanea.
  • Integra la tua Cloud Identity di produzione l'account Google Workspace con la tua istanza IdP di produzione.

Ad esempio, supponiamo che tu voglia configurare la federazione con Active Directory e avere una foresta di Active Directory separata a scopo di test. In questo caso, integra la gestione temporanea di Cloud Identity o Google Workspace l'account di servizio con la foresta di gestione temporanea e Cloud Identity Account Google Workspace 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.

Le foreste e i domini di Active Directory di produzione e gestione temporanea potrebbero utilizzare DNS domini che non ti consentono di applicare lo stesso approccio di mappatura di domini per la gestione temporanea e produzione. In questo caso, prendi in considerazione la registrazione di un numero maggiore di Nome Entità utente (UPN) di domini con suffisso nella foresta di gestione temporanea.

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

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

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

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

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

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 di possedere il 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 tutti, possono verificarsi conflitti se hai un altro account Cloud Identity o Google Workspace che utilizza già questo sottodominio. Per evitare questi conflitti, è preferibile utilizzare separati 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 che non siano sottodomini di un altro tipo. Questa prassi si applica al principale dominio e domini secondari.

Non separare Google Workspace e Google Cloud

Se usi già Google Workspace, alcuni utenti del tuo Potrebbe essere stato concesso un account Google Workspace privilegi di super amministratore per poter svolgere le attività amministrative.

Agli utenti con privilegi di super amministratore viene implicitamente concessa l'autorizzazione di modifica il criterio Identity and Access Management (IAM) del nodo organizzazione. Questa autorizzazione consente ai super amministratori di assegnarsi ruolo amministratori 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, potresti decidere di creare con un account Cloud Identity dedicato a Google Cloud, Per limitare l'accesso dei super amministratori di Google Workspace ai dell'accesso a specifiche risorse Google Cloud. 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 limitare l'accesso agli utenti dell'organizzazione Google Cloud all'account Cloud Identity. Questo assicura che il deployment di Google Cloud Google Workspace è completamente isolato. La duplicazione degli utenti negativa incide sia sull'esperienza utente sia sull'overhead amministrativo. Inoltre, non sarai in grado di ricevere email di notifica inviate da Google Cloud perché il dominio utilizzato da Cloud Identity deve essere diverso utilizzato per Google Workspace e pertanto non è adatto al routing 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 della tua organizzazione Google Cloud.

I super amministratori di Google Workspace possono utilizzare 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 è separare le responsabilità tra gli amministratori di Google Workspace e Google Cloud per ridurre il numero di super amministratori:

Proteggi l'IdP esterno quando utilizzi 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 dovranno inserire di nuovo la password se hanno già un sessione di accesso esistente.
  • Puoi applicare criteri di autenticazione a più fattori coerenti su le tue applicazioni e 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 il giorno dopo aver autenticato l'utente, l'IdP restituisce a Google un'asserzione SAML che indica che l'identità dell'utente. L'asserzione SAML è firmata. Pertanto, Google può verificare l'autenticità dell'asserzione SAML e verifica che l'identità sia corretta è stato usato il provider. Tuttavia, non c'è modo per Cloud Identity o Google Workspace per verificare che l'IdP abbia effettuato l'autenticazione corretta e ha dichiarato correttamente l'identità dell'utente.

Se il Single Sign-On è abilitato, la sicurezza e l'integrità generali del tuo account Google Il deployment dipende dalla sicurezza e dall'integrità dell'IdP. Il tuo un account Cloud Identity o Google Workspace e tutte le risorse fare affidamento sugli utenti gestiti dall'account sono a rischio se: configurato in modo non sicuro:

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

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 all'IdP o dai sistemi su cui fa affidamento il provider.
  • 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.

Garantire l'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 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 utente malintenzionato potrebbe di indirizzare le email a un server diverso e di ottenere l'accesso a informazioni.

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

Per evitare che il DNS diventi un punto debole della 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 a nessun utente l'accesso amministrativo al server DNS. non assegnerai inoltre privilegi di super amministratore in Cloud Identity Google Workspace.

  • Se prevedi di eseguire il deployment di un carico di lavoro su Google Cloud con requisiti di sicurezza non soddisfatti dall'infrastruttura DNS esistente, ti consigliamo di registrare per il carico di lavoro 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 degli audit log, i dati vengono conservate per 6 mesi.

Se operi in un settore regolamentato e conservi i dati relativi ai controlli per 6 mesi potrebbero non essere sufficienti. 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 accessi non autorizzati agli audit log esportati, utilizza un un progetto Google Cloud dedicato per il set di dati BigQuery. Per mantenere controllare i dati al sicuro da manomissioni o eliminazioni, concedere l'accesso al progetto e del set di dati con il privilegio minimo.

Gli audit log di Cloud Identity e Google Workspace complementare a Log di controllo di Cloud Audit Logs. Se utilizzi anche BigQuery per raccogliere i log di Cloud Audit Logs e altri audit log specifici dell'applicazione, puoi correlare gli eventi di accesso di attività che un utente ha eseguito in Google Cloud o nel tuo diverse 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 esporta comunque in BigQuery aggiungendo Google Workspace Enterprise a un account Cloud Identity esistente e l'acquisto di licenze Google Workspace per un Google Workspace for Education.

Organizzazioni

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

Ogni account Cloud Identity o Google Workspace può avere una sola organizzazione. Di fatto, non è possibile creare un'organizzazione senza un account corrispondente. Nonostante questa dipendenza, concedere utenti da più account diversi, accedono alle risorse di una singola 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 i loro scopi possono profondere impatto sulla security posture, sull'autonomia dei team e dei reparti la coerenza e l'efficienza dell'amministrazione.

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

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 oltre all'overhead amministrativo, è preferibile utilizzare il minor numero di organizzazioni possibile.

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. Quindi utilizza il modello di organizzazioni che soddisfano i tuoi requisiti.

Utilizza le organizzazioni per definire l'autorità amministrativa

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

Un utente a cui è stato assegnato il ruolo di Amministratore organizzazione presso a livello di organizzazione ha il controllo completo sull'organizzazione, sulle sue risorse e i relativi criteri IAM. Un amministratore dell'organizzazione può assumere il controllo di qualsiasi risorsa all'interno dell'organizzazione ed è libero di delegare le risorse amministrative a qualsiasi altro utente.

Tuttavia, le capacità di un Amministratore organizzazione sono confinate organizzazione, che diventa l'ambito ultimo della gestione autorità:

  • 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 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 responsabile della supervisione di tutti i deployment di Google Cloud.
  • Se la tua azienda è organizzata per reparto o possiede una serie di controllate autonomamente, potrebbe non esserci un solo reparto responsabile.

Se un singolo reparto è responsabile della supervisione di Google Cloud di deployment, è preferibile usare un singolo nodo 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 solo reparto per la gestione dell'organizzazione, altri reparti potrebbero subire resistenza.
  • Se consenti a più team o reparti di co-proprietà di un'unica organizzazione, potrebbe essere difficile mantenere una gerarchia delle risorse coerente assicura che i criteri IAM e i criteri dell'organizzazione siano utilizzati in modo coerente tra le tue 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 limitare questo rischi, è meglio testare le modifiche ai criteri prima di applicarle nella dell'organizzazione.

Ti consigliamo di creare un'organizzazione di gestione temporanea 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 garantire che i risultati dei test o degli esperimenti condotti nella gestione temporanea l'organizzazione applica anche all'organizzazione di produzione, di utilizzare la stessa struttura di cartelle di quella principale, con 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.

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 avranno bisogno di uno o più ambienti di test, che le tue applicazioni I team DevOps possono utilizzare per convalidare le nuove release.

Dal punto di vista della sicurezza, per impedire che release non testate vengano accidentalmente dei carichi di lavoro di produzione, è consigliabile separare ambienti dai tuoi ambienti di produzione. Analogamente, i due tipi di e 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 rigidi di quelli degli ambienti di produzione.

Come mostra il diagramma seguente, dal punto di vista della configurazione, mantieni gli ambienti di test simili agli ambienti di produzione possibile. Qualsiasi divergenza aumenta il rischio che un deployment abbia funzionato correttamente in un ambiente di test non riesce quando viene eseguito il deployment in un ambiente completamente gestito di Google Cloud.

Mantieni gli ambienti di test simili a quelli di produzione.

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

  • Applica qualsiasi criterio IAM o criterio dell'organizzazione che comune tra gli ambienti, a livello di organizzazione (o mediante l'utilizzo di cartella principale).
  • 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. Per gestire questi ambienti ambiente di gestione temporanea limiterebbe la tua capacità di utilizzare l'organizzazione di gestione temporanea per sperimentare e testare le modifiche ai criteri; tali modifiche potrebbero interrompere il lavoro di questi team. In breve, se utilizzi un'organizzazione temporanea per gestire ambienti di test, si compromettono lo scopo dell'organizzazione di gestione temporanea.

Utilizza un'organizzazione separata per l'esperimento

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 nuove funzionalità e servizi.

Utilizza un'organizzazione separata come ambiente sandbox per supportare questi tipi di attività sperimentali. Utilizzando un'organizzazione separata, puoi mantenere esperimenti non vincolati da criteri, configurazione o automazione che nella tua organizzazione di produzione.

Evita di utilizzare organizzazione temporanea per la sperimentazione. Il tuo ambiente di gestione temporanea deve utilizzare IAM che sono simili a quelli della tua organizzazione di produzione. Pertanto, è probabile che l'ambiente di gestione temporanea sia soggetto allo stesso a limiti di costo per l'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 manutenzione. 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 sperimentare, devi prima creare un account Cloud Identity dedicato. Tu e poi utilizza gli utenti esistenti dell'account Cloud Identity principale Account Google Workspace per concedere agli utenti l'accesso alla versione sperimentale dell'organizzazione.

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.

Usa la condivisione limitata 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, a livello di progetto, cartella o organizzazione, puoi aggiungere membri da origini diverse, tra cui:

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

La possibilità di fare riferimento a utenti provenienti da fonti diverse è utile per gli scenari e progetti per i quali è necessario collaborare con affiliati o altre società. 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 sia valido per tutti i progetti) o in una cartella nella parte superiore della risorsa gerarchia (per consentire l'esenzione di determinati progetti).

Se utilizzi account Cloud Identity o Google Workspace separati e organizzazioni per separare le fasi di gestione temporanea, produzione ed sperimentazione utilizzano criteri di condivisione limitati 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. La deriva dal nome di dominio principale dell'associazione un account Cloud Identity o Google Workspace.

Se esiste un nome di dominio DNS canonico utilizzato in tutta l'azienda, di utilizzare quel dominio come dominio principale in Cloud Identity di produzione oppure Account Google Workspace. Utilizzando il nome DNS canonico, ti assicuri che I dipendenti possono riconoscere facilmente il nome del nodo organizzazione.

Se l'azienda ha più società controllate o più brand diversi, potrebbe non esserci un nome di dominio canonico. Invece di scegliere arbitrariamente uno dei domini esistenti, prendi in considerazione la registrazione di un nuovo dominio DNS neutro e dedicato all'uso 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 il tuo specifici del brand, come domini secondari in modo da poterli utilizzare negli ID utente e per il Single Sign-On.

Utilizza gli account di fatturazione in tutte le 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 concesso il ruolo Billing Account User può collegare un progetto a un account di fatturazione, di conseguenza le risorse verranno fatturate a questo account. Il collegamento di un progetto a un account di fatturazione funziona all'interno della stessa organizzazione, ma anche tra le 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 gli account di fatturazione necessari, indipendentemente dal numero di organizzazioni di cui hai bisogno.

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 gli account e le organizzazioni, per ridurre al minimo la complessità, vuoi utilizzare il numero più basso di account di fatturazione 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