Tipps und Tricks zur Verwendung der Audit-Protokollierung für MariaDB

Das Audit-Plugin von MariaDB bietet Auditing-Funktionalität nicht nur für MariaDB, sondern auch für MySQL (ab Version 5.5.34 und 10.0.7) und Percona Server. MariaDB enthält standardmäßig das Audit-Plug-in ab den Versionen 10.0.10 und 5.5.37 und kann in jeder Version ab MariaDB 5.5.20 installiert werden.

Der Zweck des MariaDB-Audit-Plugins besteht darin, die Aktivität des Servers zu protokollieren. Für jede Clientsitzung wird aufgezeichnet, wer sich mit dem Server verbunden hat (d. h. Benutzername und Host), welche Abfragen ausgeführt wurden und auf welche Tabellen zugegriffen und Servervariablen geändert wurden. Diese Informationen werden in einer rotierenden Protokolldatei gespeichert oder an den lokalen syslogd gesendet.

In diesem Blogbeitrag zeigen wir Ihnen einige Best-Practice-Tunings und Tipps zur Konfiguration der Audit-Protokollierung für einen MariaDB-Server. Das Schreiben basiert auf MariaDB 10.5.9, mit der neuesten Version von MariaDB Audit Plugin 1.4.4.

Installations-Tuning

Die empfohlene Methode zum Aktivieren der Audit-Protokollierung besteht darin, die folgenden Zeilen in der MariaDB-Konfigurationsdatei festzulegen:

[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

Vergessen Sie nicht, "server_audit=FORCE_PLUS_PERMANENT" zu setzen, um das Prüfprotokoll zu erzwingen und zu verhindern, dass es von anderen Benutzern mit der UNINSTALL SONAME-Anweisung deinstalliert wird. Standardmäßig ist das Protokollierungsziel eine Protokolldatei im MariaDB-Datenverzeichnis. Wir sollten das Prüfprotokoll außerhalb dieses Verzeichnisses ablegen, da die Möglichkeit besteht, dass das Datadir gelöscht wird (SST für Galera Cluster) oder durch eine physische Wiederherstellung ersetzt wird, wie z. P>

Weiteres Tuning ist notwendig, wie in den folgenden Abschnitten gezeigt.

Audit-Ereignisfilterung

Das MariaDB-Audit-Plugin verwendet mehrere Protokolleinstellungen, die von der Plugin-Version abhängen. Die folgenden Audit-Ereignisse sind in der neuesten Plugin-Version 1.4.4 verfügbar:

Typ	Beschreibung
VERBINDEN	Verbindet, trennt und fehlgeschlagene Verbindungen, einschließlich des Fehlercodes
ABFRAGE	Ausgeführte Abfragen und ihre Ergebnisse im Klartext, einschließlich fehlgeschlagener Abfragen aufgrund von Syntax- oder Berechtigungsfehlern
TABELLE	Von der Abfrageausführung betroffene Tabellen
QUERY_DDL	Ähnlich wie QUERY, aber filtert nur Abfragen vom DDL-Typ (Anweisungen CREATE, ALTER, DROP, RENAME und TRUNCATE - außer CREATE/DROP [PROCEDURE / FUNCTION / USER] und RENAME USER (sie sind nicht DDL)
QUERY_DML	Ähnlich wie QUERY, aber filtert nur Abfragen vom DML-Typ (DO-, CALL-, LOAD DATA/XML-, DELETE-, INSERT-, SELECT-, UPDATE-, HANDLER- und REPLACE-Anweisungen)
QUERY_DML_NO_SELECT	Ähnlich wie QUERY_DML, protokolliert aber keine SELECT-Abfragen. (seit Version 1.4.4) (Anweisungen DO, CALL, LOAD DATA/XML, DELETE, INSERT, UPDATE, HANDLER und REPLACE)
QUERY_DCL	Ähnlich wie QUERY, aber filtert nur Abfragen vom DCL-Typ (Anweisungen CREATE USER, DROP USER, RENAME USER, GRANT, REVOKE und SET PASSWORD)

Standardmäßig verfolgt es alles, da die Variable server_audit_events standardmäßig leer ist. Beachten Sie, dass ältere Versionen den obigen Vorgangstyp weniger unterstützen, wie hier gezeigt. Stellen Sie also sicher, dass Sie die neueste Version verwenden, wenn Sie eine bestimmte Filterung durchführen möchten.

Wenn der Abfrage-Cache aktiviert ist und eine Abfrage aus dem Abfrage-Cache zurückgegeben wird, erscheinen keine TABLE-Datensätze im Protokoll, da der Server keine Tabellen geöffnet oder darauf zugegriffen hat und sich stattdessen auf die zwischengespeicherten Tabellen verlässt Ergebnisse. Daher sollten Sie das Abfrage-Caching deaktivieren.

Um bestimmte Ereignisse herauszufiltern, setzen Sie die folgende Zeile in der MariaDB-Konfigurationsdatei (Neustart erforderlich):

server_audit_events = 'CONNECT,QUERY,TABLE'

Oder dynamisch zur Laufzeit setzen mit SET GLOBAL (benötigt keinen Neustart, aber nicht persistent):

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

Dies ist das Beispiel eines Audit-Ereignisses:

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

Ein Eintrag in diesem Protokoll besteht aus einer Reihe von Informationen, die durch ein Komma getrennt sind und die folgenden Informationen enthalten:

Zeitstempel
Der MySQL-Host (identisch mit dem Wert von SELECT @@hostname)
Der Datenbankbenutzer
Host, mit dem sich der Benutzer verbunden hat
Verbindungs-ID
Thread-ID
Betrieb
Datenbank
SQL-Anweisung/Befehl
Rückgabecode. 0 bedeutet, dass die Operation eine Erfolgsantwort zurückgibt (auch leer), während ein Wert ungleich Null einen Fehler bei der Ausführung der Operation bedeutet, wie z. B. eine fehlgeschlagene Abfrage aufgrund von Syntax- oder Berechtigungsfehlern.

Beim Filtern der Einträge würde man ein einfaches grep ausführen und nach einem bestimmten Muster suchen:

$ 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

Standardmäßig werden alle Passwortwerte mit Sternchen maskiert:

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

Benutzerfilterung prüfen

Wenn Sie alles verfolgen, werden Sie wahrscheinlich mit dem überwachenden Benutzer für seine Stichprobenverantwortung überschwemmt, wie im folgenden Beispiel gezeigt:

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

Im Zeitraum von einer Sekunde können wir 14 QUERY-Ereignisse sehen, die vom Audit-Plugin für unseren überwachenden Benutzer namens "cmon" aufgezeichnet wurden. In unserem Test-Workload liegt die Protokollierungsrate bei etwa 32 KB pro Minute, was sich auf bis zu 46 MB pro Tag summiert. Je nach Speichergröße und E/A-Kapazität kann dies bei einigen Workloads zu viel sein. Daher wäre es besser, den überwachenden Benutzer aus der Audit-Protokollierung herauszufiltern, damit wir eine sauberere Ausgabe haben und viel einfacher zu auditieren und zu analysieren sind.

Abhängig von den Sicherheits- und Überwachungsrichtlinien könnten wir den unerwünschten Benutzer wie den überwachenden Benutzer herausfiltern, indem wir die folgende Variable in der MariaDB-Konfigurationsdatei verwenden (Neustart erforderlich):

server_audit_excl_users='cmon'

Oder dynamisch zur Laufzeit setzen mit SET GLOBAL (benötigt keinen Neustart, aber nicht persistent):

MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'

Sie können mehrere Datenbankbenutzer hinzufügen, getrennt durch Kommas. Nachdem wir das obige hinzugefügt hatten, bekamen wir ein saubereres Audit-Log, wie unten (nichts mehr vom 'cmon'-Benutzer):

$ 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

Verwaltung der Protokollrotation

Da das Überwachungsprotokoll eine große Anzahl von Ereignissen erfassen wird, wird empfohlen, eine geeignete Protokollrotation dafür zu konfigurieren. Andernfalls würden wir mit einer enormen Größe der Protokolldatei enden, was die Analyse sehr erschwert. Während der Server läuft und server_audit_output_type=file ist, können wir die Protokolldateirotation erzwingen, indem wir die folgende Anweisung verwenden:

MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;

Für die automatische Protokollrotation sollten wir die folgenden Variablen in der MariaDB-Konfigurationsdatei setzen:

server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30

Oder dynamisch zur Laufzeit setzen mit SET GLOBAL (kein Neustart erforderlich):

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

Um die Revisionsprotokollrotation zu deaktivieren, setzen Sie einfach server_audit_file_rotations auf 0. Der Standardwert ist 9. Die Protokollrotation erfolgt automatisch, nachdem sie den angegebenen Schwellenwert erreicht hat, und behält die letzten 30 Protokolle bei, was bedeutet, dass die Auditprotokollierung der letzten 30 Tage.

Prüfung mit Syslog oder Rsyslog Facility

Die Verwendung der syslog- oder rsyslog-Funktion erleichtert die Protokollverwaltung, da sie die Protokollierung von verschiedenen Systemtypen in einem zentralen Repository ermöglicht. Anstatt eine weitere Protokollierungskomponente zu pflegen, können wir das MariaDB-Audit anweisen, sich bei syslog zu protokollieren. Dies ist praktisch, wenn Sie einen Protokollsammler/Streamer für Protokollanalysedienste wie Splunk, LogStash, Loggly oder Amazon CloudWatch haben.

Setzen Sie dazu die folgenden Zeilen in der MariaDB-Konfigurationsdatei (Neustart erforderlich):

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

Oder wenn Sie zur Laufzeit wechseln wollen (benötigt keinen Neustart, aber nicht persistent):

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

Die Einträge ähneln dem Syslog-Format:

$ 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

Wenn Sie einen Remote-Protokollierungsdienst für ein zentralisiertes Protokollierungs-Repository einrichten möchten, können wir rsyslog verwenden. Der Trick besteht darin, die Variable server_audit_syslog_facility zu verwenden, in der wir einen Filter erstellen können, um die Protokollierung zu erleichtern, ähnlich wie unten:

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

Davor sind jedoch einige Schritte erforderlich. Betrachten Sie die folgende MariaDB-Master-Slave-Replikationsarchitektur mit einem zentralisierten rsyslog-Server:

In diesem Beispiel laufen alle Server auf Ubuntu 20.04. Auf dem rsyslog-Zielserver müssen wir Folgendes in /etc/rsyslog.conf festlegen:

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

Beachten Sie, dass der Teil "&~" wichtig ist und lassen Sie sich das nicht entgehen. Im Grunde weist es die Protokollierungsfunktion an, sich bei /var/log/mariadb-centralized-audit.log anzumelden und die weitere Verarbeitung direkt danach zu stoppen.

Erstellen Sie als Nächstes die Zielprotokolldatei mit dem richtigen Dateieigentümer und der richtigen Berechtigung:

$ 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 neu starten:

$ systemctl restart rsyslog

Stellen Sie sicher, dass alle zugänglichen IP-Adressen auf TCP-Port 514 überwacht werden:

$ 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

Wir haben die Konfiguration des Ziel-rsyslog-Servers abgeschlossen. Jetzt können wir den Quellteil konfigurieren. Erstellen Sie auf dem MariaDB-Server eine neue separate rsyslog-Konfigurationsdatei unter /etc/rsyslog.d/50-mariadb-audit.conf und fügen Sie die folgenden Zeilen hinzu:

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

Bei den Einstellungen im ersten Abschnitt geht es darum, eine Warteschlange auf der Festplatte zu erstellen, was empfohlen wird, damit kein Logeintrag verloren geht. Die letzte Zeile ist wichtig. Wir haben die Variable server_audit_syslog_facility für das Audit-Plugin in LOG_LOCAL6 geändert. Hier haben wir "local6.*" als Filter angegeben, um nur Syslog-Einträge mit der Einrichtung local6 an rsyslog weiterzuleiten, das auf dem rsyslog-Server 172.31.6.200 auf Port 514 über das TCP-Protokoll läuft.

Um die Änderungen für rsyslog zu aktivieren, besteht der letzte Schritt darin, rsyslog auf dem MariaDB-Server neu zu starten, um die Änderungen zu aktivieren:

$ systemctl restart rsyslog

Jetzt ist rsyslog auf dem Quellknoten korrekt konfiguriert. Wir können testen, indem wir auf den MariaDB-Server zugreifen und einige Aktivitäten ausführen, um Audit-Ereignisse zu generieren. Sie sollten sehen, dass die Audit-Log-Einträge hierher weitergeleitet werden:

$ 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

Abschließende Gedanken

Das MariaDB-Audit-Plugin kann auf viele Arten konfiguriert werden, um es an Ihre Sicherheits- und Audit-Richtlinien anzupassen. Audit-Informationen können Ihnen bei der Behebung von Leistungs- oder Anwendungsproblemen helfen und zeigen Ihnen genau, welche SQL-Abfragen verarbeitet werden.