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 di container per utenti e gruppi. Questi account sono quindi fondamentali l'autenticazione degli utenti aziendali e la gestione dell'accesso dell'accesso a specifiche risorse Google Cloud. Cloud Identity o L'account Google Workspace indica una directory di utenti, non una account utente individuale. 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 cloud-native.

Account Cloud Identity e Google Workspace

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

Cloud Identity fornisce un sottoinsieme della piattaforma Google Workspace le funzionalità di machine learning. 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 lo stesso concetto e utilizzano lo stesso set di API e strumenti amministrativi. 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 di account possibile, ma il maggior numero necessario

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 aiuta a garantire che le impostazioni come criteri relativi alle password, Single Sign-On e verifica in due passaggi vengono applicate in modo coerente a tutti gli utenti.

Nonostante i vantaggi derivanti dall'utilizzo di una sola Cloud Identity Google Workspace, puoi usufruire di flessibilità e funzionalità amministrative autonomia grazie all'uso di più account. Quando decidi quanti Account Cloud Identity o Google Workspace da utilizzare, prendi in considerazione tutti che implicano l'utilizzo di più account. Quindi utilizza il numero più piccolo di account Cloud Identity o Google Workspace che soddisfano le tue i tuoi requisiti.

Utilizzare account separati per la gestione temporanea e la produzione

