Das Audit-Plugin für Compliance-Anforderungen einsetzen: Zugriffsprotokollierung in MySQL

1. Warum Audit-Logging für Magento-Shops mit Kundendaten relevant ist

Ein Magento-Shop speichert in seiner Datenbank weit mehr als nur Produktdaten: Kundenadressen, Bestellhistorien, teilweise Zahlungsreferenzen und in vielen Konfigurationen auch Daten aus B2B-Sonderpreisen oder individuellen Vertragskonditionen. Die DSGVO verlangt in Artikel 32 Absatz 1 Buchstabe d ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit technischer Maßnahmen zur Sicherstellung der Sicherheit der Verarbeitung, und ein Zugriffsprotokoll auf Datenbankebene ist dafür eine der direktesten Nachweisformen.

Ohne Audit-Logging lässt sich im Nachhinein oft nicht mehr rekonstruieren, ob ein ungewöhnlicher Datenzugriff durch einen legitimen administrativen Vorgang, einen fehlerhaft konfigurierten Reporting-Job oder tatsächlich durch einen kompromittierten Zugang verursacht wurde. Gerade bei einem Sicherheitsvorfall verlangt die Meldepflicht nach Artikel 33 DSGVO innerhalb von 72 Stunden eine belastbare Einschätzung des Umfangs, die ohne ein durchsuchbares Zugriffsprotokoll kaum seriös möglich ist.

2. Überblick: MySQL Enterprise Audit versus Percona Audit Log Plugin

MySQL selbst bringt in der kostenpflichtigen Enterprise Edition das Plugin audit_log mit, das Verbindungen, ausgeführte Anweisungen und administrative Aktionen in einem strukturierten Format protokolliert. In der frei verfügbaren MySQL Community Edition fehlt dieses Plugin jedoch vollständig, was für viele Magento-Betreiber, die aus Kostengründen auf Community-Editionen oder Percona Server setzen, eine praktische Lücke darstellt.

Percona Server für MySQL, ein binärkompatibler, quelloffener Fork, schließt diese Lücke mit dem Percona Audit Log Plugin, das eine mit dem Enterprise-Pendant weitgehend kompatible API und ein sehr ähnliches Funktionsspektrum bietet, jedoch ohne Lizenzkosten. Da Percona Server als Drop-in-Ersatz für Standard-MySQL in den meisten Magento-Setups problemlos funktioniert, ist der Wechsel für audit-pflichtige Umgebungen oft die wirtschaftlichste Lösung, sofern nicht ohnehin bereits eine Enterprise-Lizenz vorliegt.

3. Installation und Aktivierung des Percona Audit Log Plugin

Das Plugin ist in Percona Server bereits als Shared-Library mitgeliefert und muss lediglich über INSTALL PLUGIN aktiviert werden, ein Serverneustart ist dafür nicht notwendig. Nach der Aktivierung beginnt das Plugin sofort mit der Protokollierung gemäss den Standardeinstellungen, die zunächst noch keine Filterung vornehmen und deshalb vor dem produktiven Einsatz unbedingt angepasst werden sollten, da sonst binnen kurzer Zeit erhebliche Log-Mengen entstehen.

Für eine dauerhafte Aktivierung über Neustarts hinweg empfiehlt sich zusätzlich der Eintrag in der Konfigurationsdatei, damit das Plugin nach jedem geplanten oder ungeplanten Neustart automatisch wieder geladen wird, ohne dass ein manueller Eingriff nötig ist.

-- Plugin zur Laufzeit aktivieren (kein Neustart erforderlich)
INSTALL PLUGIN audit_log SONAME 'audit_log.so';

-- Aktivierung dauerhaft in der Konfiguration verankern
-- /etc/mysql/percona-server.conf.d/mysqld.cnf
-- [mysqld]
-- plugin-load-add = audit_log.so
-- audit_log_format = JSON

-- Status prüfen
SHOW PLUGINS;

4. Filterkonfiguration: audit_log_filter gegen Log-Flut einsetzen

Ohne Filterung protokolliert das Plugin standardmäßig jede einzelne SQL-Anweisung, was bei einem stark frequentierten Magento-Shop schnell mehrere Gigabyte an Logdaten pro Tag erzeugt und dabei überwiegend irrelevante, lesende Anfragen des Anwendungsbetriebs enthält. Die moderne, JSON-basierte Filterkonfiguration über audit_log_filter löst dieses Problem, indem sie erlaubt, Regeln pro Nutzerkonto und Ereignisklasse zu definieren, statt pauschal alles mitzuschreiben.

In der Praxis bewährt sich ein Ansatz, bei dem lesende Standardzugriffe des Magento-Anwendungsnutzers grösstenteils von der Protokollierung ausgenommen werden, während administrative Aktionen, Schemaänderungen, Rechteänderungen und jeglicher Zugriff über privilegierte Konten wie den Migrations- oder DBA-Nutzer vollständig protokolliert werden. Diese gezielte Auswahl reduziert das Logvolumen um eine Grössenordnung, ohne die eigentlich sicherheitsrelevanten Ereignisse zu verlieren.

-- Filter definieren: administrative Ereignisse vollstaendig protokollieren
SELECT audit_log_filter_set_filter('log_admin', '{ "filter": { "class": { "name": "general", "event": { "name": ["error", "status"] } } } }');

-- Bestimmten Nutzer (DBA/Migration) dem strengen Filter zuordnen
SELECT audit_log_filter_set_user('ci_migration@%', 'log_admin');

-- Regulaeren Anwendungsnutzer nur bei DDL/DCL protokollieren
SELECT audit_log_filter_set_filter('log_app', '{ "filter": { "class": { "name": "table_access", "event": "insert" } } }');
SELECT audit_log_filter_set_user('magento_app@%', 'log_app');

