MySQL-8-Rollen: Granulare Rechteverwaltung statt Nutzer-für-Nutzer-GRANTs

1. Warum Einzel-GRANTs pro Nutzer auf Dauer problematisch werden

In einem klassischen, rollenlosen Rechtemodell wird jedes einzelne Recht direkt an einen konkreten Nutzeraccount vergeben, sodass für fünf gleichberechtigte Analysten fünfmal dieselbe Liste von GRANT-Anweisungen ausgeführt werden muss. Sobald sich das benötigte Rechteset ändert, etwa weil eine zusätzliche Tabelle für Reporting freigegeben werden soll, müssen alle fünf Accounts einzeln nachgepflegt werden, was in der Praxis regelmäßig dazu führt, dass einzelne Accounts übersehen werden und die tatsächlichen Rechte über die Zeit auseinanderlaufen.

Dieses Auseinanderlaufen ist nicht nur ein Wartungsproblem, sondern ein echtes Sicherheitsrisiko: Ein ehemaliger Mitarbeiter-Account, der versehentlich nicht vollständig deaktiviert wurde, oder ein Account mit historisch gewachsenen, nie wieder entzogenen Zusatzrechten, ist in einem rollenbasierten Modell durch einen einzigen zentralen Blick auf die Rollenzuweisung sofort erkennbar, in einem Einzel-GRANT-Modell dagegen nur durch mühsames Vergleichen jedes einzelnen Accounts.

2. CREATE ROLE und GRANT TO ROLE: Grundlegende Syntax

Eine Rolle wird syntaktisch fast identisch zu einem Nutzeraccount angelegt, unterscheidet sich aber dadurch, dass sie sich niemals direkt anmelden kann, sondern ausschließlich als Container für gebündelte Rechte dient. Rechte werden der Rolle über dieselbe GRANT-Syntax zugewiesen, die auch für reguläre Nutzer verwendet wird, mit dem einzigen Unterschied, dass als Ziel statt eines Nutzernamens der Rollenname angegeben wird.

Die eigentliche Verbindung zwischen Rolle und Nutzer entsteht anschließend über eine weitere GRANT-Anweisung, die die Rolle einem oder mehreren konkreten Nutzeraccounts zuweist. Diese Trennung zwischen Rechtedefinition auf der Rolle und Zuweisung an Nutzer ist der eigentliche strukturelle Vorteil: Ändert sich das Rechteset, genügt eine einzige Anpassung an der Rolle, und alle zugewiesenen Nutzer erben die Änderung automatisch.

-- Rolle anlegen
CREATE ROLE 'analyst_readonly';

-- Rechte einmalig der Rolle zuweisen
GRANT SELECT ON magento2db.* TO 'analyst_readonly';

-- Rolle einem konkreten Nutzer zuweisen
CREATE USER 'jsmith'@'%' IDENTIFIED BY 'ein_sicheres_passwort';
GRANT 'analyst_readonly' TO 'jsmith'@'%';

3. Mandatory- und optional aktivierte Rollen im Unterschied

Eine einem Nutzer zugewiesene Rolle ist standardmäßig nicht automatisch beim Login aktiv, sie muss zunächst explizit über SET ROLE aktiviert werden, was für Sicherheitsaudits praktisch ist, aber im Alltag zusätzliche Reibung erzeugt. Für Rollen, die praktisch immer aktiv sein sollen, etwa das Grundrecht eines App-Users auf seine eigene Datenbank, lässt sich über die Systemvariable activate_all_roles_on_login oder über SET DEFAULT ROLE eine automatische Aktivierung beim Login konfigurieren.

Alternativ lässt sich eine Rolle über mandatory_roles serverweit als verpflichtend markieren, sodass sie für jeden Nutzer implizit verfügbar ist, unabhängig von einer expliziten Zuweisung über GRANT. Dieser Mechanismus eignet sich besonders für organisationsweite Basisrechte, etwa Leserechte auf eine zentrale Referenztabelle mit Landescodes, die wirklich jeder Account benötigt, unabhängig von seiner sonstigen Funktion.

-- Rolle beim Login automatisch aktivieren
ALTER USER 'jsmith'@'%' DEFAULT ROLE 'analyst_readonly';

