Decidi una gerarchia di risorse per la tua zona di destinazione Google Cloud

Last reviewed 2023-08-31 UTC

Una gerarchia di risorse aiuta a organizzare le risorse in Google Cloud. Questo documento descrive come scegliere la gerarchia delle risorse nell'ambito della progettazione della zona di destinazione. È destinata agli amministratori di sistema, agli architetti e ai professionisti tecnici cloud coinvolti nella progettazione della gerarchia delle risorse. Questo documento fa parte di una serie sulle zone di destinazione. Include gerarchie di esempio che dimostrano modi comuni in cui le aziende possono strutturare le risorse in Google Cloud.

Fattori di progettazione per la gerarchia delle risorse

Quando definisci la tua gerarchia delle risorse in Google Cloud, devi considerare come funziona oggi la tua organizzazione e lo stato finale ideale della trasformazione del cloud. Il modo migliore per gestire le risorse è basato sul modo previsto di lavorare nel cloud della tua organizzazione. Poiché ogni organizzazione è diversa, non esiste un 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 aziendali e sulle operazioni in Google Cloud.

Gerarchia delle risorse di Google Cloud

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

Il seguente diagramma mostra un nodo radice chiamato Organization e le cartelle ai livelli uno, due e tre. I progetti e le sottocartelle vengono creati nelle cartelle del livello due.

Gerarchia di esempio con nodo radice, cartelle e progetti.

Fattori della gerarchia delle risorse

Quando decidi la gerarchia delle risorse, considera i seguenti fattori:

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

Informazioni sulle interazioni delle risorse in tutta la gerarchia

I criteri dell'organizzazione sono ereditati dai discendenti nella gerarchia delle risorse, ma possono essere sostituiti dai criteri definiti a un livello inferiore. Per ulteriori informazioni, consulta Comprendere la valutazione della gerarchia. Puoi utilizzare i vincoli dei criteri dell'organizzazione per impostare linee guida per l'intera organizzazione o per parti significative dell'organizzazione e continuare a consentire le eccezioni.

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

Devi inoltre prendere in considerazione quanto segue:

Punti decisionali per la progettazione della gerarchia delle risorse

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

Decisioni per le gerarchie di risorse.

Il diagramma precedente illustra i seguenti punti decisionali:

  1. Le diverse società controllate, gruppi regionali o unità aziendali hanno requisiti delle norme molto diversi?
    1. In caso affermativo, segui la progettazione in base alla regione o alle società controllate.
    2. In caso contrario, passa al punto decisionale successivo.

  2. I team di prodotti o carichi di lavoro richiedono una forte autonomia rispetto ai criteri? Ad esempio, non hai un team per la sicurezza centrale che stabilisce i criteri per tutti i team di carichi di lavoro o di prodotto.

    1. In caso affermativo, consulta la struttura basata sul framework di responsabilizzazione.

    2. In caso contrario, consulta la progettazione basata sull'ambiente di applicazione.

Il tuo caso d'uso specifico potrebbe portarti a una progettazione della gerarchia delle risorse diversa da quella suggerita dal grafico decisionale. La maggior parte delle organizzazioni sceglie un approccio ibrido e seleziona progettazioni diverse a diversi livelli della gerarchia delle risorse, a partire da quella che influisce maggiormente sui criteri e sull'accesso.

Opzione 1: gerarchia basata sugli ambienti applicativi

In molte organizzazioni definisci criteri e controlli di accesso diversi per ambienti applicativi diversi, 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ù rigorosi negli ambienti di produzione rispetto a quelli di test.

Utilizza una gerarchia basata sugli ambienti applicativi se si verifica quanto segue:

  • Esistono ambienti applicativi distinti che hanno requisiti di criteri e di amministrazione diversi.
  • Hai requisiti di sicurezza o audit centralizzati che un team di sicurezza centrale deve essere in grado di applicare in modo coerente su tutti i dati e i carichi di lavoro di produzione.
  • Hai bisogno di diversi ruoli IAM (Identity and Access Management) per accedere alle risorse Google Cloud in ambienti diversi.

Evita questa gerarchia se si verifica quanto segue:

  • Non esegui più ambienti applicativi.
  • Non hai dipendenze delle applicazioni e processi aziendali variabili negli ambienti.
  • Esistono forti differenze tra i criteri a seconda dell'area geografica, dei team o delle applicazioni.

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 applicativi con criteri, controlli dell'accesso, requisiti normativi e processi diversi. Gli ambienti sono i seguenti:

  • Ambiente di sviluppo e QA: questo ambiente è gestito da sviluppatori che sono sia dipendenti interni che consulenti. Esegue continuamente il push del codice e sono responsabili del controllo di qualità. Questo ambiente non è mai disponibile per i consumatori della tua azienda. L'ambiente ha requisiti di integrazione e autenticazione meno rigorosi rispetto all'ambiente di produzione e agli sviluppatori vengono assegnati ruoli approvati con autorizzazioni appropriate. 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 test di regressione e test delle applicazioni e supporta le offerte business-to-business (B2B) dei client example.com che utilizzano le API example.com. A questo scopo, example.com crea due tipi di progetto:

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

  • Ambiente di produzione: questo ambiente ospita tutte le offerte di prodotti che sono stati convalidati, accettati e lanciati. Questo ambiente è soggetto alle normative PCI DSS (Payment Card Industry Data Security Standard), utilizza moduli di sicurezza hardware (HSM) e si integra con processori di terze parti per elementi come l'autenticazione e le procedure di pagamento. I team di controllo e conformità sono stakeholder fondamentali di questo ambiente. L'accesso a questo ambiente è strettamente controllato e limitato principalmente a processi di deployment automatizzati.

