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

Riepilogo

Per eseguire il deployment degli elementi di base aziendali 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, il deployment automatizzato terraform-example-foundation su GitHub e passaggi aggiuntivi che devono essere configurati manualmente dopo il il deployment di base iniziale sia completato.

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 seguenti:

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

Segui le indicazioni 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 offre controlli amministrativi aggiuntivi che possono aiutarti a di sicurezza e conformità. Tuttavia, alcuni controlli comportano ulteriori a compromessi in termini di costi o operativi che potrebbero non essere appropriati per tutti i clienti. Questi controlli richiedono anche input personalizzati per le tue esigenze specifiche che non possono essere completamente automatizzati nel progetto, con un valore predefinito per clienti.

Questa sezione introduce i controlli di sicurezza che applichi centralmente ai tuoi base. Questa sezione non intende essere esaustiva di tutte le funzionalità di sicurezza controlli che puoi applicare a carichi di lavoro specifici. Per ulteriori informazioni sulle per prodotti e soluzioni per la sicurezza, consulta il Centro best practice per la sicurezza di Google Cloud.

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

Controllo Descrizione

Protezione le risorse con i Controlli di servizio VPC

I Controlli di servizio VPC consentono di definire criteri di sicurezza che accesso ai servizi gestiti da Google al di fuori di un perimetro attendibile, bloccare l'accesso ai dati da località non attendibili e mitigare i rischi di esfiltrazione di dati. Tuttavia, I Controlli di servizio VPC possono causare l'interruzione dei servizi esistenti finché non definisci eccezioni per consentire i pattern di accesso previsti.

Valuta se il valore della riduzione dei rischi di esfiltrazione giustifica la maggiore complessità e overhead operativo derivante dall'adozione dei Controlli di servizio VPC. Lo schema prepara reti con restrizioni e variabili facoltative da configurare Controlli di servizio VPC, ma il perimetro non è abilitato finché non prendi passaggi aggiuntivi per progettarla e abilitarla.

Limita località delle risorse

Potrebbero essere previsti requisiti normativi secondo cui le risorse cloud devono di cui è stato eseguito il deployment in località geografiche approvate. Questo vincolo dei criteri dell'organizzazione richiede che sia possibile eseguire il deployment delle risorse solo nell'elenco di località definire.

Abilita Assured Workloads

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

Attivare l'accesso ai dati log

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

Valuta dove i carichi di lavoro gestiscono i dati sensibili che richiede i log di accesso ai dati e abilita i log per ciascun servizio e ambiente lavorando con dati sensibili.

Abilita Access Approval

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

Valutare il processo operativo necessario per esaminare le richieste di Access Approval per ridurre i possibili ritardi la risoluzione degli incidenti di assistenza.

Attiva Motivazioni per l'accesso alle chiavi

Key Access Justifications ti consente di controllare in modo programmatico se Google può accedere alle tue chiavi di crittografia, ad esempio per operazioni automatizzate e per Assistenza clienti per accedere ai contenuti dei clienti.

Valuta il costo e l'overhead operativo associato a Key Access Justifications, nonché ai suoi su Cloud External Key Manager (Cloud EKM).

Disattiva Cloud Shell

Cloud Shell è una di sviluppo online. Questa shell è ospitata su un server gestito da Google al di fuori del tuo ambiente. Pertanto, non è soggetta ai controlli che definisci che potresti aver implementato sulle tue workstation di sviluppo.

Se vuoi controllare rigorosamente le workstation che uno sviluppatore può utilizzare per accedere al cloud e le risorse, disabilita Cloud Shell. Potresti anche valutare Cloud Workstations per un un'opzione di workstation configurabile nel proprio ambiente.

Limita alla console Google Cloud

Google Cloud ti consente di limitare l'accesso alla console Google Cloud in base all'accesso attributi di livello come appartenenza ai gruppi, intervalli di indirizzi IP attendibili e 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, come parte di un percorso zero il deployment attendibile.

Convenzioni di denominazione

Ti consigliamo di utilizzare una convenzione di denominazione standardizzata per dell'accesso a specifiche risorse Google Cloud. La seguente tabella descrive le tradizionali per i nomi delle risorse nel progetto.

Risorsa Convenzione di denominazione

Cartella

fldr-environment

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

Ad esempio: fldr-production

ID progetto