-- Serverweit verpflichtende Rolle festlegen (my.cnf oder global)
SET PERSIST mandatory_roles = 'basic_reference_reader';

4. Rollen kombinieren und hierarchisch aufbauen

Rollen lassen sich nicht nur Nutzern, sondern auch anderen Rollen zuweisen, wodurch sich hierarchische Rechtestrukturen abbilden lassen, ohne Rechte mehrfach zu definieren. Eine Rolle 'app_write' kann beispielsweise alle Rechte einer bereits bestehenden Rolle 'app_read' erben und zusätzlich um Schreibrechte ergänzen, statt die Leserechte redundant erneut aufzulisten.

Diese Kompositionsfähigkeit reduziert nicht nur Schreibaufwand bei der Ersteinrichtung, sondern erleichtert auch spätere Audits erheblich, weil sich die tatsächlich wirksamen Rechte eines Nutzers über SHOW GRANTS mit der Option USING vollständig nachvollziehen lassen, inklusive aller über Rollenketten vererbten Einzelrechte.

CREATE ROLE 'app_read', 'app_write';
GRANT SELECT ON magento2db.* TO 'app_read';
GRANT INSERT, UPDATE, DELETE ON magento2db.* TO 'app_write';
GRANT 'app_read' TO 'app_write';

-- Effektive Rechte eines Nutzers inklusive Rollen anzeigen
SHOW GRANTS FOR 'shopapp'@'%' USING 'app_write';

5. Praktisches Rechtemodell für ein Team mit drei Zugriffsstufen

Für ein typisches Team rund um eine Magento-Datenbank bietet sich eine Aufteilung in mindestens drei klar getrennte Rollen an: eine Read-Only-Analyst-Rolle mit reinem SELECT-Zugriff für Reporting und Ad-hoc-Auswertungen, eine App-User-Rolle mit den für den laufenden Shop-Betrieb tatsächlich benötigten DML-Rechten ohne DDL-Berechtigung, und eine DBA-Rolle mit vollem Zugriff inklusive Schema-Änderungen, Backup-Rechten und Nutzerverwaltung.

Entscheidend für die praktische Sicherheit ist, dass die App-User-Rolle explizit keine DDL-Rechte wie CREATE, ALTER oder DROP enthält, selbst wenn die Anwendung im laufenden Betrieb niemals ein Schema ändert. Ein kompromittierter Anwendungs-Account ohne DDL-Rechte begrenzt den möglichen Schaden strukturell auf Datenmanipulation, während ein Account mit vollem Zugriff im schlimmsten Fall die gesamte Datenbankstruktur gefährden könnte.

CREATE ROLE 'readonly_analyst', 'shop_app_user', 'db_admin';

GRANT SELECT ON magento2db.* TO 'readonly_analyst';

GRANT SELECT, INSERT, UPDATE, DELETE
    ON magento2db.* TO 'shop_app_user';

GRANT ALL PRIVILEGES ON magento2db.* TO 'db_admin' WITH GRANT OPTION;
GRANT 'readonly_analyst' TO 'db_admin';

6. Temporäre Rechteerweiterung ohne dauerhafte GRANTs

Ein häufiger Anwendungsfall ist eine kurzfristig benötigte Rechteerweiterung, etwa wenn ein Analyst für eine einmalige Untersuchung zusätzlich Schreibzugriff auf eine bestimmte Staging-Tabelle benötigt. Statt dafür dauerhafte GRANTs zu vergeben, die anschließend wieder manuell entfernt werden müssten, lässt sich eine zusätzliche, eng begrenzte Rolle anlegen, die der Nutzer nur bei Bedarf über SET ROLE für die aktuelle Session aktiviert.

Nach Ende der Session ist diese zusätzliche Rolle automatisch wieder inaktiv, ohne dass ein Administrator manuell eingreifen muss, und die Grundrechte des Nutzers bleiben unverändert auf dem regulären Niveau. Diese Technik reduziert die Zeitspanne erweiterter Rechte auf das tatsächlich benötigte Minimum und vermeidet die typische Ansammlung vergessener, nie wieder entzogener Sonderrechte.

