L'architettura del pattern di accesso controllato si basa sull'esposizione di API selezionate dei carichi di lavoro in esecuzione in Google Cloud all'ambiente di calcolo privato senza esporle a internet pubblico. Questo modello è la controparte del modello di uscita con controllo e si adatta bene a scenari di ibrido edge, ibrido a più livelli e multicloud partizionato.
Come per il pattern di uscita controllata, puoi facilitare questa esposizione limitata tramite un gateway API o un bilanciatore del carico che funge da facciata per i carichi di lavoro o i servizi esistenti. In questo modo, diventa accessibile a ambienti di computing privati, ambienti on-premise o altri ambienti cloud, come segue:
- I carichi di lavoro di cui esegui il deployment nell'ambiente di calcolo privato o in altri ambienti cloud sono in grado di comunicare con il gateway API o il bilanciatore del carico utilizzando indirizzi IP interni. Non è possibile raggiungere altri sistemi diGoogle Cloud .
- La comunicazione dall' Google Cloud all'ambiente di calcolo privato o ad altri ambienti cloud non è consentita. Il traffico viene avviato solo dall'ambiente privato o da altri ambienti cloud alle API in Google Cloud.
Architettura
Il seguente diagramma mostra un'architettura di riferimento che soddisfa i requisiti del pattern di ingresso con controllo.
La descrizione dell'architettura nel diagramma precedente è la seguente:
- Sul Google Cloud lato, esegui il deployment dei carichi di lavoro in un VPC (o in più VPC) per le applicazioni.
- La Google Cloud rete dell'ambiente si estende ad altri ambienti di calcolo (on-premise o su un altro cloud) utilizzando la connettività di rete ibrida o multicloud per facilitare la comunicazione tra gli ambienti.
- Facoltativamente, puoi utilizzare una VPC di transito per:
- Fornisci ulteriori livelli di sicurezza del perimetro per consentire l'accesso a API specifiche all'esterno della VPC dell'applicazione.
- Indirizza il traffico agli indirizzi IP delle API. Puoi creare regole del firewall VPC per impedire ad alcune origini di accedere a determinate API tramite un endpoint.
- Ispeziona il traffico di livello 7 nel VPC di transito integrando un'appliance virtuale di rete (NVA).
- Accedi alle API tramite un gateway API o un bilanciatore del carico (proxy o bilanciatore del carico delle applicazioni) per fornire un livello di proxy e un livello di astrazione o una facade per le API dei tuoi servizi. Se devi distribuire il traffico su più istanze di API Gateway, puoi utilizzare un bilanciatore del carico di rete passthrough interno.
- Fornisci accesso limitato e granulare a un servizio pubblicato tramite un endpoint Private Service Connect utilizzando un bilanciatore del carico tramite Private Service Connect per esporre un'applicazione o un servizio.
- Tutti gli ambienti devono utilizzare uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.
Il seguente diagramma illustra il design di questo pattern utilizzando Apigee come piattaforma API.
Nel diagramma precedente, l'utilizzo di Apigee come piattaforma API fornisce le seguenti funzionalità per abilitare il pattern di accesso controllato:
- Funzionalità di gateway o proxy
- Funzionalità di sicurezza
- Limitazione di frequenza
- Analytics
Nel design:
- La connettività di rete in uscita (per il traffico proveniente da altri ambienti) passa attraverso un endpoint Private Service Connect nella VPC dell'applicazione associata alla VPC Apigee.
- Nella VPC dell'applicazione viene utilizzato un bilanciatore del carico interno per esporre le API dell'applicazione tramite un endpoint Private Service Connect presentato nella VPC di Apigee. Per ulteriori informazioni, consulta Architettura con il peering VPC disattivato.
Configura le regole del firewall e il filtro del traffico nel VPC dell'applicazione. In questo modo, viene fornito un accesso granulare e controllato. Inoltre, aiuta a impedire ai sistemi di raggiungere direttamente le tue applicazioni senza passare per l'endpoint Private Service Connect e il gateway API.
Inoltre, puoi limitare la pubblicità della sottorete dell'indirizzo IP interno del carico di lavoro di backend nel VPC dell'applicazione alla rete on-premise per evitare la raggiungibilità diretta senza passare per l'endpoint Private Service Connect e il gateway API.
Alcuni requisiti di sicurezza potrebbero richiedere l'ispezione della sicurezza del perimetro al di fuori del VPC dell'applicazione, incluso il traffico di connettività ibrida. In questi casi, puoi incorporare un VPC di transito per implementare livelli di sicurezza ulteriori. Questi livelli, come le NVA di firewall di nuova generazione (NGFW) con più interfacce di rete, o Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS), eseguono un'analisi approfondita dei pacchetti al di fuori della VPC dell'applicazione, come illustrato nel seguente diagramma:
Come illustrato nel diagramma precedente:
- La connettività di rete in uscita (per il traffico proveniente da altri ambienti) passa attraverso un VPC di transito separato verso l'endpoint Private Service Connect nel VPC di transito associato al VPC Apigee.
- Nella VPC dell'applicazione, un bilanciatore del carico interno (ILB nel diagramma) viene utilizzato per esporre l'applicazione tramite un endpoint Private Service Connect nella VPC di Apigee.
Puoi eseguire il provisioning di più endpoint nella stessa rete VPC, come mostrato nel diagramma seguente. Per coprire diversi casi d'uso, puoi controllare i diversi percorsi di rete possibili utilizzando le regole firewall del router Cloud e VPC. Ad esempio, se colleghi la tua rete on-premise Google Cloud utilizzando più connessioni di rete ibrida, puoi inviare parte del traffico on-premise ad API di Google o servizi pubblicati specifici Google Cloud tramite una connessione e il resto tramite un'altra. Inoltre, puoi utilizzare l'accesso globale di Private Service Connect per fornire opzioni di failover.
Varianti
Il pattern di architettura ingresso controllato può essere combinato con altri approcci per soddisfare requisiti di progettazione diversi, tenendo comunque conto dei requisiti di comunicazione del pattern. Il pattern offre le seguenti opzioni:
Esporre i backend delle applicazioni ad altri ambienti utilizzando Private Service Connect
Utilizza un'architettura hub and spoke per esporre i backend delle applicazioni ad altri ambienti
Accedere alle API di Google da altri ambienti
Per gli scenari che richiedono l'accesso ai servizi Google, come Cloud Storage o BigQuery, senza inviare traffico tramite la rete internet pubblica, Private Service Connect offre una soluzione. Come mostrato nel diagramma seguente, consente di raggiungere le API e i servizi di Google supportati (inclusi Google Maps, Google Ads eGoogle Cloud) da ambienti on-premise o di altro tipo tramite una connessione di rete ibrida che utilizza l'indirizzo IP dell'endpoint Private Service Connect. Per ulteriori informazioni sull'accesso alle API di Google tramite gli endpoint di Private Service Connect, consulta Informazioni sull'accesso alle API di Google tramite gli endpoint.
Nel diagramma precedente, la rete on-premise deve essere connessa alla rete VPC di transito (consumer) utilizzando i tunnel Cloud VPN o un collegamento VLAN Cloud Interconnect.
È possibile accedere alle API di Google utilizzando endpoint o backends. Endpoints ti consente di scegliere come target un bundle di API di Google. I backend ti consentono di scegliere come target una specifica API di Google regionale.
Esporre i backend delle applicazioni ad altri ambienti utilizzando Private Service Connect
In scenari specifici, come evidenziato dal pattern ibrido a più livelli, potresti dover eseguire il deployment dei backend in Google Cloud mantenendo i frontend in ambienti di calcolo privati. Sebbene meno comune, questo approccio è applicabile quando si ha a che fare con frontend monolitici di grandi dimensioni che potrebbero fare affidamento su componenti legacy. In alternativa, più comunemente, quando gestisci applicazioni distribuite su più ambienti, inclusi on-premise e altri cloud, che richiedono la connettività ai backend ospitati in Google Cloud su una rete ibrida.
In un'architettura di questo tipo, puoi utilizzare un gateway API o un bilanciatore del carico locale nell'ambiente on-premise privato o in altri ambienti cloud per esporre direttamente il frontend dell'applicazione alla rete internet pubblica. L'utilizzo di Google Cloud Private Service Connect semplifica la connettività privata ai backend esposti tramite un endpoint Private Service Connect, idealmente utilizzando API predefinite, come illustrato nel seguente diagramma:
Il design nel diagramma precedente utilizza un deployment di Apigee Hybrid costituito da un piano di gestione in Google Cloud e un piano di runtime ospitato nell'altro ambiente. Puoi installare e gestire il piano di runtime su un API gateway distribuito su una delle piattaforme Kubernetes supportate nel tuo ambiente on-premise o in altri ambienti cloud. In base ai tuoi requisiti per i workload distribuiti su Google Cloud e in altri ambienti, puoi utilizzare Apigee su Google Cloud con Apigee Hybrid. Per ulteriori informazioni, consulta Gateway API distribuiti.
Utilizza un'architettura hub and spoke per esporre i backend delle applicazioni ad altri ambienti
In alcuni scenari potrebbe essere necessario esporre le API dai backend delle applicazioni ospitati in Google Cloud diverse reti VPC. Come illustrato nel diagramma seguente, un VPC hub funge da punto di interconnessione centrale per i vari VPC (spoke), consentendo la comunicazione sicura tramite la connettività ibrida privata. Se vuoi, puoi utilizzare le funzionalità di API Gateway locale in altri ambienti, come Apigee Hybrid, per terminare le richieste client localmente dove è ospitato il frontend dell'applicazione.
Come illustrato nel diagramma precedente:
- Per fornire ulteriori funzionalità di ispezione di livello 7 NGFW, l'NVA con funzionalità NGFW è facoltativamente integrata nel design. Potresti richiedere queste funzionalità per rispettare requisiti di sicurezza specifici e gli standard delle norme di sicurezza della tua organizzazione.
Questo design presuppone che le VPC spoke non richiedano la comunicazione diretta tra VPC.
- Se è richiesta la comunicazione da spoke a spoke, puoi utilizzare la NVA per semplificarla.
- Se hai backend diversi in VPC diversi, puoi utilizzare Private Service Connect per esporli al VPC Apigee.
- Se il peering VPC viene utilizzato per la connettività northbound e southbound tra le VPC spoke e la VPC hub, devi prendere in considerazione la limitazione di transitività della connettività VPC tramite il peering VPC. Per ovviare a questo limite, puoi scegliere una delle seguenti opzioni:
- Per interconnettere le VPC, utilizza un'NVA.
- Se applicabile, valuta il modello Private Service Connect.
- Per stabilire la connettività tra la VPC Apigee e i backend che si trovano in altriGoogle Cloud progetti della stessa organizzazione senza componenti di rete aggiuntivi, utilizza la VPC condivisa.
Se sono necessarie NVA per l'ispezione del traffico, incluso il traffico proveniente da altri ambienti, la connettività ibrida agli ambienti on-premise o ad altri ambienti cloud deve essere terminata nel VPC di transito ibrido.
Se il design non include l'NVA, puoi terminare la connettività ibrida nel VPC hub.
Se sono richieste determinate funzionalità di bilanciamento del carico o di sicurezza, ad esempio l'aggiunta di WAF o protezione DDoS di Google Cloud Armor, puoi eventualmente implementare un bilanciatore del carico delle applicazioni esterno al perimetro tramite una VPC esterna prima di inoltrare le richieste dei client esterni ai backend.
Best practice
- Per le situazioni in cui le richieste dei client provenienti da internet devono essere ricevute localmente da un frontend ospitato in un ambiente cloud on-premise privato o di altro tipo, valuta la possibilità di utilizzare Apigee Hybrid come soluzione di gateway API. Questo approccio facilita anche una migrazione senza problemi della soluzione a un ambiente completamente Google Cloud-hosted, mantenendo la coerenza della piattaforma API (Apigee).
- Utilizza Apigee Adapter for Envoy con un'architettura di deployment di Apigee Hybrid con Kubernetes, se applicabile ai tuoi requisiti e all'architettura.
- La progettazione di VPC e progetti in Google Cloud deve rispettare la gerarchia delle risorse e i requisiti del modello di comunicazione sicura, come descritto in questa guida.
- L'integrazione di un VPC di transito in questo design offre la flessibilità di eseguire il provisioning di ulteriori misure di sicurezza del perimetro e connettività ibrida al di fuori del VPC del carico di lavoro.
- Utilizza Private Service Connect per accedere alle API e ai servizi Google da ambienti on-premise o da altri ambienti cloud utilizzando l'indirizzo IP interno dell'endpoint su una rete di connettività ibrida. Per saperne di più, vedi Accedere all'endpoint da host on-premise.
- Per contribuire a proteggere i Google Cloud servizi nei tuoi progetti e contribuire a mitigare il rischio di esfiltrazione di dati, utilizza i Controlli di servizio VPC per specificare i perimetri di servizio a livello di progetto o rete VPC.
- Se necessario, puoi estendere i perimetri dei servizi a un ambiente ibrido tramite una VPN o Cloud Interconnect. Per ulteriori informazioni sui vantaggi dei perimetri di servizio, consulta la Panoramica dei Controlli di servizio VPC.
- Utilizza regole del firewall VPC o criteri del firewall per controllare l'accesso a livello di rete alle risorse Private Service Connect tramite l'endpoint Private Service Connect. Ad esempio, le regole firewall in uscita nel VPC dell'applicazione (consumatore) possono limitare l'accesso dalle istanze VM all'indirizzo IP o alla subnet dei tuoi endpoint. Per ulteriori informazioni sulle regole firewall VPC in generale, consulta Regole firewall VPC.
- Quando progetti una soluzione che include NVA, è importante prendere in considerazione l'alta disponibilità (HA) delle NVA per evitare un singolo punto di errore che potrebbe bloccare tutte le comunicazioni. Segui le indicazioni per la progettazione e l'implementazione dell'HA e della ridondanza fornite dal fornitore dell'NVA.
- Per rafforzare la sicurezza del perimetro e proteggere il tuo API gateway di cui è stato eseguito il deployment nel rispettivo ambiente, puoi eventualmente implementare meccanismi di bilanciamento del carico e web application firewall nell'altro ambiente di calcolo (ibrido o altro cloud). Implementa queste opzioni nella rete di perimetro collegata direttamente a internet.
- Se le istanze richiedono l'accesso a internet, utilizza Cloud NAT nella VPC dell'applicazione per consentire ai carichi di lavoro di accedere a internet. In questo modo, puoi evitare di assegnare istanze VM con indirizzi IP pubblici esterni in sistemi di cui è stato eseguito il deployment dietro un API gateway o un bilanciatore del carico.
- Per il traffico web in uscita, utilizza Secure Web Proxy. Il proxy offre diversi vantaggi.
- Consulta le best practice generali per i pattern di networking ibrida e multicloud.