Encriptación en tránsito para Google Cloud

Este contenido se actualizó por última vez en abril de 2025 y representa el statu quo en el momento de su redacción. Es posible que cambien las políticas y los sistemas de seguridad de Google en el futuro, ya que mejoramos la protección de nuestros clientes de forma continua.

En Google, nuestros controles de seguridad ayudan a proteger tus datos, ya sea que estén en tránsito en Internet, dentro de la infraestructura de Google o almacenados en nuestros servidores. La autenticación, la integridad y la encriptación de los datos en reposo y en tránsito son fundamentales para la estrategia de seguridad de Google. En este documento, se describe cómo diseñamosGoogle Cloud para encriptar los datos en tránsito desde Internet y los datos en tránsito dentro de las redes de Google. Este documento no se aplica a los datos en tránsito a través de interconexiones entre las redes de centros de datos del cliente y las redes de centros de datos de Google.

La encriptación en tránsito usa varias tecnologías para ayudar a proteger los datos, como la seguridad de la capa de transporte (TLS), BoringSSL, la seguridad de la capa de transporte de la capa de aplicación (ALTS) y el protocolo de seguridad de PSP. Además de la protección predeterminada que proporciona Google, puedes proteger aún más los datos agregando opciones de encriptación, como IPsec, certificados TLS administrados y Cloud Service Mesh.

Este documento está dirigido a los equipos de operaciones de seguridad y a los directores de seguridad de la información que usan o piensan usar Google Cloud. En este documento, se supone que tienes conocimientos básicos sobre la encriptación y las primitivas criptográficas.

Autenticación, integridad y encriptación

Google usa las siguientes medidas de seguridad para garantizar la autenticidad, la integridad y la privacidad de los datos en tránsito:

  • La autenticación verifica la identidad de un par (ya sea una persona o un proceso) en una conexión.
  • La integridad evita que los datos que envías se alteren mientras están en tránsito entre la fuente y el destino.
  • La encriptación usa la criptografía para que tus datos sean ilegibles mientras están en tránsito y mantener su confidencialidad.

La encriptación en tránsito ayuda a proteger tus datos en caso de que se intercepten las comunicaciones mientras se transfieren datos entre el usuario final y Google Cloud o entre dos servicios. La encriptación en tránsito autentica los extremos y encripta los datos antes de la transmisión. Al llegar, el receptor desencripta los datos y verifica que no se hayan modificado durante el tránsito.

La encriptación es uno de los componentes de una estrategia de seguridad más amplia. La encriptación en tránsito protege tus datos contra posibles atacantes y elimina la necesidad de que Google, Google Cloud los clientes o los usuarios finales confíen en las capas inferiores de la red.

Cómo se enruta el tráfico

En esta sección, se describe cómo las solicitudes van desde un usuario final hasta el servicio o la aplicación del cliente correspondientes, y cómo se enruta el tráfico entre servicios.Google Cloud

Un Google Cloud servicio es un servicio de nube modular que ofrecemos a nuestros clientes. Estos servicios incluyen cómputo, almacenamiento de datos, análisis de datos y aprendizaje automático. Por ejemplo, Cloud Storage es un servicio de Google Cloud .

Una aplicación de cliente es una aplicación alojada en Google Cloud que tú, como cliente de Google, puedes compilar y también implementar con los servicios de Google Cloud. Las aplicaciones de clientes o soluciones de socios alojadas enGoogle Cloud no se consideran Google Cloud servicios. Por ejemplo, una aplicación que compilas con Cloud Run, Google Kubernetes Engine o una VM en Compute Engine es una aplicación de cliente.

En el siguiente diagrama, se muestran las rutas de tráfico desde el usuario final hasta Google, las rutas dentro de la red de Google y la seguridad de cada conexión. Se muestran las siguientes rutas de tráfico:

  • Usuario final en Internet a un servicio de Google Cloud (etiquetado como A en el diagrama)
  • Del usuario final en Internet a una aplicación del cliente alojada enGoogle Cloud (etiquetada como B en el diagrama)
  • De máquina virtual a máquina virtual (etiquetado como C en el diagrama)
  • De máquina virtual a Google Front End (GFE) (etiquetado como D en el diagrama)
  • GFE a las APIs y los servicios de Google (etiquetado como E en el diagrama)
  • Google Cloud servicio a Google Cloud servicio (etiquetado como F en el diagrama)

Rutas de tráfico para Google.

Encriptación en tránsito entre el usuario final y Google

En las siguientes secciones, se proporcionan más detalles sobre las solicitudes de enrutamiento del usuario final que se muestran en el diagrama anterior.

Usuario final a un servicio de Google Cloud

Los servicios deGoogle Cloud , como Cloud Storage o Compute Engine, son servicios en la nube que ofrecemos a los clientes y que se ejecutan en nuestro entorno de producción. Los servicios deGoogle Cloud aceptan solicitudes de todo el mundo a través de un sistema distribuido globalmente llamado Google Front End (GFE). GFE finaliza el tráfico para las conexiones entrantes de HTTP(S), TCP y TLS, proporciona contramedidas de ataque de DSD y, además, enruta y balancea las cargas del tráfico a losGoogle Cloud servicios en sí. Existen puntos de presencia de GFE en todo el mundo con rutas que se anuncian a través de unidifusión o Anycast.

