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 accesso 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 continuità 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 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 firewall che utilizzi devono consentire il traffico tra indirizzi IP specifici le origini degli indirizzi e le destinazioni in base ai requisiti dei applicazioni per le quali è stato 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 al loro interno.
Architettura
Il seguente diagramma illustra un'architettura di riferimento di alto livello 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 un singolo o più VPC condivisi o non condivisi. Per altri possibili progetti diverse di questo motivo, fai riferimento alle successive varianti di design. La la struttura selezionata dei tuoi VPC deve essere in linea con i progetti progettazione 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 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 tra cui:
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
- Usa un firewall centralizzato a livello di applicazione
- Architettura distribuita di microservizi Zero Trust
Un VPC per ambiente
I motivi più comuni per prendere in considerazione l'opzione un-VPC per ambiente sono che segue:
- 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 che forniscono l'isolamento della rete tra i diversi ambienti, un VPC condiviso per ogni ambiente disponibili in Google Cloud, come quelle di sviluppo, test e produzione.
- Requisiti di scalabilità che potrebbero dover andare oltre Quote VPC per un singolo VPC o progetto.
Come illustrato nel diagramma seguente, la progettazione con un singolo VPC per ambiente ogni VPC si integra direttamente con l'ambiente on-premise o un altro tramite VPN o Cloud Interconnect con più ambienti Collegamenti VLAN.
Il pattern visualizzato nel diagramma precedente può essere applicato a una zona di destinazione topologia di rete hub e spoke. In questa topologia, è possibile condividere una singola (o più) connessione ibrida in 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 NVA con funzionalità di ispezione del firewall di nuova generazione (NGFW) sul transito VPC, come descritto nella sezione successiva, "Usare un livello di applicazione centralizzato firewall".
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. A a implementare questi meccanismi, puoi estendere la topologia per passare il traffico cross-environment attraverso un firewall NVA centralizzato, come mostrato nell' nel seguente diagramma.
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 sia est-ovest che flussi di traffico nord-sud, la progettazione di un NVA centralizzato potrebbe includere più segmenti con diversi livelli di controlli di accesso per la 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 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 al e requisiti di sicurezza delle applicazioni Mesh di servizi.
Best practice per i pattern a mesh
- Prima di fare qualsiasi altra cosa, decidi progettazione della gerarchia delle risorse, e la progettazione necessaria per supportare qualsiasi progetto e VPC. Questo può essere d'aiuto selezioni l'architettura di networking ottimale in linea con 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. Basa questi controlli e criteri sulla sicurezza i requisiti delle tue applicazioni. Per ulteriori informazioni, vedi appliance di rete centralizzate su Google Cloud
Quando si progetta una soluzione che include le VVA, è importante considerare l'alta disponibilità (HA) delle VM per evitare single point of failure che potrebbero 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 account Google Cloud alla rete internet pubblica, considera il design consigli trattati in Networking per la distribuzione delle applicazioni per internet.
Per proteggere i servizi Google Cloud nei tuoi progetti e per per ridurre il rischio di esfiltrazione di dati, utilizza i Controlli di servizio VPC 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.
Esamina il best practice generali per 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 altre ambienti, valuta l'utilizzo di uno dei pattern con accesso limitato descritti negli altri documenti di questa serie.