En este documento se ofrece información detallada sobre el encriptado en tránsito de Google Distributed Cloud (GDC) en entornos aislados.
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 de la conexión que se establezca, GDC aplica 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 Cloud Service Mesh de GDC, se utiliza el protocolo TLS.
Introducción
La seguridad suele ser un factor decisivo a la hora de elegir un proveedor de servicios en la nube. Para nosotros, es de máxima importancia: trabajamos sin descanso para proteger tus datos, tanto si se transfieren por tu red como si se mueven dentro de 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 encriptado de los datos, independientemente de si están en reposo o en tránsito. En esta publicación, describimos nuestro enfoque de cifrado en tránsito para Google Distributed Cloud aislado (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 en Descripción general del diseño de la seguridad de la infraestructura de Google.
Público: este documento está dirigido a directores de seguridad de la información y a equipos de operaciones de seguridad que usen o estén pensando en usar 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 encriptado
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 el sistema de identidad de acceso (AIS) gestionado por GDC.
- Integridad: nos aseguramos de que los datos llegan a su destino sin sufrir ningún cambio, es decir, protegidos frente a modificaciones no autorizadas.
- Encriptado: hacemos que tus datos sean ilegibles mientras están en tránsito para mantener su confidencialidad. Al utilizar el encriptado, los datos legibles (texto sin formato) se transforman en ininteligibles (texto cifrado), con lo que nos aseguramos de que solo pueden acceder a ellos los usuarios que haya autorizado el propietario. 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. Para obtener más información sobre el encriptado, consulta el artículo Introducción a la criptografía moderna.
El encriptado se puede usar para proteger los datos en varios estados:
- Encriptado en reposo: los datos se protegen frente a intrusiones en el sistema y filtraciones externas, ya que se encriptan mientras están almacenados. El estándar de cifrado avanzado (AES) se suele utilizar para cifrar datos en reposo.
- Encriptado en tránsito: tiene lugar 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. Esta protección se consigue encriptando los datos antes de la transmisión, autenticando los endpoints y, al llegar, desencriptando y verificando que los datos no se hayan modificado. Por ejemplo, se utiliza el protocolo de seguridad en la capa de transporte (TLS) para cifrar datos en tránsito para la seguridad del transporte, y las extensiones seguras multipropósito de correo de Internet (S/MIME) se utilizan a menudo para el cifrado de mensajes de correo electrónico.
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 posibles atacantes en el momento en el que se establece y autentica una conexión. Gracias al encriptado, se consigue lo siguiente:
- Eliminar la necesidad de confiar en las capas inferiores de la red, que suelen proporcionar terceros.
- Reducir la superficie de ataques potenciales.
- 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 esta publicación se explica el enfoque de GDC en cuanto al cifrado de datos en tránsito y dónde se aplica.
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 estas ubicaciones está restringido, muy supervisado y auditado. Solo un pequeño grupo de personal autorizado tiene acceso al hardware. Los datos en tránsito que se encuentran dentro de estos límites físicos suelen estar autenticados y encriptados.
Para las comunicaciones que entran o salen del límite físico de GDC, utilizamos un sistema de autenticación y encriptado sólido para proteger los datos en tránsito.
¿Cómo se enruta el tráfico?
Para entender cómo funciona el encriptado 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 se describe cómo llegan las solicitudes 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 diferentes sitios.
Un servicio gestionado por GDC es un servicio de nube privada modular. 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 del cliente es una aplicación alojada en GDC que tú, como cliente de GDC, puedes crear e implementar con los servicios de GDC. Las aplicaciones del cliente o las soluciones de partners que se alojan en GDC no se consideran servicios gestionados por GDC. Por ejemplo, una aplicación que crees con las máquinas virtuales de GDC, el servicio de bases de datos y Vertex AI es una aplicación del 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 la seguridad que se aplica a cada conexión.
Figura 1: Infraestructura de conectividad entre sitios
Usuario final (red del cliente) a la API y al servicio gestionado de GDC
En el caso de los servicios gestionados alojados en las puertas de enlace de entrada de Cloud Service Mesh, estos aceptan solicitudes de la red del cliente mediante la puerta de enlace de entrada de Cloud Service Mesh. La puerta de enlace de entrada de Cloud Service Mesh dirige el tráfico de proxy para HTTP(S) entrante, y enruta y equilibra la carga de tráfico que reciben los propios servicios gestionados por GDC. Otra capa de firewall proporciona medidas de respuesta a los ataques DDoS 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 gestionado por GDC. En la figura 1, esta interacción se muestra como la conexión A.
La mayoría de las APIs y los servicios gestionados de GDC se alojan en las puertas de enlace de entrada de Cloud Service Mesh. Sin embargo, algunos servicios se alojan directamente en el equilibrador de carga de capa 4 gestionado por GDC. Por ejemplo, las bases de datos de DBS se alojan en un equilibrador de carga externo de GDC. Estos servicios están configurados para autenticar y encriptar las conexiones en la capa de aplicación mediante TLS. En la figura 1, esta interacción se muestra como la conexión B.
Usuario final (red del cliente) a una aplicación del cliente alojada en GDC
Hay 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 el tráfico depende de tu configuración.
Exponer aplicaciones del cliente a través de la puerta de enlace de APIs del cliente
GDC permite exponer aplicaciones del cliente a través de la puerta de enlace de APIs del cliente. El servicio de API Gateway del cliente permite a los usuarios desarrollar, implementar, proteger, gestionar y escalar la API según sea necesario. En la figura 1, esta interacción se muestra como la conexión C.
Exponer cargas de trabajo del cliente en contenedores a través del equilibrador de carga externo del cliente
GDC permite exponer cargas de trabajo en contenedores gestionadas por el cliente a través de un equilibrador de carga externo. GDC ofrece la posibilidad de configurar políticas de entrada y salida para el personal correspondiente. En la figura 1, esta interacción se muestra como la conexión E.
Exponer cargas de trabajo de máquinas virtuales
GDC permite exponer máquinas virtuales creadas por el cliente a los usuarios finales. GDC ofrece la posibilidad de configurar políticas de entrada y salida para el personal correspondiente. En la figura 1, esta interacción se muestra como la conexión F.
Servicio de interconexión entre sitios de GDC
El enrutamiento de un servicio gestionado a otro suele producirse 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 tanto en la capa de aplicación (por ejemplo, TLS) como en la capa de red. En la figura 1, esta interacción se muestra como la conexión G.
Máquina virtual a máquina virtual
Las conexiones entre máquinas virtuales dentro de GDC no se encriptan a nivel de red. Los clientes son responsables de encriptar los datos mediante protocolos encriptados adecuados o tecnologías específicas, como los túneles IPSec.
Encriptado en tránsito de forma predeterminada
GDC utiliza varios métodos de encriptado, tanto predeterminados como configurables por el usuario, para los datos en tránsito. El tipo de encriptado 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 utiliza Google para proteger los datos en tránsito.
En el resto de esta sección se describen las protecciones predeterminadas que utiliza Google para proteger los datos en tránsito.
Encriptado entre el usuario y la puerta de enlace 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 del 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 encriptado entre el usuario y 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 encriptado 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 encriptan en tránsito con el protocolo de seguridad en la capa de transporte (TLS). La puerta de enlace de entrada de Cloud Service Mesh negocia un protocolo de encriptado concreto con el cliente según su compatibilidad. La puerta de enlace de entrada de Cloud Service Mesh de GDC 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 encriptado compatibles con GDC durante la comunicación 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. Cuando se presenta el certificado, que incluye el nombre del host de DNS y la clave pública del servidor, lo firma la 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 de todo el mundo deben conocer la CA raíz. Los navegadores y dispositivos del cliente están configurados 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.
Entre la puerta de enlace de entrada de Cloud Service Mesh y el frontend de una aplicación
Hay dos casos:
- La puerta de enlace de entrada de Cloud Service Mesh finaliza TLS y vuelve a encriptar 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 Istio Sidecar
- La puerta de enlace de entrada de Cloud Service Mesh finaliza TLS y vuelve a encriptar TLS en otro servidor con la CA configurada.
Encriptado de red del tráfico de almacenamiento
En el sistema de almacenamiento de archivos y almacenamiento en 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 mediante IPSec. El encriptado del lado del cliente para el tráfico de almacenamiento estará disponible en breve. El modo de transporte de IPSec se utiliza entre el tráfico de archivos y bloques y el host que necesita acceder al almacenamiento. La autenticación se realiza mediante una clave precompartida que se genera sobre la marcha y se almacena de forma segura en GDC. Una vez que se establecen las asociaciones de seguridad (SA) de IPSec, la información se intercambia mediante el túnel IPSec. Los paquetes se encriptan y desencriptan 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 aplicación (capa 7) de la infraestructura de GDC, usamos mTLS o TLS para la autenticación, la integridad y el encriptado 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 servicio de GDC. Cada servicio que se ejecuta en GDC lo hace como una identidad de cuenta de servicio con credenciales criptográficas asociadas. Al comunicarse a través de mTLS mediante Cloud Service Mesh, los servicios de GDC utilizan certificados de cliente para autenticarse en otros servicios. Cloud Service Mesh verifica estos certificados mediante una autoridad de certificación interna. Al comunicarse a través de TLS (por ejemplo, con un servidor de la API de Kubernetes de GDC), los servicios de GDC utilizan tokens de cuenta de servicio de Kubernetes para autenticarse en los servicios. Los tokens de cuenta de servicio de Kubernetes se verifican mediante las claves públicas del emisor de tokens del servidor de la API de Kubernetes.