Networking per l'accesso sicuro all'interno del cloud: architetture di riferimento

Last reviewed 2025-01-13 UTC

Questo documento fa parte di una serie che descrive le architetture di rete e di sicurezza per le aziende che eseguono la migrazione dei carichi di lavoro dei data center aGoogle Cloud.

La serie è composta dai seguenti documenti:

I carichi di lavoro per i casi d'uso intra-cloud si trovano nelle reti VPC e devono connettersi a altre risorse in Google Cloud. Potrebbero utilizzare servizi forniti in modo nativo nel cloud, come BigQuery. Il perimetro di sicurezza è fornito da una serie di funzionalità proprietarie (proprietari) e di terze parti (terze parti), come firewall, Controlli di servizio VPC e appliance virtuali di rete.

In molti casi, questi carichi di lavoro si estendono su più Google Cloud reti VPC e i confini tra le reti VPC devono essere protetti. Questo documento illustra in dettaglio queste architetture di sicurezza e connettività.

Architettura lift and shift

Il primo scenario per un caso d'uso intra-cloud è un'architettura di tipo lift-and-shift in cui sposti i carichi di lavoro consolidati nel cloud così come sono.

Cloud NGFW

Puoi contribuire a stabilire un perimetro sicuro configurando Cloud Next Generation Firewall. Puoi utilizzare i tag, gli account di servizio e i tag di rete per applicare regole firewall granulari alle VM. Per le linee guida sull'implementazione su come gestire il traffico con le regole firewall, consulta Criteri firewall di rete nel blueprint Enterprise Foundations. Google Cloud

Puoi anche utilizzare il logging delle regole firewall per controllare e verificare gli effetti dell'impostazione della regola firewall.

Puoi utilizzare i log di flusso VPC per l'analisi forense della rete e anche trasmettere i log in streaming per integrarli con il SIEM. Questo sistema complessivo può fornire monitoraggio in tempo reale, correlazione di eventi, analisi e avvisi di sicurezza.

La Figura 1 mostra come le regole del firewall possono utilizzare i tag di rete per contribuire a limitare il traffico tra le VM in una rete VPC.

Configurazione del firewall di rete che utilizza i tag di rete per applicare un controllo granulare in uscita.

Figura 1. Configurazione del firewall di rete che utilizza i tag di rete per applicare un controllo granulare in uscita.

Appliance virtuale di rete

Un'appliance virtuale di rete (NVA) è una VM con funzioni di sicurezza come i firewall per applicazioni web (WAF) o i firewall a livello di applicazione di sicurezza. Le NVA con più interfacce di rete possono essere utilizzate per creare un bridge tra le reti VPC. Puoi utilizzare le NVA per implementare il traffico delle funzioni di sicurezza tra le reti VPC, soprattutto quando utilizzi una configurazione hub-spoke, come mostrato nella figura 2.

Configurazione centralizzata delle appliance di rete in una rete VPC condiviso.

Figura 2. Configurazione centralizzata delle appliance di rete in una rete VPC condiviso.

Cloud IDS

Cloud IDS (Cloud Intrusion Detection System) ti consente di implementare il logging e il controllo di sicurezza nativi eseguendo il mirroring del traffico da una subnet nella tua rete VPC. Con Cloud IDS puoi ispezionare e monitorare un'ampia gamma di minacce a livello di rete e di applicazione per sottoporle ad analisi. Crea endpoint Cloud IDS nella tua Google Cloud rete VPC. Questi endpoint monitorano il traffico in entrata e in uscita verso e da questa rete, nonché il traffico all'interno della rete VPC, utilizzando la funzionalità di mirroring dei pacchetti integrata nello Google Cloud stack di rete. Devi attivare l'accesso privato ai servizi per connetterti al progetto del producer di servizi (il progetto gestito da Google) che ospita le procedure di Cloud IDS.

Se hai un'architettura hub and spoke, il traffico di ogni spoke può essere sottoposto a mirroring nelle istanze Cloud IDS, come mostrato nella figura 3.

Configurazione di Cloud IDS per eseguire il mirroring del traffico VPC che utilizza l'accesso ai servizi privati.

Figura 3. Configurazione di Cloud IDS per eseguire il mirroring del traffico VPC che utilizza l'accesso ai servizi privati.

