Claves de encriptación administradas por el cliente (CMEK)

De forma predeterminada, Bigtable encripta el contenido del cliente almacenado en reposo. Bigtable controla la encriptación por ti sin que debas realizar ninguna acción adicional. Esta opción se denomina Encriptación predeterminada de Google.

Si deseas controlar tus claves de encriptación, puedes usar las claves de encriptación administradas por el cliente (CMEK) en Cloud KMS con servicios integrados en CMEK, incluido Bigtable. El uso de claves de Cloud KMS te permite controlar su nivel de protección, ubicación, programa de rotación, permisos de uso y acceso, y límites criptográficos. El uso de Cloud KMS también te permite ver los registros de auditoría y controlar los ciclos de vida de las claves. En lugar de que Google posea y administre las claves de encriptación de claves (KEK) simétricas que protegen tus datos, tú las controlas y administras en Cloud KMS.

Después de configurar tus recursos con CMEK, la experiencia de acceso a tus recursos de Bigtable es similar a usar la encriptación predeterminada de Google. Para obtener más información sobre tus opciones de encriptación, consulta Claves de encriptación administradas por el cliente (CMEK).

En esta página, se describen las CMEK para Bigtable. Para obtener instrucciones para realizar tareas relacionadas con CMEK con Bigtable, consulta Usa CMEK.

Funciones

  • Seguridad: Las CMEK proporcionan el mismo nivel de seguridad que la encriptación predeterminada de Google, pero ofrecen más control administrativo.

  • Control de acceso a los datos: Los administradores pueden rotar, administrar el acceso e inhabilitar o destruir la clave que se usa para proteger los datos en reposo en Bigtable.

  • Auditabilidad: todas las acciones en las claves de CMEK se registran y se pueden ver en Cloud Logging. Las claves de Cloud EKM admiten Key Access Justification, que agrega un campo de justificación a todas las solicitudes de claves. Con determinados socios de administración de claves externas, puedes aprobar o rechazar automáticamente estas solicitudes, según la justificación.

  • Rendimiento comparable: Las instancias protegidas con CMEK de Bigtable ofrecen un rendimiento comparable al de las instancias de Bigtable que usan la encriptación predeterminada de Google.

  • Flexibilidad: puedes usar la misma clave CMEK en varios proyectos, instancias o clústeres, o bien usar claves separadas según tus necesidades empresariales.

  • Protección entre regiones: puedes habilitar CMEK en instancias que tienen clústeres en cualquier región en la que Bigtable esté disponible. Cada clúster está protegido por una clave CMEK en la región de ese clúster.

Precios

Cloud KMS cobra por el costo de la clave y por todas las operaciones criptográficas realizadas con ella. Consulta los precios de Cloud KMS para obtener más detalles.

Se te factura por los costos de operaciones cuando Bigtable solicita a la clave de Cloud KMS realizar una operación de encriptación o desencriptación. Cada solicitud de encriptación o desencriptación se envía desde cada tabla en cada clúster de la instancia. Dado que Bigtable usa la encriptación de sobre, estos costos por tabla suelen ser bajos, dada la pequeña cantidad de operaciones criptográficas esperadas. Si almacenas muchas tablas en una instancia protegida con CMEK, los costos serán más altos.

No se aplican costos adicionales de Bigtable por usar instancias habilitadas con CMEK.

Qué se protege con CMEK

En una instancia protegida con CMEK, Bigtable usa la clave CMEK para proteger los datos en reposo. Esto incluye los datos en todas las tablas del clúster. Los datos almacenados en el almacenamiento HDD y SSD están protegidos.

Algunos datos están protegidos por la encriptación predeterminada en reposo de Google y no por la clave de CMEK:

  • Un subconjunto de claves de fila que marca los límites del rango y se usa para el enrutamiento
  • Depuración de datos, incluidos los volcados de memoria y los registros operativos
  • Datos en tránsito o en memoria
  • Un subconjunto de valores de marca de tiempo que se usa para la recolección de elementos no utilizados

Bigtable usa la encriptación de sobre para los datos en reposo. La clave CMEK se usa como una clave de encriptación de claves (KEK) para encriptar otras claves que usa Bigtable. Cuando rotas la clave CMEK, Bigtable solo necesita volver a encriptar las claves intermedias.

Habilita CMEK

