Questo documento fa parte di una serie che descrive le architetture di networking e sicurezza per le aziende che migrano i carichi di lavoro dei data center a Google Cloud.
La serie è costituita dai seguenti documenti:
- Progettazione di reti per la migrazione dei carichi di lavoro aziendali: approcci dell'architettura
- Networking per un accesso intra-cloud sicuro: architetture di riferimento (questo documento)
- Networking per la distribuzione di applicazioni su 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. Può 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 come firewall, controlli di servizio VPC e appliance virtuali di rete.
In molti casi, questi carichi di lavoro coprono più reti VPC Google Cloud e i confini tra le reti VPC devono essere protetti. Il presente documento tratta 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 consolidati nel cloud così come sono.
Firewall
Puoi stabilire un perimetro sicuro configurando regole firewall.
Puoi utilizzare i tag di rete per applicare regole firewall granulari a una raccolta di VM. Un tag è un attributo arbitrario composto 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 di implementazione su come gestire il traffico con le regole firewall di Google Cloud, consulta Criteri firewall di rete nel progetto delle basi aziendali.
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 integrarli 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 VM per contribuire a 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 virtuale di rete
Un'appliance virtuale di rete (NVA) è una VM con più interfacce di rete. che consente di connetterti direttamente a diverse reti VPC. Sulle VM possono essere implementate funzioni di sicurezza come WAF (Web Application Firewall) e firewall a livello di applicazione di sicurezza. È possibile utilizzare gli NVA per implementare funzioni di sicurezza per il traffico est-ovest, soprattutto se si utilizza una configurazione a raggio hub, come mostrato nella Figura 2.
Per le linee guida sull'implementazione relative all'utilizzo delle VMV 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 l'ispezione e il logging di sicurezza nativi eseguendo il mirroring del traffico da una subnet nella tua rete VPC. Utilizzando Cloud IDS, puoi esaminare 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 intra-VPC, utilizzando la funzionalità di mirroring dei pacchetti integrata nello stack di networking di Google Cloud. Devi abilitare l'accesso privato ai servizi per connetterti al progetto del produttore di servizi (il progetto gestito da Google) che ospita i processi 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.
Puoi proteggere Cloud IDS nel perimetro di servizio Controlli di servizio VPC utilizzando un passaggio aggiuntivo. Scopri di più sul supporto dei Controlli di servizio VPC nei prodotti supportati.
Peering di rete VPC
Per le applicazioni che coprono più reti VPC, 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'altra è in un'architettura hub e spoke con transitività, in cui il traffico da un raggio può raggiungere un altro raggio. Le sezioni seguenti forniscono dettagli su come usare il peering di rete VPC con queste architetture.
Architettura hub e spoke
Un'architettura hub e spoke è un modello diffuso 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 il logging o l'autenticazione. Il modello è utile anche se l'azienda ha bisogno di implementare un insieme comune di criteri di sicurezza per il traffico in uscita 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 hub e spoke pura 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 Topologia di rete Hub e spoke nel progetto delle basi aziendali.
Tuttavia, se non hai bisogno di una separazione a livello di VPC, puoi utilizzare un'architettura VPC condiviso, che potrebbe fornire un modello più semplice per alcune aziende che hanno appena iniziato a utilizzare Google Cloud.
Figura 4. di rete hub e spoke che usa il peering di rete VPC per l'isolamento di rete e la connettività non transitiva.
Hub e spoke con transitività
Per abilitare hub e spoke con transitività (il traffico proveniente 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 direttamente il peering con ogni altra rete VPC che deve raggiungere.
In alternativa, puoi utilizzare un NVA per collegare l'hub e gli spoke. L'AVA si trova quindi dietro i bilanciatori del carico interni che vengono utilizzati come hop successivo per il traffico dagli spoke VPC. La figura 5 mostra entrambe queste opzioni.
Inoltre, puoi usare le VPN per connetterti tra l'hub e le reti VPC spoke. Questa disposizione consente la connettività fra le connessioni a raggi X, che forniscono la transitività attraverso la rete VPC dell'hub.
Figura 5. configurazione di rete hub e spoke che utilizza Cloud VPN per l'isolamento della rete e la connettività transitiva.
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 per la sicurezza del privilegio minimo per l'amministrazione della rete, il controllo e controllo dell'accesso, perché è possibile delegare le attività di amministrazione di rete agli amministratori di rete e della sicurezza. Puoi assegnare la possibilità di creare e gestire le VM agli amministratori di 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 incidono sulla rete nella rete VPC condiviso.
Ad esempio, per aumentare l'isolamento puoi definire due reti VPC in due progetti host e collegare 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 VPC.
Figura 6. Configurazione di rete VPC condiviso che utilizza più host isolati e progetti di servizio (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 per 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 organizzazione, pertanto Private Service Connect può essere utilizzato per utilizzare privatamente servizi di un'altra rete VPC, anche se è collegato a un'altra risorsa dell'organizzazione.
Puoi utilizzare Private Service Connect in due modi: per accedere alle API di Google o ai servizi ospitati in altre reti VPC.
Usa 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 tramite un endpoint Private Service Connect privato per la tua rete VPC.
I carichi di lavoro possono inviare il traffico a un set 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 tramite un backend di Private Service Connect.
Usa 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 dell'organizzazione o in una diversa. Una rete VPC del producer di servizi può supportare più consumer di servizi. Il consumer può connettersi al servizio 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 il collegamento a un servizio e utilizzare il servizio tramite un endpoint.
Connettore di accesso VPC serverless
Un connettore di accesso serverless VPC gestisce il traffico tra l'ambiente serverless e la rete VPC. Quando crei un connettore nel progetto Google Cloud, lo colleghi a una rete VPC e a una regione 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 alla rete VPC attraverso il connettore 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 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 networking supportati per l'utilizzo del connettore di accesso serverless VPC.
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 dei criteri IAM su un servizio come Cloud Storage o BigQuery. Di conseguenza, le risorse in questi servizi diventano accessibili pubblicamente. In tal 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 viene bloccato, anche se i criteri IAM consentono l'accesso.
I Controlli di servizio VPC possono creare perimetri in base ad attributi client come tipo di identità (account di servizio o utente) e origine della rete (indirizzo IP o rete VPC).
I Controlli di servizio VPC aiutano 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 al dominio o codice compromesso.
- Esposizione pubblica di dati privati causata da criteri IAM non configurati correttamente.
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 mediante servizi di accesso privato.
Utilizzando le regole di traffico in entrata e in uscita, puoi abilitare la comunicazione tra due perimetri di servizio, come mostrato nella Figura 12.
Figura 12. Configurazione delle regole di traffico in entrata e in uscita per comunicare tra i perimetri di servizio.
Per suggerimenti dettagliati sulle architetture di deployment dei Controlli di servizio VPC, consulta Progettazione e architettura dei perimetri di servizio. Per ulteriori informazioni sull'elenco dei servizi supportati da Controlli di servizio VPC, consulta Prodotti supportati e limitazioni.
Architettura distribuita Zero Trust
I controlli di sicurezza perimetrali di rete sono necessari, ma non sufficienti, per supportare i principi di sicurezza del privilegio minimo e della difesa approfondita. Le architetture distribuite Zero Trust si basano, ma non si basano esclusivamente sul perimetro della rete, per l'applicazione della sicurezza. Essendo architetture distribuite, sono composte da microservizi con applicazione dei criteri di sicurezza, autenticazione avanzata e identità del carico di lavoro per ogni servizio.
Puoi implementare le architetture distribuite Zero Trust come servizi gestiti da Cloud Service Mesh e Cloud Service Mesh.
Cloud Service Mesh
Cloud Service Mesh può essere configurato in modo da fornire un mesh di microservizi Distributed Architecting Zero Trust all'interno di un cluster GKE utilizzando la sicurezza dei servizi. In questo modello, nei servizi GKE con componenti collaterali di Envoy o gRPC senza proxy, identità, certificati e criteri di autorizzazione sono tutti gestiti da tutti i seguenti elementi: Cloud Service Mesh, Workload Identity, Certificate Authority Service e IAM. La gestione dei certificati e la denominazione sicura sono fornite dalla piattaforma e tutte le comunicazioni tra i servizi sono soggette alla sicurezza del trasporto mTLS. La figura 13 mostra un cluster con questa configurazione.
Figura 13. Mesh di architetture distribuite Zero Trust a cluster singolo che utilizza Cloud Service Mesh.
Un criterio di autorizzazione specifica in che modo un server autorizza le richieste in entrata o gli RPC. I criteri di autorizzazione possono essere configurati per consentire o negare una richiesta in entrata o 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 per l'implementazione per la configurazione dei criteri di autorizzazione sui mesh basati su gRPC ed Envoy.
Nella Figura 13, l'architettura include un singolo cluster e un networking fisso (spazio di indirizzi IP condiviso). In genere nell'architettura distribuita Zero Trust vengono 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 per l'accesso ai carichi di lavoro ibrido, come descritto più avanti in questo documento.
Per informazioni sul controllo granulare della modalità di gestione del traffico con Cloud Service Mesh, consulta Panoramica sulla gestione avanzata del traffico.
Cloud Service Mesh
Cloud Service Mesh fornisce un mesh di microservizi mTLS Zero Trust Distributed Architecture basato su elementi di base di Istio. Puoi configurare la rete mesh utilizzando un flusso integrato. Cloud Service Mesh gestito, con piani di controllo e dati gestiti da Google, è supportato su GKE. È inoltre disponibile un piano di controllo in-cluster, adatto ad altri ambienti come Google Distributed Cloudises o GKE Multi-Cloud. Cloud Service Mesh gestisce identità e 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 dei servizi multi-cluster. Come con Cloud Service Mesh, quando i carichi di lavoro operano in un ambiente di connettività di rete VPC semplice (o condiviso), non sono previsti requisiti di connettività di rete speciali oltre alla configurazione del firewall. Quando la tua architettura include più cluster Cloud 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 di Cloud Service Mesh sono le stesse descritte in Best practice per il networking di GKE.
Cloud Service Mesh si integra inoltre con Identity-Aware Proxy (IAP). IAP consente di impostare criteri 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 considerare i requisiti dei cluster GKE. Per ulteriori informazioni, consulta la sezione Requisiti nella documentazione "Installazione di singoli progetti su GKE".
Passaggi successivi
- Networking per la distribuzione di applicazioni per 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 per le zone di destinazione.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.