Este es el tercer informe acerca de cómo Google usa la encriptación para proteger tus datos. En él, encontrarás información más detallada sobre la encriptación en tránsito de Google Cloud y Google Workspace.
Nos esforzamos en mantener una alta protección de los datos de los clientes en todos los productos de Google y ser lo más transparentes posible sobre nuestros métodos de protección.
Este contenido se actualizó por última vez en septiembre de 2022 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, ya que mejoramos la protección de nuestros clientes de forma continua.
Resumen para directores generales de información
- Google usa varias medidas de seguridad para garantizar la autenticidad, la integridad y la privacidad de los datos en tránsito.
- Para los casos de uso que se analizan en este informe, Google encripta y autentica datos en tránsito en una o más capas de red cuando los datos se transfieren fuera de los límites físicos no controlados por Google ni en su nombre. 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.
- Según la conexión que se realice, Google aplica las protecciones predeterminadas a los datos en tránsito. Por ejemplo, aseguramos las comunicaciones entre el usuario y el Google Front End (GFE) mediante la TLS.
- Los clientes de Google Cloud con requisitos adicionales de encriptación de datos a través de WAN pueden elegir la implementación de protección de datos adicional a medida que se transfieren de un usuario a una aplicación o de una máquina virtual a otra. Estas protecciones incluyen túneles IPSec, S/MIME de Gmail, Istio y certificados SSL administrados.
- Google trabaja de forma activa con el sector para que todas las personas, en cualquier lugar, tengan acceso a la encriptación en tránsito. Tenemos varios proyectos de código abierto que promueven el uso de la encriptación en tránsito y la seguridad de los datos en Internet a gran escala, que incluyen el Certificado de transparencia, las API de Chrome y el SMTP seguro.
- Google pretende seguir siendo el líder de la industria de encriptación en tránsito. A fin de lograrlo, dedicamos recursos para desarrollar y mejorar la tecnología de encriptación. Nuestro trabajo en este campo incluye innovaciones en las áreas de Key Transparency y criptografía poscuántica.
Introducción
La seguridad suele ser un factor decisivo al momento de elegir un proveedor de servicios en la nube pública. En Google, la seguridad es lo más importante. Trabajamos sin descanso para proteger tus datos, ya sea que estén en tránsito en Internet, dentro de los límites de la infraestructura de Google o almacenados en nuestros servidores.
La autenticación, la integridad y la encriptación de datos en reposo y en tránsito son fundamentales para la estrategia de seguridad de Google. En este informe, se describe nuestro enfoque respecto a la encriptación en tránsito de Google Cloud.
Para obtener información sobre los datos en reposo, consulta Encriptación en reposo en Google Cloud Platform. Para ver una descripción general de toda la seguridad de Google, consulta la descripción general del diseño de seguridad de la infraestructura de Google.
Público: este documento está dirigido a los equipos de operaciones de seguridad y CISO que usan o piensan usar Google Cloud.
Requisitos: Además de esta introducción, se da por sentado que tienes conocimientos básicos sobre la encriptación y las primitivas criptográficas.
Autenticación, integridad y encriptación
Google usa varias medidas de seguridad para garantizar la autenticidad, la integridad y la privacidad de los datos en tránsito.
- Autenticación: verificamos la fuente de datos, ya sea una persona o un proceso, y su destino.
- Integridad: nos aseguramos de que los datos que envíes lleguen intactos a su destino.
- Encriptación: para mantener la privacidad de tus datos, los hacemos ilegibles mientras estén en tránsito. La encriptación es el proceso que convierte datos legibles (texto simple) en datos ilegibles (texto cifrado) a fin de garantizar que solo las partes autorizadas por el propietario de los datos puedan acceder al texto sin formato. Los algoritmos que se usan en el proceso de encriptación son públicos, pero la clave necesaria para desencriptar el texto cifrado es privada. A menudo, la encriptación en tránsito usa un intercambio de claves asimétricas, como el intercambio basado en curvas elípticas de Diffie-Hellman, para crear una clave simétrica compartida que se usa en la encriptación de datos. Para obtener más información sobre la encriptación, consulta Introduction to Modern Cryptography (Introducción a la criptografía moderna).
La encriptación se puede usar para proteger los datos en tres estados:
- La encriptación en reposo protege tus datos contra la vulneración del sistema o el robo de datos mediante la encriptación mientras están almacenados. A menudo, se usa el estándar de encriptación avanzada (AES) para encriptar los datos en reposo.
- Encriptación en tránsito: Protege tus datos en caso de que se intercepten las comunicaciones mientras se transfieren datos entre tu sitio y el proveedor de servicios en la nube o entre dos servicios. Para lograr esta protección, los datos se encriptan antes de su transmisión, se autentican los extremos, y, al momento de la llegada, los datos se desencriptan y se verifica que se hayan modificado. Por ejemplo, la seguridad de la capa de transporte (TLS) se usa con frecuencia para encriptar datos en tránsito y garantizar la seguridad durante su transferencia, mientras que las Extensiones de Correo de Internet de Propósitos Múltiples/Seguro (S/MIME) se usan a menudo para la seguridad de los mensajes de correo electrónico.
- Encriptación en uso: protege tus datos en la memoria contra el riesgo o el robo de datos mediante su encriptación mientras se procesan. Para obtener más información, consulta Confidential Computing.
La encriptación es uno de los componentes de una estrategia de seguridad más amplia. Una vez establecida y autenticada una conexión, la encriptación en tránsito protege tus datos contra posibles atacantes mediante las siguientes acciones:
- Quita la necesidad de confiar en las capas inferiores de la red, las que, con frecuencia, son proporcionadas por terceros.
- Reduce la posible superficie de exposición a ataques.
- Impide que los atacantes accedan a los datos si se interceptan las comunicaciones.
Con una autenticación, integridad y encriptación adecuadas, es posible proteger los datos que se transfieren entre usuarios, dispositivos o procesos en un entorno hostil. En lo que queda de este informe, se explica el enfoque de Google respecto a la encriptación de datos en tránsito y dónde se aplica.
Infraestructura de red de Google
Límites físicos
Un límite físico es la barrera de un espacio físico controlado por Google o en su nombre donde podemos garantizar el uso de medidas de seguridad estrictas. El acceso físico a estas ubicaciones es restringido y se supervisa exhaustivamente. Solo un pequeño porcentaje del personal de Google tiene acceso al hardware. En general, se autentican los datos en tránsito dentro de estos límites físicos, pero puede que no se encripten de manera predeterminada.
Debido a la escala mundial de Internet, no podemos aplicar los mismos controles de seguridad física en los vínculos de fibra de nuestra WAN ni en cualquier lugar fuera de los límites físicos controlados por Google o en su nombre. Es por esta razón que aplicamos automáticamente protecciones adicionales fuera de nuestro límite de confianza físico. Estas protecciones incluyen la encriptación de los datos en tránsito para todo el tráfico fuera de nuestros límites físicos.
Cómo se enruta el tráfico
A fin de entender bien cómo funciona la encriptación en tránsito de Google, es necesario explicar el modo en el que el tráfico se enruta a través de Internet. En esta sección, se describe cómo las solicitudes van desde un usuario final hasta el servicio de Google Cloud o la aplicación del cliente correspondientes y cómo se enruta el tráfico entre servicios.
Un servicio de Google Cloud 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 mediante los servicios de Google Cloud. Las aplicaciones de clientes o soluciones de socios alojadas en Google Cloud no se consideran servicios de Google Cloud.1 Por ejemplo, una aplicación compilada usando Google App Engine, Google Kubernetes Engine o una VM en Google Compute Engine es una aplicación de cliente.
En la figura 1, se muestran los cinco tipos de solicitudes de enrutamiento que se analizan a continuación. En esta figura, se muestran las interacciones entre los diversos componentes de red y la seguridad aplicada a cada conexión.
Usuario final (Internet) a un servicio de Google Cloud
Los servicios de Google Cloud aceptan solicitudes de todo el mundo a través de un sistema de distribución mundial llamado Google Front End (GFE). El GFE finaliza el tráfico entrante de proxy TLS, HTTP(S) y TCP, proporciona contramedidas para aplacar los ataques de DSD y, además, enruta el tráfico y balancea sus cargas a los servicios de Google Cloud en sí. Existen puntos de presencia del GFE en todo el mundo con rutas anunciadas a través de Unicast o Anycast.
Los GFE autorizan el tráfico a los servicios de Google Cloud. Los GFE enrutan la solicitud del usuario a través de nuestra red troncal a un servicio de Google Cloud. Esta conexión se autentica y encripta desde el GFE hasta el frontend del servicio de Google Cloud o la aplicación del cliente cuando esas comunicaciones salen de un límite físico controlado por Google o en su nombre. La figura 1 muestra esta interacción (etiquetada como conexión A).
Del usuario final (Internet) a una aplicación de cliente alojada en Google Cloud
Existen diversas maneras de enrutar el tráfico de Internet a una aplicación de cliente alojada en Google Cloud. El modo en que tu tráfico se enruta depende de tu configuración, como se explica a continuación. La Figura 1 muestra esta interacción (etiquetada como conexión B).
Si usas un balanceador de cargas de aplicaciones externo o un balanceador de cargas de red de proxy externo (con un proxy SSL), consulta Encriptación del balanceador de cargas a los backends.
Entre máquinas virtuales
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 se autentican y encriptan. Esto incluye conexiones entre las VM del cliente y entre las VM administradas por el cliente y Google, como Cloud SQL. La Figura 1 muestra esta interacción (etiquetada como conexión C). Ten en cuenta que las conexiones de VM a VM que usan direcciones IP externas no están encriptadas.
Conectividad a los servicios y las API de Google
El control del tráfico depende de la ubicación del servicio de Google Cloud:
La mayoría de los servicios y las API de Google se alojan en Google Front Ends (GFE); sin embargo, algunos servicios se alojan en instancias administradas por Google. Por ejemplo, los accesos de servicios privados y las instancias principales de los GKE para clústeres privados se alojan en instancias administradas por Google.
Con el Acceso privado a Google, las VM sin direcciones IP externas pueden acceder a las API y los servicios de Google admitidos, que incluyen las aplicaciones de clientes alojadas en App Engine. Para obtener más información sobre el acceso a los servicios y las API de Google, consulta Opciones de acceso privado a los servicios.
Si una instancia de VM de Compute Engine se conecta a la dirección IP externa de otra instancia de VM de Compute Engine, el tráfico permanece en la red de producción de Google, pero no se encripta debido al uso de la dirección IP externa. A los sistemas que están fuera de la red de producción de Google y se conectan a una dirección IP externa de una instancia de VM de Compute Engine se les enruta el tráfico a través de Internet.
En la Figura 1 se muestra una ruta externa (conexión etiquetada como D) Los siguientes son casos habituales de este tipo de solicitud de enrutamiento:
- De una VM de Compute Engine a Google Cloud Storage
- De una VM de Compute Engine a una API de aprendizaje automático
Según la configuración predeterminada, los servicios de Google Cloud admiten la protección de estas conexiones con TLS2, desde la VM hasta el GFE. La conexión se autentica desde el GFE hasta el servicio y se encripta si la conexión sale de un límite físico. Además de estas protecciones predeterminadas, puedes aplicar la encriptación de sobre. Para obtener más información, consulta Encripta tus datos.
Entre servicios de Google Cloud
El enrutamiento de un servicio de producción a otro se realiza en nuestra tecnología de red, y es posible que requiera el enrutamiento del tráfico fuera de los límites físicos controlados por Google o en su nombre. La figura 1 muestra esta interacción (etiquetada como conexión E). Un ejemplo de este tipo de tráfico es un evento de Google Cloud Storage que activa a Google Cloud Functions. Se encriptan las conexiones entre los servicios de producción si salen de un límite físico y se autentican dentro de él.
Figura 1: Protección según la configuración predeterminada y las opciones superpuestas en una red de VPC
Encriptación en tránsito de forma predeterminada
Google usa diversos métodos de encriptación de datos en tránsito, tanto predeterminados como configurables por el usuario. El tipo de encriptación usado depende de la capa OSI, del tipo de servicio y del componente físico de la infraestructura. Las figuras 2 y 3 muestran las protecciones opcionales y predeterminadas que Google Cloud aplica a las capas 3, 4 y 7.
Figura 2: Protección predeterminada y opciones en las capas 3 y 4 en Google Cloud
Figura 3: Protección predeterminada y opciones en la capa 7 en Google Cloud3
En el resto de esta sección, se describen las protecciones predeterminadas que Google usa para proteger los datos en tránsito.
Encriptación del usuario al Google Front End
En la actualidad, muchos sistemas usan HTTPS para comunicarse a través de Internet. HTTPS proporciona seguridad mediante una conexión TLS, lo que garantiza la autenticidad, integridad y privacidad de las solicitudes y respuestas. Para aceptar las solicitudes HTTPS, el receptor necesita un par de claves públicas/privadas y un certificado X.509 de autenticación de servidor proporcionado por una autoridad certificada (CA). El par de claves y el certificado ayudan a proteger las solicitudes de un usuario en la capa de aplicación (capa 7), ya que son prueba de que el receptor es propietario del nombre de dominio para el que se realizan las solicitudes. Las subsecciones siguientes abordan los componentes de la encriptación entre el usuario y GFE, es decir: TLS, BoringSSL y la autoridad certificada de Google. Ten en cuenta que no todas las rutas de cliente se enrutan a través de GFE. En particular, GFE se usa para el tráfico desde un usuario hasta un servicio de Google Cloud y desde un usuario hasta una aplicación de cliente alojada en Google Cloud que usa Google Cloud Load Balancing.
Seguridad de la capa de transporte (TLS)
Cuando un usuario envía una solicitud a un servicio de Google Cloud, aseguramos los datos en tránsito con autenticación, integridad y encriptación usando el protocolo HTTPS con un certificado de una autoridad certificada web (pública). Todos los datos que el usuario envía al GFE se encriptan en tránsito mediante la seguridad de la capa de transporte (TLS) o QUIC. El GFE negocia un protocolo de encriptación determinado con el cliente en función de lo que el cliente puede admitir. Cuando es posible, GFE negocia protocolos de encriptación más modernos.
La encriptación TLS en escala del GFE no solo se aplica a las interacciones del usuario final con Google, sino que también facilita las interacciones de las API con Google a través de la TLS, incluido Google Cloud. Además, nuestra encriptación TLS se usa en Gmail para intercambiar correos electrónicos con servidores de correo externos (obtén más detalles en la sección Exige TLS en Gmail).
Google es líder del sector tanto en la adopción de TLS como en el fortalecimiento de su implementación. Para ello, habilitamos de forma predeterminada muchas de las características de seguridad de TLS. Por ejemplo, usamos la confidencialidad directa en nuestra implementación de la TLS desde 2011. La confidencialidad directa se encarga de que la clave que protege una conexión no sea persistente, de modo tal que un atacante que intercepte y lea un mensaje no pueda leer los anteriores.
BoringSSL
BoringSSL es una implementación de código abierto que mantiene Google del protocolo TLS. Proviene de OpenSSL y su interfaz es, en su mayoría, compatible con OpenSSL. Google bifurcó BoringSSL de OpenSSL a fin de simplificar OpenSSL para el uso interno y lograr una mayor compatibilidad con los proyectos de código abierto de Android y Chromium. BoringCrypto, el núcleo de BoringSSL, cuenta con la validación FIPS 140-2 de nivel 1.
La TLS se implementa en el GFE con BoringSSL. La tabla 1 muestra los protocolos de encriptación compatibles con el GFE cuando este se comunica con los clientes.
| Protocolos | Autenticación | Intercambio de claves | Encriptación | Funciones de hash |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256 (NIST secp256r1) | AES-256-GCM | SHA256 |
| TLS 1.1 | AES-128-CBC | SHA17 | ||
| TLS 1.04 | AES-256-CBC | MD58 | ||
| QUIC5 | ChaCha20-Poly1305 | |||
| 3DES6 |
Tabla 1: Encriptación implementada en el Google Front End para los servicios de Google Cloud y también implementada en la biblioteca criptográfica BoringSSL
Autoridad certificada de Google
Como parte de la TLS, un servidor debe demostrar su identidad al usuario cuando recibe una solicitud de conexión. Esta verificación de identidad se logra en el protocolo TLS cuando se hace que el servidor presente un certificado que contenga la identidad afirmada. El certificado contiene el nombre de host DNS del servidor y su clave pública. Una vez presentado el certificado, lo firma una autoridad certificadora (CA) emisora, que es de confianza para el usuario que solicita la conexión9. Como resultado, los usuarios que solicitan conexiones al servidor solo necesitan confiar en la CA raíz. Si el servidor desea otorgar acceso universal, los dispositivos cliente de todo el mundo deben conocer la CA raíz. Actualmente, la mayoría de los navegadores y otras implementaciones de cliente de TLS cuentan con su propio conjunto de CA raíz que están configuradas como confiables en su "tienda raíz".
Google siempre ha operado su propia CA emisora, la cual usamos para firmar los certificados de los dominios de Google. Sin embargo, no operábamos nuestra propia CA raíz. En la actualidad, varias CA raíces ampliamente distribuidas firman nuestros certificados de CA, entre ellas DigiCert y raíces que GlobalSign operaba anteriormente (“GS Root R2” y “GS Root R4”).
En junio de 2017, anunciamos la transición hacia el uso de CA raíces de propiedad de Google. Con el tiempo, planeamos operar una CA raíz distribuida por todo el mundo que emita certificados para los dominios de Google y para nuestros clientes.
Migración de clave raíz y rotación de claves
Las claves de CA raíz no cambian con frecuencia, ya que migrar a una nueva CA raíz implica que todos los navegadores y dispositivos depositen su confianza en ese certificado, lo cual es un proceso demoroso. Como resultado, aun cuando Google opera ahora sus propias CA raíces, seguiremos dependiendo de varias CA raíces de terceros para un período de transición a fin de responder a los dispositivos heredados mientras migramos a las nuestras.
Crear una clave de CA raíz nueva requiere una ceremonia de claves. En Google, la ceremonia ordena que un mínimo de 3 de las 6 personas autorizadas posibles se reúnan físicamente para usar claves de hardware almacenadas en una caja fuerte. Estas personas se reúnen en una habitación dedicada, protegida contra la interferencia electromagnética y con un módulo de seguridad de hardware (HSM) aislado, para generar un conjunto de claves y certificados. La habitación dedicada se encuentra en una ubicación segura en los centros de datos de Google. Existen controles adicionales, como medidas de seguridad físicas, cámaras y otros observadores humanos, que garantizan que el proceso se lleve a cabo según lo planeado. Si la ceremonia se realiza correctamente, el certificado generado es idéntico a un certificado de muestra, salvo por el nombre del emisor, la clave pública y la firma. Luego, el certificado de CA raíz resultante se envía a los programas raíces de navegadores y dispositivos para su inclusión. Este proceso se diseñó para garantizar la comprensión total de la privacidad y la seguridad de las claves privadas asociadas, a fin de que las claves sean confiables durante una década o más.
Como se explicó anteriormente, las CA usan sus claves privadas para firmar certificados, y estos verifican identidades cuando se inicia un protocolo de enlace TLS como parte de la sesión de un usuario. Los certificados de servidores se firman con CA intermedias, cuya creación es similar a la de una CA raíz. Los certificados de la CA intermedia se distribuyen como parte de la sesión de TLS para que sea más fácil migrar a una nueva CA intermedia. Este método de distribución también permite que el operador de la CA mantenga el material de la clave de la CA raíz en estado sin conexión.
La seguridad de una sesión de TLS depende del nivel de protección de la clave del servidor. Para lograr una mayor mitigación del riesgo de vulnerabilidad de claves, los ciclos de vida de los certificados TLS de Google se limitan a alrededor de tres meses y se rotan aproximadamente cada dos semanas.
Un cliente que ya se conectó antes a un servidor puede usar una clave de ticket privada10 para reanudar una sesión previa con un protocolo de enlace TLS abreviado, lo que hace que estos tickets sean muy valiosos para los atacantes. Google rota las claves de tickets al menos una vez al día y se encarga de que las claves de todas las propiedades caduquen cada 3 días. Para obtener más información sobre la rotación de claves de tickets de sesión, consulta la página sobre cómo medir el peligro a la seguridad de los accesos directos criptográficos de TLS.
Google Front End a frontends de aplicaciones
En algunos casos, como se explicó en Cómo se enruta el tráfico, el usuario se conecta a un GFE dentro de un límite físico diferente del servicio deseado y del frontend de aplicaciones asociado. Cuando esto ocurre, la solicitud del usuario y cualquier otro protocolo de capa 7, como HTTP, recibe la protección de TLS o se encapsula en una RPC protegida mediante la seguridad de transporte de la capa de la aplicación (ALTS). Esto se explica en Autenticación, integridad y encriptación entre servicios. Estas RPC están autenticadas y encriptadas.
En el caso de los servicios de Google Cloud, las RPC se protegen usando ALTS. En el caso de las aplicaciones de cliente alojadas en Google Cloud, si el tráfico se enruta mediante el Google Front End (por ejemplo, si usan el balanceador de cargas de Google Cloud), el tráfico a la VM se protege mediante la encriptación de redes virtuales de Google Cloud, que se describe en la sección siguiente.
Encriptación y autenticación de redes virtuales de Google Cloud
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 Cloud se realiza en la capa de red.
Usamos el Estándar de encriptación avanzada (AES) en modo Galois/Counter (GCM) con una clave de 128 bits (AES-128-GCM) para implementar la encriptación en la capa de red. Cada par de hosts en comunicación establece una clave de sesión mediante un canal de control protegido por ALTS para comunicaciones autenticadas y encriptadas. La clave de sesión se usa para encriptar todas las comunicaciones de VM a VM entre esos hosts; las claves de sesión se rotan con regularidad.
En la capa de red (capa 3), la red virtual de Google Cloud autentica todo el tráfico entre las VM. Esta autenticación, que se realiza mediante tokens de seguridad, impide que un host vulnerado pueda falsificar la identidad de paquetes en la red.
Durante la autenticación, los tokens de seguridad se encapsulan en un encabezado de túnel que contiene la información de autenticación del emisor y del receptor. El plano de control11 del lado emisor define el token, mientras que el host receptor lo valida. Los tokens de seguridad se generan previamente para cada flujo y se componen de una clave de token (que contiene la información del emisor) y el secreto de host. Existe un secreto por cada par emisor-receptor de límites físicos controlados por Google o en su nombre.
La figura 4 muestra cómo se crean las claves de tokens, los secretos de host y los tokens de seguridad.
Figura 4: Tokens de seguridad
El secreto de límite físico es un número seudoaleatorio de 128 bits del cual derivan los secretos de host mediante un HMAC-SHA1. El secreto de límite físico se negocia a través de un protocolo de enlace entre los planos de control de red de un par de límites físicos y se vuelve a negociar cada cierta cantidad de horas. Los tokens de seguridad que se usan para la autenticación individual entre VM, que derivan de estas y otras entradas, son HMAC negociados para un par de emisor-receptor determinado.
Encriptación de máquina virtual a Google Front End
El tráfico de VM a GFE usa IP externas para llegar a los servicios de Google, pero es posible configurar el Acceso privado a fin de usar solo direcciones IP de Google para las solicitudes.
De forma predeterminada, admitimos el tráfico TLS desde una VM hasta GFE. La conexión se realiza del mismo modo que cualquier otra conexión externa. Para obtener más información sobre la TLS, consulta Seguridad de la capa de transporte (TLS).
Autenticación, integridad y encriptación entre servicios
En la infraestructura de Google, usamos nuestra Seguridad de transporte de la capa de la aplicación (ALTS) en la capa de la aplicación (7) para la autenticación, integridad y encriptación de las llamadas RPC de Google desde el GFE a un servicio y entre servicios.
La ALTS usa cuentas de servicio para la autenticación. Cada servicio que se ejecuta en la infraestructura de Google lo hace como una identidad de cuenta de servicio con credenciales criptográficas asociadas. Cuando se hacen RPC o se reciben de otros servicios, un servicio usa sus credenciales para autenticarse. La ALTS verifica estas credenciales mediante una autoridad certificada interna.
En un límite físico controlado por Google o en su nombre, la ALTS brinda integridad y autenticación de RPC en modo "integridad y autenticación". En el caso del tráfico por la WAN fuera de los límites físicos controlados por Google o en su nombre, la ALTS aplica automáticamente la encriptación para el tráfico de RPC de la infraestructura en modo "autenticación, integridad y privacidad". Actualmente, todo el tráfico hacia los servicios de Google, incluidos los servicios de Google Cloud, se benefician de esas mismas protecciones.
La ALTS también se usa para encapsular otros protocolos de la capa 7, como HTTP, en mecanismos de RPC de infraestructura para el tráfico que va desde el Google Front End hacia el frontend de la aplicación. Esta protección aísla la capa de la aplicación y quita todas las dependencias de la seguridad de la ruta de red.
Los servicios de infraestructura de seguridad aceptan y envían comunicaciones ALTS solo en el modo “autenticación, integridad y privacidad”, incluso en límites físicos controlados por Google o en su nombre. Un ejemplo es el Almacén de claves, que almacena y administra las claves de encriptación que se usan para proteger los datos almacenados en reposo en la infraestructura de Google.
Encriptación de red mediante PSP
El protocolo de seguridad de PSP (PSP) es independiente del transporte, 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, usamos PSP para encriptar 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. Usamos PSP para encriptar el tráfico dentro y entre nuestros centros de datos. PSP admite protocolos que no son de TCP, como UDP, y usa una clave de encriptación para cada conexión de capa 4.
Para obtener más información sobre cómo usamos PSP, consulta Anuncio de descarga de hardware criptográfico a gran escala de PSP ahora es de código abierto.
Protocolo ALTS
La ALTS tiene un protocolo de enlace seguro similar a la TLS mutua. Dos servicios que desean comunicarse usando la ALTS utilizan este protocolo de enlace para autenticarse y negociar los parámetros de comunicación antes de enviar cualquier información sensible. El protocolo es un proceso de dos pasos:
- Paso 1: Protocolo de enlace El cliente inicia un protocolo de enlace de curva elíptica de Diffie Hellman (ECDH) con el servidor mediante Curve25519. Tanto el cliente como el servidor tienen parámetros públicos ECDH certificados como parte de su certificado, que se usa durante un intercambio de claves Diffie Hellman. El protocolo de enlace da como resultado una clave de tráfico común que está disponible en el cliente y en el servidor. Las identidades de intercambio de tráfico de los certificados se envían a la capa de la aplicación para su uso en decisiones de autorización.
- Paso 2: Registro de la encriptación Mediante la clave de tráfico común del paso 1, los datos se transmiten del cliente al servidor de manera segura. La encriptación en ALTS se implementa mediante BoringSSL y otras bibliotecas de encriptación. La encriptación suele ser AES-128-GCM, mientras que el GMAC de AES-GCM proporciona la integridad.
En el siguiente diagrama se muestra el protocolo de enlace de ALTS con más detalle. En las implementaciones más recientes, un ayudante de procesos ejecuta el protocolo de enlace, pero existen casos en los que las aplicaciones lo hacen de forma directa.
Figura 5: Protocolo de enlace ALTS
Como se describió al principio de la sección Autenticación, integridad y encriptación entre servicios, la ALTS usa cuentas de servicio para la autenticación, con cada servicio que se ejecuta en la infraestructura de Google como una identidad de servicio con credenciales criptográficas asociadas. Durante el protocolo de enlace ALTS, el ayudante de procesos accede a las claves privadas y los certificados correspondientes que cada par cliente-servidor usa en sus comunicaciones. La clave privada y el certificado correspondiente (búfer de protocolo firmado) se aprovisionaron para la identidad de la cuenta de servicio del servicio.
Certificados ALTS Existen muchos tipos de certificados ALTS:
- Certificados de máquina: Proporcionan una identidad a los servicios principales en una máquina específica. Rotan cada 6 horas, aproximadamente.
- Certificados de usuario: Proporcionan una identidad de usuario final para un código de desarrollo de un ingeniero de Google. Rotan cada 20 horas, aproximadamente.
- Certificados de trabajos Borg: Proporcionan una identidad a los trabajos que se ejecutan en la infraestructura de Google. Rotan cada 48 horas, aproximadamente.
La clave de firma del certificado raíz se almacena en la autoridad certificada (CA) interna de Google, que no guarda ninguna relación con nuestra CA externa y es independiente de ella.
Encriptación en ALTS
La encriptación en ALTS puede implementarse mediante diversos algoritmos, dependiendo de las máquinas que se usan. Por ejemplo, la mayoría de los servicios usa AES-128-GCM12. Encontrarás más información sobre la encriptación ALTS en la tabla 2.
| Máquinas | Encriptación de mensajes usada | |
|---|---|---|
| Más común | AES-128-GCM | |
| Sandy Bridge o más antigua | AES-128-VCM | Usa una VMAC en vez de una GMAC y es levemente más eficiente en estas máquinas más antiguas. |
Tabla 2: Encriptación en ALTS
La mayoría de los servicios de Google usa ALTS o encapsulación de RPC que usa ALTS. Si no se usa ALTS, se emplean otras protecciones. Por ejemplo:
- Algunos servicios de inicialización y administración de máquinas de nivel bajo usan SSH
- Algunos servicios de registro de infraestructura de bajo nivel TLS o Datagram TLS (DTLS)13
- Algunos servicios que usan transporte no TCP utilizan otros protocolos criptográficos o protecciones a nivel de red cuando se encuentran en límites físicos controlados por Google o en su nombre
Las comunicaciones entre las VM y los servicios de Google Cloud Platform usan TLS en vez de ALTS para comunicarse con Google Front End. Estas comunicaciones se describen en Encriptación de máquinas virtuales a Google Front End.
Configura otras opciones de encriptación en las opciones de tránsito
Puedes configurar protecciones para tus datos cuando están en tránsito entre Google Cloud y tus centros de datos, o en tránsito entre tus aplicaciones alojadas en Google Cloud y los dispositivos de los usuarios.
Si conectas tu centro de datos a Google Cloud, ten en cuenta lo siguiente:
- Usa TLS con el balanceador de cargas de aplicaciones externo o el balanceador de cargas de red del proxy externo para conectarte a tu servicio de nube. GFE finaliza las conexiones TLS de los usuarios que usan certificados SSL que aprovisionas y controlas. Para obtener más información sobre cómo personalizar el certificado, consulta Descripción general de los certificados SSL.
- Crea un túnel IPSec con Cloud VPN o usa Cloud Interconnect para conectar de manera segura tu red local a tu red de nube privada virtual. Para obtener más información, consulta Elige un producto de Conectividad de red.
- Usa MACsec para Cloud Interconnect a fin de proteger el tráfico entre tu router local y los routers perimetrales de Google. Si deseas más información, consulta la descripción general de MACsec para Cloud Interconnect.
Si conectas tus dispositivos de usuario a las aplicaciones que se ejecutan en Google Cloud, ten en cuenta lo siguiente:
- Usa la compatibilidad de GFE con TLS mediante la configuración del certificado SSL que usas. Por ejemplo, puedes hacer que la sesión TLS finalice en tu aplicación.
- Considera nuestros certificados SSL gratuitos y automatizados, que están disponibles para los dominios personalizados de Firebase Hosting y App Engine. Con los dominios personalizados de App Engine, también puedes proporcionar tus propios certificados SSL y usar un encabezado de HTTP con Seguridad de Transporte Estricta (HSTS).
- Para las cargas de trabajo en GKE y Compute Engine, considera usar la malla de servicios de GKE Enterprise a fin de que puedas usar mTLS para la autenticación, lo que garantiza que todas las comunicaciones de TCP estén encriptadas en tránsito.
Si usas Google Workspace, configura Gmail para habilitar S/MIME en correos electrónicos salientes, configura políticas para el contenido y el cumplimiento de archivos adjuntos y crea reglas de enrutamiento para los correos electrónicos entrantes y salientes.
Innovación y estudios de la encriptación en tránsito
Con los años, participamos en varios proyectos de código abierto y otras iniciativas que fomentan el uso de la encriptación en tránsito en Internet.
Estos esfuerzos incluyen lo siguiente:
- El Certificado de transparencia (CT) es un esfuerzo que lanzamos para que los operadores de sitios y titulares de dominios puedan detectar si una CA emitió certificados incorrectos o no autorizados.
- Nuestro Informe de transparencia HTTPS anual hace un seguimiento de nuestro progreso hacia nuestra meta de encriptación del 100% en tránsito para todas nuestras propiedades, incluido Google Cloud.
- El desarrollo del algoritmo combinado de curva elíptica y poscuántica (CECPQ2), que ayuda a proteger las conexiones de TLS contra ataques informáticos cuánticos.
Para obtener más información sobre nuestras contribuciones recientes, consulta Colaboración con la comunidad de investigadores de seguridad.
¿Qué sigue?
- Para obtener información general sobre la seguridad de Google Cloud, incluidas las prácticas recomendadas de seguridad, consulta la sección Seguridad del sitio web de Google Cloud.
- Para obtener información sobre el cumplimiento y las certificaciones relacionadas de Google Cloud, consulta la sección Cumplimiento del sitio web de Google Cloud, que incluye el informe público de la auditoría SOC3 de Google.
- Para conocer prácticas recomendadas sobre cómo proteger los datos en tránsito, consulta el Plano de bases empresariales y el Framework de arquitectura de Google Cloud: Seguridad, privacidad y cumplimiento, y Decide cómo cumplir con los requisitos reglamentarios para la encriptación en tránsito.