Crittografia dal bilanciatore del carico ai backend

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Crittografia in tutte le aree geografiche di Google Cloud

Tutto il traffico da VM a VM all'interno di una rete VPC e di reti VPC in peering viene criptato. Questo include il traffico da VM a VM all'interno dei confini fisici (ovvero il traffico intra-cluster).

Crittografia tra bilanciatori del carico e backend proxy

Per alcuni bilanciatori del carico del proxy (vedi la tabella 1), Google cripta automaticamente il traffico ai backend che si trovano all'interno delle reti VPC di Google Cloud. Questa operazione è chiamata crittografia automatica a livello di rete. Inoltre, Google Cloud fornisce opzioni di protocollo sicuro per criptare le comunicazioni con il servizio di backend.

Alcuni bilanciatori del carico Google Cloud utilizzano i Google Front End (GFE) come client per i backend. Altri utilizzano il proxy Envoy open source. In tutti i casi, il bilanciatore del carico supporta le suite di crittografia elencate in RFC 8446, sezione 9.1.

La tabella seguente offre un riepilogo.

Tabella 1. Comunicazioni tra bilanciatori del carico e backend
Bilanciatore del carico del proxy Client al backend Crittografia automatica a livello di rete Opzioni di protocolli sicuri del servizio di backend
Bilanciatore del carico HTTP(S) esterno globale GFE (con software Envoy per le funzionalità di routing avanzate) HTTPS e HTTP/2
Bilanciatore del carico HTTP(S) esterno globale (versione classica) GFE HTTPS e HTTP/2
Bilanciatore del carico HTTP(S) esterno a livello di area geografica Proxy Envoy HTTPS e HTTP/2
Bilanciatore del carico del proxy TCP GFE N/D. Se vuoi utilizzare un protocollo sicuro, utilizza il bilanciatore del carico del proxy SSL.
Bilanciatore del carico del proxy SSL GFE SSL
Bilanciatore del carico HTTP(S) interno Proxy Envoy HTTPS e HTTP/2
Traffic Director Proxy lato client HTTPS e HTTP/2

Casi d'uso del protocollo di backend sicuro

Nei seguenti casi è consigliato un protocollo sicuro per la connessione alle istanze di backend:

  • Quando richiedi una connessione criptata verificabile dal bilanciatore del carico (o Traffic Director) alle istanze di backend.

  • Quando il bilanciatore del carico si connette a un'istanza di backend esterna a Google Cloud (con un NEG Internet). La comunicazione con il backend di un NEG Internet potrebbe consentire il transito nella rete Internet pubblica. Quando il bilanciatore del carico si connette a un NEG Internet, il certificato firmato da una Public CA deve soddisfare i requisiti di convalida.

Considerazioni sul protocollo di backend sicuro

Quando utilizzi un protocollo del servizio di backend sicuro, tieni presente quanto segue:

  • Gli endpoint o le istanze di backend del bilanciatore del carico devono utilizzare lo stesso protocollo del servizio di backend. Ad esempio, se il protocollo del servizio di backend è HTTPS, i backend devono essere server HTTPS.

  • Se il protocollo del servizio di backend è HTTP/2, i backend devono utilizzare TLS. Per le istruzioni di configurazione, consulta la documentazione del software in esecuzione sugli endpoint o sulle istanze di backend.

  • Devi installare chiavi e certificati privati negli endpoint o nelle istanze di backend affinché funzionino come server HTTPS o SSL. Questi certificati non devono necessariamente corrispondere ai certificati SSL di frontend del bilanciatore del carico. Per le istruzioni di installazione, consulta la documentazione del software in esecuzione sugli endpoint o sulle istanze di backend.

  • Ad eccezione dei bilanciatori del carico HTTPS con i backend di NEG Internet, i GFE non utilizzano l'estensione SNI (Server Name Indication) per le connessioni al backend.

  • Quando un GFE si connette ai backend all'interno di Google Cloud, il GFE accetta qualsiasi certificato presentato dai backend. I GFE non eseguono la convalida dei certificati. Ad esempio, il certificato viene considerato valido anche nelle seguenti circostanze:

    • Il certificato è autofirmato.
    • Il certificato è firmato da un'autorità di certificazione (CA) sconosciuta.
    • Il certificato è scaduto o non è ancora valido.
    • Gli attributi CN e subjectAlternativeName non corrispondono a un'intestazione Host o a un record PTR DNS.

Protocolli di frontend sicuri

Quando utilizzi un proxy HTTPS di destinazione o SSL di destinazione come parte della configurazione, Google Cloud utilizza un protocollo di frontend sicuro.

Il bilanciamento del carico HTTP(S) e il bilanciamento del carico del proxy SSL utilizzano la libreria BoringCrypto di Google. Per i dettagli relativi allo standard FIPS 140-2, consulta il certificato 3678 del programma CMVP (Cryptographic Module Validation Program) del NIST.

Il bilanciamento del carico HTTP(S) interno utilizza la libreria BoringSSL di Google. Per i dettagli relativi allo standard FIPS 140-2, consulta la documentazione di Envoy. Google crea proxy Envoy per il bilanciamento del carico HTTP(S) interno in modalità conforme allo standard FIPS.

Traffic Director supporta i proxy Envoy creati in modalità conforme allo standard FIPS.