Tipy a triky pomocí protokolování auditu pro MariaDB

Audit Plugin MariaDB poskytuje funkce auditu nejen pro MariaDB, ale také pro MySQL (od verze 5.5.34 a 10.0.7) a Percona Server. MariaDB začala ve výchozím nastavení zahrnovat Audit Plugin od verzí 10.0.10 a 5.5.37 a lze jej nainstalovat v jakékoli verzi od MariaDB 5.5.20.

Účelem modulu MariaDB Audit Plugin je protokolovat aktivitu serveru. Pro každou relaci klienta zaznamená, kdo se připojil k serveru (tj. uživatelské jméno a hostitel), jaké dotazy byly provedeny a ke kterým tabulkám byl přistupován a proměnné serveru, které byly změněny. Tyto informace jsou uloženy v rotujícím log souboru nebo mohou být odeslány do místního syslogd.

V tomto příspěvku na blogu vám ukážeme několik osvědčených postupů a tipů, jak nakonfigurovat protokolování auditu pro server MariaDB. Psaní je založeno na MariaDB 10.5.9 s nejnovější verzí MariaDB Audit Plugin 1.4.4.

Ladění instalace

Doporučený způsob, jak povolit protokolování auditu, je nastavení následujících řádků v konfiguračním souboru 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

Nezapomeňte nastavit "server_audit=FORCE_PLUS_PERMANENT" pro vynucení protokolu auditu a znemožnění jeho odinstalování ostatními uživateli pomocí příkazu UNINSTALL SONAME. Ve výchozím nastavení je cílem protokolování soubor protokolu v datovém adresáři MariaDB. Protokol auditu bychom měli umístit mimo tento adresář, protože existuje šance, že datadir bude vymazán (SST pro Galera Cluster) nebo bude nahrazen pro fyzickou obnovu, jako je výměna datadir při obnově zálohy převzaté ze zálohy MariaDB.

Je nutné další ladění, jak je ukázáno v následujících částech.

Filtrování událostí auditu

Plugin MariaDB Audit využívá několik nastavení protokolu v závislosti na verzi pluginu. V nejnovější verzi pluginu 1.4.4 jsou k dispozici následující auditní události:

Ve výchozím nastavení bude sledovat vše, protože proměnná server_audit_events bude ve výchozím nastavení prázdná. Všimněte si, že starší verze mají menší podporu pro výše uvedený typ operace, jak je znázorněno zde. Pokud tedy chcete provést konkrétní filtrování, ujistěte se, že používáte nejnovější verzi.

Pokud je povolena mezipaměť dotazů a dotaz je vrácen z mezipaměti dotazů, v protokolu se neobjeví žádné záznamy TABLE, protože server neotevřel ani nepřistupoval k žádným tabulkám a místo toho se spoléhal na mezipaměť Výsledek. Možná budete chtít zakázat ukládání dotazů do mezipaměti.

Chcete-li odfiltrovat konkrétní události, nastavte v konfiguračním souboru MariaDB následující řádek (vyžaduje restart):

server_audit_events = 'CONNECT,QUERY,TABLE'

Nebo jej nastavte dynamicky za běhu pomocí SET GLOBAL (nevyžaduje restart, ale není trvalé):

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

Toto je příklad jedné události auditu:

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

Záznam v tomto protokolu se skládá ze skupiny informací oddělených čárkou obsahující následující informace:

• Časové razítko

• Hostitel MySQL (identický s hodnotou SELECT @@hostname)

• Uživatel databáze

• Hostitel, ke kterému se uživatel připojoval

• ID připojení

• ID vlákna

• Provoz

• Databáze

• příkaz/příkaz SQL

• Vrácený kód. 0 znamená, že operace vrátí odpověď o úspěchu (dokonce i prázdnou), zatímco nenulová hodnota znamená chybu při provádění operace, jako je neúspěšný dotaz kvůli chybám syntaxe nebo oprávnění.

Při filtrování záznamů by člověk udělal jednoduchý grep a hledal konkrétní vzor:

$ 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

Ve výchozím nastavení budou všechna hesla maskována hvězdičkami:

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

Kontrola filtrování uživatelů

Pokud budete vše sledovat, pravděpodobně budete zaplaveni monitorovacím uživatelem kvůli jeho odpovědnosti za vzorkování, jak ukazuje příklad níže:

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

Během jedné sekundy můžeme vidět 14 událostí QUERY zaznamenaných zásuvným modulem auditu pro našeho monitorovacího uživatele s názvem „cmon“. V našem testovacím vytížení se rychlost protokolování pohybuje kolem 32 KB za minutu, což bude akumulovat až 46 MB za den. V závislosti na velikosti úložiště a kapacitě IO to může být u některých úloh nadměrné. Bylo by tedy lepší odfiltrovat monitorujícího uživatele z protokolování auditu, abychom mohli mít čistší výstup a bylo by mnohem snazší jej auditovat a analyzovat.

