Il pattern mesh si basa sullo sviluppo di un'architettura di rete ibrida. Questa architettura si estende a più ambienti di elaborazione. In questi ambienti, tutti i sistemi possono comunicare tra loro e non sono limitati a una via di mezzo la comunicazione in base ai requisiti di sicurezza delle applicazioni. Questo pattern di networking si applica principalmente ibrido a più livelli, multi-cloud partizionato, o bursting diverse architetture. È applicabile anche continuazione aziendale per eseguire il provisioning di un ambiente di ripristino di emergenza (RE) in Google Cloud. In tutto casi, è necessario collegare gli ambienti di computing in modo da allineare con i seguenti requisiti di comunicazione:
- I carichi di lavoro possono comunicare tra loro in diversi ambienti utilizzando indirizzi IP RFC 1918 privati.
- La comunicazione può essere avviata da entrambe le parti. Le specifiche del del modello di comunicazione può variare in base alle applicazioni come i modelli di comunicazione discussi nella progettazione le opzioni che seguono.
- Le regole del 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. L'ideale è è possibile utilizzare un approccio alla sicurezza a più livelli per limitare i flussi di traffico in modo granulare, sia tra gli ambienti di elaborazione che all'interno.
Architettura
Il seguente diagramma illustra un'architettura di riferimento di alto livello del pattern reticolato.
- Tutti gli ambienti devono utilizzare uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.
- Sul lato di Google Cloud, puoi eseguire il deployment dei carichi di lavoro in un singolo o più VPC condivisi o non condivisi. Per altre possibili opzioni di design di questo pattern, consulta le varianti di design che seguono. La struttura selezionata dei VPC deve essere in linea con i progetti e il design della gerarchia delle risorse della tua organizzazione.
- La rete VPC di Google Cloud si estende ad altre computing ambienti cloud-native. 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 delle tue applicazioni.
Limita le comunicazioni solo agli indirizzi IP consentiti delle origini e delle destinazioni. Utilizza una delle seguenti funzionalità o una combinazione di queste:
Appliance virtuali di rete (NVA) con firewall di nuova generazione (NGFW), collocate nel percorso della rete.
Firewall aziendale di nuova generazione Cloud con il servizio di prevenzione delle intrusioni (Intrusion Prevention Service, IPS) per implementare di ispezione per la prevenzione delle minacce senza modificare la progettazione della rete i percorsi dei carichi di lavoro.
Varianti
Il pattern di architettura mesh può essere combinato con altri approcci per soddisfare diversi requisiti di progettazione, pur considerando la comunicazione i requisiti del pattern. Le opzioni per i pattern sono descritte nelle sezioni seguenti:
- Un VPC per ambiente
- Utilizzare un firewall a livello di applicazione centralizzato
- Architettura distribuita di microservizi Zero Trust
Una VPC per ambiente
Ecco alcuni dei motivi più comuni per prendere in considerazione l'opzione di una sola VPC per ambiente:
- L'ambiente cloud richiede una separazione a livello di rete del VPC
di reti e risorse, in linea con le linee guida
progettazione della gerarchia delle risorse.
Se è necessaria la separazione amministrativa dei domini, puoi anche combinarla
con un progetto separato per ambiente.
- Per gestire centralmente le risorse di rete in una rete comune e fornire isolamento della rete tra i diversi ambienti, utilizza una VPC condivisa per ogni ambiente di 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, il design di un 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ù agganci VLAN.
Il pattern mostrato nel diagramma precedente può essere applicato a una topologia di rete hub-and-spoke della zona di destinazione. In questa topologia, è possibile condividere una o più connessioni ibride con tutti i VPC spoke. Viene condiviso utilizzando un VPC di transito per terminare sia la connettività ibrida sia le altre VPC spoke. Puoi anche espandere questo design aggiungendo un NVA con funzionalità di ispezione del firewall di nuova generazione (NGFW) nella VPC di transito, come descritto nella sezione successiva "Utilizzare un firewall a livello di applicazione centralizzato".
Usa un firewall centralizzato a livello di applicazione
Se i tuoi requisiti tecnici impongono di considerare il livello dell'applicazione (livello 7) e analisi approfondita dei pacchetti, con funzionalità di firewall avanzate che superano le funzionalità di Cloud Next Generation Firewall, puoi utilizzare un'appliance NGFW ospitata una NVA. Tuttavia, l'NVA deve soddisfare le esigenze di sicurezza della tua organizzazione. Per implementare questi meccanismi, puoi estendere la topologia in modo da far passare tutto il traffico tra ambienti tramite un firewall NVA centralizzato, come mostrato nel diagramma seguente.
Puoi applicare il pattern nel seguente diagramma alla progettazione della zona di destinazione utilizzando un topologia hub e spoke con appliance centralizzate:
Come mostrato nel diagramma precedente, l'ANP agisce come livello di sicurezza perimetrale e funge da base per abilitare l'ispezione del traffico in linea. Inoltre, applica criteri di controllo dell'accesso rigorosi. Per ispezionare i flussi di traffico est-ovest e nord-sud, la progettazione di un'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 dei microservizi discussa nella sezione Pattern di mirroring è applicabile anche a questo pattern di architettura.
La differenza fondamentale tra questo pattern e il pattern speculare è che il modello di comunicazione in Google Cloud e in altri ambienti possono essere avviati da entrambi i lati. Il traffico deve essere controllato e granulare, in base ai requisiti di sicurezza e dell'applicazione che utilizza Service Mesh.
Best practice per i pattern a maglie
- Prima di fare qualsiasi altra cosa, decidi la struttura della gerarchia delle risorse e la progettazione necessaria per supportare qualsiasi progetto e VPC. In questo modo, puoi selezionare l'architettura di rete ottimale in linea con la struttura dei tuoi progetti Google Cloud.
- Utilizza un architettura distribuita Zero Trust quando utilizzi Kubernetes nel tuo ambiente di computing privato in Google Cloud.
- Quando utilizzi le VM centralizzate nella progettazione, devi definire più segmenti con diversi livelli di traffico e controlli di accesso di sicurezza criteri di ispezione. Basati su questi controlli e criteri in base ai requisiti di sicurezza delle tue applicazioni.
- Quando progetti una soluzione che include NVA, è importante prendere in considerazione l'alta disponibilità (HA) delle NVA per evitare un singolo punto di errore che potrebbe bloccare tutte le comunicazioni. Segui la progettazione di alta disponibilità e ridondanza e all'implementazione fornite dal Fornitore di sicurezza Google Cloud che fornisce le VNA.
- Per garantire una maggiore privacy, l'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 VPC condiviso con Apigee nello stesso organizzazione risorsa.
- Se la progettazione della tua soluzione richiede l'esposizione di un'applicazione basata su Google Cloud all'internet pubblico, prendi in considerazione i consigli di progettazione descritti in Networking per l'implementazione di applicazioni rivolte a internet.
- Per contribuire a proteggere i servizi Google Cloud 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. Inoltre, puoi estendere i perimetri dei servizi a un ambiente ibrido tramite una VPN o Cloud Interconnect autorizzata. Per saperne di più sui vantaggi dei perimetri di servizio, consulta la Panoramica dei Controlli di servizio VPC.
- Consulta le best practice generali per i pattern di networking ibrida e multicloud.
Se intendi applicare un isolamento più rigido e un accesso più granulare tra le tue applicazioni ospitate in Google Cloud e in altre ambienti, valuta l'utilizzo di uno dei pattern con accesso limitato descritti negli altri documenti di questa serie.