Cifrado MySQL: cifrado de clave maestra en InnoDB

En la publicación de blog anterior de esta serie, MySQL Encryption: Talking About Keyrings, describí cómo funcionan los llaveros. En esta publicación, hablaré sobre cómo funciona la criptografía de clave maestra y cuáles son los pros y los contras de usar la criptografía de sobre como clave maestra.

La idea detrás del cifrado de sobres es que usa una clave para cifrar muchas otras claves. En InnoDB, esta «clave única» es la clave de cifrado maestra y las «otras claves múltiples» son las claves del espacio de tablas. Esas claves de espacio de tablas son las que realmente se utilizan para cifrar los espacios de tablas. Gráficamente se puede presentar así:

La clave maestra reside en el conjunto de claves, mientras que las claves del espacio de tabla cifradas residen en los encabezados del espacio de tabla (escrito en la página 0 de un espacio de tabla). En la imagen de arriba:

La tabla A se cifra con la clave 1. La clave 1 se cifra con la clave maestra y se almacena (cifra) en el encabezado de la tabla A.

La tabla B se cifra con la clave 2. La clave 2 se cifra con la clave maestra y se almacena (cifra) en el encabezado de la tabla B.

Y así. Cuando un servidor quiere descifrar la Tabla A, toma la clave maestra del conjunto de claves, lee la clave cifrada 1 del encabezado de la Tabla A y descifra la clave 1. La clave descifrada 1 se almacena en caché en la memoria del servidor y se usa para descifrar la Tabla UNA.

InnoDB

En InnoDB, el cifrado/descifrado real se realiza en la capa de E/S del servidor. Entonces, justo antes de que una página se lave al disco, se cifra y, sin embargo, justo después de leer una página cifrada del disco, se descifra.

El cifrado InnoDB solo funciona en el nivel del tablespace. Normalmente, cuando crea una tabla independiente, crea un espacio de tabla de archivo por tabla (ENCENDIDO por defecto). Entonces, lo que realmente crean es un tablespace que puede contener solo una tabla. También puede crear una tabla que pertenezca a un espacio de tabla general. Sin embargo, su mesa seguirá estando en un espacio de mesa. Dado que la criptografía funciona en el nivel del tablespace, un tablespace puede estar completamente cifrado o sin cifrar. Por lo tanto, no puede tener algunas tablas en el espacio de tabla encriptado general y otras no.

Si por alguna razón ha deshabilitado el archivo por tabla, entonces todas las tablas independientes se crean en el espacio del sistema. En Percona Server para MySQL, puede cifrar el espacio de tablas del sistema especificando (variable innodb_sys_tablespace_encrypt) durante el arranque o mediante el uso de subprocesos de cifrado (todavía es una función experimental). En MySQL, no puedes;).

Antes de continuar, debemos entender cómo se construye la ID de la clave maestra. Consiste en el prefijo UUID, KEY_ID e INNODBKey. Tiene este aspecto: INNODBKey-UUID-KEY_ID.

UUID es el uuid del servidor en el que se cifró el tablespace. KEY_ID es solo un valor cada vez mayor. Cuando se crea la primera clave maestra, este KEY_ID es igual a 1. Entonces, cuando gira la clave maestra, se crea una nueva clave maestra con KEY_ID = 2 y así sucesivamente. Discutiremos la rotación de la llave maestra en profundidad más adelante en futuras publicaciones de blog de esta serie.

Ahora que sabemos cómo se ve la ID de la clave maestra, podemos echar un vistazo a una clave criptográfica. Cuando un tablespace se cifra por primera vez, el encabezado de cifrado se agrega al encabezado del tablespace. Se parece a esto:

KEY ID es el KEY_ID del ID de clave maestra que ya discutimos. UUID es el uuid del servidor, luego se usa en la ID maestra. La clave del espacio de tablas consta de 256 bits generados aleatoriamente (desde el servidor). Tablespace IV también consta de 256 claves generadas aleatoriamente (aunque debería ser de 128 bits). IV se usa para inicializar el cifrado y descifrado AES (solo se usan 128 bits de esos 256 bits). Por último, tenemos la suma de verificación CRC32 de la clave del espacio de tabla y IV.

