Scegli una gerarchia delle risorse per la tua zona di destinazione Google Cloud

Last reviewed 2024-10-31 UTC

Una gerarchia delle risorse ti aiuta a organizzare le risorse in Google Cloud. Questo documento descrive come scegliere la gerarchia delle risorse nell'ambito del design della landing zone. È rivolto ad amministratori di sistemi cloud, architetti e professionisti tecnici coinvolti nella progettazione della gerarchia delle risorse. Questo documento fa parte di una serie sulle zone di destinazione. Sono incluse gerarchie di esempio che mostrano i modi comuni in cui le aziende possono strutturare le risorse in Google Cloud.

Fattori di progettazione per la gerarchia delle risorse

Quando definisci la gerarchia delle risorse in Google Cloud, devi considerare il funzionamento attuale della tua organizzazione e lo stato finale ideale della trasformazione cloud. Il modo migliore per gestire le risorse si basa sul modo in cui la tua organizzazione intende lavorare nel cloud. Poiché ogni organizzazione è diversa, non esiste un unico approccio migliore per la gerarchia delle risorse.

Tuttavia, ti consigliamo di evitare di mappare la struttura dell'organizzazione aziendale alla gerarchia delle risorse. Concentrati invece sulle esigenze e sulle operazioni della tua attività in Google Cloud.

Gerarchia delle risorse di Google Cloud

La gerarchia delle risorse in Google Cloud inizia dal nodo radice, chiamato organizzazione. Consigliamo alle attività di avere un solo nodo principale, ad eccezione di situazioni specifiche. Definisci i livelli inferiori della gerarchia utilizzando cartelle e progetti, e crei cartelle all'interno di cartelle per creare la gerarchia. Puoi creare i progetti che ospitano i tuoi carichi di lavoro a qualsiasi livello della gerarchia.

Il seguente diagramma mostra un nodo principale denominato Organization e cartelle ai livelli uno, due e tre. I progetti e le sottocartelle vengono creati nelle cartelle di livello 2.

Gerarchia di esempio con nodo radice, cartelle e progetti.

Fattori della gerarchia delle risorse

Quando decidi la gerarchia delle risorse, prendi in considerazione i seguenti fattori:

  • Chi è responsabile delle risorse cloud? Si tratta di reparti, filiali, team tecnici o persone giuridiche?
  • Quali sono le tue esigenze di conformità?
  • Hai eventi aziendali imminenti, come fusioni, acquisizioni e spin-off?

Comprendere le interazioni delle risorse nella gerarchia

I criteri dell'organizzazione vengono ereditati dai discendenti nella gerarchia delle risorse, ma possono essere sostituiti dai criteri definiti a un livello inferiore. Per ulteriori informazioni, consulta la sezione Informazioni sulla valutazione della gerarchia. Utilizzi i vincoli dei criteri dell'organizzazione per impostare linee guida per l'intera organizzazione o per parti significative e consentire comunque eccezioni.

I criteri di autorizzazione, precedentemente noti come criteri IAM vengono ereditati dai discendenti e i criteri di autorizzazione a livelli inferiori sono additivi. Tuttavia, i criteri di autorizzazione possono essere sostituiti dai criteri di rifiuto, che consentono di limitare le autorizzazioni a livello di progetto, cartella e organizzazione. I criteri di rifiuto vengono applicati prima dei criteri di autorizzazione.

Devi inoltre tenere conto di quanto segue:

Punti decisionali per la progettazione della gerarchia delle risorse

Il seguente diagramma di flusso mostra gli aspetti da considerare per scegliere la gerarchia delle risorse migliore per la tua organizzazione.

Decisioni per le gerarchie delle risorse.

Il diagramma precedente illustra i seguenti punti decisionali:

  1. Le diverse controllate, i gruppi regionali o le business unit hanno requisiti delle norme molto diversi?
    1. In caso affermativo, segui il design in base alla regione o alle filiali.
    2. In caso contrario, vai al punto di decisione successivo.

  2. I tuoi team di prodotto o di carico di lavoro richiedono una forte autonomia per i propri criteri? Ad esempio, non disponi di un team di sicurezza centrale che determina i criteri per tutti i team di prodotti o carichi di lavoro.

    1. Se sì, consulta il design basato sul framework di responsabilità.

    2. In caso contrario, consulta la sezione Progettazione in base all'ambiente dell'applicazione.

