Il pattern meshed si basa sulla creazione di un'architettura di rete ibrida. Questa architettura si estende su più ambienti di computing. In questi ambienti, tutti i sistemi possono comunicare tra loro e non sono limitati alla comunicazione unidirezionale in base ai requisiti di sicurezza delle tue applicazioni. Questo pattern di networking si applica principalmente alle architetture ibride a più livelli, multi-cloud partizionate o bursting. È applicabile anche alla progettazione della continuità aziendale per il provisioning di un ambiente di ripristino di emergenza in Google Cloud. In tutti i casi, è necessario connettere gli ambienti di computing in modo da rispettare i seguenti requisiti di comunicazione:
- I carichi di lavoro possono comunicare tra loro oltre i confini dell'ambiente utilizzando indirizzi IP RFC 1918 privati.
- La comunicazione può essere avviata da entrambe le parti. I dettagli del modello di comunicazione possono variare in base alle applicazioni e ai requisiti di sicurezza, ad esempio i modelli di comunicazione discussi nelle opzioni di progettazione che seguono.
- Le regole firewall che utilizzi devono consentire il traffico tra origini e destinazioni di indirizzi IP specifici in base ai requisiti dell'applicazione o delle applicazioni per cui è progettato il pattern. Idealmente, puoi utilizzare un approccio di sicurezza multilivello per limitare i flussi di traffico in modo granulare, sia tra gli ambienti di computing sia al loro interno.
Architettura
Il seguente diagramma illustra un'architettura di riferimento di alto livello del pattern mesh.
- Tutti gli ambienti devono utilizzare uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.
- Sul lato Google Cloud , puoi eseguire il deployment dei carichi di lavoro in uno o più VPC condivisi o non condivisi. Per altre possibili opzioni di progettazione di questo pattern, consulta le varianti di progettazione riportate di seguito. La struttura selezionata dei tuoi VPC deve essere in linea con i progetti e la progettazione della gerarchia delle risorse della tua organizzazione.
- La rete VPC di Google Cloud si estende ad altri ambienti di computing. Questi ambienti possono essere on-premise o in un altro cloud. Utilizza una delle opzioni di connettività di rete ibrida e multicloud che soddisfano i requisiti della tua attività e della tua applicazione.
Limita le comunicazioni solo agli indirizzi IP consentiti delle origini e delle destinazioni. Utilizza una delle seguenti funzionalità o una loro combinazione:
Appliance virtuale di rete (NVA) con funzionalità di ispezione del firewall di nuova generazione (NGFW), posizionata nel percorso di rete.
Cloud Next Generation Firewall Enterprise con il servizio di prevenzione delle intrusioni (IPS) per implementare l'ispezione approfondita dei pacchetti per la prevenzione delle minacce senza modificare la progettazione della rete o il routing.
Varianti
Il pattern di architettura meshed può essere combinato con altri approcci per soddisfare diversi requisiti di progettazione, tenendo comunque conto dei requisiti di comunicazione del pattern. Le opzioni di pattern sono descritte nelle sezioni seguenti:
- Un VPC per ambiente
- Utilizzare un firewall del livello applicazione centralizzato
- Architettura distribuita Zero Trust basata su microservizi
Un VPC per ambiente
I motivi comuni per prendere in considerazione l'opzione di una sola VPC per ambiente sono i seguenti:
- L'ambiente cloud richiede la separazione a livello di rete delle reti e delle risorse VPC, in linea con la progettazione della gerarchia delle risorse della tua organizzazione.
Se è necessaria la separazione dei domini amministrativi, può anche essere combinata
con un progetto separato per ambiente.
- Per gestire centralmente le risorse di rete in una rete comune e fornire l'isolamento di rete tra i diversi ambienti, utilizza una VPC condivisa per ogni ambiente che hai in Google Cloud, ad esempio sviluppo, test e produzione.
- Requisiti di scalabilità che potrebbero dover superare le quote VPC per un singolo VPC o progetto.
Come illustrato nel seguente diagramma, la progettazione di una VPC per ambiente consente a ogni VPC di integrarsi direttamente con l'ambiente on-premise o con altri ambienti cloud utilizzando VPN o Cloud Interconnect con più collegamenti VLAN.
Il pattern mostrato nel diagramma precedente può essere applicato a una zona di destinazione topologia di rete hub-and-spoke. In questa topologia, una o più connessioni ibride possono essere condivise con tutti i VPC spoke. Viene condiviso utilizzando un VPC di transito per terminare sia la connettività ibrida sia gli altri VPC spoke. Puoi anche espandere questo progetto aggiungendo NVA con funzionalità di ispezione firewall di nuova generazione (NGFW) nel VPC di transito, come descritto nella sezione successiva "Utilizzare un firewall di livello applicazione centralizzato".
Utilizzare un firewall del livello applicazione centralizzato
Se i tuoi requisiti tecnici impongono di prendere in considerazione il livello applicazione (livello 7) e l'ispezione approfondita dei pacchetti con funzionalità firewall avanzate che superano le funzionalità di Cloud Next Generation Firewall, puoi utilizzare un'appliance NGFW ospitata in un'NVA. Tuttavia, questa NVA deve soddisfare le esigenze di sicurezza della tua organizzazione. Per implementare questi meccanismi, puoi estendere la topologia per far passare tutto il traffico tra ambienti diversi attraverso un firewall NVA centralizzato, come mostrato nel diagramma seguente.
Puoi applicare il pattern nel seguente diagramma alla progettazione della landing zone utilizzando una topologia hub e spoke con appliance centralizzate:
Come mostrato nel diagramma precedente, la NVA funge da livello di sicurezza perimetrale e da base per l'attivazione dell'ispezione del traffico inline. Inoltre, applica rigide policy di controllo dell'accesso. Per esaminare i flussi di traffico est-ovest e nord-sud, la progettazione di una NVA centralizzata potrebbe includere più segmenti con diversi livelli di controlli di accesso alla sicurezza.
Architettura distribuita Zero Trust dei microservizi
Quando vengono utilizzate applicazioni containerizzate, l'architettura distribuita zero trust basata sui microservizi descritta nella sezione pattern mirroring è applicabile anche a questo pattern di architettura.
La differenza principale tra questo pattern e il pattern mirroring è che il modello di comunicazione tra i carichi di lavoro in Google Cloud e altri ambienti può essere avviato da entrambi i lati. Il traffico deve essere controllato e granulare, in base ai requisiti dell'applicazione e di sicurezza utilizzando Service Mesh.
Best practice per il pattern a rete
- Prima di fare qualsiasi altra cosa, decidi la struttura della gerarchia delle risorse e la struttura necessaria per supportare qualsiasi progetto e VPC. In questo modo, puoi selezionare l'architettura di rete ottimale in linea con la struttura dei tuoi Google Cloud progetti.
- Utilizza un'architettura distribuita zero trust quando utilizzi Kubernetes nel tuo ambiente di computing privato eGoogle Cloud.
- Quando utilizzi NVA centralizzati nella progettazione, devi definire più segmenti con diversi livelli di controlli di accesso alla sicurezza e criteri di ispezione del traffico. Basali sui requisiti di sicurezza delle tue applicazioni.
- Quando progetti una soluzione che include NVA, è importante considerare l'alta disponibilità (HA) delle NVA per evitare un singolo punto di errore che potrebbe bloccare tutte le comunicazioni. Segui le indicazioni per la progettazione e l'implementazione dell'alta disponibilità e della ridondanza fornite dal Google Cloud fornitore di sicurezza che fornisce le tue NVA.
- Per garantire maggiore privacy, integrità dei dati e un modello di comunicazione controllato, esponi le applicazioni tramite API utilizzando gateway API, come Apigee e Apigee Hybrid, con mTLS end-to-end. Puoi anche utilizzare un VPC condiviso con Apigee nella stessa risorsa organizzazione.
- Se la progettazione della tua soluzione richiede l'esposizione di un'applicazione basata su Google Cloud a internet pubblico, prendi in considerazione i consigli di progettazione descritti in Networking per la distribuzione di applicazioni rivolte a internet.
- Per proteggere i servizi nei tuoi progetti e contribuire a mitigare il rischio di esfiltrazione di dati, utilizza i Controlli di servizio VPC per specificare i perimetri di servizio a livello di progetto o di rete VPC. Google Cloud Inoltre, puoi estendere i service perimeter a un ambiente ibrido tramite una VPN autorizzata o Cloud Interconnect. Per saperne di più sui vantaggi dei perimetri di servizio, consulta la sezione Panoramica dei Controlli di servizio VPC.
- Consulta le best practice generali per i pattern di networking ibrido e multicloud.
Se intendi applicare un isolamento più rigoroso e un accesso più granulare tra le tue applicazioni ospitate in Google Cloude in altri ambienti, valuta la possibilità di utilizzare uno dei pattern controllati descritti negli altri documenti di questa serie.