Modelli di architettura di rete sicura ibrida e multi-cloud

Last reviewed 2025-01-23 UTC

Questa pagina fornisce una visualizzazione su una sola pagina di tutte le pagine in Crea architetture ibride e multi-cloud utilizzando Google Cloud. Puoi stampare questa pagina o puoi 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 un insieme di tre documenti. Vengono illustrati i modelli di architettura di rete ibrida e multi-cloud. Questa parte esplora diversi modelli di architettura di rete sicura comuni che puoi utilizzare per le architetture ibride e multi-cloud. Descrive gli scenari per cui questi pattern di networking 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 è composto da queste parti:

• Crea architetture ibride e multi-cloud: descrive la pianificazione di una strategia per la progettazione di una configurazione ibrida e multi-cloud con Google Cloud.
• Modelli di architettura ibrida e multi-cloud: illustra 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 illustrati i modelli di architettura di rete ibrida e multi-cloud da una prospettiva di rete (questo documento).

Il collegamento di ambienti di computing privati a Google Cloud in modo 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 unici dei tuoi carichi di lavoro aziendali. Deve anche essere adatto ai pattern di architettura che intendi applicare. Anche se potrebbe essere necessario personalizzare ogni progetto, esistono pattern comuni che puoi utilizzare come modello.

I pattern di architettura di rete descritti in questo documento non devono essere considerati alternative alla progettazione della landing zone in Google Cloud. Devi invece progettare ed eseguire il deployment dei pattern di architettura che selezioni nell'ambito della progettazione complessiva della landing zone, che copre le seguenti aree: Google Cloud

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

Diverse applicazioni possono utilizzare pattern di architettura di rete diversi, che vengono incorporati come parte di un'architettura di zona di destinazione. In una configurazione multicloud, devi mantenere la coerenza della progettazione della landing zone in tutti gli ambienti.

Questa serie contiene le seguenti pagine:

• Considerazioni sul design
• Pattern di architettura
  • Pattern a specchio
  • Motivo a rete
  • Pattern ad accesso riservato
    • Uscita controllata
    • Ingresso controllato
    • Traffico in entrata e in uscita controllato
  • Handover
• Best practice generali

Collaboratori

Autore: Marwan Al Shawi | Partner Customer Engineer

Altri collaboratori:

• Saud Albazei | Customer Engineer, modernizzazione delle applicazioni
• 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 | EMEA Solution Lead, Application Modernization
• Ammett Williams | Developer Relations Engineer

Pattern di architettura

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

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

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

• Pattern a specchio
• Motivo a rete
• Pattern ad accesso riservato
  • Uscita controllata
  • Ingresso controllato
  • Traffico in uscita e in entrata controllati
• Modello di trasferimento

Pattern speculare

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

Il pattern mirroring 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 computing in modo da rispettare i seguenti requisiti:

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

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 separati sul lato Google Cloud .
• VPC condiviso viene utilizzato per i carichi di lavoro di sviluppo e test. Una rete VPC aggiuntiva viene utilizzata per gli strumenti CI/CD e amministrativi. Con i VPC condivisi:
  • Le applicazioni vengono gestite da team diversi per ambiente e per progetto di servizio.
  • Il progetto host amministra e controlla la comunicazione di rete e i controlli di sicurezza tra gli ambienti di sviluppo e test, nonché all'esterno del VPC.
• Il VPC CI/CD è connesso alla rete che esegue i carichi di lavoro di produzione nel tuo ambiente di computing privato.
• Le regole firewall consentono solo il traffico consentito.
  • Puoi anche utilizzare 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. Cloud Next Generation Firewall Enterprise funziona creando endpoint firewall zonali gestiti da Google che utilizzano la tecnologia di intercettazione dei pacchetti per ispezionare in modo trasparente i workload alla ricerca delle firme delle minacce configurate. Protegge inoltre i carichi di lavoro dalle minacce.
• Consente la comunicazione tra i VPC sottoposti a peering utilizzando indirizzi IP interni.
  • Il peering in questo pattern consente ai sistemi 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 multi-cloud che soddisfano i requisiti della tua attività e delle tue applicazioni. Per consentirti di eseguire il deployment e la gestione dei carichi di lavoro di produzione, questa connessione fornisce la raggiungibilità della rete privata tra i diversi ambienti di computing. Tutti gli ambienti devono avere uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.

Se le istanze negli ambienti di sviluppo e test richiedono l'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 saperne di più sugli Google Cloud strumenti e sulle funzionalità che ti aiutano a creare, testare ed eseguire il deployment 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 comunque conto di tutti i requisiti di comunicazione, il pattern di architettura mirroring offre queste opzioni, descritte nelle sezioni seguenti:

• VPC condiviso per ambiente
• Firewall centralizzato a livello di applicazione
• Topologia hub e 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 CI/CD e strumenti amministrativi che potrebbero essere necessari per soddisfare determinati requisiti di sicurezza dell'organizzazione. Questi requisiti limitano la comunicazione, il dominio amministrativo e controllo dell'accesso per diversi servizi che devono essere gestiti anche da team diversi.

Questo design consente la separazione fornendo l'isolamento a livello di rete e progetto tra i diversi ambienti, il che consente una comunicazione più granulare e controllo dell'accesso dell'accesso 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 workload creati da team diversi per ambiente e per progetto di servizio. Il networking VPC e le relative funzionalità di sicurezza possono essere sottoposti a provisioning e gestiti dai team di operazioni di networking in base alle seguenti possibili strutture:

• 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 basarsi sulla struttura del team, sulle operazioni di sicurezza e sui requisiti di accesso di ciascun team. Puoi applicare questa variante di progettazione alla rete VPC condivisa per ogni opzione di progettazione della landing zone dell'ambiente. Tuttavia, devi considerare i requisiti di comunicazione del pattern mirroring 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 condiviso per ogni ambiente principale, come illustrato nel seguente diagramma:

Firewall centralizzato a livello di applicazione

In alcuni scenari, i requisiti di sicurezza potrebbero richiedere la considerazione del livello 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 ospitata 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 inserire la NVA nel percorso di rete tra Virtual Private Cloud e l'ambiente di computing privato utilizzando più interfacce di rete.

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

La NVA in questa progettazione funge da livello di sicurezza perimetrale. Servono anche come base per l'attivazione dell'ispezione del traffico inline e l'applicazione di criteri di controllo dell'accesso dell'accesso rigorosi.

Per una strategia di sicurezza multilivello solida che includa regole firewall VPC e funzionalità di servizio di prevenzione delle intrusioni, includi un'ulteriore ispezione del traffico e un controllo di sicurezza per i flussi di traffico est-ovest e nord-sud.