El GFE enruta el tráfico de un usuario final a través de la red de Google hacia un servicio deGoogle Cloud y de un usuario final a una aplicación de cliente alojada en Google Cloud que usa Cloud Load Balancing.

Las solicitudes que los clientes envían a un Google Cloud servicio a través de HTTPS, HTTP/2 o HTTP/3 se protegen con TLS. La TLS en el GFE se implementa con BoringSSL, una implementación de código abierto del protocolo TLS que mantiene Google. BoringCrypto, el núcleo de BoringSSL, cuenta con la validación FIPS 140-3 de nivel 1.

El GFE negocia parámetros criptográficos estándares de la industria con el cliente, incluida la negociación de claves con seguridad de avance. En el caso de los clientes más antiguos y con menos capacidad, el GFE elige las primitivas criptográficas heredadas más sólidas que ofrece el cliente.

Del usuario final a una aplicación del cliente alojada en Google Cloud

Puedes enrutar el tráfico de los usuarios finales desde Internet a tus aplicaciones para clientes alojadas en Google Cloud a través de una conexión directa o un balanceador de cargas. Cuando el tráfico se enruta directamente, se dirige a la dirección IP externa del servidor de la VM que aloja la aplicación.

Puedes usar TLS con el balanceador de cargas de aplicaciones externo o el balanceador de cargas de red de proxy externo para conectarte a tu aplicación que se ejecuta en Google Cloud. Cuando usas un balanceador de cargas de capa 7, la conexión entre el usuario final y el balanceador de cargas se encripta con TLS de forma predeterminada (siempre que la aplicación cliente del usuario final admita TLS). El GFE finaliza las conexiones TLS de tus usuarios finales con certificados TLS autoadministrados o administrados por Google. Para obtener más información sobre cómo personalizar tu certificado, consulta Descripción general de los certificados SSL. Para habilitar la encriptación entre el balanceador de cargas y la VM que aloja la aplicación del cliente, consulta Encriptación del balanceador de cargas a los backends.

Para configurar TLS mutua (mTLS), consulta Descripción general de TLS mutua. Para las cargas de trabajo en GKE y Compute Engine, considera usar Cloud Service Mesh para que puedas usar mTLS para la autenticación mutua (cliente y servidor) y encriptar las comunicaciones en tránsito con los certificados que administras.

Para Firebase Hosting y los dominios personalizados de Cloud Run, considera nuestros certificados TLS gratuitos y automatizados. Con los dominios personalizados de Cloud Run, también puedes proporcionar tus propios certificados SSL y usar un encabezado de HTTP con Seguridad de Transporte Estricta (HSTS).

Encriptación en tránsito dentro de las redes de Google

Google Cloud encripta los datos del cliente en tránsito dentro de las redes de Google, a menos que se describa lo contrario en esta sección.

Las interconexiones especializadas de rendimiento ultra alto que conectan las TPU o las GPU dentro de las supercomputadoras de IA de Google son independientes de las redes que se describen en este documento. En Google Cloud, estas interconexiones de rendimiento ultra alto son ICI para las TPU y NVLink para las GPU. Para obtener más información, consulta Arquitectura de TPU y Tipos de máquinas con GPU.

El tráfico a través de conexiones a VMs que usan direcciones IP externas sale de las redes de Google. Eres responsable de configurar tu propia encriptación para esas conexiones.

Google Cloud Autenticación y encriptación de redes virtuales

La red virtual deGoogle Cloudencripta, protege la integridad y autentica el tráfico entre las VMs.

La encriptación del tráfico de IP privada dentro de la misma VPC o en redes de VPC con intercambio de tráfico dentro de la red virtual de Google Cloudse realiza en la capa de red.

Cada par de hosts en comunicación establece una clave de sesión a través de un canal de control protegido por ALTS para comunicaciones autenticadas, encriptadas y protegidas contra la pérdida de integridad. La clave de sesión se usa para encriptar la comunicación de VM a VM entre esos hosts, y las claves de sesión se rotan periódicamente.

Las conexiones de VM a VM dentro de las redes de VPC y las redes de VPC con intercambio de tráfico dentro de la red de producción de Google están protegidas contra la integridad y encriptadas. Estas conexiones incluyen las que se establecen entre las VMs del cliente y entre las VMs administradas por el cliente y Google, como Cloud SQL. El diagrama en Cómo se enruta el tráfico muestra esta interacción (conexión C). Ten en cuenta que, debido a que Google activa el encriptado automático según el uso de direcciones IP internas, las conexiones entre VMs que usan direcciones IP externas no se encriptan automáticamente.

La red virtual deGoogle Cloudautentica todo el tráfico entre las VMs. Esta autenticación, que se realiza con tokens de seguridad, impide que un host vulnerado pueda falsificar la identidad de paquetes en la red.

