Claves de encriptado gestionadas por el cliente (CMEK)

De forma predeterminada, Bigtable cifra el contenido del cliente en reposo. Bigtable se encarga del cifrado sin que tengas que hacer nada más. Esta opción se llama Cifrado predeterminado de Google.

Si quieres controlar tus claves de cifrado, puedes usar claves de cifrado gestionadas por el cliente (CMEKs) en Cloud KMS con servicios integrados con CMEKs, como Bigtable. Si usas claves de Cloud KMS, tendrás control sobre su nivel de protección, ubicación, calendario de rotación, permisos de uso y acceso, y límites criptográficos. Cloud KMS también te permite monitorizar el uso de las claves, ver los registros de auditoría y controlar los ciclos de vida de las claves. En lugar de que Google sea el propietario y el gestor de las claves de cifrado de claves (KEKs) simétricas que protegen tus datos, tú controlas y gestionas estas claves en Cloud KMS.

Una vez que hayas configurado tus recursos con CMEKs, la experiencia de acceso a tus recursos de Bigtable será similar a la de usar el cifrado predeterminado de Google. Para obtener más información sobre las opciones de encriptado, consulta Claves de encriptado gestionadas por el cliente (CMEK).

CMEK con Autokey de Cloud KMS

Puedes crear CMEKs manualmente para proteger tus clústeres de Bigtable o usar Autokey de Cloud KMS. Con Autokey, los conjuntos de claves y las claves se generan a petición como parte de la creación de recursos en Bigtable. Los agentes de servicio que usan las claves para las operaciones de cifrado y descifrado se crean si aún no existen y se les asignan los roles de gestión de identidades y accesos (IAM) necesarios. Para obtener más información, consulta la descripción general de Autokey.

Autokey de Cloud KMS crea una clave predeterminada cuando se crea un clúster de Bigtable, a menos que el clúster se cree en la consola. Autokey de Cloud KMS no crea claves para recursos de Bigtable que no sean clústeres.

Para configurar las claves de cifrado gestionadas por el cliente manualmente, consulta Usar CMEK.

Funciones

  • Seguridad: CMEK proporciona el mismo nivel de seguridad que el cifrado predeterminado de Google, pero ofrece más control administrativo.

  • Control de acceso a los datos: los administradores pueden rotar, gestionar el acceso a la clave utilizada para proteger los datos inactivos en Bigtable, así como inhabilitarla o destruirla.

  • Auditoría: todas las acciones que se realizan en tus claves CMEK se registran y se pueden consultar en Cloud Logging. Las claves de Cloud EKM admiten Justificaciones de Acceso a Claves, que añade un campo de justificación a todas las solicitudes de claves. Con determinados partners de gestión de claves externas, puedes aprobar o rechazar estas solicitudes automáticamente en función de la justificación.

  • Rendimiento comparable: las instancias de Bigtable protegidas con CMEK ofrecen un rendimiento comparable al de las instancias de Bigtable que usan el cifrado predeterminado de Google.

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

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

Precios

Cloud KMS cobra el coste de la clave y las operaciones criptográficas que se realicen con ella. Consulta los precios de Cloud KMS para obtener más información.

Se te cobra por los costes de las operaciones cuando Bigtable pide a la clave de Cloud KMS que realice una operación de cifrado o descifrado. Cada solicitud de cifrado o descifrado se envía desde cada tabla de cada clúster de la instancia. Como Bigtable usa el encriptado de envolvente, estos costes por tabla suelen ser bajos, dado el pequeño número de operaciones criptográficas previstas. Si almacenas muchas tablas en una instancia protegida con CMEK, tus costes serán más elevados.

No hay costes adicionales de Bigtable por usar instancias habilitadas para CMEK.

Qué se protege con CMEK

En una instancia protegida por CMEK, Bigtable usa tu clave de CMEK para proteger los datos en reposo. Esto incluye los datos de todas las tablas del clúster. Los datos almacenados en unidades de disco duro y de estado sólido están protegidos.

Algunos datos están protegidos con el cifrado predeterminado de Google en reposo y no con la clave CMEK:

  • Subconjunto de claves de fila que marcan los límites de los intervalos y se usan para el enrutamiento.
  • Datos de depuración, incluidos volcados del núcleo y registros operativos
  • Datos en tránsito o en memoria
  • Subconjunto de valores de marca de tiempo que se usa para la recogida de elementos no utilizados.

Bigtable usa el encriptado de envolvente para los datos en reposo. La clave CMEK se usa como clave de cifrado de claves (KEK) para cifrar otras claves que usa Bigtable. Cuando rotas la clave CMEK, Bigtable solo tiene que volver a cifrar las claves intermedias.

Habilitar CMEK

A grandes rasgos, para usar claves CMEK con Bigtable, sigue estos pasos:

  1. Crea y configura una clave CMEK en cada región en la que se vayan a ubicar los clústeres de tu instancia.
  2. Crea una instancia de Bigtable y selecciona una clave CMEK para cada clúster de 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 tienen que especificar una clave ni una configuración de cifrado al leer, escribir o eliminar datos. Bigtable puede acceder a la clave en tu nombre después de que concedas el rol Encriptador/Desencriptador de Cloud KMS al agente de servicio de Bigtable.

Para obtener instrucciones detalladas, consulta Usar CMEK.

Puedes usar lo siguiente cuando trabajes con claves de cifrado gestionadas por el cliente en Bigtable.

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

Gestión de claves

Las operaciones de gestión de claves se realizan con Cloud KMS. Bigtable no puede detectar ni aplicar ningún cambio en las claves 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 de cada tabla de cada clúster cada 5 minutos.