CREATE ROLE 'staging_writer_temp';
GRANT INSERT, UPDATE ON magento2db.staging_import TO 'staging_writer_temp';
GRANT 'staging_writer_temp' TO 'jsmith'@'%';

-- Nutzer aktiviert die Rolle nur bei Bedarf für die aktuelle Session
SET ROLE 'staging_writer_temp';

7. Rollen widerrufen und Rechteänderungen zentral steuern

Verlässt ein Teammitglied das Projekt oder wechselt in eine andere Funktion, genügt ein einziger REVOKE-Befehl, um die Rollenzuweisung des betroffenen Nutzers zu entfernen, während die Rolle selbst mit allen zugehörigen Rechten für alle anderen Nutzer unverändert bestehen bleibt. Im Einzel-GRANT-Modell wäre dafür eine vollständige Liste einzelner REVOKE-Anweisungen nötig, mit dem entsprechenden Risiko, ein Recht schlicht zu vergessen.

Ebenso lässt sich eine Rolle mit DROP ROLE vollständig entfernen, wodurch alle Nutzer, denen sie zugewiesen war, das entsprechende Rechteset sofort verlieren, ohne dass jeder einzelne Nutzeraccount separat bearbeitet werden muss. Diese zentrale Steuerbarkeit ist gerade bei häufigen Team-Wechseln oder bei der regelmäßigen Rezertifizierung von Zugriffsrechten ein erheblicher operativer Vorteil.

-- Nur die Rollenzuweisung eines Nutzers entfernen
REVOKE 'shop_app_user' FROM 'former_employee'@'%';

-- Rolle inklusive aller Rechte für alle Nutzer vollstaendig entfernen
DROP ROLE 'staging_writer_temp';

8. Rollenzuweisungen auditieren und Abweichungen erkennen

Für regelmäßige Sicherheitsaudits liefert die Sicht information_schema.applicable_roles einen vollständigen Überblick darüber, welcher Nutzer welche Rollen zugewiesen bekommen hat und ob diese Zuweisung als Standardrolle beim Login aktiv ist. Diese Abfrage lässt sich problemlos automatisieren und regelmäßig gegen eine dokumentierte Soll-Liste abgleichen, um Abweichungen frühzeitig zu erkennen, statt sie erst bei einem tatsächlichen Sicherheitsvorfall zu bemerken.

Ergänzend zeigt mysql.role_edges die konkreten Beziehungen zwischen Rollen und Nutzern beziehungsweise zwischen Rollen untereinander auf Tabellenebene, was sich besonders für komplexere, mehrstufige Rollenhierarchien eignet, bei denen eine reine SHOW-GRANTS-Abfrage pro Nutzer schnell unübersichtlich wird.

SELECT grantee, role_name, is_default, is_mandatory
FROM information_schema.applicable_roles
ORDER BY grantee, role_name;

9. Bestehende Einzel-GRANTs schrittweise auf Rollen migrieren

Eine bestehende, historisch gewachsene Rechtevergabe lässt sich nicht in einem einzigen Schritt gefahrlos auf Rollen umstellen, ohne versehentlich Rechte zu verlieren oder zu doppeln. Der sicherere Weg beginnt damit, für jeden bestehenden Nutzer die aktuellen Rechte über SHOW GRANTS zu dokumentieren, daraus gemeinsame Muster zu identifizieren und für jedes wiederkehrende Muster eine eigene Rolle anzulegen, deren Rechte exakt dem dokumentierten Bestand entsprechen.

Erst wenn diese neuen Rollen den zugehörigen Nutzern zusätzlich zugewiesen wurden und ein Vergleich über information_schema.applicable_roles bestätigt, dass die effektiven Rechte unverändert bleiben, werden die ursprünglichen Einzel-GRANTs schrittweise entfernt. Dieser zweistufige Ansatz mit paralleler Übergangsphase minimiert das Risiko, während der Migration versehentlich Zugriffsrechte zu verlieren, die für den laufenden Betrieb tatsächlich benötigt werden.

10. Zusammenfassung

11. FAQ: MySQL-Rollen: Das Wichtigste auf einen Blick