Cloud IDS può essere protetto nel perimetro di servizio VPC Service Controls tramite un passaggio aggiuntivo. Puoi scoprire di più sul supporto dei Controlli di servizio VPC nei prodotti supportati.

Network Connectivity Center

Network Connectivity Center è un framework di orchestrazione che semplifica la connettività di rete tra le risorse collegate a una risorsa di gestione centrale chiamata hub. Network Connectivity Center supporta i seguenti tipi di reti:

  • Google Cloud Reti VPC
  • Reti on-premise e di altri cloud che utilizzano Cloud Interconnect o VPN ad alta disponibilità
  • Connessioni criptate ancorate da VM

Network Connectivity Center è il control plane dell'architettura. Le connessioni alle reti sono chiamate raggi. Puoi utilizzare Network Connectivity Center per connettere le reti in una topologia full mesh o hub and spoke.

Peering di rete VPC

Per le applicazioni che si estendono su più reti VPC, che appartengano allo stesso Google Cloud progetto o alla stessa risorsa dell'organizzazione, il peering delle reti VPC consente la connettività tra le reti VPC. Questa connettività consente al traffico di rimanere all'interno della rete di Google, in modo che non attraversi la rete internet pubblica.

Un'architettura hub and spoke è un modello molto utilizzato per la connettività VPC. Questo modello è utile quando un'azienda ha varie applicazioni che devono accedere a un insieme comune di servizi, come la registrazione o l'autenticazione. Il modello è utile anche se l'azienda deve implementare un insieme comune di criteri di sicurezza per il traffico che esce dalla rete tramite l'hub. Per indicazioni sulla configurazione di un'architettura hub-and-spoke utilizzando il peering di rete VPC, consulta Connettività inter-VPC di rete cross-cloud utilizzando il peering di rete VPC.

VPC condiviso

Puoi utilizzare un VPC condiviso per mantenere il controllo centralizzato sulle risorse di rete come subnet, route e firewall nei progetti host. Questo livello di controllo ti consente di implementare la best practice di sicurezza del privilegio minimo per l'amministrazione, l'auditing e il controllo degli accessi della rete perché puoi delegare le attività di amministrazione della rete agli amministratori di rete e di sicurezza. Puoi assegnare la possibilità di creare e gestire VM agli amministratori delle istanze utilizzando i progetti di servizio. L'utilizzo di un progetto di servizio garantisce che agli amministratori delle VM venga concessa solo la possibilità di creare e gestire le istanze e che non possano apportare modifiche che influiscono sulla rete nella rete VPC condivisa.

Ad esempio, puoi fornire un maggiore isolamento definendo due reti VPC in due progetti host e collegando più progetti di servizio a ogni rete, uno per la produzione e uno per i test. La Figura 6 mostra un'architettura che isola un ambiente di produzione da un ambiente di test utilizzando progetti separati.

Per ulteriori informazioni sulle best practice per la creazione di reti VPC, consulta Best practice e architetture di riferimento per la progettazione di VPC.

Configurazione della rete VPC condiviso che utilizza più host e progetti di servizio isolati (ambienti di test e di produzione).

Figura 6. Configurazione della rete VPC condiviso che utilizza più host e progetti di servizio isolati (ambienti di test e di produzione).

Architettura di servizi ibridi

L'architettura dei servizi ibridi fornisce servizi cloud-native aggiuntivi che sono progettati per consentirti di connettere e proteggere i servizi in un ambiente multi-VPC. Questi servizi cloud-native completano ciò che è disponibile nell'architettura di lift and shift e possono semplificare la gestione di un ambiente segmentato in VPC su larga scala.

Private Service Connect

Private Service Connect consente di mostrare un servizio ospitato in una rete VPC in un'altra rete VPC. Non è necessario che i servizi siano ospitati dalla stessa risorsa dell'organizzazione, pertanto Private Service Connect può essere utilizzato per utilizzare privatamente i servizi di un'altra rete VPC, anche se è collegata a un'altra risorsa dell'organizzazione.

Puoi utilizzare Private Service Connect in due modi: per accedere alle API di Google o per accedere ai servizi ospitati in altre reti VPC.

