Pattern di architettura di networking sicura ibrida e multi-cloud

Last reviewed 2023-12-14 UTC

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

Questo è il terzo dei tre documenti di un insieme. Illustra i pattern di architettura di networking ibridi e multi-cloud. Questa parte esplora diversi pattern comuni di architettura di rete sicura che è possibile utilizzare per architetture ibride e multi-cloud. Descrive gli scenari per i quali 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 è costituito da queste parti:

• Crea architetture ibride e multi-cloud: illustra la pianificazione di una strategia per progettare una configurazione ibrida e multi-cloud con Google Cloud.
• Modelli di architettura ibrida e multi-cloud: illustra i pattern di architettura comuni da adottare nell'ambito di una strategia ibrida e multi-cloud.
• Pattern di architettura di networking sicura ibrida e multi-cloud: esamina i pattern di architettura di networking ibrida e multi-cloud dal punto di vista del networking (questo documento).

Connettere ambienti di computing privati a Google Cloud in modo sicuro e affidabile è essenziale per qualsiasi architettura ibrida e multi-cloud di successo. Il pattern di architettura di networking ibrido e cloud che scegli per una configurazione ibrida e multi-cloud deve soddisfare i requisiti specifici dei carichi di lavoro aziendali. Deve inoltre adattarsi ai pattern di architettura che intendi applicare. Anche se potresti aver bisogno di personalizzare ogni progetto, ci sono dei modelli comuni che puoi usare come modello.

I pattern dell'architettura di networking in questo documento non devono essere considerati alternative alla progettazione delle zone di destinazione in Google Cloud. Devi invece progettare ed eseguire il deployment dei pattern di architettura selezionati come parte della progettazione complessiva della zona di destinazione di Google Cloud, che si estende nelle seguenti aree:

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

Applicazioni diverse possono utilizzare pattern di architettura di networking differenti, incorporati in un'architettura delle zone di destinazione. In una configurazione multi-cloud, devi mantenere la coerenza della progettazione della zona di destinazione in tutti gli ambienti.

Questa serie contiene le seguenti pagine:

• Considerazioni sulla progettazione
• Modelli architettonici
  • Motivo speculare
  • Pattern a maglia
  • Pattern ad arco
    • Traffico in uscita ad accesso controllato
    • Ingresso con accesso limitato
    • In entrata e in uscita con accesso limitato
  • Passaggio a mano
• 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 | Writer tecnico, networking
• Daniel Strebel | EMEA Solution Lead, Modernizzazione delle applicazioni
• Ammett Williams | Ingegnere per le relazioni con gli sviluppatori

Modelli di architettura

I documenti di questa serie parlano dei pattern di architettura di networking 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 dovrebbero essere incorporati nell'architettura complessiva della zona di destinazione dell'organizzazione, che può includere più pattern di networking per soddisfare i requisiti specifici di comunicazione e sicurezza delle diverse applicazioni.

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

• Motivo speculare
• Pattern a maglia
• Pattern ad arco
  • Traffico in uscita ad accesso controllato
  • Ingresso con accesso limitato
  • Traffico in uscita con accesso controllato e ingresso riservato
• Sequenza a mano

Motivo speculare

Il pattern con mirroring si basa sulla replica del design di un determinato ambiente o ambienti esistenti in uno o più ambienti nuovi. Pertanto, questo pattern si applica principalmente alle architetture che seguono il modello ambiente ibrido. Con questo pattern, i carichi di lavoro di sviluppo e test vengono eseguiti in un ambiente, mentre i carichi di lavoro di gestione temporanea e produzione in un altro.

Il pattern con mirroring presuppone che i carichi di lavoro di test e produzione non comunichino 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 in linea con i seguenti requisiti:

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

Architettura

Il seguente diagramma dell'architettura mostra un'architettura di riferimento di alto livello di questo pattern che supporta CI/CD, Monitoring, 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 sono distribuiti in base agli ambienti funzionali (sviluppo, test, CI/CD e strumenti amministrativi) su VPC separati sul lato Google Cloud.
• Il VPC condiviso viene utilizzato per i carichi di lavoro di sviluppo e test. Viene usato un altro VPC per CI/CD e gli strumenti amministrativi. Con i VPC condivisi:
  • Le applicazioni sono gestite da team diversi per ambiente e progetto di servizio.
  • Il progetto host amministra e controlla i controlli di sicurezza e della comunicazione di rete 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 servizio di prevenzione delle intrusioni (IPS) per implementare l'ispezione approfondita dei pacchetti al fine di prevenire le minacce senza modificare la progettazione o il routing. Cloud Next Generation Firewall Enterprise funziona creando endpoint firewall a livello di zona gestiti da Google che utilizzano la tecnologia di intercettazione dei pacchetti per ispezionare in modo trasparente i carichi di lavoro alla ricerca delle firme di minaccia configurate. Inoltre, protegge i carichi di lavoro dalle minacce.
• Abilita la comunicazione tra i VPC in 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.
• Considera queste best practice generali.

Puoi stabilire questa connessione CI/CD utilizzando una delle opzioni di connettività di rete ibrida e multi-cloud discusse in base ai requisiti aziendali e delle applicazioni. Per consentire il deployment e la gestione dei carichi di lavoro di produzione, questa connessione fornisce la connettività di rete privata tra i diversi ambienti di elaborazione. Tutti gli ambienti devono avere uno spazio di indirizzi IP RFC 1918 senza sovrapposizione.

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 di progetto host del VPC condiviso. Il deployment nella stessa rete del progetto host del VPC condiviso aiuta a evitare di rendere queste istanze direttamente accessibili da internet.
• Per il traffico web in uscita, puoi utilizzare Secure Web Proxy. Il proxy offre diversi vantaggi.

Per ulteriori informazioni sugli strumenti e sulle funzionalità di Google Cloud che aiutano a creare, testare ed eseguire il deployment in Google Cloud e in ambienti ibridi e multi-cloud, consulta il blog DevOps e CI/CD su Google Cloud.

Varianti

Per soddisfare diversi requisiti di progettazione, pur prendendo in considerazione tutti i requisiti di comunicazione, il pattern di architettura con mirroring offre queste opzioni, descritte nelle sezioni seguenti:

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

VPC condiviso per ambiente

L'opzione di progettazione del VPC condiviso per ambiente consente la separazione del livello di applicazione o di servizio tra ambienti, tra cui 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 garantisce la separazione fornendo isolamento a livello di rete e di progetto tra i diversi ambienti, che consente una comunicazione più granulare e controllo dell'accesso Identity and Access Management (IAM).

Da un punto di vista di gestione e operazioni, questo design offre la flessibilità necessaria per gestire le applicazioni e i carichi di lavoro creati da team diversi per ambiente e per progetto di servizio. Il networking VPC e le relative funzionalità di sicurezza possono essere sottoposti a provisioning e gestiti dai team delle operazioni di networking in base alle seguenti strutture possibili:

• Un unico team gestisce tutti i progetti host in tutti gli ambienti.
• I progetti host vengono gestiti da team diversi nei rispettivi ambienti.

Le decisioni relative alla gestione dei progetti host dovrebbero essere basate sulla struttura dei team, sulle operazioni di sicurezza e sui requisiti di accesso di ogni team. Puoi applicare questa variante di progettazione alla rete VPC condivisa per ogni opzione di progettazione della zona di destinazione dell'ambiente. Tuttavia, devi considerare i requisiti di comunicazione del pattern con mirroring per definire quale comunicazione è consentita 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 diagramma seguente:

