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 proxy e backend
Per alcuni bilanciatori del carico proxy (vedi 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. La crittografia automatica a livello di rete è applicabile solo alle comunicazioni con questi tipi di backend:
- Gruppi di istanze
- NEG a livello di zona (endpoint
GCE_VM_IP_PORT
)
Inoltre, Google Cloud fornisce opzioni di protocolli sicuri per la crittografia della comunicazione con il servizio di backend.
Alcuni bilanciatori del carico Google Cloud utilizzano Google Front End (GFE) come client per i backend, mentre 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 per TLS 1.3. Per TLS 1.2 e versioni precedenti, il bilanciatore del carico supporta le suite di crittografia associate al profilo del criterio SSL COMPATIBILE.
La tabella seguente fornisce un riepilogo dei bilanciatori del carico proxy che criptano il traffico verso i backend.
Bilanciatore del carico proxy | Proxy (client al backend) | Crittografia automatica a livello di rete | Opzioni del protocollo del servizio di backend |
---|---|---|---|
Bilanciatore del carico delle applicazioni esterno globale | GFE (con software Envoy per le funzionalità di routing avanzate) | HTTP, HTTPS e HTTP/2 Scegli HTTPS o HTTP/2 se hai bisogno di crittografia verificabile in transito ai backend. |
|
Bilanciatore del carico delle applicazioni classico | GFE | HTTP, HTTPS e HTTP/2 Scegli HTTPS o HTTP/2 se hai bisogno di crittografia verificabile in transito per i backend. |
|
Bilanciatore del carico delle applicazioni esterno regionale | Proxy Envoy | HTTP, HTTPS e HTTP/2 Scegli HTTPS o HTTP/2 se hai bisogno di crittografia verificabile in transito ai backend. |
|
Bilanciatore del carico delle applicazioni interno regionale | Proxy Envoy | HTTP, HTTPS e HTTP/2 Scegli HTTPS o HTTP/2 se hai bisogno di crittografia verificabile in transito ai backend. |
|
Bilanciatore del carico delle applicazioni interno tra regioni | Proxy Envoy | HTTP, HTTPS e HTTP/2 Scegli HTTPS o HTTP/2 se hai bisogno di crittografia verificabile in transito ai backend. |
|
Bilanciatore del carico di rete proxy esterno globale | GFE (con software Envoy per le funzionalità di routing avanzate) | SSL o TCP Scegli SSL per il protocollo del servizio di backend se hai bisogno di crittografia verificabile in transito ai backend. |
|
Bilanciatore del carico di rete proxy classico | GFE | SSL o TCP Scegli SSL per il protocollo del servizio di backend se hai bisogno di crittografia verificabile in transito ai backend. |
|
Bilanciatore del carico di rete proxy esterno regionale | Proxy Envoy | TCP | |
Bilanciatore del carico di rete proxy interno regionale | Proxy Envoy | TCP | |
Bilanciatore del carico di rete proxy interno tra regioni | Proxy Envoy | TCP | |
Cloud Service Mesh | 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 Cloud Service Mesh) 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 backend NEG internet, i bilanciatori del carico non utilizzano l'estensione SNI (Server Name Indication) per le connessioni al backend.
Quando un bilanciatore del carico si connette ai backend all'interno di Google Cloud, il bilanciatore del carico accetta qualsiasi certificato presentato dai backend. In questo caso, il bilanciatore del carico non esegue 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
esubjectAlternativeName
non corrispondono a un'intestazioneHost
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.
I bilanciatori del carico delle applicazioni esterni e i bilanciatori del carico di rete proxy esterni 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.
I bilanciatori del carico delle applicazioni interni utilizzano la libreria BoringSSL di Google. Per i dettagli relativi allo standard FIPS 140-2, consulta la documentazione di Envoy. Google crea proxy Envoy per i bilanciatori del carico delle applicazioni interni in modalità conforme allo standard FIPS.
Cloud Service Mesh supporta i proxy Envoy creati in modalità conforme allo standard FIPS.