Chiffrement entre l'équilibreur de charge et les backends

Chiffrement automatique entre les serveurs GFE et les backends

Pour les types d'équilibreurs de charge suivants, Google chiffre automatiquement le trafic entre les serveurs Google Front End (GFE) et vos backends hébergés dans les réseaux VPC Google Cloud :

  • Équilibrage de charge HTTP(S)
  • Équilibrage de charge proxy TCP
  • Équilibrage de charge proxy SSL

Options de protocole de backend sécurisé

Lorsque vous créez un service de backend, vous sélectionnez un protocole de service de backend. Les protocoles de service de backend suivants fournissent une connectivité sécurisée aux backends :

  • Pour l'équilibrage de charge HTTP(S) : HTTPS et HTTP/2
  • Pour l'équilibrage de charge HTTP(S) interne : HTTPS et HTTP/2
  • Pour l'équilibrage de charge proxy SSL : SSL
  • Pour Traffic Director : HTTPS et HTTP/2

Lorsque l'équilibrage de charge HTTP(S) ou l'équilibrage de charge proxy SSL se connecte à un backend à l'aide d'un protocole sécurisé, le serveur GFE est le client HTTPS ou SSL. Lorsque l'équilibrage de charge HTTP(S) interne se connecte à un backend à l'aide d'un protocole sécurisé, le proxy Envoy est le client HTTPS.

Lorsqu'un proxy côté client configuré avec Traffic Director se connecte à un backend à l'aide d'un protocole de service de backend sécurisé, le proxy côté client est le client SSL ou HTTPS.

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 Traffic Director) 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.

  • Lorsqu'un serveur GFE démarre une session TLS sur les backends, il n'utilise pas l'extension SNI (Server Name Indication).

  • Lorsqu'un serveur GFE se connecte à des backends au sein de Google Cloud, il accepte tous les certificats présentés par vos backends. Les serveurs GFE n'effectuent pas de validation des certificats. 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 et subjectAlternativeName ne correspondent pas à un en-tête Host 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é.

L'équilibrage de charge HTTP(S) et l'équilibrage de charge proxy SSL 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.

L'équilibrage de charge HTTP(S) interne utilise 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 l'équilibrage de charge HTTP(S) interne en mode conforme à la norme FIPS.

Traffic Director est compatible avec les proxys Envoy intégrés en mode conforme à la norme FIPS.