Firewall a livello di applicazione centralizzato

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

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

Questa progettazione può essere utilizzata anche con più VPC condivisi, come illustrato nel diagramma seguente.

L'NVA in questa progettazione funge da livello di sicurezza perimetrale. Inoltre, funge da base per abilitare l'ispezione del traffico in linea e applicare criteri di controllo dell'accesso rigorosi.

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

Nota: nelle regioni cloud supportate e quando tecnicamente fattibile per il tuo progetto, puoi eseguire il deployment delle VM senza richiedere più reti VPC o interfacce delle appliance. Questo deployment si basa sull'utilizzo delle funzionalità di bilanciamento del carico e di routing basato su criteri. Queste funzionalità abilitano un meccanismo basato su criteri e indipendente dalla topologia per l'integrazione delle VM nella tua rete cloud. Per maggiori dettagli, consulta Esegui il deployment di appliance virtuali di rete (NVA) senza più VPC.

Topologia hub e spoke

Un'altra possibile variante della 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 diagramma seguente, tutti gli ambienti di fase si connettono con il CI/CD e il VPC amministrativo in un'architettura hub e spoke. Utilizza questa opzione se devi separare i domini amministrativi e le funzioni in ciascun ambiente. Il modello di comunicazione hub e spoke può essere utile per i seguenti requisiti:

• Le applicazioni devono accedere a un set comune di servizi, come monitoraggio, strumenti di gestione della configurazione, CI/CD o autenticazione.
• È necessario applicare un insieme comune di criteri di sicurezza al traffico in entrata e in uscita in modo centralizzato attraverso l'hub.

Per ulteriori informazioni sulle opzioni di progettazione hub e spoke, consulta Topologia hub e spoke con appliance centralizzate e topologia hub e spoke senza appliance centralizzate.

Come mostrato nel diagramma precedente, la comunicazione tra VPC e la connettività ibrida passano attraverso il VPC dell'hub. Nell'ambito di questo pattern, puoi controllare e limitare la comunicazione nel VPC dell'hub per allinearti ai tuoi requisiti di connettività.

Nell'ambito dell'architettura di rete hub e spoke, di seguito sono riportate le opzioni di connettività principali (tra gli spoke e i VPC 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 sull'opzione da prendere in considerazione nella progettazione, consulta Architettura di rete Hub-and-spoke. Un fattore di influenza chiave per la selezione di VPN su peering VPC tra gli spoke e il VPC dell'hub è il caso in cui è richiesta la transitività del traffico. La transitività del traffico indica che il traffico proveniente da uno spoke può raggiungere altri spoke attraverso l'hub.

Architettura distribuita dei microservizi Zero Trust

Le architetture ibride e multi-cloud possono richiedere più cluster per raggiungere i propri obiettivi tecnici e commerciali, compresa la separazione dell'ambiente di produzione dagli ambienti di sviluppo e test. Pertanto, i controlli di sicurezza perimetrali di rete sono importanti, soprattutto quando devono rispettare determinati requisiti di sicurezza.

Non è sufficiente per supportare i requisiti di sicurezza delle attuali architetture di microservizi distribuiti cloud-first, perciò dovresti prendere in considerazione anche le architetture distribuite Zero Trust. L'architettura distribuita di microservizi Zero Trust supporta la tua architettura di microservizi con applicazione, autenticazione e identità dei carichi di lavoro dei criteri di sicurezza a livello di microservizi. L'attendibilità è basata sull'identità e viene applicata per ogni servizio.

Utilizzando un'architettura di proxy distribuito, come un mesh di servizi, i servizi possono convalidare in modo efficace i chiamanti e implementare criteri di controllo dell'accesso granulari per ogni richiesta, consentendo un ambiente di microservizi più sicuro e scalabile. Cloud Service Mesh ti offre la flessibilità di disporre di un mesh comune in grado di coprire i deployment di Google Cloud e on-premise. Il mesh usa i criteri di autorizzazione per proteggere le comunicazioni tra i servizi.

Potresti anche incorporare Apigee Adapter per Envoy, che è un deployment di gateway API Apigee leggero all'interno di un cluster Kubernetes, con questa architettura. Apigee Adapter per Envoy è un proxy perimetrale e di servizio open source progettato per applicazioni cloud-first.

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

• Architettura distribuita senza attendibilità
• Ambiente ibrido di GKE Enterprise
• Collegati a Google
  • Connetti un cluster GKE Enterprise on-premise a una rete Google Cloud.
• Configura un mesh multi-cloud o ibrido
  • Esegui il deployment di Cloud Service Mesh in ambienti e cluster diversi.

Best practice per pattern speculari

• 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 previsto di disponibilità del sistema. Per ulteriori informazioni, consulta Affidabilità dell'infrastruttura Google Cloud.

• Per eliminare gli errori di configurazione per processi ripetuti come gli aggiornamenti del codice, l'automazione è essenziale per standardizzare le build, i test e i deployment. Per scoprire di più su come utilizzare i vari controlli e protezioni durante l'automazione, consulta Automatizzare i deployment.

• L'integrazione di NVA centralizzate in questa progettazione potrebbe richiedere l'integrazione di più segmenti con diversi livelli di controlli di accesso alla sicurezza. Per ulteriori informazioni, consulta Appliance di rete centralizzate su Google Cloud.

• Quando si progetta una soluzione che include le VM a elevata disponibilità, è importante considerare l'alta disponibilità per evitare un single point of failure che potrebbe bloccare tutte le comunicazioni. Segui le indicazioni di progettazione e implementazione per l'alta disponibilità e la ridondanza fornite dal fornitore di NVA. Per ulteriori informazioni, consulta la sezione relativa alle opzioni di architettura delle appliance di rete centralizzate su Google Cloud per ottenere disponibilità elevata tra le appliance virtuali.

• Se non esporti le route IP on-premise tramite peering VPC o VPN nel VPC di sviluppo e test, puoi limitare la connettività della rete dagli ambienti di sviluppo e test all'ambiente on-premise. Per maggiori informazioni, consulta Scambio di route personalizzate di peering di rete VPC.

• Per i carichi di lavoro con indirizzi IP privati che possono richiedere l'accesso alle API di Google, puoi esporre le API di Google utilizzando un endpoint Private Service Connect all'interno di una rete VPC. Per maggiori informazioni, consulta Traffico in entrata con accesso limitato in questa serie.

• Esamina le best practice generali per i pattern di architettura di networking ibride e multi-cloud.

Motivo a maglia

Il pattern mesh si basa sullo sviluppo di un'architettura di rete ibrida. Questa architettura si estende a più ambienti di elaborazione. In questi ambienti, tutti i sistemi possono comunicare tra loro e non sono limitati alla comunicazione unidirezionale in base ai requisiti di sicurezza delle applicazioni. Questo pattern di networking si applica principalmente alle architetture ibride a livelli, multi-cloud partizionate o bursting. È applicabile anche alla progettazione della continuità aziendale per eseguire il provisioning di un ambiente di ripristino di emergenza (RE) in Google Cloud. In tutti i casi, è necessario connettere gli ambienti di computing in modo che siano in linea con i seguenti requisiti di comunicazione:

• I carichi di lavoro possono comunicare tra loro attraverso i confini dell'ambiente, usando indirizzi IP RFC 1918 privati.
• La comunicazione può essere avviata da entrambi i lati. Le specifiche del modello di comunicazione possono variare in base alle applicazioni e ai requisiti di sicurezza, ad esempio i modelli di comunicazione discussi nelle opzioni di progettazione riportate di seguito.
• Le regole firewall che utilizzi devono consentire il traffico tra origini e destinazioni di indirizzi IP specifici in base ai requisiti dell'applicazione o delle applicazioni per cui è progettato il pattern. Idealmente, è possibile utilizzare un approccio alla sicurezza a più livelli per limitare i flussi di traffico in modo granulare, sia tra gli ambienti di elaborazione che all'interno.

Architettura

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

• Tutti gli ambienti devono utilizzare uno spazio di indirizzi IP RFC 1918 senza sovrapposizione.
• Sul lato Google Cloud, puoi eseguire il deployment dei carichi di lavoro in uno o più VPC condivisi o VPC non condivisi. Per altre possibili opzioni di progettazione di questo motivo, fai riferimento alle seguenti varianti di design. La struttura selezionata dei VPC deve essere in linea con la progettazione della gerarchia delle risorse della tua organizzazione.
• La rete VPC di Google Cloud si estende ad altri ambienti di computing. Questi ambienti possono essere on-premise o in un altro cloud. Utilizza una delle opzioni di connettività di rete ibrida e multi-cloud che soddisfano i requisiti aziendali e delle applicazioni.

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

  • Regole firewall o criteri firewall.

  • Appliance virtuali di rete (NVA) con funzionalità di ispezione del firewall di nuova generazione (NGFW), collocata nel percorso di rete.

  • Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS) per implementare l'ispezione approfondita dei pacchetti al fine di prevenire le minacce senza modificare la progettazione della rete o il routing.