Todo este tiempo digo que tenemos una clave de espacio de tabla cifrada en el encabezado. Simplifiqué esto un poco. De hecho, mantenemos las claves IV y del espacio de tablas juntas, y las ciframos con la clave maestra. Recuerde, antes de cifrar el espacio de tablas y las claves IV, primero calculamos el CRC32 de los dos.

¿Por qué necesitamos CRC32?

Bueno, para asegurarnos de que usamos la clave maestra correcta para descifrar el espacio de tablas y la clave IV. Después de descifrar el espacio de tabla y la clave IV, calculamos la suma de verificación y la comparamos con el CRC32 almacenado en el encabezado. En caso de que correspondan, sabemos que hemos utilizado la clave maestra correcta y tenemos una clave de espacio de tabla válida y un espacio de tabla iv para descifrar la tabla. En caso de que no coincidan, hemos marcado el espacio de tabla como faltante (no podemos descifrarlo de todos modos).

Puede preguntar: ¿cuándo verificamos si tenemos las claves maestras correctas para descifrar todas las tablas? La respuesta es: al principio del servidor. Inicialmente, cada servidor de tabla/tablespace encriptado lee el UUID, KEY_ID del encabezado para construir la ID de la clave maestra. A continuación, toma la clave maestra requerida de Keyring, descifra las claves de tablespace y iv, y verifica la suma de verificación. Nuevamente, si las coincidencias de la suma de verificación son todas buenas, de lo contrario, el espacio de tabla se marca como faltante.

Si sigue esta serie de encriptación de publicaciones de blog, puede recordar que en MySQL Encryption: Talking About Keyrings mencioné que el llavero basado en servidor solo toma una lista de ID de clave (para ser precisos, ID de clave e ID de usuario, como este par ). identifica solo la clave en el conjunto de claves) al comienzo del servidor. Ahora digamos que el servidor toma todas las claves que necesita al principio para validar que puede descifrar las claves del tablespace. Entonces, ¿por qué un conjunto de claves basado en servidor toma solo key_id y user_id cuando se inicializa en lugar de tomar todas las claves? Porque es posible que no se necesiten todas las claves; esto se debe principalmente a la rotación de la llave maestra. La rotación de la clave maestra genera una nueva clave maestra en el conjunto de claves, pero nunca elimina las versiones anteriores de la clave maestra. Luego, puede terminar con algunas claves en Server Vault (Server Vault, si está utilizando keyring_vault) que el servidor no necesita y, por lo tanto, no se llevan al inicio del servidor.

Es hora de hablar un poco sobre los pros y los contras de la criptografía de llave maestra. La mayor ventaja es que solo necesita una clave de cifrado (clave maestra) para almacenarla por separado de sus datos cifrados. Esto hace que el inicio del servidor sea más rápido y el conjunto de claves es más pequeño, lo que facilita su administración. Además, la llave maestra se puede girar con un comando.

Sin embargo, la criptografía de clave maestra tiene una gran desventaja; una vez que un tablespace se cifra con tablespace_key, siempre se cifra con la misma clave. La rotación de la llave maestra no ayudará aquí.. ¿Por qué es esto una desventaja? Sabemos que MySQL tiene errores que pueden provocar un bloqueo y producir un archivo central. Dado que el archivo central contiene un volcado de memoria de nuestro servidor, puede suceder que este volcado central contenga una clave de espacio de tablas descifrada. Lo que es peor, las claves de espacio de tablas descifradas se almacenan en la memoria que se puede intercambiar en el disco. Se puede decir que no es una desventaja porque necesita tener acceso de raíz para acceder a esos archivos de intercambio de núcleo/partición. Esto es cierto, pero solo necesita acceder a la raíz por un tiempo. Una vez que alguien accede a la clave del espacio de tabla descifrado, puede continuar usándola para descifrar los datos, incluso si esa persona ya no puede acceder a la raíz. Además, el disco puede ser robado y los archivos de partición / núcleo de intercambio pueden leerse por varios medios, y el propósito de TDE es hacerlo ilegible incluso si el disco es robado. Percona Server para MySQL ofrece una función que hace posible volver a cifrar un espacio de tabla, con claves recién generadas. Esta característica se denomina subproceso de cifrado y aún es experimental al momento de escribir esta publicación de blog.

Estén atentos para obtener más información sobre el cifrado de datos transparente en las próximas publicaciones de blog de esta serie.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario