En este documento, se proporcionan detalles sobre la encriptación en tránsito de Google Distributed Cloud (GDC) aislado.
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 establezca, GDC aplica 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 Cloud Service Mesh de GDC con TLS.
Introducción
La seguridad suele ser un factor decisivo a la hora 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 se trasladen por tu red, se muevan dentro de la infraestructura de Google o se almacenen en nuestros servidores.
Una estrategia fundamental de seguridad de Google es la autenticación, la integridad y la encriptación de los datos que están en reposo y en tránsito. En este documento, se describe nuestro enfoque respecto a la encriptación en tránsito para Google Distributed Cloud aislado (GDC).
Para 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 CISO y a los equipos de operaciones de seguridad que usan o consideran 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 el AIS administrado por GDC.
- Integridad: Nos aseguramos de que los datos que envíes lleguen intactos a su destino, es decir, que estén 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) para 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 que se requiere para desencriptar el texto cifrado es privada. La encriptación en tránsito suele usar el intercambio de claves asimétricas, como Diffie-Hellman basado en curvas elípticas, para establecer una clave simétrica compartida que se usa para la encriptación de datos. Para obtener más información sobre la encriptación, consulta Introducción a la criptografía moderna.
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 usando 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 que se establece y autentica 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, que se suelen proporcionar mediante terceros.
- Reducción de la superficie de ataque potencial
- Impide que los atacantes accedan a los datos si se interceptan las comunicaciones.
Con la autenticación, la integridad y la encriptación adecuadas, los datos que viajan entre usuarios, dispositivos o procesos se pueden proteger en un entorno hostil. En el resto de este documento, se explica el enfoque de GDC para 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 cruza dentro o fuera del límite físico de GDC, empleamos una autenticación y una 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 este. En esta sección, se describe cómo las solicitudes llegan de un usuario final al servicio de GDC o a la aplicación del cliente adecuados, 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 creas con las VMs de GDC, el servicio de base de datos 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 red y la seguridad implementada para cada conexión.
Figura 1: Infraestructura de conectividad entre sitios
Del usuario final (red del cliente) a la API de GDC y al servicio administrado
En el caso de los servicios administrados alojados en puertas de enlace de entrada de Cloud Service Mesh, aceptan solicitudes de la red del cliente con la puerta de enlace de entrada de Cloud Service Mesh. La puerta de enlace de entrada de Cloud Service Mesh envía el tráfico de proxy para el tráfico 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 los ataques 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. En la figura 1, se muestra esta interacción como la 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 las conexiones en la capa de aplicación con TLS. En la figura 1, se muestra esta interacción como la conexión B.
Del usuario final (red del cliente) a una aplicación de cliente alojada en GDC
Existen 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 tu tráfico depende de tu configuración.
Exponer las aplicaciones del cliente a través de su API Gateway
GDC admite la exposición de aplicaciones de clientes a través de la API Gateway del cliente. El servicio de API Gateway del cliente permite que los usuarios desarrollen, implementen, protejan, administren y escalen la API según sea necesario. En la figura 1, se muestra esta interacción como la conexión C.
Exponer las cargas de trabajo de los clientes en contenedores a través del balanceador de cargas externo de los clientes
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. En la figura 1, se muestra esta interacción como la conexión E.
Expón cargas de trabajo de máquina virtual
GDC admite exponer las 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. En la figura 1, se muestra esta interacción como la 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 de GDC. En algunos casos, como la copia de seguridad entre sitios, los datos se enrutan fuera del límite físico de GDC. En ese caso, los datos se encriptan en la capa de aplicación, por ejemplo, TLS, y también se pueden encriptar en la capa de red. En la Figura 1, se muestra esta interacción como la 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 los protocolos encriptados adecuados o tecnologías específicas, como los túneles IPSec.
Encriptación en tránsito de forma predeterminada
GDC usa varios métodos de encriptación, tanto predeterminados como configurables por el usuario, para los datos en tránsito. El tipo de encriptación que se usa depende de la capa de OSI, el tipo de servicio y el componente físico de la infraestructura. En esta sección, se describen las protecciones predeterminadas que usa Google para proteger los datos en tránsito.
En el resto de esta sección, se describen las protecciones predeterminadas que usa Google 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, que garantiza la autenticidad, integridad y confidencialidad de las solicitudes y respuestas. Para aceptar solicitudes HTTPS, el receptor requiere un par de claves pública y privada, y un certificado X.509 para la autenticación del servidor de una autoridad certificadora (AC). El par de claves y el certificado ayudan a autenticar las solicitudes de un usuario en la capa de aplicación (capa 7) demostrando que el receptor es el propietario del nombre de dominio al que se dirigen las solicitudes. En las siguientes subsecciones, se analizan los componentes de la encriptación del usuario a la puerta de enlace de entrada de Cloud Service Mesh, es decir, TLS, BoringSSL y la autoridad certificadora 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, lo que proporciona autenticación, integridad y encriptación, con HTTPS y 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 la seguridad de la capa de transporte (TLS). La puerta de enlace de entrada de Cloud Service Mesh negocia un protocolo de encriptación específico con el cliente según lo que este pueda admitir. La puerta de enlace de entrada de GDC Cloud Service Mesh aplica solo algoritmos aprobados por los FIPS para proporcionar una seguridad más sólida.
BoringSSL
BoringSSL es una implementación de código abierto del protocolo TLS que mantiene Google, bifurcada de OpenSSL, que es, en su mayoría, compatible con la interfaz de OpenSSL. Google bifurcó BoringSSL de OpenSSL para simplificar OpenSSL, tanto para uso interno como para brindar una mejor asistencia a los proyectos de código abierto de Chromium y Android. BoringCrypto, el núcleo de BoringSSL, se validó con FIPS 140-2 nivel 1.
La 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 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 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 haciendo que el servidor presente un certificado que contenga su identidad declarada. 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ón. Como resultado, los usuarios que solicitan conexiones al servidor solo necesitan confiar en la CA raíz. Si se quiere acceder al servidor de forma ubicua, la CA raíz debe ser conocida por cualquier dispositivo cliente potencial. Los navegadores y dispositivos de los clientes se configuran con un conjunto de AC raíz en las que confían, según el entorno en el que opera el cliente.
La AC 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 a los frontends de la aplicación
Dos casos:
- La puerta de enlace de entrada de Cloud Service Mesh finaliza la TLS y vuelve a encriptar la mTLS con los 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 la TLS y vuelve a encriptarla 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 en bloque 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 sobre la marcha 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 que cumple con los FIPS especificada en la SA de IPsec.
Autenticación, integridad y encriptación entre servicios
Dentro de 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. Cada servicio que se ejecuta en GDC se ejecuta 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 cuenta de servicio de Kubernetes se verifican con las claves públicas de la entidad emisora de tokens del servidor de la API de Kubernetes.