V závislosti na zásadách zabezpečení a auditu bychom mohli odfiltrovat nežádoucího uživatele, jako je uživatel monitorování pomocí následující proměnné v konfiguračním souboru MariaDB (vyžaduje restart):

server_audit_excl_users='cmon'

Nebo jej nastavte dynamicky za běhu pomocí SET GLOBAL (nevyžaduje restart, ale není trvalé):

MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'

Můžete přidat více uživatelů databáze oddělených čárkou. Po přidání výše uvedeného jsme získali přehlednější protokoly auditu, jak je uvedeno níže (už nic od uživatele „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

Správa rotace protokolů

Protože protokol auditu bude zachycovat velké množství událostí, doporučuje se pro něj nakonfigurovat správnou rotaci protokolu. Jinak bychom skončili s enormní velikostí logfile, což velmi ztěžuje analýzu. Zatímco server běží a server_audit_output_type=file, můžeme vynutit rotaci logfile pomocí následujícího příkazu:

MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;

Pro automatickou rotaci protokolu bychom měli v konfiguračním souboru MariaDB nastavit následující proměnné:

server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30

Nebo jej nastavte dynamicky za běhu pomocí SET GLOBAL (nevyžaduje restart):

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

Chcete-li zakázat rotaci protokolu auditu, jednoduše nastavte server_audit_file_rotations na 0. Výchozí hodnota je 9. Rotace protokolu proběhne automaticky, jakmile dosáhne zadané prahové hodnoty a zachová posledních 30 protokolů, což znamená protokolování auditu za posledních 30 dní.

Audit pomocí Syslog nebo Rsyslog Facility

Použití zařízení syslog nebo rsyslog usnadní správu protokolů, protože umožňuje protokolování z různých typů systémů v centrálním úložišti. Namísto údržby další logovací komponenty můžeme dát pokyn MariaDB Audit, aby se přihlásil do syslogu. To je užitečné, pokud máte sběrač/streamer protokolů pro služby analyzátoru protokolů, jako je Splunk, LogStash, Loggly nebo Amazon CloudWatch.

Za tímto účelem nastavte v konfiguračním souboru MariaDB následující řádky (vyžaduje restart):

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

Nebo pokud chcete provést změnu v běhovém prostředí (nevyžaduje restart, ale není trvalé):

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

Položky budou podobné formátu 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

Pokud chcete nastavit službu vzdáleného protokolování pro centralizované úložiště protokolování, můžeme použít rsyslog. Trik je v použití proměnné server_audit_syslog_facility, kde můžeme vytvořit filtr pro usnadnění protokolování, podobně jako níže:

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

Předtím však existuje několik nezbytných kroků. Zvažte následující replikační architekturu MariaDB master-slave s centralizovaným serverem rsyslog:

V tomto příkladu všechny servery běží na Ubuntu 20.04. Na cílovém serveru rsyslog musíme v /etc/rsyslog.conf nastavit následující:

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
& ~

Všimněte si, že část "&~" je důležitá a nenechte si ji ujít. V zásadě říká protokolovacímu zařízení, aby se přihlásilo do /var/log/mariadb-centralized-audit.log a hned poté zastavilo další zpracování.

Dále vytvořte cílový soubor protokolu se správným vlastnictvím souboru a oprávněním:

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

Restartujte rsyslog:

$ systemctl restart rsyslog

Ujistěte se, že naslouchá na všech dostupných adresách IP na portu 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

Dokončili jsme konfiguraci cílového serveru rsyslog. Nyní jsme připraveni nakonfigurovat zdrojovou část. Na serveru MariaDB vytvořte nový samostatný konfigurační soubor rsyslog na adrese /etc/rsyslog.d/50-mariadb-audit.conf a přidejte následující řádky:

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

Nastavení v první části se týká vytvoření fronty na disku, což se doporučuje, aby nedošlo ke ztrátě žádné položky protokolu. Poslední řádek je důležitý. Změnili jsme proměnnou server_audit_syslog_facility na LOG_LOCAL6 pro plugin auditu. Zde jsme specifikovali "local6.*" jako filtr, který pouze přepošle záznamy Syslog pomocí zařízení local6 na rsyslog běžící na serveru rsyslog 172.31.6.200, na portu 514 prostřednictvím protokolu TCP.

Chcete-li aktivovat změny pro rsyslog, posledním krokem je restartovat rsyslog na serveru MariaDB, aby se změny aktivovaly:

$ systemctl restart rsyslog

Nyní je rsyslog správně nakonfigurován na zdrojovém uzlu. Můžeme to vyzkoušet tak, že přistoupíme na server MariaDB a provedeme některé činnosti pro generování událostí auditu. Měli byste vidět, že záznamy protokolu auditu jsou předávány sem:

$ 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

Poslední myšlenky

Plugin MariaDB Audit Plugin lze nakonfigurovat mnoha způsoby, aby vyhovoval vašim zásadám zabezpečení a auditu. Informace o auditu vám mohou pomoci při odstraňování problémů s výkonem nebo aplikací a umožňují vám přesně vidět, jaké dotazy SQL se zpracovávají.