Esegui il deployment del progetto base

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:

• Crea un account Cloud Identity e verifica la proprietà del dominio.
• Richiedi un account con fatturazione mensile non automatica al tuo team di vendita Google Cloud o crea un account di fatturazione self-service.
• Applica le best practice per la sicurezza per gli account amministratore.
• Verificare e risolvere i problemi relativi agli account utente consumer.
• Configura il provider di identità esterno come fonte di dati attendibili per la sincronizzazione degli account utente e del servizio SSO.
• Esegui il provisioning dei gruppi per il controllo dell'accesso necessari per eseguire il blueprint.
• Determina la topologia di rete che utilizzerai.
• Decidi lo strumento di gestione del codice sorgente. Le istruzioni per terraform-example-foundation sono scritte in un repository Git ospitato in Cloud Source Repositories.
• Decidi gli strumenti di automazione CI/CD. terraform-example-foundation fornisce diversi set di istruzioni per diversi strumenti di automazione.

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

• Pianifica l'allocazione degli indirizzi IP in base al numero e alle dimensioni degli intervalli richiesti dal blueprint.
• Ordina le connessioni Dedicated Interconnect.

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:

• Fase 0-bootstrap per creare una pipeline di base.

  Se utilizzi un account di fatturazione self-service, devi richiedere una quota di progetto aggiuntiva prima di procedere alla fase successiva.

• Fase 1-org per configurare le risorse a livello di organizzazione.
• Esegui il deployment dello stage 2-environments per creare gli ambienti.
• Esegui lo staging di 3-networks-dual-svpc or 3-networks-hub-and-spoke per creare risorse di rete nella topologia che preferisci.
• Fase 4-projects per creare una pipeline dell'infrastruttura.
• (Facoltativo) Esegui lo staging di 5-app-infra per un utilizzo di esempio della pipeline dell'infrastruttura.

Passaggi aggiuntivi dopo il deployment di IaC

Dopo aver eseguito il deployment del codice Terraform, completa le seguenti operazioni:

• Completa le modifiche alla configurazione on-premise.
• Attiva Security Command Center Premium.
• Esporta i dati di fatturazione Cloud in BigQuery.
• Registrati a un piano di assistenza clienti Google Cloud.
• Attiva i log di Access Transparency.
• Condividere i dati di Cloud Identity con Google Cloud.
• Applica i controlli amministrativi per Cloud Identity che non sono automatizzati dal deployment di IaC.
• Valuta quali dei controlli amministrativi aggiuntivi per i clienti con carichi di lavoro sensibili sono appropriati per il tuo caso d'uso.
• Esamina le best practice operative e pianifica come collegare le operazioni e le funzionalità esistenti alle risorse di base.

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 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 eccezioni per consentire i pattern di accesso previsti.

Valuta se il valore della mitigazione dei rischi di esfiltrazione giustifica la maggiore complessità e il sovraccarico operativo dell'adozione dei Controlli di servizio VPC. Il blueprint prepara i controlli di rete prerequisiti e un perimetro di Controlli di servizio VPC di prova, ma il perimetro non viene applicato finché non esegui passaggi aggiuntivi.

Limitare le posizioni delle risorse

Potresti avere requisiti normativi che prevedono che le risorse cloud vengano implementate solo in località geografiche approvate. Questo vincolo dei criteri dell'organizzazione impone che le risorse possano essere implementate solo nell'elenco di località che definisci.

Abilita 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'attivazione.

Abilita i log di accesso ai dati

Potresti avere l'obbligo di registrare tutti gli accessi a determinati dati sensibili o risorse.

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 gestisce dati sensibili.

Attiva Access Approval

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

Valuta la procedura operativa necessaria per esaminare le richieste di approvazione dell'accesso per ridurre i possibili ritardi nella risoluzione degli incidenti di assistenza.

Attiva Key Access Justifications

Key Access Justifications ti consentono di controllare in modo programmatico se Google può accedere alle tue chiavi di crittografia, anche per operazioni automatizzate e per consentire al team di assistenza clienti di accedere ai tuoi contenuti.

Valuta il costo e l'overhead 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 workstation di sviluppo.

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

Limitare l'accesso alla Google Cloud console

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

Valuta i pattern di accesso di cui ti fidi per l'accesso degli utenti ad applicazioni basate sul web come la console nell'ambito di un'implementazione zero trust più ampia.

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 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 ambiente net.
• description sono informazioni aggiuntive sul progetto. Puoi utilizzare abbreviazioni brevi e leggibili.
• randomid è un suffisso randomizzato per evitare conflitti per i nomi delle risorse che devono essere univoci a livello globale e per ridurre il rischio che gli autori degli attacchi indovinino 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

• environmentcode è una forma abbreviata del campo ambiente (uno tra b, c, p, n, d o net).
• vpctype è uno tra svpc, float o peer.

Ad esempio: vpc-p-svpc

Subnet

sn-environmentcode-vpctype-region{-description}

