In een databasebeheersysteem (DBMS) is op rollen gebaseerd toegangsbeheer (RBAC) een beperking op databasebronnen op basis van een reeks vooraf gedefinieerde groepen privileges en is het een van de belangrijkste methoden voor geavanceerde toegangscontrole. Databaserollen kunnen worden gemaakt en verwijderd, en er kunnen privileges aan worden toegekend en ingetrokken. Rollen kunnen worden toegekend aan en ingetrokken van individuele gebruikersaccounts. De van toepassing zijnde actieve rollen voor een account kunnen worden geselecteerd uit de rollen die aan het account zijn toegekend en kunnen tijdens sessies voor dat account worden gewijzigd.
In deze blogpost zullen we enkele tips en trucs behandelen over het gebruik van de databaserol om gebruikersrechten te beheren en als een geavanceerd toegangscontrolemechanisme voor onze databasetoegang. Als je meer wilt weten over de basisprincipes van rollen in MySQL en MariaDB, bekijk dan deze blogpost, Database User Management:Rollen beheren voor MariaDB.
MySQL versus MariaDB-rollen
MySQL en MariaDB gebruiken twee verschillende rolmechanismen. In MySQL 8.0 en later is de rol vergelijkbaar met die van een andere gebruiker, met gebruikersnaam en host ('role1'@'localhost'). Ja, dat is de rolnaam, die praktisch gelijk is aan de standaard gebruiker-hostdefinitie. MySQL slaat de roldefinitie op net als het opslaan van gebruikersrechten in de systeemtabel mysql.user.
MariaDB had rol- en toegangsprivileges geïntroduceerd in MariaDB versie 10.0.5 (november 2013), ruim 8 jaar voordat MySQL deze functie in MySQL8.0 opnam. Het volgt vergelijkbaar rolbeheer in een SQL-compatibel databasesysteem, robuuster en veel gemakkelijker te begrijpen. MariaDB slaat de definitie op in de systeemtabel mysql.user, gemarkeerd met een nieuw toegevoegde kolom met de naam is_role. MySQL slaat de rol op een andere manier op, met behulp van een gebruiker-host-combinatie die vergelijkbaar is met het standaard MySQL-gebruikersbeheer.
Dat gezegd hebbende, rolmigratie tussen deze twee DBMS'en is nu incompatibel met elkaar.
MariaDB-beheer- en back-uprollen
MySQL heeft dynamische privileges, die een set privileges bieden voor algemene beheertaken. Voor MariaDB kunnen we soortgelijke dingen instellen met behulp van rollen, met name voor back-up- en herstelrechten. Omdat het voor MariaDB Backup een fysieke back-up is en andere rechten vereist, kunnen we een specifieke rol maken om deze aan een andere databasegebruiker toe te wijzen.
Maak eerst een rol en wijs deze toe met de juiste rechten:
MariaDB> CREATE ROLE mariadb_backup;
MariaDB> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO mariadb_backup;We kunnen dan de back-upgebruiker maken, deze de rol mariadb_backup verlenen en de standaardrol toewijzen:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'passw0rdMMM';
MariaDB> GRANT mariadb_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mariadb_backup FOR [email protected];Voor mysqldump of mariadb-dump kunnen de minimale rechten om een back-up te maken als volgt worden ingesteld:
MariaDB> CREATE ROLE mysqldump_backup;
MariaDB> GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO mysqldump_backup;We kunnen dan de back-upgebruiker maken, deze de rol mysqldump_backup toekennen en de standaardrol toewijzen:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_backup FOR [email protected];Voor herstel vereist het gewoonlijk een andere set privileges, wat een beetje is:
MariaDB> CREATE ROLE mysqldump_restore;
MariaDB> GRANT SUPER, ALTER, INSERT, CREATE, DROP, LOCK TABLES, REFERENCES, SELECT, CREATE ROUTINE, TRIGGER ON *.* TO mysqldump_restore;We kunnen dan de herstelgebruiker maken, deze de rol mysqldump_restore toekennen en de standaardrol toewijzen:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_restore TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_restore FOR [email protected];Door deze truc te gebruiken, kunnen we het aanmaakproces van beheerders vereenvoudigen door een rol toe te wijzen met vooraf gedefinieerde privileges. Onze GRANT-verklaring kan dus worden ingekort en is gemakkelijk te begrijpen.
Rol over rol creëren in MariaDB
We kunnen een andere rol maken over een bestaande rol, vergelijkbaar met een genest groepslidmaatschap, met meer gedetailleerde controle over privileges. We kunnen bijvoorbeeld de volgende 4 rollen maken:
MariaDB> CREATE ROLE app_developer, app_reader, app_writer, app_structure;Verleen de rechten om de schemastructuur te beheren aan de rol app_structure:
MariaDB> GRANT CREATE, ALTER, DROP, CREATE VIEW, CREATE ROUTINE, INDEX, TRIGGER, REFERENCES ON app.* to app_structure;Verleen de rechten voor Data Manipulation Language (DML) aan de app_writer-rol:
MariaDB> GRANT INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES app.* to app_writer;Verleen de rechten voor Data Query Language (DQL) aan de app_reader-rol:
MariaDB> GRANT SELECT, LOCK TABLES, SHOW VIEW app.* to app_reader;En tot slot kunnen we alle bovenstaande rollen toewijzen aan app_developer die volledige controle over het schema zou moeten hebben:
MariaDB> GRANT app_structure TO app_developer;
MariaDB> GRANT app_reader TO app_developer;
MariaDB> GRANT app_writer TO app_developer;De rollen zijn klaar en nu kunnen we een databasegebruiker maken met de 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.%';Aangezien Michael nu tot de rollen app_deleloper en app_reader behoort, kunnen we ook de laagste privileges toewijzen als de standaardrol om hem te beschermen tegen ongewenste menselijke fouten:
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';Het goede aan het gebruik van een rol is dat je de feitelijke privileges voor de databasegebruiker kunt verbergen. Beschouw de volgende databasegebruiker die zojuist is ingelogd:
MariaDB> SELECT user();
+----------------------+
| user() |
+----------------------+
| [email protected] |
+----------------------+Bij het ophalen van de privileges met SHOW GRANTS, zou Michael het volgende zien:
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' |
+----------------------------------------------------------------------------------------------------------------+En wanneer Michael probeert de privileges van de app_developer op te zoeken, ziet hij deze fout:
MariaDB> SHOW GRANTS FOR FOR app_developer;
ERROR 1044 (42000): Access denied for user 'michael'@'localhost' to database 'mysql'Met deze truc kunnen de DBA's alleen de logische groepering vertonen waar de gebruiker thuishoort en niets meer. We kunnen de aanvalsvector van dit aspect verminderen, omdat de gebruikers geen idee hebben van de daadwerkelijke privileges die aan hen zijn toegewezen.
Standaardrol afdwingen in MariaDB
Door een standaardrol af te dwingen, kan een databasegebruiker op de eerste laag worden beschermd tegen onbedoelde menselijke fouten. Neem bijvoorbeeld gebruiker Michael aan wie de rol app_developer is toegekend, waarbij de rol app_developer een superset is van de rollen app_strucutre, app_writer en app_reader, zoals hieronder geïllustreerd:
Aangezien Michael tot de app_deleloper-rol behoort, kunnen we ook het laagste privilege instellen als de standaardrol om hem te beschermen tegen onbedoelde gegevenswijziging:
MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';Wat gebruiker "michael" betreft, hij ziet het volgende zodra hij is ingelogd:
MariaDB> SELECT user(),current_role();
+-------------------+----------------+
| user() | current_role() |
+-------------------+----------------+
| [email protected] | app_reader |
+-------------------+----------------+De standaardrol is app_reader, wat een alleen-lezen-privilege is voor een database met de naam "app". De huidige gebruiker heeft de mogelijkheid om tussen alle toepasselijke rollen te schakelen met behulp van de functie ROL INSTELLEN. Wat Michael betreft, hij kan overschakelen naar een andere rol door de volgende verklaring te gebruiken:
MariaDB> SET ROLE app_developer;Op dit punt zou Michael in staat moeten zijn om naar de database 'app' te schrijven, aangezien app_developer een superset is van app_writer en app_structure. Om de beschikbare rollen voor de huidige gebruiker te controleren, kunnen we de information_schema.applicable_roles tabel opvragen:
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 |
+-------------------+---------------+--------------+------------+Op deze manier stellen we een soort primaire rol in voor de gebruiker, en de primaire rol kan het laagst mogelijke privilege zijn voor een specifieke gebruiker. De gebruiker moet toestemming geven voor zijn actieve rol door over te schakelen naar een andere bevoorrechte rol voordat hij een riskante activiteit op de databaseserver uitvoert.
Roltoewijzing in MariaDB
MariaDB biedt een roltoewijzingstabel met de naam mysql.roles_mapping. De mapping stelt ons in staat om gemakkelijk de correlatie tussen een gebruiker en zijn rollen te begrijpen, en hoe een rol wordt toegewezen aan een andere rol:
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 |
+-------------+-------------------+------------------+--------------+
Uit de bovenstaande uitvoer kunnen we afleiden dat een gebruiker zonder host in feite een rol is boven een rol en dat beheerders met beheerdersrechten (Admin_option =Y) ook automatisch worden toegewezen aan de aangemaakte rollen. Om de lijst met aangemaakte rollen te krijgen, kunnen we de MySQL-gebruikerstabel opvragen:
MariaDB> SELECT user FROM mysql.user WHERE is_role = 'Y';
+------------------+
| User |
+------------------+
| app_developer |
| app_writer |
| app_reader |
| app_structure |
| mysqldump_backup |
| mariadb_backup |
+------------------+Laatste gedachten
Het gebruik van rollen kan de databasebeveiliging verbeteren door een extra beschermingslaag te bieden tegen onbedoelde wijziging van gegevens door databasegebruikers. Bovendien vereenvoudigt het het beheer en onderhoud van bevoegdheden voor organisaties met veel databasegebruikers.