esegui il deployment del progetto base

Last reviewed 2023-12-20 UTC

Questa sezione descrive il processo che puoi utilizzare per eseguire il deployment del progetto, le sue convenzioni di denominazione e le alternative ai suggerimenti del progetto.

Riepilogo

Per eseguire il deployment della tua piattaforma aziendale in linea con le best practice e i suggerimenti di questo progetto, segui le attività di alto livello riassunte in questa sezione. Il deployment richiede una combinazione di passaggi di configurazione prerequisiti, deployment automatico tramite terraform-example-foundation su GitHub e passaggi aggiuntivi che devono essere configurati manualmente dopo il completamento del deployment iniziale di base.

Processo Procedura

Prerequisiti per 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 il deployment di terraform-example-foundation da GitHub

Segui le istruzioni 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 requisiti di sicurezza e conformità. Tuttavia, alcuni controlli comportano costi aggiuntivi o compromessi operativi che potrebbero non essere appropriati per tutti i clienti. Questi controlli richiedono anche input personalizzati per i tuoi requisiti specifici, che non possono essere completamente automatizzati nel progetto base con un valore predefinito per tutti i clienti.

Questa sezione illustra i controlli di sicurezza da applicare a livello centrale. 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 per la sicurezza di Google, visita il Centro best practice per la sicurezza di Google Cloud.

Valuta se i seguenti controlli sono appropriati per la tua base in base ai tuoi requisiti di conformità, alla 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 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 località 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 delle eccezioni per consentire i pattern di accesso previsti.

Valuta se il valore della mitigazione dei rischi di esfiltrazione giustifica la maggiore complessità e l'overhead operativo derivante dall'adozione dei Controlli di servizio VPC. Il progetto prepara le reti limitate e le variabili facoltative per configurare i Controlli di servizio VPC, ma il perimetro non è abilitato finché non vengono eseguiti ulteriori passaggi per la progettazione e l'abilitazione.

Limita le località delle risorse

Potresti avere requisiti normativi che richiedono il deployment delle risorse cloud solo in località geografiche approvate. Questo vincolo del criterio dell'organizzazione impone che il deployment delle risorse possa essere eseguito solo nell'elenco delle località definite da te.

Abilita Assured Workloads

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

Abilita i log di accesso ai dati.

Potrebbe essere necessario registrare tutti gli accessi a determinati dati o risorse sensibili.

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

Abilita Access Approval

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

Valuta il processo operativo necessario per esaminare le richieste di Access Approval al fine di ridurre i possibili ritardi nella risoluzione degli incidenti di assistenza.

Abilita Key Access Justifications

Key Access Justifications ti consente di controllare in modo programmatico se Google può accedere alle tue chiavi di crittografia, anche per le operazioni automatizzate e per consentire all'assistenza clienti di accedere ai contenuti dei tuoi clienti.

Valuta il costo e l'overhead operativo associato a Key Access Justifications, nonché la sua dipendenza da Cloud External Key Manager (Cloud EKM).

Disabilita Cloud Shell

Cloud Shell è un ambiente di sviluppo online. Questa shell è ospitata su un server gestito da Google all'esterno del tuo ambiente, pertanto non è soggetta ai controlli che potresti aver implementato sulle tue workstation di sviluppo.

Se vuoi controllare rigorosamente le workstation che uno sviluppatore può utilizzare per accedere alle risorse cloud, disabilita Cloud Shell. Puoi anche valutare Cloud Workstations 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 ad attributi del livello di accesso come iscrizione ai gruppi, intervalli di indirizzi IP attendibili e verifica dei dispositivi. Alcuni attributi richiedono un abbonamento aggiuntivo a BeyondCorp Enterprise.

Valuta i pattern di accesso che ritieni affidabili per l'accesso degli utenti ad applicazioni basate sul web come la console nell'ambito di un deployment Zero Trust più ampio.

Convenzioni di denominazione

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

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 breve forma di campo Ambiente (uno tra b, c, p, n, d o net). I progetti host VPC condiviso utilizzano environmentcode dell'ambiente associato. I progetti per le risorse di networking condivise tra gli ambienti, come il progetto interconnect, utilizzano il codice di ambiente net.
  • description è un'informazione aggiuntiva sul progetto. Puoi usare abbreviazioni brevi e leggibili.
  • randomid è un suffisso casuale per evitare conflitti per i nomi delle risorse che devono essere univoci a livello globale e per mitigare i rischi da parte di utenti malintenzionati che inducono i nomi delle risorse. Il progetto aggiunge automaticamente un identificatore alfanumerico casuale di quattro caratteri.

Ad esempio: prj-c-logging-a1b2

Rete VPC

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode è una breve forma di campo Ambiente (b, c, p, n, d o net).
  • vpctype è uno tra shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete è destinata a essere utilizzata con i Controlli di servizio VPC.

Ad esempio: vpc-p-shared-base