En un nivel alto, para usar CMEK con Bigtable, sigue estos pasos:

  1. Crea y configura una clave CMEK en cada región en la que estarán los clústeres de tu instancia.
  2. Crea una instancia nueva de Bigtable y selecciona una clave CMEK para cada clúster en la instancia. La clave CMEK de un clúster debe estar en la misma región que el clúster.
  3. Programa una rotación de claves para cada clave.

Las aplicaciones que usan Bigtable no necesitan especificar una clave o configuración de encriptación cuando leen, escriben o borran datos. Bigtable puede acceder a la clave en tu nombre después de otorgar la función de Encriptador y Desencriptador de Cloud KMS al agente de servicio de Bigtable.

Para obtener instrucciones detalladas, consulta Usa CMEK.

Puedes usar lo siguiente cuando trabajes con CMEK para Bigtable.

También puedes acceder directamente a la API de Administrador de Cloud Bigtable, pero te recomendamos que lo hagas solo si no puedes usar una biblioteca cliente de Bigtable que realice llamadas de CMEK a la API.

Administración de claves

Las operaciones de administración de claves se realizan mediante Cloud KMS. Bigtable no puede detectar ni realizar cambios en cualquier cambio de clave hasta que Cloud KMS los propague. Algunas operaciones, como inhabilitar o destruir una clave, pueden tardar hasta 4 horas en propagarse. Los cambios en los permisos de una clave suelen propagarse más rápido.

Después de crear al menos una tabla en una instancia protegida por CMEK, Bigtable valida la clave para cada tabla en cada clúster cada 5 minutos.

Si Bigtable detecta una clave inhabilitada, inhabilita un clúster a la vez de forma en cascada hasta que todos los clústeres de la instancia estén inhabilitados. Después de que el primer clúster informa que una clave se inhabilita o se destruye, y hasta que la instancia esté inhabilitada, algunas solicitudes de datos podrían tener éxito y otras mostrar un error. Cualquier operación de datos que se envíe a un clúster inhabilitado se mostrará con un error FAILED_PRECONDITION o NOT_FOUND.

Además, debido a que la replicación de Bigtable tiene coherencia eventual, es posible que un clúster haya confirmado una solicitud de escritura, pero aún no la haya replicado en los otros clústeres de la instancia antes de que se inhabilitara.

El proceso de Bigtable para inhabilitar de manera automática todos los clústeres en una instancia después de inhabilitar una clave puede tomar varias horas. Para evitar este estado, te recomendamos que siempre inhabilites todas las claves de una instancia al mismo tiempo.

Cuando un clúster de Bigtable está inhabilitado, las siguientes operaciones de administrador están restringidas para toda la instancia:

  • Crear un clúster
  • Borra un clúster
  • Crea una tabla
  • Modifica una familia de columnas
  • Restablece una tabla

Aún puedes borrar la instancia, una tabla y una copia de seguridad.

Si las llamadas de Bigtable a Cloud KMS detectan que se volvió a habilitar una clave que estaba inhabilitada, Cloud KMS restablece el acceso al clúster de Bigtable de forma automática.

Si se destruyó una clave de Cloud KMS, cualquier instancia de Bigtable que tenga un clúster encriptado con esa clave se volverá inaccesible de manera permanente.

Cómo se controla un estado de clave no disponible

En raras ocasiones, como durante períodos en los que Cloud KMS no está disponible, es posible que Bigtable no pueda recuperar el estado de una clave de Cloud KMS.

Si un clúster de Bigtable está protegido por una clave habilitada en el momento en que Bigtable no puede comunicarse con Cloud KMS por primera vez, Bigtable sigue admitiendo operaciones completas de instancia en función del mejor esfuerzo mediante claves almacenadas en caché derivadas de la clave de Cloud KMS por un período de hasta 1 hora, para minimizar el impacto de cualquier incidente en tu carga de trabajo.

Después de una hora, si Bigtable aún no puede conectarse con Cloud KMS, Bigtable comenzará a desconectar la instancia como medida de protección. Los datos en tu instancia de Bigtable permanecerán inaccesibles hasta que tu instancia pueda volver a conectarse con Cloud KMS y Cloud KMS responda que la clave está activa.