prj-environmentcode-description-randomid

  • environmentcode è una forma breve del campo Ambient (uno di b, c, p, n, d o net). Host VPC condiviso i progetti utilizzano il environmentcode dell'ambiente associato. Progetti per risorse di networking condivisi tra ambienti, come Progetto interconnect, usa l'ambiente net le API nel tuo codice.
  • description sono informazioni aggiuntive sul progetto. Tu possono utilizzare abbreviazioni brevi leggibili da una persona.
  • randomid è un suffisso randomizzato per evitare collisioni per nomi delle risorse che devono essere univoci a livello globale per mitigare i malintenzionati dei nomi delle risorse. Il progetto aggiunge automaticamente identificatore alfanumerico di quattro caratteri.

Ad esempio: prj-c-logging-a1b2

Rete VPC

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode è una forma breve del campo Ambient (uno di b, c, p, n, d o net).
  • vpctype è uno di 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 forma breve del campo Ambient (uno di b, c, p, n, d o net).
  • vpctype è uno di 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 Google Cloud valido regione in cui si trova la risorsa. Consigliamo di rimuovere trattini e utilizzando una forma abbreviata di alcune regioni e indicazioni stradali per evitare di toccare 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 utilizza abbreviazioni brevi leggibili da una persona.

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

Criteri firewall

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype è hierarchical o network.
  • scope è global o Google Cloud regione in cui si trova la risorsa. Consigliamo di rimuovere trattini e utilizzando una forma abbreviata di alcune regioni e indicazioni stradali per evitare di raggiungere 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 breve del campo Ambient (uno di b, c, p, n, d o net) proprietario del criterio risorsa.
  • description sono informazioni aggiuntive sulla gerarchia criterio firewall. Puoi utilizzare abbreviazioni brevi leggibili da una persona.

Per esempio:

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Router Cloud

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

  • environmentcode è una forma breve del campo Ambient (uno di b, c, p, n, d o net).
  • vpctype è uno di 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 account Google Cloud valido regione in cui si trova la risorsa. Consigliamo di rimuovere trattini e utilizzando una forma abbreviata di alcune regioni e indicazioni stradali per evitare di raggiungere 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 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 Cloud Interconnect è connesso.
  • colo è la colocation della struttura che Cloud Interconnect dai dati on-premise nel nostro centro.

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 Cloud Interconnect è connesso.
  • colo è la colocation il nome della struttura che Cloud Interconnect dai dati on-premise nel nostro centro.
  • environmentcode è una forma breve del campo Ambient (uno di b, c, p, n, d o net).
  • vpctype è uno di 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 account Google Cloud valido regione in cui si trova la risorsa. Consigliamo di rimuovere trattini e utilizzando una forma abbreviata di alcune regioni e indicazioni stradali per evitare di raggiungere 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 utilizza abbreviazioni brevi leggibili da una persona.

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

Gruppo

grp-gcp-description@example.com

Dove description sono informazioni aggiuntive sul gruppo. Puoi utilizzare la modalità abbreviazioni brevi leggibili da una persona.

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

Ruolo personalizzato

rl-description

Dove description informazioni aggiuntive sul ruolo. Puoi usare video brevi e facilmente leggibili da una persona o abbreviazioni di questo genere.

Ad esempio: rl-customcomputeadmin

Account di servizio

sa-description@projectid.iam.gserviceaccount.com

Dove:

  • description sono informazioni aggiuntive sul 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 i suggerimenti per soddisfare le tue esigenze specifiche. La tabella seguente introduce alcune delle varianti comuni che potreste aver bisogno in base alla vostra lo stack tecnologico e i modi di lavorare esistenti.

Area decisionale Possibili alternative

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

Decidi una gerarchia delle risorse per la zona di destinazione di Google Cloud scenari in cui potresti preferire l'uso di più organizzazioni, ad esempio:

  • La tua organizzazione include società secondarie che hanno maggiori probabilità di essere vendute future o che funzionano come entità completamente separate.
  • Vuoi sperimentare in un ambiente sandbox senza connettività al tuo per l'organizzazione esistente.

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

Decidi una gerarchia delle risorse per la zona di destinazione di Google Cloud per strutturare le cartelle in base a come vuoi gestirle, risorse ed ereditare criteri come:

  • 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 vincoli dei criteri dell'organizzazione a livello del nodo organizzazione.

Potrebbero esserci diversi criteri di sicurezza o modalità di lavoro per diversi settori dell'attività. In questo scenario, applica il criterio dell'organizzazione a un nodo inferiore della gerarchia delle risorse. Esamina l'elenco completo di organizzazione vincoli previsti dalle norme 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 direzioni 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, ad esempio GitLab, GitHub o Bitbucket.

Se utilizzi una connessione privata per un repository privato ospitato nel tuo ambiente on-premise, percorso di rete dal repository a Google Cloud completamente gestito di Google Cloud.

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

