Questo documento fa parte di una serie che descrive il networking e la sicurezza architetture aziendali che eseguono la migrazione dei carichi di lavoro dei data center in Google Cloud.
La serie è costituita dai seguenti documenti:
- Progettazione di reti per la migrazione dei carichi di lavoro aziendali: approcci dell'architettura
- Networking per l'accesso sicuro all'interno del cloud: architetture di riferimento (questo documento)
- Networking per l'implementazione di applicazioni rivolte 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 consumare servizi forniti in modo nativo nel cloud, come BigQuery. Il perimetro di sicurezza è fornite da una serie di funzionalità proprietarie (proprietarie) 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ù reti VPC di Google Cloud 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.
Firewall
Per stabilire un perimetro sicuro, puoi configurare
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 un
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 per le aziende.
Puoi anche utilizzare il logging del firewall per controllare e verificare gli effetti del dell'impostazione della regola firewall.
Puoi utilizzare i log di flusso VPC per le analisi forensi della rete generare un flusso di log per l'integrazione 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 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 in uscita.
Appliance virtuale di rete
Un'appliance virtuale di rete (NVA) è una VM con più interfacce di rete. L'NVA ti consente di connetterti direttamente a diverse reti VPC. Funzioni di sicurezza come il web i firewall per le applicazioni (WAF) e i firewall a livello di applicazione implementate sulle VM. Puoi utilizzare le NVA per implementare funzioni di sicurezza per il traffico est-ovest, in particolare quando utilizzi una configurazione hub-spoke, come mostrato nella figura 2.
Figura 2. Configurazione centralizzata delle appliance di rete in una rete VPC condivisa.
Cloud IDS
Cloud Intrusion Detection System (Cloud IDS) consente di implementare l'ispezione di sicurezza nativa mediante il mirroring del traffico da una subnet nella tua rete VPC. Con Cloud IDS, puoi ispezionare e monitorare un'ampia gamma di a livello di rete e di applicazione per l’analisi. Crea da te Endpoint Cloud IDS nella tua rete VPC associata al progetto Google Cloud. Questi endpoint monitorano il traffico in entrata e in uscita da e verso la rete, oltre al traffico di rete intra-VPC, utilizzando il mirroring pacchetto integrate nello stack di networking di Google Cloud. Tu deve abilitare accesso privato ai servizi per potersi collegare producer di servizi (il progetto gestito da Google) che ospita Cloud IDS i processi di machine learning.
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 ai servizi privati.
Cloud IDS può essere protetto nel servizio Controlli di servizio VPC un perimetro utilizzando passaggio aggiuntivo. Puoi scoprire di più sul supporto dei Controlli di servizio VPC in prodotti supportati.
Peering di rete VPC
Per le applicazioni che coprono più reti VPC, appartengono allo stesso progetto Google Cloud o alla stessa risorsa dell'organizzazione, Il peering di rete VPC consente la connettività tra VPC reti. Questa connettività permette al traffico di rimanere all'interno della rete Google non attraversa la rete internet pubblica.
Esistono due modelli per utilizzare il peering di rete VPC in un approccio lift and shift dell'architettura. Uno è con un carattere "puro" hub e spoke e l'altro è in un'architettura hub e spoke con transitività, in cui il traffico proveniente da uno spoke può raggiungere un altro spoke. Le sezioni che seguono forniscono dettagli su come utilizzare il peering di rete VPC con queste diverse architetture.
Architettura hub e spoke
R architettura hub e spoke è un modello molto diffuso per la connettività VPC che utilizza peering di rete VPC. Questo modello è utile quando un'azienda ha di accedere a un set comune di servizi, come il logging o autenticazione. Il modello è utile anche se l'azienda deve implementare insieme comune di criteri di sicurezza per il traffico in uscita dalla rete tramite l'hub. In un modello hub-and-spoke puro, lo scambio di traffico tra gli spoke (noto come traffico di transito) non è consentito. La figura 4 mostra una che utilizza il peering di rete VPC per connettere all'hub. Per le linee guida di implementazione per la creazione di reti hub-and-spoke, consulta Topologia di rete hub-and-spoke nel progetto di fondazione di un'azienda.
Tuttavia, se non hai bisogno di una separazione a livello di VPC, puoi utilizzare una VPC condiviso che potrebbe fornire un modello più semplice per alcune aziende che sono con Google Cloud.
Figura 4. L'architettura di rete hub and spoke utilizza Peering di rete VPC per l'isolamento di rete e la connettività non transitiva.
Hub e spoke con transitività
Per abilitare l'architettura hub-and-spoke con transitività (il traffico da uno spoke può raggiungere altri spoke tramite l'hub), esistono diversi approcci che utilizzano il peering di rete VPC. Puoi utilizzare la modalità Peering di rete VPC in una topologia mesh completa, in cui ogni VPC la rete esegue direttamente il peering con ogni altra rete VPC di cui ha bisogno da raggiungere.
In alternativa, puoi utilizzare un'NVA per collegare l'hub e i raggi. L'AVA si trova quindi dietro bilanciatori del carico interni, utilizzati come hop successivo per il traffico dagli spoke VPC. La figura 5 mostra entrambe le queste opzioni.
Inoltre, puoi utilizzare le VPN per connettere le reti VPC dell'hub e dello spoke. Questa disposizione consente la raggiungibilità tramite connessioni spoke-spoke, che garantiscono la transitività nella 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 la modalità VPC condiviso, per mantenere il controllo centralizzato sulle risorse di rete come subnet, e firewall nei progetti host. Questo livello di controllo consente di implementare la best practice di sicurezza del privilegio minimo per l'amministrazione di rete, e controllo dell'accesso perché è possibile delegare l'amministrazione di rete le attività agli amministratori di rete e della sicurezza. Puoi assegnare la possibilità creare e gestire VM per gli amministratori di 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 VPC in due progetti host e collegando più servizi in ogni rete, uno per la produzione e uno per il 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 un VPC reti, consulta Best practice e architetture di riferimento per la progettazione di VPC.
Figura 6. Configurazione della rete VPC condivisa 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 integrano a ciò che è disponibile nell'architettura lift and shift e possono semplificare gestire 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 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 API di Google o per accedere a servizi ospitati in un altro VPC reti.
Usa Private Service Connect per accedere alle API di Google
Quando utilizzi Private Service Connect, puoi esporre 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 da inviare il traffico verso le API di Google utilizzando Private Service Connect privato per la tua rete VPC.
I carichi di lavoro possono inviare il traffico Set di API di Google globali mediante un endpoint Private Service Connect. Inoltre, puoi utilizza un backend Private Service Connect per accedere a una singola API di Google, estendendo le funzionalità di sicurezza del carico bilanciatori ai servizi API. La figura 8 mostra questa configurazione.
Figura 8. Configurazione di Private Service Connect da inviare il traffico verso le API di Google utilizzando Private Service Connect di un backend cloud.
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 un'altra. un producer di servizi. La rete VPC può supportano più consumer di servizi. Il consumer può connettersi al servizio producer inviando traffico a un Endpoint Private Service Connect situato nell'interfaccia utente rete VPC. 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 consumare il servizio tramite un endpoint.
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, colleghi a una specifica rete VPC e regione. Puoi quindi configurare dai tuoi servizi serverless per utilizzare il connettore per il traffico di rete in uscita. Puoi specificare un connettore utilizzando una subnet o un intervallo CIDR. Traffico inviato tramite di accesso alla rete VPC abbia origine dalla subnet o Intervallo CIDR specificato, come mostrato nella Figura 10.
Figura 10. Configurazione del connettore di accesso VPC serverless Consente di accedere agli ambienti serverless di Google Cloud utilizzando indirizzi IP interni all'interno della tua 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.
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 in che questi servizi diventino accessibili pubblicamente. In questo caso, sussiste il rischio che i dati dell'esposizione. Se questi servizi sono stati configurati nell'ambito perimetro dei Controlli di servizio VPC, l'accesso alle risorse in entrata è bloccato anche se i criteri IAM consentono l'accesso.
I Controlli di servizio VPC possono creare perimetri in base ad attributi del client come 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 dei dati privati causata da una configurazione errata i criteri IAM.
La figura 11 mostra come i Controlli di servizio VPC consentono di definire un servizio il perimetro per mitigare questi rischi.
Figura 11. Perimetro di servizio VPC esteso a ibrido ambienti usando servizi di accesso privato.
Utilizzando le regole di traffico in entrata e in uscita, puoi abilitare la comunicazione tra due perimetri di servizio, come illustrato nella Figura 12.
Figura 12. Configurazione di regole di ingresso e uscita per la comunicazione tra i perimetri di servizio.
Per suggerimenti dettagliati sul deployment dei Controlli di servizio VPC architetture, vedi Progettare e progettare perimetri di servizio. Per ulteriori informazioni sull'elenco dei servizi supportati 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 il supporto i principi di sicurezza del privilegio minimo e della difesa approfondita. Zero Trust Le architetture distribuite si basano sulla rete, ma non si basano unicamente perimetrale del perimetro per l'applicazione della sicurezza. In quanto architetture distribuite, sono composto da microservizi con applicazione dei criteri di sicurezza per servizio, l'autenticazione avanzata e l'identità per i carichi di lavoro.
Puoi implementare le architetture distribuite Zero Trust come servizi gestiti Cloud Service Mesh e Cloud Service Mesh.
Cloud Service Mesh
Cloud Service Mesh può essere configurato per fornire un mesh di microservizi con architettura distribuita Zero Trust all'interno di un cluster GKE utilizzando la sicurezza dei servizi. In questo modello, nei servizi GKE che includono Envoy file collaterali o gRPC senza proxy, identità, certificati e criterio di autorizzazione il tutto gestito da Google 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 al trasporto mTLS sicurezza. La figura 13 mostra un cluster con questa configurazione.
Figura 13. Mesh di architettura distribuita Zero Trust a un cluster che utilizza Cloud Service Mesh.
Un criterio di autorizzazione specifica in che modo un server autorizza le richieste o le RPC in entrata. Il criterio di autorizzazione può essere configurato per consentire o negare una richiesta o un'RPC in entrata in base a vari parametri, ad esempio l'identità del client che ha inviato la richiesta, l'host, le intestazioni e altri attributi HTTP. Sono disponibili linee guida per l'implementazione dei criteri di autorizzazione su mesh basati su gRPC e Envoy.
Nella figura 13, l'architettura ha un singolo cluster e una networking flat (spazio degli indirizzi IP condiviso). In genere vengono utilizzati più cluster Architettura distribuita Zero Trust per isolamento, località e scala.
In ambienti più complessi, più cluster possono condividere l'identità gestita quando sono raggruppati in parchi risorse. In questo caso, puoi configurare la connettività di networking le reti VPC utilizzando Private Service Connect. Questo approccio è simile all'accesso ibrido ai carichi di lavoro multi-cluster connettività di rete come descritto più avanti in questo documento.
Per informazioni sul controllo granulare del modo in cui viene gestito il traffico con Cloud Service Mesh, consulta la Panoramica della gestione avanzata del traffico.
Cloud Service Mesh
Cloud Service Mesh offre un'esperienza preconfigurata mTLS Mesh di microservizi Zero Trust Distributed Architecture basato su Istio le basi. Puoi configurare la rete mesh utilizzando un modello flusso. Cloud Service Mesh gestito, con i dati e i piani di controllo gestiti da Google, è supportata 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 le tue I carichi di lavoro operano in una connettività di rete VPC fissa (o condivisa) non sono previsti requisiti speciali per la connettività di rete la configurazione del firewall. Quando l'architettura include più elementi Cloud Service Mesh tra i cluster in reti VPC separate in ambienti di networking, ad esempio attraverso una connessione Cloud Interconnect è necessaria anche una connessione gateway est-ovest. Le best practice per la rete di Cloud Service Mesh sono le stesse descritte in Best practice per la rete di GKE.
Cloud Service Mesh si integra anche con Identity-Aware Proxy (IAP). IAP ti consente di impostare criteri criteri di accesso in modo da poter controllare l'accesso degli utenti a un carico di lavoro in base agli attributi del come l'identità dell'utente, l'indirizzo IP e il tipo di dispositivo. Questo livello di controllo consente un ambiente end-to-end zero trust.
Devi considerare i requisiti dei cluster GKE quando utilizzi Cloud Service Mesh. 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 per internet: architetture di riferimento.
- Networking per carichi di lavoro ibridi e multi-cloud: architetture di riferimento.
- Migrazione a Google Cloud può aiutarti a pianificare, progettare e implementare il processo di migrazione dei carichi di lavoro in Google Cloud.
- La pagina Design della zona di destinazione in Google Cloud fornisce indicazioni per creare una rete della zona di destinazione.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.