Il tuo caso d'uso specifico potrebbe portarti a progettare un'altra gerarchia delle risorse rispetto a quella suggerita dal grafico decisionale. La maggior parte delle organizzazioni sceglie un approccio ibrido e seleziona design diversi a diversi livelli della gerarchia delle risorse, iniziando con il design che influisce maggiormente su criteri e accesso.

Opzione 1: gerarchia basata sugli ambienti di applicazione

In molte organizzazioni, vengono definiti criteri e controlli di accesso diversi per diversi ambienti di applicazione, come sviluppo, produzione e test. Avere criteri separati standardizzati in ogni ambiente semplifica la gestione e la configurazione. Ad esempio, potresti avere criteri di sicurezza più stringenti negli ambienti di produzione rispetto a quelli di test.

Utilizza una gerarchia basata sugli ambienti di applicazione se si verificano le seguenti condizioni:

  • Hai ambienti di applicazione separati con requisiti di gestione e norme diversi.
  • Hai requisiti di sicurezza o di controllo centralizzati che un team di sicurezza centrale deve essere in grado di applicare in modo coerente a tutti i dati e i carichi di lavoro di produzione.
  • Per accedere alle risorse Google Cloud in ambienti diversi, sono necessari ruoli IAM (Identity and Access Management) diversi.

Evita questa gerarchia se è vera una delle seguenti condizioni:

  • Non esegui più ambienti di applicazione.
  • Non hai dipendenze dell'applicazione e processi aziendali diversi tra gli ambienti.
  • Esistono notevoli differenze nelle norme per regioni, team o applicazioni diverse.

Il seguente diagramma mostra una gerarchia per example.com, una società di tecnologia finanziaria fittizia.

Diagramma dell'opzione 1.

Come mostrato nel diagramma precedente, example.com ha tre ambienti di applicazione con criteri, controlli dell'accesso, requisiti normativi e procedure diversi. Gli ambienti sono i seguenti:

  • Ambiente di sviluppo e QA: questo ambiente è gestito da sviluppatori che sono sia dipendenti interni che consulenti. Eseguono push di codice in modo continuo e sono responsabili del controllo qualità. Questo ambiente non è mai disponibile per i consumatori della tua attività. L'ambiente ha requisiti di integrazione e autenticazione meno rigidi rispetto all'ambiente di produzione e agli sviluppatori vengono assegnati ruoli approvati con autorizzazioni adeguate. L'ambiente di sviluppo e QA è progettato solo per le offerte di applicazioni standard di example.com.

  • Ambiente di test: questo ambiente viene utilizzato per i test di regressione e delle applicazioni e supporta le offerte business-to-business (B2B) dei clienti di example.com che utilizzano le API example.com. A questo scopo, example.com crea due tipi di progetti:

    • Progetti di test interni per completare la regressione interna, il rendimento e la configurazione per le offerte B2B.
    • Progetti UAT del cliente con supporto multi-tenant in modo che i clienti B2B possano convalidare le proprie configurazioni e allinearsi ai requisiti di example.com per esperienza utente, branding, flussi di lavoro, report e così via.

  • Ambiente di produzione: questo ambiente ospita tutte le offerte di prodotti convalidate, accettate e lanciate. Questo ambiente è soggetto ai regolamenti del Payment Card Industry Data Security Standard (PCI DSS), utilizza moduli di sicurezza hardware (HSM) e si integra con elaboratori di terze parti per elementi quali autenticazione e pagamenti. I team di audit e conformità sono stakeholder fondamentali di questo ambiente. L'accesso a questo ambiente è strettamente controllato e limitato principalmente ai processi di deployment automatizzati.

Per ulteriori informazioni sulla progettazione di una gerarchia basata sugli ambienti di applicazione, consulta Struttura dell'organizzazione nel progetto della piattaforma di base per le aziende.

Opzione 2: gerarchia basata su regioni o filiali

