Questi contenuti sono stati aggiornati l'ultima volta a dicembre 2023 e rappresentano lo status quo del momento in cui sono stati redatti. Criteri e sistemi di sicurezza di Google possono variare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.

Questo documento descrive le best practice che consentono di eseguire il deployment di un insieme di risorse di base in Google Cloud. Una piattaforma cloud è la base di risorse, configurazioni e funzionalità che consente alle aziende di adottare Google Cloud per le proprie esigenze aziendali. Una struttura di base ben progettata consente coerenza di governance, controlli di sicurezza, scalabilità, visibilità e accesso ai servizi condivisi in tutti i carichi di lavoro nel tuo ambiente Google Cloud. Dopo aver eseguito il deployment dei controlli e della governance descritti in questo documento, puoi eseguire il deployment dei carichi di lavoro in Google Cloud.

Il progetto di base aziendale (precedentemente noto come progetto di base della sicurezza) è destinato ad architetti, professionisti della sicurezza e team di tecnici delle piattaforme responsabili della progettazione di un ambiente di livello enterprise su Google Cloud. Questo progetto è costituito da:

• Un repository GitHub di terraform-example-foundation contenente gli asset Terraform di cui è possibile eseguire il deployment.
• Una guida che descrive l'architettura, la progettazione e i controlli implementati con il progetto base (questo documento).

Puoi utilizzare questa guida in due modi:

• per creare una base completa basata sulle best practice di Google. Puoi eseguire il deployment di tutti i suggerimenti di questa guida come punto di partenza, quindi personalizzare l'ambiente per soddisfare i requisiti specifici della tua attività.
• Esaminare un ambiente esistente su Google Cloud. Puoi confrontare componenti specifici della tua progettazione con le best practice consigliate da Google.

Casi d'uso supportati

Il progetto di base aziendale offre un livello di base di risorse e configurazioni che consentono di abilitare tutti i tipi di carichi di lavoro su Google Cloud. Che tu stia eseguendo la migrazione a Google Cloud di carichi di lavoro di computing esistenti, creando applicazioni web containerizzate o creando carichi di lavoro di big data e machine learning, il progetto di base aziendale ti aiuta a creare l'ambiente per supportare carichi di lavoro aziendali su larga scala.

Dopo aver eseguito il deployment del progetto di base aziendale, puoi eseguire il deployment diretto dei carichi di lavoro o eseguire il deployment di progetti aggiuntivi per supportare carichi di lavoro complessi che richiedono funzionalità aggiuntive.

Un modello di sicurezza di difesa in profondità

I servizi Google Cloud traggono vantaggio dalla progettazione della sicurezza dell'infrastruttura Google sottostante. È tua responsabilità progettare la sicurezza nei sistemi che crei su Google Cloud. Il progetto di base aziendale consente di implementare un modello di sicurezza per la difesa in profondità per i servizi e i carichi di lavoro di Google Cloud.

Il seguente diagramma mostra un modello di sicurezza per la difesa in profondità per la tua organizzazione Google Cloud che combina controlli dell'architettura, dei criteri e dei controlli.

Il diagramma descrive i seguenti controlli:

• I controlli dei criteri sono vincoli programmatici che applicano configurazioni di risorse accettabili e prevengono configurazioni rischiose. Il progetto utilizza una combinazione di controlli dei criteri, tra cui la convalida di Infrastructure as Code (IaC) nella pipeline e i vincoli dei criteri dell'organizzazione.
• I controlli dell'architettura sono la configurazione delle risorse Google Cloud come le reti e la gerarchia delle risorse. L'architettura del progetto base si basa sulle best practice per la sicurezza.
• I controlli di rilevamento consentono di rilevare comportamenti anomali o dannosi all'interno dell'organizzazione. Il progetto utilizza funzionalità della piattaforma come Security Command Center, si integra con i controlli e i flussi di lavoro di rilevamento esistenti come un centro operativo di sicurezza (SOC) e fornisce funzionalità per applicare controlli di rilevamento personalizzati.

Decisioni chiave

Questa sezione riassume le decisioni architettoniche di alto livello del progetto.

Il diagramma descrive in che modo i servizi Google Cloud contribuiscono alle decisioni di architettura chiave:

• Cloud Build: le risorse di infrastruttura sono gestite utilizzando un modello GitHub. IaC dichiarativo è scritto in Terraform e gestito in un sistema di controllo della versione per la revisione e l'approvazione, e il deployment delle risorse viene eseguito utilizzando Cloud Build come strumento di automazione dell'integrazione continua e del deployment continuo (CI/CD). La pipeline applica anche controlli Policy as Code per verificare che le risorse soddisfino le configurazioni previste prima del deployment.
• Cloud Identity: gli utenti e le iscrizioni ai gruppi vengono sincronizzati dal provider di identità esistente. I controlli per la gestione del ciclo di vita degli account utente e il Single Sign-On (SSO) si basano sui controlli e sui processi esistenti del tuo provider di identità.
• Identity and Access Management (IAM): i criteri di autorizzazione (precedentemente noti come criteri IAM) consentono l'accesso alle risorse e vengono applicati ai gruppi in base alla funzione lavorativa. Gli utenti vengono aggiunti ai gruppi appropriati per ricevere accesso di sola visualizzazione alle risorse di base. Il deployment di tutte le modifiche alle risorse di base viene eseguito tramite la pipeline CI/CD che utilizza identità degli account di servizio con privilegi.
• Resource Manager: tutte le risorse sono gestite in un'unica organizzazione, con una gerarchia di risorse di cartelle che organizza i progetti in base agli ambienti. I progetti sono etichettati con metadati per la governance, tra cui l'attribuzione dei costi.
• Networking: le topologie di rete utilizzano il VPC condiviso per fornire risorse di rete per i carichi di lavoro in più regioni e zone, separate dall'ambiente e gestite centralmente. Tutti i percorsi di rete tra host on-premise, risorse Google Cloud nelle reti VPC e servizi Google Cloud sono privati. Nessun traffico in uscita verso o in entrata dalla rete internet pubblica è consentito per impostazione predefinita.
• Cloud Logging: i sink di log aggregati sono configurati per raccogliere log pertinenti per la sicurezza e l'audit in un progetto centralizzato per la conservazione, l'analisi e l'esportazione a lungo termine su sistemi esterni.
• Cloud Monitoring: i progetti di monitoraggio dell'ambito sono configurati per visualizzare le metriche sulle prestazioni delle applicazioni in più progetti in un'unica posizione.
• Servizio criteri dell'organizzazione: i vincoli dei criteri dell'organizzazione sono configurati per prevenire varie configurazioni ad alto rischio.
• Secret Manager: i progetti centralizzati vengono creati per un team responsabile della gestione e del controllo dell'uso di secret delle applicazioni sensibili per soddisfare i requisiti di conformità.
• Cloud Key Management Service (Cloud KMS): i progetti centralizzati vengono creati per un team responsabile della gestione e del controllo delle chiavi di crittografia al fine di soddisfare i requisiti di conformità.
• Security Command Center: le funzionalità di rilevamento e monitoraggio delle minacce vengono fornite utilizzando una combinazione di controlli di sicurezza integrati di Security Command Center e soluzioni personalizzate che consentono di rilevare e rispondere agli eventi di sicurezza.

Per conoscere le alternative a queste decisioni chiave, consulta le alternative.

Passaggi successivi

• Leggi ulteriori informazioni su autenticazione e autorizzazione (documento successivo di questa serie).

autentica e autorizza

Questa sezione illustra come utilizzare Cloud Identity per gestire le identità utilizzate dai dipendenti per accedere ai servizi Google Cloud.

Provider di identità esterno come fonte attendibile

Ti consigliamo di federare l'account Cloud Identity con il tuo provider di identità esistente. La federazione ti aiuta a garantire che i processi di gestione degli account esistenti vengano applicati a Google Cloud e ad altri servizi Google.

Se non hai un provider di identità, puoi creare account utente direttamente in Cloud Identity.

Il seguente diagramma mostra una visualizzazione generale della federazione delle identità e del Single Sign-On (SSO). che utilizza Microsoft Active Directory, situato nell'ambiente on-premise, come provider di identità di esempio.

Questo diagramma descrive le seguenti best practice:

• Le identità degli utenti vengono gestite in un dominio Active Directory situato nell'ambiente on-premise e federato a Cloud Identity. Active Directory utilizza Google Cloud Directory Sync per il provisioning delle identità a Cloud Identity.
• Gli utenti che tentano di accedere ai servizi Google vengono reindirizzati al provider di identità esterno per il Single Sign-On con SAML, utilizzando le credenziali esistenti per l'autenticazione. Nessuna password è sincronizzata con Cloud Identity.

La tabella seguente fornisce i link per configurare le indicazioni per i provider di identità.

Provider di identità	Consulenza
Active Directory	Provisioning degli account utente di Active Directory Single Sign-On di Active Directory
ID Microsoft Entra (in precedenza Azure AD)	Federazione di Google Cloud con Microsoft Entra ID
Altri provider di identità esterni (ad esempio Ping o Okta)	Integrazione delle soluzioni di Ping Identity con i servizi di identità Google Utilizzo di Okta con i provider Google Cloud Best practice per la federazione di Google Cloud con un provider di identità esterno

Ti consigliamo vivamente di applicare l'autenticazione a più fattori presso il tuo provider di identità con un meccanismo resistente al phishing come un token di sicurezza Titan.

Le impostazioni consigliate per Cloud Identity non sono automatizzate tramite il codice Terraform in questo progetto base. Consulta i controlli amministrativi per Cloud Identity per conoscere le impostazioni di sicurezza consigliate che devi configurare oltre a eseguire il deployment del codice Terraform.

Gruppi per controllo dell'accesso

Un'entità è un'identità a cui è concesso l'accesso a una risorsa. Le entità includono Account Google per utenti, gruppi Google, account Google Workspace, domini Cloud Identity e account di servizio. Alcuni servizi consentono inoltre di concedere l'accesso a tutti gli utenti che si autenticano con un Account Google o a tutti gli utenti su internet. Affinché un'entità possa interagire con i servizi Google Cloud, devi concederle i ruoli in Identity and Access Management (IAM).

Per gestire i ruoli IAM su larga scala, ti consigliamo di assegnare gli utenti ai gruppi in base alle loro funzioni lavorative e ai requisiti di accesso, quindi di concedere i ruoli IAM a questi gruppi. Devi aggiungere utenti ai gruppi utilizzando i processi del tuo provider di identità esistente per la creazione e l'appartenenza ai gruppi.

Non è consigliabile concedere i ruoli IAM ai singoli utenti perché i singoli compiti possono aumentare la complessità della gestione e del controllo dei ruoli.

Il progetto base configura gruppi e ruoli per l'accesso di sola visualizzazione alle risorse di base. Ti consigliamo di eseguire il deployment di tutte le risorse del progetto mediante la pipeline di base e di non concedere ruoli agli utenti ai gruppi per modificare le risorse di base al di fuori della pipeline.

La tabella seguente mostra i gruppi configurati dal progetto per la visualizzazione delle risorse di base.

Nome	Descrizione	Ruoli	Ambito
[email protected]	Amministratori con privilegi elevati che possono concedere ruoli IAM a livello di organizzazione. Può accedere a qualsiasi altro ruolo. Questo privilegio non è consigliato per l'uso quotidiano.	Amministratore dell'organizzazione	organizzazione
[email protected]	Amministratori con privilegi elevati che possono modificare l'account di fatturazione Cloud. Questo privilegio non è consigliato per l'uso quotidiano.	Amministratore account di fatturazione	organizzazione
[email protected]	Il team responsabile di visualizzare e analizzare la spesa in tutti i progetti.	Visualizzatore account di fatturazione	organizzazione
		Utente BigQuery	progetto di fatturazione
[email protected]	Il team responsabile dell'audit dei log relativi alla sicurezza.	Visualizzatore log Utente BigQuery	progetto di logging
[email protected]	Il team responsabile del monitoraggio delle metriche sulle prestazioni delle applicazioni.	Visualizzatore Monitoring	progetto di monitoraggio
[email protected]	Il team responsabile della revisione della sicurezza del cloud.	Revisore della sicurezza	organizzazione
[email protected]	Il team responsabile della visualizzazione e della gestione delle configurazioni di rete.	Visualizzatore rete Compute	organizzazione
[email protected]	Il team responsabile della configurazione di Security Command Center.	Editor amministratore Centro sicurezza	organizzazione
[email protected]	Il team responsabile della gestione, dell'archiviazione e del controllo delle credenziali e di altri secret utilizzati dalle applicazioni.	Amministratore Secret Manager	progetti secret
[email protected]	Il team responsabile dell'applicazione della gestione delle chiavi di crittografia per soddisfare i requisiti di conformità.	Visualizzatore Cloud KMS	progetti kms

Man mano che crei i tuoi carichi di lavoro sulla base degli elementi di base, puoi creare gruppi aggiuntivi e concedere ruoli IAM in base ai requisiti di accesso per ogni carico di lavoro.

Ti consigliamo vivamente di evitare i ruoli di base (come Proprietario, Editor o Visualizzatore) e di utilizzare invece ruoli predefiniti. I ruoli di base sono eccessivamente permissivi e rappresentano un potenziale rischio per la sicurezza. I ruoli Proprietario ed Editor possono portare all'escalation dei privilegi e allo spostamento laterale e il ruolo Visualizzatore include l'accesso per leggere tutti i dati. Per le best practice sui ruoli IAM, consulta Utilizzare IAM in modo sicuro.

Account super amministratore

Gli utenti di Cloud Identity con l'account super amministratore bypassano le impostazioni SSO dell'organizzazione e si autenticano direttamente in Cloud Identity. Questa eccezione è stata progettata, per cui il super amministratore può comunque accedere alla console Cloud Identity in caso di errore di configurazione o interruzione del servizio SSO. Tuttavia, devi valutare una maggiore protezione per gli account super amministratore.

Per proteggere i tuoi account super amministratore, ti consigliamo di applicare sempre la verifica in due passaggi con i token di sicurezza in Cloud Identity. Per ulteriori informazioni, consulta Best practice per la protezione degli account amministratore.

Problemi con gli account utente consumer

Se non hai utilizzato Cloud Identity o Google Workspace prima di iniziare l'onboarding in Google Cloud, è possibile che i dipendenti della tua organizzazione utilizzino già account consumer associati alle loro identità email aziendali per accedere ad altri servizi Google come Google Marketing Platform o YouTube. Gli account consumer sono account interamente di proprietà e gestiti dalla persona che li ha creati. Poiché questi account non sono sotto il controllo della tua organizzazione e potrebbero includere dati personali e aziendali, devi decidere come consolidare questi account con altri account aziendali.

Ti consigliamo di consolidare gli account utente consumer esistenti nell'onboarding in Google Cloud. Se non utilizzi già Google Workspace per tutti i tuoi account utente, ti consigliamo di bloccare la creazione di nuovi account consumer.

Controlli amministrativi per Cloud Identity

