To zawsze przyprawia o ból głowy... trzeba dodać nową rolę użytkownika lub zmienić niektóre uprawnienia i trzeba to przypisać jeden... po... jednym. Jest to normalny obowiązek, zwłaszcza w dużych organizacjach lub w firmie, w której masz złożoną strukturę uprawnień, a nawet jeśli musisz zarządzać dużą liczbą użytkowników bazy danych.
Załóżmy na przykład, że musisz dodać uprawnienie UPDATE do określonej bazy danych dla całego zespołu ds. kontroli jakości, jeśli jest to pięcioosobowy zespół, nie ma problemu, ale jeśli mają 50... lub 100... ciężko. Oczywiście zawsze możesz napisać do niego skrypt, ale w ten sposób zawsze istnieje ryzyko.
W tym blogu zobaczymy, jak możemy rozwiązać ten problem z zarządzaniem użytkownikami bazy danych za pomocą ról i konkretnych wskazówek, jak używać ich w MariaDB.
Co to jest rola?
W świecie baz danych rola to grupa uprawnień, które można przypisać jednemu lub większej liczbie użytkowników, a użytkownik może mieć przypisaną jedną lub więcej ról. Dla porównania, to jest jak grupa w systemie operacyjnym Linux.
Jeśli widzimy poprzedni przykład dotyczący uprawnienia UPDATE w zespole QA, jeśli mamy utworzoną rolę QA i wszyscy członkowie QA mają tę rolę przypisaną, liczba członków nie ma znaczenia, wystarczy zmienić uprawnienie w tej roli kontroli jakości i będzie ona rozpowszechniana wśród wszystkich użytkowników kontroli jakości.
Role w MariaDB
Aby zarządzać rolami w MariaDB, należy utworzyć rolę za pomocą instrukcji CREATE ROLE, przypisać uprawnienia do tej roli za pomocą instrukcji GRANT, a następnie przypisać uprawnienia użytkownikowi, aby móc korzystać z tej roli. Możesz także ustawić domyślną rolę, dzięki czemu użytkownik przyjmie ją podczas łączenia.
Jako użytkownik bazy danych musisz ustawić rolę podczas uzyskiwania dostępu do bazy danych (jeśli nie ma roli domyślnej) i możesz zmienić rolę w razie potrzeby za pomocą instrukcji SET ROLE.
Po stronie aplikacji powinieneś być w stanie ustawić rolę (lub użyć domyślnej) przed zapytaniem, aby to zadziałało, więc w starych aplikacjach implementacja może być skomplikowana.
Zobaczmy trochę specyfikacji ról w MariaDB.
- Tylko jedna rola może być aktywna w tym samym czasie dla bieżącego użytkownika.
- Od wersji MariaDB 10.1 mamy rolę domyślną. Ta rola jest automatycznie włączana, gdy użytkownik się połączy.
- Role są przechowywane w pamięci.
Jak sprawdzić role
W MariaDB można to sprawdzić na wiele sposobów:
- POKAŻ DOTACJE [ DLA (użytkownik | rola)]:Lista dotacji dla bieżącego użytkownika lub dla konkretnego użytkownika.
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) - SELECT user FROM mysql.user WHERE is_role='Y':Lista ról utworzonych w bazie danych.
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:To lista dostępnych ról dla bieżącego użytkownika.
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:Lista aktualnie aktywnych ról.
MariaDB [testing]> SELECT * FROM information_schema.enabled_roles; +-----------+ | ROLE_NAME | +-----------+ | qateam | +-----------+ 1 row in set (0.000 sec) - SELECT * FROM mysql.roles_mapping:Lista relacji między rolami i uprawnieniami użytkowników.
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)
Jak zarządzać rolami w MariaDB
Zobaczmy przykład, jak nim zarządzać w MariaDB. W tym przypadku użyjemy wersji MariaDB 10.3 działającej na CentOS 7.
Najpierw utwórzmy nowego użytkownika bazy danych:
MariaDB [testing]> CREATE USER [email protected]'%' IDENTIFIED BY 'PASSWORD';Jeśli sprawdzimy dotacje dla tego nowego użytkownika, zobaczymy coś takiego:
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)Spróbujmy teraz zalogować się za pomocą tego użytkownika i połączyć się z testową bazą danych:
$ 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'Jak widzieliśmy, nie możemy połączyć się z testową bazą danych z tym użytkownikiem, więc teraz utworzymy rolę „qateam” z uprawnieniami i przypiszemy tę rolę temu nowemu użytkownikowi.
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)Jeśli spróbujemy użyć tej roli bez GRANT, zobaczymy następujący błąd:
MariaDB [(none)]> SET ROLE qateam;
ERROR 1959 (OP000): Invalid role specification `qateam`Tak więc teraz uruchomimy GRANT, aby umożliwić użytkownikowi korzystanie z niego:
MariaDB [(none)]> GRANT qateam TO [email protected]'%';
Query OK, 0 rows affected (0.000 sec)Ustaw rolę dla bieżącego użytkownika:
MariaDB [(none)]> SET ROLE qateam;
Query OK, 0 rows affected (0.000 sec)I spróbuj uzyskać dostęp do bazy danych:
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]>Możemy sprawdzić dotacje dla bieżącego użytkownika:
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)I aktualna rola:
MariaDB [testing]> SELECT CURRENT_ROLE;
+--------------+
| CURRENT_ROLE |
+--------------+
| qateam |
+--------------+
1 row in set (0.000 sec)Tutaj widzimy przydział dla roli qateam i to wszystko, nie mamy uprawnień przypisanych bezpośrednio do użytkownika, mamy uprawnienia do roli, a użytkownik pobiera uprawnienia stamtąd.
Wniosek
Zarządzanie rolami może ułatwić nam życie w dużych firmach lub bazach danych z dużą liczbą użytkowników, którzy mają do nich dostęp. Jeśli chcemy z niego korzystać z naszej aplikacji, musimy wziąć pod uwagę, że aplikacja musi również móc nią zarządzać.
