In un sistema di gestione dei database (DBMS), i controlli di accesso basati sui ruoli (RBAC), sono una restrizione alle risorse del database basata su un insieme di gruppi predefiniti di privilegi ed è diventata una delle principali metodi per il controllo degli accessi avanzato. I ruoli del database possono essere creati ed eliminati, nonché avere privilegi concessi e revocati da essi. I ruoli possono essere concessi e revocati da singoli account utente. I ruoli attivi applicabili per un account possono essere selezionati tra quelli concessi all'account e modificati durante le sessioni per quell'account.
In questo post del blog, tratteremo alcuni suggerimenti e trucchi sull'utilizzo del ruolo del database per gestire i privilegi degli utenti e come meccanismo di controllo dell'accesso avanzato per l'accesso al nostro database. Se desideri conoscere le nozioni di base sui ruoli in MySQL e MariaDB, dai un'occhiata a questo post del blog, Database User Management:Managing Roles for MariaDB.
Ruoli MySQL e MariaDB
MySQL e MariaDB utilizzano due diversi meccanismi di ruolo. In MySQL 8.0 e versioni successive, il ruolo è simile a quello di un altro utente, con nome utente e host ('role1'@'localhost'). Sì, questo è il nome del ruolo, che è praticamente simile alla definizione standard dell'host utente. MySQL memorizza la definizione del ruolo proprio come la memorizzazione dei privilegi utente nella tabella di sistema mysql.user.
MariaDB aveva introdotto ruoli e privilegi di accesso in MariaDB versione 10.0.5 (novembre 2013), ben 8 anni prima che MySQL includesse questa funzionalità in MySQL8.0. Segue una gestione dei ruoli simile in un sistema di database conforme a SQL, più robusto e molto più facile da capire. MariaDB memorizza la definizione nella tabella di sistema mysql.user contrassegnata con una colonna appena aggiunta chiamata is_role. MySQL memorizza il ruolo in modo diverso, utilizzando una combinazione utente-host simile alla gestione utente standard di MySQL.
Detto questo, la migrazione dei ruoli tra questi due DBMS è ora incompatibile tra loro.
Ruoli amministrativi e di backup di MariaDB
MySQL ha privilegi dinamici, che forniscono una serie di privilegi per le comuni attività di amministrazione. Per MariaDB, possiamo impostare cose simili usando i ruoli, in particolare per i privilegi di backup e ripristino. Per MariaDB Backup, poiché si tratta di un backup fisico e richiede un diverso insieme di privilegi, possiamo creare un ruolo specifico da assegnare a un altro utente del database.
In primo luogo, crea un ruolo e assegnalo con i giusti privilegi:
MariaDB> CREATE ROLE mariadb_backup;
MariaDB> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO mariadb_backup;Possiamo quindi creare l'utente di backup, concedergli il ruolo mariadb_backup e assegnare il ruolo predefinito:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'passw0rdMMM';
MariaDB> GRANT mariadb_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mariadb_backup FOR [email protected];Per mysqldump o mariadb-dump, i privilegi minimi per creare un backup possono essere impostati come segue:
MariaDB> CREATE ROLE mysqldump_backup;
MariaDB> GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO mysqldump_backup;Possiamo quindi creare l'utente di backup, concedergli il ruolo mysqldump_backup e assegnare il ruolo predefinito:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_backup FOR [email protected];Per il ripristino, richiede comunemente un diverso insieme di privilegi, che è un po':
MariaDB> CREATE ROLE mysqldump_restore;
MariaDB> GRANT SUPER, ALTER, INSERT, CREATE, DROP, LOCK TABLES, REFERENCES, SELECT, CREATE ROUTINE, TRIGGER ON *.* TO mysqldump_restore;Possiamo quindi creare l'utente di ripristino, concedergli il ruolo mysqldump_restore e assegnare il ruolo predefinito:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_restore TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_restore FOR [email protected];Utilizzando questo trucco possiamo semplificare il processo di creazione dell'utente amministrativo assegnando un ruolo con privilegi predefiniti. Pertanto, la nostra dichiarazione GRANT può essere abbreviata e di facile comprensione.
Creazione di ruolo su ruolo in MariaDB
Possiamo creare un altro ruolo su un ruolo esistente simile all'appartenenza a un gruppo nidificato con un controllo più dettagliato sui privilegi. Ad esempio, potremmo creare i seguenti 4 ruoli:
MariaDB> CREATE ROLE app_developer, app_reader, app_writer, app_structure;Concedi i privilegi per gestire la struttura dello schema al ruolo app_structure:
MariaDB> GRANT CREATE, ALTER, DROP, CREATE VIEW, CREATE ROUTINE, INDEX, TRIGGER, REFERENCES ON app.* to app_structure;Concedi i privilegi per Data Manipulation Language (DML) al ruolo app_writer:
MariaDB> GRANT INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES app.* to app_writer;Concedi i privilegi per Data Query Language (DQL) al ruolo app_reader:
MariaDB> GRANT SELECT, LOCK TABLES, SHOW VIEW app.* to app_reader;E infine, possiamo assegnare tutti i ruoli precedenti a app_developer che dovrebbe avere il pieno controllo dello schema:
MariaDB> GRANT app_structure TO app_developer;
MariaDB> GRANT app_reader TO app_developer;
MariaDB> GRANT app_writer TO app_developer;I ruoli sono pronti e ora possiamo creare un utente del database con il ruolo 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.%';Dato che Michael ora appartiene ai ruoli app_deleloper e app_reader, possiamo anche assegnare i privilegi più bassi come ruolo predefinito per proteggerlo da errori umani indesiderati:
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';Il vantaggio dell'utilizzo di un ruolo è che puoi nascondere i privilegi effettivi all'utente del database. Considera il seguente utente del database che ha appena effettuato l'accesso:
MariaDB> SELECT user();
+----------------------+
| user() |
+----------------------+
| [email protected] |
+----------------------+Durante il tentativo di recuperare i privilegi utilizzando SHOW GRANTS, Michael vedeva:
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' |
+----------------------------------------------------------------------------------------------------------------+E quando Michael tenta di cercare i privilegi dell'app_developer, vede questo errore:
MariaDB> SHOW GRANTS FOR FOR app_developer;
ERROR 1044 (42000): Access denied for user 'michael'@'localhost' to database 'mysql'Questo trucco consente ai DBA di mostrare solo il raggruppamento logico a cui appartiene l'utente e nient'altro. Possiamo ridurre il vettore di attacco da questo aspetto poiché gli utenti non avranno idea dei privilegi effettivi assegnati loro.
Applicazione del ruolo predefinito in MariaDB
Imponendo un ruolo predefinito, un utente del database può essere protetto al primo livello da errori umani accidentali. Ad esempio, considera l'utente Michael a cui è stato concesso il ruolo app_developer, dove il ruolo app_developer è un superset di ruoli app_strucutre, app_writer e app_reader, come illustrato di seguito:
Dato che Michael appartiene al ruolo app_deleloper, possiamo anche impostare il privilegio più basso come ruolo predefinito per proteggerlo da modifiche accidentali dei dati:
MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';Per quanto riguarda l'utente "michael", una volta effettuato l'accesso vedrebbe quanto segue:
MariaDB> SELECT user(),current_role();
+-------------------+----------------+
| user() | current_role() |
+-------------------+----------------+
| [email protected] | app_reader |
+-------------------+----------------+Il suo ruolo predefinito è app_reader, che è un privilegio di sola lettura per un database chiamato "app". L'utente corrente ha la possibilità di passare da un ruolo applicabile all'altro utilizzando la funzione IMPOSTA RUOLO. Per quanto riguarda Michael, può passare a un altro ruolo usando la seguente affermazione:
MariaDB> SET ROLE app_developer;A questo punto, Michael dovrebbe essere in grado di scrivere nel database "app" poiché app_developer è un superset di app_writer e app_structure. Per verificare i ruoli disponibili per l'utente corrente, possiamo interrogare la tabella 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 |
+-------------------+---------------+--------------+------------+In questo modo, stiamo impostando un ruolo primario per l'utente e il ruolo principale può essere il privilegio più basso possibile per un utente specifico. L'utente deve acconsentire al proprio ruolo attivo, passando a un altro ruolo privilegiato prima di eseguire qualsiasi attività rischiosa sul server del database.
Mappatura dei ruoli in MariaDB
MariaDB fornisce una tabella di mappatura dei ruoli chiamata mysql.roles_mapping. La mappatura ci consente di comprendere facilmente la correlazione tra un utente e i suoi ruoli e come viene mappato un ruolo su un altro ruolo:
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 |
+-------------+-------------------+------------------+--------------+
Dall'output sopra, possiamo dire che un utente senza un host è fondamentalmente un ruolo su un ruolo e anche gli utenti amministrativi (Admin_option =Y) vengono assegnati automaticamente ai ruoli creati. Per ottenere l'elenco dei ruoli creati, possiamo interrogare la tabella utente di MySQL:
MariaDB> SELECT user FROM mysql.user WHERE is_role = 'Y';
+------------------+
| User |
+------------------+
| app_developer |
| app_writer |
| app_reader |
| app_structure |
| mysqldump_backup |
| mariadb_backup |
+------------------+Pensieri finali
L'utilizzo dei ruoli può migliorare la sicurezza del database fornendo un ulteriore livello di protezione contro la modifica accidentale dei dati da parte degli utenti del database. Inoltre, semplifica la gestione dei privilegi e le operazioni di manutenzione per le organizzazioni che hanno molti utenti di database.
