Esegui il deployment del progetto base

Last reviewed 2023-12-20 UTC

Questa sezione descrive la procedura che puoi utilizzare per eseguire il deployment del blueprint, le relative convenzioni di denominazione e le alternative ai consigli per i blueprint.

Riepilogo

Per eseguire il deployment della tua base di dati aziendale in linea con le best practice e i consigli di questo blueprint, segui le attività di alto livello riepilogate in questa sezione. Il deployment richiede una combinazione di passaggi di configurazione preliminari, deployment automatico tramite terraform-example-foundation su GitHub e passaggi aggiuntivi che devono essere configurati manualmente al termine del deployment iniziale della base.

Processo Passaggi

Prerequisiti prima di eseguire il deployment delle risorse della pipeline di base

Completa i seguenti passaggi prima di eseguire il deployment della pipeline di base:

Per connetterti a un ambiente on-premise esistente, prepara quanto segue:

Passaggi per eseguire il deployment di terraform-example-foundation da GitHub

Segui le istruzioni del file readme per ogni fase per eseguire il deployment di terraform-example-foundation da GitHub:

Passaggi aggiuntivi dopo il deployment di IaC

Dopo aver eseguito il deployment del codice Terraform, completa quanto segue:

Controlli amministrativi aggiuntivi per i clienti con carichi di lavoro sensibili

Google Cloud fornisce controlli amministrativi aggiuntivi che possono aiutarti a soddisfare i tuoi requisiti di sicurezza e conformità. Tuttavia, alcuni controlli comportano costi aggiuntivi o compromessi operativi che potrebbero non essere appropriati per ogni cliente. Questi controlli richiedono inoltre input personalizzati per i tuoi requisiti specifici che non possono essere completamente automatizzati nel blueprint con un valore predefinito per tutti i clienti.

Questa sezione illustra i controlli di sicurezza che puoi applicare in modo centralizzato alla base. Questa sezione non intende essere esaustiva di tutti i controlli di sicurezza che puoi applicare a carichi di lavoro specifici. Per ulteriori informazioni sui prodotti e sulle soluzioni di sicurezza di Google, visita il Centro best practice per la sicurezza di Google Cloud.

Valuta se i seguenti controlli sono appropriati per la tua fondazione in base ai tuoi requisiti di conformità, alla tua propensione al rischio e alla sensibilità dei dati.

Controllo Descrizione

Proteggi le tue risorse con i Controlli di servizio VPC

I Controlli di servizio VPC ti consentono di definire criteri di sicurezza che impediscono l'accesso ai servizi gestiti da Google al di fuori di un perimetro attendibile, bloccano l'accesso ai dati da posizioni non attendibili e mitigano i rischi di esfiltrazione di dati. Tuttavia, Controlli di servizio VPC può causare l'interruzione dei servizi esistenti finché non definisci le eccezioni per consentire i pattern di accesso previsti.

Valuta se il valore della mitigazione dei rischi di esfiltrazione giustifica la maggiore complessità e il carico operativo dell'adozione dei Controlli di servizio VPC. Il blueprint prepara le reti con limitazioni e le variabili facoltative per configurare i Controlli di servizio VPC, ma il perimetro non viene attivato finché non esegui passaggi aggiuntivi per progettarlo e attivarlo.

Limita le posizioni delle risorse

Potresti avere requisiti normativi che richiedono di implementare le risorse cloud solo in località geografiche approvate. Questo vincolo del criterio dell'organizzazione impone che le risorse possano essere implementate solo nell'elenco di località che definite.

Abilitare Assured Workloads

Assured Workloads fornisce controlli di conformità aggiuntivi che ti aiutano a rispettare regimi normativi specifici. Il progetto fornisce variabili facoltative nella pipeline di deployment per l'abilitazione.

Attivare i log di accesso ai dati

Potresti avere l'obbligo di registrare tutto l'accesso a determinati dati o risorse sensibili.

Valuta dove i tuoi carichi di lavoro gestiscono dati sensibili che richiedono log di accesso ai dati e attiva i log per ogni servizio e ambiente che lavora con dati sensibili.

Attivare l'approvazione accesso

Access Approval garantisce che l'assistenza clienti e il team di ingegneria di Cloud richiedano la tua approvazione esplicita ogni volta che devono accedere ai contenuti dei tuoi clienti.

