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 progetto base, le relative convenzioni di denominazione e le alternative ai suggerimenti relativi ai progetti.

Riepilogo

Per eseguire il deployment della tua base 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 dei prerequisiti, deployment automatico tramite terraform-example-foundation su GitHub e passaggi aggiuntivi che devono essere configurati manualmente al termine del deployment di base iniziale.

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:

I passaggi per eseguire il deployment di terraform-example-foundation da GitHub

Segui le indicazioni README per ogni fase per 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 introduce i controlli di sicurezza che applichi centralmente agli elementi di 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 per la sicurezza di Google, vedi Centro best practice per la sicurezza di Google Cloud.

Valuta se i seguenti controlli sono appropriati per gli elementi di 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

Controlli di servizio VPC consente 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 riducono i rischi di esfiltrazione di dati. Tuttavia, i Controlli di servizio VPC possono interrompere i 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 l'overhead operativo associato all'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

I requisiti normativi potrebbero indicare che il deployment delle risorse cloud deve essere eseguito 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à che definisci.

Abilita Assured Workloads

Assured Workloads fornisce controlli di conformità aggiuntivi per soddisfare 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 dati sensibili che richiedono log di accesso ai dati e abilita i log per ogni servizio e ambiente che utilizza dati sensibili.

Abilita Access Approval

Access Approval garantisce che l'assistenza clienti e i tecnici Google Cloud richiedano la tua approvazione esplicita ogni volta che devono accedere ai contenuti dei tuoi clienti.

Valuta il processo operativo necessario per esaminare le richieste Access Approval al fine di mitigare i possibili ritardi nella risoluzione di incidenti relativi all'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 l'assistenza clienti per accedere ai contenuti dei tuoi clienti.

Valuta il costo e l'overhead operativo associato a Key Access Justifications e 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 al di fuori 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. Potresti anche valutare Cloud Workstations per un'opzione di workstation configurabile nel tuo ambiente.

Limita l'accesso alla console Google Cloud

Google Cloud consente di limitare l'accesso alla console Google Cloud in base ad attributi del livello di accesso come l'iscrizione ai gruppi, 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 che ritieni attendibili per l'accesso degli utenti alle applicazioni basate sul web, come la console, nell'ambito di un deployment Zero Trust più ampio.

Convenzioni di denominazione

Ti consigliamo di utilizzare una convenzione di denominazione standardizzata per le risorse Google Cloud. La seguente tabella 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 è un formato breve del campo dell'ambiente (uno tra b, c, p, n, d o net). I progetti host del VPC condiviso utilizzano il environmentcode dell'ambiente associato. I progetti per le risorse di networking condivisi tra ambienti, come il progetto interconnect, utilizzano il codice dell'ambiente net.
  • description sono informazioni aggiuntive sul progetto. Puoi utilizzare abbreviazioni brevi leggibili da una persona.
  • randomid è un suffisso casuale per evitare collisioni tra nomi delle risorse che devono essere univoci a livello globale e per mitigare i malintenzionati che potrebbero indovinare 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 è un formato breve del campo dell'ambiente (uno tra b, c, p, n, d o net).
  • vpctype è uno tra shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete deve essere utilizzata con i Controlli di servizio VPC o meno.

Ad esempio: vpc-p-shared-base

Subnet

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

  • environmentcode è un formato breve del campo dell'ambiente (uno tra b, c, p, n, d o net).
  • vpctype è uno tra shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete deve essere utilizzata con i Controlli di servizio VPC o meno.
  • region è qualsiasi regione di 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 è un'informazione aggiuntiva sulla subnet. Puoi utilizzare brevi abbreviazioni leggibili da una persona.

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

Criteri firewall

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype è hierarchical o network.
  • scope corrisponde a global o alla regione di Google Cloud in cui si trova la risorsa. Ti consigliamo di rimuovere i trattini e di utilizzare una forma abbreviata di alcune regioni e direzioni 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 è un formato breve del campo Ambiente (uno tra b, c, p, n, d o net) proprietario della risorsa del criterio.
  • description sono informazioni aggiuntive sul criterio firewall gerarchico. Puoi utilizzare abbreviazioni brevi leggibili da una persona.

Ad esempio:

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Router Cloud

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

  • environmentcode è un formato breve del campo dell'ambiente (uno tra b, c, p, n, d o net).
  • vpctype è uno tra shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete deve essere utilizzata con i Controlli di servizio VPC o meno.
  • region è una 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 direzioni 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 sul router Cloud. Puoi utilizzare abbreviazioni brevi leggibili da una persona.

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

Connessione Cloud Interconnect

