En este blog, presentamos una forma de mover una base de datos existente primero a un estado cifrado y luego, cómo mover su base de datos a un estado no cifrado.
Para usar el cifrado, debe cargar un complemento para administrar las claves de cifrado. Consulte los complementos de cifrado admitidos actualmente. Cada clave utiliza un número entero de 32 bits como identificador de clave (key_id) y clave real. Las claves se pueden versionar para que los datos se vuelvan a cifrar de la clave anterior a la versión más nueva de la clave. En este blog, usaremos el complemento de administración de claves de archivos como ejemplo (consulte administración de claves de cifrado). También asumimos que está utilizando la versión más reciente de MariaDB Server (este blog asume que MDEV-15566 está solucionado, es decir, la versión de MariaDB debe ser 10.1.33, 10.2.15 o 10.3.6).
Mover una base de datos a un estado encriptado o a un estado no encriptado se realiza mediante key_rotation. La rotación de claves mueve la base de datos de un estado cifrado existente a otro. Tenga en cuenta que aquí el espacio de tablas podría no tener un estado cifrado (es decir, el espacio de tablas no está cifrado) o el espacio de tablas podría tener un estado de cifrado que se mueve a un estado no cifrado. La rotación de claves puede ocurrir periódicamente (según la variable de configuración innodb-encryption-rotate-key-age es decir, la antigüedad de la clave antes de que se rote), solicitada por el administrador de la base de datos (p. ej., emitiendo set global innodb_encrypt_tables=ON; ) o mediante un sistema de gestión de claves de cifrado (consulte, por ejemplo, rotar claves).
Los administradores de la base de datos deben tomar la decisión de si es suficiente cifrar solo tablas individuales (consulte el cifrado de datos para InnoDB) o toda la base de datos, incluido el espacio de tabla del sistema. Tenga en cuenta que los datos de la tabla también se escriben en el registro de rehacer y en el registro de deshacer. Por lo tanto, si la base de datos contiene tablas que contienen datos muy confidenciales innodb-encrypt-log también debe estar habilitado. En este blog, mostramos cómo cifrar toda la base de datos.
Mover la base de datos al estado cifrado
Antes de que la base de datos se pueda mover a un estado cifrado, debemos agregar la configuración del complemento de cifrado al archivo de configuración (consulte la descripción detallada de los parámetros):
# File Key Management
plugin-load-add = file_key_management
file-key-management-filename = /mnt/flash/keys.txt
file-key-management-encryption-algorithm = aes_ctr
# InnoDB encryption setup
innodb-encrypt-tables=ON
innodb-encrypt-log=ON
innodb-encryption-rotate-key-age=1024
innodb-encryption-threads=4
innodb-tablespaces-encryption
Después de reiniciar, el progreso de la operación de cifrado se puede monitorear desde la tabla INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION. En el siguiente ejemplo, consultamos el nombre del tablespace, la página actual bajo la rotación de claves y la página máxima en el tablespace para aquellas tablas que aún no están cifradas:
MariaDB [(none)]> select name, KEY_ROTATION_PAGE_NUMBER, KEY_ROTATION_MAX_PAGE_NUMBER from information_schema.innodb_tablespaces_encryption where min_key_version = 0 or ROTATING_OR_FLUSHING = 1;
+---------------+--------------------------+------------------------------+
| name | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER |
+---------------+--------------------------+------------------------------+
| innodb_system | 17641 | 1397504 |
+---------------+--------------------------+------------------------------+
1 row in set (0.000 sec)
Naturalmente, también puede consultar el estado de todas las tablas:
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption;
+-------+-------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| SPACE | NAME | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING |
+-------+-------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| 0 | innodb_system | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 3 | tpcc1000/customer | 1 | 1 | 0 | 1 | 2401 | 1317888 | 1 | 1 |
+-------+-------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
2 rows in set (0.000 sec)
A partir de esto, podemos ver que el espacio de tabla del sistema ya está encriptado, pero la tabla del cliente de la base de datos tpcc1000 se está encriptando actualmente. Si su sistema tiene recursos de hardware y el proceso de cifrado parece lento, puede probar los siguientes parámetros:
# Set close to number of cores
set global innodb_encryption_threads=16;
# For SSD increase number of I/O operations used for encryption in second
set global innodb_encryption_rotation_iops=40000;
El cifrado de la base de datos finaliza cuando no hay tablas sin cifrar:
MariaDB [tpcc1000]> select name, KEY_ROTATION_PAGE_NUMBER, KEY_ROTATION_MAX_PAGE_NUMBER from information_schema.innodb_tablespaces_encryption where min_key_version = 0 or ROTATING_OR_FLUSHING = 1;
Empty set (0.001 sec)
Y para verificar, enumere todas las tablas que están encriptadas:
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption where min_key_version != 0;
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| SPACE | NAME | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| 0 | innodb_system | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 3 | tpcc1000/customer | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 2 | tpcc1000/district | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 4 | tpcc1000/history | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 8 | tpcc1000/item | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 5 | tpcc1000/new_orders | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 7 | tpcc1000/order_line | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 6 | tpcc1000/orders | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 9 | tpcc1000/stock | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 1 | tpcc1000/warehouse | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
10 rows in set (0.000 sec)
Como puede verse, todos los tablespaces usan ENCRYPTION_SCHEME=1 (cifrado) y MIN_KEY_VERSION=1 . Después de esta fase, el administrador de la base de datos debe considerar disminuir la cantidad de subprocesos de cifrado utilizados y las operaciones de rotación. Además, también se debe considerar la necesidad de una mayor rotación de claves, ya que el complemento de administración de claves de archivos no admite la rotación de claves real. La rotación de claves se puede desactivar usando innodb-encryption-rotate-key-age=0 . Tenga en cuenta que, incluso con esa configuración, todas las tablas nuevas creadas se tienen en cuenta para el cifrado.
Mover la base de datos a un estado no cifrado
Aquí asumimos que tiene una base de datos cifrada y ya no es necesario cifrar los datos o la protección de datos se realiza de manera diferente. Usaremos la misma base de datos como ejemplo para mover la base de datos al estado cifrado. En este punto no hay necesidad de reiniciar el servidor. En su lugar, mover la base de datos al estado no cifrado se puede realizar como una operación en línea. En primer lugar, el administrador de la base de datos debe comprobar que no haya tablas que utilicen cifrado explícito, es decir, que haya una tabla en la que crear tabla haya utilizado la opción de tabla ENCRYPTED=YES. Ahora, mover la base de datos a un estado sin cifrar se puede hacer simplemente emitiendo:
SET GLOBAL innodb_encrypt_tables=OFF;
Esto comenzará a descifrar todos los espacios de tabla, incluido el espacio de tabla del sistema, y el progreso de esta operación se puede monitorear mediante:
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption where min_key_version != 0;
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| SPACE | NAME | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| 7 | tpcc1000/order_line | 1 | 1 | 1 | 1 | 76564 | 1947904 | 1 | 1 |
| 6 | tpcc1000/orders | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 9 | tpcc1000/stock | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 1 | tpcc1000/warehouse | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 10 | tpcc1000/t1 | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
5 rows in set (0.001 sec)
A partir de esto, podemos ver que la tabla order_line de la base de datos tpcc1000 se está rotando. La operación finaliza cuando no hay tablas que usen cifrado, es decir, ¡tiene min_key_version! =0.
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption where min_key_version != 0 or rotating_or_flushing = 1;
Empty set (0.000 sec)
Si es necesario eliminar la configuración de cifrado de la configuración, ahora es el momento de apagar el servidor. Si la configuración utiliza el cifrado de registro de rehacer, es decir, innodb-encrypt-log=ON realice copias de seguridad de su base de datos, incluidos los archivos de registro de InnoDB, y luego elimine los archivos de registro de InnoDB, ya que no se pueden utilizar si contienen datos cifrados.
rm -rf ib_logfile*
Elimine la configuración de cifrado de la configuración y reinicie el servidor. Ahora tiene una instancia de base de datos donde no se usa cifrado.
Conclusión
Mover una base de datos a un estado cifrado como se ve arriba requiere que el servidor se reinicie y requiere una configuración cuidadosa del complemento de cifrado. La duración de esta operación depende del número de mesas y del tamaño de estas. Hemos presentado una forma de monitorear este progreso y cómo acelerarlo si el hardware utilizado tiene suficientes recursos. Mover una base de datos a un estado no cifrado requiere solo configurar una variable global. Sin embargo, si el cifrado se necesita por más tiempo y es necesario eliminar todas las referencias a él, es necesario reiniciarlo una vez. Hemos mostrado cómo monitorear esta transición y cómo eliminar por completo la configuración de cifrado tanto de la base de datos como de la configuración.
