← Voltar ao hub MariaDB
MariaDB 09 de novembro de 2026 10 min de leitura

Criptografia de dados em repouso no MariaDB: como ativar o TDE sem trocar de banco

Criptografia de dados em repouso no MariaDB: como ativar o TDE sem trocar de banco

Sim, o MariaDB criptografa dados em repouso de forma nativa, inclusive na edição Community: tabelas e tablespaces InnoDB, redo log, tabelas Aria, binary logs, relay logs e arquivos temporários podem ser gravados cifrados em disco, com chaves fornecidas por um plugin de gerenciamento de chaves. É o que o mercado chama de TDE (Transparent Data Encryption), e está no servidor desde o MariaDB 10.1, que trouxe "Table, Tablespace and log Encryption" na lista oficial de novidades da versão.

É uma pergunta que aparece em auditoria, due diligence e questionário de segurança de cliente grande: "o banco está criptografado?". No MariaDB, responder "sim" não exige trocar de produto. Mas exige entender o que o recurso protege — e o que não protege.

O que a criptografia em repouso do MariaDB protege?

O TDE protege o arquivo, não a consulta. Segundo a documentação oficial de Data-at-Rest Encryption, a cifragem acontece na camada de I/O: a página é criptografada quando o servidor a grava em disco e descriptografada quando é lida de volta para a memória.

Na prática, isso cobre disco ou snapshot que sai do seu controle, arquivo .ibd copiado por quem tem acesso ao sistema operacional mas não às chaves, e backup físico que vai parar onde não deveria.

O que pode ser cifrado, segundo a documentação:

  • InnoDB: todos os tablespaces, tabelas individuais e o redo log;
  • Aria: apenas tabelas com ROW_FORMAT=PAGE (que é o padrão);
  • binary logs e relay logs;
  • arquivos temporários internos em disco, com encrypt_tmp_files=ON.

O que o TDE do MariaDB não protege?

Aqui é onde vejo mais confusão, e onde o CTO precisa ser honesto com o auditor e com o próprio time. A documentação é explícita: ficam fora da criptografia os metadados (arquivos .frm e dicionário de dados), o error log, o general query log, o slow query log e o log de controle do Aria.

Pense no slow query log: ele grava o texto das consultas. Se a sua aplicação monta WHERE cpf = '...' com valores literais, esse dado vai em texto claro para um arquivo que o TDE não toca. Ou você controla o acesso a esses logs, ou desliga o que não usa.

E tem o ponto mais importante: o TDE não protege contra acesso SQL autorizado nem contra SQL injection. Quem entra com usuário e senha válidos lê o dado descriptografado, porque o servidor faz isso para ele. Também não protege dado em trânsito — para isso existe TLS. Criptografia em repouso é uma camada, não a estratégia inteira. Falo mais sobre esse conjunto no guia de limites, suporte e segurança do MariaDB para CTOs.

Como funciona o gerenciamento de chaves?

Sem plugin de chaves, não há criptografia. O MariaDB não guarda as chaves; ele pede a um plugin. Os três citados na documentação são:

  • File Key Management (file_key_management): as chaves ficam em um arquivo no servidor. É o mais simples para começar.
  • HashiCorp Key Management: busca as chaves em um HashiCorp Vault. Entrou como novidade no MariaDB 10.9.
  • AWS Key Management: integra com o KMS da AWS.

Minha opinião, depois de muitos anos vendo ambiente de produção: o plugin de arquivo é ótimo para laboratório e para empresas pequenas com um servidor bem controlado. Mas guardar a chave no mesmo disco do dado reduz bastante o valor do controle — quem leva o disco leva a chave. Se o seu cenário de ameaça inclui snapshot vazado, a chave precisa morar em outro lugar: um cofre de chaves, ou no mínimo um arquivo de chaves cifrado com a senha fora do volume de dados.

