MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Gestion des utilisateurs de la base de données :gestion des rôles pour MariaDB

C'est toujours un casse-tête... vous devez ajouter un nouveau rôle d'utilisateur ou modifier certains privilèges, et vous devez l'attribuer un... par... un. Il s'agit d'une tâche régulière, en particulier dans les grandes organisations, ou dans une entreprise où vous avez une structure de privilèges complexe, ou même si vous devez gérer un nombre élevé d'utilisateurs de base de données.

Par exemple, disons que vous devez ajouter le privilège UPDATE à une base de données spécifique pour toute l'équipe QA, s'ils sont une équipe de cinq, il n'y a pas de problème, mais s'ils sont 50... ou 100... cela peut deviens difficile. Bien sûr, vous pouvez toujours écrire un script pour cela, mais de cette façon, il y a toujours un risque.

Dans ce blog, nous verrons comment nous pouvons résoudre ce problème de gestion des utilisateurs de base de données en utilisant des rôles et avec des conseils spécifiques sur la façon de les utiliser avec MariaDB.

Qu'est-ce qu'un rôle ?

Dans le monde des bases de données, un rôle est un groupe de privilèges pouvant être attribués à un ou plusieurs utilisateurs, et un utilisateur peut se voir attribuer un ou plusieurs rôles. Pour faire une comparaison, c'est comme un groupe sur Linux OS.

Si nous voyons l'exemple précédent sur le privilège UPDATE sur l'équipe QA, si nous avons créé le rôle QA, et que tous les membres QA ont ce rôle assigné, peu importe le nombre de membres, il vous suffit de changer le privilège sur ce rôle QA et il sera propagé à tous les utilisateurs QA.

Rôles sur MariaDB

Pour gérer les rôles sur MariaDB, vous devez créer le rôle avec l'instruction CREATE ROLE, attribuer le privilège à ce rôle avec une instruction GRANT, puis attribuer le privilège à l'utilisateur pour pouvoir utiliser ce rôle. Vous pouvez également définir un rôle par défaut, afin que l'utilisateur le prenne lors de la connexion.

En tant qu'utilisateur de la base de données, vous devez définir le rôle lorsque vous accédez à la base de données (s'il n'y a pas de rôle par défaut), et vous pouvez modifier le rôle si nécessaire avec une instruction SET ROLE.

Du côté de l'application, vous devriez pouvoir définir le rôle (ou utiliser la valeur par défaut) avant d'interroger pour que cela fonctionne, donc dans les anciennes applications, cela pourrait être complexe à mettre en œuvre.

Voyons quelques spécifications pour les rôles sur MariaDB.

  • Un seul rôle peut être actif à la fois pour l'utilisateur actuel.
  • Depuis MariaDB 10.1, nous avons un rôle par défaut. Ce rôle est automatiquement activé lorsque l'utilisateur se connecte.
  • Les rôles sont stockés en mémoire.

Comment vérifier les rôles

Sur MariaDB, il existe plusieurs façons de le vérifier :

  • SHOW GRANTS [ FOR (user | role) ] :répertorie les subventions pour l'utilisateur actuel ou pour un utilisateur spécifique. 
    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' :liste les rôles créés dans la base de données. 
    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 :il s'agit d'une liste des rôles disponibles pour l'utilisateur actuel. 
    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 :répertorie les rôles actifs actuels. 
    MariaDB [testing]> SELECT * FROM information_schema.enabled_roles;
+-----------+
| ROLE_NAME |
+-----------+
| qateam    |
+-----------+
1 row in set (0.000 sec)
  • SELECT * FROM mysql.roles_mapping :répertorie les relations entre les rôles et les droits des utilisateurs. 
    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)

Comment gérer les rôles sur MariaDB

Voyons un exemple de la façon de le gérer sur MariaDB. Dans ce cas, nous utiliserons la version MariaDB 10.3 exécutée sur CentOS 7.

Commençons par créer un nouvel utilisateur de base de données :

MariaDB [testing]> CREATE USER [email protected]'%' IDENTIFIED BY 'PASSWORD';

Si nous vérifions les autorisations pour ce nouvel utilisateur, nous verrons quelque chose comme ceci :

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)

Maintenant, essayons de nous connecter avec cet utilisateur et de nous connecter à la base de données de 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'

Comme nous avons pu le voir, nous ne pouvons pas nous connecter à la base de données de test avec cet utilisateur, donc, maintenant, nous allons créer un rôle "qateam" avec les privilèges et nous allons attribuer ce rôle à ce nouvel utilisateur.

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)

Si nous essayons d'utiliser ce rôle sans GRANT, nous verrons l'erreur suivante :

MariaDB [(none)]> SET ROLE qateam;
ERROR 1959 (OP000): Invalid role specification `qateam`

Nous allons donc maintenant exécuter le GRANT pour permettre à l'utilisateur de l'utiliser :

MariaDB [(none)]> GRANT qateam TO [email protected]'%';
Query OK, 0 rows affected (0.000 sec)

Définissez le rôle sur l'utilisateur actuel :

MariaDB [(none)]> SET ROLE qateam;
Query OK, 0 rows affected (0.000 sec)

Et essayez d'accéder à la base de données :

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]>

Nous pouvons vérifier les subventions pour l'utilisateur actuel :

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)

Et le rôle actuel :

MariaDB [testing]> SELECT CURRENT_ROLE;
+--------------+
| CURRENT_ROLE |
+--------------+
| qateam       |
+--------------+
1 row in set (0.000 sec)

Ici, nous pouvons voir la subvention pour le rôle qateam, et c'est tout, nous n'avons pas le privilège attribué directement à l'utilisateur, nous avons les privilèges pour le rôle, et l'utilisateur prend les privilèges à partir de là.

Conclusion

La gestion des rôles peut nous faciliter la vie dans les grandes entreprises ou les bases de données avec un grand nombre d'utilisateurs qui y accèdent. Si nous voulons l'utiliser depuis notre application, nous devons tenir compte de l'application doit être capable de le gérer aussi.