Alcune organizzazioni operano in più regioni e hanno società controllate che svolgono attività in aree geografiche diverse o sono il risultato di fusioni e acquisizioni. Queste organizzazioni richiedono una gerarchia delle risorse che utilizzi le opzioni di scalabilità e gestione di Google Cloud e mantenga l'indipendenza per i diversi processi e criteri esistenti tra le regioni o le filiali. Questa gerarchia utilizza le filiali o le regioni come livello di cartella più alto nella gerarchia delle risorse. Le procedure di deployment in genere si concentrano sulle regioni.

Utilizza questa gerarchia se è vera la seguente condizione:

  • Regioni o filiali diverse operano in modo indipendente.
  • Le regioni o le società controllate hanno strutture di base operative, offerte di piattaforme digitali e procedure diverse.
  • La tua attività ha standard di conformità e normativi diversi per regioni o filiali.

Il seguente diagramma mostra un esempio di gerarchia di un'organizzazione globale con due società controllate e un gruppo di società controllate con una struttura regionalizzata.

Diagramma dell'opzione 2.

Il diagramma precedente ha la seguente struttura gerarchica:

  • Al primo livello si trovano le seguenti cartelle:
    • Le cartelle Subsidiary 1 e Subsidiary 2 rappresentano le due società consociate dell'azienda che hanno criteri e autorizzazioni di accesso diversi rispetto al resto dell'organizzazione. Ogni controllata utilizza IAM per limitare l'accesso ai propri progetti e alle risorse Google Cloud.
    • La cartella Holding group rappresenta i gruppi con criteri comuni di alto livello nelle varie regioni.
    • La cartella Bootstrap rappresenta le risorse comuni necessarie per eseguire il deployment dell'infrastruttura Google Cloud, come descritto nel progetto di base per le aziende.
  • Al secondo livello, all'interno della cartella Holding di gruppo, sono presenti le seguenti cartelle:
    • Le cartelle APAC, EMEA e Americas rappresentano le varie regioni all'interno del gruppo che hanno governance, autorizzazioni di accesso e criteri diversi.
    • La cartella Shared infrastructure rappresenta le risorse utilizzate a livello globale in tutte le regioni.
  • All'interno di ogni cartella sono presenti vari progetti che contengono le risorse di cui sono responsabili queste filiali o regioni.

Puoi aggiungere altre cartelle per separare persone giuridiche, reparti e team diversi all'interno della tua azienda.

Opzione 3: gerarchia basata su un framework di responsabilità

Una gerarchia basata su un framework di responsabilità funziona meglio quando i prodotti vengono gestiti in modo indipendente o quando le unità organizzative hanno team chiaramente definiti che possiedono il ciclo di vita dei prodotti. In queste organizzazioni, i proprietari di prodotto sono responsabili dell'intero ciclo di vita del prodotto, inclusi processi, assistenza, criteri, sicurezza e diritti di accesso. I tuoi prodotti sono indipendenti tra loro e le linee guida e i controlli a livello di organizzazione sono rari.

Utilizza questa gerarchia quando si verifica quanto segue:

  • Gestisci un'organizzazione che ha una proprietà e una responsabilità chiare per ogni prodotto.
  • I tuoi carichi di lavoro sono indipendenti e non condividono molti criteri comuni.
  • Le tue procedure e le piattaforme per sviluppatori esterni vengono offerte come servizi o prodotti.

Il seguente diagramma mostra una gerarchia di esempio per un fornitore di piattaforme di e-commerce.

Diagramma dell'opzione 3.

Il diagramma precedente ha la seguente struttura gerarchica:

  • Le seguenti cartelle si trovano al primo livello:
    • Le cartelle denominate Ecommerce Modules e Logistics and Warehousing Modules rappresentano i moduli all'interno dell'offerta della piattaforma che richiedono le stesse autorizzazioni di accesso e gli stessi criteri durante il ciclo di vita del prodotto.
    • La cartella Reconciliation and Billing rappresenta i team di prodotto responsabili dei moduli end-to-end per componenti aziendali specifici all'interno dell'offerta della piattaforma.
    • La cartella Bootstrap rappresenta le risorse comuni necessarie per eseguire il deployment dell'infrastruttura Google Cloud, come descritto nel progetto di base per le aziende.
  • All'interno di ogni cartella sono presenti vari progetti che contengono i moduli indipendenti di cui sono responsabili diversi team di prodotto.

