Ir al contenido principal
Producto

Tome el Control: Claves Administradas por el Cliente para Lakebase Postgres

Cifrado en almacenamiento y cómputo con control de revocación

por Ben Hagan

  • Lakebase CMK permite al cliente controlar las claves de cifrado, lo que le permite administrar las claves en su propio KMS en la nube en lugar de depender de los valores predeterminados administrados por Databricks.
  • Proteja todo el ciclo de vida de los datos cifrando tanto el almacenamiento a largo plazo como las cachés de cómputo efímeras.
  • Use su KMS como un "interruptor de apagado" técnico para hacer que los datos sean criptográficamente inaccesibles y terminar las instancias de cómputo activas, proporcionando una protección para cargas de trabajo de Postgres de alta conformidad.

El cifrado en reposo es una base de la nube, pero para las empresas que operan en entornos altamente regulados, las organizaciones deben controlar la raíz de confianza. Las Claves Administradas por el Cliente (CMK) de Lakebase brindan este control al permitirle usar sus propias claves de cifrado de su Servicio de Administración de Claves (KMS), por ejemplo, AWS KMS, Azure Key Vault o Google Cloud KMS, para proteger y administrar datos en todo el ciclo de vida de Lakebase.

Las Claves Administradas por el Cliente (CMK) de Lakebase ofrecen administración y control integrales en toda la arquitectura, a diferencia de las bases de datos administradas convencionales. Si bien las bases de datos tradicionales solo cifran el almacenamiento, Lakebase CMK administra tanto el almacenamiento persistente como el cómputo efímero.

La Arquitectura del Cifrado de Lakebase

La arquitectura de Lakebase separa el almacenamiento y el cómputo en capas independientes, un diseño que permite el escalado elástico y las operaciones sin servidor. La capa de almacenamiento (Pageserver y Safekeeper) mantiene datos persistentes de larga duración en el almacenamiento de objetos y cachés locales, mientras que la capa de cómputo ejecuta instancias de Postgres independientes que escalan hacia arriba, hacia abajo o a cero según la demanda.

el diagrama de arquitectura representa el mecanismo de cifrado a través de servicios de claves administrados en la nube, Databricks y la aplicación de claves de Lakebase

Esta separación crea un desafío único para el cifrado: ambas capas (así como todas sus cachés en toda la arquitectura) deben cifrarse y permanecer bajo el control del cliente. Lakebase CMK aborda esto a través de un modelo jerárquico de Cifrado Envolvente.

La Jerarquía de Claves

El Cifrado Envolvente es un modelo de seguridad donde los datos se cifran con claves de datos únicas (DEK), y esas claves se cifran a su vez con claves de nivel superior. Esta jerarquía garantiza que su CMK nunca salga de su KMS en la nube; Databricks solo recibe versiones envueltas (cifradas) de las claves necesarias para descifrar los datos. El modelo también permite el cifrado de alto rendimiento a escala, ya que el KMS solo se contacta para desenvolver claves, no para cifrar cada bloque de datos. Esta arquitectura es lo que permite la rotación de claves sin interrupciones y la revocación oportuna si alguna vez es necesario.

La jerarquía consta de tres niveles:

  1. Clave Administrada por el Cliente (CMK): La Raíz de Confianza que reside en su KMS en la nube (AWS KMS, Azure Key Vault o Google Cloud KMS). Databricks nunca ve el texto plano de esta clave.
  2. Clave de Cifrado de Claves (KEK): Una clave transitoria utilizada por el Servicio de Administración de Claves de Databricks para envolver claves de datos.
  3. Claves de Cifrado de Datos (DEK): Claves únicas generadas para cada segmento de datos. Estas se almacenan junto con los datos en un estado cifrado (envuelto).
jerarquía de cifrado envolvente

Cuando se necesitan acceder a los datos, los componentes de Lakebase desenrollan la DEK necesaria utilizando claves obtenidas de su KMS. En caso de revocación, el desenrollado fallará, haciendo que los datos sean criptográficamente inaccesibles. Como parte de este proceso, todas las instancias de cómputo efímero se terminan para eliminar el acceso a los datos en caché.

