Modelli di architettura di rete sicura ibrida e multi-cloud

Last reviewed 2025-01-23 UTC

Questa pagina fornisce una visualizzazione in un'unica pagina di tutte le pagine di Creare architetture ibride e multi-cloud utilizzando Google Cloud. Puoi stampare questa pagina o salvarla in formato PDF utilizzando la funzione di stampa del browser e scegliendo l'opzione Salva come PDF. Questa pagina non fornisce un riquadro del sommario sul lato destro.

Questo documento è il terzo di tre documenti in un insieme. Vengono descritti i modelli di architettura di rete ibrida e multi-cloud. Questa parte illustra diversi modelli di architettura di rete sicura che puoi utilizzare per le architetture ibride e multicloud. Descrive gli scenari per i quali questi schemi di reti sono più adatti e fornisce le best practice per implementarli con Google Cloud.

Il set di documenti per i modelli di architettura ibrida e multi-cloud è costituito da queste parti:

• Crea architetture ibride e multi-cloud: discute la pianificazione di una strategia per l'architettura di una configurazione ibrida e multi-cloud con Google Cloud.
• Modelli di architettura ibrida e multi-cloud: discute i modelli di architettura comuni da adottare nell'ambito di una strategia ibrida e multi-cloud.
• Modelli di architettura di rete sicura ibrida e multi-cloud: vengono descritti i modelli di architettura di rete ibrida e multi-cloud dal punto di vista della rete (questo documento).

La connessione di ambienti di calcolo privati in modo Google Cloud sicuro e affidabile è essenziale per qualsiasi architettura ibrida e multi-cloud di successo. La connettività di rete ibrida e il modello di architettura di rete cloud che scegli per una configurazione ibrida e multi-cloud devono soddisfare i requisiti specifici dei carichi di lavoro aziendali. Inoltre, deve essere adatto ai pattern di architettura che intendi applicare. Sebbene tu debba personalizzare ogni design, esistono pattern comuni che puoi utilizzare come modello.

I pattern di architettura di rete in questo documento non devono essere considerati alternativi al design della zona di destinazione in Google Cloud. Devi invece progettare ed eseguire il deployment dei pattern di architettura selezionati nell'ambito del Google Cloud design complessivo della zona di destinazione, che copre le seguenti aree:

• Identità
• Gestione delle risorse
• Sicurezza
• Networking
• Monitoraggio

Applicazioni diverse possono utilizzare pattern di architettura di rete diversi, che vengono incorporati nell'ambito di un'architettura della landing zone. In una configurazione multicloud, devi mantenere la coerenza del design della zona di destinazione in tutti gli ambienti.

Questa serie contiene le seguenti pagine:

• Considerazioni sul design
• Modelli di architettura
  • Motivo speculare
  • Motivo a maglie
  • Modelli con accesso riservato
    • Traffico in uscita soggetto a restrizioni
    • Ingresso con cancello
    • In entrata e in uscita con accesso riservato
  • Trasferimento
• Best practice generali

Collaboratori

Autore: Marwan Al Shawi | Partner Customer Engineer

Altri collaboratori:

• Saud Albazei | Customer Engineer, Application Modernization
• Anna Berenberg | Engineering Fellow
• Marco Ferrari | Cloud Solutions Architect
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Cloud Solutions Architect
• Mark Schlagenhauf | Technical Writer, Networking
• Daniel Strebel | Solution Lead EMEA, Application Modernization
• Ammett Williams | Developer Relations Engineer

Pattern di architettura

I documenti di questa serie illustrano i pattern di architettura di rete progettati in base ai modelli di comunicazione richiesti tra le applicazioni che si trovano in Google Cloud e in altri ambienti (on-premise, in altri cloud o entrambi).

Questi pattern devono essere incorporati nell'architettura complessiva della zona di destinazione dell'organizzazione, che può includere più pattern di rete per soddisfare i requisiti specifici di comunicazione e sicurezza di diverse applicazioni.

I documenti di questa serie illustrano anche le diverse varianti di progettazione che possono essere utilizzate con ogni pattern di architettura. I seguenti schemi di networking possono aiutarti a soddisfare i requisiti di comunicazione e sicurezza per le tue applicazioni:

• Motivo speculare
• Motivo a maglie
• Modelli con accesso riservato
  • Traffico in uscita soggetto a restrizioni
  • Ingresso con cancello
  • Uscita e ingresso con accesso riservato
• Modello di passaggio di consegne

Motivo speculare

Il pattern in mirror si basa sulla replica del design di uno o più ambienti esistenti in uno o più ambienti nuovi. Pertanto, questo pattern si applica principalmente alle architetture che seguono il pattern ambiente ibrido. In questo modello, esegui i carichi di lavoro di sviluppo e test in un ambiente e quelli di gestione temporanea e produzione in un altro.

Il pattern speculare presuppone che i workload di test e di produzione non debbano comunicare direttamente tra loro. Tuttavia, dovrebbe essere possibile gestire ed eseguire il deployment di entrambi i gruppi di carichi di lavoro in modo coerente.

Se utilizzi questo pattern, collega i due ambienti di calcolo in modo che siano in linea con i seguenti requisiti:

• L'integrazione e il deployment continui (CI/CD) possono eseguire il deployment e gestire i carichi di lavoro in tutti gli ambienti di calcolo o in ambienti specifici.
• Il monitoraggio, la gestione della configurazione e altri sistemi amministrativi devono funzionare in tutti gli ambienti di calcolo.
• I carichi di lavoro non possono comunicare direttamente tra ambienti di calcolo. Se necessario, la comunicazione deve essere granulare e controllata.

Architettura

Il seguente diagramma dell'architettura mostra un'architettura di riferimento di alto livello di questo pattern che supporta CI/CD, monitoraggio, gestione della configurazione, altri sistemi amministrativi e comunicazione dei carichi di lavoro:

La descrizione dell'architettura nel diagramma precedente è la seguente:

• I carichi di lavoro vengono distribuiti in base agli ambienti funzionali (sviluppo, test, CI/CD e strumenti amministrativi) in VPC distinte Google Cloud .
• La VPC condivisa viene utilizzata per i carichi di lavoro di sviluppo e test. Viene utilizzata un'altra VPC per gli strumenti di CI/CD e di amministrazione. Con i VPC condivisi:
  • Le applicazioni sono gestite da team diversi per ambiente e per progetto di servizio.
  • Il progetto host amministra e controlla i controlli di sicurezza e di comunicazione di rete tra gli ambienti di sviluppo e di test, nonché all'esterno del VPC.
• La VPC CI/CD è connessa alla rete su cui vengono eseguiti i carichi di lavoro di produzione nel tuo ambiente di calcolo privato.
• Le regole del firewall consentono solo il traffico consentito.
  • Puoi anche utilizzare 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 o il routing. Cloud Next Generation Firewall Enterprise funziona creando endpoint di firewall zonali gestiti da Google che utilizzano la tecnologia di intercettazione dei pacchetti per ispezionare in modo trasparente i workload alla ricerca delle firme di minacce configurate. Inoltre, protegge i carichi di lavoro dalle minacce.
• Consente la comunicazione tra i VPC accoppiati utilizzando indirizzi IP interni.
  • Il peering in questo pattern consente ai sistemi di CI/CD e amministrativi di eseguire il deployment e gestire i carichi di lavoro di sviluppo e test.
• Prendi in considerazione queste best practice generali.

Stabilisci questa connessione CI/CD utilizzando una delle opzioni di connettività di rete ibrida e multicloud discusse che soddisfano i requisiti della tua attività e delle tue applicazioni. Per consentirti di eseguire il deployment e gestire i carichi di lavoro di produzione, questa connessione fornisce la raggiungibilità della rete privata tra i diversi ambienti di calcolo. Tutti gli ambienti devono avere uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.

Se le istanze negli ambienti di sviluppo e test richiedono accesso a internet, valuta le seguenti opzioni:

• Puoi eseguire il deployment di Cloud NAT nella stessa rete del progetto host VPC condiviso. Il deployment nella stessa rete del progetto host VPC condiviso consente di evitare di rendere queste istanze direttamente accessibili da internet.
• Per il traffico web in uscita, puoi utilizzare Secure Web Proxy. Il proxy offre diversi vantaggi.

Per ulteriori informazioni sulle Google Cloud funzionalità e sugli strumenti che ti aiutano a creare, testare e implementare in Google Cloud e in ambienti ibridi e multicloud, consulta il blog DevOps e CI/CD su Google Cloud spiegati.

Varianti

Per soddisfare diversi requisiti di progettazione, tenendo conto di tutti i requisiti di comunicazione, il pattern di architettura speculare offre le seguenti opzioni, descritte nelle sezioni seguenti:

• VPC condiviso per ambiente
• Firewall a livello di applicazione centralizzato
• Topologia hub and spoke
• Architettura distribuita Zero Trust basata su microservizi

VPC condiviso per ambiente

L'opzione di progettazione VPC condiviso per ambiente consente la separazione a livello di applicazione o servizio tra gli ambienti, inclusi gli strumenti di CI/CD e amministrativi che potrebbero essere necessari per soddisfare determinati requisiti di sicurezza dell'organizzazione. Questi requisiti limitano la comunicazione, il dominio amministrativo e il controllo dell'accesso per diversi servizi che devono essere gestiti anche da team diversi.

Questo design consente la separazione grazie all'isolamento a livello di rete e di progetto tra i diversi ambienti, il che consente un controllo più granulare della comunicazione e dell'accesso con Identity and Access Management (IAM).

Dal punto di vista della gestione e delle operazioni, questo design offre la flessibilità di gestire le applicazioni e i carichi di lavoro creati da team diversi per ambiente e per progetto di servizio. Il networking VPC e le relative funzionalità di sicurezza possono essere di cui è possibile eseguire il provisioning e la gestione da parte dei team di operazioni di rete in base alle seguenti strutture possibili:

• Un team gestisce tutti i progetti host in tutti gli ambienti.
• Team diversi gestiscono i progetti host nei rispettivi ambienti.

Le decisioni relative alla gestione dei progetti host devono essere basate sulla struttura del team, sulle operazioni di sicurezza e sui requisiti di accesso di ciascun team. Puoi applicare questa variazione di progettazione alla rete VPC condivisa per ogni opzione di progettazione della zona di destinazione dell'ambiente. Tuttavia, devi considerare i requisiti di comunicazione del pattern mirrored per definire quali comunicazioni sono consentite tra i diversi ambienti, inclusa la comunicazione sulla rete ibrida.

