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 alla comunicazione unidirezionale in base ai requisiti di sicurezza delle applicazioni. Questo pattern di networking si applica principalmente alle architetture ibride a livelli, multi-cloud partizionate o bursting. È applicabile anche alla progettazione della continuità aziendale per eseguire il provisioning di un ambiente di ripristino di emergenza (RE) in Google Cloud. In tutti i casi, è necessario connettere gli ambienti di computing in modo che siano in linea con i seguenti requisiti di comunicazione:
- I carichi di lavoro possono comunicare tra loro attraverso i confini dell'ambiente, usando indirizzi IP RFC 1918 privati.
- La comunicazione può essere avviata da entrambi i lati. Le specifiche 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 riportate di seguito.
- 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, è 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 mesh.
- Tutti gli ambienti devono utilizzare uno spazio di indirizzi IP RFC 1918 senza sovrapposizione.
- Sul lato Google Cloud, puoi eseguire il deployment dei carichi di lavoro in uno o più VPC condivisi o VPC non condivisi. Per altre possibili opzioni di progettazione di questo motivo, fai riferimento alle seguenti varianti di design. La struttura selezionata dei VPC deve essere in linea con 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 multi-cloud che soddisfano i requisiti aziendali e delle 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 funzionalità di ispezione del firewall di nuova generazione (NGFW), collocata nel percorso di rete.
Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS) per implementare l'ispezione approfondita dei pacchetti al fine di prevenire le minacce senza modificare la progettazione della rete o il routing.
Varianti
Il pattern di architettura mesh può essere combinato con altri approcci per soddisfare diversi requisiti di progettazione, pur continuando a considerare i requisiti di comunicazione del pattern. Le opzioni per i pattern sono descritte nelle sezioni seguenti:
- Un VPC per ambiente
- Usa un firewall centralizzato a livello di applicazione
- Architettura distribuita di microservizi Zero Trust
Un VPC per ambiente
Ecco i motivi più comuni per prendere in considerazione l'opzione one-VPC-per-environment:
- L'ambiente cloud richiede una separazione a livello di rete delle reti e delle risorse VPC, in linea con la progettazione della gerarchia delle risorse dell'organizzazione.
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 l'isolamento della rete tra i diversi ambienti, utilizza un VPC condiviso per ogni ambiente in Google Cloud, ad esempio sviluppo, test e produzione.
- Scala i requisiti che potrebbero dover superare le quote di VPC per un singolo VPC o progetto.
Come illustrato nel diagramma seguente, la progettazione con un singolo VPC per ambiente consente a ogni VPC di integrarsi direttamente con l'ambiente on-premise o con altri ambienti cloud tramite VPN o con Cloud Interconnect con più collegamenti VLAN.
Il pattern visualizzato nel diagramma precedente può essere applicato a una topologia di rete hub e spoke di una zona di destinazione. In questa topologia, una singola (o più) connessione ibrida può essere condivisa con tutti i VPC spoke. Viene condiviso utilizzando un VPC di transito per terminare sia la connettività ibrida che gli altri VPC spoke. Puoi anche espandere questa progettazione aggiungendo NVA con funzionalità di ispezione del firewall di nuova generazione (NGFW) presso il VPC di transito, come descritto nella sezione successiva, "Usa 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 delle applicazioni (livello 7) e l'ispezione approfondita dei pacchetti con funzionalità di firewall avanzate che superano le capacità del firewall di nuova generazione Cloud, puoi utilizzare un'appliance NGFW ospitata in un AVA. Tuttavia, tale NVA deve soddisfare le esigenze di sicurezza dell'organizzazione. Per implementare questi meccanismi, puoi estendere la topologia in modo da passare tutto il traffico cross-environment attraverso un firewall NVA centralizzato, come mostrato nel diagramma seguente.
Puoi applicare il pattern nel seguente diagramma alla progettazione della zona di destinazione utilizzando una topologia hub e raggi con appliance centralizzate:
Come mostrato nel diagramma precedente, NVA funge da livello di sicurezza perimetrale e funge da base per consentire l'ispezione del traffico in linea. Applica inoltre criteri rigidi di controllo dell'accesso. Per ispezionare i flussi di traffico sia da est a ovest che da nord-sud, la progettazione di un NVA centralizzato potrebbe includere più segmenti con diversi livelli di controlli di accesso alla sicurezza.
Architettura distribuita dei microservizi Zero Trust
Quando si utilizzano applicazioni containerizzate, a questo pattern di architettura è applicabile anche l'architettura distribuita del protocollo Zero Trust di microservizi, descritta nella sezione relativa al pattern con mirroring.
La differenza fondamentale tra questo pattern e il pattern con mirroring è 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 ai requisiti delle applicazioni e ai requisiti di sicurezza utilizzando Mesh di servizi.
Best practice per i pattern a mesh
- Prima di fare qualsiasi altra cosa, decidi la progettazione della gerarchia delle risorse e la progettazione necessaria per supportare qualsiasi progetto e VPC. In questo modo puoi selezionare l'architettura di networking 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 e Google Cloud.
Quando utilizzi VNA centralizzate nella progettazione, devi definire più segmenti con diversi livelli di controlli di accesso di sicurezza e criteri di ispezione del traffico. Basa questi controlli e criteri sui requisiti di sicurezza delle tue applicazioni. Per ulteriori informazioni, consulta Appliance di rete centralizzate su Google Cloud.
Quando si progetta una soluzione che include le VM a elevata disponibilità, è importante considerare l'alta disponibilità per evitare un single point of failure che potrebbe bloccare tutte le comunicazioni. Segui le linee guida per la progettazione e l'implementazione di alta disponibilità e ridondanza fornite dal fornitore di servizi di sicurezza di Google Cloud che fornisce le tue AVA.
Per fornire maggiore privacy, integrità dei dati e un modello di comunicazione controllato, esponi le applicazioni tramite API utilizzando gateway API, come Apigee e Apigee ibrido con mTLS end-to-end. Puoi anche utilizzare un VPC condiviso con Apigee nella stessa risorsa dell'organizzazione.
Se la progettazione della tua soluzione richiede l'esposizione di un'applicazione basata su Google Cloud alla rete internet pubblica, considera i suggerimenti di progettazione discussi in Networking per la distribuzione di applicazioni per internet.
Per proteggere i servizi Google Cloud nei tuoi progetti e ridurre il rischio di esfiltrazione di dati, utilizza Controlli di servizio VPC per specificare i perimetri di servizio a livello di progetto o di rete VPC. Inoltre, puoi estendere i perimetri di servizio a un ambiente ibrido su una VPN autorizzata o Cloud Interconnect. 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 ibridi e multi-cloud.
Se intendi applicare un isolamento più rigido e un accesso più granulare tra le tue applicazioni ospitate in Google Cloud e in altri ambienti, valuta l'utilizzo di uno dei pattern con accesso limitato descritti negli altri documenti di questa serie.