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 circulen por Internet, se muevan dentro de la infraestructura de Google o estén 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 informe, 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 los centros de datos del cliente y las redes de los centros de datos de Google.
La encriptación en tránsito usa varias tecnologías para ayudar a proteger los datos, incluidos la seguridad de la capa de transporte (TLS), BoringSSL, la seguridad de transporte de la capa de aplicación (ALTS) y el protocolo de seguridad del PSP. Además de la protección predeterminada que proporciona Google, puedes agregar opciones de encriptación como IPsec, certificados TLS administrados y Cloud Service Mesh para aumentar la protección de los datos.
Este documento está dirigido a los equipos de operaciones de seguridad y a los directores de seguridad de la información que usan o consideran 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 intercambio de tráfico (ya sea una persona o un proceso) en una conexión.
- La integridad evita que los datos que envías se modifiquen mientras están en tránsito entre el origen y el destino.
- La encriptación usa criptografía para que tus datos sean ilegibles mientras están en tránsito y para mantenerlos confidenciales.
La encriptación en tránsito ayuda a proteger tus datos en caso de que se intercepten las comunicaciones mientras se transfieren 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. Cuando llega, 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 defiende tus datos contra posibles atacantes y quita 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 servicioGoogle Cloud o la aplicación del cliente correspondientes y cómo se enruta el tráfico entre servicios.
Un Google Cloud servicio es un servicio de nube modular que ofrecemos a nuestros clientes. Estos servicios incluyen procesamiento, almacenamiento de datos, análisis de datos y aprendizaje automático. Por ejemplo, Cloud Storage es un servicio Google Cloud .
Una aplicación de cliente es una aplicación alojada en Google Cloud que tú, como cliente de Google, puedes compilar e implementar mediante 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 compilada 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 Google Cloud (etiquetado A en el diagrama)
- Del usuario final en Internet a una aplicación de cliente alojada enGoogle Cloud (con la etiqueta B en el diagrama)
- De máquina virtual a máquina virtual (etiquetada C en el diagrama)
- De máquina virtual a Google Front End (GFE) (con la etiqueta D en el diagrama)
- GFE a las APIs y los servicios de Google (etiquetados E en el diagrama)
- Google Cloud service to Google Cloud service (etiquetado con F en el diagrama)
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 de usuarios finales que se muestran en el diagrama anterior.
Usuario final de un Google Cloud servicio
Google Cloud Los servicios como Cloud Storage o Compute Engine son servicios en la nube que ofrecemos a los clientes y se ejecutan en nuestro entorno de producción.Google Cloud Los servicios aceptan solicitudes de todo el mundo mediante un sistema distribuido a nivel global llamado Google Front End (GFE). GFE finaliza el tráfico de las conexiones HTTP(S), TCP y TLS entrantes; proporciona contramedidas de ataque DDoS, y enruta y balancea las cargas del tráfico a los Google Cloud servicios en sí mismos. Los puntos de presencia de GFE existen en todo el mundo con rutas de acceso que se anuncian mediante unidifusión o Anycast.
GFE enruta el tráfico de un usuario final a través de la red de Google a un servicioGoogle Cloud y de un usuario final a una aplicación de cliente que se aloja en Google Cloud y usa Cloud Load Balancing.
Las solicitudes que los clientes envían a un servicio Google Cloud a través de HTTPS, HTTP/2 o HTTP/3 están protegidas con TLS. TLS se implementa en GFE con BoringSSL, una implementación de código abierto del protocolo TLS que mantiene Google. BoringCrypto, el núcleo de BoringSSL, está validado según el nivel 1 del estándar FIPS 140-3.
El GFE negocia parámetros criptográficos estándar de la industria con el cliente, incluida la negociación de claves seguras para reenvío. En el caso de los clientes más antiguos y con menos capacidades, GFE elige las primitivas criptográficas heredadas más sólidas que ofrece el cliente.
Del usuario final a una aplicación de cliente alojada en Google Cloud
Puedes enrutar el tráfico de usuarios finales desde Internet hasta las aplicaciones de tus clientes que están alojadas en Google Cloud mediante una conexión directa o a través de un balanceador de cargas. Cuando el tráfico se enruta directamente, el tráfico se enruta a la dirección IP externa del servidor de VM que aloja la aplicación.
Puedes usar TLS con el balanceador de cargas de aplicaciones externo o el balanceador de cargas de red del proxy externo para conectarte a la 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 de forma predeterminada con TLS (siempre que la aplicación cliente del usuario final admita TLS). El GFE finaliza las conexiones TLS de tus usuarios finales mediante 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. En el caso de las cargas de trabajo en GKE y Compute Engine, considera usar Cloud Service Mesh para poder usar mTLS en la autenticación mutua (cliente y servidor) y encriptar las comunicaciones en tránsito mediante certificados que administres.
Para Firebase Hosting y 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 HTTP de 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 muy alto rendimiento que conectan TPU o GPU dentro de las supercomputadoras de IA de Google son independientes de las redes descritas en este documento. En Google Cloud, estas interconexiones de rendimiento ultraalto son ICI para TPU y NVLink para GPU. Para obtener más información, consulta Arquitectura de TPU y Tipos de máquinas de GPU.
El tráfico mediante conexiones a VM mediante direcciones IP externas sale de las redes de Google. Eres responsable de configurar tu propia encriptación para esas conexiones.
Google Cloud la autenticación y encriptación de redes virtuales
La red virtual deGoogle Cloudencripta, protege y autentica el tráfico entre las VMs.
La encriptación del tráfico de IP privada dentro de la misma VPC o entre redes de VPC con intercambio de tráfico dentro de la red virtual de Google Cloudse realiza en la capa de la 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, protegidas por la integridad y encriptadas. La clave de sesión se usa para encriptar la comunicación de VM a VM entre esos hosts. Las claves de sesión se rotan de forma periódica.
Las conexiones de VM a VM dentro de redes de VPC y de VPC con intercambio de tráfico dentro de la red de producción de Google están encriptadas y protegidas por la integridad. Estas conexiones incluyen conexiones entre las VM del cliente y entre las VM del cliente y las administradas por Google, como Cloud SQL. En el diagrama de Cómo se enruta el tráfico, se muestra esta interacción (conexión C). Ten en cuenta que, debido a que Google activa la encriptación automática en función del uso de direcciones IP internas, las conexiones entre VM que usan direcciones IP externas no se encriptan de forma automática.
La red virtual deGoogle Cloudautentica todo el tráfico entre las VM. Esta autenticación, que se logra con tokens de seguridad, evita que un host vulnerado falsifique la identidad de los paquetes de la red.
Los tokens de seguridad se encapsulan en un encabezado de túnel que contiene información de autenticación sobre el remitente y el receptor. El plano de control en el host de envío 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 remitente) y el secreto del host.
Conectividad a los servicios y las API de Google
El control del tráfico difiere según la ubicación en la que esté alojado el servicio 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. Se autentica y encripta la conexión del GFE al servicio.
Algunos servicios, como Cloud SQL, se alojan en instancias de VM administradas por Google. Si las VM del cliente acceden a los servicios alojados en las instancias de VM administradas por Google con 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 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 Google Cloud , protegemos los datos en tránsito (lo que proporciona autenticación, integridad y encriptación) mediante HTTPS con 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 particular con el cliente en función de lo que este pueda admitir. Cuando es posible, el 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 del GFE a un Google Cloud servicio, y de un Google Cloud servicio a otro Google Cloud .
La elevación 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 declaran sus identidades basadas en servicios. Cuando se realizan o reciben RPC de otros servicios, un servicio usa sus credenciales para autenticarse. La alta disponibilidad verifica que la AC interna de Google haya emitido estas credenciales. La AC interna de Google no está relacionada y es independiente de Certificate Authority Service.
El sistema usa encriptación y protección de la integridad criptográfica para el tráfico que transporta Google Cloud datos del GFE a un servicio y entre servicios que se ejecutan en el entorno de producción de Google.
La Altitud también se usa con el objetivo de encapsular otros protocolos de 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 usa Google para encriptar los datos en tránsito.
Encriptación de red mediante PSP
PSP es un protocolo independiente del transporte que habilita la seguridad por conexión y admite la transferencia de la encriptación al hardware de tarjetas de interfaz de red inteligentes (SmartNIC). Siempre que los SmartNIC estén disponibles, la {/3}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 utiliza PSP para encriptar el tráfico dentro de nuestros centros de datos y entre ellos. PSP también admite protocolos que no son 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
La ALTS es un sistema de encriptación y autenticación mutua desarrollado por Google. La {/3}ALTS proporciona autenticación, integridad y confidencialidad para los datos en tránsito entre servicios que se ejecutan en el entorno de producción de Google. La elevación consta de los siguientes protocolos:
Protocolo de enlace: El cliente inicia una combinación de curva elíptica y un intercambio de claves seguro cuántico. Al final del protocolo de enlace, los servicios involucrados autentican las identidades de los demás mediante el intercambio y la verificación de los certificados firmados y procesan 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 mediante la clave de tráfico compartida. De forma predeterminada, la configuración de seguridad de la capa de red (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 la {/3}ALTS proporciona autenticación de mensajes AES. BoringSSL o PSP proporciona la encriptación en la sistema horizontal. Esta encriptación se valida con el nivel 1 del estándar FIPS 140-2 o con el nivel 1 del estándar FIPS 140-3.
Las claves de firma raíz para los certificados ALTS se almacenan en la AC interna de Google.
¿Qué sigue?
- Consulta seguridad del centro de datos para obtener más información al respecto.
- Si deseas obtener información sobre las opciones de configuración de seguridad para las interconexiones entreGoogle Cloud y las redes del centro de datos del cliente, consulta Elige un producto de conectividad de red (IPSec) y Descripción general de MACsec para Cloud Interconnect.
- Para obtener información sobre Google Cloud el cumplimiento y las certificaciones relacionadas, consulta el Centro de recursos de cumplimiento, que incluye nuestro informe de auditoría SOC 3.
- Si deseas conocer las prácticas recomendadas para proteger tus datos en tránsito, consulta el plano de bases empresariales, Google Cloud Framework de la arquitectura: seguridad, privacidad y cumplimiento, y Decide cómo cumplir los requisitos reglamentarios para la encriptación en tránsito.