Neste blog, apresentamos uma maneira de mover um banco de dados existente primeiro para um estado criptografado e, em seguida, como mover seu banco de dados para um estado não criptografado.
Para usar a criptografia, você precisa carregar um plugin para gerenciar as chaves de criptografia. Veja os plugins de criptografia atualmente suportados. Cada chave usa um inteiro de 32 bits como identificador de chave (key_id) e chave real. As chaves podem ser versionadas para que os dados sejam criptografados novamente da chave mais antiga para a versão mais recente da chave. Neste blog, usaremos o plug-in de gerenciamento de chave de arquivo como exemplo (consulte gerenciamento de chave de criptografia). Também presumimos que você esteja usando a versão mais recente do MariaDB Server (este blog pressupõe que o MDEV-15566 está corrigido, ou seja, a versão do MariaDB deve ser 10.1.33, 10.2.15 ou 10.3.6).
A movimentação de um banco de dados para um estado criptografado ou não criptografado é feita usando uma key_rotation. A rotação de chaves move o banco de dados de um estado criptografado existente para outro. Observe que aqui o tablespace não pode ter um estado criptografado (ou seja, o tablespace não é criptografado) ou o tablespace pode ter um estado de criptografia que é movido para um estado não criptografado. A rotação de chaves pode ocorrer periodicamente (com base na variável de configuração innodb-encryption-rotate-key-age ou seja, qual a idade da chave antes de ser rotacionada), solicitada pelo administrador do banco de dados (por exemplo, emitindo set global innodb_encrypt_tables=ON; ) ou pelo sistema de gerenciamento de chaves de criptografia (consulte, por exemplo, girar chaves).
Os administradores de banco de dados precisam decidir se é suficiente criptografar apenas tabelas individuais (consulte a criptografia de dados para InnoDB) ou todo o banco de dados, incluindo o tablespace do sistema. Observe que os dados da tabela também são gravados no log de redo e log de desfazer. Assim, se o banco de dados contém tabelas que contêm dados muito sensíveis innodb-encrypt-log também deve ser habilitado. Neste blog, mostramos como criptografar todo o banco de dados.
Movendo o banco de dados para o estado criptografado
Antes que o banco de dados possa ser movido para um estado criptografado, precisamos adicionar a configuração do plug-in de criptografia ao arquivo de configuração (consulte a descrição detalhada dos 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
Após a reinicialização, o progresso da operação de criptografia pode ser monitorado na tabela INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION. No exemplo a seguir, consultamos o nome do tablespace, a página atual sob rotação de chave e a página máxima no tablespace para as tabelas que ainda não foram criptografadas:
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, você também pode consultar o status de todas as tabelas:
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 disso, podemos ver que o tablespace do sistema já está criptografado, mas a tabela customer do banco de dados tpcc1000 está sendo criptografada. Se o seu sistema tiver recursos de hardware e o processo de criptografia parecer lento, você pode tentar os seguintes 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;
A criptografia do banco de dados é concluída quando não há tabelas em um estado não criptografado:
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)
E para verificar, liste todas as tabelas que estão criptografadas:
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 pode ser visto, todos os tablespaces usam ENCRYPTION_SCHEME=1 (criptografado) e MIN_KEY_VERSION=1 . Após esta fase, o administrador do banco de dados deve considerar a diminuição do número de encadeamentos de criptografia usados e iops de rotação. Além disso, a necessidade de mais rotação de chave também deve ser considerada, pois o plug-in de gerenciamento de chave de arquivo não suporta rotação de chave real. A rotação de chaves pode ser desativada usando innodb-encryption-rotate-key-age=0 . Observe que mesmo com essa configuração todas as novas tabelas criadas são consideradas para criptografia.
Movendo o banco de dados para o estado não criptografado
Aqui assumimos que você tem um banco de dados criptografado e não há mais a necessidade de criptografar os dados ou a proteção dos dados é feita de forma diferente. Usaremos o mesmo banco de dados como exemplo para mover o banco de dados para o estado criptografado. Neste ponto, não há necessidade de reiniciar o servidor. Em vez disso, mover o banco de dados para o estado não criptografado pode ser feito como uma operação online. Primeiro, o administrador do banco de dados deve verificar se não há tabelas usando criptografia explícita, ou seja, há uma tabela em que criar tabela usou a opção de tabela ENCRYPTED=YES. Agora, mover o banco de dados para um estado não criptografado pode ser feito simplesmente emitindo:
SET GLOBAL innodb_encrypt_tables=OFF;
Isso começará a descriptografar todos os tablespaces, incluindo o tablespace do sistema e o progresso desta operação pode ser monitorado por:
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 disso, podemos ver que a tabela order_line do banco de dados tpcc1000 está sendo rotacionada. A operação é concluída quando não há tabelas usando criptografia, ou seja, 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)
Se a configuração de criptografia precisar ser removida da configuração, agora é a hora de desligar o servidor. Se a configuração usar criptografia de redo log, ou seja, innodb-encrypt-log=ON faça backups do seu banco de dados, incluindo arquivos de log do InnoDB e, em seguida, remova os arquivos de log do InnoDB, pois eles são inutilizáveis se contiverem dados criptografados.
rm -rf ib_logfile*
Remova a configuração de criptografia da configuração e reinicie o servidor. Agora você tem uma instância de banco de dados em que nenhuma criptografia é usada.
Conclusão
Mover um banco de dados para um estado criptografado como visto acima requer que o servidor seja reiniciado e requer uma configuração cuidadosa do plug-in de criptografia. A duração dessa operação depende do número de tabelas e do tamanho dessas tabelas. Apresentamos uma maneira de monitorar esse progresso e como acelerá-lo se o hardware usado tiver recursos suficientes. Mover um banco de dados para um estado não criptografado requer apenas a configuração de uma variável global. No entanto, se a criptografia for mais necessária e houver a necessidade de remover todas as referências a ela, haverá a necessidade de uma reinicialização. Mostramos como monitorar essa transição e como remover totalmente a configuração de criptografia do banco de dados e da configuração.
