È sempre un mal di testa... devi aggiungere un nuovo ruolo utente o modificare alcuni privilegi, e devi assegnarlo uno... per... uno. Questo è un dovere regolare, soprattutto nelle grandi organizzazioni, o in un'azienda in cui si dispone di una struttura di privilegi complessa, o anche se si deve gestire un numero elevato di utenti del database.
Ad esempio, supponiamo che tu debba aggiungere il privilegio UPDATE a un database specifico per tutto il team QA, se sono un team di cinque non ci sono problemi, ma se sono 50... o 100... possono diventar difficile. Certo, puoi sempre scriverne uno script, ma in questo modo c'è sempre il rischio.
In questo blog vedremo come possiamo risolvere questo problema di gestione degli utenti del database utilizzando i ruoli e con suggerimenti specifici su come utilizzarli con MariaDB.
Cos'è un ruolo?
Nel mondo dei database, un ruolo è un gruppo di privilegi che possono essere assegnati a uno o più utenti ea un utente può essere assegnato uno o più ruoli. Per fare un confronto, è come un gruppo su sistema operativo Linux.
Se vediamo l'esempio precedente sul privilegio UPDATE nel team QA, se abbiamo creato il ruolo QA e tutti i membri QA hanno questo ruolo assegnato, non importa il numero di membri, devi solo cambiare il privilegio su questo ruolo QA e verrà propagato a tutti gli utenti QA.
Ruoli su MariaDB
Per gestire i ruoli su MariaDB è necessario creare il ruolo con l'istruzione CREATE ROLE, assegnare il privilegio a quel ruolo con un'istruzione GRANT, quindi assegnare il privilegio all'utente per poter utilizzare questo ruolo. Puoi anche impostare un ruolo predefinito, in modo che l'utente lo assumerà durante la connessione.
Come utente del database, devi impostare il ruolo quando accedi al database (se non esiste un ruolo predefinito) e puoi modificare il ruolo, se necessario, con un'istruzione SET ROLE.
Dal lato dell'applicazione, dovresti essere in grado di impostare il ruolo (o utilizzare l'impostazione predefinita) prima di eseguire query per farlo funzionare, quindi nelle vecchie applicazioni potrebbe essere complesso da implementare.
Vediamo alcune specifiche per i ruoli su MariaDB.
- Può essere attivo un solo ruolo alla volta per l'utente corrente.
- Da MariaDB 10.1 abbiamo un ruolo predefinito. Questo ruolo viene abilitato automaticamente quando l'utente si connette.
- I ruoli sono archiviati in memoria.
Come controllare i ruoli
Su MariaDB ci sono diversi modi per verificarlo:
- SHOW GRANTS [ FOR (user | role) ]:elenca le concessioni per l'utente corrente o per uno specifico.
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) - SELEZIONA utente DA mysql.user WHERE is_role='Y':elenca i ruoli creati nel database.
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:è un elenco di ruoli disponibili per l'utente corrente.
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:elenca i ruoli attivi correnti.
MariaDB [testing]> SELECT * FROM information_schema.enabled_roles; +-----------+ | ROLE_NAME | +-----------+ | qateam | +-----------+ 1 row in set (0.000 sec) - SELECT * FROM mysql.roles_mapping:elenca le relazioni tra ruoli e autorizzazioni utente.
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)
Come gestire i ruoli su MariaDB
Vediamo un esempio di come gestirlo su MariaDB. In questo caso, utilizzeremo la versione MariaDB 10.3 in esecuzione su CentOS 7.
Per prima cosa, creiamo un nuovo utente del database:
MariaDB [testing]> CREATE USER [email protected]'%' IDENTIFIED BY 'PASSWORD';Se controlliamo le sovvenzioni per questo nuovo utente, vedremo qualcosa del genere:
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)Ora, proviamo ad accedere con questo utente e a connetterci al database di test:
$ 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'Come abbiamo potuto vedere, non possiamo connetterci al database di test con questo utente, quindi ora creeremo un ruolo "qateam" con i privilegi e assegneremo questo ruolo a questo nuovo utente.
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)Se proviamo a utilizzare questo ruolo senza GRANT, vedremo il seguente errore:
MariaDB [(none)]> SET ROLE qateam;
ERROR 1959 (OP000): Invalid role specification `qateam`Quindi, ora eseguiremo GRANT per consentire all'utente di utilizzarlo:
MariaDB [(none)]> GRANT qateam TO [email protected]'%';
Query OK, 0 rows affected (0.000 sec)Imposta il ruolo sull'utente corrente:
MariaDB [(none)]> SET ROLE qateam;
Query OK, 0 rows affected (0.000 sec)E prova ad accedere al database:
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]>Possiamo controllare le sovvenzioni per l'utente corrente:
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)E il ruolo attuale:
MariaDB [testing]> SELECT CURRENT_ROLE;
+--------------+
| CURRENT_ROLE |
+--------------+
| qateam |
+--------------+
1 row in set (0.000 sec)Qui possiamo vedere la concessione per il ruolo qateam, e basta, non abbiamo il privilegio assegnato direttamente all'utente, abbiamo i privilegi per il ruolo e l'utente prende i privilegi da lì.
Conclusione
La gestione dei ruoli può semplificarci la vita nelle grandi aziende o nei database con un numero elevato di utenti che vi accedono. Se vogliamo utilizzarlo dalla nostra applicazione, dobbiamo tenere conto che anche l'applicazione deve essere in grado di gestirla.