Varianti

Il pattern di architettura mesh può essere combinato con altri approcci per soddisfare diversi requisiti di progettazione, pur continuando a considerare i requisiti di comunicazione del pattern. Le opzioni per i pattern sono descritte nelle sezioni seguenti:

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

Un VPC per ambiente

Ecco i motivi più comuni per prendere in considerazione l'opzione one-VPC-per-environment:

• L'ambiente cloud richiede una separazione a livello di rete delle reti e delle risorse VPC, in linea con la progettazione della gerarchia delle risorse dell'organizzazione. Se è necessaria la separazione amministrativa dei domini, puoi anche combinarla con un progetto separato per ambiente.
  • Per gestire centralmente le risorse di rete in una rete comune e fornire l'isolamento della rete tra i diversi ambienti, utilizza un VPC condiviso per ogni ambiente in Google Cloud, ad esempio sviluppo, test e produzione.
• Scala i requisiti che potrebbero dover superare le quote di VPC per un singolo VPC o progetto.

Come illustrato nel diagramma seguente, la progettazione con un singolo VPC per ambiente consente a ogni VPC di integrarsi direttamente con l'ambiente on-premise o con altri ambienti cloud tramite VPN o con Cloud Interconnect con più collegamenti VLAN.

Il pattern visualizzato nel diagramma precedente può essere applicato a una topologia di rete hub e spoke di una zona di destinazione. In questa topologia, una singola (o più) connessione ibrida può essere condivisa con tutti i VPC spoke. Viene condiviso utilizzando un VPC di transito per terminare sia la connettività ibrida che gli altri VPC spoke. Puoi anche espandere questa progettazione aggiungendo NVA con funzionalità di ispezione del firewall di nuova generazione (NGFW) presso il VPC di transito, come descritto nella sezione successiva, "Usa un firewall a livello di applicazione centralizzato".

Usa un firewall centralizzato a livello di applicazione

Se i tuoi requisiti tecnici impongono di considerare il livello delle applicazioni (livello 7) e l'ispezione approfondita dei pacchetti con funzionalità di firewall avanzate che superano le capacità del firewall di nuova generazione Cloud, puoi utilizzare un'appliance NGFW ospitata in un AVA. Tuttavia, tale NVA deve soddisfare le esigenze di sicurezza dell'organizzazione. Per implementare questi meccanismi, puoi estendere la topologia in modo da passare tutto il traffico cross-environment attraverso un firewall NVA centralizzato, come mostrato nel diagramma seguente.

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

Come mostrato nel diagramma precedente, NVA funge da livello di sicurezza perimetrale e funge da base per consentire l'ispezione del traffico in linea. Applica inoltre criteri rigidi di controllo dell'accesso. Per ispezionare i flussi di traffico sia da est a ovest che da nord-sud, la progettazione di un NVA centralizzato potrebbe includere più segmenti con diversi livelli di controlli di accesso alla sicurezza.

Architettura distribuita dei microservizi Zero Trust

Quando si utilizzano applicazioni containerizzate, a questo pattern di architettura è applicabile anche l'architettura distribuita del protocollo Zero Trust di microservizi, descritta nella sezione relativa al pattern con mirroring.

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

Best practice per i pattern a mesh

• Prima di fare qualsiasi altra cosa, decidi la progettazione della gerarchia delle risorse e la progettazione necessaria per supportare qualsiasi progetto e VPC. In questo modo puoi selezionare l'architettura di networking ottimale in linea con la struttura dei tuoi progetti Google Cloud.
• Utilizza un'architettura distribuita Zero Trust quando utilizzi Kubernetes nel tuo ambiente di computing privato e Google Cloud.

• Quando utilizzi VNA centralizzate nella progettazione, devi definire più segmenti con diversi livelli di controlli di accesso di sicurezza e criteri di ispezione del traffico. Basa questi controlli e criteri sui requisiti di sicurezza delle tue applicazioni. Per ulteriori informazioni, consulta Appliance di rete centralizzate su Google Cloud.

• Quando si progetta una soluzione che include le VM a elevata disponibilità, è importante considerare l'alta disponibilità per evitare un single point of failure che potrebbe bloccare tutte le comunicazioni. Segui le linee guida per la progettazione e l'implementazione di alta disponibilità e ridondanza fornite dal fornitore di servizi di sicurezza di Google Cloud che fornisce le tue AVA.

• Per fornire maggiore privacy, integrità dei dati e un modello di comunicazione controllato, esponi le applicazioni tramite API utilizzando gateway API, come Apigee e Apigee ibrido con mTLS end-to-end. Puoi anche utilizzare un VPC condiviso con Apigee nella stessa risorsa dell'organizzazione.

• Se la progettazione della tua soluzione richiede l'esposizione di un'applicazione basata su Google Cloud alla rete internet pubblica, considera i suggerimenti di progettazione discussi in Networking per la distribuzione di applicazioni per internet.

• Per proteggere i servizi Google Cloud nei tuoi progetti e ridurre il rischio di esfiltrazione di dati, utilizza Controlli di servizio VPC per specificare i perimetri di servizio a livello di progetto o di rete VPC. Inoltre, puoi estendere i perimetri di servizio a un ambiente ibrido su una VPN autorizzata o Cloud Interconnect. Per ulteriori informazioni sui vantaggi dei perimetri di servizio, consulta Panoramica dei Controlli di servizio VPC.

• Consulta le best practice generali per i pattern di networking ibridi e multi-cloud.

Se intendi applicare un isolamento più rigido e un accesso più granulare tra le tue applicazioni ospitate in Google Cloud e in altri ambienti, valuta l'utilizzo di uno dei pattern con accesso limitato descritti negli altri documenti di questa serie.