Nota: nelle regioni cloud supportate e quando tecnicamente fattibile per la tua progettazione, le NVA possono essere implementate senza richiedere più reti VPC o interfacce appliance. Questo deployment si basa sull'utilizzo del bilanciamento del carico e delle funzionalità di routing basato su criteri. Queste funzionalità consentono un meccanismo indipendente dalla topologia e basato su policy per l'integrazione di NVA nella tua rete cloud. Per maggiori dettagli, vedi Deployment di appliance virtuali di rete (NVA) senza più VPC.

Topologia hub-and-spoke

Un'altra possibile variante di progettazione è l'utilizzo di VPC separati (inclusi i VPC condivisi) per lo sviluppo e le diverse fasi di test. In questa variante, come mostrato nel seguente diagramma, tutti gli ambienti di staging si connettono al VPC CI/CD e amministrativo 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ò aiutarti con 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, vedi Topologia hub-and-spoke con appliance centralizzate e Topologia hub-and-spoke senza appliance centralizzate.

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 nel VPC hub in modo che sia in linea con i tuoi requisiti di connettività.

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

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

Per ulteriori informazioni su quale opzione devi prendere in considerazione nella progettazione, consulta Architettura di rete hub-and-spoke. Un fattore chiave che influenza la scelta della VPN rispetto al peering VPC tra gli spoke e il VPC hub è quando è richiesta la transitività del traffico. La transitività del traffico significa che il traffico di 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 propri 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 quando 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 di criteri di sicurezza a livello di microservizio, l'autenticazione e l'identità del carico di lavoro. L'attendibilità è basata sull'identità e applicata per ogni servizio.

Utilizzando un'architettura proxy distribuita, come un mesh di servizi, i servizi possono convalidare efficacemente i chiamanti e implementare criteri dicontrollo dell'accessoo granulare per ogni richiesta, consentendo un ambiente di microservizi più sicuro e scalabile. Cloud Service Mesh ti offre la flessibilità di disporre di un mesh comune che può includere i tuoi Google Cloud e i deployment on-premise. La mesh utilizza criteri di autorizzazione per proteggere le comunicazioni da servizio a servizio.

Potresti anche incorporare Apigee Adapter for Envoy, che è un deployment leggero del gateway API Apigee all'interno di un cluster Kubernetes, con questa architettura. Apigee Adapter for Envoy è un proxy di servizio e edge open source progettato per 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 reteGoogle Cloud .
• Configurare un mesh multi-cloud o ibrido
  • Esegui il deployment di Cloud Service Mesh in ambienti e cluster.

Best practice per il pattern a specchio

• I sistemi CI/CD necessari per il deployment o la riconfigurazione dei deployment di produzione devono essere ad alta disponibilità, il che significa che tutti i componenti dell'architettura devono essere progettati per fornire il livello di disponibilità del sistema previsto. Per ulteriori informazioni, consulta Affidabilità dell'infrastruttura.Google Cloud
• Per eliminare gli errori di configurazione per i 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 questa progettazione potrebbe richiedere l'incorporazione di più segmenti con diversi livelli di controlli di accesso alla sicurezza.
• Quando progetti una soluzione che include NVA, è importante considerare 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'alta disponibilità e della ridondanza fornite dal fornitore della NVA.
• Se non esporti le route IP on-premise tramite il peering VPC o la VPN nel VPC di sviluppo e test, puoi limitare la raggiungibilità della rete dagli ambienti di sviluppo e test all'ambiente on-premise. Per maggiori informazioni, consulta Scambio di route personalizzate del peering di rete VPC.
• Per i carichi di lavoro con indirizzamento IP privato 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 saperne di più, consulta Ingresso controllato, in questa serie.
• Consulta le best practice generali per i modelli di architettura di rete ibrida e multicloud.

Pattern a rete

Il pattern meshed si basa sulla creazione di un'architettura di rete ibrida. Questa architettura si estende su più ambienti di computing. In questi ambienti, tutti i sistemi possono comunicare tra loro e non sono limitati alla comunicazione unidirezionale in base ai requisiti di sicurezza delle tue applicazioni. Questo pattern di networking si applica principalmente alle architetture ibride a più livelli, multi-cloud partizionate o bursting. È applicabile anche alla progettazione della continuità aziendale per il provisioning di un ambiente di ripristino di emergenza in Google Cloud. In tutti i casi, è necessario connettere gli ambienti di computing in modo da rispettare 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 discussi nelle opzioni di progettazione che seguono.
• Le regole firewall che utilizzi devono consentire il traffico tra origini e destinazioni di indirizzi IP specifici in base ai requisiti dell'applicazione o delle applicazioni per cui è progettato il pattern. Idealmente, puoi utilizzare un approccio di sicurezza multilivello per limitare i flussi di traffico in modo granulare, sia tra gli ambienti di computing sia al loro interno.

Architettura

Il seguente diagramma illustra un'architettura di riferimento di alto livello del pattern mesh.

• Tutti gli ambienti devono utilizzare uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.
• Sul lato Google Cloud , puoi eseguire il deployment dei carichi di lavoro in uno o più VPC condivisi o non condivisi. Per altre possibili opzioni di progettazione di questo pattern, consulta le varianti di progettazione riportate di seguito. La struttura selezionata dei tuoi VPC deve essere in linea con i progetti e la progettazione della gerarchia delle risorse della tua organizzazione.
• La rete VPC di Google Cloud si estende ad altri ambienti di computing. Questi ambienti possono essere on-premise o in un altro cloud. Utilizza una delle opzioni di connettività di rete ibrida e multicloud che soddisfano i requisiti della tua attività e della tua applicazione.

• Limita le comunicazioni solo agli indirizzi IP consentiti delle origini e delle destinazioni. Utilizza una delle seguenti funzionalità o una loro combinazione:

  • 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 della rete o il routing.

Varianti

Il pattern di architettura meshed 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 del livello applicazione centralizzato
• Architettura distribuita Zero Trust basata su microservizi

Un VPC per ambiente

I motivi comuni per prendere in considerazione l'opzione di una sola VPC per ambiente sono i seguenti:

• L'ambiente cloud richiede la separazione a livello di rete delle reti e delle risorse VPC, in linea con la progettazione della gerarchia delle risorse della tua organizzazione. Se è necessaria la separazione dei domini amministrativi, può anche essere combinata con un progetto separato per ambiente.
  • Per gestire centralmente le risorse di rete in una rete comune e fornire l'isolamento di rete tra i diversi ambienti, utilizza una VPC condivisa per ogni ambiente che hai 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 seguente diagramma, la progettazione di una 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ù collegamenti VLAN.