Cloud Identity ha vari controlli amministrativi non automatizzati dal codice Terraform nel progetto. Ti consigliamo di applicare ciascuno di questi controlli di sicurezza basati sulle best practice fin dalle prime fasi del processo di creazione delle basi.

Controllo	Descrizione
Implementare la verifica in due passaggi	Gli account utente potrebbero essere stati compromessi da phishing, ingegneria sociale, password spraying o altre minacce. La verifica in due passaggi consente di attenuare queste minacce. Ti consigliamo di applicare la verifica in due passaggi a tutti gli account utente della tua organizzazione con un meccanismo anti-phishing, come i token di sicurezza Titan o altre chiavi basate sugli standard FIDO U2F (CTAP1) resistenti al phishing.
Imposta la durata della sessione per i servizi Google Cloud	I token OAuth permanenti sulle workstation per sviluppatori possono rappresentare un rischio per la sicurezza se esposti. Ti consigliamo di impostare un criterio di riautenticazione in modo che richieda l'autenticazione ogni 16 ore utilizzando un token di sicurezza.
Impostare la durata delle sessioni per i servizi Google	(Solo per i clienti di Google Workspace) Le sessioni web persistenti in altri servizi Google possono rappresentare un rischio per la sicurezza se esposte. Consigliamo di applicare una lunghezza massima delle sessioni web e allinearla ai controlli della lunghezza delle sessioni del provider SSO.
Condividere dati da Cloud Identity con i servizi Google Cloud	Gli audit log delle attività di amministrazione di Google Workspace o Cloud Identity vengono normalmente gestiti e visualizzati nella Console di amministrazione, separatamente dai log nell'ambiente Google Cloud. Questi log contengono informazioni pertinenti per il tuo ambiente Google Cloud, ad esempio eventi di accesso utente. Ti consigliamo di condividere gli audit log di Cloud Identity con il tuo ambiente Google Cloud per gestire centralmente i log di tutte le origini.
Configurare la verifica post-SSO	Il progetto presuppone che tu abbia configurato l'accesso SSO con il tuo provider di identità esterno. Ti consigliamo di attivare un livello aggiuntivo di controllo basato sull'analisi del rischio relativo all'accesso di Google. Una volta applicata questa impostazione, gli utenti potrebbero dover effettuare ulteriori verifiche dell'accesso basate sul rischio al momento dell'accesso, se Google ritiene che l'accesso di un utente sia sospetto.
Risolvere i problemi relativi agli account utente consumer	Gli utenti con un indirizzo email valido nel tuo dominio, ma senza Account Google, possono registrarsi ad account consumer non gestiti. Questi account potrebbero contenere dati aziendali, ma non sono controllati dai processi di gestione del ciclo di vita dell'account. Ti consigliamo di adottare le misure necessarie per assicurarti che tutti gli account utente siano account gestiti.
Disattivare il recupero dell'account per gli account super amministratore	Il recupero autonomo dell'account super amministratore è disattivato per impostazione predefinita per tutti i nuovi clienti (i clienti esistenti potrebbero avere questa impostazione attiva). La disattivazione di questa impostazione consente di ridurre il rischio che un attacco telefonico, a email compromesse o di ingegneria sociale possa consentire a un aggressore di ottenere privilegi di super amministratore sul tuo ambiente. Pianifica una procedura interna affinché un super amministratore possa contattare un altro super amministratore della tua organizzazione se non riesce più ad accedere al proprio account e assicurati che tutti i super amministratori conoscano la procedura per il recupero con assistenza assistita.
Imporre e monitorare i requisiti delle password per gli utenti	Nella maggior parte dei casi, le password degli utenti sono gestite tramite il provider di identità esterno, ma gli account super amministratore ignorano l'accesso SSO e devono utilizzare una password per accedere a Cloud Identity. Disattiva il riutilizzo delle password e monitora la sicurezza delle password per tutti gli utenti che utilizzano una password per accedere a Cloud Identity, in particolare gli account super amministratore.
Imposta criteri a livello di organizzazione per l'utilizzo dei gruppi	Per impostazione predefinita, gli account utente esterni possono essere aggiunti ai gruppi in Cloud Identity. Ti consigliamo di configurare le impostazioni di condivisione in modo che i proprietari dei gruppi non possano aggiungere membri esterni. Tieni presente che questa limitazione non si applica all'account super amministratore o ad altri utenti con delega di amministratore con autorizzazioni di amministratore di Gruppi. Poiché la federazione del provider di identità viene eseguita con privilegi di amministratore, le impostazioni di condivisione dei gruppi non si applicano a questa sincronizzazione dei gruppi. Ti consigliamo di rivedere i controlli nel provider di identità e nel meccanismo di sincronizzazione per assicurarti che non vengano aggiunti membri non del dominio ai gruppi o di applicare limitazioni del gruppo.

Passaggi successivi

• Scopri di più sulla struttura organizzativa (prossimo documento di questa serie).

Struttura organizzativa

Il nodo radice per la gestione delle risorse in Google Cloud è l'organizzazione. L'organizzazione Google Cloud fornisce una gerarchia delle risorse che fornisce una struttura di proprietà per le risorse e i punti di collegamento per i criteri dell'organizzazione e i controlli dell'accesso. La gerarchia delle risorse è composta da cartelle, progetti e risorse e definisce la struttura e l'utilizzo dei servizi Google Cloud all'interno di un'organizzazione.

Le risorse più in basso nella gerarchia ereditano criteri come i criteri di autorizzazione IAM e i criteri dell'organizzazione. Tutte le autorizzazioni di accesso vengono negate per impostazione predefinita, finché non applichi i criteri di autorizzazione direttamente a una risorsa o la risorsa eredita i criteri di autorizzazione da un livello superiore nella gerarchia delle risorse.

Il seguente diagramma mostra le cartelle e i progetti di cui viene eseguito il deployment dal progetto.

Le seguenti sezioni descrivono le cartelle e i progetti presenti nel diagramma.

Cartelle

Il progetto utilizza le cartelle per raggruppare i progetti in base al loro ambiente. Questo raggruppamento logico viene utilizzato per applicare configurazioni come criteri di autorizzazione e criteri dell'organizzazione a livello di cartella, dopodiché tutte le risorse all'interno della cartella ereditano i criteri. La tabella seguente descrive le cartelle che fanno parte del progetto base.

Cartella	Descrizione
bootstrap	Contiene i progetti utilizzati per il deployment dei componenti di base.
common	Contiene progetti con risorse condivise da tutti gli ambienti.
production	Contiene progetti con risorse di produzione.
nonproduction	Contiene una copia dell'ambiente di produzione per consentirti di testare i carichi di lavoro prima di promuoverli in produzione.
development	Contiene le risorse cloud utilizzate per lo sviluppo.
networking	Contiene le risorse di networking condivise da tutti gli ambienti.

Progetti

Il progetto utilizza i progetti per raggruppare le singole risorse in base alla loro funzionalità e ai confini previsti per controllo dell'accesso#39;accesso. La tabella seguente descrive i progetti inclusi nel progetto base.

Cartella	Progetto	Descrizione
bootstrap	prj-b-cicd	Contiene la pipeline di deployment utilizzata per creare i componenti di base dell'organizzazione. Per ulteriori informazioni, consulta la metodologia di deployment.
	prj-b-seed	Contiene lo stato di Terraform dell'infrastruttura e l'account di servizio Terraform necessario per eseguire la pipeline. Per saperne di più, consulta la metodologia di deployment.
common	prj-c-secrets	Contiene secret a livello di organizzazione. Per maggiori informazioni, consulta l'articolo sull'archiviazione delle credenziali dell'applicazione con Secret Manager.
	prj-c-logging	Contiene le origini log aggregate per gli audit log. Per ulteriori informazioni, consulta Logging centralizzato per la sicurezza e l'audit.
	prj-c-scc	Contiene risorse per aiutare a configurare avvisi di Security Command Center e altro monitoraggio della sicurezza personalizzato. Per maggiori informazioni, consulta la pagina relativa al monitoraggio delle minacce con Security Command Center.
	prj-c-billing-logs	Contiene un set di dati BigQuery con le esportazioni della fatturazione dell'organizzazione. Per maggiori informazioni, consulta la pagina relativa all'allocazione dei costi tra i centri di costo interni.
	prj-c-infra-pipeline	Contiene una pipeline di infrastruttura per il deployment di risorse come VM e database da utilizzare nei carichi di lavoro. Per ulteriori informazioni, consulta i livelli della pipeline.
	prj-c-kms	Contiene chiavi di crittografia a livello di organizzazione. Per ulteriori informazioni, consulta la pagina relativa alla gestione delle chiavi di crittografia.
networking	prj-net-{env}-shared-base	Contiene il progetto host per una rete VPC condiviso per i carichi di lavoro che non richiedono Controlli di servizio VPC. Per ulteriori informazioni, consulta la sezione topologia di rete.
	prj-net-{env}-shared-restricted	Contiene il progetto host per una rete VPC condiviso per i carichi di lavoro che richiedono Controlli di servizio VPC. Per ulteriori informazioni, consulta la pagina relativa alla topologia di rete.
	prj-net-interconnect	Contiene le connessioni Cloud Interconnect che forniscono connettività tra il tuo ambiente on-premise e Google Cloud. Per ulteriori informazioni, consulta la sezione sulla connettività ibrida.
	prj-net-dns-hub	Contiene risorse per un punto di comunicazione centrale tra il sistema DNS on-premise e Cloud DNS. Per ulteriori informazioni, consulta la sezione Configurazione DNS centralizzata.
cartelle di ambiente (production, non-production e development)	prj-{env}-monitoring	Contiene un progetto di definizione dell'ambito per aggregare le metriche dei progetti in quell'ambiente. Per maggiori informazioni, consulta gli avvisi relativi a metriche e metriche basate su log.
	prj-{env}-secrets	Contiene secret a livello di cartella. Per maggiori informazioni, vedi Archiviare e controllare le credenziali delle applicazioni con Secret Manager.
	prj-{env}-kms	Contiene chiavi di crittografia a livello di cartella. Per ulteriori informazioni, consulta la pagina relativa alla gestione delle chiavi di crittografia.
	progetti di applicazione	Contiene vari progetti in cui crei risorse per le applicazioni. Per ulteriori informazioni, consulta i pattern di deployment dei progetti e i livelli della pipeline.

Governance per la proprietà delle risorse

Ti consigliamo di applicare etichette in modo coerente ai progetti per facilitare la governance e l'allocazione dei costi. La seguente tabella descrive le etichette del progetto che vengono aggiunte a ogni progetto per la governance nel progetto.

Etichetta	Descrizione
application	Il nome leggibile dell'applicazione o del carico di lavoro associato al progetto.
businesscode	Un breve codice che descrive quale unità aziendale è proprietaria del progetto. Il codice shared viene utilizzato per progetti comuni che non sono esplicitamente collegati a una business unit.
billingcode	Un codice utilizzato per fornire informazioni sullo storno di addebito.
primarycontact	Il nome utente del contatto principale responsabile del progetto. Poiché le etichette del progetto non possono includere caratteri speciali come la e commerciale (@), vengono impostate sul nome utente senza il suffisso @example.com.
secondarycontact	Il nome utente del contatto secondario secondario responsabile del progetto. Poiché le etichette del progetto non possono includere caratteri speciali come @, imposta solo il nome utente senza il suffisso @example.com.
environment	Un valore che identifica il tipo di ambiente, come bootstrap, common, production, non-production,development o network.
envcode	Un valore che identifica il tipo di ambiente, abbreviato in b, c, p, n, d o net.
vpc	L'ID della rete VPC che questo progetto dovrebbe utilizzare.

Occasionalmente Google potrebbe inviare notifiche importanti, quali sospensioni dell'account o aggiornamenti ai termini del prodotto. Il progetto utilizza i contatti necessari per inviare queste notifiche ai gruppi che configuri durante il deployment. I contatti necessari sono configurati a livello di nodo organizzazione ed ereditati da tutti i progetti dell'organizzazione. Ti consigliamo di controllare questi gruppi e di verificare che le email siano monitorate in modo affidabile.

I contatti necessari vengono utilizzati per uno scopo diverso rispetto ai campi primarycontact e secondarycontact configurati nelle etichette del progetto. I contatti nelle etichette del progetto sono destinati alla governance interna. Ad esempio, se identifichi risorse non conformi in un progetto di un carico di lavoro e devi contattare i proprietari, puoi utilizzare il campo primarycontact per trovare la persona o il team responsabile del carico di lavoro.

Passaggi successivi

• Scopri di più sul networking (documento successivo di questa serie).

Networking

Il networking è necessario per consentire alle risorse di comunicare all'interno della tua organizzazione Google Cloud e tra l'ambiente cloud e l'ambiente on-premise. Questa sezione descrive la struttura nel progetto per reti VPC, spazio di indirizzi IP, DNS, criteri firewall e connettività all'ambiente on-premise.

Topologia di rete

Il repository di progetti fornisce le seguenti opzioni per la topologia di rete:

• Utilizza reti VPC condiviso separate per ogni ambiente, senza traffico di rete consentito direttamente tra gli ambienti.
• Utilizza un modello hub e spoke che aggiunge una rete hub per connettere ogni ambiente in Google Cloud, con il traffico di rete tra ambienti controllati da un'appliance virtuale di rete (NVA).

Scegli la topologia di rete VPC condiviso doppia quando non vuoi la connettività di rete diretta tra gli ambienti. Scegli la topologia di rete hub e spoke quando vuoi consentire la connettività di rete tra ambienti filtrati da un'NVA, ad esempio quando ti affidi a strumenti esistenti che richiedono un percorso di rete diretto a ogni server nel tuo ambiente.

Entrambe le topologie utilizzano il VPC condiviso come principale costrutto di networking poiché il VPC condiviso consente una chiara separazione delle responsabilità. Gli amministratori di rete gestiscono le risorse di rete in un progetto host centralizzato, mentre i team dei carichi di lavoro eseguono il deployment delle proprie risorse dell'applicazione e utilizzano quelle dei progetti di servizio collegati al progetto host.

Entrambe le topologie includono una versione di base e una versione limitata di ogni rete VPC. La rete VPC di base viene utilizzata per le risorse che contengono dati non sensibili, mentre la rete VPC limitata viene utilizzata per le risorse con dati sensibili che richiedono i Controlli di servizio VPC. Per ulteriori informazioni sull'implementazione dei Controlli di servizio VPC, consulta Proteggere le risorse con i Controlli di servizio VPC.

Topologia di rete VPC doppia condivisa

Se hai bisogno dell'isolamento della rete tra le reti di sviluppo, non di produzione e di produzione su Google Cloud, ti consigliamo la topologia di rete VPC condiviso doppia. Questa topologia utilizza reti VPC condiviso separate per ogni ambiente, con ogni ambiente inoltre suddiviso tra una rete VPC condiviso di base e una rete VPC condiviso limitata.

Il seguente diagramma mostra la topologia di rete VPC condiviso doppia.

