I ett databashanteringssystem (DBMS) är rollbaserad åtkomstkontroll (RBAC) en begränsning av databasresurser baserad på en uppsättning fördefinierade grupper av privilegier och har blivit en av de viktigaste metoder för avancerad åtkomstkontroll. Databasroller kan skapas och tas bort, samt ha privilegier beviljade och återkallade från dem. Roller kan tilldelas och återkallas från individuella användarkonton. De tillämpliga aktiva rollerna för ett konto kan väljas bland de som tilldelats kontot och ändras under sessioner för det kontot.
I det här blogginlägget kommer vi att täcka några tips och tricks för att använda databasrollen för att hantera användarprivilegier och som en avancerad åtkomstkontrollmekanism för vår databasåtkomst. Om du vill lära dig om grunderna för roller i MySQL och MariaDB, kolla in det här blogginlägget, Databas User Management:Managing Roles for MariaDB.
MySQL vs MariaDB-roller
MySQL och MariaDB använder två olika rollmekanismer. I MySQL 8.0 och senare liknar rollen en annan användare, med användarnamn och värd ('role1'@'localhost'). Ja, det är rollnamnet, som praktiskt taget liknar standarddefinitionen för användar-värd. MySQL lagrar rolldefinitionen precis som när du lagrar användarbehörigheter i systemtabellen mysql.user.
MariaDB hade introducerat roll- och åtkomstprivilegier i MariaDB version 10.0.5 (november 2013), drygt 8 år innan MySQL inkluderade den här funktionen i MySQL8.0. Den följer liknande rollhantering i ett SQL-kompatibelt databassystem, mer robust och mycket lättare att förstå. MariaDB lagrar definitionen i mysql.user systemtabellen flaggad med en nyligen tillagd kolumn som heter is_role. MySQL lagrar rollen på ett annat sätt, med en användar-värdkombination som liknar den vanliga MySQL-användarhanteringen.
Med det sagt är rollmigrering mellan dessa två DBMS nu inkompatibel med varandra.
MariaDB administrativa roller och säkerhetskopiering
MySQL har dynamiska privilegier, som ger en uppsättning privilegier för vanliga administrationsuppgifter. För MariaDB kan vi ställa in liknande saker med hjälp av roller, särskilt för säkerhetskopiering och återställningsprivilegier. För MariaDB Backup, eftersom det är en fysisk säkerhetskopia och kräver en annan uppsättning privilegier, kan vi skapa en specifik roll för att den ska tilldelas en annan databasanvändare.
Skapa först en roll och tilldela den med rätt behörigheter:
MariaDB> CREATE ROLE mariadb_backup;
MariaDB> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO mariadb_backup;Vi kan sedan skapa backupanvändaren, ge den rollen mariadb_backup och tilldela standardrollen:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'passw0rdMMM';
MariaDB> GRANT mariadb_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mariadb_backup FOR [email protected];För mysqldump eller mariadb-dump kan de minimala behörigheterna för att skapa en säkerhetskopia ställas in enligt nedan:
MariaDB> CREATE ROLE mysqldump_backup;
MariaDB> GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO mysqldump_backup;Vi kan sedan skapa backupanvändaren, ge den rollen mysqldump_backup och tilldela standardrollen:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_backup FOR [email protected];För återställning kräver det vanligtvis en annan uppsättning privilegier, vilket är lite:
MariaDB> CREATE ROLE mysqldump_restore;
MariaDB> GRANT SUPER, ALTER, INSERT, CREATE, DROP, LOCK TABLES, REFERENCES, SELECT, CREATE ROUTINE, TRIGGER ON *.* TO mysqldump_restore;Vi kan sedan skapa återställningsanvändaren, ge den rollen mysqldump_restore och tilldela standardrollen:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_restore TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_restore FOR [email protected];Genom att använda detta trick kan vi förenkla processen för att skapa administrativa användare genom att tilldela en roll med fördefinierade privilegier. Således kan vårt GRANT-uttalande förkortas och lätt att förstå.
Skapa roll framför roll i MariaDB
Vi kan skapa en annan roll över en befintlig roll som liknar ett kapslat gruppmedlemskap med mer finkornig kontroll över privilegier. Till exempel kan vi skapa följande fyra roller:
MariaDB> CREATE ROLE app_developer, app_reader, app_writer, app_structure;Ge behörighet att hantera schemastrukturen till rollen app_structure:
MariaDB> GRANT CREATE, ALTER, DROP, CREATE VIEW, CREATE ROUTINE, INDEX, TRIGGER, REFERENCES ON app.* to app_structure;Ge behörigheterna för Data Manipulation Language (DML) till rollen app_writer:
MariaDB> GRANT INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES app.* to app_writer;Ge privilegier för Data Query Language (DQL) till rollen app_reader:
MariaDB> GRANT SELECT, LOCK TABLES, SHOW VIEW app.* to app_reader;Och slutligen kan vi tilldela alla ovanstående roller till app_developer som bör ha full kontroll över schemat:
MariaDB> GRANT app_structure TO app_developer;
MariaDB> GRANT app_reader TO app_developer;
MariaDB> GRANT app_writer TO app_developer;Rollerna är klara och nu kan vi skapa en databasanvändare med rollen 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.%';Eftersom Michael nu tillhör rollerna app_deleloper och app_reader kan vi också tilldela de lägsta privilegierna som standardrollen för att skydda honom mot oönskade mänskliga misstag:
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';Det som är bra med att använda en roll är att du kan dölja de faktiska privilegierna för databasanvändaren. Tänk på att följande databasanvändare just har loggat in:
MariaDB> SELECT user();
+----------------------+
| user() |
+----------------------+
| [email protected] |
+----------------------+När han försökte hämta privilegierna med SHOW GRANTS, skulle Michael se:
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' |
+----------------------------------------------------------------------------------------------------------------+Och när Michael försöker leta efter app_developers privilegier, skulle han se det här felet:
MariaDB> SHOW GRANTS FOR FOR app_developer;
ERROR 1044 (42000): Access denied for user 'michael'@'localhost' to database 'mysql'Det här tricket tillåter DBA:erna att endast visa den logiska grupperingen där användaren hör hemma och inget mer. Vi kan minska attackvektorn från denna aspekt eftersom användarna inte har någon aning om de faktiska privilegierna som tilldelas dem.
Tillämpa standardroll i MariaDB
Genom att upprätthålla en standardroll kan en databasanvändare skyddas i det första lagret mot oavsiktliga mänskliga misstag. Tänk till exempel på användaren Michael som har beviljats rollen app_developer, där rollen app_developer är en superuppsättning av rollerna app_strucutre, app_writer och app_reader, som illustreras nedan:
Eftersom Michael tillhör rollen app_deleloper kan vi också ställa in den lägsta behörigheten som standardroll för att skydda honom mot oavsiktlig dataändring:
MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';När det gäller användaren "michael", skulle han se följande när han är inloggad:
MariaDB> SELECT user(),current_role();
+-------------------+----------------+
| user() | current_role() |
+-------------------+----------------+
| [email protected] | app_reader |
+-------------------+----------------+Dess standardroll är app_reader, vilket är ett skrivskyddat privilegium för en databas som kallas "app". Den aktuella användaren har möjlighet att växla mellan alla tillämpliga roller med funktionen SET ROLE. När det gäller Michael kan han byta till en annan roll genom att använda följande uttalande:
MariaDB> SET ROLE app_developer;Vid det här laget borde Michael kunna skriva till databasen "app" eftersom app_developer är en superuppsättning av app_writer och app_structure. För att kontrollera tillgängliga roller för den aktuella användaren kan vi fråga tabellen 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 |
+-------------------+---------------+--------------+------------+På detta sätt anger vi en primär roll för användaren, och den primära rollen kan vara den lägsta möjliga behörigheten för en specifik användare. Användaren måste samtycka till sin aktiva roll genom att byta till en annan privilegierad roll innan någon riskfylld aktivitet utförs på databasservern.
Rollmappning i MariaDB
MariaDB tillhandahåller en rollmappningstabell som heter mysql.roles_mapping. Mappningen gör att vi enkelt kan förstå sambandet mellan en användare och dess roller, och hur en roll mappas till en annan roll:
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 |
+-------------+-------------------+------------------+--------------+
Från ovanstående utdata kan vi se att en användare utan en värd i grunden är en roll över en roll och administrativa användare (Admin_option =Y) tilldelas också de skapade rollerna automatiskt. För att få listan över skapade roller kan vi fråga MySQL-användartabellen:
MariaDB> SELECT user FROM mysql.user WHERE is_role = 'Y';
+------------------+
| User |
+------------------+
| app_developer |
| app_writer |
| app_reader |
| app_structure |
| mysqldump_backup |
| mariadb_backup |
+------------------+Sluta tankar
Användning av roller kan förbättra databassäkerheten genom att tillhandahålla ett extra lager av skydd mot oavsiktlig datamodifiering av databasanvändarna. Dessutom förenklar det privilegiehantering och underhåll för organisationer som har många databasanvändare.