Puoi anche eseguire il provisioning di una rete VPC condivisa per ogni ambiente principale, come illustrato nel seguente diagramma:

Firewall a livello di applicazione centralizzato

In alcuni scenari, i requisiti di sicurezza potrebbero richiedere l'utilizzo del livello di applicazione (livello 7) e dell'ispezione approfondita dei pacchetti con meccanismi di firewalling avanzati che superano le funzionalità di Cloud Next Generation Firewall. Per soddisfare i requisiti e gli standard di sicurezza della tua organizzazione, puoi utilizzare un'appliance NGFW in hosting in un'appliance virtuale di rete (NVA). Diversi Google Cloud partner per la sicurezza offrono opzioni adatte a questa attività.

Come illustrato nel seguente diagramma, puoi posizionare l'NVA nel percorso di rete tra Virtual Private Cloud e l'ambiente di calcolo privato utilizzando più interfacce di rete.

Questo design può essere utilizzato anche con più VPC condivisi, come illustrato nel seguente diagramma.

L'NVA in questo design funge da livello di sicurezza del perimetro. Inoltre, funge da base per attivare l'ispezione del traffico in linea e applicare criteri di controllo dell'accesso rigorosi.

Per una strategia di sicurezza multilivello solida che includa regole firewall VPC e funzionalità di servizi di prevenzione delle intrusioni, includi ulteriori ispezioni del traffico e controlli di sicurezza per i flussi di traffico est-ovest e nord-sud.

Nota: nelle regioni cloud supportate e se tecnicamente fattibile per il tuo progetto, le NVA possono essere implementate senza richiedere più reti VPC o interfacce di appliance. Questo deployment si basa sull'utilizzo delle funzionalità di bilanciamento del carico e routing basato su criteri. Queste funzionalità consentono un meccanismo indipendente dalla topologia e basato su criteri per integrare le NVA nella rete cloud. Per maggiori dettagli, consulta Eseguire il deployment di appliance virtuali di rete (NVA) senza più VPC.

Topologia hub and spoke

Un'altra possibile variante di progettazione è utilizzare VPC distinti (inclusi VPC condivisi) per lo sviluppo e le diverse fasi di test. In questa variante, come mostrato nel diagramma seguente, tutti gli ambienti di fase si connettono al CI/CD e alla VPC amministrativa in un'architettura hub and spoke. Utilizza questa opzione se devi separare i domini amministrativi e le funzioni in ogni ambiente. Il modello di comunicazione hub-and-spoke può essere utile per i seguenti requisiti:

• Le applicazioni devono accedere a un insieme comune di servizi, come monitoraggio, strumenti di gestione della configurazione, CI/CD o autenticazione.
• Un insieme comune di criteri di sicurezza deve essere applicato al traffico in entrata e in uscita in modo centralizzato tramite l'hub.

Per ulteriori informazioni sulle opzioni di progettazione hub-and-spoke, consulta Topologia hub-and-spoke con appliance centralizzati e Topologia hub-and-spoke senza appliance centralizzati.

Come mostrato nel diagramma precedente, la comunicazione tra VPC e la connettività ibrida passano tutte attraverso il VPC hub. Nell'ambito di questo pattern, puoi controllare e limitare la comunicazione nella VPC hub in modo che sia in linea con i tuoi requisiti di connettività.

Nell'ambito dell'architettura di rete hub-and-spoke, le opzioni di connettività principali (tra gli spoke e le VPC hub) sono le seguenti Google Cloud:

• Peering di rete VPC
• VPN
• Utilizzo di un'appliance virtuale di rete (NVA)
  • Con più interfacce di rete
  • Con Network Connectivity Center (NCC)

Per ulteriori informazioni sull'opzione da considerare nel tuo design, consulta Architettura di rete hub-and-spoke. Un fattore chiave che influisce sulla scelta della VPN rispetto al peering VPC tra gli spoke e il VPC hub è quando è richiesta la transitività del traffico. La transitività del traffico indica che il traffico da uno spoke può raggiungere altri spoke tramite l'hub.

Architettura distribuita Zero Trust dei microservizi

Le architetture ibride e multi-cloud possono richiedere più cluster per raggiungere i loro obiettivi tecnici e commerciali, inclusa la separazione dell'ambiente di produzione dagli ambienti di sviluppo e test. Pertanto, i controlli di sicurezza del perimetro di rete sono importanti, soprattutto se sono necessari per rispettare determinati requisiti di sicurezza.

Non è sufficiente supportare i requisiti di sicurezza delle attuali architetture di microservizi distribuite cloud-first, ma devi anche prendere in considerazione le architetture distribuite Zero Trust. L'architettura distribuita Zero Trust dei microservizi supporta l'architettura dei microservizi con l'applicazione dei criteri di sicurezza a livello di microservizio, l'autenticazione e l'identità del carico di lavoro. La attendibilità è basata sull'identità e applicata per ogni servizio.

Utilizzando un'architettura proxy distribuita, come un mesh di servizi, i servizi possono verificare in modo efficace gli utenti chiamanti e implementare criteri di controllo dell'accesso granulari per ogni richiesta, consentendo un ambiente di microservizi più sicuro e scalabile. Cloud Service Mesh ti offre la flessibilità di avere un mesh comune che può includere i deploymentGoogle Cloud e on-premise. Il mesh utilizza i criteri di autorizzazione per contribuire a proteggere le comunicazioni da servizio a servizio.

Con questa architettura puoi anche incorporare Apigee Adapter for Envoy, che è un deployment di Apigee API Gateway in un cluster Kubernetes. Apigee Adapter for Envoy è un proxy di servizi ed edge open source progettato per le applicazioni cloud-first.

Per ulteriori informazioni su questo argomento, leggi i seguenti articoli:

• Architettura distribuita Zero Trust
• Ambiente ibrido GKE Enterprise
• Connetti a Google
  • Connetti un cluster GKE Enterprise on-premise a una Google Cloud rete.
• Configurare un mesh multi-cloud o ibrido
  • Esegui il deployment di Cloud Service Mesh in ambienti e cluster.

Best practice per i pattern speculari

• I sistemi CI/CD necessari per il deployment o la riconfigurazione dei deployment di produzione devono essere altamente disponibili, il che significa che tutti i componenti dell'architettura devono essere progettati per fornire il livello previsto di disponibilità del sistema. Per ulteriori informazioni, consulta la sezione sull'Google Cloud affidabilità dell'infrastruttura.
• Per eliminare gli errori di configurazione per processi ripetuti come gli aggiornamenti del codice, l'automazione è essenziale per standardizzare le build, i test e i deployment.
• L'integrazione di NVA centralizzate in questo design potrebbe richiedere l'incorporazione di più segmenti con diversi livelli di controlli di accesso di sicurezza.
• 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 indicazioni per la progettazione e l'implementazione dell'HA e della ridondanza fornite dal fornitore dell'NVA.
• Se non esporti le route IP on-premise tramite il peering VPC o la VPN nella VPC di sviluppo e test, puoi limitare la connettività di rete dagli ambienti di sviluppo e test all'ambiente on-premise. Per maggiori informazioni, consulta la sezione Scambio di route personalizzate con il peering di rete VPC.
• Per i carichi di lavoro con indirizzi IP privati che possono richiedere l'accesso alle API di Google, puoi esporre le API di Google utilizzando un endpoint Private Service Connect all'interno di una rete VPC. Per ulteriori informazioni, consulta Ingresso con cancello, in questa serie.
• Consulta le best practice generali per i modelli di architettura di rete ibrida e multicloud.

Motivo a maglie

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.

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

• Un VPC per ambiente
• Utilizzare un firewall a livello di applicazione centralizzato
• Architettura distribuita Zero Trust basata su microservizi

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.

Il pattern mostrato nel diagramma precedente può essere applicato a una topologia di rete hub-and-spoke della landing zone. 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:

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 nella progettazione, 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.

Pattern con cancello

Il pattern gated si basa su un'architettura che espone applicazioni e servizi selezionati in modo granulare, in base ad API o endpoint esposti specifici tra i diversi ambienti. Questa guida suddivide questo schema in tre possibili opzioni, ciascuna determinata dal modello di comunicazione specifico:

• Traffico in uscita soggetto a restrizioni

• Ingresso con cancello

• In entrata e in uscita con controllo (controllo bidirezionale in entrambe le direzioni)

Come accennato in precedenza in questa guida, gli schemi di architettura di rete descritti qui possono essere adattati a varie applicazioni con requisiti diversi. Per soddisfare le esigenze specifiche di diverse applicazioni, l'architettura della zona di destinazione principale potrebbe incorporare contemporaneamente un pattern o una combinazione di pattern. Il deployment specifico dell'architettura selezionata è determinato dai requisiti di comunicazione specifici di ciascun pattern con accesso controllato.

Nota: in generale, il pattern con accesso controllato può essere applicato o incorporato con l'opzione di progettazione della zona di destinazione che espone i servizi in un modello di consumatore-produttore.

Questa serie illustra ogni pattern con controllo e le relative opzioni di progettazione. Tuttavia, un'opzione di progettazione comune applicabile a tutti i pattern con controlli è l'architettura distribuita Zero Trust per le applicazioni containerizzate con architettura di microservizi. Questa opzione è basata su Cloud Service Mesh, Apigee e Apigee Adapter for Envoy, un deployment di gateway Apigee leggero all'interno di un cluster Kubernetes. Apigee Adapter for Envoy è un proxy di servizi e di edge open source molto utilizzato, progettato per le applicazioni cloud-first. Questi controlli dell'architettura hanno consentito comunicazioni tra servizi sicure e la direzione della comunicazione a livello di servizio. I criteri di comunicazione del traffico possono essere progettati, perfezionati e applicati a livello di servizio in base al pattern selezionato.

I pattern con controllo consentono l'implementazione di Cloud Next Generation Firewall Enterprise con il servizio di prevenzione delle intrusioni (IPS) per eseguire l'ispezione approfondita dei pacchetti per la prevenzione delle minacce senza alcuna modifica di progettazione o routing. Questa ispezione è soggetta alle applicazioni specifiche a cui viene eseguito l'accesso, al modello di comunicazione e ai requisiti di sicurezza. Se i requisiti di sicurezza richiedono il livello 7 e l'ispezione approfondita dei pacchetti con meccanismi di firewalling avanzati che superano le funzionalità di Cloud Next Generation Firewall, puoi utilizzare un NGFW (Next Generation Firewall) centralizzato in hosting in un'appliance virtuale di rete (NVA). Diversi Google Cloud partner per la sicurezza offrono appliance NGFW in grado di soddisfare i tuoi requisiti di sicurezza. L'integrazione di NVA con questi pattern con controlli può richiedere l'introduzione di più zone di sicurezza all'interno della progettazione della rete, ciascuna con livelli di controllo dell'accesso distinti.

