В система за управление на база данни (DBMS), контролът на достъп, базиран на роли (RBAC), е ограничение върху ресурсите на базата данни, базиран на набор от предварително дефинирани групи от привилегии и се превърна в един от основните методи за разширен контрол на достъпа. Ролите в базата данни могат да се създават и отпадат, както и да им се предоставят и отнемат привилегии. Роли могат да се предоставят и отменят от индивидуални потребителски акаунти. Приложимите активни роли за акаунт могат да бъдат избрани от предоставените на акаунта и променени по време на сесиите за този акаунт.
В тази публикация в блога ще разгледаме някои съвети и трикове за използване на ролята на базата данни за управление на привилегиите на потребителите и като усъвършенстван механизъм за контрол на достъпа за нашия достъп до базата данни. Ако искате да научите за основите на ролите в MySQL и MariaDB, вижте тази публикация в блога, Управление на потребители на база данни:Управление на роли за MariaDB.
Роли в MySQL срещу MariaDB
MySQL и MariaDB използват два различни механизма за роли. В MySQL 8.0 и по-нови, ролята е подобна на друг потребител, с потребителско име и хост ('role1'@'localhost'). Да, това е името на ролята, което на практика е подобно на стандартната дефиниция потребител-хост. MySQL съхранява дефиницията на ролята точно както съхранява привилегиите на потребителя в системната таблица mysql.user.
MariaDB въведе привилегии за роля и достъп в MariaDB версия 10.0.5 (ноември 2013 г.), добри 8 години преди MySQL да включи тази функция в MySQL8.0. Той следва подобно управление на ролите в SQL-съвместима система за бази данни, по-стабилна и много по-лесна за разбиране. MariaDB съхранява дефиницията в системната таблица mysql.user, маркирана с новодобавена колона, наречена is_role. MySQL съхранява ролята по различен начин, като използва комбинация потребител-хост, подобна на стандартното управление на потребителите на MySQL.
Като казахме това, миграцията на роли между тези две СУБД вече е несъвместима една с друга.
Административни и резервни роли на MariaDB
MySQL има динамични привилегии, които предоставят набор от привилегии за общи административни задачи. За MariaDB можем да зададем подобни неща, използвайки роли, особено за привилегии за архивиране и възстановяване. За MariaDB Backup, тъй като е физическо архивиране и изисква различен набор от привилегии, можем да създадем конкретна роля, която да бъде присвоена на друг потребител на база данни.
Първо, създайте роля и я задайте с правилните привилегии:
MariaDB> CREATE ROLE mariadb_backup;
MariaDB> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO mariadb_backup;След това можем да създадем резервния потребител, да му предоставим ролята mariadb_backup и да зададем ролята по подразбиране:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'passw0rdMMM';
MariaDB> GRANT mariadb_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mariadb_backup FOR [email protected];За mysqldump или mariadb-dump минималните привилегии за създаване на резервно копие могат да бъдат зададени, както следва:
MariaDB> CREATE ROLE mysqldump_backup;
MariaDB> GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO mysqldump_backup;След това можем да създадем резервния потребител, да му предоставим ролята mysqldump_backup и да зададем ролята по подразбиране:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_backup FOR [email protected];За възстановяване обикновено се изисква различен набор от привилегии, който е малко:
MariaDB> CREATE ROLE mysqldump_restore;
MariaDB> GRANT SUPER, ALTER, INSERT, CREATE, DROP, LOCK TABLES, REFERENCES, SELECT, CREATE ROUTINE, TRIGGER ON *.* TO mysqldump_restore;След това можем да създадем потребител за възстановяване, да му предоставим ролята mysqldump_restore и да зададем ролята по подразбиране:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_restore TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_restore FOR [email protected];Използвайки този трик, можем да опростим процеса на създаване на административен потребител, като зададем роля с предварително дефинирани привилегии. По този начин нашето изявление GRANT може да бъде съкратено и лесно за разбиране.
Създаване на роля над роля в MariaDB
Можем да създадем друга роля върху съществуваща роля, подобна на членство в вложена група с по-фин контрол върху привилегиите. Например, можем да създадем следните 4 роли:
MariaDB> CREATE ROLE app_developer, app_reader, app_writer, app_structure;Предоставете привилегиите за управление на структурата на схемата на ролята app_structure:
MariaDB> GRANT CREATE, ALTER, DROP, CREATE VIEW, CREATE ROUTINE, INDEX, TRIGGER, REFERENCES ON app.* to app_structure;Дайте привилегиите за език за манипулиране на данни (DML) на ролята на app_writer:
MariaDB> GRANT INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES app.* to app_writer;Предоставете привилегиите за езика на заявки за данни (DQL) на ролята app_reader:
MariaDB> GRANT SELECT, LOCK TABLES, SHOW VIEW app.* to app_reader;И накрая, можем да присвоим всички горепосочени роли на app_developer, който трябва да има пълен контрол върху схемата:
MariaDB> GRANT app_structure TO app_developer;
MariaDB> GRANT app_reader TO app_developer;
MariaDB> GRANT app_writer TO app_developer;Ролите са готови и сега можем да създадем потребител на база данни с ролята на app_developer:
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.%';Тъй като Майкъл вече принадлежи към ролите app_deleloper и app_reader, можем също да зададем най-ниските привилегии като роля по подразбиране, за да го защитим от нежелана човешка грешка:
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';Хубавото при използването на роля е, че можете да скриете действителните привилегии от потребителя на базата данни. Помислете за следния потребител на база данни, който току-що е влязъл:
MariaDB> SELECT user();
+----------------------+
| user() |
+----------------------+
| [email protected] |
+----------------------+Когато се опитва да извлече привилегиите с помощта на SHOW GRANTS, Майкъл ще види:
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' |
+----------------------------------------------------------------------------------------------------------------+И когато Майкъл се опитва да потърси привилегиите на app_developer, той ще види тази грешка:
MariaDB> SHOW GRANTS FOR FOR app_developer;
ERROR 1044 (42000): Access denied for user 'michael'@'localhost' to database 'mysql'Този трик позволява на DBA да показват само логическото групиране, където принадлежи потребителят, и нищо повече. От този аспект можем да намалим вектора на атака, тъй като потребителите няма да имат представа за действителните привилегии, които им се предоставят.
Прилагане на ролята по подразбиране в MariaDB
Чрез прилагане на роля по подразбиране потребителят на база данни може да бъде защитен на първия слой срещу случайни човешки грешки. Например, помислете за потребителя Michael, на когото е предоставена ролята app_developer, където ролята app_developer е супернабор от роли app_strucutre, app_writer и app_reader, както е илюстрирано по-долу:
Тъй като Майкъл принадлежи към ролята на app_deleloper, можем да зададем и най-ниското привилегия като роля по подразбиране, за да го защити срещу случайна промяна на данните:
MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';Що се отнася до потребителя "michael", той ще види следното, след като влезе:
MariaDB> SELECT user(),current_role();
+-------------------+----------------+
| user() | current_role() |
+-------------------+----------------+
| [email protected] | app_reader |
+-------------------+----------------+Неговата роля по подразбиране е app_reader, което е привилегия само за четене за база данни, наречена "app". Текущият потребител има възможност да превключва между всички приложими роли с помощта на функцията SET ROLE. Що се отнася до Майкъл, той може да премине към друга роля, като използва следното изявление:
MariaDB> SET ROLE app_developer;В този момент Майкъл би трябвало да може да пише в базата данни „app“, тъй като app_developer е супернабор от app_writer и app_structure. За да проверим наличните роли за текущия потребител, можем да потърсим таблицата information_schema.applicable_roles:
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 |
+-------------------+---------------+--------------+------------+По този начин ние задаваме основна роля за потребителя, като основната роля може да бъде възможно най-ниската привилегия за конкретен потребител. Потребителят трябва да даде съгласието си за активната си роля, като премине към друга привилегирована роля, преди да извърши рискова дейност към сървъра на базата данни.
Определяне на роли в MariaDB
MariaDB предоставя таблица за съпоставяне на роли, наречена mysql.roles_mapping. Съпоставянето ни позволява лесно да разберем връзката между потребител и неговите роли и как една роля е съпоставена с друга роля:
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 |
+-------------+-------------------+------------------+--------------+
От горния изход можем да разберем, че потребител без хост е основно роля над роля и администраторските потребители (Admin_option =Y) също се присвояват на създадените роли автоматично. За да получим списъка със създадени роли, можем да потърсим потребителската таблица на MySQL:
MariaDB> SELECT user FROM mysql.user WHERE is_role = 'Y';
+------------------+
| User |
+------------------+
| app_developer |
| app_writer |
| app_reader |
| app_structure |
| mysqldump_backup |
| mariadb_backup |
+------------------+Последни мисли
Използването на роли може да подобри сигурността на базата данни, като осигури допълнителен слой на защита срещу случайна промяна на данните от потребителите на базата данни. Освен това, това опростява операциите по управление на привилегиите и поддръжка за организации, които имат много потребители на база данни.