5. Log-Format wählen: JSON, Rotation und Aufbewahrung praktisch konfigurieren

Das JSON-Format ist gegenüber dem älteren XML-Format klar zu bevorzugen, da es sich deutlich einfacher mit Standard-Tools wie jq auswerten und in moderne Log-Pipelines einspeisen lässt, während das ursprüngliche XML-Format vor allem aus Kompatibilitätsgründen mit älteren Auswertungswerkzeugen noch existiert. Die Rotation wird über audit_log_rotate_on_size gesteuert, das eine maximale Dateigröße definiert, nach deren Erreichen automatisch eine neue Logdatei begonnen wird.

Die Anzahl aufbewahrter Rotationen legt audit_log_rotations fest, wobei dieser Wert nicht isoliert von der eigentlichen, oft rechtlich vorgeschriebenen Aufbewahrungsfrist betrachtet werden sollte. In vielen Fällen ist es sinnvoller, lokal nur wenige, kurzlebige Rotationen vorzuhalten und die eigentliche Langzeitarchivierung an ein externes, unveränderliches Speichersystem auszulagern, das gezielt vor nachträglicher Manipulation schützt.

6. Praktische Anwendungsfälle für Magento-Shops mit Kundendaten

Ein typischer Anwendungsfall ist die lückenlose Nachvollziehbarkeit, welches Administrationskonto wann auf die Tabelle customer_entity oder customer_address_entity außerhalb der normalen Anwendungslogik zugegriffen hat, etwa über einen direkten Datenbankzugriff bei einer Support-Anfrage. Ohne Audit-Log lässt sich ein solcher Zugriff im Nachhinein bestenfalls über allgemeine Shell-Historie rekonstruieren, was für einen belastbaren Compliance-Nachweis nicht ausreicht.

Ein zweiter, ebenso wichtiger Anwendungsfall betrifft Admin-Nutzer-Aktionen innerhalb von Magento selbst: Änderungen an Zahlungskonfigurationen, das Anlegen neuer Admin-Konten oder Exporte von Kundendaten über den integrierten Export sollten sowohl auf Anwendungsebene über Magentos eigenes Admin-Aktionsprotokoll als auch auf Datenbankebene sichtbar sein, um bei Unstimmigkeiten beide Quellen gegeneinander abgleichen zu können.

7. Performance-Overhead und Tuning der Protokollierung

Jede protokollierte Anweisung erzeugt zusätzlichen Schreibaufwand, der bei einer ungefilterten Vollprotokollierung auf stark frequentierten Systemen durchaus messbar wird, insbesondere wenn die Logdatei auf demselben Speichermedium wie die eigentlichen Datenbankdateien liegt. Eine gezielte Filterung, wie im vorherigen Abschnitt beschrieben, ist deshalb nicht nur eine Frage der Übersichtlichkeit, sondern auch der Performance, da nur ein kleiner Bruchteil aller Anfragen tatsächlich geschrieben werden muss.

Zusätzlich lässt sich der Overhead senken, indem die Audit-Logdatei auf einem separaten Datenträger liegt, der nicht mit dem I/O-Pfad der InnoDB-Datendateien konkurriert, sowie durch eine bewusst moderate Rotationsgröße, die verhindert, dass eine einzelne, sehr große Logdatei bei jedem Schreibvorgang unnötig lange offen gehalten werden muss.

8. Integration mit SIEM- und Log-Aggregationssystemen

Ein isoliertes Audit-Log auf dem Datenbankserver selbst nützt im Ernstfall wenig, wenn ein Angreifer mit ausreichenden Rechten die Logdatei einfach löschen oder manipulieren kann. Deshalb gehört die zeitnahe Weiterleitung an ein zentrales, vom Datenbankserver getrenntes System zur Grundausstattung jeder ernsthaften Audit-Strategie, etwa über rsyslog mit Datei-Überwachung oder über einen leichtgewichtigen Log-Shipper wie Filebeat, der die JSON-Einträge direkt an eine Elasticsearch- oder OpenSearch-Instanz weiterreicht.

In einer solchen zentralisierten Umgebung lassen sich zusätzlich Alarmregeln definieren, etwa eine Benachrichtigung, sobald ein privilegiertes Konto außerhalb der üblichen Wartungsfenster auf kundenbezogene Tabellen zugreift, was die reine Protokollierung um eine proaktive Erkennungskomponente ergänzt.

9. Aufbewahrungsfristen und Zugriffsschutz auf die Audit-Logs selbst

Die konkrete Aufbewahrungsfrist für Audit-Logs richtet sich nach internen Compliance-Vorgaben und branchenspezifischen Anforderungen, wobei ein Zeitraum von sechs bis zwölf Monaten in der Praxis üblich ist und gleichzeitig mit den eigenen Datenschutz-Löschkonzepten abgeglichen werden sollte, damit die Logs selbst nicht länger als nötig personenbezogene Daten enthalten. Wichtig ist, dass diese Frist unabhängig von der technischen Rotation im Datenbanksystem in der externen Archivierung durchgesetzt wird.

Ebenso wichtig ist der Zugriffsschutz auf die Logdateien selbst: Wer Schreibzugriff auf das Audit-Log hat, kann im Zweifel eigene Spuren verwischen, weshalb restriktive Dateiberechtigungen, eine getrennte Zielsystem-Berechtigung für die Log-Aggregation und, wo verfügbar, ein Append-only- beziehungsweise Write-once-Speichermodell für die archivierten Logs empfehlenswert sind. Damit schließt sich der Kreis zwischen technischer Protokollierung und einem tatsächlich belastbaren Compliance-Nachweis.

10. Zusammenfassung

11. FAQ: Audit-Plugin für Compliance: das Wichtigste auf einen Blick