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