En este documento se proporciona información sobre el cifrado en tránsito de Google Distributed Cloud (GDC) con air gap.
Resumen para directores de sistemas de información
- GDC cuenta con diversos sistemas de seguridad para preservar la autenticidad, la integridad y la confidencialidad de los datos en tránsito.
- En función del tipo de conexión establecida, GDC aplica una serie de protecciones predeterminadas a los datos en tránsito de los componentes de GDC. Por ejemplo, para proteger las comunicaciones entre los usuarios y la puerta de enlace de entrada de GDC Cloud Service Mesh, se utiliza el protocolo TLS.
Introducción
A la hora de decantarse por un proveedor de servicios en la nube, la seguridad suele ser un factor clave. Para nosotros, es de máxima importancia: Trabajamos constantemente para proteger tus datos, tanto cuando se transfieren por tu red como cuando circulan por la infraestructura de Google o se almacenan en nuestros servidores.
Los cimientos de nuestra estrategia de seguridad son la autenticación, la integridad y el cifrado de los datos, independientemente de si están en reposo o en tránsito. En este documento se describe nuestro enfoque del cifrado en tránsito para Google Distributed Cloud air-gapped (GDC).
Si te interesan más los datos en reposo, consulta el artículo Encriptado en reposo. O bien, si prefieres hacerte una idea general de cómo funcionan nuestros sistemas de seguridad, puedes leer la descripción general del diseño de la seguridad de la infraestructura de Google.
Audiencia: este documento está dirigido a los directores de seguridad de la información (o CISO) y a los equipos de operaciones de seguridad que estén utilizando o planteándose utilizar GDC.
Requisitos previos: además de leer esta introducción, se presupone que el lector tiene conocimientos básicos sobre el encriptado y las primitivas criptográficas.
Autenticación, integridad y cifrado
GDC cuenta con diversos sistemas de seguridad para preservar la autenticidad, la integridad y la confidencialidad de los datos en tránsito.
- Autenticación: autenticamos el destino de los datos en la capa de red. La fuente se autentica mediante AIS gestionado por GDC.
- Integridad: nos aseguramos de que los datos que envías llegan a su destino sin sufrir ningún cambio, es decir, protegidos contra modificaciones no autorizadas.
- Encriptado: tus datos serán ilegibles (y, por tanto, confidenciales) durante toda la fase de tránsito. El cifrado es el proceso mediante el cual los datos legibles (texto sin formato) se transforman en ininteligibles (texto cifrado), con el objetivo de asegurar que solo puedan acceder a ellos las partes autorizadas por el propietario de los datos. Los algoritmos que utilizamos en el proceso de encriptado son públicos, pero la clave usada para desencriptar los textos cifrados, no. Para encriptar datos en tránsito solemos utilizar claves simétricas compartidas. Para ello, recurrimos a un proceso llamado "intercambio de claves asimétricas", como es el caso del protocolo Diffie-Hellman, que está basado en curvas elípticas. Si quieres obtener más información sobre el cifrado, te recomendamos que consultes este recurso: Introduction to Modern Cryptography.
Puedes recurrir al cifrado para proteger datos mientras están en estos estados:
- El encriptado en reposo protege tus datos frente a intrusiones en el sistema o filtraciones externas, ya que se encriptan mientras están almacenados. El estándar que más se suele utilizar para encriptar datos de este tipo es el estándar de encriptado avanzado (AES, por sus siglas en inglés).
- Encriptado en tránsito: protege tus datos si se intercepta algún tipo de comunicación mientras se transfieren datos entre tu sitio web y el proveedor de servicios en la nube, o entre dos servicios. Para proteger dichos datos, se encriptan antes de que tenga lugar la transmisión. A continuación, se autentican los endpoints y, por último, se descifran y se verifica que los datos no se han modificado cuando llegan a su destino. Por ejemplo, se utiliza el protocolo de seguridad en la capa de transporte (TLS) para preservar la seguridad de los datos mientras se transportan, y las extensiones seguras multipropósito de correo de Internet (S/MIME) sirven para cifrar los correos electrónicos.
El encriptado debe entenderse como un elemento más de los que componen cualquier estrategia de seguridad más amplia. Al implementar este proceso en los datos en tránsito, es posible protegerlos frente a atacantes potenciales en el momento en el que se establece y autentica una conexión. Gracias al encriptado, se consigue lo siguiente:
- Evitar tener que depender de las capas inferiores de la red, que habitualmente suministran terceros.
- Reducir la superficie de posibles ataques.
- Impedir que los atacantes puedan acceder a los datos, en caso de que se interceptaran las comunicaciones.
Para proteger los datos que circulan entre usuarios, dispositivos o procesos en entornos hostiles, te recomendamos poner en marcha las estrategias de autenticación, integridad y encriptado más adecuadas. En el resto de este documento te explicaremos en qué consiste nuestro sistema de encriptado de datos en tránsito y en qué casos se implementa.
Infraestructura de red de GDC
Límites físicos
Cuando hablamos de "límites físicos", nos referimos a la frontera del espacio físico que conforma dicha red. En este espacio, sabemos con total seguridad que se están aplicando unas medidas de seguridad más que estrictas. El acceso físico a dichas ubicaciones está restringido, monitorizado de cerca y auditado. Solo un pequeño grupo de personal autorizado tiene acceso al hardware. Los datos en tránsito que circulan dentro de estos límites físicos suelen estar autenticados y cifrados.
En las comunicaciones que entran o salen del límite físico del GDC, utilizamos una autenticación y un cifrado sólidos para proteger los datos en tránsito.
¿Cómo se enruta el tráfico?
Para entender cómo funciona el cifrado en tránsito en GDC, es necesario explicar cómo se enruta el tráfico hacia y a través de GDC. En esta sección, descubrirás cómo se transfieren las solicitudes de los usuarios finales al servicio de GDC o la aplicación de cliente correspondiente y cómo se enruta el tráfico entre servicios de diferentes sitios.
Un servicio gestionado por GDC es un servicio modular de nube privada. Estos servicios incluyen computación, almacenamiento y aprendizaje automático. Por ejemplo, el almacenamiento de objetos de GDC es un servicio gestionado por GDC. Una aplicación de cliente es una aplicación alojada en GDC que puedes crear y desplegar mediante los servicios de GDC. Las aplicaciones de clientes o soluciones de partners que estén alojadas en GDC no se considerarán servicios gestionados por GDC. Por ejemplo, una aplicación que crees con máquinas virtuales de GDC, Database Service y Vertex AI es una aplicación de cliente.
En la figura 1 se muestran diferentes tipos de solicitudes de enrutamiento. En la figura 1 se muestran las interacciones entre los distintos componentes de la red y las medidas de seguridad aplicadas a cada conexión.
Imagen 1: Infraestructura de conectividad entre sitios
Entre el usuario final (red del cliente) y la API de GDC y el servicio gestionado
En el caso de los servicios gestionados alojados en las pasarelas de entrada de Cloud Service Mesh, aceptan solicitudes de la red del cliente mediante la pasarela de entrada de Cloud Service Mesh. Cloud Service Mesh Ingress Gateway dirige el tráfico de proxy de las solicitudes HTTP y HTTPS entrantes, y enruta y equilibra la carga del tráfico que reciben los propios servicios gestionados por GDC. Otra capa de cortafuegos proporciona contramedidas contra ataques DDoS con detección y prevención de intrusiones. Esta conexión se autentica y encripta desde la pasarela de entrada de Cloud Service Mesh hasta el frontend del servicio gestionado por GDC. En la figura 1 se muestra esta interacción como conexión A.
La mayoría de las APIs y los servicios gestionados de GDC se alojan en pasarelas de entrada de Cloud Service Mesh. Sin embargo, algunos servicios se alojan directamente en el balanceador de carga de capa 4 gestionado por GDC. Por ejemplo, las bases de datos de DBS se alojan en un balanceador de carga externo de GDC. Estos servicios están configurados para autenticar y cifrar las conexiones en la capa de aplicación mediante TLS. En la figura 1 se muestra esta interacción como conexión B.
Entre el usuario final (red del cliente) y una aplicación de cliente alojada en GDC
Hay varias formas de enrutar el tráfico de la red del cliente a una aplicación del cliente alojada en GDC. La forma en que se enruta el tráfico depende de tu configuración.
Exponer aplicaciones de clientes a través de la API Gateway del cliente
GDC permite exponer aplicaciones de clientes a través de la API Gateway del cliente. El servicio API Gateway permite a los clientes desarrollar, desplegar, proteger, gestionar y escalar la API según sea necesario. En la figura 1 se muestra esta interacción como conexión C.
Exponer cargas de trabajo de clientes en contenedores a través de un balanceador de carga externo de clientes
GDC permite exponer cargas de trabajo en contenedores gestionadas por el cliente a través de un balanceador de carga externo. GDC ofrece la posibilidad de configurar políticas de entrada y salida para el personal correspondiente. En la figura 1 se muestra esta interacción como conexión E.
Exponer cargas de trabajo de máquinas virtuales
GDC permite exponer las máquinas virtuales creadas por los clientes a los usuarios finales. GDC ofrece la posibilidad de configurar políticas de entrada y salida para el personal correspondiente. En la figura 1 se muestra esta interacción como conexión F.
Servicio de interconexión entre sitios de GDC
El enrutamiento de un servicio gestionado a otro suele producirse por completo dentro de los límites físicos del GDC. En algunos casos, como las copias de seguridad entre sitios, los datos se enrutan fuera del límite físico del GDC. En ese caso, los datos se cifran tanto en la capa de aplicación (por ejemplo, TLS) como en la capa de red. En la figura 1 se muestra esta interacción como conexión G.
De máquina virtual a máquina virtual
Las conexiones entre máquinas virtuales dentro de los centros de datos de Google no están encriptadas a nivel de red. Los clientes son responsables de cifrar los datos mediante protocolos cifrados adecuados o tecnologías específicas, como los túneles IPSec.
Encriptado en tránsito de forma predeterminada
GDC usa varios métodos de encriptado, tanto predeterminados como personalizables, para los datos en tránsito. El tipo de cifrado utilizado depende de la capa OSI, el tipo de servicio y el componente físico de la infraestructura. En esta sección se describen las protecciones predeterminadas que usamos en Google para proteger los datos en tránsito.
En el resto de esta sección se describen las protecciones predeterminadas que usamos en Google para proteger los datos en tránsito.
Encriptado entre el usuario y la pasarela de entrada de Cloud Service Mesh
En muchos sistemas actuales se usa el protocolo HTTPS para las comunicaciones a través de Internet. HTTPS utiliza una conexión TLS para ofrecer un sistema seguro, lo que a su vez garantiza la autenticidad, integridad y confidencialidad de las solicitudes y respuestas. Para aceptar solicitudes HTTPS, el receptor necesita un par de claves pública/privada y un certificado X.509, emitido por una autoridad de certificación (CA), para autenticar el servidor. El par de claves y el certificado ayudan a autenticar las solicitudes de un usuario en la capa de aplicación (capa 7) al demostrar que el receptor es propietario del nombre de dominio para el que están destinadas las solicitudes. En las siguientes subsecciones se abordan los componentes del cifrado desde el usuario a la puerta de enlace de entrada de Cloud Service Mesh: TLS, BoringSSL y la autoridad de certificación configurable de GDC.
Seguridad en la capa de transporte (TLS)
Cuando envías una solicitud a un servicio de GDC, protegemos los datos en tránsito y ofrecemos autenticación, integridad y cifrado mediante el protocolo HTTPS con un certificado de una autoridad de certificación de confianza. Todos los datos que el usuario envía a la puerta de enlace de entrada de Cloud Service Mesh para el servicio gestionado por GDC se cifran en tránsito con el protocolo Seguridad en la capa de transporte (TLS). Cloud Service Mesh Ingress Gateway negocia un protocolo de cifrado concreto con el cliente según su compatibilidad. La pasarela de entrada de malla de servicios de GDC Cloud solo aplica algoritmos aprobados por FIPS para ofrecer una mayor seguridad.
BoringSSL
BoringSSL es una implementación de software libre del protocolo TLS mantenida por Google y cuya interfaz es altamente compatible con OpenSSL. Google creó BoringSSL a partir de OpenSSL para simplificar este último, tanto para uso interno como para ofrecer una mejor compatibilidad con los Proyectos de Software Libre de Android y Chromium. BoringCrypto, el núcleo de BoringSSL, se ha validado según el estándar FIPS 140-2 de nivel 1.
TLS se implementa en la puerta de enlace de entrada de Cloud Service Mesh mediante BoringSSL. En la tabla 1 se muestran los protocolos de cifrado que admite GDC al comunicarse con los clientes.
| Protocolos | Autenticación | Intercambio de claves | Encriptado | Funciones 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 |
Tabla 1: Encriptado implementado en la puerta de enlace de entrada de Cloud Service Mesh para los servicios de GDC y en la biblioteca criptográfica de BoringSSL
Autoridad de certificación configurable de GDC
Como parte de TLS, los servidores tienen que demostrar su identidad al usuario al recibir una solicitud de conexión, por lo que deben presentar un certificado con la identidad que reclaman. El certificado contiene el nombre de host DNS del servidor y su clave pública. Una vez presentado, el certificado lo firma una autoridad de certificación (CA) emisora en la que confía el usuario que solicita la conexión. Como resultado, los usuarios que solicitan las conexiones al servidor solo tienen que confiar en la CA raíz. Si el servidor requiere un acceso ubicuo, los dispositivos del cliente deben conocer la CA raíz. Los navegadores y dispositivos de los clientes se configuran con un conjunto de CAs raíz en las que confían, en función del entorno en el que opere el cliente.
La CA raíz de GDC depende del entorno en el que se implemente y de los requisitos de los clientes de ese entorno.
Cloud Service Mesh Ingress Gateway a los front-ends de las aplicaciones
Dos casos:
- Cloud Service Mesh Ingress Gateway finaliza TLS y vuelve a cifrar mTLS con certificados de Istio de Cloud Service Mesh.
- mTLS de la pasarela de entrada al frontend de la aplicación Sidecar de Istio
- Cloud Service Mesh Ingress Gateway finaliza TLS, vuelve a cifrar TLS en otro servidor con la CA configurada.
Cifrado de red del tráfico de almacenamiento
En el sistema de almacenamiento de archivos y en bloques de GDC, el tráfico se dirige entre la aplicación que usa el almacenamiento y el servicio de almacenamiento. Esos datos se autentican y se cifran en tránsito mediante IPSec. El cifrado del lado del cliente para el tráfico de almacenamiento estará disponible próximamente. El modo de transporte de IPSec se usa entre el tráfico de archivos y de bloques al host que necesita acceder al almacenamiento. La autenticación se realiza mediante una clave precompartida que se genera durante el vuelo y se almacena de forma segura en GDC. Una vez que se han establecido las asociaciones de seguridad de IPSec, la información se intercambia mediante el túnel IPSec. Los paquetes se cifran y descifran mediante el cifrado criptográfico compatible con FIPS especificado en la SA de IPSec.
Autenticación, integridad y encriptado entre servicios
En la capa de aplicaciones (capa 7) de la infraestructura de GDC, usamos mTLS o TLS para la autenticación, la integridad y el cifrado de las llamadas RPC desde la puerta de enlace de entrada de Cloud Service Mesh a un servicio y de un servicio de GDC a otro. Cada servicio que se ejecuta en GDC lo hace como una identidad de cuenta de servicio con credenciales criptográficas asociadas. Cuando se comunican a través de mTLS mediante Cloud Service Mesh, los servicios de GDC usan certificados de cliente para autenticarse en otros servicios. Cloud Service Mesh verifica estos certificados mediante una autoridad de certificación interna. Cuando se comunican a través de TLS, por ejemplo, con un servidor de la API de Kubernetes de GDC, los servicios de GDC usan tokens de cuentas de servicio de Kubernetes para autenticarse en los servicios. Los tokens de las cuentas de servicio de Kubernetes se verifican mediante las claves públicas del emisor de tokens del servidor de la API de Kubernetes.