L'architettura del pattern di rete in uscita riservato si basa sull'esposizione selezionare le API dall'ambiente on-premise o da un altro ambiente cloud con 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 un gateway API o un proxy oppure un bilanciatore del carico che funge da facciata 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 di carichi di lavoro di backend all'interno di una rete interna, traffico in uscita riservato il networking aiuta a mantenere un livello di sicurezza più elevato all'interno dei sistemi on-premise nell'ambiente di computing. 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.
- Altri sistemi nell'ambiente di computing privato non sono raggiungibili direttamente da Google Cloud.
- La comunicazione dall'ambiente di calcolo privato a qualsiasi carico di lavoro impiegato in Google Cloud non è consentita.
- Il traffico verso le API private in altri ambienti viene avviato solo dall'ambiente Google Cloud.
Questa guida si concentra sugli ambienti ibridi e multi-cloud collegati tramite una rete ibrida privata. Se i requisiti di sicurezza della tua organizzazione le chiamate API alle API di destinazione remote con indirizzi IP pubblici possono raggiungibili direttamente tramite internet. Tuttavia, è necessario considerare le seguenti misure di sicurezza di Compute Engine:
- 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 aspetti altri aspetti della sicurezza. Per ulteriori informazioni, vedi Best practice per la protezione di applicazioni e API con Apigee.
Architettura
Il seguente diagramma mostra un'architettura di riferimento che supporta 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 o VPC (Virtual Private Cloud). 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'ambiente Google Cloud vengono estese agli altri ambienti di calcolo. Gli ambienti possono essere on-premise 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 quando utilizzi regole firewall stateful. Puoi utilizzare qualsiasi combinazione delle seguenti funzionalità per proteggere e limita 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 il 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 dell'architettura di traffico in uscita riservato può essere combinato con altri approcci a soddisfare diversi requisiti di progettazione che continuano a tenere conto della comunicazione i requisiti 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 di progettazione, l'esposizione e la gestione delle API risiedono in Google 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
Le funzionalità di frontend globali di Google Cloud, 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 della velocità di distribuzione dei contenuti si ottiene implementando queste applicazioni dai punti di presenza (da un periodo all'altro) di Google Cloud. I POP di Google Cloud presenta su oltre 180 centri di scambio internet e 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.
- 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.
La rete northbound in questo progetto viene stabilita tramite:
- Un bilanciatore del carico (LB nel diagramma), in cui le richieste del client terminano, elabora il traffico e quindi la instrada al backend Private Service Connect.
- R 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 producer collegamento al servizio pubblicato (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) nel VPC del cliente.
Il deployment dell'ILB viene eseguito con una rete di connettività ibrida gruppi di endpoint (NEG di 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 Modelli di implementazione di Private Service Connect.
Esporre servizi remoti tramite Private Service Connect
Utilizzare l'opzione Private Service Connect per esporre i servizi remoti per i seguenti scenari:
- Non utilizzi una piattaforma API o vuoi evitare di collegare l'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 consentire comunicazioni unidirezionali sicure tra i client, applicazioni e servizi in tutti gli ambienti, anche quando disponi una scadenza breve.
- Potresti dover fornire connettività a più VPC consumer tramite una un VPC del producer di servizi (VPC di transito) per offrire una scalabilità multi-tenant o modelli di servizio single-tenant, per 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 nelle varie regioni e tramite la connettività ibrida. Questa astrazione Semplifica l'integrazione di risorse da diversi cloud e on-premise ambienti su 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 collegamento a un servizio che fa riferimento a un
Bilanciatore del carico di rete proxy interno regionale
o 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 in questo progetto funge da VPC di transito.
Nel diagramma precedente, i carichi di lavoro nella rete VPC dell'applicazione può raggiungere i servizi ibridi in esecuzione nel tuo ambiente on-premise in altri ambienti cloud, tramite Private Service Connect come illustrato nel diagramma seguente. 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 più utenti di accedere allo stesso servizio. Come illustrato nel diagramma seguente, puoi rendere l'applicazione accessibile a più VPC. Questa funzionalità di accessibilità può essere utile servizi multi-tenant scenari in cui il servizio viene utilizzato da più VPC consumer anche se Gli 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 offre i seguenti vantaggi:
- Evita potenziali dipendenze di scalabilità condivise e una gestibilità complessa e su larga scala.
- Migliora la sicurezza fornendo un controllo granulare della connettività.
- Riduce il coordinamento degli indirizzi IP tra il producer e il consumer dell' 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 descritte in precedenza, tra cui 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ò trovarsi nella stessa regione dell'endpoint o in un'altra regione. Questo approccio possono essere utilizzati per fornire disponibilità elevata tra i servizi ospitati in più regioni o di accedere a servizi disponibili in una singola regione da altre regioni. Quando un endpoint Private Service Connect viene acceduto da risorse ospitate in altre regioni, ai costi per il traffico in uscita interregionale si applicano i costi in uscita interregionali per il traffico destinato agli endpoint con accesso globale.
Best 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 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 essere basata 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 a un indirizzo IP specifico origini e destinazioni dei consumer API e dei gateway API che potrebbero essere ospitati in diversi ambienti.
- 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 attraverso il suo carico utilizza un bilanciatore del carico, valuta di utilizzare Google Cloud Armor come ulteriore livello di sicurezza per proteggersi dagli attacchi DDoS e a livello delle applicazioni. minacce alla sicurezza.
Se le istanze richiedono l'accesso a internet, usa Cloud NAT nel VPC dell'applicazione (consumer) per consentire ai carichi di lavoro di accedere internet. In questo modo eviterai di assegnare istanze VM con server indirizzi IP pubblici in sistemi il cui deployment viene eseguito dietro un gateway API o con il bilanciatore del carico di rete passthrough esterno regionale.
- Per il traffico web in uscita, puoi utilizzare Secure Web Proxy di Google Cloud. Il proxy offre diversi vantaggi.
Esamina il best practice generali per pattern di networking ibridi e multi-cloud.