Traffico in uscita con accesso controllato

L'architettura del pattern di rete Uscita controllata si basa sull'esposizione di API selezionate dall'ambiente on-premise o da un altro ambiente cloud ai carichi di lavoro di cui è stato eseguito il deployment in Google Cloud. Ciò avviene senza esporli direttamente alla rete internet pubblica da un ambiente on-premise o da altri ambienti cloud. Puoi facilitare questa esposizione limitata tramite un gateway o un proxy API oppure un bilanciatore del carico che funge da facade per i carichi di lavoro esistenti. Puoi eseguire il deployment della funzionalità del gateway API in un segmento di rete perimetrale isolato, ad esempio una rete perimetrale.

Il pattern di rete di uscita controllata si applica principalmente (ma non solo) ai pattern di architettura delle applicazioni a più livelli e ai pattern di architettura delle applicazioni partizionate. Quando esegui il deployment dei carichi di lavoro di backend all'interno di una rete interna, la rete di uscita gated contribuisce a mantenere un livello di sicurezza più elevato all'interno del tuo ambiente di calcolo on-premise. Il pattern richiede di collegare gli ambienti di calcolo in modo da soddisfare i seguenti requisiti di comunicazione:

• I carichi di lavoro di cui esegui il deployment in Google Cloud possono comunicare con il gateway API o il bilanciatore del carico (o un endpoint Private Service Connect) che espone l'applicazione utilizzando indirizzi IP interni.
• Non è possibile raggiungere altri sistemi nell'ambiente di calcolo privato direttamente dall'interno Google Cloud.
• La comunicazione dall'ambiente di calcolo privato a qualsiasi workload impiegato in Google Cloud non è consentita.
• Il traffico verso le API private in altri ambienti viene avviato solo dall' Google Cloud ambiente.

Questa guida si concentra sugli ambienti ibridi e multi-cloud collegati tramite una rete ibrida privata. Se i requisiti di sicurezza della tua organizzazione lo consentono, le chiamate API alle API target remote con indirizzi IP pubblici possono essere raggiunte direttamente tramite internet. Tuttavia, devi considerare i seguenti meccanismi di sicurezza:

• API OAuth 2.0 con Transport Layer Security (TLS).
• Limitazione di frequenza.
• Criteri di protezione dalle minacce.
• TLS reciproco configurato nel backend del livello API.
• Filtro della lista consentita degli indirizzi IP configurato per consentire la comunicazione solo con origini e destinazioni API predefinite da entrambi i lati.

Per proteggere un proxy API, prendi in considerazione questi altri aspetti di sicurezza. Per saperne di più, consulta le best practice per la protezione di applicazioni e API utilizzando Apigee.

Architettura

Il seguente diagramma mostra un'architettura di riferimento che supporta i requisiti di comunicazione elencati nella sezione precedente:

I dati passano attraverso il diagramma precedente come segue:

• Google Cloud D'altra parte, puoi eseguire il deployment dei carichi di lavoro in virtual private cloud (VPC). Le VPC possono essere singole o multiple (condivise o non condivise). Il deployment deve essere in linea con i progetti e con il design della gerarchia delle risorse della tua organizzazione.
• Le reti VPC dell' Google Cloud ambiente vengono estese agli altri ambienti di calcolo. Gli ambienti possono essere on-premise o in un altro cloud. Per facilitare la comunicazione tra gli ambienti che utilizzano indirizzi IP interni, utilizza una connettività di rete ibrida e multi-cloud adeguata.

• Per limitare il traffico che proviene da indirizzi IP VPC specifici e è destinato a gateway o bilanciatori del carico remoti, utilizza il filtro della lista consentita di indirizzi IP. Il traffico di ritorno da queste connessioni è consentito se utilizzi regole firewall stateful. Puoi utilizzare qualsiasi combinazione delle seguenti funzionalità per proteggere e limitare le comunicazioni solo agli indirizzi IP di origine e di destinazione consentiti:

  • Regole firewall o criteri firewall.

  • Appliance virtuale di rete (NVA) con funzionalità di ispezione del firewall di nuova generazione (NGFW) posizionate nel percorso di rete.

  • Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS) per implementare l'ispezione approfondita dei pacchetti per la prevenzione delle minacce.

• Tutti gli ambienti condividono uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.

Varianti

Il pattern di architettura di uscita controllata può essere combinato con altri approcci per soddisfare requisiti di progettazione diversi che prendono comunque in considerazione i requisiti di comunicazione di questo pattern. Il pattern offre le seguenti opzioni:

• Utilizza Google Cloud API Gateway e il frontend globale
• Esporre servizi remoti utilizzando Private Service Connect

Utilizza Google Cloud API Gateway e il frontend globale

Con questo approccio di progettazione, l'esposizione e la gestione delle API risiedono inGoogle Cloud. Come mostrato nel diagramma precedente, puoi farlo tramite l'implementazione di Apigee come piattaforma API. La decisione di eseguire il deployment di un gateway API o di un bilanciatore del carico nell'ambiente remoto dipende dalle tue esigenze specifiche e dalla configurazione attuale. Apigee offre due opzioni per il provisioning della connettività:

• Con il peering VPC
• Senza peering VPC

Google Cloud Le funzionalità di frontend globali come Cloud Load Balancing, Cloud CDN (se si accede tramite Cloud Interconnect) e Cross-Cloud Interconnect migliorano la velocità con cui gli utenti possono accedere alle applicazioni i cui backend sono ospitati nei tuoi ambienti on-premise e in altri ambienti cloud.

L'ottimizzazione delle velocità di caricamento dei contenuti viene raggiunta pubblicando queste applicazioni da Google Cloud point of presence (POP). Google Cloud I POP sono presenti su oltre 180 centri di scambio internet e in oltre 160 strutture di interconnessione in tutto il mondo.

Per scoprire in che modo i PoP contribuiscono a fornire API ad alte prestazioni quando utilizzi Apigee con Cloud CDN per eseguire le seguenti operazioni, guarda Caricare API ad alte prestazioni con Apigee e Cloud CDN su YouTube:

• Riduci la latenza.
• Ospitare API a livello globale.
• Aumenta la disponibilità per i picchi di traffico.

L'esempio di progettazione illustrato nel diagramma precedente si basa su Private Service Connect senza peering VPC.

La rete in uscita in questo progetto viene stabilita tramite:

• Un bilanciatore del carico (LB nel diagramma), in cui terminano le richieste dei client, elabora il traffico e lo instrada a un backend Private Service Connect.
• Un backend di Private Service Connect consente a un Google Cloud bilanciatore del carico di inviare le richieste dei client tramite una connessione Private Service Connect associata a un collegamento di servizio del producer al servizio pubblicato (istanza di runtime Apigee) utilizzando gruppi di endpoint di rete (NEG) Private Service Connect.

Il networking verso sud viene stabilito tramite:

• Un endpoint Private Service Connect che fa riferimento a un collegamento di servizio associato a un bilanciatore del carico interno (ILB nel diagramma) nella VPC del cliente.

• L'LB viene disegnato con gruppi di endpoint di rete con connettività ibrida (NEG con connettività ibrida).

• Per accedere ai servizi ibridi è necessario utilizzare il NEG di connettività ibrida tramite una connettività di rete ibrida, come VPN o Cloud Interconnect.

Per ulteriori informazioni, consulta Configurare un bilanciatore del carico di rete proxy interno regionale con connettività ibrida e Pattern di implementazione di Private Service Connect.

Nota: a seconda dei requisiti, le API dei backend on-premise possono essere esposte tramite Apigee Hybrid, un proxy o un gateway API di terze parti o un bilanciatore del carico.

Esporre servizi remoti tramite Private Service Connect

Utilizza l'opzione Private Service Connect per esporre i servizi remoti per i seguenti scenari:

• Non utilizzi una piattaforma API o vuoi evitare di collegare la tua intera rete VPC direttamente a un ambiente esterno per i seguenti motivi:
  • Hai limitazioni di sicurezza o requisiti di conformità.
  • Esiste una sovrapposizione di intervalli di indirizzi IP, ad esempio in uno scenario di acquisizione e fusione.
• Per abilitare comunicazioni unidirezionali sicure tra client, applicazioni e servizi in tutti gli ambienti anche quando hai una scadenza breve.
• Potresti dover fornire connettività a più VPC consumer tramite una VPC di produzione di servizi (VPC di transito) per offrire modelli di servizio multi-tenant o mono-tenant altamente scalabili, in modo da raggiungere i servizi pubblicati in altri ambienti.

L'utilizzo di Private Service Connect per le applicazioni utilizzate come API fornisce un indirizzo IP interno per le applicazioni pubblicate, consentendo l'accesso sicuro all'interno della rete privata in più regioni e tramite connettività ibrida. Questa astrazione facilita l'integrazione delle risorse da diversi cloud e ambienti on-premise tramite un modello di connettività ibrida e multi-cloud. Puoi accelerare l'integrazione delle applicazioni ed esporre in modo sicuro le applicazioni che si trovano in un ambiente on-premise o in un altro ambiente cloud utilizzando Private Service Connect per pubblicare il servizio con accesso granulare. In questo caso, puoi utilizzare la seguente opzione:

• Un allegato del servizio che fa riferimento a un bilanciatore del carico di rete proxy interno regionale o a un bilanciatore del carico delle applicazioni interno.
  • Il bilanciatore del carico utilizza un gruppo di endpoint di rete ibrida (NEG di connettività ibrida) in un VPC producer che in questo progetto funge da VPC di transito.

Nel diagramma precedente, i workload nella rete VPC della tua applicazione possono raggiungere i servizi ibridi in esecuzione nel tuo ambiente on-premise o in altri ambienti cloud tramite l'endpoint Private Service Connect, come illustrato nel seguente diagramma. Questa opzione di progettazione per le comunicazioni unidirezionali offre un'alternativa al peering con un VPC di transito.

Nell'ambito del design nel diagramma precedente, più frontend, backend o endpoint possono connettersi allo stesso collegamento del servizio, che consente a più reti VPC o a più utenti di accedere allo stesso servizio. Come illustrato nel diagramma seguente, puoi rendere l'applicazione accessibile a più VPC. Questa accessibilità può essere utile in scenari di servizi multi-tenant in cui il servizio viene utilizzato da più VPC dei consumatori anche se i relativi intervalli di indirizzi IP si sovrappongono.

