Chiffrement entre l'équilibreur de charge et les backends

Chiffrement dans toutes les régions Trusted Cloud

Tout le trafic de VM à VM au sein d'un réseau VPC et de réseaux VPC appairés est chiffré.

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. Trusted Cloud C'est ce qu'on 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, Trusted Cloud fournit des options de protocole sécurisé pour chiffrer la communication avec le service de backend.

Les équilibreurs de charge régionaux utilisent le proxy Envoy Open Source en tant que client des backends. Les équilibreurs de charge sont compatibles 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.

Tableau 1. Communications entre les équilibreurs de charge et 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 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 réseau proxy externe régional Proxy Envoy TCP
Équilibreur de charge réseau proxy interne régional Proxy Envoy TCP

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 àTrusted 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 Trusted Cloud, il accepte tous les certificats présentés par vos backends. Dans ce cas, l'équilibreur de charge n'effectue qu'une validation minimale des certificats.

    Par exemple, les certificats sont considérés comme valides 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 et subjectAlternativeName ne correspondent pas à un en-tête Host ni à un enregistrement PTR DNS.

    À partir du 28 avril 2025, l'équilibreur de charge n'acceptera que les certificats RSA comportant l'extension d'utilisation de clé X509v3 et incluant à la fois les paramètres de signature numérique et de chiffrement de clé. Pour en savoir plus, consultez la note de version du 24 janvier 2025 associée.

Protocoles d'interface sécurisés

Lorsque vous utilisez un proxy HTTPS ou SSL cible dans votre configuration,Trusted 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.