Subnet

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

  • environmentcode è una breve forma di campo Ambiente (b, c, p, n, d o net).
  • vpctype è uno tra shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete è destinata a essere utilizzata con i Controlli di servizio VPC.
  • region è qualsiasi regione Google Cloud valida in cui si trova la risorsa. Ti consigliamo di rimuovere i trattini e di utilizzare una forma abbreviata di alcune regioni e indicazioni stradali per evitare di raggiungere i limiti di caratteri. Ad esempio, au (Australia), na (Nord America), sa (Sud America), eu (Europa), se (sud-est) o ne (nord-est).
  • description contiene informazioni aggiuntive sulla subnet. Puoi usare 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 utilizzare una forma abbreviata di alcune regioni e indicazioni stradali per evitare di raggiungere i limiti di caratteri. Ad esempio, au (Australia), na (Nord America), sa (Sud America), eu (Europa), se (sud-est) o ne (nord-est).
  • environmentcode è una breve forma di campo Ambiente (b, c, p, n, d o net) proprietario della risorsa del criterio.
  • description è un'informazione aggiuntiva 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 breve forma di campo Ambiente (b, c, p, n, d o net).
  • vpctype è uno tra shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete è destinata a essere utilizzata con i Controlli di servizio VPC.
  • region è qualsiasi regione Google Cloud valida in cui si trova la risorsa. Ti consigliamo di rimuovere i trattini e di utilizzare una forma abbreviata di alcune regioni e indicazioni stradali per evitare di raggiungere i limiti di caratteri. Ad esempio, au (Australia), na (Nord America), sa (Sud America), eu (Europa), se (sud-est) o ne (nord-est).
  • description fornisce 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 tuo data center a cui è connessa Cloud Interconnect.
  • colo è il nome della struttura di colocation con cui viene eseguito il peering di Cloud Interconnect dal data center on-premise.

Ad esempio: ic-mydatacenter-lgazone1

Collegamento VLAN di Cloud Interconnect

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

  • dc è il nome del tuo data center a cui è connessa Cloud Interconnect.
  • colo è il nome della struttura di colocation con cui viene eseguito il peering di Cloud Interconnect del data center on-premise.
  • environmentcode è una breve forma di campo Ambiente (b, c, p, n, d o net).
  • vpctype è uno tra shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete è destinata a essere utilizzata con i Controlli di servizio VPC.
  • region è qualsiasi regione Google Cloud valida in cui si trova la risorsa. Ti consigliamo di rimuovere i trattini e di utilizzare una forma abbreviata di alcune regioni e indicazioni stradali per evitare di raggiungere 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 VLAN. Puoi usare abbreviazioni brevi e leggibili.

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

Gruppo.

grp-gcp-description@example.com

Dove description contiene informazioni aggiuntive sul gruppo. Puoi usare abbreviazioni brevi e leggibili.

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

Ruolo personalizzato

rl-description

Dove description contiene informazioni aggiuntive sul ruolo. Puoi usare abbreviazioni brevi e leggibili.

Ad esempio: rl-customcomputeadmin

Account di servizio

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 è un'informazione aggiuntiva 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 progetto potrebbero non funzionare per tutti i clienti. Puoi personalizzare qualsiasi suggerimento in base alle tue esigenze specifiche. La seguente tabella presenta alcune delle varianti comuni di cui potresti aver bisogno in base allo stack tecnologico e alle modalità di lavoro esistenti.

Area decisionale Possibili alternative

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

Decidi una gerarchia di risorse per la tua zona di destinazione Google Cloud presenta 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à alla tua organizzazione esistente.

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

Decidere una gerarchia di risorse per la tua zona di destinazione Google Cloud introduce altri approcci per la strutturazione delle cartelle in base a come vuoi gestire le risorse ed ereditare criteri, ad esempio:

  • Cartelle basate sugli ambienti applicativi
  • Cartelle basate su entità regionali o controllate
  • Cartelle basate su un framework di responsabilizzazione

Criteri dell'organizzazione: il progetto base applica tutti i vincoli dei criteri dell'organizzazione a livello di nodo organizzazione.

Potresti avere criteri di sicurezza o modi di lavorare diversi per parti diverse dell'azienda. In questo scenario, applica i vincoli dei criteri dell'organizzazione a un nodo inferiore nella gerarchia delle risorse. Consulta l'elenco completo dei vincoli relativi ai criteri dell'organizzazione che contribuiscono a soddisfare i tuoi requisiti.

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

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

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

Utilizza il tuo sistema di controllo della versione preferito per gestire i repository di codice, ad esempio GitLab, GitHub o Bitbucket.

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

Provider di identità: il progetto base presuppone un'Active Directory on-premise e federa le identità a Cloud Identity utilizzando Google Cloud Directory Sync.

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

Se non hai ancora un provider di identità, puoi creare e gestire le identità degli utenti direttamente in Cloud Identity.

Se hai già un provider di identità, ad esempio Okta, Ping o ID voce Azure, puoi gestire gli account utente nel provider di identità esistente e sincronizzarlo con Cloud Identity.

