Questo documento fa parte di una serie che descrive il networking e la sicurezza per le aziende che migrano i 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 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 si trovano 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 coprono più istanze reti VPC e i confini tra le reti VPC reti devono essere protette. Il presente documento tratta queste misure di sicurezza e le architetture di connettività.
Architettura lift and shift
Il primo scenario per un caso d'uso intra-cloud è un'architettura lift and shift che consente di spostare i carichi di lavoro stabiliti nel cloud così come sono.
Firewall
Per stabilire un perimetro sicuro, puoi configurare
regole firewall.
Puoi utilizzare la modalità
tag di rete per applicare regole firewall granulari
in 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 l'implementazione
linee guida su come
gestire il traffico con le regole firewall di Google Cloud,
vedi
Criteri del firewall di rete
nel progetto delle basi aziendali.
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 flussi di log per l'integrazione 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 limitare il traffico tra le VM in una rete VPC.
Figura 1. La configurazione del firewall di rete che applica i tag di rete un controllo granulare del traffico in uscita.
Appliance virtuale di rete
R appliance virtuale di rete (NVA) è una VM con più interfacce di rete. L'NVA ti consente di connetterti direttamente in 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 usare le funzionalità VDA per implementare funzioni di sicurezza per il traffico da est a ovest, soprattutto quando usi una configurazione a raggio hub, come mostrato nella figura 2.
Per le linee guida di implementazione relative all'utilizzo delle VML 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 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 attivare 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 e spoke, il traffico da ciascuno dei raggi può il 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.
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 seguenti sezioni forniscono dettagli su come utilizzare in 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 e spoke puro, lo scambio di traffico tra gli spoke (noto come traffico transitorio) non è consentito. La figura 4 mostra una che utilizza il peering di rete VPC per connettere all'hub. Per le linee guida di implementazione della creazione di hub e spoke reti, 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 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 attivare hub e spoke con transitività (il traffico proveniente da uno spoke può raggiungere altri spoke attraverso l'hub), 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 gli spoke. 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 usare le VPN per connetterti tra l'hub e lo spoke reti VPC. Questo accordo consente la connettività connessioni a raggi, che forniscono la transitività attraverso l'hub rete VPC.
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'uso di un progetto di servizio garantisce che agli amministratori delle VM vengano fornite solo capacità di creare e gestire le istanze, e che non sono autorizzati a modifiche che incidono sulla rete nella rete VPC condiviso.
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 i test. La figura 6 mostra un'architettura che isola un ambiente di produzione da un ambiente 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 di una rete VPC condiviso che usa più e progetti di servizio isolati (ambienti di test e produzione).
Architettura dei servizi ibridi
L'architettura dei servizi ibridi fornisce servizi cloud-native aggiuntivi che sono progettati per consentirti di connettere e proteggere i servizi 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, È possibile usare Private Service Connect per consumare privatamente i servizi da 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 del tuo 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 a un consumer di servizi in un'altra rete VPC in nella stessa risorsa dell'organizzazione o in una diversa. 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 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
R Connettore di accesso serverless VPC gestisce il traffico tra il tuo ambiente serverless e il tuo VPC in ogni rete. 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. Tu 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 supporti Cloud Run, Cloud Functions o nell'ambiente standard di App Engine. Per ulteriori informazioni, consulta l'elenco servizi supportati e protocolli di rete supportati per l'utilizzo del connettore di accesso VPC serverless.
Controlli di servizio VPC
Controlli di servizio VPC 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 sono la causa Impostare in modo errato i 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 delle regole in entrata e in uscita per comunicare tra 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 servizio gestito Zero Trust Mesh di microservizi dell'architettura 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 con architettura distribuita 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 RPC. Il criterio di autorizzazione può essere configurato 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 di implementazione per la configurazione dei criteri di autorizzazione su mesh basate gRPC e Envoy.
Nella figura 13, l'architettura ha un singolo cluster e networking piatta (spazio di 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 vengono raggruppati per cluster 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 su un controllo granulare della modalità di gestione del traffico con Cloud Service Mesh, consulta 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. Un piano di controllo nel cluster ed è inoltre disponibile, che è adatto altri ambienti come Google Distributed Cloudises o GKE Multi-Cloud. Cloud Service Mesh gestisce identità e certificati per conto tuo, fornendoti una Basato su Istio modello dei criteri di autorizzazione.
Cloud Service Mesh si basa su parchi per la gestione servizio multi-cluster configurazione e identità del deployment. 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 il networking di Cloud Service Mesh sono le stesse di quelle sono descritti in Best practice per il networking 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 consente un ambiente Zero Trust end-to-end.
Devi considerare i requisiti dei cluster GKE quando utilizzi Cloud Service Mesh. Per ulteriori informazioni, consulta Requisiti in "Installazione di un singolo progetto su GKE" documentazione.
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 carichi di lavoro in Google Cloud.
- Progettazione delle zone di destinazione in Google Cloud fornisce le indicazioni per creare una rete per le zone di destinazione.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.