Si Bigtable detecta una clave inhabilitada, inhabilitará un clúster a la vez de forma gradual hasta que todos los clústeres de la instancia estén inhabilitados. Después de que el primer clúster informe de que una clave se ha inhabilitado o destruido, y hasta que se inhabilite la instancia, es posible que algunas solicitudes de datos se completen correctamente y otras devuelvan un error. Las operaciones de datos que se envían a un clúster inhabilitado devuelven un error FAILED_PRECONDITION o NOT_FOUND.

Además, como la replicación de Bigtable es coherente en última instancia, es posible que un clúster haya confirmado una solicitud de escritura, pero que aún no la haya replicado en los demás clústeres de la instancia antes de que se inhabilitara.

El proceso de Bigtable para inhabilitar automáticamente todos los clústeres de una instancia después de que se inhabilite una clave puede tardar varias horas. Para evitar esta situación, te recomendamos que inhabilites todas las claves de una instancia al mismo tiempo.

Cuando se inhabilita un clúster de Bigtable, se restringen las siguientes operaciones de administrador en toda la instancia:

  • Crear un clúster
  • Eliminar un clúster
  • Crear una tabla
  • Modificar una familia de columnas
  • Restaurar una tabla

Aún puedes eliminar la instancia, una tabla o una copia de seguridad.

Si las llamadas de Bigtable a Cloud KMS detectan que se ha vuelto a habilitar una clave que estaba inhabilitada, Cloud KMS restaura el acceso al clúster de Bigtable automáticamente.

Si se ha destruido una clave de Cloud KMS, cualquier instancia de Bigtable que tenga un clúster cifrado con esa clave dejará de ser accesible permanentemente.

Si se destruye una clave de Cloud KMS y no se puede recuperar, cualquier clúster de Bigtable encriptado con esa clave se volverá inaccesible de forma permanente.

Cómo se gestiona un estado de clave no disponible

En casos excepcionales, como durante los periodos en los que Cloud KMS no está disponible, es posible que Bigtable no pueda obtener 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, Bigtable seguirá admitiendo operaciones de instancia completas en la medida de lo posible durante un máximo de una hora para minimizar el impacto de cualquier incidente de este tipo en tu carga de trabajo.

Si, después de una hora, Bigtable sigue sin poder conectarse con Cloud KMS, Bigtable empezará a poner la instancia sin conexión como medida de protección. Los datos de tu instancia de Bigtable no se podrán acceder hasta que la 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 tu instancia de Bigtable está protegido por una clave que se inhabilitó antes de que Bigtable no pudiera comunicarse con Cloud KMS, tu instancia seguirá siendo inaccesible hasta que pueda volver a conectarse a Cloud KMS y hayas vuelto a habilitar la clave.

Consideraciones sobre las claves externas

Cuando usas Cloud EKM, Google no tiene control sobre la disponibilidad de tu clave gestionada de forma externa en el sistema del partner de gestión de claves externo.

Si la clave gestionada externamente no está disponible, Bigtable seguirá admitiendo operaciones de clúster en la medida de lo posible durante un máximo de una hora.

Si, al cabo de una hora, Bigtable sigue sin poder conectarse a Cloud KMS, empezará a poner la instancia sin conexión como medida de protección. Los datos de tu instancia de Bigtable no se podrán acceder hasta que la instancia pueda volver a conectarse con Cloud KMS y Cloud KMS responda que la clave externa está activa.

Si tienes previsto usar una clave externa para una instancia de Bigtable que tenga clústeres en más de una región, asegúrate de que la clave sea compatible con esas regiones. Para obtener más información, consulta Gestores de claves externos y regiones. 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 organización

Bigtable admite restricciones de política de organización para ayudar a garantizar el uso de CMEK en toda una organización. Para obtener más información 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, una copia de seguridad está protegida por la clave CMEK del clúster en el que se almacena. Las tablas nuevas que se restauran a partir de una copia de seguridad están protegidas por la clave o las claves CMEK del clúster en el que se restauran. Para obtener más información sobre cómo afecta CMEK a las copias de seguridad y a las operaciones de restauración, consulte Copias de seguridad. Para saber cómo crear una copia de seguridad o restaurar datos a partir de una, consulta Gestionar copias de seguridad.

Almacenamiento de registros

Puedes auditar las solicitudes que Bigtable envía a Cloud KMS en tu nombre en Cloud Logging si has habilitado 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 aproximadamente por tabla en cada clúster.

Limitaciones

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

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

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

    • Las instancias que no usan CMEK no se pueden convertir para que usen CMEK.
    • Las instancias de CMEK no se pueden convertir para usar el cifrado predeterminado de Google.
    • Los clústeres creados con una clave CMEK no se pueden volver a configurar para usar otra clave.

  • Los recursos de Bigtable protegidos con CMEK (instancias, clústeres, tablas o copias de seguridad) vinculados a una clave a la que no se puede acceder como resultado de una acción activada por el usuario (como inhabilitar o destruir una clave, o revocar el rol Encrypter/Decrypter) durante más de 30 días consecutivos se eliminan automáticamente.

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

  • Durante un máximo de cinco minutos después de crear una tabla en una instancia protegida con CMEK, es posible que la versión y el estado de la clave se indiquen como desconocidos. Sin embargo, los datos que se escriban en la tabla seguirán protegidos con la clave CMEK durante ese tiempo.

  • Si inhabilita o elimina solo una versión en lugar de todas las versiones de una clave que usa Bigtable, puede provocar un comportamiento impredecible. Siempre debes inhabilitar o eliminar todas las versiones de una clave de cifrado gestionada por el cliente.

Siguientes pasos