Benutzerverwaltung und Passwort-Policies in MySQL sauber umsetzen

1. Warum granulare Benutzerverwaltung in Magento-Datenbankumgebungen wichtig ist

Ein einzelner Datenbanknutzer mit vollen Rechten, den Anwendung, Cron-Jobs, Reporting-Tools und gelegentliche manuelle Eingriffe gemeinsam nutzen, ist bequem einzurichten, aber im Betrieb ein erhebliches Risiko: Wird das Passwort dieses einen Kontos kompromittiert, etwa über eine ungenügend abgesicherte env.php in einem alten Backup, hat der Angreifer sofort vollen Zugriff auf Lese-, Schreib- und Schema-Operationen gleichzeitig.

Granulare Benutzerverwaltung begrenzt den Schaden im Fall einer Kompromittierung auf den Umfang, den das jeweilige Konto tatsächlich benötigt, und macht darüber hinaus jede Aktion einem konkreten Zweck zuordenbar, was sowohl die Fehlersuche als auch spätere Audit-Auswertungen erheblich erleichtert. In Kombination mit Audit-Logging, wie es in einem separaten Artikel dieser Reihe behandelt wird, entsteht so ein Nachvollziehbarkeits-Fundament, das ein einzelnes Sammelkonto grundsätzlich nicht bieten kann.

2. Die validate_password-Komponente installieren und konfigurieren

Seit MySQL 8.0 wird Passwortstärke nicht mehr über das ältere Plugin-System, sondern über eine Komponente namens validate_password durchgesetzt, die als serverseitiges Komponentenframework tiefer in den Server integriert ist als klassische Plugins. Nach der Installation stehen drei vordefinierte Policy-Stufen zur Verfügung: LOW prüft nur die Mindestlänge, MEDIUM verlangt zusätzlich eine Mischung aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen, und STRONG vergleicht zusätzlich gegen eine konfigurierbare Wörterbuchdatei häufig verwendeter, unsicherer Passwörter.

Für produktive Magento-Umgebungen ist die Stufe STRONG in Kombination mit einer unternehmensspezifischen Wörterbuchdatei empfehlenswert, wobei die Einzelparameter wie Mindestlänge und Anzahl geforderter Sonderzeichen über eigene Systemvariablen zusätzlich verschärft werden können, unabhängig von der gewählten Policy-Stufe.

-- Komponente installieren (kein Neustart erforderlich)
INSTALL COMPONENT 'file://component_validate_password';

-- Strenge Policy-Stufe aktivieren und Mindestlänge erhöhen
SET GLOBAL validate_password.policy = 'STRONG';
SET GLOBAL validate_password.length = 14;
SET GLOBAL validate_password.mixed_case_count = 1;
SET GLOBAL validate_password.number_count = 1;
SET GLOBAL validate_password.special_char_count = 1;

-- Verhindert, dass das Passwort den Nutzernamen enthaelt
SET GLOBAL validate_password.check_user_name = ON;

3. Passwort-Ablauf und -Historie: erzwungene Rotation ohne Wiederverwendung

Über die globale Variable default_password_lifetime lässt sich eine serverweite Standard-Gültigkeitsdauer für Passwörter festlegen, die sich pro Nutzer mit ALTER USER ... PASSWORD EXPIRE INTERVAL n DAY gezielt überschreiben lässt, etwa um für hochprivilegierte Konten eine kürzere Frist als für den regulären Anwendungsnutzer zu erzwingen. Läuft ein Passwort ab, verweigert MySQL nach der nächsten Anmeldung sämtliche Anweisungen außer dem Setzen eines neuen Passworts, bis dieses erneuert wurde.

Damit ein abgelaufenes Passwort nicht einfach durch dasselbe alte Passwort ersetzt wird, sorgen password_history und password_reuse_interval dafür, dass eine bestimmte Anzahl vorheriger Passwörter beziehungsweise ein bestimmter Zeitraum lang keine Wiederverwendung möglich ist. Für Konten mit direktem menschlichem Zugriff, etwa DBA-Accounts, ist eine Kombination aus beiden Mechanismen sinnvoll, während rein technische Anwendungskonten meist über andere Mechanismen wie ein Secrets-Management-System rotiert werden.

