En este documento, se proporcionan detalles sobre el tránsito de encriptación aislado de Google Distributed Cloud (GDC).
Resumen para directores generales de información
- GDC emplea varias medidas de seguridad para garantizar la autenticidad, la integridad y la confidencialidad de los datos en tránsito.
- Según la conexión que se realice, GDC aplica las protecciones predeterminadas a los datos en tránsito para los componentes de GDC. Por ejemplo, protegemos las comunicaciones entre el usuario y la puerta de enlace de entrada de GDC Cloud Service Mesh con TLS.
Introducción
La seguridad suele ser un factor decisivo al momento de elegir un proveedor de servicios en la nube. 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 tu red, se trasladen dentro de la infraestructura de Google o se almacenen 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 nuestro enfoque respecto a la encriptación en tránsito de Google Distributed Cloud aislado (GDC).
Para obtener información sobre los datos en reposo, consulta Encriptación en reposo. 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 a los directores de seguridad de la información que usan o piensan usar GDC.
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
GDC emplea varias medidas de seguridad para garantizar 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 con la AIS administrada por GDC.
- Integridad: Nos aseguramos de que los datos que envíes lleguen intactos a su destino, es decir, protegidos contra cambios no autorizados.
- Encriptación: Para mantener la confidencialidad 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 simple. 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.
La encriptación se puede usar para proteger los datos en varios 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 no 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.
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:
- Elimina 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 el resto de este documento, se explica el enfoque de GDC respecto a la encriptación de datos en tránsito y dónde se aplica.
Infraestructura de red de GDC
Límites físicos
Un límite físico es la barrera de un espacio físico controlado por Google o en coordinación con Google, donde podemos garantizar el uso de medidas de seguridad estrictas. El acceso físico a estas ubicaciones es restringido, se supervisa exhaustivamente y se audita. Solo un pequeño grupo de personal aprobado tiene acceso al hardware. En general, se autentican y encriptan los datos en tránsito dentro de estos límites físicos.
Para la comunicación que entra o sale del límite físico del GDC, empleamos una autenticación y encriptación sólidas para proteger los datos en tránsito.
Cómo se enruta el tráfico
Para comprender cómo funciona la encriptación en tránsito en GDC, es necesario explicar cómo se enruta el tráfico hacia GDC y a través de ella. En esta sección, se describe cómo las solicitudes van desde un usuario final hasta el servicio de GDC o la aplicación del cliente correspondientes, y cómo se enruta el tráfico entre los servicios de varios sitios.
Un servicio administrado por GDC es un servicio de nube privada modular. Estos servicios incluyen procesamiento, almacenamiento y aprendizaje automático. Por ejemplo, el almacenamiento de objetos de GDC es un servicio administrado por GDC. Una aplicación de cliente es una aplicación alojada en GDC que tú, como cliente de GDC, puedes compilar y también implementar con los servicios de GDC. Las aplicaciones de clientes o soluciones de socios alojadas en GDC no se consideran servicios administrados por GDC. Por ejemplo, una aplicación que compilas con VMs 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 diversos componentes de red y la seguridad aplicada a cada conexión.
Figura 1: Infraestructura de conectividad entre sitios
Del usuario final (red del cliente) a la API y el servicio administrado de GDC
En el caso de los servicios administrados alojados en las puertas de enlace de entrada de Cloud Service Mesh, estos aceptan solicitudes de la red del cliente a través de la puerta de enlace de entrada de Cloud Service Mesh. El proxy de la puerta de enlace de entrada de Cloud Service Mesh reenvía el tráfico de HTTP(S) entrante, y enruta y balancea las cargas del tráfico a los servicios administrados por GDC. Otra capa de firewall proporciona contramedidas para aplacar los ataques de DSD con detección y prevención de intrusiones. Esta conexión se autentica y encripta desde la puerta de enlace de entrada de Cloud Service Mesh hasta el frontend del servicio administrado por GDC. La figura 1 muestra esta interacción como conexión A.
La mayoría de las APIs y los servicios administrados de GDC se alojan en las puertas de enlace de entrada de Cloud Service Mesh. Sin embargo, algunos servicios se alojan directamente en el balanceador de cargas de capa 4 administrado por GDC. Por ejemplo, las bases de datos de DBS se alojan en un balanceador de cargas externo de GDC. Estos servicios están configurados para autenticar y encriptar conexiones en la capa de aplicación con TLS. La Figura 1 muestra esta interacción como conexión B.
Del usuario final (red del cliente) a una aplicación del cliente alojada en GDC
Existen varias formas de enrutar el tráfico desde la red del cliente a una aplicación del cliente alojada en GDC. La forma en que se enruta tu tráfico depende de tu configuración.
Exponer aplicaciones de clientes a través de la puerta de enlace de API del cliente
GDC admite la exposición de aplicaciones del cliente a través de la puerta de enlace de API del cliente. El servicio de API Gateway del cliente permite a los usuarios desarrollar, implementar, proteger, administrar y escalar la API según sea necesario. La Figura 1 muestra esta interacción como conexión C.
Expón cargas de trabajo de clientes en contenedores a través del balanceador de cargas externo del cliente
GDC admite la exposición de cargas de trabajo en contenedores que administra el cliente a través de un balanceador de cargas externo. GDC proporciona la capacidad de configurar políticas de entrada y salida para el personal correspondiente. La figura 1 muestra esta interacción como conexión E.
Expón cargas de trabajo de máquina virtual
GDC admite la exposición de máquinas virtuales creadas por el cliente a los usuarios finales. GDC proporciona la capacidad de configurar políticas de entrada y salida para el personal correspondiente. La Figura 1 muestra esta interacción como conexión F.
Servicio de interconexión entre sitios de GDC
El enrutamiento de un servicio administrado a otro suele ocurrir por completo dentro del límite físico del GDC. En algunos casos, como la copia de seguridad entre sitios, los datos se enrutan fuera del límite físico del GDC. En ese caso, los datos se encriptan en la capa de aplicación (por ejemplo, TLS) y también en la capa de red. La figura 1 muestra esta interacción como conexión G.
Entre máquina virtual
Las conexiones de VM a VM dentro de GDC no se encriptan a nivel de la red. Los clientes son responsables de encriptar los datos con protocolos encriptados adecuados o tecnologías específicas, como los túneles IPSec.
Encriptación en tránsito predeterminada
GDC 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. En esta sección, se describen las protecciones predeterminadas que Google usa para proteger los datos en tránsito.
En el resto de esta sección, se describen las protecciones predeterminadas que Google usa para proteger los datos en tránsito.
Encriptación de usuario a puerta de enlace de entrada de Cloud Service Mesh
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 confidencialidad 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 autenticar 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. En las siguientes subsecciones, se abordan los componentes de la encriptación entre el usuario y la puerta de enlace de entrada de Cloud Service Mesh, es decir: TLS, BoringSSL y la autoridad certificada configurable de GDC.
Seguridad de la capa de transporte (TLS)
Cuando envías una solicitud a un servicio de GDC, protegemos los datos en tránsito con autenticación, integridad y encriptación a través de HTTPS con un certificado de una autoridad certificadora de confianza. Todos los datos que el usuario envía a la puerta de enlace de entrada de Cloud Service Mesh para el servicio administrado por GDC se encriptan en tránsito con seguridad de la capa de transporte (TLS). Cloud Service Mesh Ingress Gateway negocia un protocolo de encriptación determinado con el cliente en función de lo que el cliente puede admitir. La puerta de enlace de entrada de GDC Cloud Service Mesh solo aplica algoritmos aprobados por FIPS para brindar mayor seguridad.
BoringSSL
BoringSSL es una implementación de código abierto del protocolo TLS que mantiene Google. 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.
TLS en la puerta de enlace de entrada de Cloud Service Mesh se implementa con BoringSSL. En la tabla 1, se muestran los protocolos de encriptación que admite GDC cuando 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 |
Tabla 1: Encriptación implementada en la puerta de enlace de entrada de Cloud Service Mesh para los servicios de GDC y también implementada en la biblioteca criptográfica BoringSSL
Autoridad certificadora configurable de GDC
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 certificada (CA) emisora, que es de confianza para el usuario que solicita la conexión. Como resultado, los usuarios que solicitan conexiones al servidor solo necesitan confiar en la CA raíz. Si el servidor desea otorgar acceso universal, cualquier dispositivo cliente potencial debe conocer la CA raíz. Los navegadores y dispositivos del cliente se configuran con un conjunto de CA raíz en las que confían, según el entorno en el que opera el cliente.
La CA raíz de GDC depende del entorno en el que se implementa y de los requisitos de los clientes en ese entorno.
Puerta de enlace de entrada de Cloud Service Mesh para front-ends de aplicaciones
Hay dos casos:
- La puerta de enlace de entrada de Cloud Service Mesh finaliza TLS y vuelve a encriptar mTLS con certificados de Istio de Cloud Service Mesh.
- mTLS desde la puerta de enlace de entrada hasta el frontend de la aplicación de sidecar de Istio
- La puerta de enlace de entrada de Cloud Service Mesh finaliza TLS y vuelve a encriptar TLS en algún otro servidor con la CA configurada.
Encriptación de red del tráfico de almacenamiento
En el sistema de almacenamiento de archivos y bloques de GDC, el tráfico se enruta entre la aplicación que usa el almacenamiento y el servicio de almacenamiento. Esos datos se autentican y encriptan en tránsito con IPSec. La encriptación del cliente para el tráfico de almacenamiento estará disponible pronto. El modo de transporte de IPSec se usa entre el tráfico de archivos y bloques hacia el host que necesita acceder al almacenamiento. La autenticación se realiza con una clave precompartida que se genera durante el vuelo y se almacena de forma segura en GDC. Una vez que se establecen las SA de IPsec, la información se intercambia a través del túnel de IPsec. Los paquetes se encriptan y desencriptan con la criptografía de encriptación compatible con FIPS especificada en la SA de IPsec.
Autenticación, integridad y encriptación entre servicios
En la infraestructura de GDC, en la capa de aplicación (capa 7), usamos mTLS o TLS para la autenticación, la integridad y la encriptación de las llamadas de RPC desde la puerta de enlace de entrada de Cloud Service Mesh a un servicio y de un servicio de GDC a otro servicio de GDC. 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 con Cloud Service Mesh, los servicios de GDC usan certificados de cliente para autenticarse en otros servicios. Cloud Service Mesh verifica estos certificados con una autoridad certificadora 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 la cuenta de servicio de Kubernetes se verifican con las claves públicas del emisor del token del servidor de la API de Kubernetes.