Per saperne di più sulla progettazione di una gerarchia basata sugli ambienti applicativi, consulta Struttura organizzativa nel progetto di base dell'azienda.

Opzione 2: gerarchia basata sulle regioni o sulle società controllate

Alcune organizzazioni operano in molte regioni e hanno consociate che operano in diverse aree geografiche 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 dai diversi processi e criteri esistenti tra le regioni o le società controllate. Questa gerarchia utilizza consociate o regioni come livello di cartella più alto nella gerarchia delle risorse. Le procedure di deployment sono in genere concentrate sulle regioni.

Utilizza questa gerarchia se si verifica quanto segue:

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

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

Diagramma dell'opzione 2.

Il diagramma precedente ha la seguente struttura gerarchica:

  • Le seguenti cartelle si trovano al primo livello:
    • Le cartelle Subsidiary 1 e Subsidiary 2 rappresentano le due società controllate dell'azienda che hanno autorizzazioni di accesso e criteri diversi dal resto dell'organizzazione. Ogni società controllata utilizza IAM per limitare l'accesso ai propri progetti e alle risorse Google Cloud.
    • La cartella Holding group rappresenta i gruppi che hanno criteri comuni di alto livello tra le regioni.
    • La cartella Bootstrap rappresenta le risorse comuni necessarie per eseguire il deployment dell'infrastruttura Google Cloud, come descritto nel progetto della piattaforma aziendale.
  • Al secondo livello, all'interno della cartella Blocco 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 consociate o regioni.

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

Opzione 3: gerarchia basata su un framework di responsabilizzazione

Una gerarchia basata su un framework di responsabilità funziona al meglio quando i prodotti vengono gestiti in modo indipendente o quando le unità organizzative hanno team ben definiti, proprietari del ciclo di vita dei prodotti. In queste organizzazioni, i proprietari dei prodotti sono responsabili per l'intero ciclo di vita del prodotto, inclusi processi, assistenza, criteri, sicurezza e diritti di accesso. I tuoi prodotti sono indipendenti gli uni dagli altri e le linee guida e i controlli a livello di organizzazione non sono comuni.

Utilizza questa gerarchia quando si verifica quanto segue:

  • Gestisci un'organizzazione che ha chiare proprietà e responsabilità per ogni prodotto.
  • I carichi di lavoro sono indipendenti e non condividono molti criteri comuni.
  • I tuoi processi e le tue piattaforme per sviluppatori esterne vengono offerti come offerte di 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 della piattaforma aziendale.
  • Ogni cartella contiene diversi progetti contenenti i moduli indipendenti di cui sono responsabili i diversi team di prodotto.

Per maggiori informazioni, consulta la pagina Gerarchia delle risorse del framework Terraform FAST di Fabric.

Best practice per la gerarchia delle risorse

Le seguenti sezioni descrivono le best practice consigliate per progettare la gerarchia delle risorse, 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.

Utilizza un singolo nodo organizzazione

Per evitare l'overhead della gestione, utilizza un singolo nodo organizzazione quando possibile. Tuttavia, valuta l'utilizzo di più nodi organizzazione per i seguenti casi d'uso:

  • Vuoi testare le modifiche principali ai livelli IAM o alla gerarchia delle risorse.
  • Vuoi sperimentare in un ambiente sandbox che non ha 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 progetto di base per la sicurezza ha una convenzione di denominazione di esempio che puoi adattare ai tuoi requisiti.

Mantieni separati le risorse di bootstrap dai servizi comuni

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

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

Posiziona la cartella per i servizi comuni subito sotto il nodo organizzazione quando si verifica quanto segue:

  • La gerarchia utilizza gli ambienti applicativi al livello più alto e i team o le applicazioni al secondo livello.
  • I servizi condivisi, come il monitoraggio, sono comuni tra gli ambienti.

Posiziona la cartella per i servizi comuni a un livello inferiore, sotto le cartelle dell'applicazione, quando si verifica quanto segue:

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

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

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

Gerarchia di esempio con cartella di infrastruttura condivisa.

Il diagramma precedente ha la seguente struttura gerarchica:

  • Le cartelle al primo livello sono le seguenti:
    • Le cartelle Development environment e Production environment contengono gli ambienti delle applicazioni.
    • La cartella Shared infrastructure contiene risorse comuni condivise tra più ambienti, come il monitoraggio.
    • La cartella Bootstrap contiene le risorse comuni necessarie per eseguire il deployment dell'infrastruttura Google Cloud, come descritto nel progetto della piattaforma aziendale.
  • 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 applicativi, che contiene servizi condivisi tra le applicazioni ma indipendenti per ciascun ambiente. Ad esempio, potresti avere un progetto secret a livello di cartella per applicare criteri di autorizzazione diversi ai secret di produzione e ai secret di non produzione.
  • All'interno di ogni cartella dell'applicazione sono presenti vari progetti che contengono i moduli indipendenti che fanno parte di ciascuna applicazione.

Passaggi successivi