Motivi recintati

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

• Traffico in uscita ad accesso controllato

• Ingresso con accesso limitato

• In uscita e in entrata con accesso limitato (con gate bidirezionale in entrambe le direzioni)

Come accennato in precedenza in questa guida, i pattern dell'architettura di networking qui descritti 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 un pattern o una combinazione di pattern contemporaneamente. Il deployment specifico dell'architettura selezionata è determinato dai requisiti di comunicazione specifici di ciascun pattern con accesso limitato.

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

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

I pattern limitati consentono l'implementazione di Cloud Firewall Enterprise di nuova generazione con il servizio di prevenzione delle intrusioni (IPS) per eseguire un'ispezione approfondita dei pacchetti per la prevenzione delle minacce senza alcuna modifica 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 il livello 7 e un'ispezione approfondita dei pacchetti con meccanismi di firewall avanzati che superano le capacità del firewall di Cloud Next Generation, puoi utilizzare un firewall centralizzato di nuova generazione (NGFW) ospitato in un'appliance virtuale di rete (NVA). Diversi partner per la sicurezza di Google Cloud offrono appliance NGFW in grado di soddisfare le tue esigenze di sicurezza. L'integrazione delle VM con questi pattern di accesso può richiedere l'introduzione di più zone di sicurezza all'interno della progettazione della rete, ciascuna con livelli di controllo dell'accesso dell'accesso distinti. Per ulteriori informazioni, consulta Appliance di rete centralizzate su Google Cloud.

Traffico in uscita riservato

L'architettura del pattern di networking del traffico in uscita riservato si basa sull'esposizione di API selezionate dall'ambiente on-premise o da un altro ambiente cloud ai carichi di lavoro di cui viene 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 attraverso un gateway API o un proxy oppure un bilanciatore del carico che funga da facciata per i carichi di lavoro esistenti. Puoi eseguire il deployment della funzionalità gateway API in un segmento di rete perimetrale isolato, ad esempio una rete perimetrale.

Il pattern di rete in uscita riservato si applica principalmente ai pattern di architettura delle applicazioni a più livelli e ai pattern di architettura delle applicazioni partizionate, a titolo esemplificativo. Quando esegui il deployment di carichi di lavoro di backend all'interno di una rete interna, il networking in uscita riservato aiuta a mantenere un livello più elevato di sicurezza all'interno dell'ambiente di computing on-premise. Il pattern richiede che gli ambienti di elaborazione vengano collegati in modo da soddisfare i seguenti requisiti di comunicazione:

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

Questa guida si concentra sugli ambienti ibridi e multi-cloud connessi su 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 tramite internet. Tuttavia, devi prendere in considerazione i seguenti meccanismi di sicurezza:

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

Per proteggere un proxy API, considera questi altri aspetti di sicurezza. Per ulteriori informazioni, consulta le best practice per la protezione di applicazioni e API con Apigee.

Architettura

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

I dati passano attraverso il diagramma precedente come segue:

• Sul lato Google Cloud, puoi eseguire il deployment dei carichi di lavoro in 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 sono 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 che proviene da indirizzi IP VPC specifici ed è destinato a gateway o bilanciatori del carico remoti, utilizza i filtri nella lista consentita di indirizzi IP. Il traffico restituito da queste connessioni è consentito quando si utilizzano le 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 virtuali di rete (NVA) con funzionalità di ispezione del firewall di nuova generazione (NGFW) che si trovano nel percorso di rete.

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

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

Varianti

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

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

Utilizza il gateway API Google Cloud e il frontend globale

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

• Con il peering VPC
• Senza peering VPC

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

L'ottimizzazione delle velocità di distribuzione dei contenuti si ottiene distribuendo le applicazioni dai punti di presenza (PoP) di Google Cloud. I PoP di Google Cloud 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 aiutano a fornire API ad alte prestazioni quando si utilizzano Apigee con Cloud CDN per svolgere quanto segue, guarda Delivering ad alte prestazioni API con Apigee e Cloud CDN su YouTube:

• Riduci la latenza.
• Ospita le API in tutto il mondo.
• Aumenta la disponibilità per i picchi di traffico.

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

In questa progettazione, la rete verso nord è stabilita tramite:

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

Il networking verso sud viene stabilito attraverso:

• 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 deployment dell'ILB viene eseguito con gruppi di endpoint di rete con connettività ibrida (NEG di connettività ibrida).

• Si accede ai servizi ibridi tramite il NEG di connettività ibrida su una connettività di rete ibrida, come VPN o Cloud Interconnect.

Per maggiori 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 tuoi requisiti, le API dei backend on-premise possono essere esposte tramite Apigee Hybrid, un gateway o un proxy API di terze parti oppure un bilanciatore del carico.

Esposizione di servizi remoti utilizzando Private Service Connect

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

• Non stai utilizzando una piattaforma API o vuoi evitare di connettere l'intera rete VPC direttamente a un ambiente esterno per i seguenti motivi:
  • Sono presenti limitazioni di sicurezza o requisiti di conformità.
  • I tuoi intervalli di indirizzi IP si sovrappongono, ad esempio in uno scenario di fusione e acquisizione.
• Consentire comunicazioni unidirezionali sicure tra client, applicazioni e servizi tra gli ambienti, anche quando la scadenza è breve.
• Potresti dover fornire connettività a più VPC consumer tramite un VPC del producer di servizi (VPC di transito) per offrire modelli di servizio multi-tenant o single-tenant a scalabilità elevata, al fine di raggiungere i servizi pubblicati in altri ambienti.

L'uso di Private Service Connect per le applicazioni utilizzate come API fornisce un indirizzo IP interno per le applicazioni pubblicate, consentendo un accesso sicuro all'interno della rete privata tra regioni e tramite connettività ibrida. Questa astrazione facilita l'integrazione di risorse da diversi cloud e ambienti on-premise su 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 a un 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 ibrido (NEG di connettività ibrida) in un VPC producer che agisce in questa progettazione come VPC di transito.

Nel diagramma precedente, i carichi di lavoro nella rete VPC della tua applicazione possono raggiungere i servizi ibridi in esecuzione nell'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 fornisce un'opzione alternativa al peering a un VPC di transito.

Nell'ambito della progettazione descritta nel diagramma precedente, più frontend, backend o endpoint possono connettersi allo stesso collegamento al servizio, 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 servizio viene utilizzato da più VPC consumer anche se i loro intervalli di indirizzi IP si sovrappongono.

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

Il design offre i seguenti vantaggi:

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

L'approccio alla progettazione nel diagramma precedente può espandersi in fasi successive per integrare Apigee come piattaforma API utilizzando le opzioni di progettazione del networking descritte in precedenza, compresa l'opzione Private Service Connect.

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

Il client che si connette all'endpoint Private Service Connect può trovarsi nella stessa regione dell'endpoint o in una diversa regione. Questo approccio può essere utilizzato per fornire disponibilità elevata nei 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 tramite risorse ospitate in altre regioni, vengono applicati costi in uscita tra regioni al traffico destinato agli endpoint con accesso globale.

Nota: per ottenere controlli di integrità distribuiti e facilitare la connessione di più VPC ad ambienti on-premise su più connessioni ibride, collega un bilanciatore del carico delle applicazioni interno a un bilanciatore del carico delle applicazioni esterno. Per maggiori informazioni, consulta Concatenamento esplicito dei bilanciatori del carico Google Cloud L7 con PSC.

