Il modello a maglia si basa sull'implementazione 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 architetture. È applicabile anche alla progettazione della continuità aziendale per il provisioning di un ambiente di ripristino di emergenza (RE) in Google Cloud. In tutti i casi, è necessario collegare gli ambienti di calcolo in modo che siano in linea con 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 entrambi i lati. 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. Idealmente, puoi utilizzare un approccio di sicurezza a più livelli per limitare i flussi di traffico in modo granulare, sia tra che all'interno degli ambienti di calcolo.
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 altri ambienti di calcolo. Questi ambienti possono essere on-premise o in un altro cloud. Utilizza uno dei seguenti connettività di networking ibrida e multi-cloud che soddisfano i requisiti aziendali e dell'applicazione.
Limita le comunicazioni solo agli indirizzi IP consentiti delle tue origini e le destinazioni. Utilizza una delle seguenti funzionalità o una combinazione di queste:
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 o il routing della rete.
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 del dominio amministrativo, questa può essere combinata anche 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 andare oltre 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 e gli altri 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, tale NVA deve soddisfare le esigenze di sicurezza dell'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'NVA funge da livello di sicurezza perimetrale e costituisce la base per attivare 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 dei microservizi Zero Trust
Quando si utilizzano applicazioni containerizzate, i microservizi Zero Trust un'architettura distribuita, discussa nei pattern speculare è applicabile anche a questo modello di architettura.
La differenza principale tra questo pattern e quello speculare è che il modello di comunicazione tra i carichi di lavoro in Google Cloud e in altri ambienti può essere avviato da entrambi i lati. Il traffico deve essere controllato e granulare, in base al e requisiti di sicurezza delle applicazioni Mesh di servizi.
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 una architettura distribuita zero trust quando utilizzi Kubernetes nel tuo ambiente di calcolo privato e 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 una di comunicazione, esporre le applicazioni tramite API utilizzando gateway API, Mi piace Apigee e Apigee ibrido 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, lattina estendere i perimetri di servizio in un ambiente ibrido su VPN o Cloud Interconnect autorizzata. Per ulteriori informazioni sui vantaggi dei perimetri di servizio, consulta 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.