Valuta la procedura operativa richiesta per esaminare le richieste di approvazione dell'accesso per ridurre al minimo i possibili ritardi nella risoluzione degli incidenti relativi all'assistenza.

Attivare Key Access Justifications

Le Key Access Justifications alle chiavi ti consentono di controllare in modo programmatico se Google può accedere alle tue chiavi di crittografia, ad esempio per le operazioni automatiche e per consentire all'assistenza clienti di accedere ai contenuti dei clienti.

Valuta il costo e il sovraccarico operativo associati a Key Access Justifications, nonché la sua dipendenza da Cloud External Key Manager (Cloud EKM).

Disattiva Cloud Shell

Cloud Shell è un ambiente di sviluppo online. Questa shell è ospitata su un server gestito da Google al di fuori del tuo ambiente e, pertanto, non è soggetta ai controlli che potresti aver implementato sulle tue stazioni di lavoro per sviluppatori.

Se vuoi controllare rigorosamente le workstation che uno sviluppatore può utilizzare per accedere alle risorse cloud, disattiva Cloud Shell. Puoi anche valutare le workstation cloud per un'opzione di workstation configurabile nel tuo ambiente.

Limita l'accesso alla console Google Cloud

Google Cloud ti consente di limitare l'accesso alla console Google Cloud in base a attributi di livello di accesso come l'appartenenza al gruppo, gli intervalli di indirizzi IP attendibili e la verifica del dispositivo. Alcuni attributi richiedono un abbonamento aggiuntivo a Chrome Enterprise Premium.

Valuta i pattern di accesso attendibili per l'accesso degli utenti alle applicazioni web come la console nell'ambito di un implementazione in modalità zero trust più ampia.

Convenzioni di denominazione

Ti consigliamo di adottare una convenzione di denominazione standardizzata per le tue risorse Google Cloud. La tabella seguente descrive le convenzioni consigliate per i nomi delle risorse nel blueprint.

Risorsa Convenzione di denominazione

Cartella

fldr-environment

environment è una descrizione delle risorse a livello di cartella all'interno dell'organizzazione Google Cloud. Ad esempio, bootstrap, common, production, nonproduction, development o network.

Ad esempio: fldr-production

ID progetto

prj-environmentcode-description-randomid

  • environmentcode è una forma abbreviata del campo dell'ambiente (uno tra b, c, p, n, d o net). I progetti host VPC condiviso utilizzano il valore environmentcode dell'ambiente associato. I progetti per le risorse di rete condivise tra ambienti, come il progetto interconnect, utilizzano il codice ambiente net.
  • description sono informazioni aggiuntive sul progetto. Puoi usare abbreviazioni brevi e leggibili.
  • randomid è un suffisso casuale per evitare collisioni per i nomi delle risorse che devono essere univoci a livello globale e per ridurre al minimo le possibilità che gli utenti malintenzionati indovinino i nomi delle risorse. Il blueprint aggiunge automaticamente un identificativo alfanumerico di quattro caratteri casuale.

Ad esempio: prj-c-logging-a1b2

Rete VPC

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode è una forma abbreviata del campo dell'ambiente (uno tra b, c, p, n, d o net).
  • vpctype è uno dei valori shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete deve essere utilizzata con Controlli di servizio VPC o meno.

Ad esempio: vpc-p-shared-base

Subnet

sn-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode è una forma abbreviata del campo dell'ambiente (uno tra b, c, p, n, d o net).
  • vpctype è uno dei valori shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete deve essere utilizzata con Controlli di servizio VPC o meno.
  • region è una regione Google Cloud valida in cui si trova la risorsa. Ti consigliamo di rimuovere i trattini e di usare una forma abbreviata di alcune regioni e indicazioni per evitare di superare i limiti di caratteri. Ad esempio, au (Australia), na (Nord America), sa (Sud America), eu (Europa), se (sud-est) o ne (nord-est).
  • description sono informazioni aggiuntive sulla subnet. Puoi utilizzare abbreviazioni brevi e leggibili.

Ad esempio: sn-p-shared-restricted-uswest1

Criteri firewall

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype è hierarchical o network.
  • scope è global o la regione Google Cloud in cui si trova la risorsa. Ti consigliamo di rimuovere i trattini e di usare una forma abbreviata di alcune regioni e indicazioni per evitare di raggiungere il limite di caratteri. Ad esempio, au (Australia), na (Nord America), sa (Sud America), eu (Europa), se (sud-est) o ne (nord-est).
  • environmentcode è una forma abbreviata del campo dell'ambiente (b, c, p, n, d o net) proprietario della risorsa di criteri.
  • description sono informazioni aggiuntive sul criterio firewall gerarchico. Puoi utilizzare abbreviazioni brevi e leggibili.