Utilizzare Private Service Connect per accedere alle API di Google

Quando utilizzi Private Service Connect, puoi esporre le API di Google utilizzando un endpoint Private Service Connect che fa parte della tua rete VPC, come mostrato nella figura 7.

Configurazione di Private Service Connect per inviare traffico alle API di Google utilizzando un endpoint Private Service Connect privato per la tua rete VPC.

Figura 7. Configurazione di Private Service Connect per inviare traffico alle API di Google utilizzando un endpoint Private Service Connect privato per la tua rete VPC.

I carichi di lavoro possono inviare traffico a un bundle di API di Google globali utilizzando un endpoint Private Service Connect. Inoltre, puoi utilizzare un backend di Private Service Connect per accedere a una singola API di Google, estendendo le funzionalità di sicurezza dei bilanciatori del carico ai servizi API. La Figura 8 mostra questa configurazione.

Configurazione di Private Service Connect per inviare il traffico alle API di Google utilizzando un backend di Private Service Connect.

Figura 8. Configurazione di Private Service Connect per inviare traffico alle API di Google utilizzando un backend di Private Service Connect.

Utilizzare Private Service Connect tra entità o reti VPC

Private Service Connect consente inoltre a un produttore di servizi di offrire servizi a un consumatore di servizi in un'altra rete VPC, nella stessa risorsa dell'organizzazione o in un'altra. La rete VPC di un producer di servizi può supportare più consumer di servizi. Il consumer può connettersi al servizio del producer inviando traffico a un endpoint Private Service Connect situato nella rete VPC del consumer. L'endpoint inoltra il traffico alla rete VPC contenente il servizio pubblicato.

Configurazione di Private Service Connect per pubblicare
e utilizzare i servizi gestiti tramite un endpoint.

Figura 9. Configurazione di Private Service Connect per pubblicare un servizio gestito tramite un collegamento al servizio e utilizzarlo tramite un endpoint.

Accesso privato ai servizi

Private Service Connect è il modo consigliato per un producer di servizi per fornire un servizio a un consumer di servizi. Tuttavia, Private Service Connect non supporta tutti i servizi. Puoi utilizzare l'accesso ai servizi privati per accedere a questi servizi elencati.

Connettore di accesso VPC serverless

Un connettore di accesso VPC serverless gestisce il traffico tra l'ambiente serverless e la rete VPC. Quando crei un connettore nel tuo progetto Google Cloud, lo colleghi a una rete VPC e a una regione specifiche. Puoi quindi configurare i tuoi servizi serverless in modo che utilizzino il connettore per il traffico di rete in uscita. Puoi specificare un connettore utilizzando una subnet o un intervallo CIDR. Il traffico inviato tramite il connettore nella rete VPC proviene dalla subnet o dall'intervallo CIDR specificato, come mostrato nella figura 10.

Configurazione del connettore di accesso VPC serverless per accedere agli ambienti serverless Google Cloud utilizzando indirizzi IP interni all'interno della rete VPC.

Figura 10. Configurazione del connettore di accesso VPC serverless per accedere agli Google Cloud ambienti serverless utilizzando indirizzi IP interni all'interno della rete VPC.

I connettori di accesso VPC serverless sono supportati in ogni regione che supporta Cloud Run, le funzioni Cloud Run o l'ambiente standard App Engine. Per ulteriori informazioni, consulta l'elenco dei servizi supportati e protocolli di rete supportati per l'utilizzo del connettore di accesso VPC serverless.

VPC diretto in uscita

L'uscita VPC diretta consente al servizio Cloud Run di inviare traffico a una rete VPC senza configurare un connettore di accesso VPC serverless.

Controlli di servizio VPC

Controlli di servizio VPC ti aiutano a impedire l'esfiltrazione di dati da servizi come Cloud Storage o BigQuery impedendo gli accessi autorizzati da internet o da progetti che non fanno parte di un perimetro di sicurezza. Ad esempio, immagina uno scenario in cui un errore umano o un'automazione errata causano l'impostazione errata dei criteri IAM su un servizio come Cloud Storage o BigQuery. Di conseguenza, le risorse di questi servizi diventano accessibili pubblicamente. In questo caso, esiste il rischio di esposizione dei dati. Se hai configurato questi servizi all'interno del perimetro di Controlli di servizio VPC, l'accesso in entrata alle risorse è bloccato, anche se i criteri IAM lo consentono.

