Tips og tricks ved hjælp af revisionslogning til MariaDB

MariaDBs Audit Plugin giver revisionsfunktionalitet for ikke kun MariaDB, men også MySQL (fra version 5.5.34 og 10.0.7) og Percona Server. MariaDB begyndte som standard at inkludere Audit Plugin fra version 10.0.10 og 5.5.37, og det kan installeres i enhver version fra MariaDB 5.5.20.

Formålet med MariaDB Audit Plugin er at logge serverens aktivitet. For hver klientsession registrerer den, hvem der har forbindelse til serveren (dvs. brugernavn og vært), hvilke forespørgsler der blev udført, og hvilke tabeller der blev tilgået og servervariabler der blev ændret. Denne information gemmes i en roterende logfil, eller den kan sendes til den lokale syslogd.

I dette blogindlæg vil vi vise dig nogle bedste praksis-justeringer og tips til, hvordan du konfigurerer revisionslogning for en MariaDB-server. Skriftet er baseret på MariaDB 10.5.9 med den seneste version af MariaDB Audit Plugin 1.4.4.

Installationsjustering

Den anbefalede måde at aktivere revisionslogning på er ved at indstille følgende linjer 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

Glem ikke at indstille "server_audit=FORCE_PLUS_PERMANENT" til at gennemtvinge revisionsloggen og ikke tillade, at den afinstalleres af andre brugere, der bruger UNINSTALL SONAME-sætningen. Som standard er logningsdestinationen en logfil i MariaDB-datamappen. Vi bør lægge revisionsloggen uden for denne mappe, fordi der er en chance for, at datadirigent vil blive slettet (SST for Galera Cluster), eller blive erstattet til en fysisk gendannelse som datadir-bytning, når du gendanner en sikkerhedskopi taget fra MariaDB Backup.

Yderligere tuning er nødvendig, som vist i de følgende afsnit.

Fitrering af revisionsbegivenheder

MariaDB Audit-plugin bruger flere logindstillinger, der afhænger af plugin-versionen. Følgende revisionsbegivenheder er tilgængelige på den seneste plugin-version 1.4.4:

Som standard vil den spore alt, da server_audit_events-variablen vil blive sat til tom som standard. Bemærk, at ældre versioner har mindre understøttelse af ovenstående operationstype, som vist her. Så sørg for, at du kører på den nyeste version, hvis du vil foretage specifik filtrering.

Hvis forespørgselscachen er aktiveret, og en forespørgsel returneres fra forespørgselscachen, vises ingen TABLE-poster i loggen, da serveren ikke åbnede eller fik adgang til nogen tabeller og i stedet stolede på cachen resultater. Så du ønsker måske at deaktivere forespørgselscache.

For at bortfiltrere specifikke hændelser skal du indstille følgende linje i MariaDB-konfigurationsfilen (kræver genstart):

server_audit_events = 'CONNECT,QUERY,TABLE'

Eller indstil det dynamisk i kørselstiden ved hjælp af SET GLOBAL (kræver ingen genstart, men ikke vedvarende):

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

Dette er eksemplet på en revisionsbegivenhed:

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 denne log består af en masse information adskilt af et komma, der indeholder følgende information:

• Tidsstempel

• MySQL-værten (identisk med værdien af ​​SELECT @@værtsnavn)

• Databasebrugeren

• Vært, hvor brugeren oprettede forbindelse

• Forbindelses-id

• Tråd-id

• Betjening

• Database

• SQL-sætning/kommando

• Returkode. 0 betyder, at operationen returnerer et successvar (selv tomt), mens en værdi, der ikke er nul, betyder en fejl, der udfører handlingen som en mislykket forespørgsel på grund af syntaks- eller tilladelsesfejl.

Når man filtrerer indtastningerne, ville man lave en simpel grep og lede efter et 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 vil alle adgangskoders værdi være maskeret med stjerner:

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

Revision af brugerfiltrering

Hvis du sporer alt, vil du sandsynligvis blive oversvømmet af overvågningsbrugeren for dens prøveudtagningsansvar, som vist i eksemplet nedenfor:

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

I løbet af et sekund kan vi se 14 QUERY-hændelser registreret af revisions-pluginnet for vores overvågningsbruger kaldet "cmon". I vores testarbejdsmængde er logningshastigheden omkring 32 KB per minut, hvilket vil akkumulere op til 46 MB om dagen. Afhængigt af lagerstørrelsen og IO-kapaciteten kan dette være for stort i nogle arbejdsbelastninger. Så det ville være bedre at filtrere overvågningsbrugeren fra revisionslogningen, så vi kunne få et renere output og er meget nemmere at revidere og analysere.