Il diagramma descrive questi concetti chiave della topologia doppia di VPC condiviso:

• Ogni ambiente (produzione, non produzione e sviluppo) ha una rete VPC condiviso per la rete di base e una rete VPC condiviso per la rete limitata. Questo diagramma mostra solo l'ambiente di produzione, ma lo stesso pattern viene ripetuto per ogni ambiente.
• Ogni rete VPC condivisa ha due subnet e ognuna si trova in una regione diversa.
• La connettività con le risorse on-premise viene abilitata tramite quattro collegamenti VLAN all'istanza Dedicated Interconnect per ogni rete VPC condiviso, utilizzando quattro servizi router Cloud (due in ogni regione per la ridondanza). Per maggiori informazioni, consulta Connettività ibrida tra ambiente on-premise e Google Cloud.

In base alla sua progettazione, questa topologia non consente il flusso del traffico di rete direttamente tra gli ambienti. Se richiedi che il traffico di rete passi direttamente da un ambiente all'altro, devi adottare ulteriori passaggi per consentire questo percorso di rete. Ad esempio, puoi configurare gli endpoint Private Service Connect per esporre un servizio da una rete VPC a un'altra rete VPC. In alternativa, puoi configurare la rete on-premise in modo da consentire il flusso del traffico da un ambiente Google Cloud all'ambiente on-premise e poi a un altro ambiente Google Cloud.

Topologia di rete hub e spoke

Se esegui il deployment di risorse in Google Cloud che richiedono un percorso di rete diretto alle risorse in più ambienti, ti consigliamo la topologia di rete hub e spoke.

La topologia hub e spoke utilizza diversi dei concetti che fanno parte della topologia del VPC condiviso doppia, ma modifica la topologia per aggiungere una rete hub. Il seguente diagramma mostra la topologia hub e spoke.

Il diagramma descrive questi concetti chiave della topologia di rete hub e spoke:

• Questo modello aggiunge una rete hub e ciascuna delle reti di sviluppo, non di produzione e di produzione (spoke) è connessa alla rete hub tramite il peering di rete VPC. In alternativa, se prevedi di superare il limite di quota, puoi utilizzare un gateway VPN ad alta disponibilità.
• La connettività alle reti on-premise è consentita solo tramite la rete hub. Tutte le reti spoke possono comunicare con le risorse condivise nella rete hub e utilizzare questo percorso per connettersi alle reti on-premise.
• Le reti hub includono un NVA per ogni regione, di cui viene eseguito il deployment in modo ridondante dietro istanze di Network Load Balancer interni. L'NVA funge da gateway per consentire o negare il traffico di comunicazione tra reti spoke.
• La rete hub ospita anche strumenti che richiedono la connettività a tutte le altre reti. Ad esempio, puoi eseguire il deployment di strumenti sulle istanze VM per la gestione della configurazione nell'ambiente comune.
• Il modello hub e spoke è duplicato per una versione di base e una versione limitata di ogni rete.

Per abilitare il traffico spoke-to-spoke, il progetto esegue il deployment degli NVA sulla rete VPC condiviso dell'hub che fungono da gateway tra le reti. Le route vengono scambiate da reti VPC hub-spoke tramite lo scambio di route personalizzate. In questo scenario, la connettività tra spoke deve essere instradata attraverso l'NVA poiché il peering di rete VPC non è transitorio e, di conseguenza, le reti VPC spoke non possono scambiare dati direttamente tra loro. Devi configurare le appliance virtuali in modo da consentire selettivamente il traffico tra gli spoke.

Per ulteriori informazioni sull'utilizzo delle NVA per controllare il traffico tra spoke, consulta appliance di rete centralizzate su Google Cloud.

Pattern di deployment dei progetti

Quando crei nuovi progetti per i carichi di lavoro, devi decidere in che modo le risorse di questo progetto si connettono alla rete esistente. La seguente tabella descrive i pattern per il deployment di progetti utilizzati nel progetto base.

Pattern	Descrizione	Esempio di utilizzo
Progetti di base condivisi	Questi progetti sono configurati come progetti di servizio in un progetto host VPC condiviso di base. Utilizza questo pattern quando le risorse nel tuo progetto hanno i seguenti criteri: Richiedi la connettività di rete all'ambiente on-premise o alle risorse nella stessa topologia del VPC condiviso. Richiedere un percorso di rete per i servizi Google contenuti nell'indirizzo IP virtuale privato. Non richiedono Controlli di servizio VPC.	example_base_shared_vpc_project.tf
Progetti limitati condivisi	Questi progetti sono configurati come progetti di servizio per un progetto host VPC condiviso limitato. Utilizza questo pattern quando le risorse nel tuo progetto hanno i seguenti criteri: Richiedi la connettività di rete all'ambiente on-premise o alle risorse nella stessa topologia del VPC condiviso. Richiedere un percorso di rete per i servizi Google contenuti nell'indirizzo IP virtuale limitato. Richiedi i Controlli di servizio VPC.	example_restricted_shared_vpc_project.tf
Progetti mobili	I progetti floating non sono connessi ad altre reti VPC nella topologia. Utilizza questo pattern quando le risorse nel tuo progetto hanno i seguenti criteri: Non richiedere una connettività mesh completa a un ambiente on-premise o a risorse nella topologia VPC condiviso. Non richiedere una rete VPC o vuoi gestire la rete VPC per questo progetto indipendentemente dalla topologia della rete VPC principale (ad esempio quando vuoi utilizzare un intervallo di indirizzi IP in conflitto con gli intervalli già in uso). Potresti voler mantenere la rete VPC di un progetto mobile separata dalla topologia di rete VPC principale, ma anche esporre un numero limitato di endpoint tra le reti. In questo caso, pubblica i servizi utilizzando Private Service Connect per condividere l'accesso alla rete con un singolo endpoint nelle reti VPC senza esporre l'intera rete.	example_floating_project.tf
Progetti di peering	I progetti di peering creano le proprie reti VPC e sono in peering con altre reti VPC nella tua topologia. Utilizza questo pattern quando le risorse nel tuo progetto hanno i seguenti criteri: Richiedi la connettività di rete nella rete VPC in peering direttamente, ma non hai bisogno di connettività transitiva a un ambiente on-premise o ad altre reti VPC. Devi gestire la rete VPC per questo progetto indipendentemente dalla topologia di rete principale. Se crei progetti di peering, è tua responsabilità allocare intervalli di indirizzi IP non in conflitto e pianificare la quota di gruppi di peering.	example_peering_project.tf

Allocazione degli indirizzi IP

Questa sezione illustra in che modo l'architettura del progetto base alloca gli intervalli di indirizzi IP. Potrebbe essere necessario modificare gli intervalli specifici di indirizzi IP utilizzati in base alla disponibilità degli indirizzi IP nell'ambiente ibrido esistente.

La seguente tabella fornisce una suddivisione dello spazio di indirizzi IP allocato per il progetto base. L'ambiente hub si applica solo nella topologia hub e spoke.

Finalità	Tipo di VPC	Regione	Ambiente hub	Ambiente di sviluppo	Ambiente non di produzione	Ambiente di produzione
Intervalli di subnet principali	Livelli	Regione 1	10.0.0.0/18	10.0.64.0/18	10.0.128.0/18	10.0.192.0/18
		Regione 2	10.1.0.0/18	10.1.64.0/18	10.1.128.0/18	10.1.192.0/18
		Non allocata	10.{2-7}.0.0/18	10.{2-7}.64.0/18	10.{2-7}.128.0/18	10.{2-7}.192.0/18
	Limitato	Regione 1	10.8.0.0/18	10.8.64.0/18	10.8.128.0/18	10.8.192.0/18
		Regione 2	10.9.0.0/18	10.9.64.0/18	10.9.128.0/18	10.9.192.0/18
		Non allocata	10.{10-15}.0.0/18	10.{10-15}.64.0/18	10.{10-15}.128.0/18	10.{10-15}.192.0/18
Accesso privato ai servizi	Livelli	Globale	10.16.0.0/21	10.16.8.0/21	10.16.16.0/21	10.16.24.0/21
	Limitato	Globale	10.16.32.0/21	10.16.40.0/21	10.16.48.0/21	10.16.56.0/21
Endpoint di Private Service Connect	Livelli	Globale	10.17.0.1/32	10.17.0.2/32	10.17.0.3/32	10.17.0.4/32
	Limitato	Globale	10.17.0.5/32	10.17.0.6/32	10.17.0.7/32	10.17.0.8/32
Subnet solo proxy	Livelli	Regione 1	10.18.0.0/23	10.18.2.0/23	10.18.4.0/23	10.18.6.0/23
		Regione 2	10.19.0.0/23	10.19.2.0/23	10.19.4.0/23	10.19.6.0/23
		Non allocata	10.{20-25}.0.0/23	10.{20-25}.2.0/23	10.{20-25}.4.0/23	10.{20-25}.6.0/23
	Limitato	Regione 1	10.26.0.0/23	10.26.2.0/23	10.26.4.0/23	10.26.6.0/23
		Regione 2	10.27.0.0/23	10.27.2.0/23	10.27.4.0/23	10.27.6.0/23
		Non allocata	10.{28-33}.0.0/23	10.{28-33}.2.0/23	10.{28-33}.4.0/23	10.{28-33}.6.0/23
Intervalli di subnet secondari	Livelli	Regione 1	100.64.0.0/18	100.64.64.0/18	100.64.128.0/18	100.64.192.0/18
		Regione 2	100.65.0.0/18	100.65.64.0/18	100.65.128.0/18	100.65.192.0/18
		Non allocata	100/{66-71}.0.0/18	100,{66-71}.64.0/18	100,{66-71}.128,0/18	100,{66-71}.192,0/18
	Limitato	Regione 1	100.72.0.0/18	100.72.64.0/18	100.72.128.0/18	100.72.192.0/18
		Regione 2	100.73.0.0/18	100.73.64.0/18	100.73.128.0/18	100.73.192.0/18
		Non allocata	100/{74-79}.0.0/18	100,{74-79}.64.0/18	100,{74-79}.128,0/18	100,{74-79}.192,0/18

La tabella precedente illustra questi concetti per l'allocazione di intervalli di indirizzi IP:

• L'allocazione degli indirizzi IP è suddivisa in intervalli per ogni combinazione di VPC di base, VPC condiviso limitato, regione e ambiente.
• Alcune risorse sono globali e non richiedono suddivisioni per ogni regione.
• Per impostazione predefinita, per le risorse a livello di regione, il deployment del progetto base viene eseguito in due regioni. Inoltre, esistono intervalli di indirizzi IP inutilizzati che puoi espandere in altre sei regioni.
• La rete hub viene utilizzata solo nella topologia di rete hub e spoke, mentre gli ambienti di sviluppo, non di produzione e produzione vengono utilizzati in entrambe le topologie di rete.

La tabella seguente illustra come viene utilizzato ogni tipo di intervallo di indirizzi IP.

Finalità	Descrizione
Intervalli di subnet principali	Le risorse di cui esegui il deployment nella tua rete VPC, ad esempio istanze di macchine virtuali, utilizzano gli indirizzi IP interni di questi intervalli.
Accesso privato ai servizi	Alcuni servizi Google Cloud, come Cloud SQL, richiedono di preallocare un intervallo di subnet per l'accesso privato ai servizi. Il progetto prenota un intervallo /21 a livello globale per ciascuna delle reti VPC condiviso per allocare gli indirizzi IP per i servizi che richiedono l'accesso privato ai servizi. Quando crei un servizio che dipende dall'accesso privato ai servizi, alloca una subnet /24 a livello di regione dall'intervallo /21 riservato.
Private Service Connect	Il progetto esegue il provisioning di ogni rete VPC con un endpoint Private Service Connect per comunicare con le API Google Cloud. Questo endpoint consente alle risorse nella rete VPC di raggiungere le API Google Cloud senza fare affidamento sul traffico in uscita verso internet o su intervalli internet pubblicamente pubblicizzati.
Bilanciatori del carico basati su proxy	Alcuni tipi di bilanciatori del carico delle applicazioni richiedono di preallocare subnet solo proxy. Sebbene il progetto non esegua il deployment di bilanciatori del carico delle applicazioni che richiedono questo intervallo, l'allocazione anticipata degli intervalli aiuta a ridurre gli attriti per i carichi di lavoro quando è necessario richiedere un nuovo intervallo di subnet per abilitare determinate risorse del bilanciatore del carico.
Intervalli di subnet secondari	Alcuni casi d'uso, come i carichi di lavoro basati su container, richiedono intervalli secondari. Il progetto base assegna intervalli dallo spazio di indirizzi IP RFC 6598 per gli intervalli secondari.

Configurazione del DNS centralizzato

Per la risoluzione DNS tra Google Cloud e ambienti on-premise, ti consigliamo di utilizzare un approccio ibrido con due sistemi DNS autorevoli. In questo approccio, Cloud DNS gestisce la risoluzione DNS autoritativa per il tuo ambiente Google Cloud, mentre i tuoi server DNS on-premise esistenti gestiscono una risoluzione DNS autoritativa per le risorse on-premise. L'ambiente on-premise e l'ambiente Google Cloud eseguono ricerche DNS tra gli ambienti tramite richieste di inoltro.

Il seguente diagramma mostra la topologia DNS in più reti VPC utilizzate nel progetto.

Il diagramma descrive i seguenti componenti della progettazione DNS di cui viene eseguito il deployment dal progetto base:

• Il progetto hub DNS nella cartella comune è il punto centrale dello scambio DNS tra l'ambiente on-premise e l'ambiente Google Cloud. L'inoltro DNS utilizza le stesse istanze Dedicated Interconnect e gli stessi router Cloud già configurati nella tua topologia di rete.
  • Nella topologia doppia del VPC condiviso, l'hub DNS utilizza la rete VPC condivisa di produzione di base.
  • Nella topologia hub e spoke, l'hub DNS utilizza la rete VPC condiviso dell'hub di base.
• I server in ogni rete VPC condivisa possono risolvere i record DNS di altre reti VPC condivise tramite l'inoltro DNS, configurato tra Cloud DNS in ogni progetto host del VPC condiviso e l'hub DNS.
• I server on-premise possono risolvere i record DNS negli ambienti Google Cloud utilizzando i criteri dei server DNS che consentono le query dai server on-premise. Il progetto configura un criterio del server in entrata nell'hub DNS per allocare gli indirizzi IP e i server DNS on-premise inoltrano le richieste a questi indirizzi. Tutte le richieste DNS inviate a Google Cloud raggiungono prima l'hub DNS, che poi risolve i record dei peer DNS.
• I server in Google Cloud possono risolvere i record DNS nell'ambiente on-premise utilizzando le zone di inoltro che eseguono query sui server on-premise. Tutte le richieste DNS all'ambiente on-premise provengono dall'hub DNS. L'origine della richiesta DNS è 35.199.192.0/19.

Criteri firewall

