Dicas e truques usando o log de auditoria para MariaDB

O plug-in de auditoria do MariaDB fornece funcionalidade de auditoria não apenas para o MariaDB, mas também para o MySQL (a partir da versão 5.5.34 e 10.0.7) e o Percona Server. O MariaDB passou a incluir por padrão o Plugin de Auditoria das versões 10.0.10 e 5.5.37, e pode ser instalado em qualquer versão do MariaDB 5.5.20.

O objetivo do MariaDB Audit Plugin é registrar a atividade do servidor. Para cada sessão do cliente, ele registra quem se conectou ao servidor (ou seja, nome de usuário e host), quais consultas foram executadas e quais tabelas foram acessadas e variáveis do servidor que foram alteradas. Essas informações são armazenadas em um arquivo de log rotativo ou podem ser enviadas para o syslogd local.

Nesta postagem do blog, mostraremos alguns ajustes de práticas recomendadas e dicas sobre como configurar o log de auditoria para um servidor MariaDB. A escrita é baseada no MariaDB 10.5.9, com a última versão do MariaDB Audit Plugin 1.4.4.

Ajuste de instalação

A maneira recomendada de habilitar o log de auditoria é definindo as seguintes linhas dentro do arquivo de configuração do MariaDB:

[mariadb]
plugin_load_add = server_audit # load plugin
server_audit=FORCE_PLUS_PERMANENT  # do not allow users to uninstall plugin
server_audit_file_path=/var/log/mysql/mariadb-audit.log # path to the audit log
server_audit_logging=ON  # enable audit logging

Não se esqueça de definir "server_audit=FORCE_PLUS_PERMANENT" para impor o log de auditoria e não permitir que ele seja desinstalado por outros usuários usando a instrução UNINSTALL SONAME. Por padrão, o destino do log é um arquivo de log no diretório de dados do MariaDB. Devemos colocar o log de auditoria fora deste diretório porque há uma chance de que o datadir seja apagado (SST para Galera Cluster), ou seja substituído por uma restauração física como troca de datadir ao restaurar um backup obtido do MariaDB Backup.

Ajustes adicionais são necessários, conforme mostrado nas seções a seguir.

Filtragem de eventos de auditoria

O plugin MariaDB Audit utiliza várias configurações de log que dependem da versão do plugin. Os seguintes eventos de auditoria estão disponíveis na versão mais recente do plug-in 1.4.4:

Tipo	Descrição
CONECTAR	Conexões, desconexões e conexões com falha, incluindo o código de erro
QUERY	Consultas executadas e seus resultados em texto simples, incluindo consultas com falha devido a erros de sintaxe ou permissão
TABELA	Tabelas afetadas pela execução da consulta
QUERY_DDL	Semelhante a QUERY, mas filtra apenas consultas do tipo DDL (instruções CREATE, ALTER, DROP, RENAME e TRUNCATE - exceto CREATE/DROP [PROCEDURE / FUNCTION / USER] e RENAME USER (elas não é DDL)
QUERY_DML	Semelhante a QUERY, mas filtra apenas consultas do tipo DML (instruções DO, CALL, LOAD DATA/XML, DELETE, INSERT, SELECT, UPDATE, HANDLER e REPLACE)
QUERY_DML_NO_SELECT	Semelhante a QUERY_DML, mas não registra consultas SELECT. (desde a versão 1.4.4) (instruções DO, CALL, LOAD DATA/XML, DELETE, INSERT, UPDATE, HANDLER e REPLACE)
QUERY_DCL	Semelhante a QUERY, mas filtra apenas consultas do tipo DCL (instruções CREATE USER, DROP USER, RENAME USER, GRANT, REVOKE e SET PASSWORD)

Por padrão, ele rastreará tudo, pois a variável server_audit_events será definida como vazia por padrão. Observe que as versões mais antigas têm menos suporte para o tipo de operação acima, conforme mostrado aqui. Portanto, verifique se você está executando a versão mais recente se quiser fazer uma filtragem específica.

Se o cache de consulta estiver ativado e uma consulta for retornada do cache de consulta, nenhum registro TABLE aparecerá no log, pois o servidor não abriu ou acessou nenhuma tabela e, em vez disso, confiou no cache resultados. Então você pode querer desabilitar o cache de consulta.

Para filtrar eventos específicos, defina a seguinte linha dentro do arquivo de configuração do MariaDB (requer reinicialização):

server_audit_events = 'CONNECT,QUERY,TABLE'

Ou defina-o dinamicamente no tempo de execução usando SET GLOBAL (não requer reinicialização, mas não é persistente):

MariaDB> SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';

Este é o exemplo de um evento de auditoria:

20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,226,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0

Uma entrada deste log consiste em um monte de informações separadas por uma vírgula contendo as seguintes informações:

Timestamp
O host MySQL (idêntico ao valor de SELECT @@hostname)
O usuário do banco de dados
Host onde o usuário estava se conectando
ID de conexão
ID do tópico
Operação
Banco de dados
instrução/comando SQL
Código de retorno. 0 significa que a operação retorna uma resposta de sucesso (mesmo vazia), enquanto um valor diferente de zero significa um erro ao executar a operação, como uma consulta com falha devido a erros de sintaxe ou permissão.

Ao filtrar as entradas, deve-se fazer um simples grep e procurar um padrão específico:

$ grep -i global /var/lib/mysql/server_audit.log
20210325 04:19:17,ip-172-31-0-44,root,localhost,14,37080,QUERY,,'set global server_audit_file_rotate_now = 1',0
20210326 00:46:48,ip-172-31-0-44,root,localhost,35,329003,QUERY,,'set global server_audit_output_type = \'syslog\'',0

Por padrão, todos os valores de senhas serão mascarados com asteriscos:

20210326 05:39:41,ip-172-31-0-44,root,localhost,52,398793,QUERY,mysql,'GRANT ALL PRIVILEGES ON sbtest.* TO [email protected] IDENTIFIED BY *****',0

Filtragem de usuário de auditoria

Se você rastrear tudo, provavelmente será inundado com o usuário de monitoramento por sua responsabilidade de amostragem, conforme mostrado no exemplo abaixo:

20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,226,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,227,QUERY,information_schema,'select @@global.wsrep_provider_options',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,228,QUERY,information_schema,'SHOW SLAVE STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,229,QUERY,information_schema,'SHOW MASTER STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,230,QUERY,information_schema,'SHOW SLAVE HOSTS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,231,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,232,QUERY,information_schema,'select @@global.wsrep_provider_options',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,233,QUERY,information_schema,'SHOW SLAVE STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,234,QUERY,information_schema,'SHOW MASTER STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,235,QUERY,information_schema,'SHOW SLAVE HOSTS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,5,236,QUERY,information_schema,'SET GLOBAL SLOW_QUERY_LOG=0',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,5,237,QUERY,information_schema,'FLUSH /*!50500 SLOW */ LOGS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,6,238,QUERY,information_schema,'SHOW GLOBAL STATUS',0

No espaço de um segundo, podemos ver 14 eventos QUERY registrados pelo plug-in de auditoria para nosso usuário de monitoramento chamado "cmon". Em nossa carga de trabalho de teste, a taxa de registro é de cerca de 32 KB por minuto, que acumulará até 46 MB por dia. Dependendo do tamanho do armazenamento e da capacidade de E/S, isso pode ser excessivo em algumas cargas de trabalho. Portanto, seria melhor filtrar o usuário de monitoramento do log de auditoria, para que pudéssemos ter uma saída mais limpa e muito mais fácil de auditar e analisar.

Dependendo das políticas de segurança e auditoria, podemos filtrar o usuário indesejado como o usuário de monitoramento usando a seguinte variável dentro do arquivo de configuração do MariaDB (requer reinicialização):

server_audit_excl_users='cmon'

Ou defina-o dinamicamente no tempo de execução usando SET GLOBAL (não requer reinicialização, mas não é persistente):

MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'

Você pode adicionar vários usuários do banco de dados, separados por vírgula. Depois de adicionar o acima, obtivemos logs de auditoria mais limpos, como abaixo (nada mais do usuário 'cmon'):

$ tail -f /var/log/mysql/mysql-audit.log
20210325 04:16:06,ip-172-31-0-44,cmon,172.31.1.119,6,36218,QUERY,information_schema,'SHOW GLOBAL STATUS',0
20210325 04:16:06,ip-172-31-0-44,root,localhost,13,36219,QUERY,,'set global server_audit_excl_users = \'cmon\'',0
20210325 04:16:09,ip-172-31-0-44,root,localhost,13,36237,QUERY,,'show global variables like \'%server_audit%\'',0
20210325 04:16:12,ip-172-31-0-44,root,localhost,13,0,DISCONNECT,,,0

Gerenciamento de rotação de log

Como o log de auditoria irá capturar um grande número de eventos, é recomendável configurar uma rotação de log adequada para ele. Caso contrário, teríamos um arquivo de log de tamanho enorme, o que dificultaria muito a análise. Enquanto o servidor estiver em execução e server_audit_output_type=file, podemos forçar a rotação do arquivo de log usando a seguinte instrução:

MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;

Para rotação automática de log, devemos definir as seguintes variáveis dentro do arquivo de configuração do MariaDB:

server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30

Ou defina-o dinamicamente no tempo de execução usando SET GLOBAL (não requer reinicialização):

MariaDB> SET GLOBAL server_audit_file_rotate_size=1000000;
MariaDB> SET GLOBAL server_audit_file_rotations=30;

Para desabilitar a rotação do log de auditoria, basta definir server_audit_file_rotations como 0. O valor padrão é 9. A rotação do log acontecerá automaticamente após atingir o limite especificado e manterá os últimos 30 logs, o que significa que o últimos 30 dias de registro de auditoria.

Auditoria usando Syslog ou Rsyslog Facility

O uso do recurso syslog ou rsyslog facilitará o gerenciamento de logs, pois permite o log de diferentes tipos de sistemas em um repositório central. Em vez de manter outro componente de registro, podemos instruir o MariaDB Audit a registrar no syslog. Isso é útil se você tiver um coletor/streamer de logs para serviços de analisador de logs como Splunk, LogStash, Loggly ou Amazon CloudWatch.

Para fazer isso, defina as seguintes linhas dentro do arquivo de configuração do MariaDB (requer reinicialização):

server_audit_logging = 'syslog'
server_audit_syslog_ident = 'mariadb-audit'

Ou se você quiser mudar no tempo de execução (não requer reinicialização, mas não persistente):

MariaDB> SET GLOBAL server_audit_logging = 'syslog';
MariaDB> SET GLOBAL server_audit_syslog_ident = 'mariadb-audit';

As entradas serão semelhantes ao formato Syslog:

$ grep mariadb-audit /var/log/syslog
Mar 26 00:48:49 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,36,329540,QUERY,,'SET GLOBAL server_audit_syslog_ident = \'mariadb-audit\'',0
Mar 26 00:48:54 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,36,0,DISCONNECT,,,0

Se você deseja configurar um serviço de log remoto para um repositório de log centralizado, podemos usar o rsyslog. O truque é usar a variável server_audit_syslog_facility onde podemos criar um filtro para facilitar o log, semelhante ao abaixo:

MariaDB> SET GLOBAL server_audit_logging = 'syslog';
MariaDB> SET GLOBAL server_audit_syslog_ident = 'mariadb-audit';
MariaDB> SET GLOBAL server_audit_syslog_facility = 'LOG_LOCAL6';

No entanto, existem algumas etapas de pré-requisitos de antemão. Considere a seguinte arquitetura de replicação mestre-escravo MariaDB com um servidor rsyslog centralizado:

Neste exemplo, todos os servidores estão rodando no Ubuntu 20.04. No servidor de destino rsyslog, precisamos definir o seguinte dentro de /etc/rsyslog.conf:

module(load="imtcp")
input(type="imtcp" port="514")
$ModLoad imtcp
$InputTCPServerRun 514
if $fromhost-ip=='172.31.0.44' then /var/log/mariadb-centralized-audit.log
& ~
if $fromhost-ip=='172.31.0.82' then /var/log/mariadb-centralized-audit.log
& ~

Observe que a parte "&~" é importante e não a perca. Ele basicamente diz ao recurso de registro para fazer login em /var/log/mariadb-centralized-audit.log e parar o processamento adicional logo depois disso.

Em seguida, crie o arquivo de log de destino com a propriedade e a permissão corretas do arquivo:

$ touch /var/log/mariadb-centralized-audit.log
$ chown syslog:adm /var/log/mariadb-centralized-audit.log
$ chmod 640 /var/log/mariadb-centralized-audit.log

Reiniciar rsyslog:

$ systemctl restart rsyslog

Certifique-se de que ele escute em todos os endereços IP acessíveis na porta TCP 514:

$ netstat -tulpn | grep rsyslog
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      3143247/rsyslogd
tcp6       0      0 :::514                  :::*                    LISTEN      3143247/rsyslogd

Concluímos a configuração do servidor rsyslog de destino. Agora estamos prontos para configurar a parte de origem. No servidor MariaDB, crie um novo arquivo de configuração rsyslog separado em /etc/rsyslog.d/50-mariadb-audit.conf e adicione as seguintes linhas:

$WorkDirectory /var/lib/rsyslog # where to place spool files
$ActionQueueFileName queue1     # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g     # 1GB space limit (use as much as possible)
$ActionQueueSaveOnShutdown on   # save messages to disk on shutdown
$ActionQueueType LinkedList     # run asynchronously
$ActionResumeRetryCount -1      # infinite retries if rsyslog host is down
local6.* action(type="omfwd" target="172.31.6.200" port="514" protocol="tcp")

As configurações na primeira seção tratam da criação de uma fila em disco, o que é recomendado para não perder nenhuma entrada de log. A última linha é importante. Alteramos a variável server_audit_syslog_facility para LOG_LOCAL6 para o plug-in de auditoria. Aqui, especificamos "local6.*" como um filtro para encaminhar apenas entradas Syslog usando o recurso local6 para rsyslog rodando no servidor rsyslog 172.31.6.200, na porta 514 via protocolo TCP.

Para ativar as alterações do rsyslog, o último passo é reiniciar o rsyslog no servidor MariaDB para ativar as alterações:

$ systemctl restart rsyslog

Agora, o rsyslog está configurado corretamente no nó de origem. Podemos testar acessando o servidor MariaDB e realizar algumas atividades para gerar eventos de auditoria. Você deve ver que as entradas do log de auditoria são encaminhadas aqui:

$ tail -f /var/log/mariadb-centralized-audit.log
Mar 26 12:56:18 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,0,CONNECT,,,0
Mar 26 12:56:18 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,489413,QUERY,,'select @@version_comment limit 1',0
Mar 26 12:56:19 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,489414,QUERY,,'show databases',0
Mar 26 12:56:37 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,0,DISCONNECT,,,0

Considerações finais

O plug-in de auditoria MariaDB pode ser configurado de várias maneiras para se adequar às suas políticas de segurança e auditoria. As informações de auditoria podem ajudá-lo a solucionar problemas de desempenho ou de aplicativos e permitem que você veja exatamente quais consultas SQL estão sendo processadas.