Em ambientes de banco de dados críticos, não basta apenas armazenar informações — é fundamental garantir visibilidade completa sobre as operações realizadas, incluindo quem executou, o que foi executado, quando ocorreu e em qual contexto.
Nesse cenário, a auditoria deixa de ser um diferencial e passa a ser um requisito essencial para segurança, governança e conformidade.
O Audit Log Plugin, disponível no Percona Server for MySQL e também na edição Enterprise do MySQL, oferece um mecanismo eficiente e estruturado para o registro de atividades no banco de dados.
Com ele, é possível obter rastreabilidade detalhada das operações, facilitar análises forenses e atender requisitos regulatórios como LGPD e políticas internas de auditoria.
O que é o Audit Log Plugin?
O Audit Log Plugin é um mecanismo que registra eventos ocorridos no banco de dados, como:
- Execução de queries (SELECT, INSERT, UPDATE, DELETE)
- Criação e alteração de objetos (DDL)
- Conexões e sessões de usuários
Diferente de logs tradicionais, ele permite controle granular, incluindo filtros por usuário e definição do tipo de evento a ser auditado.
Por que utilizar auditoria?
A auditoria não é apenas uma prática recomendada — em muitos cenários ela é obrigatória.
Com o Audit Log, é possível:
- Identificar alterações indevidas
- Rastrear atividades suspeitas
- Atender requisitos de auditoria (LGPD, compliance)
- Apoiar análises forenses em incidentes
Audit Log vs General Log
Uma abordagem comum para capturar atividades no MySQL é a utilização do General Log, que registra todas as conexões e queries executadas no servidor.
Embora simples de ativar, essa solução possui limitações importantes quando utilizada fora de cenários pontuais.
O Audit Log Plugin, por outro lado, foi projetado especificamente para auditoria, oferecendo maior controle, estrutura e eficiência.
Comparativo técnico
| Aspecto | Audit Log | General Log |
|---|---|---|
| Estrutura | JSON, XML, CSV (estruturado) | Texto simples |
| Filtro por usuário | Sim (granular) | Não |
| Controle de eventos | Sim (queries, conexões, etc.) | Não |
| Performance | Otimizado para auditoria | Alto overhead |
| Rotação de logs | Nativa | Manual |
| Uso em produção | Recomendado | Não recomendado |
Quando usar cada um?
O General Log pode ser útil em cenários específicos, como:
- Debug de aplicações
- Análise rápida de queries
- Diagnóstico pontual em ambiente controlado
No entanto, por registrar todas as operações sem filtro, seu uso contínuo em produção pode causar:
- Alto consumo de disco
- Impacto significativo de performance
- Dificuldade de análise devido ao volume de dados
Por que o Audit Log é mais adequado?
O Audit Log Plugin foi desenvolvido com foco em auditoria e segurança, permitindo:
- Filtragem por usuário ou tipo de evento
- Registro estruturado (facilitando parsing e integração)
- Controle de volume de dados gerados
- Melhor previsibilidade de impacto no ambiente
Na prática, isso permite implementar auditoria de forma sustentável, mesmo em ambientes com alta carga.
Ambiente e preparação
Para este laboratório, foi utilizado o Percona Server for MySQL 8.0 em ambiente Linux, com inicialização manual da instância e configuração personalizada.
O passo a passo completo (download, configuração e inicialização) :
|
1 2 3 4 5 6 7 8 9 10 |
#Download e extração do Percona cd /root wget https://downloads.percona.com/downloads/percona-distribution-mysql-ps/percona-distribution-mysql-ps-8.0.44/binary/tarball/Percona-Server-8.0.44-35-Linux.x86_64.glibc2.28.tar.gz mkdir -p /dados tar -xpzf Percona-Server-8.0.44-35-Linux.x86_64.glibc2.28.tar.gz -C /dados/ ln -s /dados/Percona-Server-8.0.44-35-Linux.x86_64.glibc2.28 /dados/perconaServer mkdir /dados/percona chown mysql:mysql /dados/percona /dados/my.cnf |
Extruturas de diretorios
|
1 2 3 4 |
mkdir -p /dados/percona/dados mkdir -p /dados/percona/audit chown -R mysql:mysql /dados/percona |
My.cnf
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
/dados/my.cnf conteudo abaixo: [client] user = root password = '' [mysqld] basedir = /dados/perconaServer port = 3384 datadir = /dados/percona/dados socket = /dados/percona/dados/mysql.sock log-error = /dados/percona/dados/mysqld.log pid-file = /dados/percona/dados/mysqld.pid |
Incialização e Serviço
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
/dados/perconaServer/bin/mysqld --defaults-file=/dados/my.cnf --user=mysql --initialize-insecure vim /etc/systemd/system/percona.service #Conteudo abaixo [Unit] Description=Percona Server After=network-online.target Wants=network-online.target [Service] User=mysql Group=mysql ExecStart=/dados/perconaServer/bin/mysqld --defaults-file=/dados/my.cnf --user=mysql Restart=on-failure RestartPreventExitStatus=1 [Install] WantedBy=multi-user.target #### service percona start ou systemctl start percona [start/stop/restart] |
Instalação do plugin
Após a inicialização do banco, o plugin pode ser instalado dinamicamente:
|
1 2 3 4 5 6 7 8 9 10 11 |
mysql -uroot --password= -S /dados/percona/dados/mysql.sock INSTALL PLUGIN audit_log SONAME 'audit_log.so'; ## criacao do user auditado ## Em ambientes de produção, essa prática não é recomendada, ## devendo-se aplicar o princípio do menor privilégio (<em data-start="497" data-end="514">least privilege</em>), ## concedendo apenas as permissões estritamente necessárias para cada usuário. create user dev identified by 'Dev@mysql8'; grant all on *.* to dev; |
A validação pode ser feita via:
|
1 2 3 |
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM information_schema.plugins WHERE PLUGIN_NAME = 'audit_log'; |
Demonstração prática
Após a ativação do plugin, qualquer ação executada pode ser auditada.
Exemplo:
|
1 2 |
CREATE DATABASE world; use world; |
Essas operações geram registros como:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
## OLD <AUDIT_RECORD NAME="Query" RECORD="20_2026-04-19T16:52:54" TIMESTAMP="2026-04-19T17:00:14Z" COMMAND_CLASS="create_db" CONNECTION_ID="10" STATUS="0" SQLTEXT="create database world" USER="dev[dev] @ localhost []" HOST="localhost" OS_USER="" IP="" DB="" /> <AUDIT_RECORD NAME="Query" RECORD="21_2026-04-19T16:52:54" TIMESTAMP="2026-04-19T17:00:19Z" COMMAND_CLASS="select" CONNECTION_ID="10" STATUS="0" SQLTEXT="SELECT DATABASE()" USER="dev[dev] @ localhost []" HOST="localhost" OS_USER="" IP="" DB="" /> |
Esse tipo de registro permite identificar claramente:
- Usuário responsável
- Tipo de operação
- Comando executado
- Momento da execução
Formatos de saída
O Audit Log Plugin suporta múltiplos formatos, cada um com seu caso de uso.
XML NEW
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
<AUDIT_RECORD> <NAME>Query</NAME> <RECORD>2444_2026-04-19T17:04:59</RECORD> <TIMESTAMP>2026-04-19T17:06:18Z</TIMESTAMP> <COMMAND_CLASS>select</COMMAND_CLASS> <CONNECTION_ID>9</CONNECTION_ID> <STATUS>0</STATUS> <SQLTEXT>SELECT DATABASE()</SQLTEXT> <USER>root[root] @ localhost []</USER> <HOST>localhost</HOST> <OS_USER></OS_USER> <IP></IP> <DB></DB> </AUDIT_RECORD> <AUDIT_RECORD> <NAME>Init DB</NAME> <RECORD>2445_2026-04-19T17:04:59</RECORD> <TIMESTAMP>2026-04-19T17:06:18Z</TIMESTAMP> <COMMAND_CLASS>init db</COMMAND_CLASS> <CONNECTION_ID>9</CONNECTION_ID> <STATUS>0</STATUS> <SQLTEXT></SQLTEXT> <USER>root[root] @ localhost []</USER> <HOST>localhost</HOST> <OS_USER></OS_USER> <IP></IP> <DB></DB> </AUDIT_RECORD> |
Formato estruturado e detalhado, porém mais verboso.
CSV
|
1 2 3 |
"Query","2645_2026-04-19T17:07:54","2026-04-19T17:08:19Z","create_db","9",0,"create database world","root[root] @ localhost []","localhost","","","" "Query","2646_2026-04-19T17:07:54","2026-04-19T17:08:23Z","select","9",0,"SELECT DATABASE()","root[root] @ localhost []","localhost","","","" "Init DB","2647_2026-04-19T17:07:54","2026-04-19T17:08:23Z","init db","9",0,"","root[root] @ localhost []","localhost","","","" |
Indicado para importação rápida em ferramentas externas.
JSON (recomendado)
Exemplo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
{ "audit_record": { "name": "Query", "record": "1173_2026-04-19T17:09:02", "timestamp": "2026-04-19T17:11:05Z", "command_class": "create_db", "connection_id": "9", "status": 0, "sqltext": "create database world", "user": "root[root] @ localhost []", "host": "localhost", "os_user": "", "ip": "", "db": "" } } { "audit_record": { "name": "Query", "record": "1174_2026-04-19T17:09:02", "timestamp": "2026-04-19T17:11:09Z", "command_class": "select", "connection_id": "9", "status": 0, "sqltext": "SELECT DATABASE()", "user": "root[root] @ localhost []", "host": "localhost", "os_user": "", "ip": "", "db": "" } } |
O formato JSON facilita integração com soluções de observabilidade.
Imagens:
Configuração avançada
Uma das grandes vantagens do Audit Log é a flexibilidade de configuração.
Filtro por usuário
|
1 |
audit_log_include_accounts = dev@localhost,dev@% |
Permite auditar apenas usuários específicos, reduzindo volume de logs.
Política de auditoria
|
1 |
audit_log_policy = QUERIES # opcoes ALL/LOGINS/QUERIES/NONE |
Define quais eventos serão capturados.
Nesse caso, apenas queries (SELECT + DML).
Configuração recomendada
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
## adicionados ao my.cnf # ========================= # AUDIT LOG CONFIGURATION # ========================= # Carregar o plugin de auditoria na inicialização plugin-load-add=audit_log.so # Auditar apenas o usuário dev audit_log_include_accounts=dev@localhost,dev@% # Tipo de auditoria (queries = SELECT + DML) audit_log_policy=QUERIES # Formato do log [ JSON, CSV, NEW , OLD ] audit_log_format=JSON # Arquivo de saída audit_log_file=/dados/percona/audit/auditoria.log # Buffer (256MB em bytes) audit_log_buffer_size=256MB # Flush imediato no disco audit_log_flush=ON # Controla crescimento do log e evita consumo excessivo de disco. # Rotacionar arquivo ao atingir 5M para teste audit_log_rotate_on_size=5242880 # Manter apenas 2 arquivo rotacionado para teste audit_log_rotations=2 |
Essa configuração garante:
- Persistência imediata
- Formato estruturado
- Facilidade de integração
Considerações finais
O uso do Audit Log Plugin é altamente recomendado em ambientes que exigem controle, rastreabilidade e governança sobre as operações realizadas no banco de dados.
Quando devidamente configurado, o recurso:
- Apresenta baixo impacto de performance
- Fornece visibilidade detalhada das operações
- Permite auditoria seletiva, reduzindo volume e ruído nos logs
Todos os procedimentos, comandos e configurações apresentados neste artigo foram validados em ambiente de laboratório executando Oracle Linux 8.10, com 4 GB de memória RAM, utilizando o Percona Server for MySQL versão 8.0.44-35 (Release 35), garantindo consistência e reprodutibilidade dos testes realizados.
Ressalta-se que os cenários apresentados tiveram caráter demonstrativo. Em ambientes de produção, é fundamental realizar análises adicionais, incluindo avaliação de carga, volume de logs gerados, estratégia de retenção, impacto em disco e adequação das políticas de auditoria às necessidades específicas do negócio.
Referência
https://docs.percona.com/percona-server/8.0/audit-log-plugin.html