Por el contrario, si un clúster de Bigtable está protegido por una clave que se inhabilitó antes del momento en que Bigtable no puede comunicarse con Cloud KMS por primera vez, la instancia permanece inaccesible hasta que pueda volver a conectarse con Cloud KMS y tú hayas vuelto a habilitar tu clave.

Consideraciones de claves externas

Cuando usas una clave de Cloud EKM, Google no tiene control sobre la disponibilidad de tu clave administrada de forma externa en el sistema de socios de administración de claves externas.

Si la clave administrada de forma externa no está disponible, Bigtable continúa admitiendo hasta por una hora operaciones de clúster mediante una versión de la clave almacenada en caché.

Después de una hora, si Bigtable aún no puede conectarse con Cloud KMS, comenzará a desconectar la instancia como medida de protección. Los datos en tu instancia de Bigtable permanecerán inaccesibles hasta que la instancia pueda volver a conectarse con Cloud KMS y Cloud KMS responda que la clave externa está activa.

Si planeas usar una clave externa para una instancia de Bigtable que tiene clústeres en más de una región, asegúrate de que tu clave sea compatible con esas regiones. Para obtener más información, consulta Administradores y regiones de claves externas. Además, no debes usar una combinación de claves externas y no externas en la misma instancia.

Para obtener más información sobre el uso de claves externas con Cloud Key Management Service, consulta Cloud External Key Manager (Cloud EKM).

Políticas de la organización

Bigtable admite restricciones de políticas de la organización para ayudar a garantizar el uso de CMEK en una organización. Para obtener detalles sobre cómo usar las políticas de la organización, consulta Políticas de la organización de CMEK.

Copias de seguridad

Al igual que otros datos, la clave CMEK protege la copia de seguridad del clúster en el que se almacena la copia de seguridad. Las tablas nuevas que se restablecen a partir de una copia de seguridad están protegidas por la clave CMEK o las claves del clúster en el que se restablecen. Para obtener más detalles sobre cómo CMEK afecta las copias de seguridad y las operaciones de restablecimiento, consulta Copias de seguridad. Para obtener información sobre cómo crear o restablecer a partir de una copia de seguridad, consulta Administra copias de seguridad.

Logging

Puedes auditar las solicitudes que Bigtable envía a Cloud KMS en tu nombre en Cloud Logging si habilitaste los registros de auditoría de Cloud KMS para la API de Cloud KMS en tu proyecto. Puedes esperar algunas entradas de registro cada 5 minutos por tabla en cada clúster.

Limitaciones

  • Las CMEK solo se pueden configurar a nivel del clúster. No puedes configurar CMEK en copias de seguridad, tablas o perfiles de apps.

  • La clave CMEK de un clúster debe estar en la misma región que el clúster. Cuando crees un llavero de claves de Cloud KMS, asegúrate de seleccionar la región que corresponda a la configuración zonal de Bigtable que planificaste.

  • La configuración de encriptación de un recurso de Bigtable (una instancia, clúster, tabla o copia de seguridad) es inmutable.

    • Las instancias que no son CMEK no se pueden convertir para usar CMEK.
    • Las instancias de CMEK no se pueden convertir para usar la encriptación predeterminada de Google.
    • Los clústeres creados con una clave CMEK no se pueden volver a configurar para que usen una clave diferente.

  • Los recursos de Bigtable protegidos por CMEK (instancias, clústeres, tablas o copias de seguridad) vinculados a una clave que se volvió inaccesible como consecuencia de una acción activada por el usuario (como la inhabilitación o destrucción de una clave, o mediante la revocación de la función de encriptador/desencriptador) durante más de 30 días consecutivos se borran automáticamente.

  • Si vuelves a habilitar una clave de CMEK inhabilitada para restablecer el acceso a las instancias de Bigtable protegidas por esa clave, es posible que se agote el tiempo de espera de algunas solicitudes a la API de datos mientras los datos se vuelven a conectar.

  • Durante un máximo de cinco minutos después de la creación de una tabla en una instancia protegida por CMEK, la versión de clave y el estado de clave pueden informarse como desconocidos. Sin embargo, los datos escritos en la tabla siguen protegidos con la clave CMEK durante ese tiempo.

  • Inhabilitar o borrar solo una versión en lugar de todas las versiones de una clave que usa Bigtable puede generar un comportamiento impredecible. Siempre inhabilita o borra todas las versiones de una clave CMEK.

¿Qué sigue?