Best practice

• Considerare Apigee e Apigee Hybrid come soluzione di piattaforma API offre numerosi vantaggi. Fornisce un livello di proxy e un'astrazione o un facade per le API dei tuoi servizio di backend in combinazione con funzionalità di sicurezza, limitazione di frequenza, quote e analisi.
  • Utilizza Apigee Adapter per Envoy con un'architettura di deployment ibrido Apigee con Kubernetes ove applicabile ai tuoi requisiti e all'architettura.
• I VPC e la progettazione dei progetti in Google Cloud devono essere basati 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 origini e destinazioni di indirizzi IP specifici dei consumer delle API e dei gateway API che potrebbero essere ospitati in ambienti diversi.
• Utilizza le regole firewall VPC o i criteri firewall per controllare l'accesso alle risorse Private Service Connect tramite l'endpoint Private Service Connect.
• Se un'applicazione viene esposta esternamente tramite un bilanciatore del carico dell'applicazione, valuta l'utilizzo di Google Cloud Armor come livello di sicurezza aggiuntivo per la protezione da attacchi DDoS e minacce di sicurezza a livello delle applicazioni.

• 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 istanze VM con indirizzi IP pubblici esterni nei sistemi di cui è stato eseguito il deployment dietro un gateway API o un bilanciatore del carico.

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

• Consulta le best practice generali per i pattern di networking ibridi e multi-cloud.

Ingresso riservato

L'architettura del pattern in entrata recintato si basa sull'esposizione di determinate API dei carichi di lavoro in esecuzione su Google Cloud all'ambiente di computing privato, senza esporle alla rete internet pubblica. Questo pattern è la controparte del pattern del traffico in uscita riservato ed è particolarmente adatto per gli scenari ibrido perimetrale, ibrido a livelli e multi-cloud partizionato.

Come con il pattern di traffico in uscita riservato, puoi facilitare questa esposizione limitata attraverso un gateway API o un bilanciatore del carico che funge da facciata per i carichi di lavoro o i servizi esistenti. In questo modo è possibile accedere ad ambienti di computing privati, ambienti on-premise o in altri ambienti cloud, nel modo seguente:

• I carichi di lavoro di cui esegui il deployment nell'ambiente di computing privato o in altri ambienti cloud sono in grado di comunicare con il gateway API o il bilanciatore del carico utilizzando indirizzi IP interni. Gli altri sistemi di cui è stato eseguito il deployment in Google Cloud non sono raggiungibili.
• La comunicazione da Google Cloud all'ambiente di computing 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 in entrata con accesso riservato.

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 più VPC).
• La rete dell'ambiente Google Cloud si estende ad altri ambienti di computing (on-premise o su un altro cloud) tramite la connettività di rete ibrida o multi-cloud per facilitare la comunicazione tra gli ambienti.
• Facoltativamente, puoi utilizzare un VPC di transito per eseguire le seguenti operazioni:
  • Fornisci ulteriori livelli di sicurezza perimetrali per consentire l'accesso ad API specifiche al di fuori del VPC dell'applicazione.
  • Instrada il traffico agli 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 al 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 o una facciata di astrazione 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 sovrapposizione.

Il seguente diagramma illustra la progettazione di questo pattern utilizzando Apigee come piattaforma API.

Nel diagramma precedente, l'utilizzo di Apigee come piattaforma API offre le seguenti caratteristiche e capacità per abilitare il pattern in entrata con accesso riservato:

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

Nella progettazione:

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

• Configura le regole del firewall e i filtri del traffico nel VPC dell'applicazione. In questo modo ottieni un accesso granulare e controllato. Inoltre, aiuta a impedire 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 connettività diretta senza passare attraverso l'endpoint Private Service Connect e il gateway API.

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

Come illustrato nel diagramma precedente:

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

Puoi eseguire il provisioning di diversi 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 le regole firewall di router Cloud e VPC. Ad esempio, se connetti la tua rete on-premise a Google Cloud utilizzando più connessioni di rete ibride, puoi inviare una parte del traffico da on-premise a API di Google specifiche o servizi pubblicati su una connessione e il resto su un'altra connessione. Inoltre, puoi utilizzare l'accesso globale a Private Service Connect per offrire opzioni di failover.

Varianti

Il pattern di architettura in entrata riservato può essere combinato con altri approcci per soddisfare diversi requisiti di progettazione, pur prendendo in considerazione i requisiti di comunicazione del pattern. Il pattern offre le seguenti opzioni:

• Accedere alle API di Google da altri ambienti

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

• Usa un'architettura hub e spoke per esporre i backend delle applicazioni in altri ambienti

Accedi alle API di Google da altri ambienti

Per 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 connettività ai servizi e alle API di Google supportati (inclusi Google Maps, Google Ads e Google Cloud) da ambienti on-premise o da altri ambienti cloud mediante 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 usando endpoint o backend. Gli endpoint consentono di scegliere come target un set di API di Google. I backend consentono di scegliere come target un'API di Google a livello di regione specifica.

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

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

In scenari specifici, come evidenziato dal pattern ibrido a più livelli, potresti dover eseguire il deployment dei backend in Google Cloud mantenendo i frontend negli ambienti di computing privati. Sebbene meno comune, questo approccio è applicabile quando si ha a che fare con frontend pesanti e monolitici che potrebbero basarsi su componenti legacy. Oppure, più comunemente, quando si gestiscono applicazioni distribuite in più ambienti, tra cui 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 privato on-premise o in altri ambienti cloud per esporre direttamente il frontend dell'applicazione alla rete internet pubblica. 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 in questo diagramma:

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

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

In alcuni scenari potrebbe essere necessaria l'esposizione delle API dai backend delle applicazioni ospitate in Google Cloud in reti VPC diverse. Come illustrato nel seguente diagramma, un VPC hub funge da punto centrale di interconnessione per i vari VPC (spoke), consentendo una comunicazione sicura su connettività ibrida privata. Facoltativamente, le funzionalità gateway API locali in altri ambienti, ad esempio Apigee Hybrid, possono essere utilizzate per terminare le richieste dei client localmente dove è ospitato il frontend dell'applicazione.

Come illustrato nel diagramma precedente:

• Per fornire ulteriori capacità di ispezione NGFW di livello 7, l'unità NVA con funzionalità di NGFW è facoltativamente integrata nel progetto. Potrebbero essere necessarie queste capacità per rispettare requisiti di sicurezza specifici e gli standard dei criteri di sicurezza della tua organizzazione.

• Questa progettazione presuppone che i VPC spoke non richiedano la comunicazione diretta tra VPC e VPC.

  • Se è necessaria una comunicazione spoke-to-spoke, puoi utilizzare l'NVA per facilitarne la comunicazione.
  • Se hai backend diversi in VPC diversi, puoi usare Private Service Connect per esporre questi backend al VPC di Apigee.
  • Se viene utilizzato il peering VPC per la connettività verso nord e sud tra i VPC spoke e il VPC hub, devi considerare la limitazione di transizione del networking VPC sul peering VPC. Per ovviare a questo limite, puoi utilizzare una delle seguenti opzioni:
    • Per interconnettere i VPC, utilizza un NVA.
    • Se applicabile, prendi in considerazione il modello Private Service Connect.
    • Per stabilire la connettività tra il VPC Apigee e i backend che si trovano in altri progetti Google Cloud nella stessa organizzazione senza componenti di networking aggiuntivi, utilizza il VPC condiviso.

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

