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

Una gerarchia delle risorse ti aiuta a organizzare le risorse in Google Cloud. Questo documento descrive come scegliere la gerarchia delle risorse nell'ambito della progettazione della landing zone. È destinato ad amministratori di sistemi cloud, architetti e professionisti tecnici coinvolti nella progettazione della gerarchia delle risorse. Questo documento fa parte di una serie sulle landing zone. Include 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 modo in cui la tua organizzazione opera oggi e lo stato finale ideale della trasformazione cloud. Il modo migliore per gestire le risorse si basa sul modo di lavorare previsto della tua organizzazione nel cloud. Poiché ogni organizzazione è diversa, non esiste un approccio unico e migliore per la gerarchia delle risorse.

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

Google Cloud gerarchia delle risorse

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 in situazioni specifiche. Definisci i livelli inferiori della gerarchia utilizzando cartelle e progetti, e crei cartelle all'interno di altre cartelle per creare la gerarchia. Puoi creare i progetti che ospitano i tuoi workload a qualsiasi livello della gerarchia.

Il seguente diagramma mostra un nodo radice denominato Organizzazione e cartelle ai livelli 1, 2 e 3. I progetti e le sottocartelle vengono creati nelle cartelle del secondo livello.

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 dei tuoi reparti, delle tue filiali, dei tuoi team tecnici o delle tue persone giuridiche?
  • Quali sono le tue esigenze di conformità?
  • Hai in programma eventi aziendali, come fusioni, acquisizioni e scissioni?

Comprendere le interazioni tra le risorse nell'intera gerarchia

I criteri dell'organizzazione vengono ereditati dai discendenti nella gerarchia delle risorse, ma possono essere sostituiti da criteri definiti a un livello inferiore. Per saperne di più, consulta 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 ai livelli inferiori sono additivi. Tuttavia, le policy di autorizzazione possono essere sostituite dalle policy di negazione, che consentono di limitare le autorizzazioni a livello di progetto, cartella e organizzazione. I criteri di negazione vengono applicati prima dei criteri di autorizzazione.

Devi anche 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 delinea i seguenti punti decisionali:

  1. Diverse filiali, gruppi regionali o business unit hanno requisiti delle norme molto diversi?
    1. In caso affermativo, segui le progettazioni in base alla regione o alle filiali.
    2. In caso contrario, vai al punto decisionale successivo.

  2. I tuoi team di carichi di lavoro o prodotti richiedono una forte autonomia sulle loro norme? Ad esempio, non hai un team di sicurezza centrale che determina le policy per tutti i team di workload o di prodotto.

    1. Se sì, consulta la progettazione basata 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 una progettazione della gerarchia delle risorse diversa da quella suggerita dal diagramma decisionale. La maggior parte delle organizzazioni sceglie un approccio ibrido e seleziona progetti diversi a diversi livelli della gerarchia delle risorse, a partire dal progetto che influisce maggiormente su criteri e accesso.

Opzione 1: gerarchia basata sugli ambienti delle applicazioni

In molte organizzazioni, definisci criteri e controlli dell'accesso diversi per diversi ambienti applicativi, come sviluppo, produzione e test. Disporre di criteri separati e standardizzati in ogni ambiente semplifica la gestione e la configurazione. Ad esempio, potresti avere norme di sicurezza più rigorose negli ambienti di produzione rispetto a quelli di test.

Utilizza una gerarchia basata sugli ambienti dell'applicazione se si verifica quanto segue:

  • Hai ambienti applicativi separati con requisiti di norme e amministrazione diversi.
  • Hai requisiti di sicurezza o di audit 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 tue risorseGoogle Cloud in ambienti diversi, sono necessari ruoli IAM (Identity and Access Management) diversi.

Evita questa gerarchia se è vera la seguente condizione:

  • Non esegui più ambienti applicativi.
  • Non hai dipendenze dell'applicazione e processi aziendali diversi tra gli ambienti.
  • Esistono differenze sostanziali tra le norme per regioni, team o applicazioni diversi.

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

  • Ambiente di sviluppo e controllo qualità: questo ambiente è gestito da sviluppatori che sono sia dipendenti interni che consulenti. Eseguono il push continuo del codice e sono responsabili della garanzia di qualità. Questo ambiente non è mai disponibile per i consumatori della tua attività. L'ambiente ha requisiti di integrazione e autenticazione meno rigorosi 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 example.com che utilizzano le API example.com. A questo scopo, example.com crea due tipi di progetto:

    • Progetti di test interni per completare la regressione interna, le prestazioni e la configurazione per le offerte B2B.
    • Progetti UAT dei clienti 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 che sono state 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 processori di terze parti per elementi quali l'autenticazione e i 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 saperne di più sulla progettazione di una gerarchia basata sugli ambienti delle applicazioni, consulta Struttura organizzativa nel progetto della piattaforma aziendale.

Opzione 2: gerarchia basata su regioni o filiali

