Tips och knep med hjälp av revisionsloggning för MariaDB

MariaDB:s Audit Plugin tillhandahåller revisionsfunktioner för inte bara MariaDB utan även MySQL (från och med version 5.5.34 och 10.0.7) och Percona Server. MariaDB började som standard att inkludera Audit Plugin från versionerna 10.0.10 och 5.5.37, och den kan installeras i alla versioner från MariaDB 5.5.20.

Syftet med MariaDB Audit Plugin är att logga serverns aktivitet. För varje klientsession registreras vem som anslutit till servern (d.v.s. användarnamn och värd), vilka frågor som utfördes och vilka tabeller som åtkoms till och servervariabler som ändrades. Denna information lagras i en roterande loggfil eller så kan den skickas till den lokala syslogd.

I det här blogginlägget kommer vi att visa dig några bästa praxisjusteringar och tips om hur du konfigurerar granskningsloggning för en MariaDB-server. Skrivandet är baserat på MariaDB 10.5.9, med den senaste versionen av MariaDB Audit Plugin 1.4.4.

Installationsjustering

Det rekommenderade sättet att aktivera granskningsloggning är genom att ställa in följande rader i MariaDB-konfigurationsfilen:

[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

Glöm inte att ställa in "server_audit=FORCE_PLUS_PERMANENT" för att genomdriva granskningsloggen och inte tillåta att den avinstalleras av andra användare som använder UNINSTALL SONAME-satsen. Som standard är loggningsdestinationen en loggfil i MariaDB-datakatalogen. Vi bör lägga granskningsloggen utanför den här katalogen eftersom det finns en chans att datadirigenten raderas (SST för Galera Cluster), eller att den ersätts för en fysisk återställning som att byta datadir vid återställning av en säkerhetskopia som tagits från MariaDB Backup.

Ytterligare justering är nödvändig, som visas i följande avsnitt.

Fitrering av granskningshändelser

MariaDB Audit-plugin använder flera logginställningar som beror på plugin-versionen. Följande granskningshändelser är tillgängliga på den senaste pluginversionen 1.4.4:

Som standard kommer den att spåra allt eftersom variabeln server_audit_events kommer att vara tom som standard. Observera att äldre versioner har mindre stöd för ovanstående operationstyp, som visas här. Så se till att du kör den senaste versionen om du vill göra specifik filtrering.

Om frågecachen är aktiverad och en fråga returneras från frågecachen, kommer inga TABLE-poster att visas i loggen eftersom servern inte öppnade eller fick åtkomst till några tabeller och istället förlitade sig på den cachade resultat. Så du kanske vill inaktivera frågecache.

För att filtrera bort specifika händelser, ställ in följande rad i MariaDB-konfigurationsfilen (kräver omstart):

server_audit_events = 'CONNECT,QUERY,TABLE'

Eller ställ in det dynamiskt under körningen med SET GLOBAL (kräver ingen omstart, men inte ihållande):

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

Detta är exemplet på en revisionshändelse:

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

En post i den här loggen består av en mängd information separerade med ett kommatecken som innehåller följande information:

• Tidsstämpel

• MySQL-värden (identisk med värdet för SELECT @@värdnamn)

• Databasanvändaren

• Värd där användaren ansluter

• Anslutnings-ID

• Tråd-ID

• Operation

• Databas

• SQL-sats/kommando

• Returkod. 0 betyder att operationen returnerar ett framgångssvar (även tomt), medan ett värde som inte är noll betyder ett fel när operationen utförs som en misslyckad fråga på grund av syntax- eller behörighetsfel.

När man filtrerar posterna skulle man göra ett enkelt grep och leta efter ett specifikt mönster:

$ 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

Som standard kommer alla lösenordsvärden att vara maskerade med asterisker:

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

Granska användarfiltrering

Om du spårar allt kommer du förmodligen att översvämmas av övervakningsanvändaren för dess provtagningsansvar, som visas i exemplet nedan:

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

Inom loppet av en sekund kan vi se 14 QUERY-händelser registrerade av granskningspluginen för vår övervakningsanvändare som heter "cmon". I vår testarbetsbelastning är loggningshastigheten runt 32 KB per minut, vilket kommer att ackumuleras upp till 46 MB per dag. Beroende på lagringsstorlek och IO-kapacitet kan detta vara överdrivet i vissa arbetsbelastningar. Så det skulle vara bättre att filtrera bort övervakningsanvändaren från revisionsloggningen, så att vi kan få en renare utdata och är mycket lättare att granska och analysera.

Beroende på säkerhets- och revisionspolicyer kan vi filtrera bort den oönskade användaren som övervakningsanvändaren genom att använda följande variabel i MariaDB-konfigurationsfilen (kräver omstart):

server_audit_excl_users='cmon'

Eller ställ in det dynamiskt under körningen med SET GLOBAL (kräver ingen omstart, men inte ihållande):

MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'

Du kan lägga till flera databasanvändare, separerade med kommatecken. Efter att ha lagt till ovanstående fick vi en renare granskningsloggar, enligt nedan (inget från 'cmon'-användaren längre):

$ 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

Loggrotationshantering

Eftersom revisionsloggen kommer att fånga ett stort antal händelser, rekommenderas det att konfigurera en korrekt loggrotation för den. Annars skulle vi få en enorm storlek på loggfilen vilket gör det mycket svårt att analysera. Medan servern körs och server_audit_output_type=file, kan vi tvinga loggfilen att rotera genom att använda följande sats:

MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;

För automatisk loggrotation bör vi ställa in följande variabler i MariaDB-konfigurationsfilen:

server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30

Eller ställ in det dynamiskt under körningen med SET GLOBAL (kräver ingen omstart):

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

För att inaktivera rotation av granskningslogg, ställ helt enkelt in server_audit_file_rotations till 0. Standardvärdet är 9. Loggrotationen kommer att ske automatiskt efter att den når den angivna tröskeln och kommer att behålla de senaste 30 loggarna, vilket innebär att senaste 30 dagarnas revisionsloggning.

Revision med Syslog eller Rsyslog Facility

Användning av syslog- eller rsyslog-funktionen kommer att göra logghanteringen enklare eftersom den tillåter loggning från olika typer av system i ett centralt arkiv. Istället för att underhålla en annan loggningskomponent kan vi instruera MariaDB Audit att logga till syslog. Detta är praktiskt om du har en loggsamlare/streamer för logganalystjänster som Splunk, LogStash, Loggly eller Amazon CloudWatch.

För att göra detta, ställ in följande rader i MariaDB-konfigurationsfilen (kräver omstart):

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

Eller om du vill ändra i körtiden (kräver ingen omstart, men inte ihållande):

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

Inläggen kommer att likna Syslog-formatet:

$ 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

Om du vill ställa in en fjärrloggningstjänst för ett centraliserat loggningsförråd kan vi använda rsyslog. Tricket är att använda variabeln server_audit_syslog_facility där vi kan skapa ett filter för att underlätta loggning, liknande nedan:

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

Det finns dock några nödvändiga steg i förväg. Tänk på följande MariaDB master-slave replikeringsarkitektur med en centraliserad rsyslog-server:

I det här exemplet körs alla servrar på Ubuntu 20.04. På destinationsservern för rsyslog måste vi ställa in följande inuti /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
& ~

Observera att "&~"-delen är viktig och missa inte det. Det säger i princip till loggningsanläggningen att logga in på /var/log/mariadb-centralized-audit.log och stoppa vidare bearbetning direkt efter det.

Skapa sedan målloggfilen med rätt filäganderätt och behörighet:

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

Starta om rsyslog:

$ systemctl restart rsyslog

Se till att den lyssnar på alla tillgängliga IP-adresser på TCP-port 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

Vi har slutfört konfigureringen av destinations-rsyslog-servern. Nu är vi redo att konfigurera källdelen. På MariaDB-servern, skapa en ny separat rsyslog-konfigurationsfil på /etc/rsyslog.d/50-mariadb-audit.conf och lägg till följande rader:

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

Inställningarna i det första avsnittet handlar om att skapa en kö på disken, vilket rekommenderas för att inte förlora någon loggpost. Den sista raden är viktig. Vi ändrade variabeln server_audit_syslog_facility till LOG_LOCAL6 för granskningsplugin. Här angav vi "local6.*" som ett filter för att endast vidarebefordra Syslog-poster med hjälp av facility local6 till rsyslog som körs på rsyslog-servern 172.31.6.200, på port 514 via TCP-protokoll.

För att aktivera ändringarna för rsyslog är det sista steget att starta om rsyslog på MariaDB-servern för att aktivera ändringarna:

$ systemctl restart rsyslog

Nu är rsyslog korrekt konfigurerad på källnoden. Vi kan testa genom att komma åt MariaDB-servern och utföra vissa aktiviteter för att generera revisionshändelser. Du bör se att granskningsloggposterna vidarebefordras här:

$ 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

Sluta tankar

MariaDB Audit Plugin kan konfigureras på många sätt för att passa dina säkerhets- och revisionspolicyer. Granskningsinformation kan hjälpa dig att felsöka prestanda- eller programproblem och låter dig se exakt vilka SQL-frågor som bearbetas.