L'architettura del pattern di networking del traffico in uscita riservato si basa sull'esposizione di API selezionate dall'ambiente on-premise o da un altro ambiente cloud ai carichi di lavoro di cui viene eseguito il deployment in Google Cloud. Lo fa senza esporli direttamente alla rete internet pubblica da un ambiente on-premise o da altri ambienti cloud. Puoi facilitare questa esposizione limitata attraverso un gateway API o un proxy oppure un bilanciatore del carico che funga da facciata per i carichi di lavoro esistenti. Puoi eseguire il deployment della funzionalità gateway API in un segmento di rete perimetrale isolato, ad esempio una rete perimetrale.
Il pattern di rete in uscita riservato si applica principalmente ai pattern di architettura delle applicazioni a più livelli e ai pattern di architettura delle applicazioni partizionate, a titolo esemplificativo. Quando esegui il deployment di carichi di lavoro di backend all'interno di una rete interna, il networking in uscita riservato aiuta a mantenere un livello più elevato di sicurezza all'interno dell'ambiente di computing on-premise. Il pattern richiede che gli ambienti di elaborazione vengano collegati 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 computing privato direttamente da Google Cloud.
- La comunicazione dall'ambiente di computing privato a qualsiasi carico di lavoro di cui è stato eseguito il deployment in Google Cloud non è consentita.
- Il traffico verso le API private in altri ambienti viene avviato solo all'interno dell'ambiente Google Cloud.
Questa guida si concentra sugli ambienti ibridi e multi-cloud connessi su una rete ibrida privata. Se i requisiti di sicurezza della tua organizzazione lo consentono, le chiamate API alle API di destinazione remote con indirizzi IP pubblici possono essere raggiunte direttamente tramite internet. Tuttavia, devi prendere in considerazione i seguenti meccanismi di sicurezza:
- API OAuth 2.0 con Transport Layer Security (TLS).
- Limitazione di frequenza.
- Politiche di protezione dalle minacce.
- TLS reciproco configurato nel backend del livello API.
- Filtro della lista consentita di indirizzi IP configurata per consentire solo la comunicazione con origini e destinazioni API predefinite da entrambi i lati.
Per proteggere un proxy API, considera questi altri aspetti di sicurezza. Per ulteriori informazioni, consulta le best practice per la protezione di applicazioni e API con 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:
- Sul lato Google Cloud, puoi eseguire il deployment dei carichi di lavoro in VPC. I VPC possono essere singoli o multipli (condivisi o non condivisi). Il deployment deve essere in linea con i progetti e la progettazione della gerarchia delle risorse della tua organizzazione.
- Le reti VPC dell'ambiente Google Cloud sono estese agli altri ambienti di computing. Gli ambienti possono essere on-premise o in un altro cloud. Per facilitare la comunicazione tra gli ambienti utilizzando 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 i filtri nella lista consentita di indirizzi IP. Il traffico restituito da queste connessioni è consentito quando si utilizzano le 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 virtuali di rete (NVA) con funzionalità di ispezione del firewall di nuova generazione (NGFW) che si trovano nel percorso di rete.
Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS) per implementare l'ispezione approfondita dei pacchetti al fine di prevenire le minacce.
Tutti gli ambienti condividono uno spazio di indirizzi IP RFC 1918 senza sovrapposizione.
Varianti
Il pattern di architettura in uscita riservato può essere combinato con altri approcci per soddisfare diversi requisiti di progettazione che continuano a tenere in considerazione i requisiti di comunicazione di questo pattern. Il pattern offre le seguenti opzioni:
- Utilizza il gateway API di Google Cloud e il frontend globale
- Esporre i servizi remoti utilizzando Private Service Connect
Utilizza il gateway API Google Cloud e il frontend globale
Con questo approccio alla progettazione, l'esposizione e la gestione delle API risiedono all'interno di Google Cloud. Come mostrato nel diagramma precedente, puoi farlo mediante 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
Le funzionalità di frontend globali di Google Cloud come Cloud Load Balancing, Cloud CDN (se eseguito l'accesso tramite Cloud Interconnect) e Cross-Cloud Interconnect migliorano la velocità con cui gli utenti possono accedere alle applicazioni che hanno backend ospitati nei tuoi ambienti on-premise e in altri ambienti cloud.
L'ottimizzazione delle velocità di distribuzione dei contenuti si ottiene distribuendo le applicazioni dai punti di presenza (PoP) di Google Cloud. I PoP di Google Cloud 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 aiutano a fornire API ad alte prestazioni quando si utilizzano Apigee con Cloud CDN per svolgere quanto segue, guarda Delivering ad alte prestazioni API con Apigee e Cloud CDN su YouTube:
- Riduci la latenza.
- Ospita le API in tutto il mondo.
- 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.
In questa progettazione, la rete verso nord è stabilita tramite:
- Un bilanciatore del carico (LB nel diagramma), in cui le richieste del client terminano, elabora il traffico e quindi lo instrada a un backend Private Service Connect.
- Un backend Private Service Connect consente a un bilanciatore del carico di Google Cloud di inviare richieste dei client su una connessione Private Service Connect associata a un collegamento di un servizio producer al servizio pubblicato (istanza di runtime Apigee) utilizzando i gruppi di endpoint di rete (NEG) Private Service Connect.
Il networking verso sud viene stabilito attraverso:
- Un endpoint Private Service Connect che fa riferimento a un collegamento al servizio associato a un bilanciatore del carico interno (ILB nel diagramma) nel VPC del cliente.
Il deployment dell'ILB viene eseguito con gruppi di endpoint di rete con connettività ibrida (NEG di connettività ibrida).
Si accede ai servizi ibridi tramite il NEG di connettività ibrida su una connettività di rete ibrida, come VPN o Cloud Interconnect.
Per maggiori informazioni, consulta Configurare un bilanciatore del carico di rete proxy interno regionale con connettività ibrida e Pattern di deployment di Private Service Connect.
Esposizione di servizi remoti utilizzando Private Service Connect
Utilizza l'opzione Private Service Connect per esporre i servizi remoti per i seguenti scenari:
- Non stai utilizzando una piattaforma API o vuoi evitare di connettere
l'intera rete VPC direttamente a un ambiente esterno per i seguenti
motivi:
- Sono presenti limitazioni di sicurezza o requisiti di conformità.
- I tuoi intervalli di indirizzi IP si sovrappongono, ad esempio in uno scenario di fusione e acquisizione.
- Consentire comunicazioni unidirezionali sicure tra client, applicazioni e servizi tra gli ambienti, anche quando la scadenza è breve.
- Potresti dover fornire connettività a più VPC consumer tramite un VPC del producer di servizi (VPC di transito) per offrire modelli di servizio multi-tenant o single-tenant a scalabilità elevata, al fine di raggiungere i servizi pubblicati in altri ambienti.
L'uso di Private Service Connect per le applicazioni utilizzate come API fornisce un indirizzo IP interno per le applicazioni pubblicate, consentendo un accesso sicuro all'interno della rete privata tra regioni e tramite connettività ibrida. Questa astrazione facilita l'integrazione di risorse da diversi cloud e ambienti on-premise su un modello di connettività ibrida e multi-cloud. Puoi accelerare l'integrazione delle applicazioni ed esporre in modo sicuro le applicazioni che risiedono 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 collegamento a un 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 ibrido (NEG di connettività ibrida) in un VPC producer che agisce in questa progettazione come VPC di transito.
Nel diagramma precedente, i carichi di lavoro nella rete VPC della tua applicazione possono raggiungere i servizi ibridi in esecuzione nell'ambiente on-premise o in altri ambienti cloud tramite l'endpoint Private Service Connect, come illustrato nel diagramma seguente. Questa opzione di progettazione per le comunicazioni unidirezionali fornisce un'opzione alternativa al peering a un VPC di transito.
Nell'ambito della progettazione descritta nel diagramma precedente, più frontend, backend o endpoint possono connettersi allo stesso collegamento al servizio, il che consente a più reti VPC o a più consumer di accedere allo stesso servizio. Come illustrato nel diagramma seguente, puoi rendere l'applicazione accessibile a più VPC. Questa accessibilità può essere utile negli scenari di servizi multi-tenant in cui il servizio viene utilizzato da più VPC consumer anche se i loro intervalli di indirizzi IP si sovrappongono.
La sovrapposizione di indirizzi IP è uno dei problemi più comuni durante l'integrazione di applicazioni che risiedono in ambienti diversi. La connessione Private Service Connect nel diagramma seguente aiuta a evitare il problema di sovrapposizione dell'indirizzo IP. Lo fa senza richiedere il provisioning o la gestione di componenti di rete aggiuntivi, come Cloud NAT o NVA, per eseguire la traduzione degli indirizzi IP. Per un esempio di configurazione, consulta Pubblicare un servizio ibrido utilizzando Private Service Connect.
Il design offre i seguenti vantaggi:
- Evita potenziali dipendenze di scalabilità condivise e una gestibilità complessa su larga scala.
- Migliora la sicurezza fornendo un controllo della connettività granulare.
- Riduce il coordinamento degli indirizzi IP tra il producer e il consumer del servizio e l'ambiente esterno remoto.
L'approccio alla progettazione nel diagramma precedente può espandersi in fasi successive per integrare Apigee come piattaforma API utilizzando le opzioni di progettazione del networking descritte in precedenza, compresa l'opzione Private Service Connect.
Puoi rendere l'endpoint Private Service Connect accessibile da altre regioni utilizzando l'accesso globale a Private Service Connect.
Il client che si connette all'endpoint Private Service Connect può trovarsi nella stessa regione dell'endpoint o in una diversa regione. Questo approccio può essere utilizzato per fornire disponibilità elevata nei servizi ospitati in più regioni o per accedere ai servizi disponibili in una singola regione da altre regioni. Quando si accede a un endpoint Private Service Connect tramite risorse ospitate in altre regioni, vengono applicati costi in uscita tra regioni al traffico destinato agli endpoint con accesso globale.
Best practice
- Considerare Apigee e Apigee Hybrid come soluzione di piattaforma API offre numerosi vantaggi. Fornisce un livello di proxy e un'astrazione o un facade per le API dei tuoi servizio di backend in combinazione con funzionalità di sicurezza, limitazione di frequenza, quote e analisi.
- Utilizza Apigee Adapter per Envoy con un'architettura di deployment ibrido Apigee con Kubernetes ove applicabile ai tuoi requisiti e all'architettura.
- I VPC e la progettazione dei progetti in Google Cloud devono essere basati sulla gerarchia delle risorse e sui requisiti del modello di comunicazione sicuro.
- Quando vengono utilizzate API con gateway API, devi utilizzare anche una lista consentita di indirizzi IP. Una lista consentita limita le comunicazioni a origini e destinazioni di indirizzi IP specifici dei consumer delle API e dei gateway API che potrebbero essere ospitati in ambienti diversi.
- Utilizza le regole firewall VPC o i criteri firewall per controllare l'accesso alle risorse Private Service Connect tramite l'endpoint Private Service Connect.
- Se un'applicazione viene esposta esternamente tramite un bilanciatore del carico dell'applicazione, valuta l'utilizzo di Google Cloud Armor come livello di sicurezza aggiuntivo per la protezione da attacchi DDoS e minacce di sicurezza a livello delle applicazioni.
Se le istanze richiedono l'accesso a internet, utilizza Cloud NAT nel VPC dell'applicazione (consumer) 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, puoi utilizzare Google Cloud Secure Web Proxy. Il proxy offre diversi vantaggi.
Consulta le best practice generali per i pattern di networking ibridi e multi-cloud.