Encriptación del balanceador de cargas a los backends

Encriptación en todas las regiones de Google Cloud

Se encriptará todo el tráfico de VM a VM dentro de una red de VPC y redes de VPC con intercambio de tráfico. Esto incluye el tráfico de VM a VM dentro de los límites físicos (es decir, el tráfico dentro del clúster).

Encriptación entre backends y balanceadores de cargas basados en proxy

Para algunos balanceadores de cargas de proxy (consulta la tabla 1), Google encripta de forma automática el tráfico a los backends que residen en las redes de VPC de Google Cloud. Esto se llama encriptación automática a nivel de la red. La encriptación automática a nivel de red solo se aplica a las comunicaciones con estos tipos de backends:

  • Grupos de instancias
  • NEG zonales (extremos GCE_VM_IP_PORT)

Además, Google Cloud proporciona opciones de protocolo seguro para encriptar la comunicación con el servicio de backend.

Algunos balanceadores de cargas de Google Cloud usan Google Front End (GFE) como el cliente para los backends. Otros usan el proxy de Envoy de código abierto. En todos los casos, el balanceador de cargas admite los conjuntos de algoritmos de cifrado que se enumeran en RFC 8446, sección 9.1 para TLS 1.3. En TLS 1.2 y versiones anteriores, el balanceador de cargas admite los conjuntos de algoritmos de cifrado asociados con el perfil de política de SSL COMPATIBLE.

En la siguiente tabla, se proporciona un resumen.

Tabla 1. Comunicaciones entre los balanceadores de cargas y los backends
Balanceador de cargas de proxy Proxy (del cliente hacia el backend) Encriptación automática a nivel de la red Opciones de protocolo del servicio de backend
Balanceador de cargas de aplicaciones externo global GFE (con software de Envoy para las funciones de enrutamiento avanzadas) HTTP, HTTPS y HTTP/2
Elige HTTPS o HTTP/2 si necesitas encriptación en tránsito hacia los backends.
Balanceador de cargas de aplicaciones clásico GFE HTTP, HTTPS y HTTP/2
Elige HTTPS o HTTP/2 si necesitas encriptación en tránsito hacia los backends.
Balanceador de cargas de aplicaciones externo regional Proxy de Envoy HTTP, HTTPS y HTTP/2
Elige HTTPS o HTTP/2 si necesitas encriptación en tránsito hacia los backends.
Balanceador de cargas de red del proxy externo GFE SSL o TCP
Elige SSL para el protocolo del servicio de backend si necesitas encriptación en tránsito hacia los backends.
Balanceador de cargas de aplicaciones interno Proxy de Envoy HTTP, HTTPS y HTTP/2
Elige HTTPS o HTTP/2 si necesitas encriptación en tránsito hacia los backends.
Balanceador de cargas de red del proxy interno regional Proxy de Envoy TCP
Traffic Director Proxy del cliente HTTPS y HTTP/2

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.

  • A excepción de los balanceadores de cargas HTTPS con backends de NEG de Internet, los GFE no usan la extensión de indicación del nombre del servidor (SNI) para las conexiones al backend.

  • 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.

Los balanceadores de cargas de aplicaciones externos y los balanceadores de cargas de red del proxy externos 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.

Los balanceadores de cargas de aplicaciones internos usan 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 los balanceadores de cargas de aplicaciones internos 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.