Los tokens de seguridad se encapsulan en un encabezado de túnel que contiene información de autenticación sobre el emisor y el receptor. El plano de control del host emisor establece el token, y el host receptor lo valida. Los tokens de seguridad se generan previamente para cada flujo y se componen de un token (que contiene la información del emisor) y el secreto de host.

Conectividad a los servicios y las API de Google

El control del tráfico difiere según dónde se aloje el servicio de Google Cloud .

La mayoría de los servicios y las APIs de Google se alojan en GFE. El tráfico de VM a GFE usa direcciones IP externas para llegar a los servicios de Google Cloud , pero puedes configurar el acceso privado para evitar el uso de direcciones IP externas. La conexión del GFE al servicio se autentica y encripta.

Algunos servicios, como Cloud SQL, se alojan en instancias de VM administradas por Google. Si las VMs de los clientes acceden a los servicios alojados en instancias de VM administradas por Google a través de direcciones IP externas, el tráfico permanece en la red de producción de Google, pero no se encripta automáticamente debido al uso de las direcciones IP externas. Para obtener más información, consulta Google Cloud autenticación y encriptación de redes virtuales.

Cuando un usuario envía una solicitud a un servicio de Google Cloud , protegemos los datos en tránsito (proporcionando autenticación, integridad y encriptación) con HTTPS y un certificado de una autoridad certificadora web (pública). Todos los datos que el usuario envía al GFE se encriptan en tránsito con TLS o QUIC. El GFE negocia un protocolo de encriptación específico con el cliente según lo que este pueda admitir. Cuando es posible, GFE negocia protocolos de encriptación más modernos.

Autenticación, integridad y encriptación entre servicios

La infraestructura de Google usa ALTS para la autenticación, integridad y encriptación de las conexiones desde el GFE a un servicio Google Cloud y de un servicio Google Cloud a otro Google Cloud .

ALTS usa identidades basadas en servicios para la autenticación. Los servicios que se ejecutan en el entorno de producción de Google reciben credenciales que confirman sus identidades basadas en servicios. Cuando se hacen RPC o se reciben de otros servicios, un servicio usa sus credenciales para autenticarse. La ALTS verifica que estas credenciales se emitan a través de la CA interna de Google. La CA interna de Google no se relaciona con el Servicio de autoridad certificadora y es independiente de él.

ALTS usa encriptación y protección de integridad criptográfica para el tráfico que transporta Google Cloud datos desde el GFE a un servicio y entre servicios que se ejecutan en el entorno de producción de Google.

ALTS también se usa para encapsular otros protocolos de la capa 7, como HTTP, en mecanismos de RPC para el tráfico entre los GFE y los servicios de Google Cloud. Esta protección ayuda a aislar la capa de la aplicación y quita cualquier dependencia de la seguridad de la ruta de red.

Métodos de encriptación en tránsito

En las siguientes secciones, se describen algunas de las tecnologías que Google usa para encriptar los datos en tránsito.

Encriptación de red mediante PSP

El PSP es un protocolo independiente del transporte que habilita la seguridad por conexión y admite la descarga de encriptación en hardware de tarjetas de interfaz de red inteligentes (SmartNIC). Siempre que los SmartNIC estén disponibles, ALTS usa PSP para encriptar los datos en tránsito a través de nuestra red.

PSP está diseñado para cumplir con los requisitos del tráfico de los centros de datos a gran escala. La infraestructura de Google usa PSP para encriptar el tráfico dentro y entre nuestros centros de datos. PSP también admite protocolos que no son de TCP, como UDP, y usa una clave de encriptación única para cada conexión.

Seguridad de transporte de la capa de la aplicación

ALTS es un sistema de autenticación y encriptación mutua desarrollado por Google. ALTS proporciona autenticación, confidencialidad e integridad para los datos en tránsito entre los servicios que se ejecutan en el entorno de producción de Google. ALTS consta de los siguientes protocolos:

  • Protocolo de enlace: El cliente inicia un intercambio de claves combinado de curva elíptica y seguro para la computación cuántica. Al final del protocolo de enlace, los servicios involucrados se autentican mutuamente intercambiando y verificando certificados firmados, y calculan una clave de tráfico compartida. Entre los algoritmos compatibles para derivar la clave de tráfico compartida, se encuentra el algoritmo poscuántico ML-KEM (FIPS 203) del NIST. Para obtener más información, consulta Criptografía poscuántica.

  • Protocolo de registro: Los datos de servicio a servicio se encriptan en tránsito con la clave de tráfico compartida. De forma predeterminada, ALTS usa la encriptación AES-128-GCM para todo el tráfico. Los datos en tránsito dentro del sistema de almacenamiento de nivel más bajo de Google utilizan la encriptación AES-256, y ALTS proporciona autenticación de mensajes AES. La encriptación en ALTS se proporciona a través de BoringSSL o PSP. Esta encriptación se valida en el nivel 1 de FIPS 140-2 o FIPS 140-3.

Las claves de firma raíz de los certificados de ALTS se almacenan en la CA interna de Google.

¿Qué sigue?