La herramienta de cifrado de confianza dividida (STET) permite transferir datos de claves de forma segura dentro y fuera de Google Cloud de forma verificable y protegida criptográficamente frente a personas con acceso interno a Google Cloud .
Para ello, se usan dos sistemas de gestión de claves (KMS): uno interno aGoogle Cloudy otro externo. Aunque se vea comprometido un KMS, el segundo estará ahí para proteger la privacidad de tus datos.
A continuación, se muestran una serie de ejemplos en los que se transmiten datos a Cloud Storage y se computan mediante máquinas virtuales de Compute Engine. Los ejemplos muestran cómo aumentar los niveles de seguridad para explicar cómo se adapta STET a tu flujo de seguridad.
Nivel 1: Cloud Storage
Cuando ingieres datos en Google Cloud, puedes usar Cloud Storage para que los datos estén disponibles para tus cargas de trabajo en la nube. Puedes subir los datos de tus entornos de computación on-premise a un segmento de Cloud Storage, dar acceso a ese segmento a tu carga de trabajo y hacer que la carga de trabajo (o varias cargas de trabajo) consuma esos datos cuando sea necesario. Esta estrategia evita la complejidad de crear una conexión activa directamente con la carga de trabajo para enviarle los datos que necesita.
Cloud Storage siempre encripta tus datos en reposo. Sin embargo, si confías en Cloud Storage para que realice el cifrado por ti, tendrá acceso a los datos sin cifrar (texto sin formato) antes del cifrado, así como a las claves de cifrado utilizadas para crear los datos cifrados (texto cifrado). En función de tu modelo de amenazas, puede que te interese cifrar los datos antes de enviarlos a Cloud Storage para que Cloud Storage nunca tenga visibilidad del texto sin cifrar.
Nivel 2: cifrado del lado del cliente
Cuando se usa el cifrado por parte del cliente, los datos se cifran antes de subirse a Cloud Storage y solo se descifran después de descargarse en la carga de trabajo. Por lo tanto, Cloud Storage tiene acceso al texto cifrado, pero no al texto sin cifrar. Cloud Storage añade otra capa de cifrado antes de almacenar los datos, pero la protección principal de los datos es el cifrado que se realiza antes de subirlos.
Con este enfoque, ahora debes dar a la carga de trabajo acceso a la clave de cifrado necesaria para descifrar los datos. Esta tarea puede ser difícil, ya que la clave de cifrado permite eliminar la capa de cifrado original y acceder a los datos.
Nivel 3: gestión de claves externa
Una forma habitual de abordar este problema de gestión de claves es usar un servicio de gestión de claves (KMS) específico que contenga las claves y gestione el acceso a ellas. En cada intento de cifrado o descifrado, se debe enviar una solicitud al KMS. El KMS tiene la capacidad de conceder acceso en función de varios criterios para asegurarse de que solo las partes adecuadas puedan descifrar los datos.
Los sistemas de gestión de claves tienen la capacidad de requerir una serie de criterios diferentes antes de autorizar el acceso a la clave de cifrado, pero normalmente requieren una credencial que coincida con una política configurada en el KMS. Por lo tanto, cualquier parte que tenga esa credencial podrá acceder a la clave de cifrado y descifrar los datos.
Nivel 4: Confidential Computing
Las instancias de máquina virtual confidencial se ejecutan con su memoria cifrada, lo que proporciona protecciones adicionales contra el acceso no intencionado a los datos durante su uso. En muchos modelos de amenazas, las instancias de máquina virtual confidencial son más fiables que las instancias estándar, por lo que se pueden usar para cargas de trabajo sensibles.
Si tu modelo de amenazas se basa en Confidential Computing, un problema es asegurarse de que una carga de trabajo se ejecute en una instancia de VM confidencial. La atestación remota es un medio por el cual la carga de trabajo puede demostrar a un tercero que se está ejecutando en una instancia de máquina virtual confidencial y puede confirmar muchas otras propiedades sobre la configuración y el entorno de la carga de trabajo. Como las certificaciones las genera la plataforma, la carga de trabajo no puede crear certificaciones falsas que no reflejen su entorno real.
Un KMS puede requerir y evaluar estas certificaciones antes de permitir el acceso a las claves. Este requisito ayuda a asegurar que solo se permita a la carga de trabajo prevista descifrar los datos, aunque las credenciales normales se vean comprometidas.
Nivel 5: Confianza dividida
Cuando se usa un solo KMS, este tiene el control exclusivo de las claves de cifrado. Si el operador del KMS obtuviera el texto cifrado de tus datos cifrados, tendría todo lo necesario para descifrarlos y convertirlos en texto sin formato. Aunque este riesgo podría ser aceptable si el KMS lo gestiona una entidad totalmente de confianza, algunos modelos de amenazas requieren que se elimine el control unilateral del KMS.
Con STET, puedes dividir esta confianza entre dos sistemas KMS, de modo que ninguno de los dos tenga suficiente información para descifrar tus datos. Para descifrar tus datos, sería necesario que ambos operadores de KMS se pusieran de acuerdo (y que tuvieran acceso al texto cifrado).
Si usas máquinas virtuales confidenciales, STET también facilita el cifrado y el descifrado de datos mediante claves almacenadas en un KMS que requiere certificaciones.
En conjunto, STET ayuda a asegurar que las únicas entidades que tienen acceso a tus datos en texto sin cifrar son el origen de los datos (por ejemplo, un sistema local) y el consumidor de los datos (por ejemplo, una carga de trabajo que se ejecuta en una instancia de VM confidencial).
Para obtener más información sobre el uso de STET, consulta el repositorio de GitHub y la guía de inicio rápido.
Espacio confidencial con STET
Si usas Confidential Space, STET puede usar el token de certificación de Confidential Space como prueba de certificación al acceder a la clave de cifrado de claves (KEK) almacenada en Cloud KMS.
STET gestiona el acceso a las claves de Cloud KMS de tu carga de trabajo y admite el uso de Confidential Space para realizar la certificación de los flujos de trabajo de cifrado, descifrado o ambos.
Puede crear una configuración de STET que incluya información como el nombre del grupo de identidades de carga de trabajo (WIP), los URIs de Cloud KMS y la información de descifrado. A continuación, STET usa esa información para integrarla en tu configuración de Confidential Space.
Para obtener más información, consulta el repositorio de GitHub y la guía de integración de Confidential Space.