La herramienta de encriptación de confianza dividida (STET) proporciona un mecanismo de distribución que permite la transferencia segura de datos de claves dentro y fuera de Google Cloud de una manera que está protegida de forma verificable y criptográfica contra usuarios con información privilegiada de Google Cloud .
Esto se logra con dos sistemas de administración de claves (KMS), uno interno a Google Cloudy el otro externo. Incluso si se vulnera un KMS, el segundo está disponible para ayudar a mantener la privacidad de tus datos.
A continuación, se muestra una serie de ejemplos que involucran datos transmitidos a Cloud Storage y procesados con VMs de Compute Engine. Los ejemplos describen niveles crecientes de seguridad para explicar cómo se ajusta la STET a tu flujo de seguridad.
Nivel 1: Cloud Storage
Cuando transfieres datos a Google Cloud, puedes usar Cloud Storage para que los datos estén disponibles en las cargas de trabajo de la nube. Puedes subir los datos de tus entornos de computación locales a un bucket de Cloud Storage, otorgar a tu carga de trabajo acceso a ese bucket y hacer que la carga de trabajo (o varias cargas de trabajo) consuman esos datos cuando sea necesario. Con esta estrategia, se evita la complejidad de crear una conexión activa directamente a la carga de trabajo para enviarle los datos que necesita.
Cloud Storage siempre encripta tus datos en reposo. Sin embargo, si le confías a Cloud Storage que realice esa encriptación, siempre debe tener acceso a los datos no encriptados (texto simple) antes de la encriptación, así como a las claves de encriptación que se usan para crear los datos encriptados (texto cifrado). Según tu modelo de amenaza, puede ser conveniente encriptar los datos antes de enviarlos a Cloud Storage, de modo que Cloud Storage nunca tenga visibilidad para el texto simple.
Nivel 2: Encriptación del cliente
Cuando usas la encriptación del cliente, encriptas los datos antes de que se suban a Cloud Storage y solo los desencriptas después de que se descargan en tu carga de trabajo. Como resultado, Cloud Storage tiene acceso al texto cifrado, pero no al texto simple. Cloud Storage agrega otra capa de encriptación antes de almacenarla, pero la protección principal para los datos es la encriptación que se realizó antes de subirla.
Con este enfoque, ahora debes otorgar a la carga de trabajo acceso a la clave de encriptación necesaria para desencriptar los datos. Esta tarea es potencialmente difícil, ya que la clave de encriptación otorga la capacidad de quitar la capa original de encriptación y obtener visibilidad de los datos.
Nivel 3: Administración de claves externas
Un enfoque común para este problema de administración de claves es usar un servicio de administración de claves (KMS) dedicado que conserve las claves y administre el acceso a ellas. En cada intento de encriptación o desencriptación, se debe enviar una solicitud al KMS. El KMS tiene la capacidad de otorgar el acceso en función de varios criterios para garantizar que solo las partes adecuadas puedan desencriptar los datos.
Los sistemas de KMS tienen la capacidad de requerir una serie de criterios diferentes antes de autorizar el acceso a la clave de encriptación, pero, por lo general, requieren una credencial que coincida con una política configurada en el KMS. Por lo tanto, cualquier parte que posea esa credencial podrá acceder a la clave de encriptación y desencriptar los datos.
Nivel 4: Confidential Computing
Las instancias de Confidential VM se ejecutan con su memoria encriptada, lo que proporciona protecciones adicionales contra el acceso no deseado a los datos mientras se usan. En muchos modelos de amenazas, las instancias de Confidential VM son más confiables que las instancias estándar, por lo que se pueden usar para cargas de trabajo sensibles.
Si tu modelo de amenaza se basa en Confidential Computing, un problema es garantizar que una carga de trabajo se ejecute en una instancia de VM confidencial. La certificación remota es un medio por el que la carga de trabajo puede demostrar a una parte remota que, en efecto, se ejecuta en una instancia de Confidential VM y puede confirmar muchas otras propiedades sobre la configuración y el entorno de la carga de trabajo. Debido a que la plataforma genera las certificaciones, 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 garantizar que solo la carga de trabajo deseada pueda desencriptar los datos, incluso si las credenciales normales están comprometidas.
Nivel 5: Confianza dividida
Cuando se usa un solo KMS, ese KMS tiene control exclusivo sobre las claves de encriptación. Si el operador de KMS adquiriera el texto cifrado de tus datos encriptados, tendría todo lo necesario para desencriptarlo en tu texto simple. Si bien este riesgo puede ser aceptable si una entidad completamente confiable opera el KMS, algunos modelos de amenaza crean la necesidad de quitar el control unilateral del KMS.
Con STET, tienes la opción de dividir esta confianza entre dos sistemas de KMS, sin que el KMS tenga suficiente información para desencriptar tus datos. Necesitaría la intercalación entre ambos operadores de KMS (y acceso al texto cifrado) para desencriptar tus datos.
Si usas Confidential VMs, STET también facilita la encriptación y desencriptación de los datos mediante claves almacenadas en un KMS que requiere certificaciones.
En conjunto, STET ayuda a garantizar que las únicas entidades que tienen acceso a tus datos de texto simple sean el creador de los datos (por ejemplo, un sistema local) y el consumidor de los datos (por ejemplo, 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.
Confidential Space con STET
Si usas Confidential Space, STET puede usar el token de certificación de Confidential Space como evidencia de certificación cuando se accede a la clave de encriptación de claves (KEK) que se almacena en Cloud KMS.
STET controla el acceso a las claves de Cloud KMS para tu carga de trabajo y admite el uso de Confidential Space para realizar la certificación del flujo de trabajo de encriptación, el flujo de trabajo de desencriptación o ambos.
Puedes crear una configuración de STET que incluya información como el nombre del grupo de identidades de cargas de trabajo (WIP), los URIs de Cloud KMS y la información de desencriptación. Luego, STET usa esa información para integrarse a la configuración de tu Confidential Space.
Para obtener más información, consulta el repositorio de GitHub y la guía de integración de espacios confidenciales.