Il pattern mostrato nel diagramma precedente può essere applicato a una zona di destinazione topologia di rete hub-and-spoke. In questa topologia, una o più connessioni ibride possono essere condivise con tutti i VPC spoke. Viene condiviso utilizzando un VPC di transito per terminare sia la connettività ibrida sia gli altri VPC spoke. Puoi anche espandere questo progetto aggiungendo NVA con funzionalità di ispezione firewall di nuova generazione (NGFW) nel VPC di transito, come descritto nella sezione successiva "Utilizzare un firewall di livello applicazione centralizzato".

Utilizzare un firewall del livello applicazione centralizzato

Se i tuoi requisiti tecnici impongono di prendere in considerazione il livello applicazione (livello 7) e l'ispezione approfondita dei pacchetti con funzionalità firewall avanzate che superano le funzionalità di Cloud Next Generation Firewall, puoi utilizzare un'appliance NGFW ospitata in un'NVA. Tuttavia, questa NVA deve soddisfare le esigenze di sicurezza della tua organizzazione. Per implementare questi meccanismi, puoi estendere la topologia per far passare tutto il traffico tra ambienti diversi attraverso un firewall NVA centralizzato, come mostrato nel diagramma seguente.

Puoi applicare il pattern nel seguente diagramma alla progettazione della zona di destinazione utilizzando una topologia hub e spoke con appliance centralizzate:

Come mostrato nel diagramma precedente, la NVA funge da livello di sicurezza perimetrale e da base per l'attivazione dell'ispezione del traffico inline. Inoltre, applica rigide policy di controllo dell'accesso. Per esaminare i flussi di traffico est-ovest e nord-sud, la progettazione di una 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 basata sui microservizi descritta nella sezione pattern mirroring è applicabile anche a questo pattern di architettura.

La differenza principale tra questo pattern e il pattern mirroring è che il modello di comunicazione tra i carichi di lavoro in Google Cloud e altri ambienti può essere avviato da entrambi i lati. Il traffico deve essere controllato e granulare, in base ai requisiti dell'applicazione e di sicurezza utilizzando Service Mesh.

Best practice per il pattern a rete

• Prima di fare qualsiasi altra cosa, decidi la struttura della gerarchia delle risorse e la struttura necessaria 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 un'architettura distribuita Zero Trust quando utilizzi Kubernetes all'interno del tuo ambiente di computing privato eGoogle Cloud.
• Quando utilizzi NVA centralizzati nella progettazione, devi definire più segmenti con diversi livelli di controlli di accesso alla sicurezza e criteri di ispezione del traffico. Basali sui requisiti di sicurezza delle tue applicazioni.
• Quando progetti una soluzione che include NVA, è importante considerare 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'alta disponibilità e della ridondanza fornite dal Google Cloud fornitore di sicurezza che fornisce le tue NVA.
• Per garantire maggiore privacy, 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 organizzazione.
• Se la progettazione della tua soluzione richiede l'esposizione di un'applicazione basata su Google Cloud a internet pubblico, prendi in considerazione i consigli di progettazione descritti in Networking per la distribuzione di applicazioni rivolte a internet.
• Per proteggere i 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 di rete VPC. Google Cloud Inoltre, puoi estendere i service perimeter a un ambiente ibrido tramite una VPN autorizzata o Cloud Interconnect. Per saperne di più sui vantaggi dei perimetri di servizio, consulta la sezione Panoramica dei Controlli di servizio VPC.
• Consulta le best practice generali per i pattern di networking ibrido 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 pattern controllati descritti negli altri documenti di questa serie.

Pattern con limitazioni

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

• Uscita controllata

• Ingresso controllato

• In uscita e in entrata controllati (controllati bidirezionali in entrambe le direzioni)

Come accennato in precedenza in questa guida, i pattern 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 uno o più pattern contemporaneamente. Il deployment specifico dell'architettura selezionata è determinato dai requisiti di comunicazione specifici di ogni pattern controllato.

Nota :in generale, il pattern gated può essere applicato o incorporato con l'opzione di progettazione della landing zone che espone i servizi in un modello consumer-producer.

Questa serie descrive ogni pattern controllato e le relative possibili opzioni di progettazione. Tuttavia, un'opzione di progettazione comune applicabile a tutti i pattern controllati è 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 leggero del gateway Apigee all'interno di un cluster Kubernetes. Apigee Adapter for Envoy è un proxy di servizio e perimetrale open source molto diffuso progettato per applicazioni cloud-first. Questa architettura controlla le comunicazioni sicure consentite tra servizi e la direzione della comunicazione a livello di servizio. Le policy di comunicazione del traffico possono essere progettate, ottimizzate e applicate a livello di servizio in base al pattern selezionato.

I pattern controllati 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 modifiche alla progettazione o al routing. L'ispezione è soggetta alle applicazioni specifiche a cui si accede, al modello di comunicazione e ai requisiti di sicurezza. Se i requisiti di sicurezza richiedono l'ispezione approfondita dei pacchetti e del livello 7 con meccanismi di firewalling avanzati che superano le funzionalità di Cloud Next Generation Firewall, puoi utilizzare un firewall di nuova generazione (NGFW) centralizzato ospitato 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 controllati può richiedere l'introduzione di più zone di sicurezza nella progettazione della rete, ognuna con livelli di controllo dell'accesso distinti.

Traffico in uscita controllato

L'architettura del pattern di networking gated egress 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. Lo fa 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 proxy API oppure un bilanciatore del carico che funge da facade per i carichi di lavoro esistenti. Puoi eseguire il deployment della funzionalità di gateway API in un segmento di rete perimetrale isolato, ad esempio una rete perimetrale.

Il pattern di networking gated egress 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, il networking con uscita controllata consente di mantenere un livello di sicurezza più elevato all'interno dell'ambiente di computing on-premise. Il pattern richiede di connettere gli ambienti di computing in modo da soddisfare i seguenti requisiti di comunicazione:

• I workload che implementi 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.
• Altri sistemi nell'ambiente di calcolo privato non sono raggiungibili direttamente da Google Cloud.
• La comunicazione dall'ambiente di calcolo privato a qualsiasi workload di cui è stato eseguito il deployment in Google Cloud non è consentita.
• Il traffico verso le API private in altri ambienti viene avviato solo dall'ambiente Google Cloud .

Questa guida si concentra su ambienti ibridi e multi-cloud connessi tramite una rete ibrida privata. Se i requisiti di sicurezza della tua organizzazione lo consentono, le chiamate API alle API di destinazione remote con indirizzi IP pubblici possono essere raggiunte direttamente su 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 per il backend del livello API.
• Filtro della lista consentita di indirizzi IP configurato per consentire la comunicazione con origini e destinazioni API predefinite da entrambe le parti.

Per proteggere un proxy API, considera questi altri aspetti di sicurezza. Per saperne di più, consulta 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 scorrono nel diagramma precedente nel seguente modo:

• Sul lato Google Cloud , puoi eseguire il deployment dei carichi di lavoro in virtual private cloud (VPC). I VPC possono essere singoli o multipli (condivisi o non condivisi). Il deployment deve essere in linea con i progetti e la progettazione della gerarchia delle risorse della tua organizzazione.
• Le reti VPC dell'ambiente Google Cloud vengono estese agli altri ambienti di computing. Gli ambienti possono essere on-premise o in un altro cloud. Per facilitare la comunicazione tra gli ambienti utilizzando indirizzi IP interni, utilizza una connettività di rete ibrida e multi-cloud adeguata.

• Per limitare il traffico proveniente da indirizzi IP VPC specifici e destinato a gateway remoti o bilanciatori del carico, utilizza il filtro della lista consentita di indirizzi IP. Il traffico di ritorno da queste connessioni è consentito quando si utilizzano 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 uscita controllata può essere combinato con altri approcci per soddisfare diversi requisiti di progettazione che tengano comunque conto dei requisiti di comunicazione di questo pattern. Il pattern offre le seguenti opzioni:

• Utilizzare 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 in Google Cloud. Come mostrato nel diagramma precedente, puoi farlo implementando 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à del frontend globale come Cloud Load Balancing, Cloud CDN (se accessibile tramite Cloud Interconnect) e Cross-Cloud Interconnect migliorano la velocità con cui gli utenti possono accedere alle applicazioni con backend ospitati negli ambienti on-premise e in altri ambienti cloud.

L'ottimizzazione delle velocità di distribuzione dei contenuti viene ottenuta distribuendo queste applicazioni dai Google Cloud Point of Presence (PoP). Google Cloud I PoP sono presenti in 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 Delivering high-performing APIs with Apigee and Cloud CDN su YouTube:

• Ridurre la latenza.
• Ospita le API a livello globale.
• Aumenta la disponibilità per il traffico di picco.

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 client, elabora il traffico e poi lo instrada a un backend Private Service Connect.
• Un backend di Private Service Connect consente a un bilanciatore del carico Google Cloud di inviare 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 i gruppi di endpoint di rete (NEG) di Private Service Connect.

Il networking verso sud viene stabilito tramite:

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

• Il bilanciamento del carico interno viene implementato con gruppi di endpoint di rete con connettività ibrida (NEG di connettività ibrida).

• I servizi ibridi vengono accessibili tramite 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 deployment di Private Service Connect.

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

Esporre servizi remoti utilizzando Private Service Connect

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

• Non utilizzi una piattaforma API o vuoi evitare di connettere l'intera rete VPC direttamente a un ambiente esterno per i seguenti motivi:
  • Hai limitazioni di sicurezza o requisiti di conformità.
  • Hai una sovrapposizione di intervalli di indirizzi IP, ad esempio in uno scenario di fusione e acquisizione.
• Per abilitare comunicazioni unidirezionali sicure tra client, applicazioni e servizi nei vari ambienti anche quando hai una scadenza breve.
• Potresti dover fornire la connettività a più VPC consumer tramite un VPC del produttore di servizi (VPC di transito) per offrire modelli di servizio multi-tenant o single-tenant altamente scalabili, per 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 tutte le regioni e tramite la connettività ibrida. Questa astrazione facilita l'integrazione di risorse provenienti da diversi cloud e ambienti on-premise in un modello di connettività ibrida e multi-cloud. Puoi accelerare l'integrazione delle applicazioni ed esporre in modo sicuro le applicazioni che risiedono 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 collegamento 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 funge da VPC di transito in questa progettazione.

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 diagramma seguente. Questa opzione di progettazione per le comunicazioni unidirezionali offre un'alternativa al peering a un VPC di transito.

Nell'ambito della progettazione nel diagramma precedente, più frontend, backend o endpoint possono connettersi allo stesso service attachment, il che consente a più reti VPC o a più consumer di accedere allo stesso servizio. Come illustrato nel diagramma seguente, puoi rendere l'applicazione accessibile a più VPC. Questa accessibilità può essere utile negli scenari di servizi multi-tenant in cui il tuo servizio viene utilizzato da più VPC consumer 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 che risiedono in ambienti diversi. La connessione Private Service Connect nel seguente diagramma consente di evitare il problema di sovrapposizione degli indirizzi IP. Lo fa senza richiedere il provisioning o la gestione di componenti di rete aggiuntivi, come Cloud NAT o una NVA, per eseguire la conversione dell'indirizzo IP. Per un esempio di configurazione, vedi Pubblicare un servizio ibrido utilizzando Private Service Connect.

Il design presenta i seguenti vantaggi:

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

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

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

Il client che si connette all'endpoint Private Service Connect può trovarsi nella stessa regione dell'endpoint o in una regione diversa. Questo approccio potrebbe essere utilizzato per fornire alta disponibilità tra i servizi ospitati in più regioni o per accedere ai servizi disponibili in una singola regione da altre regioni. Quando si accede a un endpoint Private Service Connect da risorse ospitate in altre regioni, al traffico destinato agli endpoint con accesso globale vengono applicati i costi in uscita tra regioni.

Nota :per eseguire controlli di integrità distribuiti e facilitare la connessione di più VPC agli 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, vedi Concatenamento esplicito dei bilanciatori del carico L7 con PSC.

Google Cloud

Best practice

• Considerare Apigee e Apigee Hybrid come soluzione per la piattaforma API offre diversi vantaggi. Fornisce un livello proxy e un'astrazione o una facciata per le API dei servizio di backend, combinati con funzionalità di sicurezza, limitazione della velocità, quote e analisi.
  • Utilizza l'adattatore Apigee per Envoy con un'architettura di deployment Apigee Hybrid con Kubernetes, se applicabile ai tuoi requisiti e all'architettura.
• La progettazione di VPC e progetti in Google Cloud deve essere basata sulla gerarchia delle risorse e sui requisiti del modello di comunicazione sicuro.
• Quando vengono utilizzate API con gateway API, devi utilizzare anche una lista consentita di indirizzi IP. Una lista consentita limita le comunicazioni a indirizzi IP specifici di origine e destinazione dei consumatori di API e dei gateway API che potrebbero essere ospitati in ambienti diversi.
• Utilizza le regole firewall VPC o le policy 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 livello di sicurezza aggiuntivo per proteggere da attacchi DDoS e minacce alla sicurezza del livello applicazione.

• Se le istanze richiedono l'accesso a internet, utilizza Cloud NAT nel VPC dell'applicazione (consumer) per consentire ai carichi di lavoro di accedere a internet. In questo modo, puoi evitare di assegnare alle istanze VM indirizzi IP pubblici esterni nei sistemi di cui è stato eseguito il deployment dietro un gateway API o un bilanciamento 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 ibrido e multicloud.

Ingress controllato

