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 a Google Cloud.
La serie è composta dai seguenti documenti:
- Progettazione di reti per la migrazione dei carichi di lavoro aziendali: approcci architetturali
- Networking per l'accesso intra-cloud sicuro: architetture di riferimento (questo documento)
- Networking per la distribuzione di applicazioni con accesso a internet: architetture di riferimento
- Networking per carichi di lavoro ibridi e multi-cloud: architetture di riferimento
I carichi di lavoro per i casi d'uso intra-cloud risiedono nelle reti VPC e devono connettersi ad 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à di prima parte (1P) e di terze parti (3P), 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 lift and shift in cui sposti i carichi di lavoro esistenti nel cloud così come sono.
Cloud NGFW
Puoi contribuire a stabilire un perimetro sicuro configurando Cloud Next Generation Firewall. Puoi utilizzare tag, service account e tag di rete per applicare regole firewall granulari alle VM. Per le linee guida sull'implementazione relative alla gestione del traffico con le regole firewall, consulta Policy firewall di rete nel progetto di base aziendale. Google Cloud
Puoi anche utilizzare il logging delle policy del firewall per controllare e verificare gli effetti dell'impostazione delle regole firewall.
Puoi utilizzare i log di flusso VPC per l'analisi forense della rete e anche trasmettere i log in streaming per l'integrazione con SIEM. Questo sistema complessivo può fornire monitoraggio in tempo reale, correlazione degli eventi, analisi e avvisi di sicurezza.
La Figura 1 mostra come le regole firewall possono utilizzare i tag di rete per limitare il traffico tra le VM in una rete VPC.
Figura 1. Configurazione del firewall di rete che utilizza i tag di rete per applicare un controllo in uscita granulare.
Appliance virtuale di rete
Un'appliance virtuale di rete (NVA) è una VM che dispone di funzioni di sicurezza come firewall per applicazioni web (WAF) o 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 and spoke, come mostrato nella Figura 2.
Figura 2. Configurazione centralizzata dell'appliance di rete in una rete VPC condiviso.
Cloud IDS
Cloud Intrusion Detection System (Cloud IDS) consente di implementare l'ispezione e il logging della sicurezza nativa mediante il mirroring del traffico da una subnet nella rete VPC. Utilizzando Cloud IDS, puoi ispezionare e monitorare un'ampia varietà di minacce a livello di rete e a livello di applicazione per l'analisi. Crea endpoint Cloud IDS nella tua rete Google Cloud VPC. Questi endpoint monitorano il traffico in entrata e in uscita da e verso la rete, nonché il traffio di rete intra-VPC, utilizzando la funzionalità di mirroring dei pacchetti integrata nello stack di rete. Google Cloud Devi abilitare l'accesso privato ai servizi per connetterti al progetto del producer di servizi (il progetto gestito da Google) che ospita i processi Cloud IDS.
Se hai un'architettura hub and spoke, il traffico di ciascuno degli spoke può essere sottoposto a mirroring alle istanze Cloud IDS, come mostrato nella Figura 3.
Figura 3. Configurazione di Cloud IDS per il mirroring del traffico VPC che utilizza l'accesso privato ai servizi.
Cloud IDS può essere protetto nel perimetro di servizio Controlli di servizio VPC utilizzando un passaggio aggiuntivo. Puoi scoprire di più sul supporto di Controlli di servizio VPC in prodotti supportati.
Network Connectivity Center
Network Connectivity Center è un framework di orchestrazione che semplifica la connettività di rete tra le risorse connesse a una risorsa di gestione centrale chiamata hub. NCC 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à affidabilità
- Connessioni criptate ancorate alle VM
Network Connectivity Center è il control plane dell'architettura. Le connessioni alle reti sono chiamate spoke. 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, indipendentemente dal fatto che appartengano allo stesso Google Cloud progetto o alla stessa risorsa organizzazione, il peering di rete 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 diffuso per la connettività VPC. Questo modello è utile quando un'azienda dispone di varie applicazioni che devono accedere a un insieme comune di servizi, come logging o autenticazione. Il modello è utile anche se l'azienda deve implementare un insieme comune di policy di sicurezza per il traffico in uscita 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 Cross-Cloud Network 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 consente di implementare la best practice di sicurezza del privilegio minimo per l'amministrazione, l'auditing e controllo dell'accesso 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 le VM agli amministratori delle istanze utilizzando i progetti di servizio. L'utilizzo di un progetto di servizio garantisce che gli amministratori delle VM abbiano solo la possibilità di creare e gestire le istanze e che non siano autorizzati ad apportare modifiche che influiscono sulla rete nella rete VPC condiviso.
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 saperne di più sulle best practice per la creazione di reti VPC, consulta Best practice e architetture di riferimento per la progettazione di VPC.
Figura 6. Configurazione della rete VPC condiviso che utilizza più host e progetti di servizio isolati (ambienti di test e produzione).
Architettura dei servizi ibridi
L'architettura dei servizi ibridi fornisce servizi cloud-native aggiuntivi progettati per consentirti di connettere e proteggere i servizi in un ambiente multi-VPC. Questi servizi cloud-native integrano ciò che è disponibile nell'architettura 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 esporre un servizio ospitato in una rete VPC in un'altra rete VPC. Non è necessario che i servizi siano ospitati dalla stessa risorsa organizzazione, pertanto Private Service Connect può essere utilizzato per utilizzare privatamente i servizi da un'altra rete VPC, anche se è collegata a un'altra risorsa 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.
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 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.
Figura 8. Configurazione di Private Service Connect per inviare traffico alle API di Google utilizzando un backend Private Service Connect.
Utilizzare Private Service Connect tra reti o entità VPC
Private Service Connect consente inoltre a un producer di servizi di offrire servizi a un consumer di servizi in un'altra rete VPC, nella stessa risorsa organizzazione o in una diversa. Una rete VPC del 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.
Figura 9. Configurazione di Private Service Connect per pubblicare un servizio gestito tramite un collegamento di servizio e utilizzare il servizio tramite un endpoint.
Accesso privato ai servizi
Private Service Connect è il modo consigliato per un producer di servizi di fornire un servizio a un consumer di servizi. Tuttavia, Private Service Connect non supporta tutti i servizi. Puoi utilizzare l'accesso privato ai servizi 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 Google Cloud progetto, lo colleghi a una rete VPC e a una regione specifiche. Puoi quindi configurare i 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.
Figura 10. Configurazione del connettore di accesso VPC serverless per accedere agli ambienti serverless utilizzando indirizzi IP interni all'interno della rete VPC. Google Cloud
I connettori di accesso VPC serverless sono supportati in ogni regione che supporta Cloud Run, Cloud Run Functions o l'ambiente standard App Engine. Per saperne di più, consulta l'elenco dei servizi supportati e dei protocolli di rete supportati per l'utilizzo del connettore di accesso VPC serverless.
Traffico in uscita VPC diretto
Il traffico in uscita VPC diretto consente al tuo servizio Cloud Run di inviare traffico a una rete VPC senza configurare un connettore di accesso VPC serverless.
Controlli di servizio VPC
I Controlli di servizio VPC consentono di 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, considera uno scenario in cui un errore umano o un'automazione errata causa l'impostazione errata delle policy 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 questi servizi sono configurati come parte del perimetro Controlli di servizio VPC, l'accesso in entrata alle risorse viene bloccato, anche se le policy IAM consentono l'accesso.
I Controlli di servizio VPC possono creare perimetri in base agli attributi del client, come il tipo di identità (account di servizio o utente) e l'origine di 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 insider dannosi o codice compromesso.
- Esposizione pubblica di dati privati causata da policy IAM configurate in modo errato.
La Figura 11 mostra come i Controlli di servizio VPC consentono di stabilire un perimetro di servizio per contribuire a mitigare questi rischi.
Figura 11. Perimetro di servizio VPC esteso agli ambienti ibridi utilizzando i servizi di accesso privato.
Utilizzando le regole in entrata e in uscita, puoi abilitare la comunicazione tra due perimetri di servizio, come mostrato nella Figura 12.
Figura 12. Configurazione delle regole in entrata e in uscita per comunicare tra i perimetri di servizio.
Per indicazioni dettagliate sulle architetture di deployment di Controlli di servizio VPC, consulta Progettare e architettare i perimetri di servizio. Per saperne di più sull'elenco dei servizi supportati da Controlli di servizio VPC, consulta Prodotti e limitazioni supportati.
Architettura distribuita Zero Trust
I controlli di sicurezza del perimetro di 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 di rete, ma non si basano esclusivamente su di esso, per l'applicazione della sicurezza. In quanto architetture distribuite, sono composte da microservizi con applicazione della policy di sicurezza per servizio, autenticazione avanzata e identità del carico di lavoro.
Puoi implementare le architetture distribuite Zero Trust come servizi gestiti da Cloud Service Mesh e Cloud Service Mesh.
Cloud Service Mesh
Cloud Service Mesh fornisce un mTLS mesh di microservizi di architettura distribuita Zero Trust preconfigurato basato su Istio. Configura il mesh utilizzando un flusso integrato flow. Cloud Service Mesh gestito, con piani dati e di controllo gestiti da Google, è supportato su GKE. È disponibile anche un control plane in-cluster adatto ad 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 policy di autorizzazione basato su Istio.
Cloud Service Mesh si basa su parchi risorse per la gestione della configurazione e dell'identità del deployment dei servizi multi-cluster. Come per Cloud Service Mesh, quando i carichi di lavoro operano in un ambiente di connettività di rete VPC flat (o condiviso), non esistono requisiti di connettività di rete speciali 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 est-ovest. Le best practice per il networking per 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 consente di impostare policy di accesso granulari in modo da poter controllare l'accesso degli utenti a un carico di lavoro in base agli attributi della richiesta di origine, come l'identità dell'utente, l'indirizzo IP e il tipo di dispositivo. Questo livello di controllo consente un ambiente Zero Trust end-to-end.
Quando utilizzi Cloud Service Mesh, devi tenere in considerazione i requisiti del cluster GKE. Per saperne di più, consulta la sezione Requisiti nella documentazione "Installazione di un singolo progetto su GKE" .
Passaggi successivi
- Networking per la distribuzione di applicazioni con accesso a internet: architetture di riferimento.
- Networking per carichi di lavoro ibridi e multi-cloud: architetture di riferimento.
- Sicurezza di rete per applicazioni distribuite in Cross-Cloud Network.
- La migrazione a Google Cloud può aiutarti a pianificare, progettare e implementare il processo di migrazione dei carichi di lavoro a Google Cloud.
- La progettazione della landing zone in Google Cloud fornisce indicazioni per la creazione di una rete della landing zone.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.