sql >> Databáze >  >> RDS >> MariaDB

Tipy a triky pro implementaci řízení přístupu k databázi na základě rolí pro MariaDB

V systému správy databází (DBMS) je řízení přístupu založené na rolích (RBAC) omezením databázových zdrojů na základě sady předdefinovaných skupin oprávnění a stalo se jedním z hlavních metody pro pokročilé řízení přístupu. Databázové role lze vytvářet a rušit, stejně jako jim lze udělovat a odebírat oprávnění. Role lze udělovat a odebírat z jednotlivých uživatelských účtů. Příslušné aktivní role pro účet lze vybrat z těch, které byly danému účtu přiděleny a které byly změněny během relací pro daný účet.

V tomto příspěvku na blogu se podíváme na několik tipů a triků, jak používat databázovou roli ke správě uživatelských oprávnění a jako pokročilého mechanismu řízení přístupu k naší databázi. Pokud se chcete dozvědět o základech rolí v MySQL a MariaDB, podívejte se na tento blogový příspěvek Správa uživatelů databáze:Správa rolí pro MariaDB.

Role MySQL vs MariaDB

MySQL a MariaDB používají dva různé mechanismy rolí. V MySQL 8.0 a novějších je role podobná jinému uživateli s uživatelským jménem a hostitelem ('role1'@'localhost'). Ano, to je název role, který je prakticky podobný standardní definici uživatel-hostitel. MySQL ukládá definici role stejně jako ukládání uživatelských oprávnění do systémové tabulky mysql.user.

MariaDB zavedla role a přístupová práva ve verzi MariaDB 10.0.5 (listopad 2013), tedy dobrých 8 let předtím, než MySQL začlenilo tuto funkci do MySQL8.0. Sleduje podobnou správu rolí v databázovém systému kompatibilním s SQL, je robustnější a mnohem srozumitelnější. MariaDB ukládá definici do systémové tabulky mysql.user označenou nově přidaným sloupcem s názvem is_role. MySQL ukládá roli odlišně pomocí kombinace uživatel-hostitel podobnou standardní správě uživatelů MySQL.

Migrace rolí mezi těmito dvěma DBMS je nyní vzájemně nekompatibilní.

Administrativní a záložní role MariaDB

MySQL má dynamická oprávnění, která poskytují sadu oprávnění pro běžné úlohy správy. Pro MariaDB můžeme nastavit podobné věci pomocí rolí, zejména pro zálohování a obnovení oprávnění. Pro MariaDB Backup, protože se jedná o fyzickou zálohu a vyžaduje jinou sadu oprávnění, můžeme vytvořit specifickou roli, která bude přiřazena jinému uživateli databáze.

Nejprve vytvořte roli a přiřaďte jí správná oprávnění:

MariaDB> CREATE ROLE mariadb_backup;
MariaDB> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO mariadb_backup;

Poté můžeme vytvořit záložního uživatele, udělit mu roli mariadb_backup a přiřadit výchozí roli:

MariaDB> CREATE USER [email protected] IDENTIFIED BY 'passw0rdMMM';
MariaDB> GRANT mariadb_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mariadb_backup FOR [email protected];

Pro mysqldump nebo mariadb-dump lze minimální oprávnění k vytvoření zálohy nastavit následovně:

MariaDB> CREATE ROLE mysqldump_backup;
MariaDB> GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO mysqldump_backup;

Poté můžeme vytvořit záložního uživatele, udělit mu roli mysqldump_backup a přiřadit výchozí roli:

MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_backup FOR [email protected];

Pro obnovení běžně vyžaduje jinou sadu oprávnění, což je trochu:

MariaDB> CREATE ROLE mysqldump_restore;
MariaDB> GRANT SUPER, ALTER, INSERT, CREATE, DROP, LOCK TABLES, REFERENCES, SELECT, CREATE ROUTINE, TRIGGER ON *.* TO mysqldump_restore;

Poté můžeme vytvořit uživatele pro obnovení, udělit mu roli mysqldump_restore a přiřadit výchozí roli:

MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_restore TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_restore FOR [email protected];

Pomocí tohoto triku můžeme zjednodušit proces vytváření administrativního uživatele přiřazením role s předdefinovanými oprávněními. Naše prohlášení GRANT tak může být zkráceno a snadno pochopitelné.

Vytvoření role Over Role v MariaDB 

Můžeme vytvořit další roli nad existující rolí podobnou členství ve vnořené skupině s jemnější kontrolou nad oprávněními. Například bychom mohli vytvořit následující 4 role:

MariaDB> CREATE ROLE app_developer, app_reader, app_writer, app_structure;

Udělte oprávnění ke správě struktury schématu roli app_structure:

MariaDB> GRANT CREATE, ALTER, DROP, CREATE VIEW, CREATE ROUTINE, INDEX, TRIGGER, REFERENCES ON app.* to app_structure;

Udělte oprávnění pro jazyk DML (Data Manipulation Language) roli app_writer:

MariaDB> GRANT INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES app.* to app_writer;

