X

Schön, dass Sie sich für unseren
Blog interessieren!

Bleiben Sie immer auf dem Laufenden
und abonnieren Sie den Blog-Newsletter

3 Minuten Lesezeit (506 Worte)

Darf es ein bisschen weniger sein? - MySQL „partial revokes“

Berechtigungen auf Datenbanken zu vergeben kann ein mühsamer Job sein. Gerade das Vergeben von restriktiven Rechten à la „Du darfst alle Tabellen lesen, bis auf die Informationen in der Datenbank XYZ" war ein aufwändiges Unterfangen. Für eine solche Aufgabe mussten die SELECT-Rechte für alle Datenbanken definiert werden, die der User lesen können sollte. Die unerwünschte Datenbank wurde einfach mit keinen Rechten bedacht. Natürlich kann man sich solche GRANT-Anweisungen mit SQL dynamisch erstellen, um den Aufwand in Grenzen zu halten. Mit der Version 8.0.16 gibt es hier eine kleine Erleichterung.

Rückrufaktion 

Ab sofort können Berechtigungen auf Schema-Ebene partiell „zurückgerufen" (revoked) werden. Dazu muss der entsprechende Parameter „partial_revokes" aktiviert werden. 

mysql> set persist partial_revokes=on;
Query OK, 0 rows affected (0.00 sec)
 

Auf unserem Test-Datenbanksystem sind mehrere Schemata (Datenbanken) vorhanden. Unter anderem die bekannte Demo-Datenbank „sakila". 

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sakila             |
| sys                |
+--------------------+
5 rows in set (0.01 sec)
 

Wir legen uns nun einen Account (User 'app_ro') an, der auf allen Datenbanken (auch auf zukünftigen) Leseberechtigungen haben soll. 

mysql> create user 'app_ro'@'%' identified by 'ordix';
Query OK, 0 rows affected (0.01 sec)
mysql> grant select on *.* to 'app_ro'@'%';
Query OK, 0 rows affected (0.01 sec)
 

Damit hat dieser Nutzer nun lesenden Zugriff auf alle (auch zukünftigen) Datenbanken: 

root@myshell2:/# mysql -uapp_ro -pordix --execute="show databases"
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sakila             |
| sys                |
+--------------------+
 

Nun entziehen wir diesem User jedoch den Zugang zu der Datenbank „sakila". 

mysql> revoke select on sakila.* from 'app_ro'@'%';
Query OK, 0 rows affected (0.01 sec)

root@myshell2:/# mysql -uapp_ro -pordix --execute="show databases"
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
 

Die Datenbank verschwindet aus dem „Blickfeld" dieses Datenbankusers ‚app_ro'. 

Alles unter Kontrolle? 

Wie werden diese Berechtigungsstrukturen verwaltet? Allgemein bekannt dürfte sein, dass die Rechte in mehreren Systemtabellen, innerhalb der MySql-Datenbank gespeichert werden. Dort befinden sich bislang nur die vergebenen „GRANTs", also die positiv formulierten Privilegien.

Mit der Version 8.0.16 werden nun in der „user"-Tabelle, innerhalb der MySql-Datenbank, auch Restriktionen verwaltet. Dazu wird die Spalte „user_attributes" (Datentype JSON) verwendet.

mysql> select user, host, user_attributes from user where user =  'app_ro';
+--------+------+----------------------------------------------------------------------+
| user   | host | user_attributes                                                      |
+--------+------+----------------------------------------------------------------------+
| app_ro | %    | {"Restrictions": [{"Database": "sakila", "Privileges": ["SELECT"]}]} |
+--------+------+----------------------------------------------------------------------+
1 row in set (0.00 sec)
 

Natürlich kann man beim SELECT die Ausgabe von JSON-Daten auch etwas lesbarer formatieren.

Fazit: Brauchen wir mehr Restriktionen? 

Die klare Antwort lautet „Ja!". Die neue Funktionalität ist auf jeden Fall hilfreich. Leider können Restriktionen aktuell nur auf Schema-Ebene gesetzt werden. Interessanter für den Entwickler und / oder den DBA wären Einschränkungen auf Objekt-Ebene (z.B. Tabellen). Aber was nicht ist, kann ja noch werden.

Principal Consultant bei ORDIX.

Seminarempfehlung

 

Kommentare

Derzeit gibt es keine Kommentare. Schreibe den ersten Kommentar!
Gäste
Mittwoch, 29. Juni 2022

Sicherheitscode (Captcha)

×
Informiert bleiben!

Bei Updates im Blog, informieren wir per E-Mail.

Weitere Artikel in der Kategorie