Encriptación del balanceador de cargas a los backends

Encriptación automática entre GFE y backends

Google encripta automáticamente el tráfico entre Google Front Ends (GFE) y los backends que residen en las redes de VPC de Google Cloud para los siguientes tipos de balanceadores de cargas:

  • Balanceo de cargas HTTP(S)
  • Balanceo de cargas del proxy de TCP
  • Balanceo de cargas del proxy de SSL

Opciones de protocolos de backend seguros

Cuando creas un servicio de backend, debes seleccionar un protocolo para ese tipo de servicio. Los siguientes protocolos de servicio de backend proporcionan conectividad segura a los backends:

  • Para el balanceo de cargas HTTP(S): HTTPS y HTTP/2
  • Para el balanceo de cargas HTTP(S) interno: HTTPS y HTTP/2
  • Para el balanceo de cargas de proxy SSL: SSL
  • Para Traffic Director: HTTPS y HTTP/2

Cuando el balanceo de cargas HTTP(S) o el balanceo de cargas de proxy SSL se conecta a un backend mediante un protocolo seguro, el GFE es el cliente SSL o HTTPS. Cuando el balanceo de cargas HTTP(S) interno se conecta a un backend con un protocolo seguro, el proxy de Envoy es el cliente HTTPS.

Cuando un proxy del cliente configurado con Traffic Director se conecta a un backend mediante un protocolo de servicio de backend seguro, el proxy del cliente es el cliente SSL o HTTPS.

Casos de uso de protocolos de backend seguros

Se recomienda un protocolo seguro que permita conectarse a instancias de backend en los siguientes casos:

  • Cuando necesites una conexión encriptada y que se pueda auditar desde el balanceador de cargas (o Traffic Director) hacia las instancias de backend

  • Cuando el balanceador de cargas se conecte a una instancia de backend que esté fuera de Google Cloud (con un NEG de Internet). La comunicación con un backend de NEG de Internet puede transitar la Internet pública. Cuando el balanceador de cargas se conecta a un NEG de Internet, el certificado firmado por Public CA debe cumplir con los requisitos de validación

Consideraciones sobre los protocolos de backend seguros

Si usas un protocolo de servicio de backend seguro, ten en cuenta lo siguiente:

  • Las instancias de backend o los extremos del balanceador de cargas deben realizar la entrega mediante el mismo protocolo que el servicio de backend. Por ejemplo, si el protocolo del servicio de backend es HTTPS, los backends deben ser servidores HTTPS.

  • Si el protocolo del servicio de backend es HTTP/2, los backends deben usar TLS. Si necesitas instrucciones para realizar la configuración, consulta la documentación del software que se ejecuta en las instancias de backend o en los extremos.

  • Debes instalar claves privadas y certificados en las instancias de backend o en los extremos a fin de que funcionen como servidores HTTPS o SSL. No es necesario que estos certificados coincidan con los certificados SSL de frontend del balanceador de cargas. Si necesitas instrucciones para realizar la instalación, consulta la documentación del software que se ejecuta en las instancias de backend o en los extremos.

  • Cuando un GFE inicia una sesión de TLS para backends, el GFE no usa la extensión de indicación del nombre del servidor (SNI).

  • Cuando un GFE se conecta a backends que están dentro de Google Cloud, el GFE acepta cualquier certificado que presenten los backends. Los GFE no realizan la validación del certificado. Por ejemplo, el certificado se considera válido incluso en las siguientes circunstancias:

    • El certificado está autofirmado.
    • El certificado está firmado por una autoridad certificada (CA) desconocida.
    • El certificado caducó o aún no es válido.
    • Los atributos CN y subjectAlternativeName no coinciden con un encabezado Host ni con un registro PTR de DNS.

Protocolos de frontend seguros

Cuando usas un HTTPS de destino o un proxy SSL de destino como parte de la configuración, Google Cloud utiliza un protocolo de frontend seguro.

El balanceo de cargas HTTP(S) y el balanceo de cargas de proxy SSL usan la biblioteca BoringCrypto de Google. Para obtener más detalles sobre FIPS 140‑2, consulta el certificado 3,678 del Programa de validación de módulos criptográficos del NIST.

El balanceo de cargas HTTP(S) interno usa la biblioteca BoringSSL de Google. Para obtener más detalles sobre FIPS 140‑2, consulta la documentación de Envoy. Google crea proxies de Envoy para el balanceo de cargas HTTP(S) interno en el modo de cumplimiento del estándar FIPS.

Traffic Director es compatible con los proxies de Envoy que se crean en el modo de cumplimiento del estándar FIPS.