Introdução
Com o aumento da atenção à segurança, seja por auditorias, conformidade com a lei e/ou para evitar vazamentos e ataques, uma das preocupações é saber se os dados do banco de dados estão criptografados. Com o MySQL é possível criptografar os dados em disco (data-at-rest), para que, em caso de roubo ou vazamento de dados físicos, a criptografia dificulte a leitura dos dados. A criptografia Transparent Data Encryption (TDE) dos dados no servidor MySQL/Percona Server 8.4 é realizada pelo componente Keyring.
Há diferentes possíveis keyrings para se utilizar, cada um com um diferente nível de segurança, nesta série de dois blogs iremos demonstrar como realizar a configuração de dois tipos:
- keyring_file — chaves em um arquivo local (este post).
- keyring_vault — chaves em cofre remoto (OpenBao/Vault) — Parte 2.
O que TDE resolve?
Criptografia de tablespaces InnoDB, logs opcionais e doublewrite; master key no keyring; rotação com ALTER INSTANCE ROTATE INNODB MASTER KEY sem reescrever todas as páginas.
Porém, ele não resolve a proteção contra uma pessoa com acesso ao servidor, nem a separação real de chave se ela mora no mesmo host, o caso do keyring_file.
Configuração
Por padrão a localização das chaves será /var/lib/mysql-keyring, caso queira outra localização, crie a pasta e dê as corretas permissões:
|
1 2 3 |
$ ls -lah [...] drwxr-x---. 2 mysql mysql 4.0K Mar 4 18:12 mysql-keyring |
Pasta criada, hora de “instalar” o keyring_file component, note que não é possível instalar-lo via INSTALL COMPONENT, isso ocorre por conta de validações que precisam ocorrer durate a inicialização do serviço antes.
Para criar o arquivo de manifesto e incializar o keyring precisamos criar o arquivo mysqld.my (json) na mesma localização do arquivo binário do mysqld, para verificar na sua instalação você pode executar o seguinte comando:
|
1 2 |
$ which mysqld /usr/sbin/mysqld |
Caso inicie o mysqld com o caminho completo (/path/to/mysqld), esse mesmo caminho deverá ser o caminho do mysqld.my (/path/to/mysqld.my).
Arquivo criado em /usr/sbin/mysql.my, preste atenção na hora de criar pra manter o padrão de JSON:
|
1 2 3 4 |
{ "read_local_manifest": false, "components": "file://component_keyring_file" } |
Após criar o manifesto, precisamos alterar o arquivo component_keyring_file.cnf, para adicionar o caminho da pasta criada no início ou o valor padrão (/var/lib/mysql-keyring/).
Para confirmar a localização deste arquivo, deve ser criado, utilize o seguinte comando:
|
1 2 3 4 5 6 7 |
mysql > SELECT @@plugin_dir; +--------------------------+ | @@plugin_dir | +--------------------------+ | /usr/lib64/mysql/plugin/ | +--------------------------+ 1 row in set (0.00 sec) |
Para o exemplo acima, vamos criar o seguinte arquivo /usr/lib64/mysql/plugin/component_keyring_file.cnf:
|
1 2 3 4 |
{ "path": "/var/lib/mysql-keyring/keyring_file", "read_only": false } |
Corrigas as permissões caso estejam incorretas:
|
1 2 3 |
$ chown mysql:mysql /usr/lib/mysql/plugin/component_keyring_file.cnf $ chmod 0640 /usr/lib/mysql/plugin/component_keyring_file.cnf $ systemctl restart mysql |
Validar TDE
Componente ativo
Para validar se o componente está ativo, verifique se o Component_name = component_keyring_file e Status = Active:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
mysql > SELECT * FROM performance_schema.keyring_component_status; +---------------------+-------------------------------------+ | STATUS_KEY | STATUS_VALUE | +---------------------+-------------------------------------+ | Component_name | component_keyring_file | | Author | Oracle Corporation | | License | GPL | | Implementation_name | component_keyring_file | | Version | 1.0 | | Component_status | Active | | Data_file | /var/lib/mysql-keyring/keyring_file | | Read_only | No | +---------------------+-------------------------------------+ 8 rows in set (0.01 sec) |
Master key e tabela cifrada
Validando a criaçào de tabelas criptografadas:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
ALTER INSTANCE ROTATE INNODB MASTER KEY; CREATE DATABASE lab; USE lab; CREATE TABLE pii ( id BIGINT PRIMARY KEY AUTO_INCREMENT, cpf CHAR(11), email VARCHAR(255) ) ENGINE=InnoDB ENCRYPTION='Y'; INSERT INTO pii (cpf, email) VALUES |
Após criar a mesma tabela pii2 porém sem ENCRYPTION=’Y’, podemos ver abaixo as opções de criação:
|
1 2 3 4 5 6 7 8 |
MySQL > SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM information_schema.TABLES WHERE TABLE_SCHEMA='lab'; +--------------+------------+----------------+ | TABLE_SCHEMA | TABLE_NAME | CREATE_OPTIONS | +--------------+------------+----------------+ | lab | pii | ENCRYPTION='Y' | | lab | pii2 | | +--------------+------------+----------------+ 2 rows in set (0.00 sec) |
Checando no disco a criptografia em ambas as tabelas:
|
1 2 3 4 5 |
$ strings /var/lib/mysql/lab/pii.ibd | grep 12345678901 || echo "Sem match (esperado)" Sem match (esperado) $ strings /var/lib/mysql/lab/pii2.ibd | grep 12345678901 || echo "Sem match (esperado)" 12345678901dba@example.com |
Rotação periódica:
|
1 |
ALTER INSTANCE ROTATE INNODB MASTER KEY; |
5. Pontos de atenção
- Um keyring por instância — nunca misture plugin legado + componente.
- Chave no mesmo host — em caso de comprometimento do host, a chave e o
.ibdvazam juntos. - Backups — restauração sem o arquivo de keyring ou sem transition-key (xtrabackup)= dados cifrados irrecuperáveis.
Conclusão
keyring_file é um bom ponto de partida para a criptografia no MySQL/Percona Server: manifest, componente, master key e tablespace cifrado. Funciona como esperado, porém, há uma preocupação: se obtém acesso à máquina, obtém acesso ao keyring_file, o que limita o uso em produção.
Próximo passo: externalizar o keyring – Parte 2: keyring_vault + OpenBao.