• Se la progettazione non include l'NVA, puoi terminare la connettività ibrida al VPC dell'hub.

• Se sono richieste determinate funzionalità di bilanciamento del carico o funzionalità di sicurezza, ad esempio l'aggiunta di protezione DDoS o WAF di Google Cloud Armor, puoi scegliere di eseguire il deployment di un bilanciatore del carico delle applicazioni esterno nel perimetro tramite un VPC esterno prima di indirizzare le richieste dei client esterni ai backend.

Best practice

• Per situazioni in cui le richieste dei client da internet devono essere ricevute localmente da un frontend ospitato in un ambiente privato on-premise o in un altro ambiente cloud, valuta la possibilità di utilizzare Apigee Hybrid come soluzione gateway API. Questo approccio facilita inoltre una migrazione senza interruzioni della soluzione a un ambiente completamente ospitato da Google Cloud, mantenendo al contempo la coerenza della piattaforma API (Apigee).
• Utilizza Apigee Adapter per Envoy con un'architettura di deployment ibrido Apigee con Kubernetes ove applicabile ai tuoi requisiti e all'architettura.
• La progettazione di VPC e progetti in Google Cloud deve rispettare i requisiti della gerarchia delle risorse e del modello di comunicazione sicura, come descritto in questa guida.
• L'integrazione di un VPC di transito in questa progettazione offre la flessibilità per eseguire il provisioning di ulteriori misure di sicurezza perimetrali e la connettività ibrida all'esterno 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 maggiori informazioni, consulta Accedere all'endpoint da host on-premise.
• Per proteggere i servizi Google Cloud nei tuoi progetti e ridurre il rischio di esfiltrazione di dati, utilizza Controlli di servizio VPC per specificare i perimetri di servizio a livello di progetto o di rete VPC.
  • Se necessario, puoi estendere i perimetri di servizio a un ambiente ibrido su VPN o Cloud Interconnect. Per ulteriori informazioni sui vantaggi dei perimetri di servizio, consulta Panoramica dei Controlli di servizio VPC.
• Utilizza le regole firewall 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 dei tuoi endpoint. Per ulteriori informazioni sulle regole firewall VPC in generale, consulta Regole firewall VPC.
• Quando si progetta una soluzione che include le VM a elevata disponibilità, è importante considerare l'alta disponibilità per evitare un single point of failure che potrebbe bloccare tutte le comunicazioni. Segui le indicazioni di progettazione e implementazione per l'alta disponibilità e la ridondanza fornite dal fornitore di NVA. Per ulteriori informazioni su come ottenere una disponibilità elevata tra le appliance virtuali, consulta la sezione Opzioni di architettura di Appliance di rete centralizzate su Google Cloud.
• Per rafforzare la sicurezza perimetrale e proteggere il gateway API di cui è stato eseguito il deployment nel rispettivo ambiente, puoi facoltativamente implementare meccanismi di bilanciamento del carico e web application firewall nell'altro ambiente di computing (ibrido o altro cloud). Implementa queste opzioni sulla rete perimetrale collegata direttamente 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 nei 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 ibridi e multi-cloud.

Traffico in uscita riservato e in entrata con accesso riservato

I pattern in uscita con accesso riservato e in entrata con accesso riservato utilizzano una combinazione di traffico in uscita riservato e in entrata con accesso riservato 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, è possibile utilizzare gateway API, endpoint Private Service Connect o bilanciatori del carico per esporre API specifiche e, facoltativamente, fornire controlli di autenticazione, autorizzazione e chiamata API.

La principale distinzione tra questo pattern e il pattern mesh nella sua applicazione risiede in 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 agli indirizzi IP specifici, le reti tra gli ambienti non devono essere allineate nel progetto. Gli scenari comuni applicabili includono, a titolo esemplificativo:

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

La comunicazione funziona nel seguente modo:

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

Architettura

Il seguente diagramma mostra un'architettura di riferimento per il traffico in uscita con accesso riservato e il pattern in entrata con accesso riservato:

L'approccio alla progettazione nel diagramma precedente comprende i seguenti elementi:

• Sul lato Google Cloud, esegui il deployment dei carichi di lavoro in un VPC (o VPC condiviso) senza esporli direttamente a internet.
• La rete dell'ambiente Google Cloud è estesa ad altri ambienti di computing. L'ambiente può essere on-premise o su un altro cloud. Per estendere l'ambiente, utilizza un modello di comunicazione con connettività ibrida e multi-cloud adatto per facilitare la comunicazione tra gli ambienti, in modo che possano utilizzare indirizzi IP interni.
• Facoltativamente, abilitando 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 consentire o vietare l'accesso a determinate API da origini specifiche prima di raggiungere il VPC dell'applicazione.
• Le API devono essere accessibili tramite un gateway API o un bilanciatore del carico per fornire un livello di proxy e un'astrazione o un'interfaccia 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 sovrapposizione.

Un'applicazione comune di questo pattern prevede il deployment dei backend delle applicazioni (o di un sottoinsieme di backend delle applicazioni) in Google Cloud durante l'hosting di altri componenti di backend e frontend in ambienti on-premise o in altri cloud (pattern ibrido a livelli o multi-cloud partizionato). Man mano che le applicazioni evolvono e migrano nel cloud, spesso emergono dipendenze e preferenze per servizi cloud specifici.

A volte, queste dipendenze e preferenze portano alla distribuzione di applicazioni e backend tra 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, è possibile utilizzare le funzionalità della connettività ibrida e multi-cloud esterna di Cloud Load Balancing 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 delle applicazioni tra diversi ambienti. Le richieste dal frontend ai servizi di backend ospitati in Google Cloud comunicano in modo sicuro sulla connessione di rete ibrida stabilita, facilitata da un bilanciatore del carico interno (ILB nel diagramma).

L'utilizzo del design di Google Cloud nel diagramma precedente aiuta a:

• 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 le applicazioni per internet con componenti delle applicazioni distribuiti (frontend o backend) e raggiungere i seguenti obiettivi, puoi utilizzare le funzionalità avanzate di bilanciamento del carico e sicurezza di Google Cloud, distribuiti nei punti di presenza (PoP):
• Riduci le spese in conto capitale e semplifica le operazioni utilizzando i servizi gestiti serverless.
• Ottimizzare le connessioni ai backend delle applicazioni a livello globale in termini di velocità e latenza.
  • La rete Cross-Cloud di Google Cloud consente la comunicazione multi-cloud tra i componenti dell'applicazione tramite connessioni private ottimali.
• Memorizza nella cache contenuti statici ad alta domanda e migliora le prestazioni delle applicazioni per le applicazioni che utilizzano Cloud Load Balancing globale fornendo l'accesso a Cloud CDN.
• Proteggi i frontend globali delle applicazioni per internet utilizzando le funzionalità di Google Cloud Armor che offrono servizi WAF (Web Application Firewall) distribuiti a livello globale e di mitigazione degli attacchi DDoS.
• Se vuoi, puoi incorporare Private Service Connect nel tuo progetto. In questo modo consenti un accesso privato e granulare alle API dei servizi Google Cloud o ai tuoi servizi pubblicati da altri ambienti senza attraversare la rete internet pubblica.

Varianti

I pattern di architettura di traffico in uscita riservato e in entrata con accesso riservato possono essere combinati con altri approcci per soddisfare diversi requisiti di progettazione, pur continuando a considerare i requisiti di comunicazione di questo pattern. I pattern offrono le seguenti opzioni:

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