La sovrapposizione degli indirizzi IP è uno dei problemi più comuni durante l'integrazione di applicazioni situate in ambienti diversi. La connessione Private Service Connect nel seguente diagramma aiuta a evitare il problema di sovrapposizione degli indirizzi IP. Ciò avviene senza richiedere il provisioning o la gestione di componenti di rete aggiuntivi, come Cloud NAT o un'NVA, per eseguire la traduzione dell'indirizzo IP. Per un esempio di configurazione, consulta Pubblicare un servizio ibrido utilizzando Private Service Connect.

Il design presenta i seguenti vantaggi:

• Evita potenziali dipendenze di scalabilità condivisa e complessità di gestione su larga scala.
• Migliora la sicurezza fornendo un controllo granulare della connettività.
• Riduce il coordinamento degli indirizzi IP tra il produttore e il consumatore del servizio e l'ambiente esterno remoto.

L'approccio di progettazione nel diagramma precedente può essere ampliato in fasi successive per integrare Apigee come piattaforma API utilizzando le opzioni di progettazione della rete discusse in precedenza, inclusa l'opzione Private Service Connect.

Puoi rendere l'endpoint Private Service Connect accessibile da altre regioni utilizzando l'accesso globale Private Service Connect.

Il client che si connette all'endpoint Private Service Connect può essere nella stessa regione dell'endpoint o in un'altra regione. Questo approccio potrebbe essere utilizzato per fornire alta disponibilità ai servizi ospitati in più regioni o per accedere ai servizi disponibili in una singola regione da altre regioni. Quando un endpoint di Private Service Connect viene acceduto da risorse ospitate in altre regioni, ai costi di traffico in uscita interregionale si applicano i costi per il traffico destinato agli endpoint con accesso globale.

Nota: per eseguire controlli di benessere distribuiti e per semplificare la connessione di più VPC a ambienti on-premise tramite più connessioni ibride, concatena un bilanciatore del carico delle applicazioni interno con un bilanciatore del carico delle applicazioni esterno. Per maggiori informazioni, consulta Catena esplicita di bilanciatori del carico L7 con PSC.

Google Cloud

Best practice

• La scelta di Apigee e Apigee Hybrid come soluzione per la tua piattaforma API offre diversi vantaggi. Fornisce un livello proxy e un'astrazione o una facade per le API dei servizi di backend, combinate con funzionalità di sicurezza, limitazione della frequenza, quote e analisi.
  • Utilizza Apigee Adapter for Envoy con un'architettura di deployment di Apigee Hybrid con Kubernetes, se applicabile ai tuoi requisiti e all'architettura.
• I VPC e la progettazione del progetto in Google Cloud devono essere basati sulla gerarchia delle risorse e sui requisiti del modello di comunicazione sicura.
• Quando vengono utilizzate API con gateway API, devi utilizzare anche una lista consentita di indirizzi IP. Una lista consentita limita le comunicazioni alle origini e alle destinazioni degli indirizzi IP specifici dei consumer e dei gateway API che potrebbero essere ospitati in ambienti diversi.
• Utilizza regole del firewall VPC o criteri del firewall per controllare l'accesso alle risorse Private Service Connect tramite l'endpoint Private Service Connect.
• Se un'applicazione è esposta esternamente tramite un bilanciatore del carico delle applicazioni, valuta la possibilità di utilizzare Google Cloud Armor come un ulteriore livello di sicurezza per proteggerti da attacchi DDoS e minacce di sicurezza a livello di applicazione.

• Se le istanze richiedono l'accesso a internet, utilizza Cloud NAT nella VPC dell'applicazione (consumatore) per consentire ai carichi di lavoro di accedere a internet. In questo modo, puoi evitare di assegnare istanze VM con indirizzi IP pubblici esterni in sistemi di cui è stato eseguito il deployment dietro un gateway API o un bilanciatore del carico.

  • Per il traffico web in uscita, puoi utilizzare Google Cloud Secure Web Proxy. Il proxy offre diversi vantaggi.

• Consulta le best practice generali per i pattern di networking ibrida e multicloud.

Ingresso con accesso controllato

L'architettura del pattern di accesso controllato si basa sull'esposizione di API selezionate dei carichi di lavoro in esecuzione in Google Cloud all'ambiente di calcolo privato senza esporle a internet pubblico. Questo modello è la controparte del modello di uscita con controllo e si adatta bene a scenari di ibrido edge, ibrido a più livelli e multicloud partizionato.

Come per il pattern di uscita controllata, puoi facilitare questa esposizione limitata tramite un gateway API o un bilanciatore del carico che funge da facciata per i carichi di lavoro o i servizi esistenti. In questo modo, diventa accessibile a ambienti di computing privati, ambienti on-premise o altri ambienti cloud, come segue:

• I carichi di lavoro di cui esegui il deployment nell'ambiente di calcolo privato o in altri ambienti cloud sono in grado di comunicare con il gateway API o il bilanciatore del carico utilizzando indirizzi IP interni. Non è possibile raggiungere altri sistemi diGoogle Cloud .
• La comunicazione dall' Google Cloud all'ambiente di calcolo privato o ad altri ambienti cloud non è consentita. Il traffico viene avviato solo dall'ambiente privato o da altri ambienti cloud alle API in Google Cloud.

Architettura

Il seguente diagramma mostra un'architettura di riferimento che soddisfa i requisiti del pattern di ingresso con controllo.

La descrizione dell'architettura nel diagramma precedente è la seguente:

• Sul Google Cloud lato, esegui il deployment dei carichi di lavoro in un VPC (o in più VPC) per le applicazioni.
• La Google Cloud rete dell'ambiente si estende ad altri ambienti di calcolo (on-premise o su un altro cloud) utilizzando la connettività di rete ibrida o multicloud per facilitare la comunicazione tra gli ambienti.
• Facoltativamente, puoi utilizzare una VPC di transito per:
  • Fornisci ulteriori livelli di sicurezza del perimetro per consentire l'accesso a API specifiche all'esterno della VPC dell'applicazione.
  • Indirizza il traffico agli indirizzi IP delle API. Puoi creare regole del firewall VPC per impedire ad alcune origini di accedere a determinate API tramite un endpoint.
  • Ispeziona il traffico di livello 7 nel VPC di transito integrando un'appliance virtuale di rete (NVA).
• Accedi alle API tramite un API gateway o un bilanciatore del carico (proxy o bilanciatore del carico delle applicazioni) per fornire un livello di proxy e un livello di astrazione o una facade per le API dei tuoi servizi. Se devi distribuire il traffico su più istanze di API Gateway, puoi utilizzare un bilanciatore del carico di rete passthrough interno.
• Fornisci accesso limitato e granulare a un servizio pubblicato tramite un endpoint Private Service Connect utilizzando un bilanciatore del carico tramite Private Service Connect per esporre un'applicazione o un servizio.
• Tutti gli ambienti devono utilizzare uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.

Il seguente diagramma illustra il design di questo pattern utilizzando Apigee come piattaforma API.

Nel diagramma precedente, l'utilizzo di Apigee come piattaforma API fornisce le seguenti funzionalità per abilitare il pattern di accesso controllato:

• Funzionalità di gateway o proxy
• Funzionalità di sicurezza
• Limitazione di frequenza
• Analytics

Nel design:

• La connettività di rete in uscita (per il traffico proveniente da altri ambienti) passa attraverso un endpoint Private Service Connect nella VPC dell'applicazione associata alla VPC Apigee.
• Nella VPC dell'applicazione, viene utilizzato un bilanciatore del carico interno per esporre le API dell'applicazione tramite un endpoint Private Service Connect presentato nella VPC di Apigee. Per ulteriori informazioni, consulta Architettura con il peering VPC disattivato.

• Configura le regole del firewall e il filtro del traffico nel VPC dell'applicazione. In questo modo, viene fornito un accesso granulare e controllato. Inoltre, aiuta a impedire ai sistemi di raggiungere direttamente le tue applicazioni senza passare per l'endpoint Private Service Connect e il gateway API.

  Inoltre, puoi limitare la pubblicità della sottorete dell'indirizzo IP interno del carico di lavoro di backend nel VPC dell'applicazione alla rete on-premise per evitare la raggiungibilità diretta senza passare per l'endpoint Private Service Connect e il gateway API.

Alcuni requisiti di sicurezza potrebbero richiedere l'ispezione della sicurezza del perimetro al di fuori del VPC dell'applicazione, incluso il traffico di connettività ibrida. In questi casi, puoi incorporare un VPC di transito per implementare livelli di sicurezza aggiuntivi. Questi livelli, come le NVA di firewall di nuova generazione (NGFW) con più interfacce di rete, o Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS), eseguono un'analisi approfondita dei pacchetti al di fuori della VPC dell'applicazione, come illustrato nel seguente diagramma:

Come illustrato nel diagramma precedente:

• La connettività di rete in uscita (per il traffico proveniente da altri ambienti) passa attraverso un VPC di transito separato verso l'endpoint Private Service Connect nel VPC di transito associato al VPC Apigee.
• Nella VPC dell'applicazione, un bilanciatore del carico interno (ILB nel diagramma) viene utilizzato per esporre l'applicazione tramite un endpoint Private Service Connect nella VPC di Apigee.

Puoi eseguire il provisioning di più endpoint nella stessa rete VPC, come mostrato nel seguente diagramma. Per coprire diversi casi d'uso, puoi controllare i diversi percorsi di rete possibili utilizzando le regole firewall di Cloud Router e VPC. Ad esempio, se colleghi la tua rete on-premise Google Cloud utilizzando più connessioni di rete ibrida, puoi inviare parte del traffico on-premise ad API di Google o servizi pubblicati specifici Google Cloud tramite una connessione e il resto tramite un'altra. Inoltre, puoi utilizzare l'accesso globale di Private Service Connect per fornire opzioni di failover.

Varianti

Il pattern di architettura ingresso controllato può essere combinato con altri approcci per soddisfare requisiti di progettazione diversi, tenendo comunque conto dei requisiti di comunicazione del pattern. Il pattern offre le seguenti opzioni:

• Accedere alle API di Google da altri ambienti

• Esporre i backend delle applicazioni ad altri ambienti utilizzando Private Service Connect

• Utilizza un'architettura hub and spoke per esporre i backend delle applicazioni ad altri ambienti

Accedere alle API di Google da altri ambienti

