Tips en trucs met behulp van Audit Logging voor MariaDB

MariaDB's Audit Plugin biedt auditfunctionaliteit voor niet alleen MariaDB maar ook MySQL (vanaf versie 5.5.34 en 10.0.7) en Percona Server. MariaDB is begonnen met het standaard opnemen van de Audit Plugin van versies 10.0.10 en 5.5.37, en het kan in elke versie vanaf MariaDB 5.5.20 worden geïnstalleerd.

Het doel van de MariaDB Audit Plugin is om de activiteit van de server te loggen. Voor elke clientsessie registreert het wie verbinding heeft gemaakt met de server (d.w.z. gebruikersnaam en host), welke query's zijn uitgevoerd en welke tabellen zijn geopend en servervariabelen die zijn gewijzigd. Deze informatie wordt opgeslagen in een roterend logbestand of kan naar de lokale syslogd worden gestuurd.

In deze blogpost laten we u enkele best-practice-afstemmingen en tips zien voor het configureren van auditregistratie voor een MariaDB-server. Het schrijven is gebaseerd op MariaDB 10.5.9, met de nieuwste versie van MariaDB Audit Plugin 1.4.4.

Installatie afstemmen

De aanbevolen manier om auditlogging in te schakelen is door de volgende regels in het MariaDB-configuratiebestand in te stellen:

[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

Vergeet niet om "server_audit=FORCE_PLUS_PERMANENT" in te stellen om het controlelogboek af te dwingen en niet toe te staan dat andere gebruikers de installatie ongedaan maken met behulp van de instructie UNINSTALL SONAME. De logboekbestemming is standaard een logbestand in de MariaDB-gegevensdirectory. We moeten het auditlogboek buiten deze map plaatsen, omdat de kans bestaat dat de datadir wordt gewist (SST voor Galera Cluster) of wordt vervangen voor een fysiek herstel, zoals datadir-swapping bij het herstellen van een back-up die is genomen vanuit MariaDB Backup.

Verdere afstemming is nodig, zoals weergegeven in de volgende secties.

Auditgebeurtenissen filteren

MariaDB Audit-plug-in gebruikt verschillende log-instellingen die afhankelijk zijn van de plug-inversie. De volgende auditgebeurtenissen zijn beschikbaar in de nieuwste plug-inversie 1.4.4:

Type

Beschrijving

VERBINDEN

Verbindt, verbreekt de verbinding en mislukte verbindingen, inclusief de foutcode

QUERY

Uitgevoerde query's en hun resultaten in platte tekst, inclusief mislukte query's vanwege syntaxis- of toestemmingsfouten

TABEL

Tabellen beïnvloed door uitvoering van zoekopdrachten

QUERY_DDL

Vergelijkbaar met QUERY, maar filtert alleen zoekopdrachten van het DDL-type (CREATE, ALTER, DROP, RENAME en TRUNCATE statements - behalve CREATE/DROP [PROCEDURE / FUNCTION / USER] en RENAME USER (ze zijn geen DDL)

QUERY_DML

Vergelijkbaar met QUERY, maar filtert alleen zoekopdrachten van het DML-type (DO, CALL, LOAD DATA/XML, DELETE, INSERT, SELECT, UPDATE, HANDLER en REPLACE-instructies)

QUERY_DML_NO_SELECT

Vergelijkbaar met QUERY_DML, maar registreert geen SELECT-query's. (sinds versie 1.4.4) (statements DO, CALL, LOAD DATA/XML, DELETE, INSERT, UPDATE, HANDLER en REPLACE)

QUERY_DCL

Vergelijkbaar met QUERY, maar filtert alleen zoekopdrachten van het DCL-type (CREATE USER, DROP USER, RENAME USER, GRANT, REVOKE en SET PASSWORD-instructies)

Standaard zal het alles volgen aangezien de server_audit_events variabele standaard op leeg staat. Houd er rekening mee dat oudere versies minder ondersteuning bieden voor het bovenstaande bewerkingstype, zoals hier wordt weergegeven. Zorg er dus voor dat u de nieuwste versie gebruikt als u specifiek wilt filteren.

Als de querycache is ingeschakeld en een query wordt geretourneerd vanuit de querycache, verschijnen er geen TABLE-records in het logboek, omdat de server geen tabellen heeft geopend of geopend en in plaats daarvan vertrouwde op de cache resultaten. Dus misschien wil je het cachen van zoekopdrachten uitschakelen.

Om specifieke gebeurtenissen uit te filteren, stelt u de volgende regel in in het MariaDB-configuratiebestand (opnieuw opstarten vereist):

server_audit_events = 'CONNECT,QUERY,TABLE'

Of stel het dynamisch in tijdens runtime met SET GLOBAL (vereist geen herstart, maar niet persistent):

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

Dit is het voorbeeld van één auditgebeurtenis:

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

Een invoer van dit logboek bestaat uit een heleboel informatie gescheiden door een komma met de volgende informatie:

Tijdstempel
De MySQL-host (identiek aan de waarde van SELECT @@hostname)
De databasegebruiker
Host waar de gebruiker verbinding maakte
Verbindings-ID
Thread-ID
Bewerking
Database
SQL-instructie/-opdracht
Retourcode. 0 betekent dat de bewerking een succesreactie retourneert (zelfs leeg), terwijl een waarde die niet nul is, een fout betekent bij het uitvoeren van de bewerking zoals een mislukte query vanwege syntaxis- of machtigingsfouten.

Bij het filteren van de items zou men een simpele grep doen en naar een specifiek patroon zoeken:

$ 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

Standaard worden alle wachtwoorden gemaskeerd met sterretjes:

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

Gebruikersfiltering controleren

Als u alles bijhoudt, wordt u waarschijnlijk overspoeld met de gebruiker die de controle uitvoert voor zijn verantwoordelijkheid voor het nemen van monsters, zoals weergegeven in het onderstaande voorbeeld:

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

In een tijdsbestek van één seconde kunnen we 14 QUERY-gebeurtenissen zien die zijn geregistreerd door de audit-plug-in voor onze monitoringgebruiker genaamd "cmon". In onze testworkload is de logsnelheid ongeveer 32 KB per minuut, wat kan oplopen tot 46 MB per dag. Afhankelijk van de opslaggrootte en IO-capaciteit kan dit bij sommige workloads overdreven zijn. Het zou dus beter zijn om de controlerende gebruiker uit de auditregistratie te filteren, zodat we een schonere output kunnen hebben en het is veel gemakkelijker om te controleren en te analyseren.

Afhankelijk van het beveiligings- en controlebeleid, kunnen we de ongewenste gebruiker eruit filteren, zoals de controlerende gebruiker door de volgende variabele in het MariaDB-configuratiebestand te gebruiken (opnieuw opstarten vereist):

server_audit_excl_users='cmon'

Of stel het dynamisch in tijdens runtime met SET GLOBAL (vereist geen herstart, maar niet persistent):

MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'

U kunt meerdere databasegebruikers toevoegen, gescheiden door komma's. Nadat we het bovenstaande hadden toegevoegd, kregen we schonere controlelogboeken, zoals hieronder (niets meer van de 'cmon'-gebruiker):

$ 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

Beheer van logboekrotatie

Omdat het auditlogboek een groot aantal gebeurtenissen gaat vastleggen, wordt het aanbevolen om er een juiste logrotatie voor te configureren. Anders zouden we eindigen met een enorm logbestand dat het erg moeilijk maakt om te analyseren. Terwijl de server draait, en server_audit_output_type=file, kunnen we de rotatie van het logbestand forceren door de volgende instructie te gebruiken:

MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;

Voor automatische logrotatie moeten we de volgende variabelen in het MariaDB-configuratiebestand instellen:

server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30

Of stel het dynamisch in tijdens runtime met SET GLOBAL (herstart niet vereist):

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

Als u de rotatie van auditlogboeken wilt uitschakelen, stelt u eenvoudig de server_audit_file_rotations in op 0. De standaardwaarde is 9. De logrotatie vindt automatisch plaats nadat de opgegeven drempel is bereikt en houdt de laatste 30 logboeken bij, wat betekent dat de auditregistratie van de afgelopen 30 dagen.

Auditing met Syslog of Rsyslog Facility

Het gebruik van de syslog- of rsyslog-faciliteit zal het logbeheer gemakkelijker maken omdat het loggen van verschillende soorten systemen in een centrale repository mogelijk maakt. In plaats van een ander logboekonderdeel te onderhouden, kunnen we de MariaDB-audit opdracht geven om in te loggen op syslog. Dit is handig als je een logboekverzamelaar/streamer hebt voor logboekanalysediensten zoals Splunk, LogStash, Loggly of Amazon CloudWatch.

Hiervoor stelt u de volgende regels in in het MariaDB-configuratiebestand (opnieuw opstarten vereist):

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

Of als u de runtime wilt wijzigen (vereist geen herstart, maar niet persistent):

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

De invoer is vergelijkbaar met het Syslog-formaat:

$ 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

Als je een externe logging-service wilt opzetten voor een gecentraliseerde logging-repository, kunnen we rsyslog gebruiken. De truc is om de variabele server_audit_syslog_facility te gebruiken, waar we een filter kunnen maken om het loggen te vergemakkelijken, zoals hieronder:

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

Er zijn echter enkele vereiste stappen vooraf. Overweeg de volgende MariaDB master-slave replicatie-architectuur met een gecentraliseerde rsyslog-server:

In dit voorbeeld draaien alle servers op Ubuntu 20.04. Op de rsyslog-bestemmingsserver moeten we het volgende instellen in /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
& ~

Merk op dat het "&~" gedeelte belangrijk is en vergeet dat niet. Het vertelt de logfunctie in feite om in te loggen op /var/log/mariadb-centralized-audit.log en de verdere verwerking direct daarna te stoppen.

Maak vervolgens het bestemmingslogbestand met de juiste bestandseigendom en toestemming:

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

Rsyslog opnieuw starten:

$ systemctl restart rsyslog

Zorg ervoor dat het luistert op alle toegankelijke IP-adressen op TCP-poort 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

We hebben de configuratie van de doel-rsyslog-server voltooid. Nu zijn we klaar om het brongedeelte te configureren. Maak op de MariaDB-server een nieuw apart rsyslog-configuratiebestand op /etc/rsyslog.d/50-mariadb-audit.conf en voeg de volgende regels toe:

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

De instellingen in het eerste gedeelte gaan over het maken van een wachtrij op de schijf, wat wordt aanbevolen om geen logboekvermeldingen kwijt te raken. De laatste regel is belangrijk. We hebben de variabele server_audit_syslog_facility gewijzigd in LOG_LOCAL6 voor de audit-plug-in. Hier hebben we "local6.*" gespecificeerd als een filter om alleen Syslog-vermeldingen met faciliteit local6 door te sturen naar rsyslog die draait op de rsyslog-server 172.31.6.200, op poort 514 via het TCP-protocol.

Om de wijzigingen voor rsyslog te activeren, is de laatste stap het herstarten van de rsyslog op de MariaDB-server om de wijzigingen te activeren:

$ systemctl restart rsyslog

Nu is rsyslog correct geconfigureerd op het bronknooppunt. We kunnen testen door toegang te krijgen tot de MariaDB-server en enkele activiteiten uit te voeren om auditgebeurtenissen te genereren. U zou moeten zien dat de vermeldingen in het auditlogboek hier worden doorgestuurd:

$ 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

Laatste gedachten

MariaDB Audit Plugin kan op vele manieren worden geconfigureerd om aan uw beveiligings- en controlebeleid te voldoen. Met controle-informatie kunt u prestatie- of toepassingsproblemen oplossen en kunt u precies zien welke SQL-query's worden verwerkt.