Questo documento fa parte di una serie che descrive le architetture di rete e sicurezza per le aziende che eseguono la migrazione dei carichi di lavoro del data center aGoogle Cloud.
La serie è costituita dai seguenti documenti:
- Progettare 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 esposte 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à proprietarie (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ù reti VPC e i confini tra le reti VPC devono essere protetti. Google CloudQuesto documento descrive 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.
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 di implementazione su come gestire il traffico con le regole firewall, consulta Policy firewall di rete nel progetto di base per le aziende. Google Cloud
Puoi anche utilizzare il logging delle regole 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 in streaming i log per l'integrazione con 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 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 con 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-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 la registrazione della sicurezza native mediante il mirroring del traffico da una subnet nella rete VPC. Utilizzando Cloud IDS, puoi ispezionare e monitorare un'ampia gamma di minacce a livello di rete e di applicazione per l'analisi. Crea endpoint Cloud IDS nella tua rete VPC. Google Cloud Questi endpoint monitorano il traffico in entrata e in uscita da e verso la rete, nonché il traffico di rete intra-VPC, utilizzando la funzionalità di mirroring dei pacchetti integrata nello stack di networking Google Cloud . Devi abilitare l'accesso privato ai servizi per connetterti al progetto service producer (il progetto gestito da Google) che ospita i processi 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.
Figura 3. Configurazione di Cloud IDS per eseguire 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 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 connesse 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 alle 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, indipendentemente dal fatto che appartengano allo stesso progetto o alla stessa risorsa organizzazione, il peering di rete VPC consente la connettività tra le reti VPC. Google Cloud 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 comune 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 norme 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à tra 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 ti consente di implementare la best practice di sicurezza del privilegio minimo per l'amministrazione, l'auditing econtrollo dell'accessoi della rete, perché puoi delegare le attività di amministrazione della rete agli amministratori di rete e della 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 VM venga concessa solo la possibilità di creare e gestire istanze e che non sia consentito apportare modifiche alla rete VPC condiviso che influiscono sulla rete.
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.
Figura 6. Configurazione di rete VPC condiviso che utilizza più progetti host e 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 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 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 di 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.
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 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 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 un collegamento al servizio e utilizzare il servizio tramite un endpoint.
Accesso privato ai servizi
Private Service Connect è il modo consigliato per un service producer di fornire un servizio a un service consumer. 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 serverless VPC 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 specifica e a una regione. 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 alla rete VPC ha origine dalla subnet o dall'intervallo CIDR che hai 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, le funzioni Cloud Run 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.
VPC diretto in uscita
L'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
Controlli di servizio VPC ti aiuta a prevenire 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 questo caso, esiste il rischio di esposizione dei dati. Se questi servizi sono configurati come parte del perimetro di Controlli di servizio VPC, l'accesso in entrata alle risorse è bloccato, anche se i criteri IAM consentono l'accesso.
Controlli di servizio VPC può creare perimetri in base ad attributi client come tipo di identità (account di servizio o utente) e 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 utenti malintenzionati 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. Il perimetro di servizio VPC è stato 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 consigli dettagliati sulle architetture di deployment dei Controlli di servizio VPC, consulta Progettare e creare perimetri di servizio. Per saperne di più sull'elenco dei servizi supportati dai Controlli di servizio VPC, consulta la sezione Prodotti supportati e limitazioni.
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 per l'applicazione della sicurezza, ma non si affidano esclusivamente a questo. 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 e Cloud Service Mesh.
Cloud Service Mesh
Cloud Service Mesh fornisce un mesh di microservizi mTLS Zero Trust Distributed Architecture basato sulle fondamenta di Istio. Hai configurato la mesh utilizzando un flusso integrato. Managed Cloud Service Mesh, con piani di controllo e dati 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 sui parchi risorse per la gestione della configurazione di deployment e dell'identità del servizio multi-cluster. Come per Cloud Service Mesh, quando i tuoi carichi di lavoro operano in un ambiente di connettività di rete VPC flat (o condiviso), non esistono requisiti speciali di connettività di rete oltre alla configurazione del firewall. Quando la tua architettura include più cluster Cloud Service Mesh in reti VPC o ambienti di networking separati, ad esempio in una connessione Cloud Interconnect, hai bisogno anche di 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 ti 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 identità dell'utente, indirizzo IP e tipo di dispositivo. Questo livello di controllo consente un ambiente zero trust end-to-end.
Quando utilizzi Cloud Service Mesh, devi considerare i requisiti del cluster GKE. Per saperne di più, consulta la sezione Requisiti della documentazione "Installazione di un singolo progetto su GKE".
Passaggi successivi
- Networking per la distribuzione di applicazioni esposte 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.
- Migrazione a Google Cloud può aiutarti a pianificare, progettare e implementare il processo di migrazione dei tuoi carichi di lavoro a Google Cloud.
- Progettazione della zona di destinazione in Google Cloud fornisce indicazioni per la creazione di una rete della zona di destinazione.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.