Consejos y trucos con el registro de auditoría para MariaDB

El complemento de auditoría de MariaDB proporciona funcionalidad de auditoría no solo para MariaDB sino también para MySQL (a partir de la versión 5.5.34 y 10.0.7) y Percona Server. MariaDB comenzó a incluir por defecto el Audit Plugin desde las versiones 10.0.10 y 5.5.37, y se puede instalar en cualquier versión desde MariaDB 5.5.20.

El propósito del complemento de auditoría de MariaDB es registrar la actividad del servidor. Para cada sesión de cliente, registra quién se conectó al servidor (es decir, el nombre de usuario y el host), qué consultas se ejecutaron, a qué tablas se accedió y qué variables del servidor se modificaron. Esta información se almacena en un archivo de registro giratorio o se puede enviar al syslogd local.

En esta publicación de blog, le mostraremos algunos ajustes de mejores prácticas y consejos sobre cómo configurar el registro de auditoría para un servidor MariaDB. La escritura se basa en MariaDB 10.5.9, con la última versión de MariaDB Audit Plugin 1.4.4.

Ajuste de instalación

La forma recomendada de habilitar el registro de auditoría es establecer las siguientes líneas dentro del archivo de configuración de 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

No olvide configurar "server_audit=FORCE_PLUS_PERMANENT" para hacer cumplir el registro de auditoría y no permitir que otros usuarios lo desinstalen mediante la instrucción UNINSTALL SONAME. De forma predeterminada, el destino de registro es un archivo de registro en el directorio de datos de MariaDB. Deberíamos colocar el registro de auditoría fuera de este directorio porque existe la posibilidad de que el directorio de datos se elimine (SST para Galera Cluster) o se reemplace por una restauración física como el intercambio de directorio de datos al restaurar una copia de seguridad tomada de MariaDB Backup.

Es necesario realizar más ajustes, como se muestra en las siguientes secciones.

Filtrado de eventos de auditoría

El complemento MariaDB Audit utiliza varias configuraciones de registro que dependen de la versión del complemento. Los siguientes eventos de auditoría están disponibles en la última versión del complemento 1.4.4:

Tipo	Descripción
CONECTAR	Conexiones, desconexiones y conexiones fallidas, incluido el código de error
CONSULTA	Consultas ejecutadas y sus resultados en texto sin formato, incluidas consultas fallidas debido a errores de sintaxis o permisos
TABLA	Tablas afectadas por la ejecución de consultas
CONSULTA_DDL	Similar a QUERY, pero filtra solo consultas de tipo DDL (CREATE, ALTER, DROP, RENAME y TRUNCATE, excepto CREATE/DROP [PROCEDURE / FUNCTION / USER] y RENAME USER (que no eres DDL)
QUERY_DML	Similar a QUERY, pero filtra solo consultas de tipo DML (DO, CALL, LOAD DATA/XML, DELETE, INSERT, SELECT, UPDATE, HANDLER y REPLACE)
QUERY_DML_NO_SELECT	Similar a QUERY_DML, pero no registra consultas SELECT. (desde la versión 1.4.4) (instrucciones DO, CALL, LOAD DATA/XML, DELETE, INSERT, UPDATE, HANDLER y REPLACE)
QUERY_DCL	Similar a QUERY, pero filtra solo consultas de tipo DCL (CREATE USER, DROP USER, RENAME USER, GRANT, REVOKE y SET PASSWORD)

De forma predeterminada, realizará un seguimiento de todo, ya que la variable server_audit_events estará vacía de forma predeterminada. Tenga en cuenta que las versiones anteriores tienen menos soporte para el tipo de operación anterior, como se muestra aquí. Así que asegúrese de estar ejecutando la última versión si desea realizar un filtrado específico.

Si la caché de consultas está habilitada y se devuelve una consulta desde la caché de consultas, no aparecerán registros TABLE en el registro, ya que el servidor no abrió ni accedió a ninguna tabla y, en cambio, se basó en la caché. resultados. Por lo tanto, es posible que desee deshabilitar el almacenamiento en caché de consultas.

Para filtrar eventos específicos, configure la siguiente línea dentro del archivo de configuración de MariaDB (requiere reiniciar):

server_audit_events = 'CONNECT,QUERY,TABLE'

O configúrelo dinámicamente en tiempo de ejecución usando SET GLOBAL (no requiere reinicio, pero no persistente):

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

Este es el ejemplo de un evento de auditoría:

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

Una entrada de este registro consiste en un montón de información separada por una coma que contiene la siguiente información:

Marca de tiempo
El host MySQL (idéntico al valor de SELECT @@hostname)
El usuario de la base de datos
Host donde el usuario se estaba conectando
ID de conexión
ID de hilo
Operación
Base de datos
instrucción/comando SQL
Código de retorno. 0 significa que la operación devuelve una respuesta correcta (incluso vacía), mientras que un valor distinto de cero significa un error al ejecutar la operación como una consulta fallida debido a errores de sintaxis o de permiso.

Al filtrar las entradas, uno haría un grep simple y buscaría un patrón 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 defecto, todos los valores de las contraseñas estarán enmascarados con 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

Filtrado de usuarios de auditoría

Si realiza un seguimiento de todo, probablemente se verá inundado con el usuario de supervisión por su responsabilidad de muestreo, como se muestra en el siguiente ejemplo:

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

En el lapso de un segundo, podemos ver 14 eventos QUERY registrados por el complemento de auditoría para nuestro usuario de monitoreo llamado "cmon". En nuestra carga de trabajo de prueba, la tasa de registro es de alrededor de 32 KB por minuto, que acumulará hasta 46 MB por día. Según el tamaño del almacenamiento y la capacidad de E/S, esto podría ser excesivo en algunas cargas de trabajo. Por lo tanto, sería mejor filtrar al usuario de monitoreo del registro de auditoría, para que podamos tener un resultado más limpio y sea mucho más fácil de auditar y analizar.

Dependiendo de las políticas de seguridad y auditoría, podríamos filtrar a los usuarios no deseados como el usuario de monitoreo usando la siguiente variable dentro del archivo de configuración de MariaDB (requiere reinicio):

server_audit_excl_users='cmon'

O configúrelo dinámicamente en tiempo de ejecución usando SET GLOBAL (no requiere reinicio, pero no persistente):

MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'

Puede agregar varios usuarios de la base de datos, separados por comas. Después de agregar lo anterior, obtuvimos registros de auditoría más limpios, como se muestra a continuación (ya nada del usuario 'vamos'):

$ 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

Gestión de rotación de registros

Dado que el registro de auditoría capturará una gran cantidad de eventos, se recomienda configurar una rotación de registro adecuada para él. De lo contrario, terminaríamos con un archivo de registro de enorme tamaño que lo hace muy difícil de analizar. Mientras el servidor se está ejecutando y server_audit_output_type=file, podemos forzar la rotación del archivo de registro usando la siguiente instrucción:

MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;

Para la rotación automática de registros, debemos establecer las siguientes variables dentro del archivo de configuración de MariaDB:

server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30

O configúrelo dinámicamente en tiempo de ejecución usando SET GLOBAL (no requiere reinicio):

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

Para deshabilitar la rotación de registros de auditoría, simplemente establezca server_audit_file_rotations en 0. El valor predeterminado es 9. La rotación de registros ocurrirá automáticamente después de alcanzar el umbral especificado y mantendrá los últimos 30 registros, lo que significa que registros de auditoría de los últimos 30 días.

Auditoría usando Syslog o Rsyslog Facility

Usar la función syslog o rsyslog facilitará la administración de registros porque permite el registro de diferentes tipos de sistemas en un repositorio central. En lugar de mantener otro componente de registro, podemos indicarle a MariaDB Audit que inicie sesión en syslog. Esto es útil si tiene un recolector/transmisor de registros para servicios de análisis de registros como Splunk, LogStash, Loggly o Amazon CloudWatch.

Para hacer esto, configure las siguientes líneas dentro del archivo de configuración de MariaDB (requiere reiniciar):

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

O si desea cambiar en el tiempo de ejecución (no requiere reinicio, pero no persistente):

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

Las entradas serán similares al 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

Si desea configurar un servicio de registro remoto para un repositorio de registro centralizado, podemos usar rsyslog. El truco es usar la variable server_audit_syslog_facility donde podemos crear un filtro para facilitar el registro, similar al siguiente:

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';

Sin embargo, hay algunos pasos de requisitos previos. Considere la siguiente arquitectura de replicación maestro-esclavo de MariaDB con un servidor rsyslog centralizado:

En este ejemplo, todos los servidores se ejecutan en Ubuntu 20.04. En el servidor de destino de rsyslog, debemos configurar lo siguiente 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
& ~

Tenga en cuenta que la parte "&~" es importante y no se la pierda. Básicamente, le dice a la instalación de registro que inicie sesión en /var/log/mariadb-centralized-audit.log y detenga el procesamiento posterior justo después de eso.

A continuación, cree el archivo de registro de destino con la propiedad y el permiso de archivo correctos:

$ 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

Asegúrese de que escucha en todas las direcciones IP accesibles en el puerto 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

Hemos completado la configuración del servidor rsyslog de destino. Ahora estamos listos para configurar la parte fuente. En el servidor MariaDB, cree un nuevo archivo de configuración de rsyslog independiente en /etc/rsyslog.d/50-mariadb-audit.conf y agregue las siguientes líneas:

$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")

La configuración en la primera sección trata sobre la creación de una cola en el disco, que se recomienda para no perder ninguna entrada de registro. La última línea es importante. Cambiamos la variable server_audit_syslog_facility a LOG_LOCAL6 para el complemento de auditoría. Aquí, especificamos "local6.*" como filtro para reenviar solo las entradas de Syslog usando la función local6 a rsyslog que se ejecuta en el servidor rsyslog 172.31.6.200, en el puerto 514 a través del protocolo TCP.

Para activar los cambios para rsyslog, el último paso es reiniciar rsyslog en el servidor MariaDB para activar los cambios:

$ systemctl restart rsyslog

Ahora, rsyslog está configurado correctamente en el nodo de origen. Podemos probar accediendo al servidor MariaDB y realizar algunas actividades para generar eventos de auditoría. Debería ver que las entradas del registro de auditoría se reenvían aquí:

$ 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

Reflexiones finales

MariaDB Audit Plugin se puede configurar de muchas maneras para adaptarse a sus políticas de seguridad y auditoría. La información de auditoría puede ayudarlo a solucionar problemas de rendimiento o de aplicaciones, y le permite ver exactamente qué consultas SQL se están procesando.