Afhængigt af sikkerheds- og revisionspolitikkerne kunne vi filtrere den uønskede bruger fra som overvågningsbrugeren ved at bruge følgende variabel i MariaDB-konfigurationsfilen (kræver genstart):

server_audit_excl_users='cmon'

Eller indstil det dynamisk i kørselstiden ved hjælp af SET GLOBAL (kræver ingen genstart, men ikke vedvarende):

MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'

Du kan tilføje flere databasebrugere, adskilt med komma. Efter at have tilføjet ovenstående fik vi en renere revisionslog, som nedenfor (intet fra 'cmon'-brugeren længere):

$ 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

Logrotationsstyring

Da revisionsloggen kommer til at fange et stort antal hændelser, anbefales det at konfigurere en korrekt logrotation for den. Ellers ville vi ende med en enorm størrelse af logfilen, som gør det meget vanskeligt at analysere. Mens serveren kører, og server_audit_output_type=fil, kan vi tvinge logfilrotationen ved at bruge følgende sætning:

MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;

For automatisk logrotation bør vi indstille følgende variabler i MariaDB-konfigurationsfilen:

server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30

Eller indstil det dynamisk i løbetiden ved hjælp af SET GLOBAL (kræver ingen genstart):

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

For at deaktivere revisionslogrotation skal du blot indstille server_audit_file_rotations til 0. Standardværdien er 9. Logrotationen vil ske automatisk, når den når den angivne tærskel og vil beholde de sidste 30 logfiler, hvilket betyder, at seneste 30 dages revisionslogning.

Revision ved hjælp af Syslog eller Rsyslog Facility

Brug af syslog- eller rsyslog-faciliteten vil gøre logstyring lettere, fordi det tillader logning fra forskellige typer systemer i et centralt lager. I stedet for at vedligeholde en anden logningskomponent kan vi instruere MariaDB Audit om at logge på syslog. Dette er praktisk, hvis du har en logopsamler/streamer til loganalysatortjenester som Splunk, LogStash, Loggly eller Amazon CloudWatch.

For at gøre dette skal du indstille følgende linjer i MariaDB-konfigurationsfilen (kræver genstart):

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

Eller hvis du vil ændre i kørselstiden (kræver ingen genstart, men ikke vedvarende):

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

Indtastningerne vil ligne 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

Hvis du ønsker at opsætte en ekstern logningstjeneste til et centraliseret logningslager, kan vi bruge rsyslog. Tricket er at bruge variablen server_audit_syslog_facility, hvor vi kan oprette et filter for at lette logningen, svarende til nedenfor:

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

Der er dog nogle forudgående trin på forhånd. Overvej følgende MariaDB master-slave-replikeringsarkitektur med en centraliseret rsyslog-server:

I dette eksempel kører alle servere på Ubuntu 20.04. På rsyslog-destinationsserveren skal vi indstille følgende inde i /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
& ~

Bemærk, at "&~"-delen er vigtig, og gå ikke glip af det. Det fortæller dybest set logningsfaciliteten at logge ind på /var/log/mariadb-centralized-audit.log og stoppe yderligere behandling lige efter det.

Opret derefter destinationslogfilen med det korrekte filejerskab og tilladelse:

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

Genstart rsyslog:

$ systemctl restart rsyslog

Sørg for, at den lytter på alle tilgængelige 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 fuldført konfigurationen af ​​destinations-rsyslog-serveren. Nu er vi klar til at konfigurere kildedelen. På MariaDB-serveren skal du oprette en ny separat rsyslog-konfigurationsfil på /etc/rsyslog.d/50-mariadb-audit.conf og tilføje følgende linjer:

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

Indstillingerne i den første sektion handler om at oprette en kø på disken, som anbefales for ikke at miste logindtastninger. Den sidste linje er vigtig. Vi ændrede variablen server_audit_syslog_facility til LOG_LOCAL6 for revisionsplugin'et. Her specificerede vi "local6.*" som et filter til kun at videresende Syslog-indgange ved hjælp af facility local6 til rsyslog, der kører på rsyslog-serveren 172.31.6.200, på port 514 via TCP-protokol.

For at aktivere ændringerne for rsyslog er det sidste trin at genstarte rsyslog på MariaDB-serveren for at aktivere ændringerne:

$ systemctl restart rsyslog

Nu er rsyslog korrekt konfigureret på kildenoden. Vi kan teste ved at få adgang til MariaDB-serveren og udføre nogle aktiviteter for at generere revisionsbegivenheder. Du bør se, at revisionslogposterne videresendes her:

$ 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

Sidste tanker

MariaDB Audit Plugin kan konfigureres på mange måder, så det passer til dine sikkerheds- og revisionspolitikker. Revisionsoplysninger kan hjælpe dig med at fejlfinde ydeevne- eller applikationsproblemer og lader dig se præcis, hvilke SQL-forespørgsler der behandles.