Ad esempio:

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Router Cloud

cr-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode è una forma abbreviata del campo dell'ambiente (uno tra b, c, p, n, d o net).
  • vpctype è uno dei valori shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete deve essere utilizzata con Controlli di servizio VPC o meno.
  • region è una regione Google Cloud valida in cui si trova la risorsa. Ti consigliamo di rimuovere i trattini e di usare una forma abbreviata di alcune regioni e indicazioni per evitare di raggiungere il limite di caratteri. Ad esempio, au (Australia), na (Nord America), sa (Sud America), eu (Europa), se (sud-est) o ne (nord-est).
  • description sono informazioni aggiuntive sul router Cloud. Puoi utilizzare abbreviazioni brevi e leggibili.

Ad esempio: cr-p-shared-base-useast1-cr1

Connessione Cloud Interconnect

ic-dc-colo

  • dc è il nome del data center a cui è connesso un Cloud Interconnect.
  • colo è il nome della struttura di collocamento con cui è eseguito il peering di Cloud Interconnect dal data center on-premise.

Ad esempio: ic-mydatacenter-lgazone1

Collegamento VLAN Cloud Interconnect

vl-dc-colo-environmentcode-vpctype-vpcconfig-region{-description}

  • dc è il nome del data center a cui è connesso un Cloud Interconnect.
  • colo è il nome della struttura di collocamento con cui è eseguito il peering di Cloud Interconnect dal data center on-premise.
  • environmentcode è una forma abbreviata del campo dell'ambiente (uno tra b, c, p, n, d o net).
  • vpctype è uno dei valori shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete deve essere utilizzata con Controlli di servizio VPC o meno.
  • region è una regione Google Cloud valida in cui si trova la risorsa. Ti consigliamo di rimuovere i trattini e di usare una forma abbreviata di alcune regioni e indicazioni per evitare di raggiungere il limite di caratteri. Ad esempio, au (Australia), na (Nord America), sa (Sud America), eu (Europa), se (sud-est) o ne (nord-est).
  • description sono informazioni aggiuntive sulla VLAN. Puoi utilizzare abbreviazioni brevi e leggibili.

Ad esempio: vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1

Gruppo

grp-gcp-description@example.com

dove description sono ulteriori informazioni sul gruppo. Puoi utilizzare abbreviature brevi e leggibili.

Ad esempio: grp-gcp-billingadmin@example.com

Ruolo personalizzato

rl-description

Dove description sono informazioni aggiuntive sul ruolo. Puoi utilizzare sigle brevi e leggibili.

Ad esempio: rl-customcomputeadmin

Service account

sa-description@projectid.iam.gserviceaccount.com

Dove:

  • description sono informazioni aggiuntive sull'account di servizio. Puoi utilizzare abbreviazioni brevi e leggibili.
  • projectid è l'identificatore univoco globale del progetto.

Ad esempio: sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

Bucket di archiviazione

bkt-projectid-description

Dove:

  • projectid è l'identificatore univoco globale del progetto.
  • description sono informazioni aggiuntive sul bucket di archiviazione. Puoi utilizzare abbreviazioni brevi e leggibili.

Ad esempio: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

Alternative ai consigli predefiniti

Le best practice consigliate nel blueprint potrebbero non funzionare per tutti i clienti. Puoi personalizzare qualsiasi suggerimento per soddisfare i tuoi requisiti specifici. La tabella seguente illustra alcune delle varianti comuni che potresti richiedere in base al tuo stack tecnologico esistente e alle tue modalità di lavoro.

Area decisionale Possibili alternative

Organizzazione:il blueprint utilizza una singola organizzazione come nodo radice per tutte le risorse.

Decidere una gerarchia di risorse per la tua zona di destinazione Google Cloud illustra scenari in cui potresti preferire più organizzazioni, ad esempio:

  • La tua organizzazione include società secondarie che potrebbero essere vendute in futuro o che operano come entità completamente separate.
  • Vuoi eseguire esperimenti in un ambiente sandbox senza connettività con la tua organizzazione esistente.