Gateway API distribuiti

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

Il seguente diagramma illustra il modo in cui 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. Questa progettazione consente di applicare rigide misure di controllo dell'accesso, laddove solo gli indirizzi IP preapprovati (API di destinazione e destinazione o indirizzi IP degli endpoint Private Service Connect) possono comunicare tra Google Cloud e gli altri ambienti.

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

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

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

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

Per estendere la connettività all'ambiente remoto, questa progettazione utilizza il peering VPC diretto con funzionalità di scambio di route cliente. La progettazione consente a richieste API specifiche provenienti da carichi di lavoro ospitati all'interno del VPC dell'applicazione Google Cloud di instradare un 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 di gruppo di endpoint di rete ibrido nel VPC di transito. Questa configurazione è descritta nella sezione successiva: Comunicazione API bidirezionale con Private Service Connect.

Comunicazione API bidirezionale con Private Service Connect

A volte, le aziende potrebbero non aver bisogno di utilizzare immediatamente un gateway API (come Apigee) o potrebbero volerlo aggiungere in un secondo momento. Tuttavia, potrebbero sussistere requisiti aziendali per consentire la comunicazione e l'integrazione tra determinate applicazioni in ambienti diversi. Ad esempio, se la tua azienda ha acquisito un'altra, potrebbe essere necessario esporre a quell'azienda determinate applicazioni. Potrebbe dover esporre le applicazioni alla tua azienda. Entrambe le aziende potrebbero avere i propri carichi di lavoro ospitati in ambienti diversi (Google Cloud, on-premise o in altri cloud) e devono evitare la sovrapposizione di indirizzi IP. In questi casi, puoi usare 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 tra regioni e tramite connettività ibrida. Questa astrazione facilita l'integrazione di risorse da diversi cloud e ambienti on-premise su un modello di connettività ibrida e multi-cloud. Consente inoltre l'assemblaggio di applicazioni in ambienti multi-cloud e on-premise. Questo può soddisfare diversi requisiti di comunicazione, come l'integrazione di applicazioni sicure in cui non viene utilizzato un gateway API o non è previsto l'uso di un gateway.

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

• Tutte le considerazioni sulla progettazione e i suggerimenti di Private Service Connect discussi in questa guida si applicano alla progettazione.
• Se è necessaria un'ispezione aggiuntiva di livello 7, puoi integrare gli NVA con questa progettazione (nel VPC di transito).
• Questa progettazione può essere utilizzata 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 endpoint e interfacce Private Service Connect

Come discusso nel pattern in entrata con accesso riservato, una delle opzioni per abilitare la comunicazione client-servizio è l'utilizzo di un endpoint Private Service Connect per esporre un servizio in un VPC del producer a un VPC consumer. Questa connettività può essere estesa a un ambiente on-premise o anche a un altro ambiente cloud provider tramite una connettività ibrida. Tuttavia, in alcuni scenari, il servizio in hosting può richiedere anche una comunicazione privata.

Per accedere a un determinato servizio, ad esempio recuperare dati da origini dati che possono essere ospitate all'interno o all'esterno del VPC consumer, questa comunicazione privata può essere 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 del producer di servizi di accedere alla rete di un consumer. Ciò avviene condividendo un'interfaccia di rete, pur mantenendo la separazione tra i 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 del producer.

Un'interfaccia Private Service Connect è un'interfaccia di rete collegata al VPC consumer (di transito). È possibile raggiungere destinazioni esterne raggiungibili dal VPC consumer (di transito) a cui è collegata l'interfaccia Private Service Connect. Pertanto, questa connessione può essere estesa a un ambiente esterno tramite una connettività ibrida come 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, è possibile definire criteri di sicurezza nel sistema operativo guest della VM di interfaccia Private Service Connect. Per maggiori informazioni, consulta Configurare la sicurezza per le interfacce di Private Service Connect. Puoi anche prendere in considerazione un approccio alternativo se non è conforme agli standard o alla conformità di sicurezza della tua organizzazione.

Best practice

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

  • Questo approccio facilita anche la migrazione della soluzione in un ambiente completamente ospitato da Google Cloud, mantenendo al contempo 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 in altri ambienti quando questi ambienti sono in configurazioni ibride o multi-cloud permanenti o a lungo termine, considera quanto segue:

  • Usa Cloud Interconnect o Cross-Cloud Interconnect.
  • Per terminare le connessioni utente a livello di frontend di destinazione nell'ambiente appropriato, utilizza la modalità ibrida.

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

• Prima di progettare la connettività e i percorsi di routing, devi identificare le richieste API o di traffico da indirizzare a un gateway API locale o remoto, oltre agli ambienti di origine e di destinazione.

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

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

• Utilizza le regole firewall Virtual Private Cloud (VPC) o i criteri firewall per controllare l'accesso a livello di rete alle risorse di 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 dei tuoi endpoint.

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

• Se un carico di lavoro in una subnet privata richiede l'accesso a internet, utilizza Cloud NAT per evitare di assegnare un indirizzo IP esterno al carico di lavoro ed esporlo alla rete 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 ibridi e multi-cloud.

Modelli di passaggio

Con il pattern handover, l'architettura si basa sull'utilizzo dei servizi di archiviazione forniti da Google Cloud per collegare un ambiente di computing privato ai progetti in Google Cloud. Questo pattern si applica principalmente alle configurazioni che seguono il modello di architettura multi-cloud ibrido di analisi, in cui:

• Carichi di lavoro in esecuzione in un ambiente di computing privato o in un altro cloud per caricare dati in posizioni di archiviazione condivise. A seconda dei casi d'uso, i caricamenti potrebbero avvenire in blocco o a incrementi più piccoli.
• I carichi di lavoro ospitati su Google Cloud o altri servizi Google (ad esempio servizi di analisi dei dati e di intelligenza artificiale) utilizzano i dati provenienti dalle posizioni di archiviazione condivisa e li elaborano in modalità flusso o batch.

Architettura

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

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 applicazioni frontend correlate all'elaborazione dei dati, all'analisi e 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 Controlli di servizio VPC per limitare l'accesso ai servizi e ridurre al minimo i rischi di esfiltrazione di dati ingiustificati dai servizi Google Cloud.
• In questa architettura, la comunicazione con i bucket Cloud Storage, o Pub/Sub, avviene su reti pubbliche o tramite connettività privata tramite VPN, Cloud Interconnect o Cross-Cloud Interconnect. In genere, la decisione su come stabilire una connessione dipende da diversi aspetti, tra cui:
  • Volume di traffico previsto
  • Che si tratti di una configurazione temporanea o definitiva
  • Requisiti di sicurezza e conformità

Variante

A questo pattern possono essere applicate anche le opzioni di progettazione descritte nel pattern in entrata con accesso riservato, che utilizza gli endpoint Private Service Connect per le API di Google. In particolare, fornisce accesso a Cloud Storage, BigQuery e ad altre API dei servizi Google. Questo approccio richiede indirizzi IP privati su una connessione di rete ibrida e multi-cloud come VPN, Cloud Interconnect e Cross-Cloud Interconnect.

Best practice

• Blocca l'accesso ai bucket Cloud Storage e agli argomenti Pub/Sub.
• Ove applicabile, utilizza soluzioni cloud-first integrate per lo spostamento dei dati come la suite di soluzioni Google Cloud. Per soddisfare le tue esigenze relative ai casi 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, consulta la sezione Valutazione delle opzioni di trasferimento.