-- Passwort läuft nach 90 Tagen ab, bei DBA-Konto strenger
ALTER USER 'dba_maria'@'localhost' PASSWORD EXPIRE INTERVAL 60 DAY;

-- Keine Wiederverwendung der letzten 5 Passwoerter innerhalb von 365 Tagen
ALTER USER 'dba_maria'@'localhost' PASSWORD HISTORY 5 PASSWORD REUSE INTERVAL 365 DAY;

4. Das Prinzip der geringsten Rechte: Rollen statt Einzelrechten

Seit MySQL 8.0 lassen sich Rechte über CREATE ROLE zu benannten Rollen bündeln, die anschließend einzelnen Nutzern zugewiesen werden, statt bei jedem neuen Konto die vollständige Liste einzelner Rechte erneut zu vergeben. Dieser Ansatz reduziert nicht nur den administrativen Aufwand, sondern macht auch nachträgliche Rechteänderungen zentral steuerbar: Eine Anpassung an einer Rolle wirkt sich automatisch auf alle zugewiesenen Nutzer aus, ohne dass jeder Account einzeln angefasst werden muss.

Für ein typisches Magento-Datenbank-Setup bewährt sich eine Aufteilung in mindestens drei Rollen mit klar unterschiedlichem Rechteumfang, die im Folgenden im Detail behandelt werden: eine reine Lese-Rolle für Reporting, eine Rolle mit erweiterten Schema-Rechten für Migrationen, und eine auf Datenmanipulation beschränkte Rolle für den laufenden Anwendungsbetrieb.

-- Rollen anlegen
CREATE ROLE 'role_reporting', 'role_migration', 'role_app_runtime';

-- Rechte den Rollen zuweisen (Beispiel Reporting)
GRANT SELECT ON magento.* TO 'role_reporting';

-- Rolle einem konkreten Nutzer zuweisen und als Standardrolle setzen
GRANT 'role_reporting' TO 'bi_readonly'@'10.0.4.%';
SET DEFAULT ROLE 'role_reporting' TO 'bi_readonly'@'10.0.4.%';

5. Getrennte User: Read-Only-Reporting-Nutzer ohne Schreibrechte

Business-Intelligence-Werkzeuge, individuelle Reporting-Skripte und Analyse-Dashboards benötigen für ihre Arbeit ausschließlich lesenden Zugriff, oft sogar nur auf einen Teil der Tabellen, etwa Bestellungen und Produktkataloge, nicht jedoch auf sensible Kernbereiche wie Admin-Zugangsdaten. Ein dedizierter Reporting-Nutzer mit ausschließlich SELECT-Rechten stellt sicher, dass ein fehlerhaftes oder kompromittiertes Reporting-Skript niemals versehentlich Produktionsdaten verändert.

Wo verfügbar, sollte dieser Nutzer zusätzlich ausschließlich gegen eine Read-Replica statt gegen die primäre Datenbank verbinden, sodass selbst rechenintensive, schlecht optimierte Reporting-Abfragen keine Auswirkung auf die Performance der eigentlichen Shop-Transaktionen haben können.

6. Migrations-User mit erweiterten DDL-Rechten, zeitlich begrenzt

Schema-Migrationen, wie sie bei jedem Magento-Setup-Upgrade über setup:upgrade ausgeführt werden, benötigen deutlich weitreichendere Rechte als der laufende Anwendungsbetrieb, insbesondere CREATE, ALTER, DROP und INDEX. Diese Rechte sollten niemals dauerhaft dem regulären Anwendungsnutzer zugewiesen werden, sondern einem eigenen, ausschließlich für Deployments genutzten Konto vorbehalten bleiben, das in der Regel nur von der CI/CD-Pipeline verwendet wird.

In besonders sicherheitssensiblen Umgebungen lässt sich dieses Konto sogar zeitlich begrenzt aktivieren, indem es außerhalb eines aktiven Deployment-Fensters über ALTER USER ... ACCOUNT LOCK gesperrt und unmittelbar vor einem geplanten Deployment automatisiert wieder entsperrt wird, wodurch das Zeitfenster für einen möglichen Missbrauch dieses hochprivilegierten Kontos minimiert wird.