Per ulteriori informazioni, consulta la gerarchia delle risorse del framework Terraform di Fabric FAST.

Best practice per la gerarchia delle risorse

Le seguenti sezioni descrivono le best practice per la progettazione della gerarchia delle risorse che consigliamo, indipendentemente dalla gerarchia delle risorse scelta.

Per altre best practice su come configurare gli account e le organizzazioni Cloud Identity e Google Workspace, consulta Best practice per la pianificazione di account e organizzazioni.

Utilizzare un singolo nodo organizzazione

Per evitare il sovraccarico di gestione, utilizza un singolo nodo dell'organizzazione, se possibile. Tuttavia, ti consigliamo di utilizzare più nodi dell'organizzazione per gestire i seguenti casi d'uso:

  • Vuoi testare modifiche sostanziali ai livelli IAM o alla gerarchia delle risorse.
  • Vuoi eseguire esperimenti in un ambiente sandbox che non abbia gli stessi criteri dell'organizzazione.
  • La tua organizzazione include società secondarie che potrebbero essere vendute o gestite come entità completamente separate in futuro.

Utilizza convenzioni di denominazione standardizzate

Utilizza una convenzione di denominazione standardizzata in tutta l'organizzazione. Il blueprint per le basi della sicurezza ha una convenzione di denominazione di esempio che puoi adattare alle tue esigenze.

Mantieni separate le risorse di bootstrap e i servizi comuni

Mantieni cartelle separate per l'avvio dell'ambiente Google Cloud utilizzando l'infrastruttura come codice (IaC) e per i servizi comuni condivisi tra ambienti o applicazioni. Posiziona la cartella di bootstrap direttamente sotto il nodo dell'organizzazione nella gerarchia delle risorse.

Posiziona le cartelle per i servizi comuni a diversi livelli della gerarchia, a seconda della struttura scelta.

Posiziona la cartella per i servizi comuni direttamente sotto il nodo dell'organizzazione quando è vero quanto segue:

  • La gerarchia utilizza gli ambienti di applicazione al livello più alto e i team o le applicazioni al secondo livello.
  • Hai servizi condivisi come il monitoraggio che sono comuni tra gli ambienti.

Posiziona la cartella per i servizi comuni a un livello inferiore, sotto le cartelle dell'applicazione, quando si verificano le seguenti condizioni:

  • Hai servizi condivisi tra le applicazioni ed esegui il deployment di un'istanza distinta per ogni ambiente di deployment.

  • Le applicazioni condividono microservizi che richiedono sviluppo e test per ogni ambiente di deployment.

Il seguente diagramma mostra un esempio di gerarchia in cui è presente una cartella dell'infrastruttura condivisa utilizzata da tutti gli ambienti e dalle cartelle dei servizi condivisi per ogni ambiente di applicazione a un livello inferiore della gerarchia:

Gerarchia di esempio con cartella dell'infrastruttura condivisa.

Il diagramma precedente ha la seguente struttura gerarchica:

  • Le cartelle del primo livello sono le seguenti:
    • Le cartelle Development environment e Production environment contengono gli ambienti di applicazione.
    • La cartella Shared infrastructure contiene risorse comuni condivise tra gli ambienti, ad esempio il monitoraggio.
    • La cartella Bootstrap contiene le risorse comuni necessarie per eseguire il deployment dell'infrastruttura Google Cloud, come descritto nel progetto di base per le aziende.
  • Al secondo livello sono presenti le seguenti cartelle:
    • Una cartella in ogni ambiente per ogni applicazione (App 1 e App 2) che contiene le risorse per queste applicazioni.
    • Una cartella Shared per entrambi gli ambienti di applicazione che contiene servizi condivisi tra le applicazioni, ma indipendenti per ciascun ambiente. Ad esempio, potresti avere un progetto di secret a livello di cartella in modo da poter applicare criteri di autorizzazione diversi ai tuoi secret di produzione e non di produzione.
  • All'interno di ogni cartella dell'applicazione sono presenti vari progetti che contengono i moduli indipendenti che fanno parte di ogni applicazione.

Passaggi successivi