Google Cloud ha diversi tipi di criteri firewall. I criteri firewall gerarchici vengono applicati a livello di organizzazione o cartella per ereditare le regole dei criteri firewall in modo coerente in tutte le risorse della gerarchia. Inoltre, puoi configurare i criteri firewall di rete per ogni rete VPC. Il progetto combina questi criteri firewall per applicare configurazioni comuni in tutti gli ambienti utilizzando criteri firewall gerarchici e per applicare configurazioni più specifiche in ogni singola rete VPC utilizzando i criteri firewall di rete.

Il progetto non utilizza le regole firewall VPC legacy. Consigliamo di utilizzare solo criteri firewall ed evitare di combinare l'utilizzo con le regole firewall VPC legacy.

Criteri firewall gerarchici

Il progetto definisce un singolo criterio firewall gerarchico e lo collega a ciascuna delle cartelle di produzione, non di produzione, di sviluppo, bootstrap e comuni. Questo criterio firewall gerarchico contiene le regole che devono essere applicate in modo ampio a tutti gli ambienti e delega la valutazione di regole più granulari al criterio firewall di rete per ogni singolo ambiente.

La tabella seguente descrive le regole dei criteri firewall gerarchici di cui è stato eseguito il deployment dal progetto.

Descrizione regola	Direzione del traffico	Filtro (intervallo IPv4)	Protocolli e porte	Azione
Delegare la valutazione del traffico in entrata da RFC 1918 ai livelli inferiori della gerarchia.	Ingress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
Delegare la valutazione del traffico in uscita a RFC 1918 ai livelli inferiori della gerarchia.	Egress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
IAP per forwarding TCP	Ingress	35.235.240.0/20	tcp:22,3390	Allow
Attivazione di Windows Server	Egress	35.190.247.13/32	tcp:1688	Allow
Controlli di integrità per Cloud Load Balancing	Ingress	130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22	tcp:80,443	Allow

Criteri firewall di rete

Il progetto configura un criterio firewall di rete per ogni rete. Ogni criterio firewall di rete inizia con un insieme minimo di regole che consentono l'accesso ai servizi Google Cloud e negano il traffico in uscita verso tutti gli altri indirizzi IP.

Nel modello hub e spoke, i criteri firewall di rete contengono regole aggiuntive per consentire la comunicazione tra spoke. Il criterio firewall di rete consente il traffico in uscita da uno allo spoke dell'hub o di un altro e consente il traffico in entrata dall'NVA nella rete hub.

La seguente tabella descrive le regole del criterio firewall di rete globale di cui è stato eseguito il deployment per ogni rete VPC nel progetto.

Descrizione regola	Direzione del traffico	Filtro	Protocolli e porte
Consenti il traffico in uscita verso le API Google Cloud.	Egress	L'endpoint Private Service Connect configurato per ogni singola rete. Vedi Accesso privato alle API di Google.	tcp:443
Nega il traffico in uscita che non corrisponde ad altre regole.	Egress	tutte	all
Consenti il traffico in uscita da uno spoke a un altro (solo per il modello hub e spoke).	Egress	L'aggregazione di tutti gli indirizzi IP utilizzati nella topologia hub e spoke. Il traffico che esce da un VPC spoke viene instradato prima all'NVA nella rete hub.	all
Consenti il traffico in entrata verso uno spoke dall'NVA nella rete hub (solo per il modello hub e spoke).	Ingress	Traffico proveniente dalle NVA nella rete hub.	all

Quando esegui il deployment del progetto base per la prima volta, un'istanza VM in una rete VPC può comunicare con i servizi Google Cloud, ma non con altre risorse di infrastruttura nella stessa rete VPC. Per consentire la comunicazione delle istanze VM, devi aggiungere ulteriori regole al criterio firewall di rete e ai tag che consentono esplicitamente alle istanze VM di comunicare. I tag vengono aggiunti alle istanze VM e il traffico viene valutato in base a questi tag. I tag dispongono inoltre di controlli IAM che consentono di definirli centralmente e delegare il loro utilizzo ad altri team.

Il seguente diagramma mostra un esempio di come aggiungere tag personalizzati e regole dei criteri firewall di rete per consentire ai carichi di lavoro di comunicare all'interno di una rete VPC.

Il diagramma illustra i seguenti concetti di questo esempio:

• Il criterio firewall di rete contiene la regola 1 che nega il traffico in uscita da tutte le origini con priorità 65530.
• Il criterio firewall di rete contiene la Regola 2 che consente il traffico in entrata dalle istanze con il tag service=frontend alle istanze con il tag service=backend con priorità 999.
• La VM istanza-2 può ricevere traffico dall'istanza-1 perché il traffico corrisponde ai tag consentiti dalla Regola 2. La regola 2 viene soddisfatta prima che venga valutata la regola 1, in base al valore di priorità.
• La VM istanza-3 non riceve traffico. L'unica regola del criterio firewall che corrisponde a questo traffico è la Regola 1, quindi il traffico in uscita dall'istanza-1 viene negato.

Accesso privato alle API Google Cloud

Per consentire alle risorse nelle tue reti VPC o nel tuo ambiente on-premise di raggiungere i servizi Google Cloud, consigliamo la connettività privata anziché in uscita del traffico internet verso endpoint API pubblici. Il progetto configura l'accesso privato Google su ogni subnet e crea endpoint interni con Private Service Connect per comunicare con i servizi Google Cloud. Se utilizzati insieme, questi controlli consentono un percorso privato ai servizi Google Cloud, senza fare affidamento sul traffico in uscita da internet o su intervalli internet pubblicizzati pubblicamente.

Il progetto configura gli endpoint Private Service Connect con i gruppi di API per distinguere i servizi all'interno di una determinata rete. La rete di base utilizza il pacchetto all-apis e può raggiungere qualsiasi servizio Google, mentre la rete limitata utilizza il pacchetto vpcsc, che consente l'accesso a un insieme limitato di servizi che supportano i Controlli di servizio VPC.

Per l'accesso da host che si trovano in un ambiente on-premise, ti consigliamo di utilizzare una convenzione di nome di dominio completo personalizzato per ogni endpoint, come descritto nella tabella seguente. Il progetto utilizza un endpoint Private Service Connect univoco per ogni rete VPC, configurato per l'accesso a un set diverso di bundle API. Pertanto, devi valutare come instradare il traffico dei servizi dall'ambiente on-premise alla rete VPC con l'endpoint API corretto e, se utilizzi Controlli di servizio VPC, assicurati che il traffico verso i servizi Google Cloud raggiunga l'endpoint all'interno del perimetro previsto. Configura i controlli on-premise per DNS, firewall e router in modo da consentire l'accesso a questi endpoint, nonché configurare gli host on-premise per l'utilizzo dell'endpoint appropriato. Per maggiori informazioni, consulta Accedere alle API di Google tramite endpoint.

Nella tabella seguente vengono descritti gli endpoint Private Service Connect creati per ogni rete.

VPC	Ambiente	Bundle di API	Indirizzo IP endpoint Private Service Connect			Nome di dominio completo personalizzato
Livelli	Nome	all-apis	10.17.0.1/32			c.private.googleapis.com
	Sviluppo	all-apis	10.17.0.2/32			d.private.googleapis.com
	Non di produzione	all-apis	10.17.0.3/32			n.private.googleapis.com
	Produzione	all-apis	10.17.0.4/32			p.private.googleapis.com
Limitato	Nome	vpcsc	10.17.0.5/32			c.restricted.googleapis.com
	Sviluppo	vpcsc	10.17.0.6/32			d.restricted.googleapis.com
	Non di produzione	vpcsc	10.17.0.7/32			n.restricted.googleapis.com
	Produzione	vpcsc	10.17.0.8/32			p.restricted.googleapis.com

Per garantire che il traffico per i servizi Google Cloud abbia una ricerca DNS nell'endpoint corretto, il progetto configura le zone DNS private per ogni rete VPC. La tabella seguente descrive queste zone DNS private.

Nome zona privata	Nome DNS	Tipo di record	Dati
googleapis.com.	*.googleapis.com.	CNAME	private.googleapis.com. (per le reti di base) o restricted.googleapis.com. (per le reti limitate)
	private.googleapis.com (per le reti di base) o restricted.googleapis.com (per le reti limitate)	A	L'indirizzo IP dell'endpoint di Private Service Connect per quella rete VPC.
gcr.io.	*.gcr.io	CNAME	gcr.io.
	gcr.io	A	L'indirizzo IP dell'endpoint di Private Service Connect per quella rete VPC.
pkg.dev.	*.pkg.dev.	CNAME	pkg.dev.
	pkg.dev.	A	L'indirizzo IP dell'endpoint di Private Service Connect per quella rete VPC.

Il progetto prevede configurazioni aggiuntive per far sì che questi endpoint Private Service Connect vengano utilizzati in modo coerente. Ogni rete VPC condiviso applica anche le seguenti impostazioni:

• Una regola del criterio firewall di rete che consente il traffico in uscita da tutte le origini verso l'indirizzo IP dell'endpoint Private Service Connect su TCP:443.
• Una regola del criterio firewall di rete che nega il traffico in uscita a 0.0.0.0/0, che include i domini predefiniti utilizzati per l'accesso ai servizi Google Cloud.

Connessione a internet

Il progetto non consente il traffico in entrata o in uscita tra le sue reti VPC e internet. Per i carichi di lavoro che richiedono una connessione a internet, è necessario seguire ulteriori passaggi per progettare i percorsi di accesso richiesti.

Per i carichi di lavoro che richiedono il traffico in uscita verso internet, ti consigliamo di gestire il traffico in uscita tramite Cloud NAT per consentire il traffico in uscita senza connessioni in entrata non richieste o tramite Secure Web Proxy per un controllo più granulare e consentire il traffico in uscita solo ai servizi web attendibili.

Per i carichi di lavoro che richiedono il traffico in entrata da internet, ti consigliamo di progettare il tuo carico di lavoro con Cloud Load Balancing e Google Cloud Armor per trarre vantaggio dalle protezioni DDoS e WAF.

Sconsigliamo di progettare carichi di lavoro che consentano la connettività diretta tra internet e una VM utilizzando un indirizzo IP esterno sulla VM.

Connettività ibrida tra un ambiente on-premise e Google Cloud

Per stabilire la connettività tra l'ambiente on-premise e Google Cloud, ti consigliamo di utilizzare Dedicated Interconnect per massimizzare la sicurezza e l'affidabilità. Una connessione Dedicated Interconnect è un collegamento diretto tra la tua rete on-premise e Google Cloud.

Il seguente diagramma illustra la connettività ibrida tra l'ambiente on-premise e una rete Google Virtual Private Cloud.

Il diagramma descrive i seguenti componenti del pattern per la disponibilità del 99,99% per Dedicated Interconnect:

• Quattro connessioni Dedicated Interconnect, con due connessioni in un'area metropolitana (area metropolitana) e due in un'altra area metropolitana.
• Le connessioni sono divise in due coppie, ciascuna connessa a un data center on-premise separato.
• I collegamenti VLAN vengono utilizzati per connettere ogni istanza di Dedicated Interconnect ai router Cloud collegati alla topologia VPC condiviso. Questi collegamenti VLAN sono ospitati nel progetto prj-c-interconnect.
• Ogni rete VPC condivisa ha quattro router Cloud, due in ogni regione, con la modalità di routing dinamico impostata su global in modo che ogni router Cloud possa annunciare tutte le subnet, indipendentemente dalla regione.

Con il routing dinamico globale, il router Cloud pubblicizza le route verso tutte le subnet nella rete VPC. Il router Cloud pubblicizza le route verso subnet remote (subnet al di fuori della regione del router Cloud) con una priorità inferiore rispetto alle subnet locali (subnet che si trovano nella regione del router Cloud). Se vuoi, puoi modificare prefissi e priorità pubblicizzati quando configuri la sessione BGP per un router Cloud.

Il traffico da Google Cloud a un ambiente on-premise utilizza il router Cloud più vicino alle risorse cloud. All'interno di una singola regione, più route verso reti on-premise hanno lo stesso valore di discriminatore multi-uscita (MED) e Google Cloud utilizza il routing ECMP a costo uguale per distribuire il traffico in uscita tra tutte le route possibili.

Modifiche alla configurazione on-premise

Per configurare la connettività tra l'ambiente on-premise e Google Cloud, devi configurare ulteriori modifiche nell'ambiente on-premise. Il codice Terraform nel progetto configura automaticamente le risorse Google Cloud, ma non modifica nessuna risorsa di rete on-premise.

Alcuni dei componenti per la connettività ibrida dal tuo ambiente on-premise a Google Cloud vengono abilitati automaticamente dal progetto, tra cui:

• Cloud DNS è configurato con l'inoltro DNS tra tutte le reti VPC condiviso a un singolo hub, come descritto in Configurazione DNS. Un criterio del server Cloud DNS viene configurato con indirizzi IP del forwarding in entrata.
• Il router Cloud è configurato per esportare le route per tutte le subnet e le route personalizzate per gli indirizzi IP utilizzati dagli endpoint Private Service Connect.

Per abilitare la connettività ibrida, devi seguire questi passaggi aggiuntivi:

1. Ordina una connessione Dedicated Interconnect.
2. Configura router e firewall on-premise per consentire il traffico in uscita verso lo spazio di indirizzi IP interni definito nell'allocazione dello spazio di indirizzi IP.
3. Configura i tuoi server DNS on-premise per inoltrare le ricerche DNS associate a Google Cloud agli indirizzi IP del forwarding in entrata già configurati dal progetto.
4. Configura i server, i firewall e i router DNS on-premise in modo che accettino query DNS dalla zona di forwarding di Cloud DNS (35.199.192.0/19).
5. Configura i server DNS on-premise per rispondere alle query dagli host on-premise ai servizi Google Cloud con gli indirizzi IP definiti nell'accesso privato alle API Cloud.
6. Per la crittografia dei dati in transito sulla connessione Dedicated Interconnect, configura MACsec per Cloud Interconnect o VPN ad alta disponibilità su Cloud Interconnect per la crittografia IPsec.

Per maggiori informazioni, consulta Accesso privato Google per gli host on-premise.

Passaggi successivi

• Leggi ulteriori informazioni sui controlli di rilevamento (documento successivo di questa serie).

Controlli di rilevamento

Le funzionalità di rilevamento e monitoraggio delle minacce vengono fornite utilizzando una combinazione di controlli di sicurezza integrati di Security Command Center e soluzioni personalizzate che consentono di rilevare e rispondere agli eventi di sicurezza.

Logging centralizzato per sicurezza e audit

Il progetto configura le funzionalità di logging per monitorare e analizzare le modifiche alle risorse Google Cloud con i log aggregati a un singolo progetto.

Il seguente diagramma mostra in che modo il progetto base aggrega i log di più origini in più progetti in un sink di log centralizzato.

Il diagramma descrive quanto segue:

• I sink di log sono configurati nel nodo organizzazione per aggregare i log di tutti i progetti nella gerarchia delle risorse.
• Sono configurati più sink di log per inviare i log corrispondenti a un filtro a destinazioni diverse per l'archiviazione e l'analisi.
• Il progetto prj-c-logging contiene tutte le risorse per l'archiviazione e l'analisi dei log.
• Facoltativamente, puoi configurare strumenti aggiuntivi per esportare i log in un SIEM.

Il progetto base utilizza diverse origini log e li include nel filtro del sink di log, in modo che possano essere esportati in una destinazione centralizzata. La tabella seguente descrive le origini log.

Sorgente log	Descrizione
Audit log delle attività di amministrazione	Non puoi configurare, disabilitare o escludere gli audit log delle attività di amministrazione.
Audit log degli eventi di sistema	Non puoi configurare, disabilitare o escludere gli audit log degli eventi di sistema.
Audit log negati per i criteri	Non puoi configurare o disabilitare gli audit log relativi ai criteri negati, ma puoi facoltativamente escluderli con i filtri di esclusione.
Audit log degli accessi ai dati	Per impostazione predefinita, il progetto base non abilita i log di accesso ai dati perché il volume e il costo di questi log possono essere elevati. Per determinare se devi abilitare i log degli accessi ai dati, valuta dove i tuoi carichi di lavoro gestiscono i dati sensibili e valuta se hai l'obbligo di abilitare i log degli accessi ai dati per ogni servizio e ambiente che utilizza dati sensibili.
Log di flusso VPC	Il progetto abilita i log di flusso VPC per ogni subnet. Il progetto configura il campionamento dei log per campionare il 50% dei log e ridurre i costi. Se crei subnet aggiuntive, devi assicurarti che i log di flusso VPC siano abilitati per ogni subnet.
Logging delle regole firewall	Il progetto base abilita il logging delle regole firewall per ogni regola del criterio firewall. Se crei regole dei criteri firewall aggiuntive per i carichi di lavoro, devi assicurarti che il logging delle regole firewall sia abilitato per ogni nuova regola.
Logging di Cloud DNS	Il progetto consente di attivare i log di Cloud DNS per le zone gestite. Se crei zone gestite aggiuntive, devi abilitare questi log DNS.
Log di controllo di Google Workspace	Richiede un passaggio di abilitazione una tantum non automatizzato dal progetto. Per ulteriori informazioni, vedi Condividere dati con i servizi di Google Cloud.
Log di Access Transparency	Richiede un passaggio di abilitazione una tantum non automatizzato dal progetto. Per ulteriori informazioni, consulta Attivare Access Transparency.

La seguente tabella descrive i sink di log e il modo in cui vengono utilizzati con le destinazioni supportate nel progetto base.

Sink	Destinazione	Finalità
sk-c-logging-la	Log instradati ai bucket Cloud Logging con Analisi dei log e un set di dati BigQuery collegato abilitato	Analizzare attivamente i log. Esegui indagini ad hoc utilizzando Esplora log nella console oppure scrivi query, report e viste SQL utilizzando il set di dati BigQuery collegato.
sk-c-logging-bkt	Log instradati a Cloud Storage	Archivia i log a lungo termine per finalità di conformità, controllo e monitoraggio degli incidenti. Facoltativamente, se hai requisiti di conformità per la conservazione obbligatoria dei dati, ti consigliamo di configurare inoltre il blocco di bucket.
sk-c-logging-pub	Log con routing a Pub/Sub	Esporta i log su una piattaforma esterna come il tuo SIEM esistente. Questa operazione richiede attività aggiuntive per l'integrazione con il SIEM, come i seguenti meccanismi: Per molti strumenti, l'integrazione di terze parti con Pub/Sub è il metodo preferito per importare i log. Per Google Google Security Operations, puoi importare dati di Google Cloud in Google Security Operations senza eseguire il provisioning di un'infrastruttura aggiuntiva. Per Splunk, puoi eseguire il flusso di log da Google Cloud a Splunk utilizzando Dataflow.

Per indicazioni su come abilitare tipi di log aggiuntivi e scrivere filtri del sink di log, consulta lo strumento di definizione dell'ambito dei log.

Monitoraggio delle minacce con Security Command Center

Ti consigliamo di attivare Security Command Center Premium per la tua organizzazione per rilevare automaticamente minacce, vulnerabilità e configurazioni errate nelle risorse Google Cloud. Security Command Center crea risultati di sicurezza da più origini, tra cui:

• Security Health Analytics: rileva vulnerabilità e configurazioni errate comuni nelle risorse Google Cloud.
• Esposizione al percorso di attacco: mostra un percorso simulato di come un utente malintenzionato potrebbe sfruttare le tue risorse di alto valore, in base alle vulnerabilità e alle configurazioni errate rilevate da altre origini di Security Command Center.
• Event Threat Detection: applica la logica di rilevamento e l'intelligence sulle minacce proprietarie ai tuoi log per identificare le minacce quasi in tempo reale.
• Container Threat Detection: rileva gli attacchi comuni di runtime dei container.
• Virtual Machine Threat Detection: rileva le applicazioni potenzialmente dannose in esecuzione su macchine virtuali.
• Web Security Scanner: esegue la scansione delle dieci principali vulnerabilità OWASP nelle tue applicazioni per il web su Compute Engine, App Engine o Google Kubernetes Engine.

Per ulteriori informazioni sulle vulnerabilità e sulle minacce affrontate da Security Command Center, consulta le origini di Security Command Center.

Devi attivare Security Command Center dopo aver eseguito il deployment del progetto base. Per le istruzioni, vedi Attivare Security Command Center per un'organizzazione.

Dopo aver attivato Security Command Center, ti consigliamo di esportare i risultati prodotti da Security Command Center negli strumenti o nei processi esistenti per valutare e rispondere alle minacce. Il progetto crea il progetto prj-c-scc con un argomento Pub/Sub da utilizzare per questa integrazione. A seconda degli strumenti in uso, utilizza uno dei seguenti metodi per esportare i risultati:

• Se utilizzi la console per gestire i risultati sulla sicurezza direttamente in Security Command Center, configura i ruoli a livello di cartella e progetto per Security Command Center per consentire ai team di visualizzare e gestire i risultati sulla sicurezza solo per i progetti di cui sono responsabili.

• Se utilizzi Google SecOps come SIEM, importa i dati di Google Cloud in Google SecOps.

• Se utilizzi uno strumento SIEM o SOAR con integrazioni con Security Command Center, condividi i dati con Cortex XSOAR, Elastic Stack, ServiceNow, Splunk o QRadar.

• Se utilizzi uno strumento esterno in grado di importare i risultati da Pub/Sub, configura le esportazioni continue in Pub/Sub e configura gli strumenti esistenti per importare i risultati dall'argomento Pub/Sub.

Avvisi sulle metriche basate su log e sulle prestazioni

Quando inizi a eseguire il deployment dei carichi di lavoro sulla base degli elementi di base, ti consigliamo di utilizzare Cloud Monitoring per misurare le metriche delle prestazioni.

Il progetto crea un progetto di monitoraggio come prj-p-monitoring per ogni ambiente. Questo progetto è configurato come progetto di ambito per raccogliere metriche aggregate sulle prestazioni di più progetti. Il progetto esegue il deployment di un esempio con metriche basate su log e un criterio di avviso per generare notifiche email in caso di modifiche al criterio IAM applicato ai bucket Cloud Storage. Ciò consente di monitorare le attività sospette su risorse sensibili come il bucket nel progetto prj-b-seed che contiene lo stato di Terraform.

Più in generale, puoi utilizzare Cloud Monitoring anche per misurare le metriche delle prestazioni e l'integrità delle applicazioni dei carichi di lavoro. A seconda della responsabilità operativa del supporto e del monitoraggio delle applicazioni nella tua organizzazione, potresti creare progetti di monitoraggio più granulari per team diversi. Utilizza questi progetti di monitoraggio per visualizzare le metriche delle prestazioni, creare dashboard di integrità delle applicazioni e attivare avvisi quando lo SLO previsto non viene soddisfatto.

Il seguente diagramma mostra una visione generale del modo in cui Cloud Monitoring aggrega le metriche delle prestazioni.

Per indicazioni su come monitorare in modo efficace i carichi di lavoro per affidabilità e disponibilità, consulta il libro Site Reliability Engineering di Google, in particolare il capitolo sul monitoraggio dei sistemi distribuiti.

Soluzione personalizzata per l'analisi automatica dei log

Potresti avere requisiti per creare avvisi per eventi di sicurezza basati su query personalizzate sui log. Le query personalizzate possono contribuire a integrare le funzionalità del tuo SIEM analizzando i log su Google Cloud ed esportando solo gli eventi che meritano un'indagine, soprattutto se non disponi della capacità di esportare tutti i log del cloud nella tua piattaforma SIEM.

Il progetto consente di abilitare questa analisi dei log configurando un'origine centralizzata dei log su cui puoi eseguire query utilizzando un set di dati BigQuery collegato. Per automatizzare questa funzionalità, devi implementare l'esempio di codice in bq-log-alerting ed estendere le funzionalità di base. Il codice campione consente di eseguire regolarmente query su un'origine log e di inviare un risultato personalizzato a Security Command Center.

Il seguente diagramma presenta il flusso ad alto livello dell'analisi automatica dei log.

Il diagramma mostra i seguenti concetti di analisi automatizzata dei log:

• I log di varie origini vengono aggregati in un bucket di log centralizzato con analisi dei log e in un set di dati BigQuery collegato.
• Le viste BigQuery sono configurate per eseguire query sui log per l'evento di sicurezza che vuoi monitorare.
• Cloud Scheduler esegue il push di un evento in un argomento Pub/Sub ogni 15 minuti e attiva Cloud Functions.
• Cloud Functions esegue query sulle viste per verificare la presenza di nuovi eventi. Se trova eventi, li invia a Security Command Center come risultati personalizzati.
• Security Command Center pubblica notifiche sui nuovi risultati in un altro argomento Pub/Sub.
• Uno strumento esterno come SIEM sottoscrive l'argomento Pub/Sub per importare nuovi risultati.

Nell'esempio sono disponibili diversi casi d'uso per eseguire query relative a comportamenti potenzialmente sospetti. Alcuni esempi includono l'accesso da un elenco di super amministratori o altri account con privilegi elevati da te specificati, modifiche alle impostazioni di logging o alle route di rete. Puoi estendere i casi d'uso scrivendo nuove visualizzazioni delle query in base ai tuoi requisiti. Scrivi le tue query o fai riferimento all'analisi dei log di sicurezza per una libreria di query SQL che ti aiutano ad analizzare i log di Google Cloud.

Soluzione personalizzata per rispondere alle modifiche agli asset

Per rispondere agli eventi in tempo reale, ti consigliamo di utilizzare Cloud Asset Inventory per monitorare le modifiche agli asset. In questa soluzione personalizzata, un feed di asset è configurato per attivare in tempo reale notifiche relative a modifiche alle risorse a Pub/Sub, dopodiché Cloud Functions esegue codice personalizzato per applicare la tua logica di business a seconda che la modifica debba essere consentita o meno.

Il progetto include un esempio di questa soluzione di governance personalizzata che monitora le modifiche IAM che aggiungono ruoli altamente sensibili, tra cui Amministratore dell'organizzazione, Proprietario ed Editor. Il diagramma seguente descrive questa soluzione.

Il diagramma precedente mostra i seguenti concetti:

• Vengono apportate modifiche a un criterio di autorizzazione.
• Il feed Cloud Asset Inventory invia a Pub/Sub una notifica in tempo reale sulla modifica del criterio di autorizzazione.
• Pub/Sub attiva una funzione.
• Cloud Functions esegue codice personalizzato per applicare i criteri. La funzione di esempio dispone di una logica per valutare se la modifica ha aggiunto i ruoli Amministratore, Proprietario o Editor dell'organizzazione a un criterio di autorizzazione. In tal caso, la funzione crea un risultato di sicurezza personalizzato e lo invia a Security Command Center.
• Facoltativamente, puoi utilizzare questo modello per automatizzare le attività di correzione. Scrivi una logica di business aggiuntiva in Cloud Functions per intervenire automaticamente sul risultato, ad esempio ripristinare lo stato precedente del criterio di autorizzazione.

Inoltre, puoi estendere l'infrastruttura e la logica utilizzate da questa soluzione di esempio per aggiungere risposte personalizzate ad altri eventi importanti per la tua attività.

Passaggi successivi

• Leggi ulteriori informazioni sui controlli preventivi (documento successivo di questa serie).

Controlli preventivi per le configurazioni accettabili delle risorse

Ti consigliamo di definire vincoli relativi ai criteri che applicano configurazioni accettabili delle risorse e prevengono configurazioni rischiose. Il progetto base utilizza una combinazione di vincoli dei criteri dell'organizzazione e convalida di Infrastructure as Code (IaC) nella tua pipeline. Questi controlli impediscono la creazione di risorse non conformi alle linee guida sui criteri. L'applicazione di questi controlli nelle prime fasi di progettazione e creazione dei carichi di lavoro consente di evitare il lavoro di correzione in un secondo momento.

Vincoli dei criteri dell'organizzazione

Il servizio Criteri dell'organizzazione applica vincoli per garantire che non sia possibile creare determinate configurazioni di risorse nella tua organizzazione Google Cloud, neanche da parte di un utente che dispone di un ruolo IAM sufficientemente con privilegi.

Il progetto applica i criteri a livello di nodo organizzazione in modo che questi controlli vengano ereditati da tutte le cartelle e da tutti i progetti all'interno dell'organizzazione. Questo pacchetto di criteri è progettato per prevenire determinate configurazioni ad alto rischio, come l'esposizione di una VM sulla rete internet pubblica o la concessione dell'accesso pubblico ai bucket di archiviazione, a meno che tu non consenta deliberatamente un'eccezione al criterio.

La seguente tabella introduce i vincoli dei criteri dell'organizzazione implementati nel progetto base:

