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 verso i backend che risiedono all'interno del VPC di Google Cloud reti. 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 (
GCE_VM_IP_PORTendpoint)
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. Altri utilizzano l'open source di Envoy proxy. 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 offre un riepilogo.
| Bilanciatore del carico proxy | Proxy (dal 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 per i backend. |
|
| Bilanciatore del carico delle applicazioni classico | GFE | HTTP, HTTPS e HTTP/2 Scegli HTTPS o HTTP/2 se hai bisogno di una crittografia controllabile in transito verso dai 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 di rete proxy esterno | GFE | SSL o TCP Scegli SSL per il protocollo del servizio di backend se è necessario il controllo la crittografia in transito verso i backend. |
|
| Bilanciatore del carico delle applicazioni interno | Proxy Envoy | HTTP, HTTPS e HTTP/2 Scegli HTTPS o HTTP/2 se hai bisogno di una crittografia controllabile in transito verso dai backend. |
|
| Bilanciatore del carico di rete proxy interno regionale | 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 NEG internet backend, bilanciatori del carico non utilizzare l'estensione Server Name Indication (SNI) per le connessioni di un backend cloud.
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
CNesubjectAlternativeNamenon corrispondono a un'intestazioneHosto 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 libreria BoringCrypto. 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 conformità a FIPS .
Cloud Service Mesh supporta i proxy Envoy integrati conformi a FIPS .