ic-dc-colo

  • dc è il nome del tuo data center a cui è connesso Cloud Interconnect.
  • colo è il nome della struttura di colocation con cui è connesso in peering 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 tuo data center a cui è connesso Cloud Interconnect.
  • colo è il nome della struttura di colocation con cui è connesso in peering Cloud Interconnect dal data center on-premise.
  • environmentcode è un formato breve del campo dell'ambiente (uno tra b, c, p, n, d o net).
  • vpctype è uno tra shared, float o peer.
  • vpcconfig è base o restricted per indicare se la rete deve essere utilizzata con i Controlli di servizio VPC o meno.
  • region è una 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 direzioni 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 utilizzare brevi abbreviazioni leggibili da una persona.

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 da una persona.

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

Ruolo personalizzato

rl-description

dove description rappresenta informazioni aggiuntive sul ruolo. Puoi usare abbreviazioni brevi leggibili da una persona.

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 leggibili da una persona.
  • projectid è l'identificatore del progetto univoco a livello globale.

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

Bucket di archiviazione

bkt-projectid-description

Dove:

  • projectid è l'identificatore del progetto univoco a livello globale.
  • description è un'informazione aggiuntiva sul bucket di archiviazione. Puoi utilizzare abbreviazioni brevi leggibili da una persona.

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 consiglio per soddisfare i tuoi requisiti specifici. La seguente tabella introduce alcune delle varianti comuni che potrebbero essere necessarie in base allo stack tecnologico e ai modi di lavoro esistenti.

Area decisionale Possibili alternative

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

Definisci una gerarchia delle risorse per la zona di destinazione di Google Cloud introduce scenari in cui potresti preferire più organizzazioni, ad esempio:

  • La tua organizzazione include società secondarie che hanno maggiori probabilità di essere vendute in futuro o che operano come entità completamente separate.
  • Vuoi sperimentare in un ambiente sandbox senza connettività alla tua organizzazione esistente.

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

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

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

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

Possono esistere diversi criteri di sicurezza o diversi modi di lavorare per diversi ambiti dell'azienda. In questo scenario, applica i vincoli dei criteri dell'organizzazione a un nodo inferiore della gerarchia delle risorse. Esamina l'elenco completo dei vincoli dei criteri dell'organizzazione che aiutano a soddisfare i tuoi requisiti.

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

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

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

Utilizza il tuo sistema di controllo della versione preferito 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 repository all'ambiente Google Cloud.

Provider di identità: il progetto parte da una Active Directory on-premise e federa le identità in 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 un provider di identità esistente, puoi creare e gestire le identità utente direttamente in Cloud Identity.

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

Se hai requisiti di sovranità dei dati o conformità che ti impediscono di utilizzare Cloud Identity, ma non ti occorrono identità utente Google gestite per altri servizi Google come Google Ads o Google Marketing Platform, potresti preferire la federazione delle identità per la forza lavoro. In questo scenario, tieni presente le limitazioni dei servizi supportati.

Più regioni: il progetto esegue il deployment di risorse di regione in due diverse regioni Google Cloud per consentire la progettazione dei carichi di lavoro tenendo presenti requisiti di alta disponibilità e ripristino di emergenza.

Se hai utenti finali in più località geografiche, potresti configurare più regioni Google Cloud per creare risorse più vicino 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 progetto fornisce una serie 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 progetto 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 in più siti fisici e regioni di Google Cloud per ottenere la massima larghezza di banda e la massima disponibilità.

A seconda dei tuoi 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 all'utilizzo di Dedicated Interconnect in un secondo momento.

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

Perimetro Controlli di servizio VPC: il progetto 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.

È possibile che un caso d'uso richieda più perimetri per un'organizzazione o che tu possa decidere di non utilizzare affatto i 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 di 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 utilizzare 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 invece 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 utilizzare un solo progetto per la gestione dell'accesso alle chiavi. Un approccio centralizzato può aiutare a soddisfare i requisiti di conformità come i custodi 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 configura un insieme di sink di log nel nodo dell'organizzazione, in modo che un team centrale di sicurezza 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 i filtri in modo che ogni team riceva solo i log necessari oppure progetta visualizzazioni di log per un controllo dell'accesso granulare dell'accesso a un bucket di log comune.

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 una singola pipeline dell'infrastruttura gestita da un team centrale se ne hai uno centrale responsabile del deployment di tutti i progetti e dell'infrastruttura. Questo team centrale può accettare richieste di pull dai team dei carichi di lavoro da esaminare e approvare prima della creazione del progetto oppure può creare personalmente la richiesta di pull in risposta a un sistema basato su ticket.

Potresti preferire pipeline più granulari se 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 di sicurezza in Security Command Center.

Decidi se esporterai i risultati sulla sicurezza da Security Command Center a strumenti come Google Security Operations o al tuo SIEM esistente o 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 da on-premise: il progetto configura un endpoint Private Service Connect univoco per ogni VPC condiviso, in modo da consentire le progettazioni 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 Controlli di servizio VPC.

Invece di 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