Suggerimenti e trucchi utilizzando Audit Logging per MariaDB

L'Audit Plugin di MariaDB fornisce funzionalità di auditing non solo per MariaDB ma anche per MySQL (a partire dalla versione 5.5.34 e 10.0.7) e Percona Server. MariaDB ha iniziato a includere per impostazione predefinita Audit Plugin dalle versioni 10.0.10 e 5.5.37 e può essere installato in qualsiasi versione da MariaDB 5.5.20.

Lo scopo di MariaDB Audit Plugin è registrare l'attività del server. Per ogni sessione client, registra chi si è connesso al server (ovvero, nome utente e host), quali query sono state eseguite e quali tabelle sono state accedute e variabili del server che sono state modificate. Queste informazioni vengono memorizzate in un file di registro rotante o possono essere inviate al syslogd locale.

In questo post del blog, ti mostreremo alcune ottimizzazioni delle migliori pratiche e suggerimenti su come configurare la registrazione di controllo per un server MariaDB. La scrittura è basata su MariaDB 10.5.9, con l'ultima versione di MariaDB Audit Plugin 1.4.4.

Regolazione dell'installazione

Il modo consigliato per abilitare la registrazione di controllo è impostare le seguenti righe all'interno del file di configurazione di 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

Non dimenticare di impostare "server_audit=FORCE_PLUS_PERMANENT" per imporre il registro di controllo e impedirne la disinstallazione da parte di altri utenti utilizzando l'istruzione UNINSTALL SONAME. Per impostazione predefinita, la destinazione di registrazione è un file di registro nella directory dei dati di MariaDB. Dovremmo mettere il registro di controllo al di fuori di questa directory perché c'è la possibilità che la datadir venga cancellata (SST per Galera Cluster) o venga sostituita per un ripristino fisico come lo scambio di datadir durante il ripristino di un backup preso da MariaDB Backup.

Sono necessarie ulteriori regolazioni, come mostrato nelle sezioni seguenti.

Filtraggio eventi di controllo

Il plug-in Audit di MariaDB utilizza diverse impostazioni di registro che dipendono dalla versione del plug-in. I seguenti eventi di controllo sono disponibili sull'ultima versione del plug-in 1.4.4:

Digita	Descrizione
CONNESSIONE	Connette, disconnette e non riesce, incluso il codice di errore
QUERY	Query eseguite e relativi risultati in testo normale, comprese le query non riuscite dovute a sintassi o errori di autorizzazione
TABELLA	Tabelle interessate dall'esecuzione della query
QUERY_DDL	Simile a QUERY, ma filtra solo le query di tipo DDL (istruzioni CREATE, ALTER, DROP, RENAME e TRUNCATE - eccetto CREATE/DROP [PROCEDURE / FUNCTION / USER] e RENAME USER (loro non sono DDL)
QUERY_DML	Simile a QUERY, ma filtra solo le query di tipo DML (istruzioni DO, CALL, LOAD DATA/XML, DELETE, INSERT, SELECT, UPDATE, HANDLER e REPLACE)
QUERY_DML_NO_SELECT	Simile a QUERY_DML, ma non registra le query SELECT. (dalla versione 1.4.4) (istruzioni DO, CALL, LOAD DATA/XML, DELETE, INSERT, UPDATE, HANDLER e REPLACE)
QUERY_DCL	Simile a QUERY, ma filtra solo le query di tipo DCL (istruzioni CREATE USER, DROP USER, RENAME USER, GRANT, REVOKE e SET PASSWORD)

Per impostazione predefinita, terrà traccia di tutto poiché la variabile server_audit_events sarà impostata su vuota per impostazione predefinita. Si noti che le versioni precedenti hanno meno supporto per il tipo di operazione sopra, come mostrato qui. Quindi assicurati di essere in esecuzione sull'ultima versione se desideri eseguire filtri specifici.

Se la cache delle query è abilitata e viene restituita una query dalla cache delle query, nel registro non verrà visualizzato alcun record TABLE poiché il server non ha aperto o non ha avuto accesso ad alcuna tabella e si è invece affidato alla cache risultati. Quindi potresti voler disabilitare la memorizzazione nella cache delle query.

Per filtrare eventi specifici, imposta la seguente riga all'interno del file di configurazione di MariaDB (richiede il riavvio):

server_audit_events = 'CONNECT,QUERY,TABLE'

Oppure impostalo dinamicamente nel runtime usando SET GLOBAL (non richiede riavvio, ma non persistente):

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

Questo è l'esempio di un evento di controllo:

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

Una voce di questo registro è costituita da un insieme di informazioni separate da una virgola contenenti le seguenti informazioni:

Timestamp
L'host MySQL (identico al valore di SELECT @@hostname)
L'utente del database
Host su cui si stava connettendo l'utente
ID connessione
ID thread
Operazione
Database
Istruzione/comando SQL
Codice di ritorno. 0 significa che l'operazione restituisce una risposta positiva (anche vuota), mentre un valore diverso da zero indica un errore nell'esecuzione dell'operazione come una query non riuscita a causa di errori di sintassi o di autorizzazione.

Quando si filtrano le voci, si dovrebbe eseguire un semplice grep e cercare uno schema specifico:

$ 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

Per impostazione predefinita, tutti i valori delle password saranno mascherati da asterischi:

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

Controlla il filtro degli utenti

Se tieni traccia di tutto, probabilmente verrai sommerso dall'utente di monitoraggio per la sua responsabilità di campionamento, come mostrato nell'esempio seguente:

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

Nell'arco di un secondo, possiamo vedere 14 eventi QUERY registrati dal plug-in di audit per il nostro utente di monitoraggio chiamato "cmon". Nel nostro carico di lavoro di prova, la velocità di registrazione è di circa 32 KB al minuto, che accumuleranno fino a 46 MB al giorno. A seconda delle dimensioni dello storage e della capacità IO, questo potrebbe essere eccessivo in alcuni carichi di lavoro. Quindi sarebbe meglio filtrare l'utente di monitoraggio dalla registrazione dell'audit, in modo da poter avere un output più pulito ed è molto più facile controllare e analizzare.

A seconda delle politiche di sicurezza e auditing, potremmo filtrare l'utente indesiderato come l'utente di monitoraggio utilizzando la seguente variabile all'interno del file di configurazione di MariaDB (richiede il riavvio):

server_audit_excl_users='cmon'

Oppure impostalo dinamicamente nel runtime usando SET GLOBAL (non richiede riavvio, ma non persistente):

MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'

Puoi aggiungere più utenti del database, separati da virgole. Dopo aver aggiunto quanto sopra, abbiamo ottenuto registri di controllo più puliti, come di seguito (niente più dall'utente '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

Gestione della rotazione del registro

Dato che il registro di controllo acquisirà un numero enorme di eventi, si consiglia di configurare una rotazione del registro appropriata per esso. Altrimenti, ci ritroveremmo con un file di registro di dimensioni enormi che lo rende molto difficile da analizzare. Mentre il server è in esecuzione e server_audit_output_type=file, possiamo forzare la rotazione del file di log utilizzando la seguente istruzione:

MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;

Per la rotazione automatica dei log, dovremmo impostare le seguenti variabili all'interno del file di configurazione di MariaDB:

server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30

Oppure impostalo dinamicamente in runtime usando SET GLOBAL (non richiede il riavvio):

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

Per disabilitare la rotazione del log di controllo, imposta semplicemente server_audit_file_rotations su 0. Il valore predefinito è 9. La rotazione del log avverrà automaticamente dopo aver raggiunto la soglia specificata e manterrà gli ultimi 30 log, il che significa che il ultimi 30 giorni di registrazione dell'audit.

Auditing utilizzando Syslog o Rsyslog Facility

L'uso della funzione syslog o rsyslog renderà più semplice la gestione dei log perché consente la registrazione da diversi tipi di sistemi in un repository centrale. Invece di mantenere un altro componente di registrazione, possiamo indicare a MariaDB Audit di accedere a syslog. Questo è utile se disponi di un raccoglitore di log/streamer per servizi di analisi di log come Splunk, LogStash, Loggly o Amazon CloudWatch.

Per fare ciò, imposta le seguenti righe all'interno del file di configurazione di MariaDB (richiede il riavvio):

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

Oppure se vuoi cambiare in runtime (non richiede riavvio, ma non persistente):

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

Le voci saranno simili 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

Se vuoi configurare un servizio di registrazione remota per un repository di registrazione centralizzato, possiamo usare rsyslog. Il trucco consiste nell'utilizzare la variabile server_audit_syslog_facility dove possiamo creare un filtro per facilitare la registrazione, simile al seguente:

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

Tuttavia, ci sono alcuni passaggi prerequisiti in anticipo. Considera la seguente architettura di replica master-slave MariaDB con un server rsyslog centralizzato:

In questo esempio, tutti i server girano su Ubuntu 20.04. Sul server di destinazione rsyslog, è necessario impostare quanto segue all'interno di /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
& ~

Nota che la parte "&~" è importante e non perderla. In pratica dice alla funzione di registrazione di accedere a /var/log/mariadb-centralized-audit.log e interrompere l'ulteriore elaborazione subito dopo.

Quindi, crea il file di registro di destinazione con la proprietà e l'autorizzazione del file corrette:

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

Riavvia rsyslog:

$ systemctl restart rsyslog

Assicurati che sia in ascolto su tutti gli indirizzi IP accessibili sulla 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

Abbiamo completato la configurazione del server rsyslog di destinazione. Ora siamo pronti per configurare la parte sorgente. Sul server MariaDB, crea un nuovo file di configurazione rsyslog separato in /etc/rsyslog.d/50-mariadb-audit.conf e aggiungi le seguenti righe:

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

Le impostazioni nella prima sezione riguardano la creazione di una coda su disco, che è consigliata per non perdere nessuna voce di registro. L'ultima riga è importante. Abbiamo modificato la variabile server_audit_syslog_facility in LOG_LOCAL6 per il plug-in di controllo. Qui, abbiamo specificato "local6.*" come filtro per inoltrare solo le voci Syslog utilizzando la funzione local6 a rsyslog in esecuzione sul server rsyslog 172.31.6.200, sulla porta 514 tramite protocollo TCP.

Per attivare le modifiche per rsyslog, l'ultimo passaggio è riavviare rsyslog sul server MariaDB per attivare le modifiche:

$ systemctl restart rsyslog

Ora, rsyslog è configurato correttamente nel nodo di origine. Possiamo testare accedendo al server MariaDB ed eseguire alcune attività per generare eventi di audit. Dovresti vedere che le voci del registro di controllo vengono inoltrate qui:

$ 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

Pensieri finali

MariaDB Audit Plugin può essere configurato in molti modi per adattarsi alle tue politiche di sicurezza e auditing. Le informazioni di controllo possono aiutarti a risolvere i problemi relativi alle prestazioni o alle applicazioni e ti consentono di vedere esattamente quali query SQL vengono elaborate.