Controlli di servizio VPC può creare perimetri in base ad attributi del client come tipo di identità (account di servizio o utente) e origine della rete (indirizzo IP o rete VPC).

I Controlli di servizio VPC contribuiscono a mitigare i seguenti rischi per la sicurezza:

  • Accesso da reti non autorizzate che utilizzano credenziali rubate.
  • Esfiltrazione di dati da parte di utenti interni malintenzionati o codice compromesso.
  • Esposizione pubblica di dati privati causata da criteri IAM configurati in modo errato.

La Figura 11 mostra come i Controlli di servizio VPC ti consentono di stabilire un perimetro di servizio per contribuire a mitigare questi rischi.

Perimetro di servizio VPC esteso agli ambienti ibridi tramite l'utilizzo di servizi di accesso privato.

Figura 11. Perimetro di servizio VPC esteso agli ambienti ibridi tramite l'utilizzo di servizi di accesso privato.

Utilizzando le regole di ingresso e di uscita, puoi attivare la comunicazione tra due perimetri di servizio, come mostrato nella figura 12.

Configurazione di regole di ingresso e uscita per la comunicazione tra i perimetri di servizio.

Figura 12. Configurazione di regole di ingresso e uscita per la comunicazione tra i perimetri di servizio.

Per consigli dettagliati sulle architetture di deployment dei Controlli di servizio VPC, consulta Progettare e progettare perimetri di servizio. Per ulteriori informazioni sull'elenco dei servizi supportati dai Controlli di servizio VPC, consulta Prodotti supportati e limitazioni.

Architettura distribuita Zero Trust

I controlli di sicurezza del perimetro della rete sono necessari, ma non sufficienti per supportare i principi di sicurezza del privilegio minimo e della difesa in profondità. Le architetture distribuite Zero Trust si basano sul perimetro della rete, ma non si basano esclusivamente su questo per l'applicazione della sicurezza. In quanto architetture distribuite, sono composte da microservizi con applicazione per servizio dei criteri di sicurezza, autenticazione avanzata e identità del carico di lavoro.

Puoi implementare architetture distribuite Zero Trust come servizi gestiti da Cloud Service Mesh.

Cloud Service Mesh

Cloud Service Mesh fornisce un mesh di microservizi diarchitettura distribuita Zero Trust plug-and-play basato sulle fondamenta di Istio. La configurazione della mesh avviene utilizzando un flusso integrato. Cloud Service Mesh gestito, con piani di controllo e di dati gestiti da Google, è supportato su GKE. È disponibile anche un piano di controllo all'interno del cluster che è adatto per altri ambienti come Google Distributed Cloud o GKE Multi-Cloud. Cloud Service Mesh gestisce l'identità e i certificati per te, fornendo un modello di criteri di autorizzazione basato su Istio.

Cloud Service Mesh si basa su parchi risorse per gestire la configurazione e l'identità del deployment di servizi multi-cluster. Come per Cloud Service Mesh, quando i carichi di lavoro operano in un ambiente di connettività di rete VPC piatto (o condiviso), non sono previsti requisiti speciali per la connettività di rete oltre alla configurazione del firewall. Quando l'architettura include più cluster Cloud Service Mesh in reti VPC o ambienti di rete separati, ad esempio tramite una connessione Cloud Interconnect, è necessario anche un gateway east-west. Le best practice per il networking di Cloud Service Mesh sono le stesse descritte in Best practice per il networking di GKE.

Cloud Service Mesh si integra anche con Identity-Aware Proxy (IAP). IAP ti consente di impostare criteri di accesso granulari in modo da controllare l'accesso degli utenti a un carico di lavoro in base agli attributi della richiesta di origine, come l'identità utente, l'indirizzo IP e il tipo di dispositivo. Questo livello di controllo consente un ambiente end-to-end zero trust.

Quando utilizzi Cloud Service Mesh, devi prendere in considerazione i requisiti del cluster GKE. Per saperne di più, consulta la sezione Requisiti della documentazione "Installazione di un singolo progetto su GKE".

Passaggi successivi