Encriptado en todas las regiones de Google Cloud
Todo el tráfico entre máquinas virtuales de una red de VPC y de las redes de VPC emparejadas se encripta.
Encriptado entre los balanceadores de carga de proxy y los backends
En el caso de algunos balanceadores de carga de proxy (consulta la tabla 1), Google encripta automáticamente el tráfico de los backends que residen en redes de Google Cloud VPC. Esto se denomina encriptado automático a nivel de red. El cifrado automático a nivel de red solo se aplica a las comunicaciones con los siguientes tipos de backend:
- Grupos de instancias
- NEGs por zonas (puntos finales
GCE_VM_IP_PORT)
Además, Google Cloud ofrece opciones de protocolo seguro para cifrar la comunicación con el servicio de backend.
Algunos Google Cloud balanceadores de carga usan Google Front Ends (GFEs) como cliente para llegar a los backends, mientras que otros usan el proxy Envoy de código abierto. En todos los casos, el balanceador de carga admite los conjuntos de cifrado que se indican en la sección 9.1 del RFC 8446 para TLS 1.3. En el caso de TLS 1.2 y versiones anteriores, el balanceador de carga admite los conjuntos de cifrado asociados al perfil de política de SSL COMPATIBLE.
En la siguiente tabla se muestra un resumen de los balanceadores de carga proxy que cifran el tráfico a los back-ends.
| Balanceador de carga de proxy | Proxy (del cliente al backend) | Encriptado automático a nivel de red | Opciones de protocolo de servicios de backend |
|---|---|---|---|
| Balanceador de carga de aplicación externo global | GFE (con software de Envoy para funciones de enrutamiento avanzadas) | HTTP, HTTPS y HTTP/2 Elige HTTPS o HTTP/2 si necesitas que el cifrado en tránsito a los backends se pueda auditar. |
|
| Balanceador de carga de aplicación clásico | GFE | HTTP, HTTPS y HTTP/2 Elige HTTPS o HTTP/2 si necesitas que el cifrado en tránsito a los backends se pueda auditar. |
|
| Balanceador de carga de aplicación externo regional | Proxy Envoy | HTTP, HTTPS y HTTP/2 Elige HTTPS o HTTP/2 si necesitas que el cifrado en tránsito a los backends se pueda auditar. |
|
| Balanceador de carga de aplicación interno regional | Proxy Envoy | HTTP, HTTPS y HTTP/2 Elige HTTPS o HTTP/2 si necesitas que el cifrado en tránsito a los backends se pueda auditar. |
|
| Balanceador de carga de aplicación interno entre regiones | Proxy Envoy | HTTP, HTTPS y HTTP/2 Elige HTTPS o HTTP/2 si necesitas que el cifrado en tránsito a los backends se pueda auditar. |
|
| Balanceador de carga de red con proxy externo global | GFE (con software de Envoy para funciones de enrutamiento avanzadas) | SSL o TCP Elige SSL para el protocolo de servicio de backend si necesitas que el cifrado en tránsito a los backends se pueda auditar. |
|
| Balanceador de carga de red de proxy clásico | GFE | SSL o TCP Elige SSL para el protocolo de servicio de backend si necesitas que el cifrado en tránsito a los backends se pueda auditar. |
|
| Balanceador de carga de red con proxy externo regional | Proxy Envoy | TCP | |
| Balanceador de carga de red con proxy interno regional | Proxy Envoy | TCP | |
| Balanceador de carga de red con proxy interno interregional | Proxy Envoy | TCP | |
| Cloud Service Mesh | Proxy de cliente | HTTPS y HTTP/2 |
Usos prácticos de protocolos de backend seguros
Te recomendamos que utilices un protocolo seguro para conectarte a instancias de backend en los siguientes casos:
Cuando necesites una conexión auditable y encriptada del balanceador de carga (o de Cloud Service Mesh) a las instancias de backend.
Cuando el balanceador de carga se conecte a una instancia de backend que se encuentre fuera deGoogle Cloud (con un NEG de Internet). La comunicación con un backend de NEG de Internet puede transcurrir por la Internet pública. Cuando el balanceador de carga se conecta a un NEG de Internet, el certificado firmado por una autoridad de certificación pública debe cumplir los requisitos de validación.
Cuestiones importantes sobre los protocolos de backend seguros
Cuando utilices protocolos de servicio de backend seguros, ten en cuenta lo siguiente:
Las instancias de backend o los puntos finales del balanceador de carga deben servir usando el mismo protocolo que el servicio de backend. Por ejemplo, si el protocolo de servicio de backend es HTTPS, los backends deben ser servidores HTTPS.
Si el protocolo del servicio de backend es HTTP/2, tus backends deberán usar TLS. Para obtener instrucciones sobre la configuración, consulta la documentación del software que se ejecute en tus instancias de backend o puntos finales.
Debes instalar claves privadas y certificados en tus instancias de backend o en los puntos finales para que funcionen como servidores HTTPS o SSL. No es necesario que estos certificados coincidan con los certificados SSL del frontend del balanceador de carga. Para obtener instrucciones sobre la instalación, consulta la documentación del software que se ejecute en tus instancias de backend o puntos finales.
A excepción de los balanceadores de carga HTTPS con backends de grupos de puntos finales de Internet, los balanceadores de carga no usan las extensiones de indicador del nombre de servidor (SNI) para las conexiones al backend.
Cuando un balanceador de carga se conecta a backends que se encuentran en Google Cloud, el balanceador de carga acepta cualquier certificado que presenten tus backends. En este caso, el balanceador de carga solo realiza una validación mínima del certificado.
Por ejemplo, los certificados se tratan como válidos incluso en las siguientes circunstancias:
- El certificado tiene una firma automática.
- Si está firmado por una autoridad de certificación desconocida.
- Si ha caducado o todavía no es válido.
- Si los atributos
CNysubjectAlternativeNameno coinciden con un registro PTR de DNS o encabezadoHost.
En el caso de los certificados RSA, a partir del 28 de abril del 2025, el balanceador de carga solo aceptará los certificados RSA que tengan la extensión de uso de claves X509v3 y que incluyan los parámetros de firma digital y cifrado de claves. Para obtener más información, consulta las notas de la versión del 24 de enero del 2025.
Protocolos de frontend seguros
Cuando utilices un proxy HTTPS o SSL de destino como parte de la configuración,Google Cloud empleará un protocolo de frontend seguro.
Los balanceadores de carga de aplicación externos y los balanceadores de carga de red de proxy externo usan la biblioteca BoringCrypto de Google. Para obtener más información sobre el estándar FIPS 140‑2, visita la página del certificado n.º 3678 del programa de validación de módulos criptográficos del instituto nacional de estándares y tecnología de EE. UU. (NIST).
Los balanceadores de carga de aplicaciones internos usan la biblioteca BoringSSL de Google. Para obtener más información sobre FIPS 140‑2, consulta la documentación de Envoy. Google crea proxies Envoy para los balanceadores de carga de aplicaciones internos en el modo que cumple los estándares FIPS.
Cloud Service Mesh admite los proxies Envoy que se crean en el modo que cumple los estándares FIPS.