Struttura delle cartelle: il blueprint ha una struttura di cartelle semplice, con i carichi di lavoro suddivisi in cartelle production, non-production e development nel livello superiore.

Decide una gerarchia delle risorse per la tua area di destinazione Google Cloud introduce altri approcci per strutturare le cartelle in base a come vuoi gestire le risorse e ereditare i criteri, ad esempio:

  • Cartelle basate sugli ambienti di applicazione
  • Cartelle basate su persone giuridiche o consociate regionali
  • Cartelle basate sul framework di responsabilità

Criteri dell'organizzazione:il blueprint applica tutti i vincoli dei criteri dell'organizzazione al nodo dell'organizzazione.

Potresti avere criteri di sicurezza o modalità di lavoro diversi per diverse parti dell'attività. In questo scenario, applica i vincoli dei criteri dell'organizzazione a un nodo inferiore nella gerarchia delle risorse. Esamina l'elenco completo di limitazioni dei criteri dell'organizzazione che ti aiutano a soddisfare i tuoi requisiti.

Strumenti della pipeline di deployment: il blueprint utilizza Cloud Build per eseguire la pipeline di automazione.

Potresti preferire altri prodotti per la tua pipeline di deployment, come Terraform Enterprise, GitLab Runners, GitHub Actions o Jenkins. Il blueprint include indicazioni alternative per ogni prodotto.

Repository di codice per il deployment: il blueprint utilizza Cloud Source Repositories come repository Git privato gestito.

Utilizza il sistema di controllo della versione che preferisci per gestire i repository di codice, come GitLab, GitHub o Bitbucket.

Se utilizzi un repository privato ospitato nel tuo ambiente on-premise, configura un percorso di rete privato dal tuo repository all'ambiente Google Cloud.

Provider di identità: il blueprint presuppone un Active Directory on-premise e federa le identità con Cloud Identity utilizzando Google Cloud Directory Sync.

Se utilizzi già Google Workspace, puoi utilizzare le identità Google già gestite in Google Workspace.

Se non hai un provider di identità esistente, puoi creare e gestire le identità utente direttamente in Cloud Identity.

Se hai già un provider di identità, come Okta, Ping o Azure Directory, puoi gestire gli account utente nel tuo provider di identità esistente e sincronizzarli con Cloud Identity.

Se hai requisiti di sovranità dei dati o di conformità che ti impediscono di utilizzare Cloud Identity e se non hai bisogno di identità utente Google gestite per altri servizi Google come Google Ads o Google Marketing Platform, potresti preferire la federazione delle identità del personale. In questo caso, tieni presente le limitazioni dei servizi supportati.

Più regioni:il blueprint esegue il deployment di risorse regionali in due regioni Google Cloud diverse per contribuire a progettare i carichi di lavoro tenendo conto dei requisiti di alta disponibilità e di ripristino di emergenza.

Se hai utenti finali in più località geografiche, puoi configurare altre regioni Google Cloud per creare risorse più vicine all'utente finale con meno latenza.

Se hai vincoli di sovranità dei dati o se le tue esigenze di disponibilità possono essere soddisfatte in una singola regione, puoi configurare una sola regione Google Cloud.

Allocazione degli indirizzi IP:il blueprint fornisce un insieme di intervalli di indirizzi IP.

Potresti dover modificare gli intervalli di indirizzi IP specifici utilizzati in base alla disponibilità degli indirizzi IP nel tuo ambiente ibrido esistente. Se modifichi gli intervalli di indirizzi IP, utilizza il blueprint come guida per il numero e le dimensioni degli intervalli richiesti e consulta gli intervalli di indirizzi IP validi per Google Cloud.

Networking ibrido: il blueprint utilizza Dedicated Interconnect su più siti fisici e regioni Google Cloud per la massima larghezza di banda e disponibilità.

A seconda dei requisiti relativi a costi, larghezza di banda e affidabilità, potresti configurare Partner Interconnect o Cloud VPN.

Se devi iniziare a eseguire il deployment delle risorse con connettività privata prima che sia possibile completare un'interconnessione dedicata, potresti iniziare con Cloud VPN e passare in un secondo momento all'utilizzo di Dedicated Interconnect.

Se non hai già un ambiente on-premise, potresti non avere bisogno di una rete ibrida.

