Винаги е главоболие... трябва да добавите нова потребителска роля или да промените някои привилегии и трябва да й присвоите едно... по... едно. Това е редовно задължение, особено в големи организации или в компания, в която имате сложна структура на привилегии, или дори ако трябва да управлявате голям брой потребители на база данни.
Например, да кажем, че трябва да добавите привилегията UPDATE към конкретна база данни за целия QA екип, ако те са екип от пет, няма проблем, но ако са 50... или 100... това може стане трудно. Разбира се, винаги можете да напишете скрипт за него, но по този начин винаги има риск.
В този блог ще видим как можем да решим този проблем с управлението на потребителите на база данни, като използваме роли и с конкретни съвети как да ги използваме с MariaDB.
Какво е роля?
В света на базата данни ролята е група от привилегии, които могат да бъдат присвоени на един или повече потребители, а потребителят може да има една или повече роли, присвоени му. За да направим сравнение, това е като група в Linux OS.
Ако видим предишния пример за привилегията UPDATE в QA екипа, ако имаме създадена QA роля и всички членове на QA имат назначена роля, няма значение броя на членовете, трябва само да промените привилегията на тази QA роля и тя ще бъде разпространена за всички потребители на QA.
Роли в MariaDB
За да управлявате роли в MariaDB, трябва да създадете ролята с оператора CREATE ROLE, да присвоите привилегията на тази роля с оператор GRANT и след това да присвоите привилегията на потребителя, за да може да използва тази роля. Можете също да зададете роля по подразбиране, така че потребителят да я приеме при свързване.
Като потребител на база данни трябва да зададете ролята, когато осъществявате достъп до базата данни (ако няма роля по подразбиране) и можете да промените ролята, ако е необходимо, с оператор SET ROLE.
От страна на приложението трябва да можете да зададете ролята (или да използвате по подразбиране), преди да направите заявка, за да работи това, така че в стари приложения може да е сложно за прилагане.
Нека видим някои спецификации за роли в MariaDB.
- Само една роля може да бъде активна едновременно за текущия потребител.
- След MariaDB 10.1 имаме роля по подразбиране. Тази роля се активира автоматично, когато потребителят се свърже.
- Ролите се съхраняват в паметта.
Как да проверите роли
В MariaDB има няколко начина да го проверите:
- ПОКАЗВАНЕ НА грантовете [ ЗА (потребител | роля) ]:Избройте безвъзмездните средства за текущия потребител или за конкретен.
MariaDB [testing]> SHOW GRANTS for [email protected]'%'; +----------------------------------------------------------------------------------------------------------+ | Grants for [email protected]% | +----------------------------------------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED BY PASSWORD '*FAAFFE644E901CFAFAEC7562415E5FAEC243B8B2' | +----------------------------------------------------------------------------------------------------------+ 1 row in set (0.000 sec)
- ИЗБЕРЕТЕ потребител ОТ mysql.user WHERE is_role='Y':Избройте ролите, създадени в базата данни.
MariaDB [testing]> SELECT user FROM mysql.user WHERE is_role='Y'; +--------+ | user | +--------+ | qateam | +--------+ 1 row in set (0.000 sec)
- SELECT * FROM information_schema.applicable_roles:Това е списък с налични роли за текущия потребител.
MariaDB [testing]> SELECT * FROM information_schema.applicable_roles; +-------------+-----------+--------------+------------+ | GRANTEE | ROLE_NAME | IS_GRANTABLE | IS_DEFAULT | +-------------+-----------+--------------+------------+ | [email protected]% | qateam | NO | NO | +-------------+-----------+--------------+------------+ 1 row in set (0.000 sec)
- SELECT * FROM information_schema.enabled_roles:Избройте текущите активни роли.
MariaDB [testing]> SELECT * FROM information_schema.enabled_roles; +-----------+ | ROLE_NAME | +-----------+ | qateam | +-----------+ 1 row in set (0.000 sec)
- ИЗБЕРЕТЕ * ОТ mysql.roles_mapping:Избройте връзките между ролите и потребителските разрешения.
MariaDB [testing]> SELECT * FROM mysql.roles_mapping; +-----------+-----------+--------+--------------+ | Host | User | Role | Admin_option | +-----------+-----------+--------+--------------+ | localhost | root | qateam | Y | | % | testuser | qateam | N | +-----------+-----------+--------+--------------+ 2 rows in set (0.000 sec)
Как да управлявате роли в MariaDB
Нека видим пример как да го управлявате в MariaDB. В този случай ще използваме версия на MariaDB 10.3, работеща на CentOS 7.
Първо, нека създадем нов потребител на база данни:
MariaDB [testing]> CREATE USER [email protected]'%' IDENTIFIED BY 'PASSWORD';
Ако проверим разрешенията за този нов потребител, ще видим нещо подобно:
MariaDB [testing]> SHOW GRANTS for [email protected]'%';
+----------------------------------------------------------------------------------------------------------+
| Grants for [email protected]% |
+----------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED BY PASSWORD '*FAAFFE644E901CFAFAEC7562415E5FAEC243B8B2' |
+----------------------------------------------------------------------------------------------------------+
1 row in set (0.000 sec)
Сега нека се опитаме да влезем с този потребител и да се свържем с тестовата база данни:
$ mysql -utestuser -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 54
Server version: 10.3.16-MariaDB-log MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> use testing
ERROR 1044 (42000): Access denied for user 'testuser'@'%' to database 'testing'
Както видяхме, не можем да се свържем с тестовата база данни с този потребител, така че сега ще създадем роля „qateam“ с привилегиите и ще присвоим тази роля на този нов потребител.
MariaDB [testing]> CREATE ROLE qateam;
Query OK, 0 rows affected (0.001 sec)
MariaDB [testing]> GRANT SELECT,INSERT,UPDATE,DELETE ON testing.* TO qateam;
Query OK, 0 rows affected (0.000 sec)
Ако се опитаме да използваме тази роля без GRANT, ще видим следната грешка:
MariaDB [(none)]> SET ROLE qateam;
ERROR 1959 (OP000): Invalid role specification `qateam`
И така, сега ще стартираме GRANT, за да позволим на потребителя да го използва:
MariaDB [(none)]> GRANT qateam TO [email protected]'%';
Query OK, 0 rows affected (0.000 sec)
Задайте ролята на текущия потребител:
MariaDB [(none)]> SET ROLE qateam;
Query OK, 0 rows affected (0.000 sec)
И опитайте да получите достъп до базата данни:
MariaDB [(none)]> use testing;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [testing]>
Можем да проверим безвъзмездните средства за текущия потребител:
MariaDB [(none)]> SHOW GRANTS for [email protected]'%';
+----------------------------------------------------------------------------------------------------------+
| Grants for [email protected]% |
+----------------------------------------------------------------------------------------------------------+
| GRANT qateam TO 'testuser'@'%' |
| GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED BY PASSWORD '*FAAFFE644E901CFAFAEC7562415E5FAEC243B8B2' |
+----------------------------------------------------------------------------------------------------------+
2 rows in set (0.000 sec)
И текущата роля:
MariaDB [testing]> SELECT CURRENT_ROLE;
+--------------+
| CURRENT_ROLE |
+--------------+
| qateam |
+--------------+
1 row in set (0.000 sec)
Тук можем да видим разрешението за ролята на qateam и това е всичко, нямаме привилегията, присвоена директно на потребителя, имаме привилегиите за ролята и потребителят взема привилегиите от там.
Заключение
Управляващите роли могат да улеснят живота ни в големи компании или бази данни с голям брой потребители, които имат достъп до тях. Ако искаме да го използваме от нашето приложение, трябва да вземем предвид, че приложението също трябва да може да го управлява.