Questo documento fa parte di una serie che descrive le architetture di networking e sicurezza per le aziende che eseguono la migrazione dei carichi di lavoro dei data center a Google Cloud.
La serie è costituita dai seguenti documenti:
- Progettazione di reti per la migrazione di carichi di lavoro aziendali: approcci all'architettura
- Networking per un accesso sicuro intra-cloud: architetture di riferimento (questo documento)
- Networking per la distribuzione di applicazioni con connessione 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. Possono consumare servizi forniti in modo nativo nel cloud, come BigQuery. Il perimetro di sicurezza è fornito da una serie di funzionalità proprietarie e di terze parti (3P), come firewall, Controlli di servizio VPC e appliance virtuali di rete.
In molti casi, questi carichi di lavoro comprendono più reti VPC Google Cloud e i confini tra le reti VPC devono essere protetti. Questo documento tratta in modo approfondito 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 si spostano i carichi di lavoro già consolidati nel cloud.
Firewall
Puoi contribuire a stabilire un perimetro sicuro configurando le regole firewall.
Puoi utilizzare i tag di rete per applicare regole firewall granulari a una raccolta di VM. Un tag è un attributo arbitrario costituito da una stringa di caratteri aggiunta al campo tags della VM al momento della creazione della VM.
Un tag può anche essere assegnato in un secondo momento modificando la VM. Per le linee guida sull'implementazione su come gestire il traffico con le regole firewall di Google Cloud, consulta Criteri firewall di rete nel progetto di base della piattaforma aziendale.
Puoi anche utilizzare il logging del firewall per controllare e verificare gli effetti dell'impostazione della regola firewall.
Puoi utilizzare i log di flusso VPC per la network forensics e eseguire il flusso dei log per l'integrazione con SIEM. Questo sistema generale può fornire monitoraggio in tempo reale, correlazione di eventi, analisi e avvisi di sicurezza.
La Figura 1 mostra come le regole firewall possono utilizzare i tag VM 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 granulare del traffico in uscita.
Appliance virtuali di rete
Un'appliance virtuale di rete (NVA) è una VM con più interfacce di rete. L'NVA consente di connettersi direttamente a più reti VPC. Nelle VM possono essere implementate funzioni di sicurezza come i web application firewall (WAF) e i firewall a livello di applicazione. Puoi utilizzare le NVA per implementare funzioni di sicurezza per il traffico est-ovest, soprattutto quando utilizzi una configurazione con spoke hub, come mostrato nella Figura 2.
Per le linee guida sull'implementazione dell'utilizzo di NVA su Google Cloud, consulta appliance di rete centralizzate su Google Cloud.
Figura 2. Configurazione dell'appliance di rete centralizzata in una rete VPC condiviso.
Cloud IDS
Cloud Intrusion Detection System (Cloud IDS) consente di implementare un'ispezione e un logging di sicurezza nativi eseguendo il mirroring del traffico da una subnet nella rete VPC. Con Cloud IDS, puoi ispezionare e monitorare un'ampia gamma di minacce a livello di rete e di applicazione per l'analisi. Puoi creare endpoint IDS Cloud nella rete VPC associata al tuo progetto Google Cloud. Questi endpoint monitorano il traffico in entrata e in uscita da e verso la rete, nonché il traffico di rete intra-VPC mediante la funzionalità di mirroring pacchetto integrata nello stack di rete di Google Cloud. Devi abilitare l'accesso privato ai servizi per connetterti al progetto producer di servizi (il progetto gestito da Google) che ospita i processi di Cloud IDS.
Se disponi di un'architettura hub e spoke, il traffico da ciascuno degli spoke può essere sottoposto a mirroring alle istanze Cloud IDS, come mostrato nella Figura 3.
Figura 3. Configurazione Cloud IDS per eseguire il mirroring del traffico VPC che utilizza l'accesso privato ai servizi.
È possibile proteggere Cloud IDS nel perimetro di servizio dei Controlli di servizio VPC tramite un passaggio aggiuntivo. Per ulteriori informazioni sul supporto dei Controlli di servizio VPC, consulta i prodotti supportati.
Peering di rete VPC
Per le applicazioni che si estendono su più reti VPC, indipendentemente dal fatto che appartengano allo stesso progetto Google Cloud o alla stessa risorsa dell'organizzazione, il peering di rete VPC consente la connettività tra reti VPC. Questa connettività consente al traffico di rimanere all'interno della rete Google in modo da non attraversare la rete internet pubblica.
Esistono due modelli per utilizzare il peering di rete VPC in un'architettura lift and shift. Uno è con un'architettura hub e spoke "pura", mentre l'altro è in un'architettura hub e spoke con transitività, in cui il traffico da uno spoke può raggiungere un altro. Le sezioni seguenti forniscono dettagli su come utilizzare il peering di rete VPC con queste diverse architetture.
Architettura hub e spoke
Un'architettura hub e spoke è un modello popolare per la connettività VPC che utilizza il peering di rete VPC. Questo modello è utile quando un'azienda ha varie applicazioni che devono accedere a un set comune di servizi, come logging o autenticazione. Il modello è utile anche se l'azienda deve implementare un insieme comune di criteri di sicurezza per il traffico che esce dalla rete attraverso l'hub. In un modello hub e spoke puro, lo scambio di traffico tra gli spoke (noto come traffico transitivo) non è consentito. La figura 4 mostra un'architettura pura hub e spoke che utilizza il peering di rete VPC per connettere gli spoke all'hub. Per le linee guida sull'implementazione per la creazione di reti hub e spoke, consulta la topologia di rete hub e spoke nel progetto di base della piattaforma aziendale.
Tuttavia, se non hai bisogno della separazione a livello di VPC, puoi utilizzare un'architettura VPC condiviso, che potrebbe fornire un modello più semplice per alcune aziende che sono appena agli inizi su Google Cloud.
Figura 4. Architettura di rete hub e spoke che utilizza il peering di rete VPC per l'isolamento della rete e la connettività non transitiva.
Hub e spoke con transitività
Per abilitare hub e spoke con transitività (il traffico da uno spoke può raggiungere altri spoke attraverso l'hub), esistono diversi approcci che utilizzano il peering di rete VPC. Puoi utilizzare il peering di rete VPC in una topologia mesh completa, in cui ogni rete VPC esegue il peering direttamente con ogni altra rete VPC che deve raggiungere.
In alternativa, puoi utilizzare un NVA per collegare l'hub e gli spoke. L'NVA risiede quindi dietro bilanciatori del carico interni utilizzati come hop successivo per il traffico dagli spoke VPC. La Figura 5 mostra entrambe queste opzioni.
Inoltre, puoi utilizzare le VPN per connetterti tra l'hub e le reti VPC spoke. Questa disposizione consente la connettività tra connessioni spoke, che forniscono transitività sulla rete VPC dell'hub.
Figura 5. Configurazione di rete hub e spoke che utilizza Cloud VPN per l'isolamento di rete e la connettività transitiva.
VPC condiviso
Puoi utilizzare un VPC condiviso per mantenere un 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, il controllo e controllo dell'accesso dell'accesso della rete poiché puoi delegare le attività di amministrazione della rete agli amministratori di rete e della sicurezza. Puoi assegnare agli amministratori di istanze la possibilità di creare e gestire le VM utilizzando i progetti di servizio. L'uso di un progetto di servizio garantisce che agli amministratori delle VM sia concessa solo la possibilità di creare e gestire le istanze e che non siano autorizzati ad apportare modifiche che influiscano sulla rete nella rete VPC condiviso.
Ad esempio, puoi fornire un maggiore isolamento definendo due reti VPC che si trovino 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.
Figura 6. Configurazione di una rete VPC condiviso che utilizza più host e progetti di servizio isolati (ambienti di test e produzione).
Architettura di servizi ibridi
L'architettura di servizi ibridi fornisce ulteriori servizi cloud-native 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 VPC su larga scala.
Private Service Connect
Private Service Connect consente di visualizzare un servizio ospitato in una rete VPC in un'altra rete VPC. Non è necessario che i servizi siano ospitati dalla stessa risorsa dell'organizzazione, quindi Private Service Connect può essere utilizzato per consumare 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 a 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 rete VPC, come mostrato nella Figura 7.
Figura 7. Configurazione di Private Service Connect per inviare il 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 il traffico alle API di Google utilizzando un backend Private Service Connect.
Utilizza 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 un'altra. La rete VPC di un producer di servizi può supportare più consumer di servizi. Il consumer può connettersi al servizio producer inviando il traffico a un endpoint Private Service Connect che si trova 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 il collegamento a un servizio e utilizzare il servizio tramite un endpoint.
Connettore di accesso serverless VPC
Un connettore di accesso serverless VPC gestisce il traffico tra il tuo ambiente serverless e la tua rete VPC. Quando crei un connettore nel progetto Google Cloud, lo colleghi a una regione e a una rete VPC specifiche. Puoi quindi configurare i tuoi servizi serverless in modo da utilizzare il connettore per il traffico di rete in uscita. Puoi specificare un connettore utilizzando una subnet o un intervallo CIDR. Il traffico inviato attraverso il connettore alla rete VPC ha origine 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 Google Cloud utilizzando indirizzi IP interni all'interno della rete VPC.
I connettori di accesso VPC serverless sono supportati in ogni regione che supporta Cloud Run, Cloud Functions o l'ambiente standard di App Engine. Per ulteriori informazioni, consulta l'elenco dei servizi supportati e dei protocolli di rete supportati per l'utilizzo del connettore di accesso VPC serverless.
Controlli di servizio VPC
Controlli di servizio VPC ti aiuta 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, puoi considerare uno scenario in cui un errore umano o un'automazione errata causa 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, c'è il rischio di esposizione dei dati. Se questi servizi sono configurati come parte del perimetro dei Controlli di servizio VPC, l'accesso in entrata alle risorse è bloccato, anche se i criteri IAM consentono l'accesso.
I Controlli di servizio VPC possono creare perimetri in base ad attributi client come il tipo di identità (account di servizio o utente) e l'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 malintenzionati interni o codice compromesso.
- Esposizione pubblica di dati privati causata da criteri IAM configurati in modo errato.
La Figura 11 mostra in che modo Controlli di servizio VPC consente di stabilire un perimetro di servizio per mitigare questi rischi.
Figura 11. Perimetro di servizio VPC esteso a ambienti ibridi mediante 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 la comunicazione tra i perimetri di servizio.
Per suggerimenti dettagliati sulle architetture di deployment dei Controlli di servizio VPC, consulta Progettare e progettare i perimetri di servizio. Per ulteriori informazioni sull'elenco dei servizi supportati dai Controlli di servizio VPC, vedi Prodotti e limitazioni supportati.
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 approfondita. Le architetture distribuite si basano sul perimetro della rete, ma non si basano esclusivamente sul perimetro di rete, per l'applicazione forzata della sicurezza. Essendo architetture distribuite, sono composte da microservizi con applicazione di criteri di sicurezza, autenticazione avanzata e identità dei carichi di lavoro per servizio.
Puoi implementare le architetture distribuite Zero Trust come servizi gestiti da Traffic Director e Anthos Service Mesh.
Traffic Director
Traffic Director può essere configurato per fornire un mesh di microservizi di tipo Architettura distribuita Zero Trust all'interno di un cluster GKE utilizzando la sicurezza dei servizi. In questo modello, nei servizi GKE con Sidecar Envoy o gRPC senza proxy, identità, certificati e criteri di autorizzazione sono tutti gestiti da: Traffic Director, Workload Identity, Certificate Authority Service e IAM. La gestione dei certificati e la denominazione sicura sono fornite dalla piattaforma e tutte le comunicazioni di servizio sono soggette alla sicurezza del trasporto mTLS. La Figura 13 mostra un cluster con questa configurazione.
Figura 13. Mesh di architettura distribuita Zero Trust a cluster singolo che utilizza Traffic Director.
Un criterio di autorizzazione specifica in che modo un server autorizza le richieste in entrata o le RPC. Il criterio di autorizzazione può essere configurato per consentire o negare una richiesta in entrata o una RPC in base a vari parametri, come l'identità del client che ha inviato la richiesta, l'host, le intestazioni e altri attributi HTTP. Sono disponibili linee guida di implementazione per la configurazione dei criteri di autorizzazione sui mesh basati su gRPC e Envoy.
Nella Figura 13, l'architettura ha un singolo cluster e un networking fisso (spazio di indirizzi IP condiviso). Nell'architettura distribuita senza Trust vengono generalmente utilizzati più cluster per isolamento, località e scalabilità.
In ambienti più complessi, più cluster possono condividere l'identità gestita quando i cluster sono raggruppati per parchi risorse. In questo caso, puoi configurare la connettività di rete tra reti VPC indipendenti utilizzando Private Service Connect. Questo approccio è simile all'approccio di connettività di rete multi-cluster di accesso a carichi di lavoro ibridi, come descritto più avanti in questo documento.
Per informazioni sul controllo granulare della modalità di gestione del traffico con Traffic Director, consulta Panoramica della gestione avanzata del traffico.
Anthos Service Mesh
Anthos Service Mesh fornisce un mesh di microservizi mTLS Zero Trust Distributed Architecture pronto all'uso basato sui fondamenti di Istio. Puoi configurare il mesh utilizzando un flusso integrato. Anthos Service Mesh gestito, con piani di controllo e dati gestiti da Google, è supportato su GKE. È inoltre disponibile un piano di controllo nel cluster, adatto ad altri ambienti come Google Distributed Cloud Virtualises o GKE Multi-Cloud. Anthos Service Mesh gestisce identità e certificati per te, fornendo un modello dei criteri di autorizzazione basato su Istio.
Anthos Service Mesh si basa sui parchi risorse per gestire la configurazione e l'identità del deployment di servizi multi-cluster. Come con Traffic Director, quando i carichi di lavoro operano in un ambiente di connettività di rete VPC flat (o condiviso), non sono previsti requisiti di connettività di rete speciali oltre alla configurazione del firewall. Se la tua architettura include più cluster Anthos Service Mesh in reti VPC o ambienti di rete separati, ad esempio attraverso una connessione Cloud Interconnect, è necessario anche un gateway est-ovest. Le best practice per il networking per Anthos Service Mesh corrispondono a quelle descritte in Best practice per il networking GKE.
Anthos Service Mesh si integra anche con Identity-Aware Proxy (IAP). IAP consente di impostare criteri di accesso granulari per consentirti di 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.
Devi considerare i requisiti dei cluster GKE quando utilizzi Anthos Service Mesh. Per ulteriori informazioni, consulta la sezione Requisiti nella documentazione relativa all'installazione di singoli progetti su GKE.
Passaggi successivi
- Networking per la distribuzione di applicazioni con connessione a internet: architetture di riferimento.
- Networking per carichi di lavoro ibridi e multi-cloud: architetture di riferimento.
- 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 delle zone di destinazione in Google Cloud offre indicazioni per creare una rete della zona di destinazione.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.