Vincolo dei criteri dell'organizzazione	Descrizione
compute.disableNestedVirtualization	La virtualizzazione nidificata sulle VM di Compute Engine può eludere il monitoraggio e altri strumenti di sicurezza per le tue VM se sono configurate in modo errato. Questo vincolo impedisce la creazione di una virtualizzazione nidificata.
compute.disableSerialPortAccess	I ruoli IAM come compute.instanceAdmin consentono l'accesso privilegiato alla porta seriale di un'istanza utilizzando le chiavi SSH. Se la chiave SSH viene esposta, un utente malintenzionato potrebbe accedere alla porta seriale e bypassare i controlli di rete e firewall. Questo vincolo impedisce l'accesso alla porta seriale.
compute.disableVpcExternalIpv6	Le subnet IPv6 esterne possono essere esposte ad accessi internet non autorizzati se non sono configurate correttamente. Questo vincolo impedisce la creazione di subnet IPv6 esterne.
compute.requireOsLogin	Il comportamento predefinito dell'impostazione delle chiavi SSH nei metadati può consentire l'accesso remoto non autorizzato alle VM se le chiavi sono esposte. Questo vincolo impone l'utilizzo di OS Login anziché di chiavi SSH basate su metadati.
compute.restrictProtocolForwardingCreationForTypes	L'inoltro del protocollo VM per gli indirizzi IP esterni può causare il traffico in uscita da internet non autorizzato se l'inoltro non è configurato correttamente. Questo vincolo consente l'inoltro del protocollo VM solo per gli indirizzi interni.
compute.restrictXpnProjectLienRemoval	L'eliminazione di un progetto host del VPC condiviso può essere problematica per tutti i progetti di servizio che utilizzano risorse di networking. Questo vincolo impedisce l'eliminazione accidentale o dannosa dei progetti host del VPC condiviso impedendo la rimozione del blocco su questi progetti.
compute.setNewProjectDefaultToZonalDNSOnly	Non è consigliabile utilizzare un'impostazione legacy per il DNS interno globale (a livello di progetto) perché riduce la disponibilità del servizio. Questo vincolo impedisce l'utilizzo dell'impostazione legacy.
compute.skipDefaultNetworkCreation	In ogni nuovo progetto che abilita l'API Compute Engine vengono create una rete VPC predefinita e regole firewall VPC eccessivamente permissive. Questo vincolo ignora la creazione della rete predefinita e delle regole firewall VPC predefinite.
compute.vmExternalIpAccess	Per impostazione predefinita, viene creata una VM con un indirizzo IPv4 esterno che può causare accessi a internet non autorizzati. Questo vincolo configura una lista consentita vuota di indirizzi IP esterni che la VM può utilizzare e nega tutti gli altri.
essentialcontacts.allowedContactDomains	Per impostazione predefinita, i contatti necessari possono essere configurati per inviare notifiche sul tuo dominio a qualsiasi altro dominio. Questo vincolo impone che solo gli indirizzi email nei domini approvati possono essere impostati come destinatari per i contatti necessari.
iam.allowedPolicyMemberDomains	Per impostazione predefinita, i criteri di autorizzazione possono essere concessi a qualsiasi Account Google, inclusi gli account non gestiti e quelli appartenenti a organizzazioni esterne. Questo vincolo assicura che i criteri di autorizzazione nella tua organizzazione possano essere concessi solo agli account gestiti del tuo dominio. Se vuoi, puoi consentire domini aggiuntivi.
iam.automaticIamGrantsForDefaultServiceAccounts	Per impostazione predefinita, agli account di servizio predefiniti vengono concessi automaticamente ruoli eccessivamente permissivi. Questo vincolo impedisce le concessioni automatiche dei ruoli IAM agli account di servizio predefiniti.
iam.disableServiceAccountKeyCreation	Le chiavi degli account di servizio sono credenziali permanenti ad alto rischio e, nella maggior parte dei casi, è possibile utilizzare un'alternativa più sicura alle chiavi degli account di servizio. Questo vincolo impedisce la creazione di chiavi degli account di servizio.
iam.disableServiceAccountKeyUpload	Il caricamento del materiale della chiave dell'account di servizio può aumentare il rischio se il materiale della chiave è esposto. Questo vincolo impedisce il caricamento delle chiavi degli account di servizio.
sql.restrictAuthorizedNetworks	Le istanze Cloud SQL possono essere esposte ad accesso internet non autenticato se sono configurate per utilizzare reti autorizzate senza un proxy di autenticazione Cloud SQL. Questo criterio impedisce la configurazione delle reti autorizzate per l'accesso al database e forza l'utilizzo del proxy di autenticazione Cloud SQL.
sql.restrictPublicIp	Le istanze Cloud SQL possono essere esposte ad accesso a internet non autenticato se vengono create con indirizzi IP pubblici. Questo vincolo impedisce gli indirizzi IP pubblici nelle istanze Cloud SQL.
storage.uniformBucketLevelAccess	Per impostazione predefinita, è possibile accedere agli oggetti in Cloud Storage tramite gli elenchi di controllo dell'accesso (ACL) legacy anziché IAM. Ciò può causare controlli dell'accesso incoerenti ed esposizione accidentale in caso di configurazione errata. L'accesso ACL legacy non è interessato dal vincolo iam.allowedPolicyMemberDomains. Questo vincolo impone che l'accesso possa essere configurato solo tramite l'accesso uniforme a livello di bucket IAM, non tramite ACL legacy.
storage.publicAccessPrevention	I bucket Cloud Storage possono essere esposti ad accesso a internet non autenticato in caso di configurazione errata. Questo vincolo impedisce gli ACL e le autorizzazioni IAM che concedono l'accesso a allUsers e allAuthenticatedUsers.

Questi criteri sono un punto di partenza che consigliamo per la maggior parte dei clienti e della maggior parte degli scenari, ma potrebbe essere necessario modificare i vincoli dei criteri dell'organizzazione per soddisfare determinati tipi di carichi di lavoro. Ad esempio, un carico di lavoro che utilizza un bucket Cloud Storage come backend per l'hosting di risorse pubbliche da parte di Cloud CDN viene bloccato da storage.publicAccessPrevention oppure un'app Cloud Run rivolta al pubblico che non richiede l'autenticazione viene bloccata da iam.allowedPolicyMemberDomains. In questi casi, modifica il criterio dell'organizzazione a livello di cartella o progetto per consentire un'eccezione limitata. Puoi anche aggiungere vincoli ai criteri dell'organizzazione in modo condizionale definendo un tag che conceda un'eccezione o applicazione del criterio e poi applicando il tag a progetti e cartelle.

Per ulteriori vincoli, consulta i vincoli disponibili e i vincoli personalizzati.

Convalida pre-deployment di Infrastructure as Code

Il progetto utilizza un approccio GitOps per gestire l'infrastruttura, il che significa che tutte le modifiche all'infrastruttura vengono implementate tramite Infrastructure as Code (IaC) con controllo della versione e possono essere convalidate prima del deployment.

I criteri applicati nel progetto base definiscono configurazioni di risorse accettabili di cui la pipeline può eseguire il deployment. Se il codice inviato al repository GitHub non supera i controlli dei criteri, non viene eseguito il deployment di alcuna risorsa.

Per informazioni su come vengono utilizzate le pipeline e su come vengono applicati i controlli tramite l'automazione CI/CD, consulta la metodologia di deployment.

Passaggi successivi

• Scopri di più sulla metodologia di deployment (prossimo documento di questa serie)

Metodologia di deployment

Ti consigliamo di utilizzare un'infrastruttura dichiarativa per eseguire il deployment degli elementi di base in modo coerente e controllabile. Questo approccio consente di avere una governance coerente mediante l'applicazione di controlli dei criteri sulle configurazioni di risorse accettabili nelle tue pipeline. Il deployment del progetto base viene eseguito utilizzando un flusso GitOps, con Terraform utilizzata per definire Infrastructure as Code (IaC), un repository Git per il controllo della versione e l'approvazione del codice, e Cloud Build per l'automazione CI/CD nella pipeline di deployment. Per un'introduzione a questo concetto, consulta Gestire l'infrastruttura come codice con Terraform, Cloud Build e GitOps.

Le seguenti sezioni descrivono come la pipeline di deployment viene utilizzata per gestire le risorse nell'organizzazione.

Livelli pipeline

Per separare i team e gli stack tecnologici responsabili della gestione dei diversi livelli dell'ambiente, consigliamo un modello che utilizzi pipeline diverse e utenti tipo diversi responsabili di ogni livello dello stack.

Il seguente diagramma presenta il nostro modello consigliato per separare una pipeline di base, dell'infrastruttura e dell'applicazione.

Il diagramma introduce i livelli della pipeline in questo modello:

• La pipeline di base esegue il deployment delle risorse di base utilizzate su tutta la piattaforma. Consigliamo di utilizzare un unico team centrale per gestire le risorse di base utilizzate da più unità aziendali e carichi di lavoro.
• La pipeline di infrastruttura esegue il deployment di progetti e infrastrutture utilizzati dai carichi di lavoro, come istanze VM o database. Il progetto configura una pipeline di infrastruttura separata per ogni business unit oppure potresti preferire una singola pipeline di infrastruttura utilizzata da più team.
• La pipeline dell'applicazione esegue il deployment degli artefatti per ogni carico di lavoro, ad esempio container o immagini. Potresti avere molti team diversi per le applicazioni con pipeline delle applicazioni individuali.

Le sezioni seguenti introducono l'utilizzo di ciascun livello della pipeline.

La pipeline di base

La pipeline di base esegue il deployment delle risorse di base. Inoltre, configura la pipeline dell'infrastruttura utilizzata per il deployment dell'infrastruttura utilizzata dai carichi di lavoro.

Per creare la pipeline di base, devi prima clonare o creare un fork di terraform-example-foundation nel tuo repository Git. Segui i passaggi nel file README di 0-bootstrap per configurare la cartella e le risorse di bootstrap.

Fase

Descrizione

0-bootstrap

Esegue il bootstrap di un'organizzazione Google Cloud. Questo passaggio configura anche una pipeline CI/CD per il codice del progetto nelle fasi successive. Il progetto CICD contiene la pipeline di base di Cloud Build per il deployment delle risorse. Il progetto seed include i bucket Cloud Storage che contengono lo stato Terraform dell'infrastruttura di base e gli account di servizio con privilegi elevati utilizzati dalla pipeline di base per creare risorse. Lo stato di Terraform è protetto tramite il controllo delle versioni degli oggetti di archiviazione. Durante l'esecuzione della pipeline CI/CD, funge da account di servizio gestiti nel progetto seed.

Dopo aver creato la pipeline di base nella fase 0-bootstrap, le fasi seguenti eseguono il deployment delle risorse sulla pipeline di base. Esamina le istruzioni README per ogni fase e implementa ogni fase in sequenza.

Fase	Descrizione
1-org	Configura cartelle condivise di primo livello, progetti per servizi condivisi, logging a livello di organizzazione e impostazioni di sicurezza di base tramite i criteri dell'organizzazione.
2-environments	Configura gli ambienti di sviluppo, non di produzione e produzione all'interno dell'organizzazione Google Cloud che hai creato.
3-networks-dual-svpc o 3-networks-hub-and-spoke	Configura i VPC condivisi nella topologia scelta e le risorse di rete associate.

La pipeline dell'infrastruttura

La pipeline dell'infrastruttura esegue il deployment dei progetti e dell'infrastruttura (ad esempio, le istanze VM e i database) utilizzati dai carichi di lavoro. La pipeline di base esegue il deployment di pipeline di infrastruttura diverse. Questa separazione tra la pipeline di base e la pipeline dell'infrastruttura consente una separazione tra le risorse a livello di piattaforma e le risorse specifiche per i carichi di lavoro.

Il seguente diagramma descrive in che modo il progetto base configura più pipeline di infrastruttura destinate all'uso da parte di team separati.

Il diagramma descrive i seguenti concetti chiave:

• Ogni pipeline dell'infrastruttura viene utilizzata per gestire le risorse dell'infrastruttura in modo indipendente dalle risorse di base.
• Ogni business unit ha la propria pipeline di infrastruttura, gestita in un progetto dedicato nella cartella common.
• Ogni pipeline dell'infrastruttura ha un account di servizio con l'autorizzazione per eseguire il deployment delle risorse solo nei progetti associati all'unità aziendale. Questa strategia crea una separazione dei compiti tra gli account di servizio con privilegi utilizzati per la pipeline di base e quelli utilizzati da ogni pipeline di infrastruttura

Questo approccio con più pipeline di infrastruttura è consigliato quando all'interno dell'organizzazione sono presenti più entità che hanno le competenze e l'intenzione di gestire la propria infrastruttura separatamente, in particolare se hanno requisiti diversi, come i tipi di criteri di convalida della pipeline che vogliono applicare. In alternativa, potresti preferire una singola pipeline di infrastruttura gestita da un unico team con criteri di convalida coerenti.

In terraform-example-foundation, la fase 4 configura una pipeline dell'infrastruttura, mentre la fase 5 mostra un esempio di utilizzo della pipeline per il deployment delle risorse dell'infrastruttura.

Fase	Descrizione
4-projects	Imposta una struttura di cartelle, progetti e una pipeline dell'infrastruttura.
5-app-infra (facoltativo)	Esegue il deployment dei progetti dei carichi di lavoro con un'istanza Compute Engine utilizzando la pipeline di infrastruttura come esempio.

La pipeline dell'applicazione

La pipeline dell'applicazione è responsabile del deployment degli artefatti delle applicazioni per ogni singolo carico di lavoro, ad esempio immagini o container Kubernetes che eseguono la logica di business dell'applicazione. Il deployment di questi artefatti viene eseguito nelle risorse di infrastruttura di cui è stato eseguito il deployment dalla pipeline dell'infrastruttura.

Il progetto di base aziendale configura la pipeline di base e la pipeline di infrastruttura, ma non esegue il deployment di una pipeline dell'applicazione. Per una pipeline dell'applicazione di esempio, vedi il progetto base dell'applicazione aziendale.

Automazione della pipeline con Cloud Build

Il progetto utilizza Cloud Build per automatizzare i processi CI/CD. La tabella seguente descrive che i controlli sono integrati nella pipeline di base e nella pipeline dell'infrastruttura di cui viene eseguito il deployment dal repository terraform-example-foundation. Se stai sviluppando pipeline utilizzando altri strumenti di automazione CI/CD, ti consigliamo di applicare controlli simili.

Controllo	Descrizione
Separa le configurazioni della build per convalidare il codice prima del deployment	Il progetto utilizza due file di configurazione di compilazione di Cloud Build per l'intera pipeline e ogni repository associato a una fase dispone di due attivatori di Cloud Build associati a questi file di configurazione. Quando il codice viene inviato a un ramo del repository, i file di configurazione di build vengono attivati per la prima esecuzione cloudbuild-tf-plan.yaml, che convalida il codice con i controlli dei criteri e il piano Terraform in base a quel ramo, quindi cloudbuild-tf-apply.yaml esegue terraform apply sul risultato di quel piano.
Controlli dei criteri di Terraform	Il progetto include una serie di vincoli di Open Policy Agent applicati dalla convalida dei criteri in Google Cloud CLI. Questi vincoli definiscono le configurazioni di risorse accettabili di cui la pipeline può eseguire il deployment. Se una build non soddisfa i criteri nella prima configurazione di build, la seconda non esegue il deployment di risorse. I criteri applicati nel progetto vengono creati tramite fork da GoogleCloudPlatform/policy-library su GitHub. Puoi scrivere criteri aggiuntivi per la libreria in modo da applicare criteri personalizzati in modo da soddisfare i tuoi requisiti.
Principio del privilegio minimo	La pipeline di base ha un account di servizio diverso per ogni fase con un criterio di autorizzazione che concede solo i ruoli IAM minimi per quella fase. Ogni trigger di Cloud Build viene eseguito come account di servizio specifico per la fase in questione. L'utilizzo di account diversi aiuta a ridurre il rischio che la modifica di un repository possa influire sulle risorse gestite da un altro repository. Per comprendere i ruoli IAM specifici applicati a ciascun account di servizio, consulta il sa.tf codice Terraform nella fase di bootstrap.
Pool privati di Cloud Build	Il progetto utilizza i pool privati di Cloud Build. I pool privati consentono di applicare facoltativamente controlli aggiuntivi come la limitazione dell'accesso ai repository pubblici o l'esecuzione di Cloud Build all'interno di un perimetro dei Controlli di servizio VPC.
i builder personalizzati di Cloud Build	Il progetto crea il proprio builder personalizzato per eseguire Terraform. Per ulteriori informazioni, vedi 0-bootstrap/Dockerfile. Questo controllo applica l'esecuzione costante della pipeline con un insieme noto di librerie nelle versioni bloccate.
Approvazione del deployment	Se vuoi, puoi aggiungere una fase di approvazione manuale a Cloud Build. Questa approvazione aggiunge un ulteriore checkpoint dopo l'attivazione della build, ma prima dell'esecuzione, in modo che un utente con privilegi possa approvare manualmente la build.