• Per ridurre al minimo la latenza e impedire trasferimenti e spostamenti di dati di volume elevato sulla rete internet pubblica, valuta l'utilizzo di Cloud Interconnect o Cross-Cloud Interconnect, incluso l'accesso agli endpoint Private Service Connect all'interno del Virtual Private Cloud per le API di Google.

• Per proteggere i servizi Google Cloud nei tuoi progetti e ridurre il rischio di esfiltrazione di dati, utilizza Controlli di servizio VPC. Questi controlli di 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 su una VPN autorizzata o Cloud Interconnect. Per ulteriori informazioni sui vantaggi dei perimetri di servizio, consulta Panoramica dei Controlli di servizio VPC.

• Comunica con carichi di lavoro di analisi dei dati pubblicati pubblicamente e 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 maggiore sicurezza e per evitare di rendere le istanze direttamente raggiungibili da internet.

• Se è necessario l'accesso a internet, puoi utilizzare Cloud NAT nello stesso VPC per gestire il traffico in uscita dalle istanze alla rete internet pubblica.

• Esamina le best practice generali per le topologie di networking ibride e multi-cloud.

Best practice generali

Durante la progettazione e l'onboarding di identità cloud, gerarchia delle risorse e reti delle zone di destinazione, tieni in considerazione i suggerimenti di progettazione descritti in Progettazione delle zone di destinazione in Google Cloud e le best practice per la sicurezza di Google Cloud descritte nel progetto delle basi aziendali. Convalida il progetto selezionato in base ai seguenti documenti:

• Best practice e architetture di riferimento per la progettazione di VPC
• Progetta la tua infrastruttura di rete
• Framework dell'architettura Google Cloud: sicurezza, privacy e conformità

Prendi in considerazione anche le seguenti best practice generali:

• Quando scegli un'opzione di connettività di rete ibrida o multi-cloud, considera i requisiti aziendali e delle applicazioni, come SLA, prestazioni, sicurezza, costi, affidabilità e larghezza di banda. Per ulteriori informazioni, vedi Scelta di un prodotto per la connettività di rete e Pattern per connettere altri provider di servizi cloud con Google Cloud.

• Utilizza 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 eseguire l'autenticazione sicura oltre i confini degli ambienti.

• Per esporre in sicurezza le applicazioni agli utenti aziendali in una configurazione ibrida e per scegliere l'approccio più adatto alle tue esigenze, devi seguire i metodi consigliati per integrare Google Cloud con il tuo sistema di gestione delle identità.

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

• Durante la progettazione degli ambienti on-premise e cloud, prendi in considerazione l'indirizzamento IPv6 fin dall'inizio e prendi in considerazione i servizi che lo supportano. Per ulteriori informazioni, consulta Introduzione a IPv6 su Google Cloud. Riassume i servizi supportati quando è stato scritto il blog.

• Durante la progettazione, il deployment e la gestione delle regole firewall VPC, puoi:

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

• Dovresti sempre progettare il cloud e la sicurezza della rete utilizzando un approccio alla sicurezza multilivello, prendendo in considerazione i livelli di sicurezza aggiuntivi, come i seguenti:

  • Google Cloud Armor
  • Sistema di rilevamento delle intrusioni nel cloud
  • IPS Cloud di nuova generazione per il firewall
  • Intelligence sulle minacce per le regole dei criteri firewall

  Questi livelli aggiuntivi possono aiutarti a filtrare, ispezionare e monitorare un'ampia varietà di minacce nei livelli di rete e di applicazione ai fini dell'analisi e della prevenzione.

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

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

• Una piattaforma API (gateway o proxy) e un 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 dell'API Cloud Load Balancing ti consente di:

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

    • Riduci la latenza
    • Ospita le API in tutto il mondo

    • Aumenta la disponibilità nei periodi di picco del traffico

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

  • Implementa una gestione avanzata del traffico.

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

  • Gestisci un bilanciamento del carico efficiente tra gateway in più regioni. Per ulteriori informazioni, guarda Protezione delle API e implementazione del failover multiregionale con PSC e Apigee.

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

• Se utilizzi Cloud Load Balancing, devi usare le funzionalità di ottimizzazione della capacità delle applicazioni ove applicabile. Questo può aiutarti ad affrontare alcuni problemi di capacità che possono verificarsi nelle applicazioni distribuite a livello globale.

  • Per un approfondimento sulla latenza, consulta Ottimizzare la 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, consulta Come posso criptare il mio traffico su Cloud Interconnect.

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

• Se hai bisogno di un volume di traffico maggiore su una connettività ibrida VPN rispetto a quello supportato da un singolo tunnel VPN, puoi valutare l'utilizzo dell'opzione di routing VPN ad alta disponibilità attivo/attivo.

  • Per configurazioni ibride o multi-cloud a lungo termine con volumi di trasferimento di dati in uscita elevati, prendi in considerazione Cloud Interconnect o Cross-Cloud Interconnect. Queste opzioni di connettività consentono di ottimizzare le prestazioni della connettività e potrebbero ridurre i costi 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 alle risorse di Google Cloud e provi a scegliere tra Cloud Interconnect, peering diretto o peering con operatori, ti consigliamo di utilizzare Cloud Interconnect, a meno che tu non abbia bisogno di accedere alle applicazioni Google Workspace. Per ulteriori informazioni, puoi confrontare le funzionalità del peering diretto con Cloud Interconnect e del peering con operatori con Cloud Interconnect.

• Concedi uno spazio di indirizzi IP sufficiente dal tuo attuale spazio di indirizzi IP RFC 1918 per contenere i sistemi ospitati nel cloud.

• Se esistono restrizioni tecniche che richiedono di conservare l'intervallo di indirizzi IP, puoi:

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

  • Esegui il provisioning e utilizza i tuoi indirizzi IPv4 pubblici per le risorse Google Cloud utilizzando il trasferimento del tuo IP (BYOIP) a Google.

• Se la progettazione della tua soluzione richiede l'esposizione di un'applicazione basata su Google Cloud alla rete internet pubblica, considera i suggerimenti di progettazione discussi in Networking per la distribuzione di applicazioni per internet.

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

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

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

  Per maggiori informazioni, vedi Sicurezza di Private Service Connect.

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

  • Esegui una valutazione completa dei livelli richiesti di affidabilità delle diverse applicazioni nei vari ambienti. In questo modo puoi raggiungere i tuoi obiettivi di disponibilità e resilienza.
  • Comprendi 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 un'unica console per la gestione della visibilità, del monitoraggio e della risoluzione dei problemi della rete.

Pattern 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 approcciarti agli ambienti ibridi e multi-cloud e come scegliere i carichi di lavoro adatti.
• Architetture di bilanciamento del carico globale che utilizzano i criteri di routing DNS: casi d'uso per i criteri di routing DNS di geolocalizzazione.
• Scopri di più sulla rete Cross-Cloud di Google Cloud, una piattaforma di rete globale aperta, sicura e ottimizzata per applicazioni e utenti in ambienti on-premise e in altri cloud.
• Progetta un'infrastruttura affidabile per i tuoi carichi di lavoro in Google Cloud: progetta linee guida per proteggere le 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 i pattern 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/perimetrale alla rete Google Cloud e scopri l'impatto della disconnessione temporanea da Google Cloud.