In einem Datenbankverwaltungssystem (DBMS) ist die rollenbasierte Zugriffskontrolle (RBAC) eine Einschränkung von Datenbankressourcen, die auf einer Reihe vordefinierter Gruppen von Berechtigungen basiert, und ist zu einer der wichtigsten geworden Methoden für erweiterte Zugriffskontrolle. Datenbankrollen können erstellt und gelöscht werden, ihnen können Berechtigungen gewährt und entzogen werden. Rollen können einzelnen Benutzerkonten zugewiesen und entzogen werden. Die anwendbaren aktiven Rollen für ein Konto können aus denen ausgewählt werden, die dem Konto zugewiesen wurden, und während der Sitzungen für dieses Konto geändert werden.
In diesem Blogbeitrag behandeln wir einige Tipps und Tricks zur Verwendung der Datenbankrolle zur Verwaltung von Benutzerrechten und als erweiterten Zugriffskontrollmechanismus für unseren Datenbankzugriff. Wenn Sie mehr über die Grundlagen von Rollen in MySQL und MariaDB erfahren möchten, lesen Sie diesen Blog-Beitrag Database User Management:Managing Roles for MariaDB.
MySQL vs. MariaDB-Rollen
MySQL und MariaDB verwenden zwei unterschiedliche Rollenmechanismen. In MySQL 8.0 und höher ähnelt die Rolle einem anderen Benutzer mit Benutzername und Host ('role1'@'localhost'). Ja, das ist der Rollenname, der praktisch der Standard-Benutzer-Host-Definition ähnelt. MySQL speichert die Rollendefinition genauso wie das Speichern von Benutzerrechten in der Systemtabelle mysql.user.
MariaDB hatte Rollen- und Zugriffsrechte in MariaDB Version 10.0.5 (Nov 2013) eingeführt, gut 8 Jahre bevor MySQL dieses Feature in MySQL8.0 aufgenommen hat. Es folgt einem ähnlichen Rollenmanagement in einem SQL-kompatiblen Datenbanksystem, robuster und viel einfacher zu verstehen. MariaDB speichert die Definition in der Systemtabelle mysql.user, die mit einer neu hinzugefügten Spalte namens is_role gekennzeichnet ist. MySQL speichert die Rolle anders und verwendet eine Benutzer-Host-Kombination ähnlich der standardmäßigen MySQL-Benutzerverwaltung.
Trotzdem ist die Rollenmigration zwischen diesen beiden DBMSs jetzt nicht mehr miteinander kompatibel.
MariaDB-Verwaltungs- und Backup-Rollen
MySQL verfügt über dynamische Berechtigungen, die eine Reihe von Berechtigungen für allgemeine Verwaltungsaufgaben bereitstellen. Für MariaDB können wir ähnliche Dinge mithilfe von Rollen festlegen, insbesondere für Sicherungs- und Wiederherstellungsberechtigungen. Da es sich bei MariaDB Backup um ein physisches Backup handelt und andere Berechtigungen erforderlich sind, können wir eine bestimmte Rolle erstellen, die einem anderen Datenbankbenutzer zugewiesen wird.
Erstellen Sie zunächst eine Rolle und weisen Sie ihr die richtigen Berechtigungen zu:
MariaDB> CREATE ROLE mariadb_backup;
MariaDB> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO mariadb_backup;Wir können dann den Backup-Benutzer erstellen, ihm die Rolle mariadb_backup zuweisen und die Standardrolle zuweisen:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'passw0rdMMM';
MariaDB> GRANT mariadb_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mariadb_backup FOR [email protected];Für mysqldump oder mariadb-dump können die minimalen Berechtigungen zum Erstellen eines Backups wie folgt festgelegt werden:
MariaDB> CREATE ROLE mysqldump_backup;
MariaDB> GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO mysqldump_backup;Wir können dann den Backup-Benutzer erstellen, ihm die Rolle mysqldump_backup zuweisen und die Standardrolle zuweisen:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_backup FOR [email protected];Für die Wiederherstellung sind normalerweise andere Berechtigungen erforderlich, was ein bisschen ist:
MariaDB> CREATE ROLE mysqldump_restore;
MariaDB> GRANT SUPER, ALTER, INSERT, CREATE, DROP, LOCK TABLES, REFERENCES, SELECT, CREATE ROUTINE, TRIGGER ON *.* TO mysqldump_restore;Wir können dann den Benutzer für die Wiederherstellung erstellen, ihm die Rolle mysqldump_restore zuweisen und die Standardrolle zuweisen:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_restore TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_restore FOR [email protected];Mit diesem Trick können wir den administrativen Benutzererstellungsprozess vereinfachen, indem wir eine Rolle mit vordefinierten Berechtigungen zuweisen. Somit kann unsere GRANT-Anweisung verkürzt und leicht verständlich werden.
Rolle über Rolle in MariaDB erstellen
Wir können eine weitere Rolle über einer bestehenden Rolle erstellen, ähnlich einer verschachtelten Gruppenmitgliedschaft mit feinerer Kontrolle über Berechtigungen. Beispielsweise könnten wir die folgenden 4 Rollen erstellen:
MariaDB> CREATE ROLE app_developer, app_reader, app_writer, app_structure;Erteilen Sie der Rolle app_structure die Berechtigungen zum Verwalten der Schemastruktur:
MariaDB> GRANT CREATE, ALTER, DROP, CREATE VIEW, CREATE ROUTINE, INDEX, TRIGGER, REFERENCES ON app.* to app_structure;Gewähren Sie der Rolle app_writer die Berechtigungen für Data Manipulation Language (DML):
MariaDB> GRANT INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES app.* to app_writer;Gewähren Sie der Rolle app_reader die Berechtigungen für Data Query Language (DQL):
MariaDB> GRANT SELECT, LOCK TABLES, SHOW VIEW app.* to app_reader;Und schließlich können wir alle oben genannten Rollen app_developer zuweisen, der die volle Kontrolle über das Schema haben sollte:
MariaDB> GRANT app_structure TO app_developer;
MariaDB> GRANT app_reader TO app_developer;
MariaDB> GRANT app_writer TO app_developer;Die Rollen sind fertig und jetzt können wir einen Datenbankbenutzer mit der Rolle app_developer erstellen:
MariaDB> CREATE USER 'michael'@'192.168.0.%' IDENTIFIED BY 'passw0rdMMMM';
MariaDB> GRANT app_developer TO 'michael'@'192.168.0.%';
MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';Da Michael nun zu den Rollen app_deleloper und app_reader gehört, können wir auch die niedrigsten Privilegien als Standardrolle zuweisen, um ihn vor unerwünschten menschlichen Fehlern zu schützen:
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';Das Gute an der Verwendung einer Rolle ist, dass Sie die eigentlichen Berechtigungen vor dem Datenbankbenutzer verbergen können. Betrachten Sie den folgenden gerade angemeldeten Datenbankbenutzer:
MariaDB> SELECT user();
+----------------------+
| user() |
+----------------------+
| [email protected] |
+----------------------+Bei dem Versuch, die Privilegien mit SHOW GRANTS abzurufen, sah Michael:
MariaDB> SHOW GRANTS FOR 'michael'@'192.168.0.%';
+----------------------------------------------------------------------------------------------------------------+
| Grants for [email protected] |
+----------------------------------------------------------------------------------------------------------------+
| GRANT `app_developer` TO `michael`@`localhost` |
| GRANT USAGE ON *.* TO `michael`@`localhost` IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' |
+----------------------------------------------------------------------------------------------------------------+Und wenn Michael versucht, nach den Privilegien von app_developer zu suchen, würde er diesen Fehler sehen:
MariaDB> SHOW GRANTS FOR FOR app_developer;
ERROR 1044 (42000): Access denied for user 'michael'@'localhost' to database 'mysql'Dieser Trick ermöglicht es den DBAs, nur die logische Gruppierung anzuzeigen, zu der der Benutzer gehört, und nicht mehr. Wir können den Angriffsvektor unter diesem Aspekt reduzieren, da die Benutzer keine Ahnung von den ihnen tatsächlich zugewiesenen Privilegien haben.
Standardrolle in MariaDB erzwingen
Durch das Erzwingen einer Standardrolle kann ein Datenbankbenutzer auf der ersten Ebene vor versehentlichen menschlichen Fehlern geschützt werden. Betrachten Sie beispielsweise den Benutzer Michael, dem die Rolle „app_developer“ zugewiesen wurde, wobei die Rolle „app_developer“ eine Obermenge der Rollen „app_strucutre“, „app_writer“ und „app_reader“ ist, wie unten dargestellt:
Da Michael zur Rolle app_deleloper gehört, können wir auch das niedrigste Privileg setzen als Standardrolle, um ihn vor versehentlicher Datenänderung zu schützen:
MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';Was den Benutzer "michael" betrifft, würde er nach dem Einloggen Folgendes sehen:
MariaDB> SELECT user(),current_role();
+-------------------+----------------+
| user() | current_role() |
+-------------------+----------------+
| [email protected] | app_reader |
+-------------------+----------------+Seine Standardrolle ist app_reader, was ein Read_only-Privileg für eine Datenbank namens "app" ist. Der aktuelle Benutzer hat die Möglichkeit, mit der Funktion SET ROLE zwischen allen anwendbaren Rollen zu wechseln. Michael kann mit der folgenden Anweisung in eine andere Rolle wechseln:
MariaDB> SET ROLE app_developer;An diesem Punkt sollte Michael in der Lage sein, in die Datenbank „app“ zu schreiben, da app_developer eine Obermenge von app_writer und app_structure ist. Um die verfügbaren Rollen für den aktuellen Benutzer zu überprüfen, können wir die Tabelle information_schema.applicable_roles abfragen:
MariaDB> SELECT * FROM information_schema.applicable_roles;
+-------------------+---------------+--------------+------------+
| GRANTEE | ROLE_NAME | IS_GRANTABLE | IS_DEFAULT |
+-------------------+---------------+--------------+------------+
| [email protected] | app_developer | NO | NO |
| app_developer | app_writer | NO | NULL |
| app_developer | app_reader | NO | NULL |
| app_developer | app_structure | NO | NULL |
| [email protected] | app_reader | NO | YES |
+-------------------+---------------+--------------+------------+Auf diese Weise legen wir gewissermaßen eine primäre Rolle für den Benutzer fest, und die primäre Rolle kann die niedrigstmögliche Berechtigung für einen bestimmten Benutzer sein. Der Benutzer muss seiner aktiven Rolle zustimmen, indem er zu einer anderen privilegierten Rolle wechselt, bevor er riskante Aktivitäten auf dem Datenbankserver ausführt.
Rollenzuordnung in MariaDB
MariaDB stellt eine Rollenzuordnungstabelle namens mysql.roles_mapping bereit. Die Zuordnung ermöglicht es uns, die Korrelation zwischen einem Benutzer und seinen Rollen leicht zu verstehen und wie eine Rolle einer anderen Rolle zugeordnet wird:
MariaDB> SELECT * FROM mysql.roles_mapping;
+-------------+-------------------+------------------+--------------+
| Host | User | Role | Admin_option |
+-------------+-------------------+------------------+--------------+
| localhost | root | app_developer | Y |
| localhost | root | app_writer | Y |
| localhost | root | app_reader | Y |
| localhost | root | app_structure | Y |
| | app_developer | app_structure | N |
| | app_developer | app_reader | N |
| | app_developer | app_writer | N |
| 192.168.0.% | michael | app_developer | N |
| localhost | michael | app_developer | N |
| localhost | root | mysqldump_backup | Y |
| localhost | dump_user1 | mysqldump_backup | N |
| localhost | root | mariadb_backup | Y |
| localhost | mariabackup_user1 | mariadb_backup | N |
+-------------+-------------------+------------------+--------------+
Aus der obigen Ausgabe können wir erkennen, dass ein Benutzer ohne Host im Grunde eine Rolle über einer Rolle ist und administrative Benutzer (Admin_option =Y) auch automatisch den erstellten Rollen zugewiesen werden. Um die Liste der erstellten Rollen zu erhalten, können wir die MySQL-Benutzertabelle abfragen:
MariaDB> SELECT user FROM mysql.user WHERE is_role = 'Y';
+------------------+
| User |
+------------------+
| app_developer |
| app_writer |
| app_reader |
| app_structure |
| mysqldump_backup |
| mariadb_backup |
+------------------+Abschließende Gedanken
Die Verwendung von Rollen kann die Datenbanksicherheit verbessern, indem eine zusätzliche Schutzebene gegen versehentliche Datenänderungen durch die Datenbankbenutzer bereitgestellt wird. Darüber hinaus vereinfacht es die Berechtigungsverwaltung und Wartungsvorgänge für Organisationen mit vielen Datenbankbenutzern.