Per la maggior parte delle impostazioni configurabili in Cloud Identity Google Workspace, puoi scegliere l'ambito a cui ogni impostazione ad esempio, puoi specificare la posizione geografica dei tuoi dati per utente, gruppo o unità organizzativa. Quando prevedi di applicare una nuova configurazione, all'inizio puoi scegliere un ambito ridotto (ad esempio, in base all'utente) e verifica se la configurazione soddisfa le tue aspettative. Dopo aver completato la verifica 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 L'account Google Workspace con un provider di identità (IdP) esterno ha un impatto globale:

  • Attivazione del Single Sign-On è un'impostazione globale che si applica a tutti gli utenti tranne i super amministratori.
  • A seconda dell'IdP esterno, anche la configurazione del provisioning degli utenti hanno un impatto globale. Un errore di configurazione accidentale nell'IdP esterno potrebbero comportare inavvertitamente modifiche, sospensione o persino eliminazione 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 prova negli account temporanei che tu e altri possono essere usate dagli amministratori per verificare le modifiche alla configurazione. Ma non concedere l'accesso dei tuoi utenti all'account gestione temporanea.

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 mapping l'approccio per Domini DNS, utenti, e gruppi a entrambe le coppie di foresta/account, come illustrato nel seguente diagramma:

Approccio alla 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:

  • Integrare Cloud Identity o Google Workspace per la gestione temporanea con un tenant di Azure Active Directory per la gestione temporanea.
  • 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 in entrambe le coppie tenant/account:

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

I tenant di Azure Active Directory di produzione e gestione temporanea potrebbero utilizzare 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 altro dominio alla gestione temporanea. tenant.

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

Quando aggiungi per la prima volta un dominio, ad esempio example.com al tuo un account Cloud Identity o Google Workspace, devi verificare la proprietà del dominio. Dopo aver aggiunto e verificato un dominio, puoi aggiungere sottodomini come marketing.example.com e finance.example.com senza doverli verificare singolarmente 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, evita di utilizzare due domini dove un dominio è 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 da 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. La presenza di un super amministratore l'accesso a un account Cloud Identity o Google Workspace consente a un utente di eliminare l'account Google Cloud associato dell'organizzazione e di tutte le sue risorse. Devi quindi presupporre che le gli amministratori hanno accesso completo a tutte le risorse all'interno di un'organizzazione.

Il fatto che i super amministratori siano anche amministratori dell'organizzazione può essere un problema di sicurezza se gli attuali amministratori di Google Workspace sono un un insieme diverso di utenti rispetto a quelli che saranno incaricati di gestire il tuo dell'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 in Cloud Identity e poi limitare l'accesso all'account Cloud Identity da parte degli utenti dell'organizzazione Google Cloud. 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 invece fai riferimento agli utenti dall'account Google Workspace nel tuo un'organizzazione Google Cloud, comprometti l'isolamento tra Google Workspace e Google Cloud:

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

I super amministratori di Google Workspace possono utilizzare delega a livello di dominio per impersonare qualsiasi utente nello stesso account Google Workspace. Un rogue il super amministratore potrebbe utilizzare i propri privilegi elevati per riottenere l'accesso in Google Cloud.

Un approccio più efficace rispetto all'utilizzo di account separati consiste nel separare responsabilità tra Google Workspace e Google Cloud di ridurre il numero di super amministratori:

Proteggi l'IdP esterno quando utilizzi il Single Sign-On

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

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'abilitazione del Single Sign-On ti espone a dei rischi. Se il Single Sign-On è abilitato e l'utente deve essere autenticato, Cloud Identity Google Workspace reindirizza l'utente al tuo IdP 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 il Single Sign-On diventi un anello debole nella tua security posture, assicurati che l'IdP e tutti i sistemi da 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 nessun utente a cui non concederà nemmeno i privilegi di super amministratore in Cloud Identity Google Workspace.
  • Non utilizzare Single Sign-On se hai dubbi sui controlli di sicurezza per l'IdP esterno.

Accesso sicuro alle zone DNS

Gli account Cloud Identity e Google Workspace sono identificati da una il nome di dominio DNS principale. Quando crei una nuova versione di Cloud Identity l'account Google Workspace, devi verificare la proprietà del dominio DNS creando un record DNS speciale nel DNS corrispondente zona di destinazione.

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

  • Google Workspace si basa su Record MX DNS per il routing delle 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 anello debole nella tua security posture, assicurati che se il server DNS è configurato in modo sicuro:

  • Limita il numero di utenti che hanno accesso amministrativo al DNS server che gestisce il dominio principale utilizzato per Cloud Identity 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 su Google Cloud di un carico di lavoro con funzionalità di sicurezza a requisiti non soddisfatti dalla tua infrastruttura DNS esistente, registrando per quel carico di lavoro un nuovo dominio DNS che utilizza DNS separati o un servizio DNS gestito.

Esporta gli audit log in BigQuery

Cloud Identity e Google Workspace gestiscono più audit log per tenere traccia delle modifiche alla configurazione e di altre attività che potrebbero per la sicurezza della tua Cloud Identity Account Google Workspace. La tabella seguente riassume questi controlli logaritmi.

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 dispositivi mobili o web di terze parti applicazioni
Gruppi Modifiche ai gruppi e alle iscrizioni ai gruppi

Puoi accedere a questi audit log tramite il Console di amministrazione o tramite 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, configurare gli audit log per l'esportazione 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 audit tra più origini può ti aiutano a rilevare e analizzare le attività sospette.

Configurare l'esportazione in BigQuery richiede una licenza Google Workspace Enterprise. Dopo aver configurato il principale log di controllo, vengono esportati per tutti gli utenti, inclusi quelli che non hanno licenza Google Workspace. Alcuni log come Drive e Mobile i log di controllo vengono esportati per gli utenti che hanno almeno un Google Workspace Licenza commerciale.

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 un solo è un'unica 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:

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

La flessibilità di fare riferimento a utenti di Cloud Identity o Gli account Google Workspace ti consentono di separare le modalità di trattamento degli account e organizzazioni. Puoi separare la decisione relativa gli account Cloud Identity o Google Workspace necessari per gestire gli utenti decidendo di quante organizzazioni 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.

Utilizzare il minor numero di organizzazioni possibile, ma il maggior numero necessario

La gerarchia delle risorse di un'organizzazione consente di ridurre gestire i criteri IAM e i criteri dell'organizzazione prendendo vantaggio dell'ereditarietà. Configurando i criteri a livello di cartella o organizzazione a livello, ti assicuri che i criteri vengano applicati in modo coerente all'interno di una sottogerarchia di risorse ed eviterai 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 usando più organizzazioni. Le seguenti sezioni descrivono quando è possibile richiedono una maggiore flessibilità o autonomia.

In ogni caso, quando decidi quante organizzazioni utilizzare, considera tutte che suggeriscono l'uso di 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 le autorizzazioni a livello di risorsa, a livello di 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 in altri a meno che non venga concessa un'autorizzazione esplicita.
  • Nessun utente esterno all'organizzazione può sottrarre il controllo a una Amministratore di quell'organizzazione.

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

  • Se la tua azienda è organizzata per funzione, potrebbe essere presente un solo reparto 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, puoi utilizzare le cartelle per strutturare le risorse e concedere di accesso ad altri team e reparti.

Se hai a che fare con più reparti indipendenti, cercando di centralizzare l'amministrazione utilizzando un'unica 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 di cartelle separate in ogni organizzazione. Usando le opzioni aziende, stabilisci dei confini tra diversi gruppi utenti amministrativi, delineando così la loro autorità amministrativa.

Utilizza un'organizzazione di gestione temporanea separata

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

C'è uno svantaggio di avere criteri che si applicano a molti progetti Google Cloud. Qualsiasi modifica al criterio stesso o alla gerarchia delle risorse del criterio potrebbero avere conseguenze indesiderate e di vasta portata. 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 consente di testare le modifiche alla gerarchia delle risorse, i criteri IAM o altre configurazioni che hanno potenziali impatto a livello di organizzazione, ad esempio livelli di accesso e norme.

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 ruoli IAM i criteri dell'organizzazione nell'organizzazione di gestione temporanea devono corrispondere della tua organizzazione di produzione o dovrebbe riflettere la versione successiva i criteri che intendi applicare alla tua organizzazione di produzione.

Come mostra il diagramma seguente, utilizzi il tuo dell'account di gestione temporanea di Cloud Identity o Google Workspace come base per l'organizzazione di gestione temporanea. Utilizzi l'account gestione temporanea (o per creare un IdP esterno con cui è integrato il tuo account di gestione temporanea gli utenti di test e una struttura di gruppi che rispecchia i gruppi che utilizzi un account di produzione Cloud Identity o Google Workspace. Puoi utilizza questi utenti e gruppi di test dedicati per testare 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. Per Ad esempio, per concedere a sviluppatori e tester la flessibilità che cercano i requisiti di sicurezza per gli ambienti di test potrebbero essere rispetto a 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.

Mantenere ambienti di test simili agli ambienti 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 dell'organizzazione e che differiscono a seconda del tipo di ambiente.

Non utilizzare organizzazione temporanea per la gestione degli ambienti di test. Gli ambienti di test sono fondamentali 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, lascia che il tuo team di sviluppo, DevOps i team operativi prendono dimestichezza con la piattaforma ed ampliano un'esperienza ottimale eseguendo tutorial. Incoraggiali a sperimentare nuove funzionalità e servizi.

Utilizza un'organizzazione separata come ambiente sandbox per supportare questi tipi delle 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. L'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, norme più rilassanti consentire gli esperimenti andrebbe a minare lo scopo della gestione temporanea dell'organizzazione.

Per evitare che l'organizzazione sperimentale venga disorganizzata, da generare costi eccessivi o diventare un rischio per la sicurezza, risolvere i problemi che definiscono in che modo i team sono autorizzati a utilizzare l'organizzazione e chi sopporta la responsabilità di mantenere l'organizzazione. Inoltre, valuta la possibilità di impostare sull'automazione per eliminare automaticamente risorse o persino interi progetti per un determinato numero di giorni.

Come mostra il diagramma seguente, quando crei un'organizzazione devi prima creare un account Cloud Identity dedicato. Tu e poi utilizza gli utenti esistenti della piattaforma 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 avere almeno uno nell'account Cloud Identity. Per informazioni su come proteggere questi account utente super amministratore, vedi 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 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 vincolare i criteri IAM a Consenti membri provenienti da fonti attendibili.

Utilizza le funzionalità di condivisione limitata al dominio per definire un insieme di account Cloud Identity o Google Workspace affidabili account da cui vuoi consentire l'aggiunta di membri a IAM criteri. 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

Utilizzare nomi di dominio neutrali 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 è presente 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. Utilizzando un nome DNS neutro, evitare di esprimere una preferenza per un brand, una società controllata o un reparto specifico. all'interno dell'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

Definizione degli account di fatturazione che paga per un determinato insieme di risorse Google Cloud. Sebbene gli account di fatturazione possano esistere al di fuori di Google Cloud sono spesso associati a un'organizzazione.

Quando gli account di fatturazione sono associati a un'organizzazione, vengono considerati una sottorisorsa dell'organizzazione e sono soggette a IAM i criteri definiti all'interno dell'organizzazione. Ciò significa che puoi puoi utilizzare Ruoli IAM di fatturazione per definire quali utenti o gruppi possono 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 ti avvali di più organizzazioni, puoi approfittare del 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 dalla requisiti commerciali o contrattuali ad esempio 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 ripartire i costi maturati in più organizzazioni, configura account di fatturazione a esportare i dati di fatturazione in BigQuery. Ogni record esportato in BigQuery non contiene solo il progetto il nome e l'ID, ma anche l'ID dell'organizzazione a cui è associato il progetto (nel campo project.ancestry_numbers).

Passaggi successivi