Strategia di diramazione

Consigliamo una strategia di ramo permanente per l'invio del codice al sistema Git e il deployment delle risorse tramite la pipeline di base. Il seguente diagramma descrive la strategia di ramo permanente.

Il diagramma descrive tre rami permanenti in Git (sviluppo, non produzione e produzione) che riflettono gli ambienti Google Cloud corrispondenti. Sono inoltre disponibili più rami di funzionalità temporanee che non corrispondono alle risorse di cui viene eseguito il deployment nei tuoi ambienti Google Cloud.

Ti consigliamo di applicare un processo di richiesta di pull (PR) al tuo sistema Git, in modo che ogni codice unito a un ramo permanente abbia un PR approvato.

Per sviluppare il codice con questa strategia per le filiali permanenti, segui questi passaggi di alto livello:

1. Quando sviluppi nuove funzionalità o lavori a una correzione di bug, crea un nuovo ramo basato sul ramo di sviluppo. Per i ramo utilizza una convenzione di denominazione che includa il tipo di modifica, un numero di ticket o un altro identificatore e una descrizione leggibile, ad esempio feature/123456-org-policies.
2. Quando completi il lavoro nel ramo delle caratteristiche, apri un PR che abbia come target il ramo di sviluppo.
3. Quando invii il PR, quest'ultimo attiva la pipeline di base per eseguire terraform plan e terraform validate per organizzare e verificare le modifiche.
4. Dopo aver convalidato le modifiche al codice, unisci la correzione di funzionalità o bug nel ramo di sviluppo.
5. Il processo di unione attiva l'esecuzione di terraform apply nella pipeline di base per eseguire il deployment delle modifiche più recenti nel ramo di sviluppo nell'ambiente di sviluppo.
6. Esamina le modifiche nell'ambiente di sviluppo utilizzando revisioni manuali, test funzionali o test end-to-end pertinenti al tuo caso d'uso. Poi promuovi le modifiche all'ambiente non di produzione aprendo un PR che abbia come target il ramo non di produzione e unendo le modifiche.
7. Per eseguire il deployment delle risorse nell'ambiente di produzione, ripeti la stessa procedura del passaggio 6: esamina e convalida le risorse di cui è stato eseguito il deployment, apri una PR al ramo di produzione ed esegui l'unione.

Passaggi successivi

• Scopri le best practice per le operazioni (prossimo documento di questa serie).

Best practice per le operazioni

Questa sezione illustra le operazioni che devi considerare quando esegui il deployment e utilizzi carichi di lavoro aggiuntivi nel tuo ambiente Google Cloud. Questa sezione non intende essere esaustiva di tutte le operazioni nel tuo ambiente cloud, ma introduce le decisioni relative ai suggerimenti sull'architettura e alle risorse di cui è stato eseguito il deployment dal progetto.

Aggiorna le risorse di base

Sebbene il progetto base fornisca un punto di partenza adeguato per l'ambiente di base, i requisiti degli elementi di base potrebbero aumentare nel tempo. Dopo il deployment iniziale, potresti regolare le impostazioni di configurazione o creare nuovi servizi condivisi da utilizzare per tutti i carichi di lavoro.

Per modificare le risorse di base, ti consigliamo di apportare tutte le modifiche tramite la pipeline di base. Rivedi la strategia di memorizzazione per un'introduzione al flusso di scrittura del codice, dell'unione e dell'attivazione delle pipeline di deployment.

Decidi gli attributi per i nuovi progetti dei carichi di lavoro

Quando crei nuovi progetti tramite il modulo Progetti di fabbrica della pipeline di automazione, devi configurare vari attributi. Il processo di progettazione e creazione di progetti per nuovi carichi di lavoro deve includere decisioni su quanto segue:

• API Google Cloud da abilitare
• Quale VPC condiviso utilizzare o se creare una nuova rete VPC
• Quali ruoli IAM creare per il project-service-account iniziale creato dalla pipeline
• Etichette del progetto da applicare
• La cartella in cui viene eseguito il deployment del progetto
• Account di fatturazione da utilizzare
• Se aggiungere il progetto a un perimetro dei Controlli di servizio VPC
• Se configurare una soglia di avviso di budget e fatturazione per il progetto

Per un riferimento completo degli attributi configurabili per ogni progetto, consulta le variabili di input per l'azienda del progetto nella pipeline di automazione.

Gestisci le autorizzazioni su larga scala

Quando esegui il deployment di progetti dei carichi di lavoro sulla base degli elementi di base, devi valutare le modalità di concessione dell'accesso agli sviluppatori e ai consumatori previsti per i progetti in questione. Ti consigliamo di aggiungere utenti a un gruppo gestito dal tuo provider di identità esistente, sincronizzare i gruppi con Cloud Identity e applicare i ruoli IAM ai gruppi. Tieni sempre presente il principio del privilegio minimo.

Ti consigliamo inoltre di utilizzare il motore per suggerimenti IAM per identificare i criteri di autorizzazione che concedono ruoli con privilegi in eccesso. Progetta un processo per rivedere periodicamente i suggerimenti o applicarli automaticamente alle pipeline di deployment.

Coordina le modifiche tra il team di networking e il team addetto alle applicazioni

Le topologie di rete di cui viene eseguito il deployment dal progetto presuppongono che tu abbia un team responsabile della gestione delle risorse di rete e team separati responsabili del deployment delle risorse dell'infrastruttura dei carichi di lavoro. Quando i team dei carichi di lavoro eseguono il deployment dell'infrastruttura, devono creare regole firewall per consentire i percorsi di accesso previsti tra i componenti del carico di lavoro, ma non hanno l'autorizzazione per modificare autonomamente i criteri firewall di rete.

Pianifica il modo in cui i team collaboreranno per coordinare le modifiche alle risorse di rete centralizzate necessarie per il deployment delle applicazioni. Ad esempio, potresti progettare un processo in cui un team dedicato ai carichi di lavoro richiede tag per le proprie applicazioni. Il team del networking crea quindi i tag e aggiunge regole al criterio firewall di rete che consente il traffico tra le risorse con i tag e delega i ruoli IAM per l'utilizzo dei tag al team del carico di lavoro.

Ottimizza il tuo ambiente con la gamma Active Assist

Oltre al motore per suggerimenti IAM, Google Cloud offre il portafoglio di servizi Active Assist per fornire suggerimenti su come ottimizzare il tuo ambiente. Ad esempio, gli insight sul firewall o il motore per suggerimenti di progetti automatici forniscono suggerimenti attuabili che possono aiutarti a rafforzare la tua strategia di sicurezza.

Progetta un processo per rivedere periodicamente i suggerimenti o applicarli automaticamente alle pipeline di deployment. Decidi quali suggerimenti devono essere gestiti da un team centrale e quali dovrebbero essere responsabilità dei proprietari dei carichi di lavoro e applica i ruoli IAM per accedere ai suggerimenti di conseguenza.

Concedi eccezioni ai criteri dell'organizzazione

Il progetto prevede una serie di vincoli per i criteri dell'organizzazione consigliati alla maggior parte dei clienti nella maggior parte degli scenari, ma potresti avere casi d'uso legittimi che richiedono eccezioni limitate ai criteri dell'organizzazione che applichi su larga scala.

Ad esempio, il progetto prevede l'applicazione del vincolo iam.disableServiceAccountKeyCreation. Questo vincolo è un importante controllo di sicurezza perché una chiave dell'account di servizio divulgata può avere un impatto negativo significativo e la maggior parte degli scenari dovrebbe utilizzare alternative più sicure alle chiavi degli account di servizio per l'autenticazione. Tuttavia, potrebbero esserci casi d'uso che possono eseguire l'autenticazione solo con una chiave dell'account di servizio, ad esempio un server on-premise che richiede l'accesso ai servizi Google Cloud e che non può utilizzare la federazione delle identità per i carichi di lavoro. In questo scenario, potresti decidere di consentire un'eccezione al criterio, a condizione che vengano applicati controlli di compensazione aggiuntivi come le best practice per la gestione delle chiavi degli account di servizio.

Pertanto, devi progettare un processo per i carichi di lavoro per richiedere un'eccezione alle norme e assicurarti che i responsabili delle decisioni responsabili della concessione delle eccezioni abbiano le conoscenze tecniche necessarie per convalidare il caso d'uso e verificare se sono necessari ulteriori controlli per compensare. Quando concedi un'eccezione a un carico di lavoro, modifica il vincolo del criterio dell'organizzazione nel modo più restrittivo possibile. Puoi anche aggiungere vincoli a un criterio dell'organizzazione in modo condizionale definendo un tag che conceda un'eccezione o un'applicazione forzata del criterio e poi applicando il tag a progetti e cartelle.

Proteggi le tue risorse con i Controlli di servizio VPC

Il progetto base contribuisce a preparare l'ambiente per i Controlli di servizio VPC separando le reti di base da quelle limitate. Tuttavia, per impostazione predefinita, il codice Terraform non abilita i Controlli di servizio VPC perché questa abilitazione può essere un processo di disturbo.

Un perimetro nega l'accesso ai servizi Google Cloud limitati dal traffico che ha origine al di fuori del perimetro, che include la console, le workstation dello sviluppatore e la pipeline di base utilizzata per il deployment delle risorse. Se utilizzi Controlli di servizio VPC, devi progettare eccezioni al perimetro che consentono i percorsi di accesso previsti.

Un perimetro dei Controlli di servizio VPC è destinato ai controlli di esfiltrazione tra l'organizzazione Google Cloud e le origini esterne. Il perimetro non è destinato a sostituire o duplicare i criteri di autorizzazione per un controllo granulare dell'accesso a singoli progetti o risorse. Quando progetti e progetti l'architettura di un perimetro, ti consigliamo di utilizzare un perimetro unificato comune per ridurre i costi di gestione.

Se devi progettare più perimetri per controllare in modo granulare il traffico dei servizi all'interno dell'organizzazione Google Cloud, ti consigliamo di definire chiaramente le minacce che vengono affrontate da una struttura perimetrale più complessa e i percorsi di accesso tra i perimetri necessari per le operazioni previste.

Per adottare i Controlli di servizio VPC, valuta quanto segue:

• Quali dei tuoi casi d'uso richiedono i Controlli di servizio VPC.

• Indica se i servizi Google Cloud richiesti supportano i Controlli di servizio VPC.

• Come configurare l'accesso per i deployment di emergenza per modificare il perimetro in caso di interruzioni delle pipeline di automazione.

• Come utilizzare le best practice per abilitare i Controlli di servizio VPC per progettare e implementare il perimetro.

Dopo l'abilitazione del perimetro, ti consigliamo di progettare un processo per aggiungere in modo coerente nuovi progetti al perimetro corretto e una procedura per progettare eccezioni quando gli sviluppatori hanno un nuovo caso d'uso negato dalla configurazione attuale del perimetro.

Test delle modifiche a livello di organizzazione in un'organizzazione separata

Ti consigliamo di non eseguire mai il deployment delle modifiche in produzione senza test. Per le risorse del carico di lavoro, questo approccio è facilitato da ambienti separati per lo sviluppo, la non produzione e la produzione. Tuttavia, alcune risorse presso l'organizzazione non dispongono di ambienti separati per facilitare i test.

Per modifiche a livello di organizzazione o altre modifiche che possono influire sugli ambienti di produzione, come la configurazione tra il tuo provider di identità e Cloud Identity, valuta la possibilità di creare un'organizzazione separata per i test.

Controlla l'accesso remoto alle macchine virtuali

Poiché consigliamo di eseguire il deployment dell'infrastruttura immutabile tramite la pipeline di base, l'infrastruttura e la pipeline dell'applicazione, ti consigliamo inoltre di concedere agli sviluppatori l'accesso diretto a una macchina virtuale solo tramite SSH o RDP per casi d'uso limitati o eccezionali.

Per scenari che richiedono l'accesso remoto, ti consigliamo di gestire l'accesso degli utenti utilizzando OS Login, ove possibile. Questo approccio utilizza i servizi gestiti di Google Cloud per applicare controllo dell'accesso#39;accesso, la gestione del ciclo di vita degli account, la verifica in due passaggi e l'audit logging. In alternativa, se devi consentire l'accesso tramite le chiavi SSH nei metadati o le credenziali RDP, è tua responsabilità gestire il ciclo di vita delle credenziali e archiviare le credenziali in modo sicuro al di fuori di Google Cloud.

In qualsiasi scenario, un utente con accesso SSH o RDP a una VM può rappresentare un rischio di escalation dei privilegi, per cui ti consigliamo di progettare il tuo modello di accesso tenendo conto di questo aspetto. L'utente può eseguire il codice su quella VM con i privilegi dell'account di servizio associato o eseguire una query sul server dei metadati per visualizzare il token di accesso utilizzato per autenticare le richieste API. Questo accesso può quindi essere un'escalation dei privilegi se non intendevi deliberatamente che l'utente opera con i privilegi dell'account di servizio.

Riduci la spesa eccessiva pianificando gli avvisi relativi al budget

Il progetto implementa le best practice introdotte nel framework dell'architettura Google Cloud: ottimizzazione dei costi per la gestione dei costi, tra cui:

• Utilizza un unico account di fatturazione per tutti i progetti nella piattaforma aziendale.

• Assegna a ogni progetto un'etichetta di metadati billingcode che viene utilizzata per allocare i costi tra i centri di costo.

• Imposta budget e soglie di avviso.

È tua responsabilità pianificare i budget e configurare gli avvisi di fatturazione. Il progetto crea avvisi di budget per i progetti dei carichi di lavoro quando la spesa prevista è in linea con il raggiungimento del 120% del budget. Questo approccio consente a un team centrale di identificare e mitigare i casi di spesa eccessiva significativa. Aumenti significativi e imprevisti delle spese senza una causa chiara possono indicare un incidente di sicurezza e dovrebbero essere analizzati sia dal punto di vista della sicurezza che del controllo dei costi.