CMK en la Práctica: Almacenamiento y Cómputo

La implementación práctica difiere entre el almacenamiento y el cómputo:

1. Capa de Persistencia (Almacenamiento)

Todos los segmentos de datos administrados por Lakebase, incluidos los segmentos WAL (registros de transacciones almacenados por Safekeeper) y los archivos de datos, se cifran con claves protegidas por su CMK. Esto proporciona defensa en profundidad: los datos en reposo están protegidos por claves de cifrado bajo su control, no por Databricks.

2. Capa Efímera (Cómputo)

La VM de cómputo de Postgres contiene datos efímeros utilizados por el sistema operativo y PostgresSQL, por ejemplo, cachés de rendimiento, artefactos WAL, archivos temporales, etc. Por lo tanto, es fundamental que todos estos datos también se administren bajo un CMK. CMK protege estos datos de cómputo efímero con:

  • Claves por Arranque: Cada vez que se inicia una instancia de cómputo de Lakebase, genera una clave efímera única.
  • Destrucción Automática: En la revocación de CMK, Lakebase Manager termina la instancia, destruyendo las claves efímeras en memoria y haciendo inaccesibles los datos del disco local.

Implementación de CMK en el Flujo de Trabajo de Lakebase

La implementación sigue el modelo estándar de delegación de Cuenta a Espacio de Trabajo de Databricks. Esta separación de funciones garantiza que los Administradores de Seguridad puedan administrar claves sin necesidad de acceso a los datos en sí. Una vez que se configura una clave a nivel del espacio de trabajo, todos los proyectos de Lakebase utilizan el CMK como parte del flujo de trabajo de cifrado.

Paso 1: Configuración de Claves

Un Administrador de Cuenta crea una Configuración de Clave en la Consola de Cuentas de Databricks. Este objeto contiene el identificador de la clave (ARN para AWS KMS, URL de Key Vault para Azure o ID de Clave para Google Cloud KMS) y el rol de IAM o principal de servicio que Lakebase asumirá para realizar operaciones de Envoltura y Desenvoltura.

Paso 2: Vinculación del Espacio de Trabajo

La configuración se mapea luego a un Espacio de Trabajo específico. Para Lakebase, esto significa:

  • Nuevos Proyectos: Todos los nuevos proyectos de Lakebase heredan automáticamente el CMK del espacio de trabajo.
  • Aislamiento: Diferentes espacios de trabajo pueden usar diferentes CMK para satisfacer requisitos de seguridad multiinquilino o multidepartamentales.

Paso 3: Administración del Ciclo de Vida y Rotación

Lakebase admite la Rotación de Claves sin Interrupciones. Cuando rota su CMK en la consola de su proveedor de nube:

  • La jerarquía de cifrado envolvente permite una rotación sin interrupciones: su CMK se puede rotar en su KMS en la nube sin volver a cifrar los datos ni cambiar las DEK.
  • No se requiere tiempo de inactividad ni re-cifrado manual.

Auditoría de Seguridad

Dado que el CMK reside en su cuenta en la nube, las operaciones criptográficas contra su clave se registran en el servicio de auditoría de su proveedor (AWS CloudTrail, Azure Monitor o Google Cloud Audit Logs).

Comience con Soberanía de Datos Mejorada

Si su organización requiere el más alto nivel de control criptográfico sobre sus cargas de trabajo de Postgres, Lakebase CMK ya está disponible para clientes del nivel Enterprise.

¿Listo para asegurar sus datos? Póngase en contacto con su equipo de cuentas de Databricks para habilitar las Claves Administradas por el Cliente para su espacio de trabajo, o visite nuestra documentación técnica para revisar las políticas de IAM y las configuraciones de KMS de requisitos previos.

¿Aún no es cliente de Databricks? Comience con una prueba.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original

Recibe las últimas publicaciones en tu bandeja de entrada

Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.