Um detalhe que costuma passar batido: a página do plugin de arquivo informa que a rotação de chaves nesse plugin só existe no Enterprise Server 11.8 em diante; no Community, não. Já o plugin da HashiCorp suporta rotação manual com FLUSH HASHICORP_KEY_MANAGEMENT_CACHE a partir do MariaDB 12.3, conforme a documentação do plugin. Se a sua política exige rotação periódica, isso pesa na escolha.

Como ativar a criptografia de dados em repouso no MariaDB?

Vou mostrar o caminho com o plugin de arquivo, porque é o que dá para testar hoje numa VM. Os comandos seguem a documentação oficial — teste em homologação antes.

1. Gerar as chaves

Cada linha do arquivo tem o formato id;chave_em_hex (no Community e no Enterprise antes do 11.8). Para gerar uma chave de 256 bits:

sudo mkdir -p /etc/mysql/encryption
echo "1;$(openssl rand -hex 32)" | sudo tee /etc/mysql/encryption/keyfile
echo "2;$(openssl rand -hex 32)" | sudo tee -a /etc/mysql/encryption/keyfile

A chave de ID 1 é especial: é a que o binary log usa.

2. (Recomendado) Cifrar o arquivo de chaves

No MariaDB 12.0 ou superior, a documentação mostra:

openssl enc -aes-256-cbc -md sha256 -pbkdf2 -iter 20000 \
  -pass file:/etc/mysql/encryption/keyfile.key \
  -in /etc/mysql/encryption/keyfile \
  -out /etc/mysql/encryption/keyfile.enc

Em versões anteriores à 12.0, o comando usa -md sha1 e não usa -pbkdf2. Depois, apague o arquivo em texto claro.

3. Configurar o servidor

Exemplo para 12.0+ com arquivo de chaves cifrado:

[mariadb]
plugin_load_add = file_key_management
loose_file_key_management_filename = /etc/mysql/encryption/keyfile.enc
loose_file_key_management_filekey = FILE:/etc/mysql/encryption/keyfile.key
loose_file_key_management_digest = sha256
loose_file_key_management_use_pbkdf2 = 20000
loose_file_key_management_encryption_algorithm = AES_CBC

innodb_encrypt_tables = ON
innodb_encrypt_log = ON
innodb_encrypt_temporary_tables = ON
innodb_encryption_threads = 4

encrypt_binlog = ON
encrypt_tmp_files = ON
aria_encrypt_tables = ON
encrypt_tmp_disk_tables = ON

Três cuidados que a documentação deixa claros e que eu reforço:

  • O algoritmo é uma decisão permanente para os dados já cifrados. O padrão é AES_CBC, e os plugins da HashiCorp e da AWS só suportam AES_CBC. Se um dia você pensa em migrar a chave para um cofre, não escolha AES_CTR agora.
  • innodb_encrypt_tables não cifra o redo log. Para isso existe innodb_encrypt_log, separado.
  • innodb_encryption_threads vem com 0. Com zero, as tabelas já existentes não são convertidas em segundo plano. Muita gente liga o recurso, vê o servidor subir e acha que acabou.

Se quiser impedir que alguém crie tabela sem criptografia, use innodb_encrypt_tables = FORCE: nesse modo, ENCRYPTED=NO passa a ser rejeitado.

4. Cifrar tabela por tabela, se preferir

Também dá para escolher tabela a tabela, inclusive com chaves diferentes, como no exemplo da visão geral de criptografia do InnoDB:

CREATE TABLE t (i INT PRIMARY KEY)
  ENGINE=InnoDB ENCRYPTED=YES ENCRYPTION_KEY_ID=2;

5. Conferir o que está cifrado

SELECT NAME, ENCRYPTION_SCHEME, CURRENT_KEY_ID, ROTATING_OR_FLUSHING
FROM information_schema.INNODB_TABLESPACES_ENCRYPTION;

ENCRYPTION_SCHEME = 1 indica tablespace cifrado; ROTATING_OR_FLUSHING mostra se as threads de fundo ainda estão trabalhando nele. Este é o print que eu levaria para o auditor — não o my.cnf.

