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 alla rete internet pubblica. Questo pattern è la controparte del il Pattern in uscita riservato ed è adatto a ibrido edge, ibrido a più livelli, e multi-cloud partizionato diversi scenari.
Come con il pattern del traffico in uscita riservato, puoi facilitare questa esposizione limitata attraverso un gateway API o un bilanciatore del carico, funge da facciata per carichi di lavoro o 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. Altri sistemi di cui è stato eseguito il deployment Google Cloud non è raggiungibile.
- Comunicazione da Google Cloud al computing privato o in altri ambienti cloud. Il traffico è solo dall'ambiente privato o da altri ambienti cloud le API in Google Cloud.
Architettura
Il seguente diagramma mostra un'architettura di riferimento che soddisfa le i requisiti del pattern di traffico 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 un VPC dell'applicazione (o più VPC).
- La rete dell'ambiente Google Cloud si estende ad altri ambienti di calcolo (on-premise o in un altro cloud) utilizzando la connettività di rete ibrida o multicloud per facilitare la comunicazione tra gli ambienti.
- Facoltativamente, puoi utilizzare un 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 firewall VPC per impedire ad alcune origini di accedere a determinate API attraverso un endpoint.
- Ispeziona il traffico di livello 7 nel VPC di transito integrando un'appliance virtuale di rete (NVA).
- Accedi alle API tramite un API gateway o un bilanciatore del carico (proxy o bilanciatore del carico delle applicazioni) per fornire un livello di proxy e un livello di astrazione o una facade per le API dei tuoi servizi. Se devi distribuire il traffico su più istanze di API Gateway, puoi utilizzare un bilanciatore del carico di rete passthrough interno.
- Fornisci accesso limitato e granulare a un servizio pubblicato tramite un endpoint Private Service Connect utilizzando un bilanciatore del carico tramite Private Service Connect per esporre un'applicazione o un servizio.
- Tutti gli ambienti devono utilizzare uno spazio di indirizzi IP RFC 1918 senza sovrapposizione.
Il seguente diagramma illustra la progettazione di questo modello 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à gateway o proxy
- Funzionalità di sicurezza
- Limitazione di frequenza
- Analytics
Nella progettazione:
- 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. Aiuta anche ai sistemi operativi di raggiungere direttamente le applicazioni senza passare 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 un’ispezione di sicurezza perimetrale esterno al VPC dell'applicazione, incluso il traffico di connettività ibrida. In questi casi, puoi incorporare una VPC di transito per implementare livelli di sicurezza aggiuntivi. Questi livelli, come le NVA di firewall di nuova generazione (NGFW) con più interfacce di rete, o Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS), eseguono un'analisi approfondita dei pacchetti al di fuori della VPC dell'applicazione, come illustrato nel seguente diagramma:
Come illustrato nel diagramma precedente:
- La connettività di rete verso nord (per il traffico proveniente da altri ambienti) passa attraverso un VPC di transito separato verso 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 Apigee.
Puoi eseguire il provisioning di diversi endpoint nella stessa rete VPC, come mostrato in nel seguente diagramma. Per trattare diversi casi d'uso, puoi controllare i diversi percorsi di rete possibili utilizzando il router Cloud le regole firewall VPC. Ad esempio, se colleghi la tua rete on-premise a Google Cloud utilizzando più connessioni di rete ibrida, puoi inviare parte del traffico on-premise ad API di Google o servizi pubblicati specifici tramite una connessione e il resto tramite un'altra connessione. Inoltre, puoi utilizzare l'accesso globale di Private Service Connect per fornire opzioni di failover.
Varianti
Il pattern dell'architettura gated in entrata può essere combinato con altri approcci a soddisfare diversi requisiti di progettazione, pur prendendo in considerazione la comunicazione i requisiti 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
Accedi alle API di Google da altri ambienti
Per scenari che richiedono l'accesso a servizi Google, come Cloud Storage o a BigQuery, senza inviare traffico sulla rete internet pubblica, Private Service Connect offre una soluzione. Come mostrato in nel diagramma seguente, consente la raggiungibilità alle API di Google supportate e servizi (tra cui Google Maps, Google Ads e Google Cloud) da ambienti on-premise o da altri ambienti cloud tramite una connessione di rete ibrida utilizzando l'indirizzo IP dell'endpoint Private Service Connect. Per ulteriori informazioni sull'accesso alle API di Google tramite gli endpoint Private Service Connect, consulta Informazioni sull'accesso alle API di Google tramite gli endpoint.
Nel diagramma precedente, la rete on-premise deve essere connessa alla rete VPC di transito (consumer) utilizzando i tunnel Cloud VPN o un collegamento VLAN Cloud Interconnect.
È possibile accedere alle API di Google utilizzando endpoint o backend. Gli endpoint ti consentono di scegliere come target delle 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 pesanti e monolitici che potrebbero basarsi componenti. O, più comunemente, quando si gestiscono applicazioni distribuite in più ambienti, tra cui on-premise e altri cloud, che richiedono e 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. Utilizzo Private Service Connect in Google Cloud facilita la e la connettività ai backend esposti attraverso l'endpoint Private Service Connect, idealmente utilizzando API predefinite, come illustrato nel seguente diagramma:
Il design nel diagramma precedente utilizza una Apigee ibrido che prevede un piano di gestione in Google Cloud e un runtime ospitato nell'altro tuo ambiente. Puoi installare e gestire il runtime su un gateway API distribuito su uno dei sistemi supportati Piattaforme Kubernetes nel tuo ambiente on-premise o in altri ambienti cloud. In base ai tuoi requisiti per i carichi di lavoro distribuiti su Google Cloud e altri ambienti, puoi utilizzare Apigee su Google Cloud con Apigee Hybrid. Per ulteriori informazioni, vedi Gateway API distribuiti.
Utilizza un'architettura hub and spoke per esporre i backend delle applicazioni ad altri ambienti
Esposizione delle API dai backend delle applicazioni ospitate in Google Cloud in alcuni scenari potrebbero essere necessarie reti VPC diverse. Come illustrato in Nel diagramma seguente, un VPC hub funge da punto centrale di interconnessione per i vari VPC (spoke), consentendo una comunicazione sicura su un cloud ibrido privato e la connettività 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 i VPC spoke non richiedano la comunicazione diretta tra VPC.
- Se è necessaria la comunicazione spoke-to-spoke, puoi utilizzare lo NVA per facilitare tale comunicazione.
- Se hai backend diversi in VPC diversi, puoi utilizzare Private Service Connect per esporli al VPC Apigee.
- Se il peering VPC viene utilizzato per i limiti nord e sud
tra i VPC spoke e il VPC hub, devi considerare
limitazione di transizione
delle reti VPC tramite peering VPC. Per ovviare a questo limite, puoi scegliere una delle seguenti opzioni:
- Per interconnettere le VPC, utilizza un'NVA.
- Ove applicabile, prendi in considerazione Private Service Connect un modello di machine learning.
- Per stabilire la connettività tra Il VPC e i backend Apigee che si trovano in altri di progetti Google Cloud nella stessa organizzazione senza componenti di rete aggiuntivi, utilizza VPC condiviso.
Se per l'ispezione del traffico sono richiesti gli NAV, incluso il traffico proveniente da in altri ambienti, la connettività ibrida a on-premise o ad altri ambienti devono essere terminati sul VPC di transito ibrido.
Se la progettazione non include l'NVA, puoi terminare la connettività al 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 situazioni in cui le richieste del client da internet devono ricevuti localmente da un frontend ospitato in un ambiente on-premise privato o nell'ambiente cloud, valuta la possibilità di utilizzare Apigee Hybrid come API gateway VPN ad alta disponibilità. Questo approccio facilita anche una migrazione senza problemi della soluzione a un ambiente completamente ospitato su Google Cloud, 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 questa progettazione offre la flessibilità provisioning di ulteriori misure di sicurezza perimetrali e 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 ulteriori informazioni, consulta Accedere all'endpoint da host on-premise.
- Per contribuire a proteggere i servizi Google Cloud nei tuoi progetti e contribuire a mitigare il rischio di esfiltrazione di dati, utilizza i Controlli di servizio VPC per specificare i perimetri di servizio a livello di progetto o di rete VPC.
- Se necessario, puoi estendere i perimetri di servizio in un ambiente ibrido su VPN o Cloud Interconnect. Per maggiori informazioni sui vantaggi dei perimetri di servizio, vedi Panoramica dei Controlli di servizio VPC.
- Utilizza le funzionalità di Regole firewall VPC o criteri firewall per controllare l'accesso a livello di rete alle risorse Private Service Connect tramite l'endpoint Private Service Connect. Ad esempio, le regole firewall in uscita nel VPC dell'applicazione (consumatore) possono limitare l'accesso dalle istanze VM all'indirizzo IP o alla subnet dei tuoi endpoint. Per ulteriori informazioni sulle regole firewall VPC in generale, consulta Regole firewall VPC.
- Quando si progetta una soluzione che include le VVA, è importante considerare l'alta disponibilità (HA) delle VM per evitare single point of failure che potrebbero bloccare tutte le comunicazioni. Segui le linee guida per la progettazione e l'implementazione della disponibilità elevata e della ridondanza fornite dal fornitore dell'NVA.
- Per rafforzare la sicurezza perimetrale e proteggere il gateway API di cui è stato eseguito il deployment nel rispettivo ambiente, puoi facoltativamente implementare i meccanismi del web application firewall e i meccanismi del cloud computing di un ambiente cloud (ibrido o altro). Implementa queste opzioni direttamente connessa a internet.
- Se le istanze richiedono l'accesso a internet, usa Cloud NAT nel VPC dell'applicazione per consentire ai carichi di lavoro di accedere a internet. In questo modo consente di evitare di assegnare istanze VM con indirizzi IP pubblici esterni il cui deployment viene eseguito dietro un gateway API o un bilanciatore del carico.
- Per il traffico web in uscita, utilizza Secure Web Proxy. Il proxy offre diversi vantaggi.
- Esamina il best practice generali per pattern di networking ibridi e multi-cloud.