Alcune organizzazioni operano in molte regioni e hanno filiali che svolgono attività 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 in Google Cloude 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 più alto della cartella nella gerarchia delle risorse. Le procedure di deployment sono in genere incentrate sulle regioni.

Utilizza questa gerarchia se:

  • Regioni o filiali diverse operano in modo indipendente.
  • Le regioni o le filiali hanno backbone operativi, offerte di piattaforme digitali e processi diversi.
  • La tua attività ha standard normativi e di conformità diversi per regioni o filiali.

Il seguente diagramma mostra una gerarchia di esempio di un'organizzazione globale con due filiali e un gruppo holding 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 filiali della società che hanno autorizzazioni di accesso e norme diverse dal resto dell'organizzazione. Ogni filiale utilizza IAM per limitare l'accesso ai propri progetti e Google Cloud risorse.
    • La cartella Holding group rappresenta i gruppi che hanno policy comuni di alto livello in tutte le regioni.
    • La cartella Bootstrap rappresenta le risorse comuni necessarie per il deployment della tua Google Cloud infrastruttura, come descritto nel blueprint delle fondamenta aziendali.
  • Al secondo livello, all'interno della cartella Group Holding, sono presenti le seguenti cartelle:
    • Le cartelle APAC, EMEA e Americas rappresentano le varie regioni all'interno del gruppo che hanno governance, accesso e criteri diversi.
    • La cartella Shared infrastructure rappresenta le risorse utilizzate a livello globale in tutte le regioni.
  • All'interno di ogni cartella si trovano vari progetti che contengono le risorse di cui sono responsabili queste filiali o regioni.

Puoi aggiungere altre cartelle per separare diverse persone giuridiche, reparti e team 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 tuoi prodotti vengono eseguiti in modo indipendente o le unità organizzative hanno team chiaramente definiti che possiedono il ciclo di vita dei prodotti. In queste organizzazioni, i product owner sono responsabili dell'intero ciclo di vita del prodotto, inclusi processi, assistenza, norme, sicurezza e diritti di accesso. I tuoi prodotti sono indipendenti l'uno dall'altro 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 workload sono indipendenti e non condividono molte policy comuni.
  • I tuoi processi e le piattaforme per sviluppatori esterni sono offerti come servizi o offerte di 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 e criteri di accesso 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 il deployment della tua Google Cloud infrastruttura, come descritto nel blueprint delle fondamenta aziendali.
  • All'interno di ogni cartella si trovano vari progetti che contengono i moduli indipendenti di cui sono responsabili i diversi team di prodotto.

Per saperne di più, consulta Controlli di servizio VPC Fabric FAST.

Best practice per la gerarchia delle risorse

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

Per ulteriori best practice su come configurare i tuoi account e le tue organizzazioni Cloud Identity e Google Workspace, consulta Best practice per la pianificazione di account e organizzazioni.

Utilizzare un unico nodo organizzazione

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

  • Vuoi testare le principali modifiche ai tuoi livelli IAM o alla gerarchia delle risorse.
  • Vuoi fare esperimenti in un ambiente sandbox che non ha le stesse policy dell'organizzazione.
  • La tua organizzazione include società secondarie che probabilmente verranno vendute o gestite come entità completamente separate in futuro.

Utilizzare convenzioni di denominazione standardizzate

Utilizza una convenzione di denominazione standardizzata in tutta l'organizzazione. Il blueprint delle basi della sicurezza ha una convenzione di denominazione di esempio che puoi adattare ai tuoi requisiti.

Mantenere separati le risorse di bootstrapping e i servizi comuni

Conserva cartelle separate per il bootstrapping dell'ambiente Google Cloud utilizzando Infrastructure as Code (IaC) e per i servizi comuni condivisi tra ambienti o applicazioni. Posiziona la cartella bootstrap subito 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 che scegli.

Posiziona la cartella per i servizi comuni subito sotto il nodo dell'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.
  • Hai servizi condivisi come il monitoraggio, comuni tra gli ambienti.

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

  • Hai servizi condivisi tra le applicazioni e implementi 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 un esempio di gerarchia in cui è presente una cartella dell'infrastruttura condivisa utilizzata da tutti gli ambienti e cartelle dei servizi condivisi per ogni ambiente dell'applicazione a un livello inferiore della gerarchia:

Esempio di gerarchia 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 dell'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 implementare la tua infrastruttura Google Cloud , come descritto nel blueprint delle fondamenta aziendali.
  • 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 dell'applicazione che contiene servizi condivisi tra le applicazioni, ma indipendenti per ogni ambiente. Ad esempio, potresti avere un progetto di secret a livello di cartella in modo da poter applicare criteri di autorizzazione diversi ai secret di produzione e non di produzione.
  • All'interno di ogni cartella dell'applicazione si trovano vari progetti che contengono i moduli indipendenti che fanno parte di ogni applicazione.

Passaggi successivi