Perimetro di Controlli di servizio VPC:il blueprint consiglia un singolo perimetro che includa tutti i progetti di servizio associati a una rete VPC limitata. I progetti associati a una rete VPC di base non sono inclusi nel perimetro.

Potresti avere un caso d'uso che richiede più perimetri per un'organizzazione o potresti decidere di non utilizzare affatto Controlli di servizio VPC.

Per informazioni, consulta scegliere come mitigare l'esfiltrazione di dati tramite le API di Google.

Secret Manager:il blueprint esegue il deployment di un progetto per l'utilizzo di Secret Manager nella cartella common per i segreti a livello di organizzazione e di un progetto in ogni cartella dell'ambiente per i segreti specifici dell'ambiente.

Se hai un unico team responsabile della gestione e del controllo dei secret sensibili nell'intera organizzazione, potresti preferire utilizzare un solo progetto per gestire l'accesso ai secret.

Se consenti ai team dei carichi di lavoro di gestire i propri secret, potresti non utilizzare un progetto centralizzato per gestire l'accesso ai secret e lasciare che i team utilizzino le proprie istanze di Secret Manager nei progetti dei carichi di lavoro.

Cloud KMS: il blueprint esegue il deployment di un progetto per l'utilizzo di Cloud KMS nella cartella common per le chiavi a livello di organizzazione e di un progetto per ogni cartella dell'ambiente per le chiavi in ogni ambiente.

Se hai un unico team responsabile della gestione e del controllo delle chiavi di crittografia dell'intera organizzazione, potresti preferire utilizzare un solo progetto per gestire l'accesso alle chiavi. Un approccio centralizzato può aiutarti a soddisfare i requisiti di conformità, come i custodi delle chiavi PCI.

Se consenti ai team di gestire le proprie chiavi, potresti non utilizzare un progetto centralizzato per gestire l'accesso alle chiavi e lasciare che i team utilizzino le proprie istanze di Cloud KMS nei progetti di workload.

Sink dei log aggregati:il blueprint configura un insieme di sink dei log nel nodo dell'organizzazione in modo che un team di sicurezza centrale possa esaminare gli audit log dell'intera organizzazione.

Potresti avere team diversi responsabili del controllo di diverse parti dell'attività e questi team potrebbero richiedere log diversi per svolgere il proprio lavoro. In questo scenario, progetta più sink aggregati nelle cartelle e nei progetti appropriati e crea filtri in modo che ogni team riceva solo i log necessari oppure progetta visualizzazioni log per controllo dell'accesso granulare dell'accesso a un bucket di log comune.

Granularità delle pipeline di infrastruttura: il blueprint utilizza un modello in cui ogni unità aziendale ha una pipeline di infrastruttura separata per gestire i progetti di carichi di lavoro.

Se hai un team centrale responsabile del deployment di tutti i progetti e dell'infrastruttura, potresti preferire una singola pipeline di infrastruttura gestita da un team centrale. Questo team centrale può accettare le richieste pull dai team di workload per esaminarle e approvarle prima della creazione del progetto oppure il team può creare la richiesta pull autonomamente in risposta a un sistema di ticket.

Potresti preferire pipeline più granulari se i singoli team di workload hanno la possibilità di personalizzare le proprie pipeline e vuoi progettare account di servizio con privilegi più granulari per le pipeline.

Esportazioni SIEM:il blueprint gestisce tutti i risultati relativi alla sicurezza in Security Command Center.

Decidi se esportare i risultati di sicurezza da Security Command Center in strumenti come Google Security Operations o nel tuo SIEM esistente oppure se i team utilizzeranno la console per visualizzare e gestire i risultati di sicurezza. Potresti configurare più esportazioni con filtri univoci per team diversi con ambiti e responsabilità diversi.

Ricerca DNS per i servizi Google Cloud da ambienti on-premise: il blueprint configura un endpoint Private Service Connect univoco per ogni VPC condiviso, il che può contribuire ad attivare progetti con più perimetri Controlli di servizio VPC.

Potresti non richiedere il routing da un ambiente on-premise agli endpoint Private Service Connect a questo livello di granularità se non hai bisogno di più perimetri di Controlli di servizio VPC.

Anziché mappare gli host on-premise agli endpoint Private Service Connect in base all'ambiente, puoi semplificare questo design utilizzando un singolo endpoint Private Service Connect con il bundle API appropriato oppure gli endpoint generici per private.googleapis.com e restricted.googleapis.com.

Passaggi successivi