Se hai requisiti di sovranità dei dati o di conformità che ti impediscono l'utilizzo di Cloud Identity e se non richiedi le identità degli utenti Google gestiti per altri servizi Google come Google Ads o Google Marketing Platform, potresti preferire la federazione delle identità per la forza lavoro. In questo scenario, presta attenzione alle limitazioni dei servizi supportati.

Più regioni: il progetto prevede il deployment di risorse a livello di regione in due diverse regioni Google Cloud per facilitare la progettazione dei carichi di lavoro tenendo conto dei requisiti di alta disponibilità e ripristino di emergenza.

Se gli utenti finali si trovano in più località geografiche, potresti configurare più regioni Google Cloud per creare risorse più vicine all'utente finale con minore 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.

Assegnazione degli indirizzi IP: il progetto base fornisce un insieme di intervalli di indirizzi IP.

Potresti dover modificare gli intervalli specifici di indirizzi IP utilizzati in base alla disponibilità degli indirizzi IP nell'ambiente ibrido esistente. Se modifichi gli intervalli di indirizzi IP, utilizza il progetto base come guida per il numero e la dimensione degli intervalli richiesti ed esamina gli intervalli di indirizzi IP validi per Google Cloud.

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

A seconda dei requisiti di costo, larghezza di banda e affidabilità, puoi configurare Partner Interconnect o Cloud VPN.

Se devi iniziare a eseguire il deployment delle risorse con connettività privata prima di poter completare una connessione Dedicated Interconnect, puoi iniziare con Cloud VPN e passare a Dedicated Interconnect in un secondo momento.

Se non hai un ambiente on-premise, potresti non aver bisogno del networking ibrido.

Perimetro dei Controlli di servizio VPC: il progetto consiglia un singolo perimetro che include tutti i progetti di servizio associati a una rete VPC limitata. I progetti associati a una rete VPC di base non sono inclusi all'interno del perimetro.

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

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

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

Se hai un unico team responsabile della gestione e del controllo dei secret sensibili in tutta l'organizzazione, potresti preferire l'utilizzo di un solo progetto per la gestione dell'accesso ai secret.

Se consenti ai team dei carichi di lavoro di gestire i propri secret, potresti non utilizzare un progetto centralizzato per la gestione dell'accesso ai secret e consentire ai team di utilizzare le proprie istanze di Secret Manager nei progetti dei carichi di lavoro.

Cloud KMS: il progetto 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 di ambiente per le chiavi in ogni ambiente.

Se hai un unico team responsabile della gestione e del controllo delle chiavi di crittografia in tutta l'organizzazione, potresti preferire l'utilizzo di un unico progetto per la gestione dell'accesso alle chiavi. Un approccio centralizzato può aiutare a soddisfare requisiti di conformità come i depositari delle chiavi PCI.

Se consenti ai team dei carichi di lavoro di gestire le proprie chiavi, potresti non utilizzare un progetto centralizzato per la gestione dell'accesso alle chiavi e consentire ai team di utilizzare le proprie istanze di Cloud KMS nei progetti dei carichi di lavoro.

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

Potresti avere team diversi che sono responsabili della verifica di diverse parti dell'azienda, i quali potrebbero richiedere log diversi per 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 dei log per un controllo dell'accesso granulare dell'accesso a un bucket di log comune.

Progetti di definizione dell'ambito di monitoraggio: il progetto base configura un singolo progetto di definizione dell'ambito di monitoraggio per ogni ambiente.

Potresti configurare progetti di ambito più granulari gestiti da team diversi, con un ambito basato su un insieme di progetti contenenti le applicazioni gestite da ogni team.

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

Potresti preferire un'unica pipeline di infrastruttura gestita da un team centrale se hai un team centrale responsabile del deployment di tutti i progetti e dell'infrastruttura. Questo team centrale può accettare le richieste di pull dai team dei carichi di lavoro per esaminarle e approvarle prima della creazione del progetto oppure il team può creare autonomamente le richieste pull in risposta a un sistema basato su ticket.

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

Esportazioni SIEM: il progetto gestisce tutti i risultati sulla sicurezza in Security Command Center.

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

Ricerche DNS per i servizi Google Cloud on-premise: il progetto configura un endpoint Private Service Connect univoco per ogni VPC condiviso, utile per abilitare la progettazione con più perimetri Controlli di servizio VPC.

Se non hai bisogno di più perimetri Controlli di servizio VPC, potrebbe non essere necessario eseguire il routing da un ambiente on-premise agli endpoint Private Service Connect a questo livello di granularità.

Anziché mappare gli host on-premise agli endpoint Private Service Connect in base all'ambiente, potresti semplificare questa progettazione in modo da utilizzare un singolo endpoint Private Service Connect con il bundle API appropriato oppure utilizzare gli endpoint generici per private.googlepais.com e restricted.googleapis.com.

Passaggi successivi