Per gli scenari che richiedono l'accesso ai servizi Google, come Cloud Storage o BigQuery, senza inviare traffico tramite la rete internet pubblica, Private Service Connect offre una soluzione. Come mostrato nel diagramma seguente, consente di raggiungere le API e i servizi di Google supportati (inclusi Google Maps, Google Ads eGoogle Cloud) da ambienti on-premise o di altro tipo tramite una connessione di rete ibrida che utilizza l'indirizzo IP dell'endpoint Private Service Connect. Per ulteriori informazioni sull'accesso alle API di Google tramite gli endpoint di Private Service Connect, consulta Informazioni sull'accesso alle API di Google tramite gli endpoint.

Nel diagramma precedente, la rete on-premise deve essere connessa alla rete VPC di transito (consumer) utilizzando i tunnel Cloud VPN o un collegamento VLAN Cloud Interconnect.

È possibile accedere alle API di Google utilizzando endpoint o backend. Endpoints ti consente di scegliere come target un bundle di API di Google. I backend ti consentono di scegliere come target una specifica API di Google a livello di regione.

Nota: gli endpoint Private Service Connect sono registrati con Service Directory per le API di Google, dove puoi archiviare, gestire e pubblicare i servizi.

Esporre i backend delle applicazioni ad altri ambienti utilizzando Private Service Connect

In scenari specifici, come evidenziato dal pattern ibrido a più livelli, potresti dover eseguire il deployment dei backend in Google Cloud mantenendo i frontend in ambienti di calcolo privati. Sebbene meno comune, questo approccio è applicabile quando si ha a che fare con frontend monolitici di grandi dimensioni che potrebbero fare affidamento su componenti legacy. In alternativa, più comunemente, quando gestisci applicazioni distribuite su più ambienti, inclusi on-premise e altri cloud, che richiedono la connettività ai backend ospitati in Google Cloud su una rete ibrida.

In un'architettura di questo tipo, puoi utilizzare un gateway API o un bilanciatore del carico locale nell'ambiente on-premise privato o in altri ambienti cloud per esporre direttamente il frontend dell'applicazione alla rete internet pubblica. L'utilizzo di Google Cloud Private Service Connect semplifica la connettività privata ai backend esposti tramite un endpoint Private Service Connect, idealmente utilizzando API predefinite, come illustrato nel seguente diagramma:

Il design nel diagramma precedente utilizza un deployment di Apigee Hybrid costituito da un piano di gestione in Google Cloud e un piano di runtime ospitato nell'altro ambiente. Puoi installare e gestire il piano di runtime su un API gateway distribuito su una delle piattaforme Kubernetes supportate nel tuo ambiente on-premise o in altri ambienti cloud. In base ai tuoi requisiti per i workload distribuiti su Google Cloud e in altri ambienti, puoi utilizzare Apigee su Google Cloud con Apigee Hybrid. Per ulteriori informazioni, consulta Gateway API distribuiti.

Utilizza un'architettura hub and spoke per esporre i backend delle applicazioni ad altri ambienti

In alcuni scenari potrebbe essere necessario esporre le API dai backend delle applicazioni ospitati in Google Cloud diverse reti VPC. Come illustrato nel diagramma seguente, un VPC hub funge da punto di interconnessione centrale per i vari VPC (spoke), consentendo la comunicazione sicura tramite la connettività ibrida privata. Se vuoi, puoi utilizzare le funzionalità di API Gateway locale in altri ambienti, come Apigee Hybrid, per terminare le richieste client localmente dove è ospitato il frontend dell'applicazione.

Come illustrato nel diagramma precedente:

• Per fornire ulteriori funzionalità di ispezione di livello 7 NGFW, l'NVA con funzionalità NGFW è facoltativamente integrata nel design. Potresti dover richiedere queste funzionalità per rispettare requisiti di sicurezza specifici e gli standard delle norme di sicurezza della tua organizzazione.

• Questo design presuppone che le VPC spoke non richiedano la comunicazione diretta tra VPC.

  • Se è richiesta la comunicazione da spoke a spoke, puoi utilizzare la NVA per semplificarla.
  • Se hai backend diversi in VPC diversi, puoi utilizzare Private Service Connect per esporli al VPC Apigee.
  • Se il peering VPC viene utilizzato per la connettività northbound e southbound tra le VPC spoke e la VPC hub, devi prendere in considerazione la limitazione di transitività della connettività VPC tramite il peering VPC. Per ovviare a questo limite, puoi scegliere una delle seguenti opzioni:
    • Per interconnettere le VPC, utilizza un'NVA.
    • Se applicabile, valuta il modello Private Service Connect.
    • Per stabilire la connettività tra la VPC Apigee e i backend che si trovano in altriGoogle Cloud progetti della stessa organizzazione senza componenti di rete aggiuntivi, utilizza la VPC condivisa.

• Se sono necessarie NVA per l'ispezione del traffico, incluso il traffico proveniente da altri ambienti, la connettività ibrida agli ambienti on-premise o ad altri ambienti cloud deve essere terminata nel VPC di transito ibrido.

• Se il design non include l'NVA, puoi terminare la connettività ibrida nel VPC hub.

• Se sono richieste determinate funzionalità di bilanciamento del carico o di sicurezza, ad esempio l'aggiunta di WAF o protezione DDoS di Google Cloud Armor, puoi eventualmente implementare un bilanciatore del carico delle applicazioni esterno al perimetro tramite una VPC esterna prima di inoltrare le richieste dei client esterni ai backend.

Best practice

• Per le situazioni in cui le richieste dei client provenienti da internet devono essere ricevute localmente da un frontend ospitato in un ambiente cloud on-premise privato o di altro tipo, valuta la possibilità di utilizzare Apigee Hybrid come soluzione di gateway API. Questo approccio facilita anche una migrazione senza problemi della soluzione a un ambiente completamente Google Cloud-hosted, mantenendo la coerenza della piattaforma API (Apigee).
• Utilizza Apigee Adapter for Envoy con un'architettura di deployment di Apigee Hybrid con Kubernetes, se applicabile ai tuoi requisiti e all'architettura.
• La progettazione di VPC e progetti in Google Cloud deve rispettare la gerarchia delle risorse e i requisiti del modello di comunicazione sicura, come descritto in questa guida.
• L'integrazione di un VPC di transito in questo design offre la flessibilità di eseguire il provisioning di ulteriori misure di sicurezza del perimetro e connettività ibrida al di fuori del VPC del carico di lavoro.
• Utilizza Private Service Connect per accedere alle API e ai servizi Google da ambienti on-premise o da altri ambienti cloud utilizzando l'indirizzo IP interno dell'endpoint su una rete di connettività ibrida. Per saperne di più, vedi Accedere all'endpoint da host on-premise.
• Per contribuire a proteggere i Google Cloud servizi 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 rete VPC.
  • Se necessario, puoi estendere i perimetri dei servizi a un ambiente ibrido tramite una VPN o Cloud Interconnect. Per ulteriori informazioni sui vantaggi dei perimetri di servizio, consulta la Panoramica dei Controlli di servizio VPC.
• Utilizza regole del firewall VPC o criteri del firewall per controllare l'accesso a livello di rete alle risorse Private Service Connect tramite l'endpoint Private Service Connect. Ad esempio, le regole firewall in uscita nel VPC dell'applicazione (consumatore) possono limitare l'accesso dalle istanze VM all'indirizzo IP o alla subnet dei tuoi endpoint. Per ulteriori informazioni sulle regole firewall VPC in generale, consulta Regole firewall VPC.
• 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 indicazioni per la progettazione e l'implementazione dell'HA e della ridondanza fornite dal fornitore dell'NVA.
• Per rafforzare la sicurezza del perimetro e proteggere il tuo API gateway di cui è stato eseguito il deployment nel rispettivo ambiente, puoi eventualmente implementare meccanismi di bilanciamento del carico e firewall per le applicazioni web nell'altro ambiente di calcolo (ibrido o altro cloud). Implementa queste opzioni nella rete di perimetro collegata direttamente a internet.
• Se le istanze richiedono l'accesso a internet, utilizza Cloud NAT nella VPC dell'applicazione per consentire ai carichi di lavoro di accedere a internet. In questo modo, puoi evitare di assegnare istanze VM con indirizzi IP pubblici esterni in sistemi di cui è stato eseguito il deployment dietro un API gateway o un bilanciatore del carico.
• Per il traffico web in uscita, utilizza Secure Web Proxy. Il proxy offre diversi vantaggi.
• Consulta le best practice generali per i pattern di networking ibrida e multicloud.

Uscita e ingresso con accesso riservato

Il pattern Uscita controllata e ingresso controllato utilizza una combinazione di uscite controllate e ingressi controllati per gli scenari che richiedono l'utilizzo bidirezionale di API selezionate tra i carichi di lavoro. I carichi di lavoro possono essere eseguiti in Google Cloud, in ambienti on-premise privati o in altri ambienti cloud. In questo pattern, puoi utilizzare gateway API, endpoint Private Service Connect o bilanciatori del carico per esporre API specifiche e, facoltativamente, fornire autenticazione, autorizzazione e controlli delle chiamate API.

La differenza principale tra questo pattern e il pattern a maglia sta nella sua applicazione a scenari che richiedono solo l'utilizzo di API bidirezionali o la comunicazione con origini e destinazioni di indirizzi IP specifici, ad esempio un'applicazione pubblicata tramite un endpoint Private Service Connect. Poiché la comunicazione è limitata alle API esposte o ad indirizzi IP specifici, le reti degli ambienti non devono essere allineate nel design. Gli scenari comuni applicabili includono, a titolo esemplificativo:

• Fusioni e acquisizioni.
• Integrazioni delle applicazioni con i partner.
• Integrazioni tra applicazioni e servizi di un'organizzazione con diverse unità organizzative che gestiscono le proprie applicazioni e le ospitano in ambienti diversi.

La comunicazione funziona nel seguente modo:

• I carichi di lavoro di cui esegui il deployment in Google Cloud possono comunicare con il gateway API (o indirizzi IP di destinazione specifici) utilizzando indirizzi IP interni. Non è possibile raggiungere altri sistemi di cui è stato eseguito il deployment nell'ambiente di calcolo privato.
• Al contrario, i carichi di lavoro di cui esegui il deployment in altri ambienti di calcolo possono comunicare con il gateway API lato Google Cloud(o con un indirizzo IP dell'endpoint pubblicato specifico) utilizzando indirizzi IP interni. Non è possibile raggiungere altri sistemi di Google Cloud .

Architettura

Il seguente diagramma mostra un'architettura di riferimento per il pattern di entrata e di uscita gated:

L'approccio di progettazione nel diagramma precedente include i seguenti elementi:

• D'altra parte, puoi eseguire il deployment dei carichi di lavoro in un VPC (o in un VPC condiviso) senza esporli direttamente a internet. Google Cloud
• La Google Cloud rete dell'ambiente viene estesa ad altri ambienti di calcolo. L'ambiente può essere on-premise o su un altro cloud. Per estendere l'ambiente, utilizza un pattern di comunicazione per la connettività ibrida e multicloud adatto per facilitare la comunicazione tra gli ambienti in modo che possano utilizzare gli indirizzi IP interni.
• Se vuoi, puoi attivare l'accesso ad indirizzi IP di destinazione specifici per utilizzare una VPC di transito e aggiungere un livello di sicurezza perimetrale all'esterno della VPC dell'applicazione.
  • Puoi utilizzare Cloud Next Generation Firewall o appliance virtuali di rete (NVA) con firewall di nuova generazione (NGFW) nel VPC di transito per ispezionare il traffico e consentire o vietare l'accesso a determinate API da origini specifiche prima che raggiungano il VPC dell'applicazione.
• Per accedere alle API è necessario utilizzare un API Gateway o un bilanciatore del carico per fornire un livello proxy e un'astrazione o una facciata per le API di servizio.
• Per le applicazioni utilizzate come API, puoi anche utilizzare Private Service Connect per fornire un indirizzo IP interno per l'applicazione pubblicata.
• Tutti gli ambienti utilizzano uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.

Un'applicazione comune di questo pattern prevede il deployment dei backend delle applicazioni (o di un sottoinsieme di backend delle applicazioni) in Google Cloud e l'hosting di altri componenti frontend e backend in ambienti on-premise o in altri cloud (pattern ibrido a più livelli o pattern multicloud partizionato). Con l'evoluzione delle applicazioni e la migrazione al cloud, spesso emergono dipendenze e preferenze per servizi cloud specifici.

A volte queste dipendenze e preferenze portano alla distribuzione di applicazioni e backend su diversi provider cloud. Inoltre, alcune applicazioni possono essere create con una combinazione di risorse e servizi distribuiti in ambienti on-premise e in più ambienti cloud.

Per le applicazioni distribuite, le funzionalità della connettività multicloud e ibrida di Cloud Load Balancing esterno possono essere utilizzate per terminare le richieste degli utenti e inoltrarle a frontend o backend in altri ambienti. Questo routing avviene tramite una connessione di rete ibrida, come illustrato nel seguente diagramma. Questa integrazione consente la distribuzione graduale dei componenti dell'applicazione in ambienti diversi. Le richieste dal frontend ai servizi di backend ospitati in Google Cloud comunicano in modo sicuro tramite la connessione di rete ibrida stabilita grazie a un bilanciatore del carico interno (ILB nel diagramma).

L'utilizzo del Google Cloud design nel diagramma precedente è utile per quanto segue:

• Facilita la comunicazione bidirezionale tra Google Cloud, on-premise e altri ambienti cloud utilizzando API predefinite su entrambi i lati in linea con il modello di comunicazione di questo pattern.
• Per fornire frontend globali per applicazioni rivolte a internet con componenti dell'applicazione distribuiti (frontend o backend) e per raggiungi i seguenti obiettivi, puoi utilizzare le funzionalità di bilanciamento del carico e di sicurezza avanzate di Google Cloud point of presence (PoP) distribuiti:
• Riduci le spese in conto capitale e semplifica le operazioni utilizzando i servizi gestiti serverless.
• Ottimizza le connessioni ai backend delle applicazioni a livello globale per velocità e latenza.
  • Google Cloud Cross-Cloud Network consente la comunicazione multicloud tra i componenti dell'applicazione tramite connessioni private ottimali.
• Memorizza nella cache i contenuti statici ad alta domanda e migliora le prestazioni delle applicazioni che utilizzano Cloud Load Balancing globale fornendo l'accesso a Cloud CDN.
• Proteggi i frontend globali delle applicazioni rivolte a internet utilizzando le funzionalità di Google Cloud Armor che forniscono servizi WAF (web application firewall) e di mitigazione degli attacchi DDoS distribuiti a livello globale.
• Facoltativamente, puoi incorporare Private Service Connect nel tuo design. In questo modo, viene attivato un accesso privato e granulare alle API di servizio o ai tuoi servizi pubblicati da altri ambienti senza attraversare internet pubblico. Google Cloud

Varianti

I pattern di architettura con uscita e ingresso controllati possono essere combinati con altri approcci per soddisfare diversi requisiti di progettazione, tenendo comunque conto dei requisiti di comunicazione di questo pattern. I pattern offrono le seguenti opzioni:

• Gateway API distribuiti
• Comunicazione bidirezionale dell'API tramite Private Service Connect
• Comunicazione bidirezionale mediante endpoint e interfacce Private Service Connect

Gateway API distribuiti

In scenari come quello basato sul pattern multicloud partizionato, le applicazioni (o i componenti dell'applicazione) possono essere create in diversi ambienti cloud, incluso un ambiente on-premise privato. Il requisito comune è instradare le richieste del client al frontend dell'applicazione direttamente nell'ambiente in cui è ospitata l'applicazione (o il componente frontend). Questo tipo di comunicazione richiede un bilanciatore del carico locale o un API gateway. Queste applicazioni e i relativi componenti potrebbero richiedere anche funzionalità specifiche della piattaforma API per l'integrazione.

Il seguente diagramma illustra come Apigee e Apigee Hybrid sono progettati per soddisfare questi requisiti con un API Gateway localizzato in ogni ambiente. La gestione della piattaforma API è centralizzata in Google Cloud. Questo design contribuisce a applicare misure di controllo dell'accesso rigorose in cui solo gli indirizzi IP preapprovati (API di destinazione e di destinazione o indirizzi IP degli endpoint di Private Service Connect) possono comunicare tra Google Cloud e gli altri ambienti.

L'elenco seguente descrive i due percorsi di comunicazione distinti nel diagramma precedente che utilizzano il gateway API Apigee:

• Le richieste del client arrivano al frontend dell'applicazione direttamente nell'ambiente che ospita l'applicazione (o il componente frontend).
• I gateway API e i proxy all'interno di ogni ambiente gestiscono le richieste API di client e applicazioni in direzioni diverse in più ambienti.
  • La funzionalità API Gateway in Google Cloud (Apigee) espone i componenti dell'applicazione (frontend o backend) ospitati in Google Cloud.
  • La funzionalità di API Gateway in un altro ambiente (ibrido) espone i componenti frontend (o backend) dell'applicazione ospitati in quell'ambiente.

Facoltativamente, puoi prendere in considerazione l'utilizzo di una VPC di transito. Una VPC di transito può offrire la flessibilità di separare i problemi ed eseguire ispezioni di sicurezza e connettività ibrida in una rete VPC separata. Dal punto di vista della raggiungibilità degli indirizzi IP, un VPC di transito (a cui è collegata la connettività ibrida) soddisfa i seguenti requisiti per mantenere la raggiungibilità end-to-end:

• Gli indirizzi IP per le API target devono essere pubblicizzati negli altri ambienti in cui sono ospitati i client/richiedenti.
• Gli indirizzi IP degli host che devono comunicare con le API di destinazione devono essere pubblicizzati nell'ambiente in cui risiede l'API di destinazione, ad esempio gli indirizzi IP dell'autore della richiesta dell'API (il client). L'eccezione si verifica quando la comunicazione avviene tramite un bilanciatore del carico, un proxy, un endpoint Private Service Connect o un'istanza NAT.

Per estendere la connettività all'ambiente remoto, questo design utilizza il peering VPC diretto con la funzionalità di scambio di route dei clienti. Il design consente di instradare richieste API specifiche provenienti da carichi di lavoro ospitati all'interno del VPC Google Cloud dell'applicazione tramite il VPC di transito. In alternativa, puoi utilizzare un endpoint Private Service Connect nella VPC dell'applicazione associata a un bilanciatore del carico con un backend del gruppo di endpoint di rete ibrida nella VPC di transito. Questa configurazione è descritta nella sezione successiva: Comunicazione API bidirezionale tramite Private Service Connect.

Comunicazione bidirezionale delle API tramite Private Service Connect

A volte le aziende potrebbero non dover utilizzare immediatamente un gateway API (come Apigee) o potrebbero volerlo aggiungere in un secondo momento. Tuttavia, potrebbero esserci requisiti aziendali per attivare la comunicazione e l'integrazione tra determinate applicazioni in ambienti diversi. Ad esempio, se la tua azienda ha acquisito un'altra azienda, potresti dover esporre determinate applicazioni a questa azienda. Potrebbe essere necessario esporre le applicazioni alla tua azienda. Entrambe le aziende potrebbero avere i propri carichi di lavoro ospitati in ambienti diversi (Google Cloud, on-premise o in altri cloud) e devono evitare la sovrapposizione degli indirizzi IP. In questi casi, puoi utilizzare Private Service Connect per facilitare una comunicazione efficace.

Per le applicazioni utilizzate come API, puoi anche utilizzare Private Service Connect per fornire un indirizzo privato per le applicazioni pubblicate, consentendo l'accesso sicuro all'interno della rete privata in più regioni e tramite connettività ibrida. Questa astrazione facilita l'integrazione delle risorse da diversi cloud e ambienti on-premise tramite un modello di connettività ibrida e multi-cloud. Inoltre, consente di assemblare le applicazioni in ambienti multi-cloud e on-premise. In questo modo è possibile soddisfare diversi requisiti di comunicazione, ad esempio integrare applicazioni sicure in cui non viene utilizzato o non è previsto l'utilizzo di un gateway API.

Utilizzando Private Service Connect con Cloud Load Balancing, come mostrato nel seguente diagramma, puoi ottenere due percorsi di comunicazione distinti. Ogni percorso viene avviato da una direzione diversa per uno scopo di connettività distinto, idealmente tramite chiamate API.

• A questo design si applicano tutte le considerazioni e i consigli di progettazione di Private Service Connect discussi in questa guida.
• Se è necessaria un'ispezione aggiuntiva a livello 7, puoi integrare le NVA con questo design (nella VPC di transito).
• Questo design può essere utilizzato con o senza gateway API.

I due percorsi di connettività mostrati nel diagramma precedente rappresentano connessioni indipendenti e non illustrano la comunicazione bidirezionale di una singola connessione o flusso.

Comunicazione bidirezionale mediante endpoint e interfacce Private Service Connect

Come discusso nel pattern di ingresso controllato, una delle opzioni per abilitare la comunicazione client-service è utilizzare un endpoint Private Service Connect per esporre un servizio in un VPC di produzione a un VPC di consumo. Questa connettività può essere estesa a un ambiente on-premise o persino a un altro ambiente di provider cloud tramite una connettività ibrida. Tuttavia, in alcuni scenari, il servizio ospitato può richiedere anche la comunicazione privata.

Per accedere a un determinato servizio, ad esempio per recuperare i dati da origini dati che possono essere ospitate all'interno o all'esterno del VPC consumer, questa comunicazione privata può avvenire tra il VPC dell'applicazione (producer) e un ambiente remoto, ad esempio un ambiente on-premise.

In questo scenario, le interfacce Private Service Connect consentono a un'istanza VM di un producer di servizi di accedere alla rete di un consumer. Lo fa condividendo un'interfaccia di rete, mantenendo al contempo la separazione dei ruoli di produttore e consumatore. Con questa interfaccia di rete nel VPC consumer, la VM dell'applicazione può accedere alle risorse del consumer come se si trovassero localmente nel VPC del producer.

Un'interfaccia Private Service Connect è un'interfaccia di rete collegata alla VPC consumer (di transito). È possibile raggiungere destinazioni esterne raggiungibili dal VPC consumer (di transito) a cui è collegata l'interfaccia Private Service Connect. Pertanto, questa connessione può essere estesa a un ambiente esterno tramite una connettività ibrida, ad esempio un ambiente on-premise, come illustrato nel seguente diagramma:

Se il VPC consumer è un'organizzazione o un'entità esterna, come un'organizzazione di terze parti, in genere non potrai proteggere la comunicazione con l'interfaccia Private Service Connect nel VPC consumer. In questo scenario, puoi definire i criteri di sicurezza nel sistema operativo guest della VM dell'interfaccia Private Service Connect. Per ulteriori informazioni, consulta Configurare la sicurezza per le interfacce Private Service Connect. In alternativa, puoi prendere in considerazione un approccio diverso se non è conforme alle norme o alla conformità alla sicurezza della tua organizzazione.

Best practice

• Per le situazioni in cui le richieste dei client provenienti da internet devono essere ricevute localmente da un frontend ospitato in un ambiente cloud on-premise privato o di altro tipo, valuta la possibilità di utilizzare Hybrid come soluzione di gateway API.

  • Questo approccio facilita anche la migrazione della soluzione a un ambiente Google Cloudcompletamente ospitato, mantenendo la coerenza della piattaforma API (Apigee).

• Per ridurre al minimo la latenza e ottimizzare i costi per volumi elevati di trasferimenti di dati in uscita verso gli altri ambienti quando questi sono in configurazioni ibride o multicloud permanenti o a lungo termine, tieni presente quanto segue:

  • Utilizza Cloud Interconnect o Cross-Cloud Interconnect.
  • Per terminare le connessioni utente nel frontend di destinazione nell'ambiente appropriato, utilizza Hybrid.

• Se applicabile ai tuoi requisiti e all'architettura, utilizza Apigee Adapter per Envoy con un deployment ibrido con Kubernetes.

• Prima di progettare i percorsi di connettività e di routing, devi identificare il traffico o le richieste API da indirizzare a un API Gateway locale o remoto, nonché gli ambienti di origine e di destinazione.

• Utilizza i Controlli di servizio VPC per proteggere i Google Cloud servizi nei tuoi progetti e per ridurre il rischio di esfiltrazione di dati, specificando i perimetri di servizio a livello di progetto o di rete VPC.

  • Puoi estendere i perimetri di servizio a un ambiente ibrido tramite una VPN autorizzata o Cloud Interconnect. Per ulteriori informazioni sui vantaggi dei perimetri di servizio, consulta la Panoramica dei Controlli di servizio VPC.

• Utilizza regole firewall Virtual Private Cloud (VPC) o criteri firewall per controllare l'accesso a livello di rete alle risorse Private Service Connect tramite l'endpoint Private Service Connect. Ad esempio, le regole firewall in uscita nel VPC dell'applicazione (consumatore) possono limitare l'accesso dalle istanze VM all'indirizzo IP o alla subnet dei tuoi endpoint.

• Quando utilizzi un'interfaccia Private Service Connect, devi proteggere la comunicazione con l'interfaccia configurando la sicurezza per l'interfaccia Private Service Connect.

• Se un workload in una subnet privata richiede l'accesso a internet, utilizza Cloud NAT per evitare di assegnare un indirizzo IP esterno al workload e di esporlo all'internet pubblico.

  • Per il traffico web in uscita, utilizza Secure Web Proxy. Il proxy offre diversi vantaggi.

• Consulta le best practice generali per i pattern di networking ibrida e multicloud.

Pattern di passaggio

Con il pattern di riassegnazione, l'architettura si basa sull'utilizzo di servizi di archiviazione forniti daGoogle Cloudper collegare un ambiente di calcolo privato ai progetti in Google Cloud. Questo pattern si applica principalmente alle configurazioni che seguono il pattern di architettura multicloud ibrida per l'analisi, dove:

• I carichi di lavoro in esecuzione in un ambiente di calcolo privato o in un altro cloud caricano i dati in posizioni di archiviazione condivise. A seconda dei casi d'uso, i caricamenti possono avvenire collettivamente o in incrementi più piccoli.
• I carichi di lavoro ospitati suGoogle Cloudo su altri servizi Google (ad esempio, servizi di analisi dei dati e di intelligenza artificiale) consumano i dati dalle posizioni di archiviazione condivise e li elaborano in streaming o in batch.

Architettura

Il seguente diagramma mostra un'architettura di riferimento per il pattern di trasferimento.

Il diagramma di architettura precedente mostra i seguenti flussi di lavoro:

• Google Cloud D'altra parte, esegui il deployment dei carichi di lavoro in una VPC dell'applicazione. Questi carichi di lavoro possono includere l'elaborazione dei dati, l'analisi e le applicazioni frontend correlate all'analisi.
• Per esporre in modo sicuro le applicazioni frontend agli utenti, puoi utilizzare Cloud Load Balancing o API Gateway.
• Un insieme di bucket Cloud Storage o code Pub/Sub carica i dati dall'ambiente di calcolo privato e li rende disponibili per un'ulteriore elaborazione da parte dei carichi di lavoro di cui è stato eseguito il deployment in Google Cloud. Utilizzando i criteri IAM (Identity and Access Management), puoi limitare l'accesso ai carichi di lavoro attendibili.
• Utilizza Controlli di servizio VPC per limitare l'accesso ai servizi e per ridurre al minimo i rischi ingiustificati di esfiltrazione di dati Google Cloud dai servizi.
• In questa architettura, la comunicazione con i bucket Cloud Storage o Pub/Sub avviene su reti pubbliche o tramite connettività privata utilizzando VPN, Cloud Interconnect o Cross-Cloud Interconnect. In genere, la decisione su come effettuare la connessione dipende da diversi aspetti, tra cui:
  • Volume di traffico previsto
  • Se si tratta di una configurazione temporanea o permanente
  • Requisiti di sicurezza e conformità

Variazione

Le opzioni di progettazione descritte nel pattern di ingresso controllato, che utilizza gli endpoint Private Service Connect per le API di Google, possono essere applicate anche a questo pattern. Nello specifico, fornisce accesso a Cloud Storage, BigQuery e altre API di servizi Google. Questo approccio richiede l'utilizzo di indirizzi IP privati su una connessione di rete ibrida e multicloud, come VPN, Cloud Interconnect e Cross-Cloud Interconnect.

Best practice

• Blocca l'accesso ai bucket Cloud Storage e agli argomenti Pub/Sub.
• Se applicabile, utilizza soluzioni di spostamento dei dati integrate e cloud-first come la Google Cloud suite di soluzioni. Per soddisfare le esigenze dei casi d'uso, queste soluzioni sono progettate per spostare, integrare e trasformare i dati in modo efficiente.

• Valuta i diversi fattori che influiscono sulle opzioni di trasferimento dei dati, come il costo, il tempo di trasferimento previsto e la sicurezza. Per ulteriori informazioni, consulta Valutare le opzioni di trasferimento.

• Per ridurre al minimo la latenza e impedire il trasferimento e il movimento di dati ad alto volume tramite la rete internet pubblica, ti consigliamo di utilizzare Cloud Interconnect o Cross-Cloud Interconnect, inclusa l'accesso agli endpoint Private Service Connect all'interno del tuo Virtual Private Cloud per le API Google.

• Per proteggere i Google Cloud servizi nei tuoi progetti e per ridurre il rischio di esfiltrazione di dati, utilizza i Controlli di servizio VPC. Questi controlli di servizio possono specificare i perimetri di servizio a livello di progetto o rete VPC.

  • Puoi estendere i perimetri di servizio a un ambiente ibrido tramite una VPN autorizzata o Cloud Interconnect. Per ulteriori informazioni sui vantaggi dei perimetri di servizio, consulta la Panoramica dei Controlli di servizio VPC.

• Comunicare con i carichi di lavoro di analisi dei dati pubblicati pubblicamente che sono ospitati su istanze VM tramite un gateway API, un bilanciatore del carico o un'appliance di rete virtuale. Utilizza uno di questi metodi di comunicazione per una maggiore sicurezza ed evitare di rendere queste istanze direttamente raggiungibili da internet.

• Se è necessario l'accesso a internet, Cloud NAT può essere utilizzato nella stessa VPC per gestire il traffico in uscita dalle istanze alla rete internet pubblica.

• Consulta le best practice generali per le topologie di rete ibride e multi-cloud.

Best practice generali

Quando progetti e esegui l'onboarding delle identità cloud, della gerarchia delle risorse e delle reti delle zone di destinazione, prendi in considerazione i consigli per la progettazione riportati in Progettazione della zona di destinazione in Google Cloud e le Google Cloud best practice per la sicurezza descritte nel blueprint Enterprise Foundations. Convalida il design selezionato in base ai seguenti documenti:

• Best practice e architetture di riferimento per la progettazione di VPC
• Decidi una gerarchia delle risorse per la tua Google Cloud zona di destinazione
• Google Cloud Framework di architettura: sicurezza, privacy e conformità

Inoltre, tieni presente le seguenti best practice generali:

• Quando scegli un'opzione di connettività di rete ibrida o multicloud, tieni conto dei requisiti aziendali e delle applicazioni, come SLA, prestazioni, sicurezza, costi, affidabilità e larghezza di banda. Per ulteriori informazioni, consulta Scegliere un prodotto per la connettività di rete e Modelli per connettere altri fornitori di servizi cloud a Google Cloud.

• Utilizza le VPC condivise su Google Cloud anziché su più VPC quando è opportuno e in linea con i requisiti della progettazione della gerarchia delle risorse. Per saperne di più, consulta Decidere se creare più reti VPC.

• Segui le best practice per la pianificazione di account e organizzazioni.

• Ove applicabile, stabilisci un'identità comune tra gli ambienti in modo che i sistemi possano autenticarsi in modo sicuro tra i confini degli ambienti.

• Per esporre in modo sicuro le applicazioni agli utenti aziendali in una configurazione ibrida e per scegliere l'approccio più adatto alle tue esigenze, devi seguire le modalità consigliate per l'integrazione Google Cloud con il tuo sistema di gestione delle identità.

  • Consulta anche Modelli per l'autenticazione degli utenti del personale in un ambiente ibrido.

• Quando progetti i tuoi ambienti on-premise e cloud, prendi in considerazione l'indirizzamento IPv6 fin dall'inizio e tieni conto di quali servizi lo supportano. Per ulteriori informazioni, consulta Introduzione all'IPv6 su Google Cloud. Riassume i servizi supportati al momento della stesura del blog.

• Quando progetti, esegui il deployment e gestisci le regole firewall VPC, puoi:

  • Utilizza il filtro basato sugli account di servizio anziché il filtro basato sui tag di rete se hai bisogno di un controllo rigoroso sull'applicazione delle regole firewall alle VM.
  • Utilizza i criteri firewall quando raggruppi diverse regole firewall, in modo da poterle aggiornare tutte contemporaneamente. Puoi anche rendere il criterio gerarchico. Per le specifiche e i dettagli dei criteri firewall gerarchici, consulta Criteri firewall gerarchici.
  • Utilizza oggetti di geolocalizzazione nel criterio del firewall quando devi filtrare il traffico IPv4 e IPv6 esterno in base a regioni o località geografiche specifiche.
  • Utilizza Threat Intelligence per le regole dei criteri di firewall se devi proteggere la tua rete consentendo o bloccando il traffico in base ai dati di Threat Intelligence, ad esempio indirizzi IP noti come dannosi o in base a intervalli di indirizzi IP del cloud pubblico. Ad esempio, puoi consentire il traffico da intervalli di indirizzi IP di cloud pubblici specifici se i tuoi servizi devono comunicare solo con quel cloud pubblico. Per ulteriori informazioni, consulta le best practice per le regole firewall.

• Devi sempre progettare la sicurezza del cloud e della rete utilizzando un approccio di sicurezza a più livelli tenendo conto di ulteriori livelli di sicurezza, come i seguenti:

  • Google Cloud Armor
  • Cloud Intrusion Detection System
  • IPS Cloud Next Generation Firewall
  • Threat intelligence per le regole delle policy firewall

  Questi livelli aggiuntivi possono aiutarti a filtrare, ispezionare e monitorare un'ampia gamma di minacce a livello di rete e applicazione per analisi e prevenzione.

• Quando decidi dove eseguire la risoluzione DNS in una configurazione ibrida, ti consigliamo di utilizzare due sistemi DNS autorevoli per il tuo ambienteGoogle Cloud privato e per le risorse on-premise ospitate da server DNS esistenti nel tuo ambiente on-premise. Per ulteriori informazioni, consulta Scegliere dove viene eseguita la risoluzione DNS.

• Se possibile, esponi sempre le applicazioni tramite API utilizzando un gateway API o un bilanciatore del carico. Ti consigliamo di prendere in considerazione una piattaforma API come Apigee. Apigee funge da astrazione o facade per le API dei servizi di backend, combinata con funzionalità di sicurezza, limitazione della frequenza, quote e analisi.

• Una piattaforma API (gateway o proxy) e un bilanciatore del carico delle applicazioni non sono mutuamente esclusivi. A volte, l'utilizzo congiunto di gateway API e bilanciatori del carico può fornire una soluzione più solida e sicura per gestire e distribuire il traffico API su larga scala. L'utilizzo di API Gateway per Cloud Load Balancing ti consente di:

  • Offri API ad alte prestazioni con Apigee e Cloud CDN per:

    • Riduci la latenza
    • Ospitare API a livello globale

    • Aumentare la disponibilità per i periodi di picco del traffico

      Per saperne di più, guarda Caricare API ad alte prestazioni con Apigee e Cloud CDN su YouTube.

  • Implementa la gestione avanzata del traffico.

  • Utilizza Google Cloud Armor come servizio di protezione DDoS, WAF e sicurezza della rete per proteggere le tue API.

  • Gestisci un bilanciamento del carico efficiente tra i gateway in più regioni. Per saperne di più, guarda Protezione delle API e implementazione del failover multiregione con PSC e Apigee.

• Per determinare quale prodotto Cloud Load Balancing utilizzare, devi innanzitutto determinare il tipo di traffico che i bilanciatori del carico devono gestire. Per ulteriori informazioni, consulta Scegliere un bilanciatore del carico.

• Quando utilizzi Cloud Load Balancing, devi utilizzare le sue funzionalità di ottimizzazione della capacità dell'applicazione, ove applicabili. In questo modo, puoi risolvere alcune delle problematiche legate alla capacità che possono verificarsi nelle applicazioni distribuite a livello globale.

  • Per un'analisi approfondita della latenza, consulta Ottimizzazione della latenza delle applicazioni con il bilanciamento del carico.

• Sebbene Cloud VPN cripti il traffico tra gli ambienti, con Cloud Interconnect devi utilizzare MACsec o VPN HA su Cloud Interconnect per criptare il traffico in transito a livello di connettività. Per ulteriori informazioni, consulta Come faccio a criptare il mio traffico tramite Cloud Interconnect.

  • Puoi anche prendere in considerazione la crittografia a livello di servizio tramite TLS. Per maggiori informazioni, consulta Decidere come soddisfare i requisiti di conformità per la crittografia in transito.

• Se hai bisogno di un volume di traffico maggiore su una connettività ibrida VPN rispetto a quanto supportato da un singolo tunnel VPN, puoi prendere in considerazione l'opzione di routing VPN ad alta disponibilità attiva/attiva.

  • Per configurazioni ibride o multicloud a lungo termine con elevati volumi di trasferimento di dati in uscita, valuta la possibilità di utilizzare Cloud Interconnect o Cross-Cloud Interconnect. Queste opzioni di connettività contribuiscono a ottimizzare le prestazioni della connettività e potrebbero ridurre gli addebiti per i trasferimenti di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, consulta i prezzi di Cloud Interconnect.

• Quando ti connetti alle risorse Google Cloud e cerchi di scegliere tra Cloud Interconnect, peering diretto o peering con operatori, ti consigliamo di utilizzare Cloud Interconnect, a meno che tu non debba accedere alle applicazioni Google Workspace. Per ulteriori informazioni, puoi confrontare le funzionalità del peering diretto con Cloud Interconnect e del peering con l'operatore con Cloud Interconnect.

• Assegna uno spazio di indirizzi IP sufficiente dallo spazio di indirizzi IP RFC 1918 esistente per ospitare i sistemi in cloud.

• Se hai limitazioni tecniche che ti richiedono di mantenere l'intervallo di indirizzi IP, puoi:

  • Utilizza gli stessi indirizzi IP interni per i carichi di lavoro on-premise durante la migrazione a Google Cloud, utilizzando subnet ibride.

  • Esegui il provisioning e utilizza i tuoi indirizzi IPv4 pubblici per leGoogle Cloud risorse che utilizzano il servizio Bring Your Own IP (BYOIP) per Google.

• Se la progettazione della tua soluzione richiede l'esposizione di un'applicazione basata suGoogle Cloudalla rete internet pubblica, valuta i consigli di progettazione descritti in Networking per l'implementazione di applicazioni rivolte a internet.

• Ove applicabile, utilizza gli endpoint Private Service Connect per consentire ai carichi di lavoro in Google Cloud, on-premise o in un altro ambiente cloud con connettività ibrida di accedere privatamente alle API di Google o ai servizi pubblicati, utilizzando indirizzi IP interni in modo granulare.

• Quando utilizzi Private Service Connect, devi controllare quanto segue:

  • Chi può eseguire il deployment delle risorse Private Service Connect.
  • Indica se è possibile stabilire connessioni tra consumatori e produttori.
  • Il traffico di rete che può accedere a queste connessioni.

  Per ulteriori informazioni, consulta Sicurezza di Private Service Connect.

• Per ottenere una configurazione cloud solida nel contesto di un'architettura ibrida e multi-cloud:

  • Esegui una valutazione completa dei livelli di affidabilità richiesti delle diverse applicazioni negli ambienti. In questo modo, puoi raggiungere i tuoi obiettivi di disponibilità e resilienza.
  • Scopri le funzionalità di affidabilità e i principi di progettazione del tuo provider cloud. Per ulteriori informazioni, consulta la sezione sull'Google Cloud affidabilità dell'infrastruttura.

• La visibilità e il monitoraggio della rete cloud sono essenziali per mantenere comunicazioni affidabili. Network Intelligence Center fornisce un'unica console per la gestione della visibilità, del monitoraggio e della risoluzione dei problemi di rete.

Modelli di architettura di rete sicura ibrida e multi-cloud: cosa succederà dopo

• Scopri di più sui comuni pattern di architettura che puoi realizzare utilizzando i pattern di rete discussi in questo documento.
• Scopri come approcciarti all'ibrido e al multicloud e come scegliere i carichi di lavoro adatti.
• Scopri di più su Google Cloud Cross-Cloud Network una piattaforma di rete globale aperta, sicura e ottimizzata per le applicazioni e gli utenti on-premise e in altri cloud.
• Progetta un'infrastruttura affidabile per i tuoi carichi di lavoro in Google Cloud: Indicazioni di progettazione per aiutarti a proteggere le tue applicazioni da guasti a livello di risorsa, zona e regione.
• Per scoprire di più sulla progettazione di architetture ad alta disponibilità in Google Cloud, consulta i pattern per app resilienti e scalabili.
• Scopri di più sulle possibili opzioni di connettività per collegare il cluster GKE Enterprise in esecuzione nel tuo ambiente on-premise/edge alla Google Cloud rete, nonché sull'impatto della disconnessione temporanea da Google Cloud.