• environmentcode è una forma abbreviata del campo ambiente (uno tra b, c, p, n, d o net).
• vpctype è uno tra svpc, float o peer.
• region è una Google Cloud regione valida in cui si trova la risorsa. Ti consigliamo di rimuovere i trattini e di utilizzare una forma abbreviata di alcune regioni e indicazioni 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 subnet. Puoi utilizzare abbreviazioni brevi e leggibili.

Ad esempio: sn-p-svpc-uswest1

Policy 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 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 forma abbreviata del campo ambiente (uno tra b, c, p, n, d o net) che possiede la risorsa policy.
• description sono informazioni aggiuntive sulla policy firewall gerarchica. Puoi utilizzare abbreviazioni brevi e leggibili.

Ad esempio:

fw-hierarchical-global-c-01

fw-network-uswest1-p-svpc

Router Cloud

cr-environmentcode-vpctype-region{-description}

• environmentcode è una forma abbreviata del campo ambiente (uno tra b, c, p, n, d o net).
• vpctype è uno tra svpc, float o peer.
• region è una 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 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 su router Cloudr. Puoi utilizzare abbreviazioni brevi e leggibili.

Ad esempio: cr-p-svpc-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 collocamento con cui viene 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-region{-description}

• dc è il nome del tuo data center a cui è connesso Cloud Interconnect.
• colo è il nome della struttura di collocamento con cui è in peering Cloud Interconnect dal data center on-premise.
• environmentcode è una forma abbreviata del campo ambiente (uno tra b, c, p, n, d o net).
• vpctype è uno tra svpc, float o peer.
• region è una 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 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 abbreviazioni brevi e leggibili.

Ad esempio: vl-mydatacenter-lgazone1-p-svpc-useast1-cr1

Gruppo

grp-gcp-description@example.com

Dove description sono informazioni aggiuntive sul gruppo. Puoi utilizzare abbreviazioni brevi e leggibili.

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

Ruolo personalizzato

rl-description

Dove description sono riportate informazioni aggiuntive sul ruolo. Puoi utilizzare abbreviazioni 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

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

Decidere una gerarchia delle risorse per la tua Google Cloud landing zone introduce scenari in cui potresti preferire più organizzazioni, ad esempio:

• La tua organizzazione include società secondarie che probabilmente verranno 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 che suddivide i carichi di lavoro in cartelle production, non-production e development nel livello superiore.

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

• Cartelle basate sugli ambienti delle applicazioni
• Cartelle basate su entità regionali o consociate
• Cartelle basate sul framework di responsabilità

Policy dell'organizzazione:il progetto applica tutti i vincoli dei criteri dell'organizzazione nel nodo organizzazione.

Potresti avere norme di sicurezza o modi di lavorare diversi per diverse parti dell'attività. In questo scenario, applica i vincoli delle policy dell'organizzazione a un nodo di livello inferiore nella gerarchia delle risorse. Consulta l'elenco completo dei vincoli delle policy dell'organizzazione che ti aiutano 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, come Terraform Enterprise, GitLab Runners, GitHub Actions o Jenkins. Il progetto include indicazioni alternative per ogni 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 blueprint presuppone un Active Directory on-premise e federato 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à degli utenti direttamente in Cloud Identity.

Se hai un provider di identità esistente, ad esempio Okta, Ping o Azure Entra ID, puoi gestire gli account utente nel 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à della forza lavoro. In questo scenario, tieni presente le limitazioni relative ai servizi supportati.

Più regioni: il blueprint esegue il deployment di risorse regionali in due regioni Google Cloud diverse per contribuire a consentire la progettazione di workload tenendo conto dei requisiti di alta disponibilità e ripristino di emergenza.

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

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

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

Potresti dover modificare gli intervalli di indirizzi IP specifici utilizzati in base alla disponibilità di 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 rivedi gli intervalli di indirizzi IP validi per Google Cloud.

Networking ibrido: il progetto utilizza Dedicated Interconnect in più siti fisici e Google Cloud regioni 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 di risorse con connettività privata prima che possa essere completata un'interconnessione dedicata, 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 di una rete ibrida.

Perimetro dei Controlli di servizio VPC: il progetto consiglia un unico perimetro che includa tutti i progetti di servizio per la topologia VPC condiviso.

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

Per informazioni, vedi decidere 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 secret a livello di organizzazione e di un progetto in ogni cartella dell'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 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 consentire invece ai team di utilizzare 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 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 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 workload 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 di log aggregati:il blueprint configura un insieme di sink di 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 dei log per controllo dell'accesso granulare a un bucket di log comune.

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

Potresti preferire una singola pipeline dell'infrastruttura gestita da un team centrale se hai un team centrale responsabile della distribuzione di tutti i progetti e dell'infrastruttura. Questo team centrale può accettare le richieste di pull dai team di workload per la revisione e l'approvazione prima della creazione del progetto oppure può creare la richiesta di pull autonomamente in risposta a un sistema di ticketing.

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 di sicurezza in Security Command Center.

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