Udělte oprávnění pro Data Query Language (DQL) roli app_reader:

MariaDB> GRANT SELECT, LOCK TABLES, SHOW VIEW app.* to app_reader;

A nakonec můžeme všechny výše uvedené role přiřadit aplikaci app_developer, která by měla mít plnou kontrolu nad schématem:

MariaDB> GRANT app_structure TO app_developer;
MariaDB> GRANT app_reader TO app_developer;
MariaDB> GRANT app_writer TO app_developer;

Role jsou připraveny a nyní můžeme vytvořit databázového uživatele s rolí 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.%';

Protože Michael nyní patří do rolí app_deleloper a app_reader, můžeme mu také přiřadit nejnižší oprávnění jako výchozí roli, abychom ho chránili před nechtěnou lidskou chybou:

MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';

Dobrá věc na použití role je, že můžete skrýt skutečná oprávnění před uživatelem databáze. Zvažte následujícího uživatele databáze, který se právě přihlásil:

MariaDB> SELECT user();
+----------------------+
| user()               |
+----------------------+
| [email protected] |
+----------------------+

Při pokusu o získání oprávnění pomocí SHOW GRANTS by Michael viděl:

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' |
+----------------------------------------------------------------------------------------------------------------+

A když se Michael pokouší vyhledat oprávnění vývojáře app_developer, zobrazí se mu tato chyba:

MariaDB> SHOW GRANTS FOR FOR app_developer;
ERROR 1044 (42000): Access denied for user 'michael'@'localhost' to database 'mysql'

Tento trik umožňuje správcům databází zobrazovat pouze logické seskupení, kam uživatel patří, a nic víc. Z tohoto hlediska můžeme snížit vektor útoku, protože uživatelé nebudou mít ponětí o skutečných oprávněních, která jim byla přidělena.

Vynucení výchozí role v MariaDB

Vynucením výchozí role může být uživatel databáze chráněn na první vrstvě proti náhodným lidským chybám. Vezměme si například uživatele Michaela, kterému byla přidělena role app_developer, kde role app_developer je nadmnožinou rolí app_strucutre, app_writer a app_reader, jak je znázorněno níže:

Protože Michael patří do role app_deleloper, můžeme nastavit i nejnižší oprávnění jako výchozí role, která ho ochrání před náhodnou úpravou dat:

MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';

Pokud jde o uživatele "michael", po přihlášení by viděl následující:

MariaDB> SELECT user(),current_role();
+-------------------+----------------+
| user()            | current_role() |
+-------------------+----------------+
| [email protected] | app_reader     |
+-------------------+----------------+

Jeho výchozí role je app_reader, což je oprávnění pouze pro čtení pro databázi s názvem „app“. Aktuální uživatel má možnost přepínat mezi libovolnými použitelnými rolemi pomocí funkce SET ROLE. Pokud jde o Michaela, může přejít do jiné role pomocí následujícího prohlášení:

MariaDB> SET ROLE app_developer;

V tomto okamžiku by měl být Michael schopen zapisovat do databáze 'app', protože app_developer je nadmnožinou app_writer a app_structure. Chcete-li zkontrolovat dostupné role pro aktuálního uživatele, můžeme se zeptat na tabulku 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        |
+-------------------+---------------+--------------+------------+

Tímto způsobem nastavujeme primární roli pro uživatele a primární role může být nejnižší možné oprávnění pro konkrétního uživatele. Před provedením jakékoli rizikové činnosti na databázovém serveru musí uživatel souhlasit se svou aktivní rolí přepnutím na jinou privilegovanou roli.

Mapování rolí v MariaDB

MariaDB poskytuje tabulku mapování rolí s názvem mysql.roles_mapping. Mapování nám umožňuje snadno pochopit korelaci mezi uživatelem a jeho rolemi a jak je role mapována na jinou roli:

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            |
+-------------+-------------------+------------------+--------------+

Z výše uvedeného výstupu můžeme říci, že Uživatel bez hostitele je v podstatě role nad rolí a k vytvořeným rolím jsou automaticky přiřazováni také administrativní uživatelé (Admin_option =Y). Chcete-li získat seznam vytvořených rolí, můžeme se dotazovat na tabulku uživatelů MySQL:

MariaDB> SELECT user FROM mysql.user WHERE is_role = 'Y';
+------------------+
| User             |
+------------------+
| app_developer    |
| app_writer       |
| app_reader       |
| app_structure    |
| mysqldump_backup |
| mariadb_backup   |
+------------------+

Poslední myšlenky

Použití rolí může zlepšit zabezpečení databáze poskytnutím další vrstvy ochrany proti náhodné úpravě dat uživateli databáze. Kromě toho zjednodušuje správu oprávnění a operace údržby pro organizace, které mají mnoho uživatelů databáze.


  1. Checker Run

  2. SQLite Tutorial:Vše, co potřebujete vědět

  3. Jednoduché uvozovky, dvojité uvozovky a zpětné uvozovky v MySQL

  4. Jak funguje SET ROWCOUNT v SQL Server