Chiffrement dans toutes les régions Google Cloud
Tout le trafic de VM à VM au sein d'un réseau VPC et de réseaux VPC appairés est chiffré. Cela inclut le trafic entre plusieurs VM au sein des limites physiques (c'est-à-dire le trafic intra-cluster).
Chiffrement entre les équilibreurs de charge basés sur un proxy et les backends
Pour certains équilibreurs de charge proxy (voir le tableau 1), Google chiffre automatiquement le trafic vers les backends résidant dans les réseaux VPC Google Cloud. Cela s'appelle le chiffrement automatique au niveau du réseau. Le chiffrement automatique au niveau du réseau ne s'applique qu'aux communications avec les types de backends suivants :
- Groupes d'instances
- NEG zonaux (points de terminaison
GCE_VM_IP_PORT
)
En outre, Google Cloud fournit des options de protocole sécurisé pour chiffrer la communication avec le service de backend.
Certains équilibreurs de charge Google Cloud utilisent Google Front End (GFE) en tant que client pour les backends, tandis que d'autres utilisent le proxy Envoy Open Source. Dans tous les cas, l'équilibreur de charge est compatible avec les suites de chiffrement répertoriées dans la RFC 8446, section 9.1 pour TLS 1.3. Pour TLS 1.2 et versions antérieures, l'équilibreur de charge est compatible avec les suites de chiffrement associées au profil de règles SSL COMPATIBLE.
Le tableau suivant récapitule les équilibreurs de charge proxy qui chiffrent le trafic vers les backends.
Équilibreur de charge proxy | Proxy (du client au backend) | Chiffrement automatique au niveau du réseau | Options de protocole du service de backend |
---|---|---|---|
équilibreur de charge d'application externe global | GFE (avec un logiciel Envoy pour les fonctionnalités de routage avancées) | HTTP, HTTPS et HTTP/2 Choisissez HTTPS ou HTTP/2 si vous avez besoin d'un chiffrement vérifiable en transit vers les backends. |
|
équilibreur de charge d'application classique | GFE | HTTP, HTTPS et HTTP/2 Choisissez HTTPS ou HTTP/2 si vous avez besoin d'un chiffrement vérifiable en transit vers les backends. |
|
équilibreur de charge d'application externe régional | Proxy Envoy | HTTP, HTTPS et HTTP/2 Choisissez HTTPS ou HTTP/2 si vous avez besoin d'un chiffrement vérifiable en transit vers les backends. |
|
Équilibreur de charge d'application interne régional | Proxy Envoy | HTTP, HTTPS et HTTP/2 Choisissez HTTPS ou HTTP/2 si vous avez besoin d'un chiffrement vérifiable en transit vers les backends. |
|
Équilibreur de charge d'application interne interrégional | Proxy Envoy | HTTP, HTTPS et HTTP/2 Choisissez HTTPS ou HTTP/2 si vous avez besoin d'un chiffrement vérifiable en transit vers les backends. |
|
Équilibreur de charge réseau proxy externe global | GFE (avec un logiciel Envoy pour les fonctionnalités de routage avancées) | SSL ou TCP Choisissez SSL pour le protocole de service de backend si vous avez besoin d'un chiffrement vérifiable en transit vers les backends. |
|
Équilibreur de charge réseau proxy classique | GFE | SSL ou TCP Choisissez SSL pour le protocole de service de backend si vous avez besoin d'un chiffrement vérifiable en transit vers les backends. |
|
Équilibreur de charge réseau proxy externe régional | Proxy Envoy | TCP | |
Équilibreur de charge réseau proxy interne régional | Proxy Envoy | TCP | |
Équilibreur de charge réseau proxy interne interrégional | Proxy Envoy | TCP | |
Cloud Service Mesh | Proxy côté client | HTTPS et HTTP/2 |
Cas d'utilisation du protocole de backend sécurisé
Un protocole sécurisé permettant de se connecter aux instances backend est recommandé dans les cas suivants :
Lorsque vous avez besoin d'une connexion chiffrée vérifiable entre l'équilibreur de charge (ou Cloud Service Mesh) et les instances backend.
Lorsque l'équilibreur de charge se connecte à une instance backend externe à Google Cloud (via un NEG Internet). La communication avec un backend NEG Internet peut transiter sur l'Internet public. Lorsque l'équilibreur de charge se connecte à un NEG Internet, le certificat signé par une autorité de certification publique doit respecter les exigences de validation.
Points à noter concernant le protocole de backend sécurisé
Lorsque vous utilisez un protocole de service de backend sécurisé, gardez les points suivants à l'esprit :
Les instances backend ou les points de terminaison de votre équilibreur de charge doivent utiliser le même protocole que le service de backend. Par exemple, si le protocole de service de backend est HTTPS, les backends doivent être des serveurs HTTPS.
Si le protocole du service de backend est HTTP/2, vos backends doivent utiliser TLS. Pour obtenir des instructions de configuration, consultez la documentation du logiciel exécuté sur vos instances backend ou points de terminaison.
Vous devez installer des clés et des certificats privés sur vos instances backend ou points de terminaison afin qu'ils fonctionnent comme des serveurs HTTPS ou SSL. Ces certificats n'ont pas besoin de correspondre aux certificats SSL de l'interface de l'équilibreur de charge. Pour obtenir des instructions d'installation, consultez la documentation du logiciel exécuté sur vos instances backend ou points de terminaison.
À l'exception des équilibreurs de charge HTTPS avec des backends de NEG Internet, les équilibreurs de charge n'utilisent pas l'extension SNI (Server Name Indication) pour les connexions au backend.
Lorsqu'un équilibreur de charge se connecte à des backends situés dans Google Cloud, il accepte tous les certificats présentés par vos backends. Dans ce cas, l'équilibreur de charge n'effectue aucune validation de certificat. Par exemple, le certificat est considéré comme valide même dans les cas suivants :
- Le certificat est autosigné.
- Le certificat est signé par une autorité de certification inconnue.
- Le certificat a expiré ou n'est pas encore valide.
- Les attributs
CN
etsubjectAlternativeName
ne correspondent pas à un en-têteHost
ni à un enregistrement PTR DNS.
Protocoles d'interface sécurisés
Lorsque vous utilisez un proxy HTTPS ou SSL cible dans votre configuration, Google Cloud utilise un protocole d'interface sécurisé.
Les équilibreurs de charge d'application externes et les équilibreurs de charge réseau proxy externes utilisent la bibliothèque BoringCrypto de Google. Pour en savoir plus sur la certification FIPS 140-2, consultez la page NIST Cryptographic Module Validation Program Certificate #3678.
Les équilibreurs de charge d'application internes utilisent la bibliothèque BoringSSL de Google. Pour en savoir plus sur la certification FIPS 140-2, consultez la documentation Envoy. Google crée des proxys Envoy pour les équilibreurs de charge d'application internes en mode conforme à la norme FIPS.
Cloud Service Mesh est compatible avec les proxys Envoy intégrés en mode conforme à la norme FIPS.