A seconda del tuo caso d'uso, puoi impostare un budget basato sul costo di un'intera cartella di ambiente o di tutti i progetti relativi a un determinato centro di costo, anziché impostare budget granulari per ogni progetto. Ti consigliamo inoltre di delegare l'impostazione del budget e degli avvisi ai proprietari dei carichi di lavoro che potrebbero impostare una soglia di avviso più granulare per il monitoraggio giornaliero.

Per indicazioni sulla creazione di funzionalità FinOps, inclusa la previsione dei budget per i carichi di lavoro, consulta Introduzione a FinOps su Google Cloud.

Alloca i costi tra i centri di costo interni

La console ti permette di visualizzare i report di fatturazione per visualizzare e prevedere i costi in più dimensioni. Oltre ai report predefiniti, ti consigliamo di esportare i dati di fatturazione in un set di dati BigQuery nel progetto prj-c-billing-logs. I record di fatturazione esportati consentono di assegnare i costi per le dimensioni personalizzate, ad esempio i centri di costo interni, in base ai metadati delle etichette di progetto come billingcode.

La seguente query SQL è una query di esempio per comprendere i costi di tutti i progetti raggruppati per etichetta billingcode.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

Per configurare questa esportazione, consulta Esportare i dati di fatturazione Cloud in BigQuery.

Se hai bisogno di una contabilità interna o di uno storno di addebito tra centri di costo, è tua responsabilità incorporare i dati ottenuti da questa query nei tuoi processi interni.

Importa i risultati dei controlli di rilevamento nel tuo SIEM esistente

Sebbene le risorse di base consentano di configurare destinazioni aggregate per gli audit log e i risultati sulla sicurezza, è tua responsabilità decidere come consumare e utilizzare questi indicatori.

Se hai bisogno di aggregare i log di tutti gli ambienti cloud e on-premise in un SIEM esistente, decidi come importare i log del progetto prj-c-logging e i risultati di Security Command Center negli strumenti e nei processi esistenti. Potresti creare un'unica esportazione per tutti i log e i risultati se un singolo team è responsabile del monitoraggio della sicurezza nell'intero ambiente oppure puoi creare più esportazioni filtrate in base all'insieme di log e risultati necessari per più team con responsabilità diverse.

In alternativa, se il volume e i costi dei log sono proibitivi, puoi evitare duplicati conservando i log e i risultati di Google Cloud solo in Google Cloud. In questo scenario, assicurati che i team esistenti dispongano dell'accesso e della formazione giusti per lavorare con i log e i risultati direttamente in Google Cloud.

• Per gli audit log, progetta visualizzazioni log in modo da concedere ai singoli team l'accesso a un sottoinsieme di log del bucket di log centralizzato, invece di duplicarlo in più bucket, aumentando così i costi di archiviazione dei log.
• Per i risultati sulla sicurezza, concedi ruoli a livello di cartella e progetto per Security Command Center per consentire ai team di visualizzare e gestire i risultati sulla sicurezza solo per i progetti di cui sono responsabili, direttamente nella console.

Sviluppa continuamente la libreria di controlli

Il progetto inizia con una base di controlli per rilevare e prevenire le minacce. Ti consigliamo di rivedere questi controlli e aggiungere altri controlli in base ai tuoi requisiti. La seguente tabella riassume i meccanismi per applicare i criteri di governance e come estenderli per requisiti aggiuntivi:

Controlli dei criteri applicati dal progetto	Guida per estendere questi controlli
Security Command Center rileva vulnerabilità e minacce da più origini di sicurezza.	Definire moduli personalizzati per Security Health Analytics e moduli personalizzati per Event Threat Detection.
Il servizio Criteri dell'organizzazione applica un insieme consigliato di vincoli dei criteri dell'organizzazione per i servizi Google Cloud.	Forza l'applicazione di vincoli aggiuntivi dall'elenco predefinito dei vincoli disponibili o crea vincoli personalizzati.
Il criterio aperto di Policy Agent (OPA) convalida il codice nella pipeline di base per le configurazioni accettabili prima del deployment.	Sviluppa vincoli aggiuntivi in base alle indicazioni fornite in GoogleCloudPlatform/policy-library.
Gli avvisi sulle metriche basate su log e sulle metriche delle prestazioni configurano le metriche basate su log per segnalare le modifiche ai criteri e alle configurazioni IAM di alcune risorse sensibili.	Progetta metriche e criteri di avviso aggiuntivi basati su log per gli eventi dei log che prevedi non debbano verificarsi nel tuo ambiente.
Una soluzione personalizzata per l'analisi automatica dei log esegue regolarmente query sui log per individuare attività sospette e crea risultati di Security Command Center.	Scrivi query aggiuntive per creare risultati per gli eventi di sicurezza che vuoi monitorare, utilizzando l'analisi dei log di sicurezza come riferimento.
Una soluzione personalizzata per rispondere alle modifiche agli asset crea risultati di Security Command Center e può automatizzare le azioni di correzione.	Creare altri feed Cloud Asset Inventory per monitorare le modifiche per determinati tipi di asset e scrivere funzioni Cloud Functions aggiuntive con logica personalizzata per rispondere alle violazioni dei criteri.

Questi controlli possono evolversi con l'evoluzione dei requisiti e della maturità su Google Cloud.

Gestisci le chiavi di crittografia con Cloud Key Management Service

Google Cloud offre crittografia at-rest predefinita per tutti i contenuti dei clienti, ma offre anche Cloud Key Management Service (Cloud KMS) per offrirti un controllo aggiuntivo sulle chiavi di crittografia per i dati at-rest. Ti consigliamo di valutare se la crittografia predefinita è sufficiente o se hai un requisito di conformità che prevede l'uso di Cloud KMS per gestire le chiavi autonomamente. Per saperne di più, consulta Decidere come soddisfare i requisiti di conformità per la crittografia at-rest.

Il progetto fornisce un progetto prj-c-kms nella cartella comune e un progetto prj-{env}-kms in ogni cartella di ambiente per la gestione centralizzata delle chiavi di crittografia. Questo approccio consente a un team centrale di controllare e gestire le chiavi di crittografia utilizzate dalle risorse nei progetti dei carichi di lavoro per soddisfare i requisiti normativi e di conformità.

A seconda del tuo modello operativo, preferisci un'unica istanza di progetto centralizzata di Cloud KMS sotto il controllo di un singolo team, potresti preferire gestire le chiavi di crittografia separatamente in ogni ambiente oppure più istanze distribuite, in modo che la responsabilità delle chiavi di crittografia possa essere delegata ai team appropriati. Modifica l'esempio di codice Terraform in base alle esigenze del tuo modello operativo.

Facoltativamente, puoi applicare i criteri dell'organizzazione relativi alle chiavi di crittografia gestite dal cliente (CMEK) per fare in modo che determinati tipi di risorse richiedano sempre una chiave CMEK e che possano essere utilizzate solo le chiavi CMEK di una lista consentita di progetti attendibili.

Archivia e verifica le credenziali delle applicazioni con Secret Manager

Ti consigliamo di non eseguire mai il commit di secret sensibili (come chiavi API, password e certificati privati) nei repository di codice sorgente. Esegui invece il commit del secret in Secret Manager e concedi il ruolo IAM Accessore ai secret di Secret Manager all'account utente o di servizio che deve accedere al secret. Ti consigliamo di concedere il ruolo IAM a un singolo secret, non a tutti i secret del progetto.

Quando possibile, devi generare automaticamente secret di produzione all'interno delle pipeline CI/CD e mantenerli inaccessibili agli utenti umani, tranne in situazioni di deployment di emergenza. In questo scenario, assicurati di non concedere ruoli IAM per visualizzare questi secret a utenti o gruppi.

Il progetto fornisce un singolo progetto prj-c-secrets nella cartella comune e un progetto prj-{env}-secrets in ogni cartella di ambiente per la gestione centralizzata dei secret. Questo approccio consente a un team centrale di controllare e gestire i secret utilizzati dalle applicazioni al fine di soddisfare i requisiti normativi e di conformità.

A seconda del tuo modello operativo, potresti preferire un'unica istanza centralizzata di Secret Manager sotto il controllo di un singolo team oppure gestire i secret separatamente in ogni ambiente oppure preferire più istanze distribuite di Secret Manager, in modo che ogni team dei carichi di lavoro possa gestire i propri secret. Modifica l'esempio di codice Terraform in base alle esigenze del tuo modello operativo.

Pianifica l'accesso per deployment di emergenza agli account con privilegi elevati

Anche se consigliamo di gestire le modifiche alle risorse di base tramite IaC con controllo della versione di cui viene eseguito il deployment dalla pipeline di base, potresti avere scenari di emergenza o eccezionali che richiedono l'accesso con privilegi per modificare direttamente il tuo ambiente. Ti consigliamo di pianificare account per deployment di emergenza (a volte chiamati account Firecall o account di emergenza) con accesso altamente privilegiato al tuo ambiente in caso di emergenza o quando i processi di automazione si interrompono.

La tabella seguente descrive alcuni scopi esemplificativi degli account per deployment di emergenza.

Scopo del deployment di emergenza	Descrizione
Super amministratore	Accesso di emergenza al ruolo Super amministratore utilizzato con Cloud Identity, ad esempio per risolvere problemi relativi alla federazione delle identità o all'autenticazione a più fattori (MFA).
Amministratore dell'organizzazione	Accesso di emergenza al ruolo Amministratore dell'organizzazione, che può quindi concedere l'accesso a qualsiasi altro ruolo IAM nell'organizzazione.
Amministratore pipeline di base	Accesso di emergenza per modificare le risorse nel progetto CICD su Google Cloud e nel repository Git esterno in caso di interruzione dell'automazione della pipeline di base.
Operations o SRE	Un team Operations o SRE ha bisogno di un accesso privilegiato per rispondere a interruzioni o incidenti. Possono essere incluse attività come il riavvio delle VM o il ripristino dei dati.

Il meccanismo che consente l'accesso del deployment di emergenza dipende dagli strumenti e dalle procedure esistenti, ma alcuni esempi includono:

• Usa gli strumenti esistenti per la gestione degli accessi con privilegi per aggiungere temporaneamente un utente a un gruppo predefinito con ruoli IAM con privilegi elevati o utilizza le credenziali di un account con privilegi elevati.
• Esegui il pre-provisioning degli account destinati esclusivamente all'utilizzo da parte degli amministratori. Ad esempio, la sviluppatrice Dana potrebbe avere un'identità [email protected] per l'uso quotidiano e [email protected] per l'accesso al deployment di emergenza.
• Utilizza un'applicazione, come l'accesso con privilegi just-in-time, che consente a uno sviluppatore di eseguire l'escalation autonomamente a ruoli con più privilegi.

Indipendentemente dal meccanismo utilizzato, valuta come rispondere operativamente alle seguenti domande:

• Come progettate l'ambito e la granularità dell'accesso del deployment di emergenza? Ad esempio, potresti progettare un meccanismo di deployment di emergenza diverso per unità aziendali diverse per assicurarti che non possano interferire a vicenda.
• In che modo il meccanismo impedisce gli abusi? Hai bisogno di approvazioni? Ad esempio, potresti avere operazioni di suddivisione in cui una persona detiene le credenziali e una persona detiene il token MFA.
• In che modo controlli e avvisi relativi all'accesso del deployment di emergenza? Ad esempio, potresti configurare un modulo Event Threat Detection personalizzato per creare un risultato di sicurezza quando viene utilizzato un account di deployment di emergenza predefinito.
• Come rimuovere l'accesso del deployment di emergenza e riprendere le normali operazioni al termine dell'incidente?

Per le attività comuni di escalation dei privilegi e rollback delle modifiche, consigliamo di progettare flussi di lavoro automatizzati in cui un utente può eseguire le operazioni senza richiedere l'escalation dei privilegi per la propria identità utente. Questo approccio può contribuire a ridurre gli errori umani e a migliorare la sicurezza.

Per i sistemi che richiedono interventi regolari, automatizzare la correzione potrebbe essere la soluzione migliore. Google incoraggia i clienti ad adottare un approccio di produzione zero-touch per apportare tutte le modifiche alla produzione utilizzando l'automazione, i proxy sicuri o il deployment di emergenza controllato. Google fornisce i libri SRE ai clienti che vogliono adottare l'approccio SRE di Google.

Passaggi successivi

• Leggi Eseguire il deployment del progetto (documento successivo di questa serie).

esegui il deployment del progetto base

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: 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. Applicare le best practice per la sicurezza per gli account amministratore. Verificare e riconciliare i problemi relativi agli account utente consumer. Configura il tuo provider di identità esterno come fonte attendibile per la sincronizzazione degli account utente e del servizio SSO. Esegui il provisioning dei gruppi per il controllo dell'accesso necessari per eseguire il progetto base. 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. Scegli gli strumenti di automazione CI/CD. terraform-example-foundation offre diversi insiemi di indicazioni 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 di intervalli richiesti dal progetto base. Ordina le tue connessioni Dedicated Interconnect.
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: 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 con la fase successiva. Fase 1-org per configurare le risorse a livello di organizzazione. Fase 2-environments per creare ambienti. Esegui la fase 3-networks-dual-svpc or 3-networks-hub-and-spoke per creare risorse di networking nella topologia che preferisci. Fase 4-projects per creare una pipeline dell'infrastruttura. (Facoltativo) Fase 5-app-infra per l'utilizzo di esempio della pipeline dell'infrastruttura.
Passaggi aggiuntivi dopo il deployment di IaC	Dopo aver eseguito il deployment del codice Terraform, completa quanto segue: Completa le modifiche alla configurazione on-premise. Attiva Security Command Center Premium. Esporta i dati di fatturazione Cloud in BigQuery. Registrati per un piano di assistenza clienti Google Cloud. Abilita i log di Access Transparency. Condividere dati da Cloud Identity con Google Cloud. Applica i controlli amministrativi per Cloud Identity che non sono automatizzati dal deployment di IaC. Valuta quali controlli amministrativi aggiuntivi per i clienti con carichi di lavoro sensibili sono appropriati per il tuo caso d'uso. Consulta le best practice per le operazioni e pianifica come connettere le operazioni e le funzionalità esistenti alle risorse di base.

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: [email protected]
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: [email protected]
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

• Implementa il progetto base utilizzando la base di esempio Terraform su GitHub.
• Scopri di più sui principi di progettazione delle best practice con il framework dell'architettura Google Cloud.

• Esamina la libreria dei progetti per accelerare la progettazione e la creazione di carichi di lavoro aziendali comuni, tra cui:

  • Importa i dati da Google Cloud in un data warehouse BigQuery protetto

  • Importa i dati da una rete esterna in un data warehouse BigQuery protetto

  • Esegui il deployment di un'architettura serverless protetta con Cloud Functions

  • Esegui il deployment di un'architettura serverless protetta con Cloud Run

• Consulta le soluzioni correlate per il deployment nel tuo ambiente di base.

• Per accedere a un ambiente dimostrativo, contattaci all'indirizzo [email protected].