Se usi già Google Workspace, puoi utilizzare le identità Google che sono già gestiti in Google Workspace.

Se non disponi di un di identità esistente, puoi creare e gestire direttamente le identità degli utenti in Cloud Identity.

Se hai già un provider di identità, ad esempio come Okta, Ping, o Azure Entra ID, potresti gestire gli account utente nel tuo provider di identità esistente. e la sincronizzazione con Cloud Identity.

Se disponi della sovranità dei dati ai requisiti di conformità che ti impediscono di utilizzare Cloud Identity se non sono necessarie identità degli utenti Google gestite per altri servizi Google come Google Ads o Google Marketing Platform, allora preferisci la forza lavoro la federazione delle identità. In questo scenario, tieni presente le limitazioni previste dalle app supportate Google Cloud.

Più regioni: il progetto esegue il deployment a livello di regione in due diverse regioni Google Cloud per consentire l'abilitazione di progettazione con requisiti di alta disponibilità e ripristino di emergenza mente.

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

Se hai vincoli di sovranità dei dati o le esigenze di disponibilità in una singola regione, puoi configurarne regione Google Cloud.

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

Potresti dover modificare gli intervalli di indirizzi IP specifici utilizzati in base Disponibilità degli indirizzi IP nel tuo ambiente ibrido esistente. Se modifichi di indirizzi IP, utilizza il progetto come guida per il numero e le dimensioni intervalli obbligatori ed esamina l'indirizzo IP valido di archiviazione per Google Cloud.

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

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

Se devi iniziare a eseguire il deployment delle risorse con prima di poter completare una connessione Dedicated Interconnect potresti iniziare con Cloud VPN e passare all'uso Dedicated Interconnect più tardi.

Se non disponi di un on-premise, potresti non aver bisogno del networking ibrido.

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

Potresti avere un caso d'uso che richiede perimetri per un'organizzazione oppure puoi decidere di non usare 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 aver utilizzato Secret Manager nella cartella common per secret a livello di organizzazione e un progetto in ogni cartella di ambiente per secret specifici dell'ambiente.

Se hai un solo team responsabile della gestione e del controllo segreti sensibili all'interno dell'organizzazione, potresti preferire utilizzarne uno progetto per la gestione dell'accesso ai secret.

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

Cloud KMS: il progetto esegue il deployment di un progetto per utilizzando Cloud KMS nella cartella common per i contenuti a livello di organizzazione e un progetto per ogni cartella di ambiente per le chiavi completamente gestito di Google Cloud.

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

Se consenti ai team dei carichi di lavoro gestire le proprie chiavi, potreste non usare un progetto centralizzato per la l'accesso alle chiavi, ma consente ai team di utilizzare le proprie Cloud KMS nei progetti dei carichi di lavoro.

Sink di log aggregati: il progetto configura un insieme di sink di log a livello di nodo organizzazione per consentire a un team di sicurezza centrale di esaminarli e gli audit log di controllo dell'intera organizzazione.

Potrebbero esserci diversi team responsabili dell'auditing parti dell'azienda e questi team potrebbero richiedere log diversi per eseguire le di lavoro. In questo scenario, progetta più sink aggregati nel modo appropriato cartelle e progetti e creare filtri in modo che ogni team riceva solo i log necessari o i log di progettazione viste per un controllo granulare degli accessi a un bucket di log comune.

Granularità delle pipeline dell'infrastruttura: il progetto base 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 sistema se hai un team centrale responsabile del deployment di tutti i progetti dell'infrastruttura. Questo team centrale può accettare richieste di pull dal carico di lavoro team da rivedere e approvare prima della creazione del progetto oppure il team può creare il pull richiedersi in risposta a un sistema basato su ticket.

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

Esportazioni SIEM: il progetto gestisce tutta la sicurezza in Security Command Center.

Decidi se esportare i risultati sulla sicurezza da Security Command Center a come Google Security Operations o il tuo SIEM esistente, o se i team puoi usare la console per visualizzare e gestire i risultati sulla sicurezza. Potresti configurare più esportazioni con filtri unici per team diversi con ambiti diversi e responsabilità.

Ricerche DNS per i servizi Google Cloud dall'ambiente on-premise: Il progetto configura un endpoint Private Service Connect univoco per per ogni VPC condiviso, per agevolare le progettazioni con perimetri Controlli di servizio VPC.

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

Invece di mappatura degli host on-premise agli endpoint Private Service Connect dell'ambiente, potresti semplificare la progettazione in modo da utilizzare l'endpoint Private Service Connect con il bundle API appropriato, o utilizzare gli endpoint generici per private.googlepais.com e restricted.googleapis.com.

Passaggi successivi