L'architettura del pattern gated in entrata si basa sull'esposizione del modello API dei carichi di lavoro in esecuzione su Google Cloud nell'ambiente di computing privato senza esporli 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 sarà accessibile ai privati ambienti di computing, ambienti on-premise o in un altro ambiente cloud, come segue:
- Carichi di lavoro di cui esegui il deployment nell'ambiente di computing privato o in altro ambienti cloud sono in grado di comunicare con il gateway API 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 altre risorse di computing (on-premise o su un altro cloud) utilizzando ambienti ibridi connettività di rete multi-cloud per facilitare la comunicazione ambienti cloud-native.
- Facoltativamente, puoi utilizzare un VPC di transito per:
- Fornire livelli di sicurezza perimetrali aggiuntivi per consentire l'accesso ad API specifiche al di fuori del VPC della tua applicazione.
- Instrada 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 al VPC di transito integrando una appliance virtuale di rete (NVA).
- Accedi alle API tramite un gateway API o un bilanciatore del carico (proxy o del carico delle applicazioni) per fornire un livello proxy e un'astrazione per le API di servizio. Se devi distribuire il traffico in più istanze del gateway API, potresti utilizzare bilanciatore del carico di rete passthrough interno.
- Fornire un accesso limitato e granulare a un 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'uso di Apigee come piattaforma API fornisce per abilitare il pattern in entrata con accesso riservato:
- Funzionalità gateway o proxy
- Funzionalità di sicurezza
- Limitazione di frequenza
- Analytics
Nella progettazione:
- La connettività di rete verso nord (per il traffico proveniente da altri ambienti) passa attraverso un servizio Private Service Connect nel VPC della tua applicazione, associate al VPC di Apigee.
- Nel VPC dell'applicazione viene utilizzato un bilanciatore del carico interno per esporre API delle applicazioni tramite un endpoint Private Service Connect presentati nel VPC di Apigee. Per ulteriori informazioni, vedi 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. 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à dell'IP interno del carico di lavoro backend nel VPC dell'applicazione rete on-premise per evitare la connettività diretta senza passare attraverso l'endpoint Private Service Connect e l'API gateway VPN ad alta disponibilità.
Alcuni requisiti di sicurezza potrebbero richiedere un’ispezione di sicurezza perimetrale esterno al VPC dell'applicazione, incluso il traffico di connettività ibrida. In tale casi, puoi incorporare un VPC di transito per implementare diversi strati. Questi livelli, come gli NVA dei firewall di nuova generazione (NGFW) con più interfacce di rete, o Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS), esegui un'ispezione approfondita dei pacchetti al di fuori del tuo VPC dell'applicazione, come illustrato nel diagramma seguente:
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.
- Nel VPC dell'applicazione, viene fornito un bilanciatore del carico interno (ILB nel diagramma) utilizzata per esporre l'applicazione tramite Endpoint Private Service Connect in Apigee in un VPC.
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 connetti la tua rete on-premise a Google Cloud utilizzando più connessioni di networking ibride, Inviare una parte del traffico da on-premise a specifiche API di Google o servizi pubblicati su una connessione e il resto su un'altra. Inoltre, puoi utilizzare Accesso globale a Private Service Connect per offrire 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:
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 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à alla 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 che accede alle API di Google attraverso gli endpoint Private Service Connect, vedi Informazioni sull'accesso alle API di Google tramite endpoint.
Nel diagramma precedente, la rete on-premise deve essere connessa una rete VPC di transito (consumer) utilizzando tunnel Cloud VPN o Collegamento VLAN di Cloud Interconnect.
API di Google sono accessibili utilizzando endpoint o backend. Gli endpoint ti consentono di scegliere come target delle API di Google. I backend ti consentono di scegliere come target API di Google regionale.
Esponi i backend delle applicazioni ad altri ambienti utilizzando Private Service Connect
In scenari specifici, come evidenziato dal pattern ibrido a più livelli, potresti di eseguire il deployment dei backend in Google Cloud mantenendo i frontend ambienti di computing 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 questa architettura, è possibile utilizzare un gateway API locale o un bilanciatore del carico ambiente on-premise privato o 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 diagramma seguente:
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 a per carichi di lavoro distribuiti tra Google Cloud e altri ambienti, puoi utilizzare Apigee su Google Cloud con Apigee ibrida. Per ulteriori informazioni, vedi Gateway API distribuiti.
Usa un'architettura hub e 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. Facoltativamente, funzionalità gateway API locali in altri ambienti, come Apigee ibrido, può essere utilizzato per terminare le richieste del client localmente dove il frontend dell'applicazione in hosting.
Come illustrato nel diagramma precedente:
- Per fornire ulteriori capacità di ispezione NGFW Layer 7, l'unità NVA con Le funzionalità NGFW sono facoltativamente integrate nel design. Potresti richiedono che queste capacità rispettino specifici requisiti di sicurezza e gli standard dei criteri di sicurezza della tua organizzazione.
Questa progettazione presuppone che i VPC spoke non richiedano un VPC diretto al VPC la comunicazione.
- 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 esporre questi backend al VPC di 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 utilizzare una delle seguenti opzioni:
- Per interconnettere i VPC, utilizza una 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 asset display, 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 alcune funzionalità di bilanciamento del carico o funzionalità di sicurezza vengono come l'aggiunta di WAF o protezione DDoS di Google Cloud Armor, puoi facoltativamente eseguire il deployment di un bilanciatore del carico delle applicazioni esterno al perimetro tramite un il VPC prima di instradare 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 inoltre una migrazione senza problemi la soluzione a un ambiente completamente ospitato su Google Cloud mantenendo la coerenza della piattaforma API (Apigee).
- Utilizza Apigee Adapter per Envoy con un Deployment ibrido di Apigee con Kubernetes ove applicabile ai tuoi requisiti e all'architettura.
- La progettazione dei VPC e dei progetti in Google Cloud deve seguire le la gerarchia delle risorse e i requisiti del modello di comunicazione sicura, descritti in questa guida.
- L'integrazione di un VPC di transito in questa progettazione offre la flessibilità esegui il provisioning di ulteriori misure di sicurezza perimetrali e della connettività ibrida all'esterno del VPC del carico di lavoro.
- Usa Private Service Connect per accedere alle API di Google e da ambienti on-premise o in altri ambienti cloud utilizzando l'indirizzo IP interno l'endpoint su una rete di connettività ibrida. Per ulteriori informazioni, vedi Accedi all'endpoint da host on-premise.
- Per contribuire a proteggere i servizi Google Cloud nei tuoi progetti
mitigazione del rischio di esfiltrazione di dati, utilizza i Controlli di servizio VPC per specificare
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: regole firewall in uscita al VPC dell'applicazione (consumer) può limitare l'accesso dalle istanze VM a l'indirizzo IP o la subnet dei tuoi endpoint. Per ulteriori informazioni sul VPC le regole firewall 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 la progettazione di alta disponibilità e ridondanza e le indicazioni fornite dal fornitore di NVA. Per ulteriori informazioni, per ottenere una disponibilità elevata tra le appliance virtuali, Sezione delle opzioni di architettura delle 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 i meccanismi del web application firewall e di bilanciamento del carico 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.