L'architettura del pattern di rete Uscita controllata si basa sull'esposizione di API selezionate dall'ambiente on-premise o da un altro ambiente cloud ai carichi di lavoro di cui è stato eseguito il deployment in Google Cloud. Ciò avviene senza esporli direttamente alla rete internet pubblica da un ambiente on-premise o da altri ambienti cloud. Puoi facilitare questa esposizione limitata tramite un gateway o un proxy API oppure un bilanciatore del carico che funge da facade per i carichi di lavoro esistenti. Puoi eseguire il deployment della funzionalità del gateway API in un segmento di rete perimetrale isolato, ad esempio una rete perimetrale.
Il pattern di rete di uscita controllata si applica principalmente (ma non solo) ai pattern di architettura delle applicazioni a più livelli e ai pattern di architettura delle applicazioni partizionate. Quando esegui il deployment dei carichi di lavoro di backend all'interno di una rete interna, la rete di uscita gated contribuisce a mantenere un livello di sicurezza più elevato all'interno del tuo ambiente di calcolo on-premise. Il pattern richiede di collegare gli ambienti di calcolo 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 calcolo privato direttamente dall'interno Google Cloud.
- La comunicazione dall'ambiente di calcolo privato a qualsiasi workload impiegato in Google Cloud non è consentita.
- Il traffico verso le API private in altri ambienti viene avviato solo dall' Google Cloud ambiente.
Questa guida si concentra sugli ambienti ibridi e multi-cloud collegati tramite una rete ibrida privata. Se i requisiti di sicurezza della tua organizzazione lo consentono, le chiamate API alle API target remote con indirizzi IP pubblici possono essere raggiunte direttamente tramite internet. Tuttavia, devi considerare i seguenti meccanismi di sicurezza:
- API OAuth 2.0 con Transport Layer Security (TLS).
- Limitazione di frequenza.
- Criteri di protezione dalle minacce.
- TLS reciproco configurato nel backend del livello API.
- Filtro della lista consentita di indirizzi IP configurato per consentire la comunicazione solo con origini e destinazioni API predefinite da entrambi i lati.
Per proteggere un proxy API, prendi in considerazione questi altri aspetti di sicurezza. Per saperne di più, consulta le best practice per la protezione di applicazioni e API utilizzando 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:
- Google Cloud D'altra parte, puoi eseguire il deployment dei carichi di lavoro in virtual private cloud (VPC). Le VPC possono essere singole o multiple (condivise o non condivise). Il deployment deve essere in linea con i progetti e con il design della gerarchia delle risorse della tua organizzazione.
- Le reti VPC dell' Google Cloud ambiente vengono estese agli altri ambienti di calcolo. Gli ambienti possono essere on-premise o in un altro cloud. Per facilitare la comunicazione tra gli ambienti che utilizzano 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 il filtro della lista consentita di indirizzi IP. Il traffico di ritorno da queste connessioni è consentito se utilizzi 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:
Appliance virtuale di rete (NVA) con funzionalità di ispezione del firewall di nuova generazione (NGFW) posizionate nel percorso di rete.
Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS) per implementare l'ispezione approfondita dei pacchetti per la prevenzione delle minacce.
Tutti gli ambienti condividono uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.
Varianti
Il pattern di architettura di uscita controllata può essere combinato con altri approcci per soddisfare requisiti di progettazione diversi che prendono comunque in considerazione i requisiti di comunicazione di questo pattern. Il pattern offre le seguenti opzioni:
- Utilizza Google Cloud API Gateway e il frontend globale
- Esporre servizi remoti utilizzando Private Service Connect
Utilizza Google Cloud API Gateway e il frontend globale
Con questo approccio di progettazione, l'esposizione e la gestione delle API risiedono inGoogle Cloud. Come mostrato nel diagramma precedente, puoi farlo tramite 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
Google Cloud Le funzionalità di frontend globale come Cloud Load Balancing, Cloud CDN (se si accede tramite Cloud Interconnect) e Cross-Cloud Interconnect migliorano la velocità con cui gli utenti possono accedere alle applicazioni i cui backend sono ospitati nei tuoi ambienti on-premise e in altri ambienti cloud.
L'ottimizzazione delle velocità di caricamento dei contenuti viene raggiunta pubblicando queste applicazioni da Google Cloud point of presence (POP). Google Cloud I POP 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 contribuiscono a fornire API ad alte prestazioni quando utilizzi Apigee con Cloud CDN per eseguire le seguenti operazioni, guarda Caricare API ad alte prestazioni con Apigee e Cloud CDN su YouTube:
- Riduci la latenza.
- Ospitare API a livello globale.
- 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.
La rete in uscita in questo progetto viene stabilita tramite:
- Un bilanciatore del carico (LB nel diagramma), in cui terminano le richieste dei client, elabora il traffico e lo instrada a un backend Private Service Connect.
- Un backend di Private Service Connect consente a un Google Cloud bilanciatore del carico di inviare le richieste dei client tramite una connessione Private Service Connect associata a un collegamento di servizio del producer al servizio pubblicato (istanza di runtime Apigee) utilizzando gruppi di endpoint di rete (NEG) Private Service Connect.
Il networking verso sud viene stabilito tramite:
- Un endpoint Private Service Connect che fa riferimento a un collegamento di servizio associato a un bilanciatore del carico interno (ILB nel diagramma) nella VPC del cliente.
L'LB viene disegnato con gruppi di endpoint di rete con connettività ibrida (NEG con connettività ibrida).
Per accedere ai servizi ibridi, utilizza il NEG di connettività ibrida tramite una connettività di rete ibrida, come VPN o Cloud Interconnect.
Per ulteriori informazioni, consulta Configurare un bilanciatore del carico di rete proxy interno regionale con connettività ibrida e Pattern di implementazione di Private Service Connect.
Esporre servizi remoti tramite Private Service Connect
Utilizza l'opzione Private Service Connect per esporre i servizi remoti per i seguenti scenari:
- Non utilizzi una piattaforma API o vuoi evitare di collegare la tua
intera rete VPC direttamente a un ambiente esterno per i seguenti
motivi:
- Hai limitazioni di sicurezza o requisiti di conformità.
- Esiste una sovrapposizione di intervalli di indirizzi IP, ad esempio in uno scenario di fusione e acquisizione.
- Per abilitare comunicazioni unidirezionali sicure tra client, applicazioni e servizi in tutti gli ambienti anche quando hai una scadenza breve.
- Potresti dover fornire connettività a più VPC consumer tramite una VPC di produzione di servizi (VPC di transito) per offrire modelli di servizio multi-tenant o mono-tenant altamente scalabili, in modo da raggiungere i servizi pubblicati in altri ambienti.
L'utilizzo di Private Service Connect per le applicazioni utilizzate come API fornisce un indirizzo IP interno per le applicazioni pubblicate, consentendo l'accesso sicuro all'interno della rete privata in più regioni e tramite connettività ibrida. Questa astrazione facilita l'integrazione delle risorse da diversi cloud e ambienti on-premise tramite un modello di connettività ibrida e multi-cloud. Puoi accelerare l'integrazione delle applicazioni ed esporre in modo sicuro le applicazioni che si trovano 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 allegato del 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 ibrida (NEG di connettività ibrida) in un VPC producer che in questo progetto funge da VPC di transito.
Nel diagramma precedente, i workload nella rete VPC della tua applicazione possono raggiungere i servizi ibridi in esecuzione nel tuo ambiente on-premise o in altri ambienti cloud tramite l'endpoint Private Service Connect, come illustrato nel seguente diagramma. Questa opzione di progettazione per le comunicazioni unidirezionali offre un'alternativa al peering con un VPC di transito.
Nell'ambito del design nel diagramma precedente, più frontend, backend o endpoint possono connettersi allo stesso collegamento del servizio, che consente a più reti VPC o a più utenti di accedere allo stesso servizio. Come illustrato nel diagramma seguente, puoi rendere l'applicazione accessibile a più VPC. Questa accessibilità può essere utile in scenari di servizi multi-tenant in cui il servizio viene utilizzato da più VPC dei consumatori anche se i relativi intervalli di indirizzi IP si sovrappongono.
La sovrapposizione degli indirizzi IP è uno dei problemi più comuni durante l'integrazione di applicazioni situate in ambienti diversi. La connessione Private Service Connect nel seguente diagramma aiuta a evitare il problema di sovrapposizione degli indirizzi IP. Ciò avviene senza richiedere il provisioning o la gestione di componenti di rete aggiuntivi, come Cloud NAT o un'NVA, per eseguire la traduzione dell'indirizzo IP. Per un esempio di configurazione, consulta Pubblicare un servizio ibrido utilizzando Private Service Connect.
Il design presenta i seguenti vantaggi:
- Evita potenziali dipendenze di scalabilità condivisa e complessità di gestione su larga scala.
- Migliora la sicurezza fornendo un controllo granulare della connettività.
- Riduce il coordinamento degli indirizzi IP tra il produttore e il consumatore del servizio e l'ambiente esterno remoto.
L'approccio di progettazione nel diagramma precedente può essere ampliato in fasi successive per integrare Apigee come piattaforma API utilizzando le opzioni di progettazione della rete discusse in precedenza, inclusa l'opzione Private Service Connect.
Puoi rendere l'endpoint Private Service Connect accessibile da altre regioni utilizzando l'accesso globale Private Service Connect.
Il client che si connette all'endpoint Private Service Connect può essere nella stessa regione dell'endpoint o in un'altra regione. Questo approccio potrebbe essere utilizzato per fornire alta disponibilità ai servizi ospitati in più regioni o per accedere ai servizi disponibili in una singola regione da altre regioni. Quando un endpoint di Private Service Connect viene acceduto da risorse ospitate in altre regioni, ai costi di traffico in uscita interregionale si applicano i costi per il traffico destinato agli endpoint con accesso globale.
Google CloudBest practice
- La scelta di Apigee e Apigee Hybrid come soluzione per la tua piattaforma API offre diversi vantaggi. Fornisce un livello proxy e un'astrazione o una facade per le API dei servizi di backend, combinate con funzionalità di sicurezza, limitazione della frequenza, quote e analisi.
- Utilizza Apigee Adapter for Envoy con un'architettura di deployment di Apigee Hybrid con Kubernetes, se applicabile ai tuoi requisiti e all'architettura.
- I VPC e la progettazione del progetto in Google Cloud devono essere basati sulla gerarchia delle risorse e sui requisiti del modello di comunicazione sicura.
- Quando vengono utilizzate API con gateway API, devi utilizzare anche una lista consentita di indirizzi IP. Una lista consentita limita le comunicazioni alle origini e alle destinazioni degli indirizzi IP specifici dei consumer e dei gateway API che potrebbero essere ospitati in ambienti diversi.
- Utilizza regole del firewall VPC o criteri del firewall per controllare l'accesso alle risorse Private Service Connect tramite l'endpoint Private Service Connect.
- Se un'applicazione è esposta esternamente tramite un bilanciatore del carico delle applicazioni, valuta la possibilità di utilizzare Google Cloud Armor come un ulteriore livello di sicurezza per proteggerti da attacchi DDoS e minacce di sicurezza del livello di applicazione.
Se le istanze richiedono l'accesso a internet, utilizza Cloud NAT nella VPC dell'applicazione (consumatore) 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 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 ibrida e multicloud.