-- Migrationsnutzer außerhalb von Deployments sperren
ALTER USER 'ci_migration'@'10.0.3.%' ACCOUNT LOCK;

-- Kurz vor einem geplanten Deployment automatisiert entsperren
ALTER USER 'ci_migration'@'10.0.3.%' ACCOUNT UNLOCK;

7. Der App-Betriebs-User: minimale Rechte für den laufenden Magento-Betrieb

Der Nutzer, mit dem sich Magento im Normalbetrieb über app/etc/env.php verbindet, benötigt für den überwiegenden Teil seiner Arbeit lediglich SELECT, INSERT, UPDATE und DELETE, jedoch keinerlei Schema-Rechte wie CREATE, ALTER, DROP oder GRANT. Diese bewusste Einschränkung hat einen konkreten Sicherheitsnutzen: Selbst eine SQL-Injection-Schwachstelle in einer Drittanbieter-Extension kann bei einem derart eingeschränkten Konto keine Tabellen löschen oder neue Admin-Konten über eine manipulierte Schema-Änderung anlegen.

In der Praxis zeigt sich, dass viele historisch gewachsene Magento-Installationen dem Anwendungsnutzer aus Bequemlichkeit weitreichende Rechte einräumen, weil einzelne Erweiterungen gelegentlich DDL-Operationen ausführen. Diese Fälle sollten identifiziert und wenn möglich auf den Migrations-User verlagert werden, statt dem dauerhaften Betriebskonto pauschal alle Rechte zu belassen.

8. Bestehende Rechte auditieren: SHOW GRANTS und information_schema

Bevor eine bestehende, historisch gewachsene Rechtestruktur bereinigt werden kann, muss zunächst der Ist-Zustand vollständig erfasst werden. Der Befehl SHOW GRANTS FOR liefert für ein einzelnes Konto eine lesbare Übersicht, während für eine systematische, serverweite Auswertung eine Abfrage gegen information_schema.USER_PRIVILEGES und information_schema.SCHEMA_PRIVILEGES deutlich effizienter ist, da sich diese Sicht direkt filtern und mit anderen Metadaten verknüpfen lässt.

Ein sinnvoller erster Schritt ist eine Bestandsaufnahme aller Konten mit dem Recht GRANT OPTION oder mit administrativen Rechten wie SUPER, da diese Konten das grösste Schadenspotenzial im Kompromittierungsfall besitzen und deshalb zuerst auf tatsächliche Notwendigkeit geprüft werden sollten.

-- Rechte eines einzelnen Kontos anzeigen
SHOW GRANTS FOR 'magento_app'@'10.0.2.%';

-- Konten mit weitreichenden administrativen Rechten identifizieren
SELECT GRANTEE, PRIVILEGE_TYPE
FROM information_schema.USER_PRIVILEGES
WHERE PRIVILEGE_TYPE IN ('SUPER', 'GRANT OPTION', 'DROP', 'SHUTDOWN')
ORDER BY GRANTEE;

9. Das Standard-Authentifizierungsplugin caching_sha2_password und Fazit

Seit MySQL 8.0 ist caching_sha2_password das Standard-Authentifizierungsplugin und löst das ältere, kryptografisch schwächere mysql_native_password ab, das mittlerweile als veraltet gilt und in aktuellen MySQL-Versionen standardmäßig deaktiviert ist. Ältere PHP-PDO-Treiber oder Legacy-Anwendungen können unter Umständen Probleme mit dem neuen Plugin haben, weshalb ein gezielter Kompatibilitätstest vor einer produktiven Umstellung sinnvoll ist, statt das ältere Plugin pauschal aus Bequemlichkeit weiter zu verwenden.

Zusammengenommen ergeben validate_password, konsequente Passwort-Rotation und eine klare Rollentrennung nach dem Prinzip der geringsten Rechte eine Benutzerverwaltung, die nicht nur Compliance-Anforderungen erfüllt, sondern im Ernstfall den Schaden einer Kompromittierung tatsächlich begrenzt, statt ihn über ein einziges Sammelkonto unnötig zu vergrößern.

10. Zusammenfassung

11. FAQ: Benutzerverwaltung und Passwort-Policies: das Wichtigste auf einen Blick