E o binlog, a replicação e o backup?

Binlog. Com encrypt_binlog = ON, binary logs e relay logs passam a ser cifrados com a chave de ID 1. Segundo a página de criptografia de binary logs, o mariadb-binlog não descriptografa sozinho: para ler eventos, use --read-from-remote-server e deixe o servidor fazer o trabalho. Desligar a criptografia não decifra arquivos antigos, e os logs antigos em texto claro continuam lá até você removê-los com PURGE BINARY LOGS.

Replicação. A mesma página avisa que a réplica recebe os eventos sem criptografia. Ou seja: se o canal de replicação não usa TLS, o dado viaja aberto entre os servidores. TDE sem TLS na replicação é meia proteção.

Backup. O mariadb-backup copia os tablespaces como estão em disco, então o backup continua cifrado — ótimo. Mas, segundo a documentação de backup de arquivos cifrados, a ferramenta precisa de acesso às mesmas chaves no --backup e no --prepare, e as chaves não vão junto com o backup. Se você perde o arquivo de chaves ou o acesso ao cofre, perdeu o backup. Simples assim. Eu trato a chave como parte do plano de recuperação de desastres, com cópia, dono e teste de restauração. Para a rotina de backup em si, veja o guia prático do mariadb-backup.

Vale a pena ligar? Minha visão de CTO para CTO

Em mais de 40 anos de tecnologia, aprendi que segurança que depende de "ninguém vai copiar esse disco" não é segurança. A criptografia em repouso do MariaDB custa pouco para ativar e está no Community. Em banco que guarda dado pessoal, para mim, deveria ser padrão.

Mas ela não substitui nada: controle de acesso, usuários com privilégio mínimo, TLS, cuidado com os logs que não são cifrados e uma gestão de chaves séria. O erro mais caro que vejo nesse assunto não é deixar de criptografar — é criptografar sem plano para as chaves e descobrir isso no dia do restore.

Como embaixador do MariaDB no Brasil (conto mais sobre isso em MariaDB Brasil Ambassador), minha recomendação é começar em homologação, medir o impacto na sua carga, validar backup e restore com as chaves e só então levar para produção. Se quiser uma base sólida antes, os fundamentos de administração estão no meu livro Aprendendo MySQL, que continuam valendo para o MariaDB.

Perguntas frequentes

A criptografia de dados em repouso existe no MariaDB Community?

Sim. Ela existe desde o MariaDB 10.1 e funciona no Community com os plugins de arquivo, HashiCorp Vault e AWS KMS. Alguns recursos, como rotação de chaves no plugin de arquivo e criptografia do GCache do Galera, são do Enterprise Server.

Preciso reiniciar o MariaDB para ativar o TDE?

Sim, para carregar o plugin de chaves e definir variáveis como encrypt_binlog, que são lidas na inicialização. Depois disso, com innodb_encryption_threads maior que zero, as tabelas InnoDB existentes são cifradas em segundo plano.

O TDE protege contra SQL injection?

Não. Quem acessa o banco por SQL com credenciais válidas, inclusive via injeção, recebe o dado já descriptografado. O TDE protege arquivos em disco; contra SQL injection valem código seguro e privilégio mínimo.

Se eu perder o arquivo de chaves, consigo recuperar o backup?

Não. A documentação oficial é clara: sem as mesmas chaves usadas na época do backup, não há restauração. Guarde as chaves fora do servidor, com cópia e teste periódico.

O slow query log fica criptografado?

Não. Error log, general log e slow query log ficam fora da criptografia em repouso. Restrinja o acesso a esses arquivos e avalie se precisa mantê-los ligados.

Vamos conversar?

Se você está avaliando criptografia em repouso no MariaDB por causa de auditoria, LGPD ou exigência de cliente, e quer uma segunda opinião de quem vive banco de dados há décadas, fale comigo. Se o seu time precisa dominar isso por conta própria, conheça os treinamentos.