L'architettura del pattern gated ingress si basa sull'esposizione di API selezionate dei carichi di lavoro in esecuzione in Google Cloud all'ambiente di computing privato senza esporle a internet pubblico. Questo pattern è la controparte del pattern uscita controllata ed è adatto agli scenari ibrido edge, ibrido a livelli e multi-cloud partizionato.

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

• I workload che implementi nell'ambiente di computing privato o in altri ambienti cloud possono comunicare con il gateway API o il bilanciatore del carico utilizzando indirizzi IP interni. Non è possibile raggiungere altri sistemi diGoogle Cloud .
• La comunicazione da 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 controllato.

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

• Sul lato Google Cloud , esegui il deployment dei carichi di lavoro in un VPC dell'applicazione (o in più VPC).
• La rete dell'ambiente Google Cloud si estende ad altri ambienti di computing (on-premise o su un altro cloud) utilizzando la connettività di rete ibrida o multicloud per facilitare la comunicazione tra gli ambienti.
• Se vuoi, puoi utilizzare un VPC di transito per eseguire le seguenti operazioni:
  • Fornisci ulteriori livelli di sicurezza perimetrale per consentire l'accesso a API specifiche al di fuori del VPC dell'applicazione.
  • Instrada il traffico verso gli indirizzi IP delle API. Puoi creare regole 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 gateway API o un bilanciatore del carico (proxy o bilanciatore del carico delle applicazioni) per fornire un livello proxy e un livello di astrazione o una facciata per le API di servizio. Se devi distribuire il traffico su più istanze del gateway API, puoi utilizzare un bilanciatore del carico di rete passthrough interno.
• Fornisci un 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 la progettazione 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 ingresso controllato:

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

Nel design:

• La connettività di rete in direzione nord (per il traffico proveniente da altri ambienti) passa attraverso un endpoint Private Service Connect nel VPC dell'applicazione associato al VPC Apigee.
• Nel VPC dell'applicazione, un bilanciatore del carico interno viene utilizzato per esporre le API dell'applicazione tramite un endpoint Private Service Connect presentato nel VPC Apigee. Per maggiori informazioni, consulta Architettura con peering VPC disattivato.

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

  Inoltre, puoi limitare la pubblicità della subnet 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 attraverso l'endpoint Private Service Connect e il gateway API.

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

Come illustrato nel diagramma precedente:

• La connettività di rete in direzione nord (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.
• Nel VPC dell'applicazione, un bilanciatore del carico interno (ILB nel diagramma) viene utilizzato per esporre l'applicazione tramite un endpoint Private Service Connect nel VPC Apigee.

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

Varianti

Il pattern di architettura gated ingress può essere combinato con altri approcci per soddisfare diversi requisiti di progettazione, 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 sulla rete internet pubblica, Private Service Connect offre una soluzione. Come mostrato nel diagramma seguente, consente la raggiungibilità alle API di Google supportate e ai servizi (inclusi Google Maps, Google Ads e Google Cloud) da ambienti on-premise o da altri ambienti cloud tramite una connessione di rete ibrida utilizzando l'indirizzo IP dell'endpoint Private Service Connect. Per ulteriori informazioni sull'accesso alle API di Google tramite gli endpoint Private Service Connect, consulta Informazioni sull'accesso alle API di Google tramite endpoint.

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

È possibile accedere alle API di Google utilizzando endpoint o backend. Gli endpoint consentono di scegliere come target un bundle di API di Google. I backend ti consentono di scegliere come target un'API Google regionale specifica.

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 livelli, potresti dover eseguire il deployment dei backend in Google Cloud mantenendo i frontend in ambienti di computing privati. Sebbene meno comune, questo approccio è applicabile quando si ha a che fare con frontend monolitici e pesanti che potrebbero basarsi su componenti legacy. O, più comunemente, quando si gestiscono applicazioni distribuite in 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 bilanciatore del carico o un gateway API locale nell'ambiente on-premise privato o in altri ambienti cloud per esporre direttamente il frontend dell'applicazione a internet pubblico. L'utilizzo di Private Service Connect in Google Cloud facilita 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 gateway API 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 altri ambienti, puoi utilizzare Apigee su Google Cloud con Apigee Hybrid. Per ulteriori informazioni, vedi Gateway API distribuiti.

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

In alcuni scenari potrebbe essere necessario esporre API dai backend delle applicazioni ospitati in Google Cloud in diverse reti VPC. Come illustrato nel diagramma seguente, un VPC hub funge da punto centrale di interconnessione per i vari VPC (spoke), consentendo una comunicazione sicura tramite connettività ibrida privata. Facoltativamente, le funzionalità del gateway API locale in altri ambienti, come Apigee Hybrid, possono essere utilizzate 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 di NGFW, la NVA con funzionalità NGFW è integrata facoltativamente nella progettazione. Potresti richiedere queste funzionalità per rispettare requisiti di sicurezza specifici e gli standard delle norme di sicurezza della tua organizzazione.

• Questo progetto presuppone che i VPC spoke non richiedano la comunicazione diretta da VPC a VPC.

  • Se è necessaria la comunicazione hub-spoke, puoi utilizzare NVA per facilitare questa comunicazione.
  • Se hai backend diversi in VPC diversi, puoi utilizzare Private Service Connect per esporre questi backend al VPC Apigee.
  • Se il peering VPC viene utilizzato per la connettività northbound e southbound tra i VPC spoke e il VPC hub, devi considerare la limitazione di transitività del networking VPC tramite il peering VPC. Per superare questa limitazione, puoi utilizzare una delle seguenti opzioni:
    • Per interconnettere i VPC, utilizza una NVA.
    • Se applicabile, considera il modello Private Service Connect.
    • Per stabilire la connettività tra il VPC Apigee e i backend che si trovano in altri progettiGoogle Cloud nella stessa organizzazione senza componenti di rete aggiuntivi, utilizza il VPC condiviso.

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

• Se la progettazione non include la NVA, puoi terminare la connettività ibrida nel VPC hub.

• Se sono richieste determinate funzionalità di bilanciamento del carico o funzionalità di sicurezza, come l'aggiunta della protezione DDoS o del WAF di Google Cloud Armor, puoi facoltativamente eseguire il deployment di un bilanciatore del carico delle applicazioni esterno perimetrale tramite un VPC esterno prima di instradare le richieste dei client esterni ai backend.

Best practice

• Per le situazioni in cui le richieste client da internet devono essere ricevute localmente da un frontend ospitato in un ambiente on-premise privato o in un altro ambiente cloud, valuta la possibilità di utilizzare Apigee Hybrid come soluzione di gateway API. Questo approccio facilita anche la migrazione senza problemi della soluzione a un ambiente completamente Google Cloudospitato, mantenendo la coerenza della piattaforma API (Apigee).
• Utilizza l'adattatore Apigee per Envoy con un'architettura di deployment Apigee Hybrid con Kubernetes, se applicabile ai tuoi requisiti e all'architettura.
• La progettazione di VPC e progetti in Google Cloud deve seguire i requisiti della gerarchia delle risorse e del modello di comunicazione sicuro, come descritto in questa guida.
• L'incorporamento di un VPC di transito in questa progettazione offre la flessibilità di eseguire il provisioning di misure di sicurezza perimetrale aggiuntive e della 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 proteggere i servizi nei tuoi progetti e contribuire a mitigare il rischio di esfiltrazione di dati, utilizza Controlli di servizio VPC per specificare i perimetri di servizio a livello di progetto o di rete VPC. Google Cloud
  • Se necessario, puoi estendere i service perimeter a un ambiente ibrido tramite una VPN o Cloud Interconnect. Per maggiori informazioni sui vantaggi dei perimetri di servizio, consulta Panoramica dei Controlli di servizio VPC.
• Utilizza le regole firewall VPC o le policy 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 (consumer) possono limitare l'accesso dalle istanze VM all'indirizzo IP o alla subnet degli endpoint. Per ulteriori informazioni sulle regole firewall VPC in generale, consulta Regole firewall VPC.
• Quando progetti una soluzione che include NVA, è importante considerare 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'alta disponibilità e della ridondanza fornite dal fornitore della NVA.
• Per rafforzare la sicurezza perimetrale e proteggere il gateway API distribuito nell'ambiente corrispondente, puoi implementare facoltativamente meccanismi di bilanciamento del carico e web application firewall nell'altro ambiente di computing (ibrido o altro cloud). Implementa queste opzioni nella rete perimetrale direttamente connessa a internet.
• Se le istanze richiedono l'accesso a internet, utilizza Cloud NAT nel 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 gateway API 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 ibrido e multicloud.

Uscita controllata e ingresso controllato

Il pattern uscita controllata e ingresso controllato utilizza una combinazione di uscita controllata e ingresso controllato per 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 audit delle chiamate API.

La principale differenza tra questo pattern e il pattern mesh risiede nella sua applicazione a scenari che richiedono esclusivamente l'utilizzo bidirezionale dell'API 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 a indirizzi IP specifici, le reti nei vari ambienti non devono essere allineate nella progettazione. Gli scenari comuni applicabili includono, a titolo esemplificativo:

• Fusioni e acquisizioni.
• Integrazioni di applicazioni con 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 che implementi in Google Cloud possono comunicare con il gateway API (o indirizzi IP di destinazione specifici) utilizzando indirizzi IP interni. Gli altri sistemi implementati nell'ambiente di computing privato non sono raggiungibili.
• Al contrario, i workload che implementi in altri ambienti di computing possono comunicare con il gateway API lato Google Cloud(o con un indirizzo IP endpoint pubblicato specifico) utilizzando indirizzi IP interni. Non è possibile raggiungere altri sistemi implementati in Google Cloud .

Architettura

Il seguente diagramma mostra un'architettura di riferimento per il pattern di uscita controllata e ingresso controllato:

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

• Sul lato Google Cloud , esegui il deployment dei carichi di lavoro in un VPC (o in un VPC condiviso) senza esporli direttamente a internet.
• La rete dell'ambiente Google Cloud viene estesa ad altri ambienti di computing. Questo 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, attivando l'accesso a indirizzi IP di destinazione specifici, puoi utilizzare un VPC di transito per aggiungere un livello di sicurezza perimetrale al di fuori del 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 per consentire o vietare l'accesso a determinate API da origini specifiche prima di raggiungere il VPC dell'applicazione.
• È necessario accedere alle API tramite un gateway API o un bilanciatore del carico per fornire un livello proxy e un'astrazione o una facade 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 di backend dell'applicazione (o di un sottoinsieme di backend dell'applicazione) in Google Cloud mentre gli altri componenti di backend e frontend vengono ospitati in ambienti on-premise o in altri cloud (pattern ibrido a più livelli o pattern multi-cloud partizionato). Man mano che le applicazioni si evolvono e vengono migrate nel 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 cloud provider. Inoltre, alcune applicazioni potrebbero 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à di connettività ibrida e multi-cloud di Cloud Load Balancing esterno possono essere utilizzate per terminare le richieste degli utenti e instradarle a frontend o backend in altri ambienti. Questo routing avviene tramite una connessione di rete ibrida, come illustrato nel diagramma seguente. 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, facilitata da un bilanciatore del carico interno (ILB nel diagramma).

L'utilizzo del Google Cloud design nel diagramma precedente è utile per i seguenti motivi:

• Facilita la comunicazione bidirezionale tra Google Cloud, on-premise e altri ambienti cloud utilizzando API predefinite su entrambi i lati che si allineano al 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 raggiungere i seguenti obiettivi, puoi utilizzare le funzionalità avanzate di bilanciamento del carico e sicurezza di Google Cloud distribuite nei point of presence (PoP):
• Riduci le spese in conto capitale e semplifica le operazioni utilizzando 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.
• Se vuoi, puoi incorporare Private Service Connect nel tuo progetto. In questo modo, puoi accedere in modo privato e granulare alle API di servizio o ai servizi pubblicati da altri ambienti senza attraversare internet pubblico. Google Cloud

Varianti

I pattern di architettura uscita controllata e ingresso controllato 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 API bidirezionale utilizzando Private Service Connect
• Comunicazione bidirezionale utilizzando interfacce ed endpoint Private Service Connect

Gateway API distribuiti

In scenari come quello basato sul pattern multicloud partizionato, le applicazioni (o i componenti delle applicazioni) 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 all'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 anche richiedere 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 gateway API localizzato in ogni ambiente. La gestione della piattaforma API è centralizzata in Google Cloud. Questo design contribuisce a imporre misurecontrollo dell'accessoo dell'accesso rigorose in cui solo gli indirizzi IP preapprovati (API di destinazione e di destinazione o indirizzi IP endpoint Private Service Connect) possono comunicare tra Google Cloud e gli altri ambienti.

Il seguente elenco 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 e i proxy API all'interno di ogni ambiente gestiscono le richieste API client e dell'applicazione in direzioni diverse in più ambienti.
  • La funzionalità del gateway API in Google Cloud (Apigee) espone i componenti dell'applicazione (frontend o backend) ospitati in Google Cloud.
  • La funzionalità del gateway API 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 un VPC di transito. Un VPC di transito può fornire flessibilità per separare le problematiche ed eseguire l'ispezione di sicurezza e la connettività ibrida in una rete VPC separata. Dal punto di vista della raggiungibilità dell'indirizzo IP, un VPC di transito (a cui è collegata la connettività ibrida) facilita i seguenti requisiti per mantenere la raggiungibilità end-to-end:

• Gli indirizzi IP delle API di destinazione devono essere pubblicizzati negli altri ambienti in cui sono ospitati 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 del richiedente 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 del cliente. La progettazione consente a richieste API specifiche provenienti da carichi di lavoro ospitati all'interno del VPC dell'applicazione Google Cloud di essere instradate tramite il VPC di transito. In alternativa, puoi utilizzare un endpoint Private Service Connect nel VPC dell'applicazione associato a un bilanciatore del carico con un backend del gruppo di endpoint di rete ibrido nel VPC di transito. Questa configurazione è descritta nella sezione successiva: comunicazione API bidirezionale tramite Private Service Connect.

Comunicazione API bidirezionale tramite Private Service Connect

A volte, le aziende potrebbero non aver bisogno di utilizzare immediatamente un gateway API (come Apigee) o potrebbero voler aggiungerlo in un secondo momento. Tuttavia, potrebbero esserci requisiti aziendali per abilitare 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 società potrebbero avere i propri workload ospitati in ambienti diversi (Google Cloud, on-premise o in altri cloud) e devono evitare la sovrapposizione di 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 tutte le regioni e tramite la connettività ibrida. Questa astrazione facilita l'integrazione di risorse provenienti da diversi cloud e ambienti on-premise in un modello di connettività ibrida e multi-cloud. Consente inoltre l'assemblaggio di applicazioni in ambienti multi-cloud e on-premise. Ciò può soddisfare diversi requisiti di comunicazione, ad esempio l'integrazione di 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à separato, idealmente tramite chiamate API.

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

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

Comunicazione bidirezionale utilizzando interfacce ed endpoint Private Service Connect

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

Per accedere a un determinato servizio, ad esempio per recuperare dati da origini dati che possono essere ospitate all'interno del VPC consumer o all'esterno, 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 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 consumer come se si trovassero localmente nel VPC producer.

Un'interfaccia Private Service Connect è un'interfaccia di rete collegata al VPC consumer (di transito). È possibile raggiungere destinazioni esterne raggiungibili dalla 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 diagramma seguente:

Se il VPC consumer è un'organizzazione o un'entità esterna, come un'organizzazione di terze parti, in genere non avrai la possibilità di proteggere la comunicazione con l'interfaccia Private Service Connect nel VPC consumer. In questo scenario, puoi definire le norme di sicurezza nel sistema operativo guest della VM dell'interfaccia Private Service Connect. Per ulteriori informazioni, vedi Configurare la sicurezza per le interfacce Private Service Connect. In alternativa, puoi valutare un approccio alternativo se non è conforme alla conformità o agli standard di sicurezza della tua organizzazione.

Best practice

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

  • Questo approccio facilita anche la migrazione della soluzione a un ambiente completamente Google Cloudospitato, 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 si trovano in configurazioni ibride o multicloud a lungo termine o permanenti, valuta quanto segue:

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

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

• Prima di progettare i percorsi di connettività e routing, devi innanzitutto identificare il traffico o le richieste API che devono essere indirizzati a un gateway API locale o remoto, insieme agli ambienti di origine e di destinazione.

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

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

• Utilizza le regole firewall di Virtual Private Cloud (VPC) o i 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 (consumer) possono limitare l'accesso dalle istanze VM all'indirizzo IP o alla subnet degli 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 ed esporlo a internet pubblica.

  • 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 ibrido e multicloud.

Pattern di trasferimento

Con il pattern di trasferimento, l'architettura si basa sull'utilizzo di servizi di archiviazione forniti daGoogle Cloudper connettere un ambiente di computing privato ai progetti in Google Cloud. Questo pattern si applica principalmente alle configurazioni che seguono il pattern di architettura ibrida multi-cloud di Analytics, in cui:

• I workload in esecuzione in un ambiente di computing privato o in un altro cloud caricano i dati in posizioni di archiviazione condivise. A seconda dei casi d'uso, i caricamenti potrebbero avvenire in blocco o in incrementi più piccoli.
• Google Cloud-hosted workloads or other Google services (data analytics and artificial intelligence services, for example) consume data from the shared storage locations and process it in a streaming or batch fashion.

Architettura

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

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

• Sul lato Google Cloud , esegui il deployment dei carichi di lavoro in un 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 computing privato e li rende disponibili per l'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 i controlli di servizio VPC per limitare l'accesso ai servizi e ridurre al minimo i rischi ingiustificati di esfiltrazione di dati dai servizi Google Cloud .
• In questa architettura, la comunicazione con i bucket Cloud Storage o Pub/Sub viene condotta su reti pubbliche o tramite connettività privata utilizzando VPN, Cloud Interconnect o Cross-Cloud Interconnect. In genere, la decisione su come connettersi dipende da diversi aspetti, ad esempio:
  • Volume di traffico previsto
  • Se si tratta di una configurazione temporanea o permanente
  • Requisiti di sicurezza e conformità

Variante

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. In particolare, fornisce l'accesso a Cloud Storage, BigQuery e altre API dei servizi Google. Questo approccio richiede l'indirizzamento IP privato tramite una connessione di rete ibrida e multicloud come VPN, Cloud Interconnect e Cross-Cloud Interconnect.

Best practice

• Limitare 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 del tuo caso d'uso, queste soluzioni sono progettate per spostare, integrare e trasformare i dati in modo efficiente.

• Valuta i diversi fattori che influenzano le opzioni di trasferimento dei dati, come costo, tempo di trasferimento previsto e sicurezza. Per ulteriori informazioni, vedi Valutare le opzioni di trasferimento.

• Per ridurre al minimo la latenza ed evitare il trasferimento e lo spostamento di grandi volumi di dati su internet pubblico, valuta la possibilità di utilizzare Cloud Interconnect o Cross-Cloud Interconnect, incluso l'accesso agli endpoint Private Service Connect all'interno di Virtual Private Cloud per le API di Google.

• Per proteggere i servizi nei tuoi progetti e ridurre il rischio di esfiltrazione di dati, utilizza i Controlli di servizio VPC. Google Cloud Questi controlli del servizio possono specificare 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 saperne di più sui vantaggi dei perimetri di servizio, consulta Panoramica dei Controlli di servizio VPC.

• Comunica con i carichi di lavoro di analisi dei dati pubblicati pubblicamente 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 che queste istanze siano raggiungibili direttamente da internet.

• Se è necessario l'accesso a internet, Cloud NAT può essere utilizzato nello stesso 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 multicloud.

Best practice generali

Quando progetti e esegui l'onboarding di identità cloud, gerarchia delle risorse e reti della zona di destinazione, tieni conto dei suggerimenti di progettazione riportati in Progettazione della zona di destinazione in Google Cloud e delle best practice di sicurezza trattate nel progetto base per la sicurezza. Google Cloud 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 zona di destinazione Google Cloud
• Google Cloud Well-Architected Framework: sicurezza, privacy e conformità

Inoltre, tieni presente le seguenti best practice generali:

• Quando scegli un'opzione di connettività di rete ibrida o multicloud, considera i 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 Pattern per la connessione di altri fornitori di servizi cloud con Google Cloud.

• Utilizza i VPC condivisi su Google Cloud anziché più VPC quando è appropriato e in linea con i requisiti di progettazione della gerarchia delle risorse. Per ulteriori informazioni, 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 oltre 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 ai tuoi requisiti, devi seguire i modi consigliati per integrare Google Cloud il tuo sistema di gestione delle identità.

  • Vedi anche Modelli per l'autenticazione degli utenti della forza lavoro in un ambiente ibrido.

• Quando progetti i tuoi ambienti on-premise e cloud, considera l'indirizzamento IPv6 fin dall'inizio e tieni conto dei servizi che lo supportano. Per saperne di più, consulta An Introduction to IPv6 on Google Cloud. Riassume i servizi supportati al momento della stesura del post del blog.

• Quando progetti, implementi e gestisci le regole firewall VPC, puoi:

  • Utilizza il filtro basato su service account anziché quello basato su tag di rete se hai bisogno di un controllo rigoroso su come le regole firewall vengono applicate alle VM.
  • Utilizza le policy 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, vedi Criteri firewall gerarchici.
  • Utilizza oggetti di geolocalizzazione nella policy firewall quando devi filtrare il traffico IPv4 esterno e IPv6 esterno in base a regioni o località geografiche specifiche.
  • Utilizza Threat Intelligence per le regole dei criteri firewall se devi proteggere la tua rete consentendo o bloccando il traffico in base ai dati di Threat Intelligence, come indirizzi IP dannosi noti o in base agli intervalli di indirizzi IP del cloud pubblico. Ad esempio, puoi consentire il traffico da intervalli di indirizzi IP cloud pubblici specifici se i tuoi servizi devono comunicare solo con quel cloud pubblico. Per saperne di più, consulta Best practice per le regole firewall.

• Devi sempre progettare la sicurezza del cloud e della rete utilizzando un approccio di sicurezza multilivello prendendo in considerazione ulteriori livelli di sicurezza, come i seguenti:

  • Google Cloud Armor
  • Cloud Intrusion Detection System
  • Cloud Next Generation Firewall IPS
  • Threat Intelligence per le regole dei criteri firewall

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

• Quando decidi dove deve essere eseguita la risoluzione DNS in una configurazione ibrida, ti consigliamo di utilizzare due sistemi DNS autorevoli per il tuo ambiente privatoGoogle Cloud e per le tue risorse on-premise ospitate dai server DNS esistenti nel tuo ambiente on-premise. Per ulteriori informazioni, vedi Scegliere dove viene eseguita la risoluzione DNS.

• Ove 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 servizio di backend, in combinazione con funzionalità di sicurezza, limitazione della frequenza, quote e analisi.

• Una piattaforma API (gateway o proxy) e il bilanciatore del carico delle applicazioni non si escludono a vicenda. A volte, l'utilizzo combinato di gateway API e bilanciatori del carico può fornire una soluzione più solida e sicura per la gestione e la distribuzione del traffico API su larga scala. L'utilizzo dei gateway API Cloud Load Balancing ti consente di eseguire le seguenti operazioni:

  • Fornisci API ad alto rendimento con Apigee e Cloud CDN per:

    • Ridurre la latenza
    • Ospitare le API a livello globale

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

      Per saperne di più, guarda il video Delivering high-performing APIs with Apigee and Cloud CDN su YouTube.

  • Implementa la gestione avanzata del traffico.

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

  • Gestisci il bilanciamento del carico efficiente tra i gateway in più regioni. Per saperne di più, guarda Securing APIs and Implementing multi-region failover with PSC and Apigee.

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

• Quando viene utilizzato Cloud Load Balancing, devi utilizzare le relative funzionalità di ottimizzazione della capacità dell'applicazione, ove applicabile. In questo modo, puoi risolvere alcuni problemi di capacità che possono verificarsi nelle applicazioni distribuite a livello globale.

  • Per un approfondimento sulla latenza, consulta Ottimizzazione della latenza delle applicazioni con il bilanciamento del carico.

• Mentre Cloud VPN cripta il traffico tra gli ambienti, con Cloud Interconnect devi utilizzare MACsec o VPN ad alta disponibilità su Cloud Interconnect per criptare il traffico in transito a livello di connettività. Per ulteriori informazioni, vedi Come posso criptare il mio traffico su Cloud Interconnect.

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

• Se hai bisogno di un volume di traffico maggiore rispetto a quello che può supportare un singolo tunnel VPN tramite una connettività ibrida VPN, puoi prendere in considerazione l'utilizzo dell'opzione di routing VPN ad alta disponibilità attivo/attivo.

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

• Quando ti connetti Google Cloud alle risorse 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à di Direct Peering con Cloud Interconnect e Carrier Peering con Cloud Interconnect.

• Consenti uno spazio di indirizzi IP sufficiente dal tuo spazio di indirizzi IP RFC 1918 esistente per ospitare i tuoi sistemi ospitati sul cloud.

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

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

  • Esegui il provisioning e utilizza i tuoi indirizzi IPv4 pubblici per le risorseGoogle Cloud utilizzando Bring Your Own IP (BYOIP) su Google.

• Se la progettazione della tua soluzione richiede l'esposizione di un'applicazione basata suGoogle Clouda internet pubblico, prendi in considerazione i consigli di progettazione illustrati in Networking per la distribuzione di applicazioni con accesso 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.
  • Se è possibile stabilire connessioni tra consumatori e produttori.
  • Quale traffico di rete è autorizzato ad accedere a queste connessioni.

  Per ulteriori informazioni, vedi Sicurezza di Private Service Connect.

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

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

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

Modelli di architettura di rete sicura ibrida e multi-cloud: passaggi successivi

• Scopri di più sui pattern di architettura comuni che puoi realizzare utilizzando i pattern di networking descritti in questo documento.
• Scopri come affrontare l'approccio ibrido e 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 applicazioni e utenti on-premise e in altri cloud.
• Progetta un'infrastruttura affidabile per i tuoi carichi di lavoro in Google Cloud: Indicazioni di progettazione per proteggere le tue applicazioni da errori a livello di risorsa, zona e regione.
• Per scoprire di più sulla progettazione di architetture ad alta disponibilità in Google Cloud, consulta Modelli per app resilienti e scalabili.
• Scopri di più sulle possibili opzioni di connettività per connettere il cluster GKE Enterprise in esecuzione nel tuo ambiente on-premise/edge alla rete Google Cloud insieme all'impatto della disconnessione temporanea da Google Cloud.