Motivo a maglie

Last reviewed 2025-01-23 UTC

Il modello a maglia si basa sull'implementazione di un'architettura di rete ibrida. Questa architettura si estende su più ambienti di calcolo. 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 modello di rete si applica principalmente alle architetture ibride a più livelli, multi-cloud partizionato o bursting. È applicabile anche al design 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 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 descritti nelle opzioni di progettazione 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.

I dati in un'architettura di rete ibrida fluiscono da due subnet in Google Cloud a un carico di lavoro in un ambiente on-premise.

  • Tutti gli ambienti devono utilizzare uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.
  • Google Cloud Puoi implementare i 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 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:

    • Regole firewall o criteri firewall.

    • 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 a maglia 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:

Una VPC per ambiente

Ecco alcuni dei motivi più comuni per prendere in considerazione l'opzione di una VPC per ambiente:

  • L'ambiente cloud richiede la separazione a livello di rete delle reti e delle risorse VPC, in linea con il design della gerarchia delle risorse della tua organizzazione. Se è necessaria la separazione del dominio amministrativo, questa può essere combinata anche con un progetto distinto 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.
  • Requisiti di scalabilità che potrebbero dover superare le quote VPC per un singolo VPC o progetto.

Come illustrato nel diagramma seguente, 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.

I dati in un'architettura di rete ibrida con un VPC in ogni ambiente fluiscono da due subnet in Google Cloud a un carico di lavoro in un ambiente on-premise.

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".

Utilizza un firewall a livello di applicazione centralizzato

Se i tuoi requisiti tecnici richiedono di prendere in considerazione il livello di applicazione (livello 7) e l'analisi approfondita dei pacchetti con funzionalità di firewalling avanzate che superano le funzionalità di Cloud Next Generation Firewall, puoi utilizzare un'appliance NGFW ospitata in un'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 al design della landing zone utilizzando una topologia hub and spoke con appliance centralizzati:

I dati di due VPC condivise in Google Cloud passano attraverso un NVA a una rete VPC di transito fino a un carico di lavoro in un ambiente on-premise.

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 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 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 ai requisiti di sicurezza e delle applicazioni che utilizzano Service Mesh.

Best practice per i pattern a maglie

  • Prima di fare qualsiasi altra cosa, decidi la gerarchia delle risorse e il design necessario 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 una architettura distribuita zero trust quando utilizzi Kubernetes nel tuo ambiente di calcolo privato e Google Cloud.
  • Quando utilizzi NVA centralizzate nel tuo design, devi definire più segmenti con diversi livelli di controlli di accesso alla sicurezza e criteri di ispezione del traffico. 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 le linee guida per la progettazione e l'implementazione dell'HA e della ridondanza fornite dal Google Cloud fornitore di soluzioni di sicurezza che fornisce le NVA.
  • 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 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 all'internet pubblico, prendi in considerazione i consigli di progettazione discussi in Networking per l'implementazione di applicazioni rivolte a internet.
  • Per contribuire a proteggere i Google Cloud servizi nei tuoi progetti e per 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ù rigoroso e un accesso più granulare tra le tue applicazioni ospitate in Google Cloude in altri ambienti, valuta la possibilità di utilizzare uno dei modelli con accesso controllato descritti negli altri documenti di questa serie.