Comment utiliser les rôles qui ont changé dans MySQL 8.0

La sécurité de la base de données est importante pour toute configuration MySQL. Les utilisateurs sont la base de tout système. En termes de systèmes de bases de données, je les classe généralement en deux groupes distincts :

1. Utilisateurs d'applications, de services ou de programmes - essentiellement des clients ou des clients utilisant un service.
2. Développeurs de bases de données, administrateurs, analystes, etc… - Ceux qui entretiennent, travaillent avec ou surveillent l'infrastructure de la base de données.

Bien que chaque utilisateur ait besoin d'accéder à la base de données à un certain niveau, ces autorisations ne sont pas toutes égales.

Par exemple, les clients et les clients ont besoin d'accéder aux données de leur "compte d'utilisateur associé", mais même cela doit être surveillé avec un certain niveau de contrôle. Cependant, certaines tables et données doivent être strictement interdites (par exemple, les tables système).

Néanmoins :

• L'analyste a besoin d'un accès en lecture ', pour recueillir des informations et des informations via des tables d'interrogation…
• Les développeurs ont besoin d'un grand nombre d'autorisations et de privilèges pour effectuer leur travail…
• Les DBA ont besoin de privilèges "root" ou de type similaire pour exécuter l'émission…
• Les acheteurs d'un service ont besoin de voir l'historique de leurs commandes et de leurs paiements…

Vous pouvez imaginer (je le sais) à quel point il est difficile de gérer plusieurs utilisateurs ou groupes d'utilisateurs au sein d'un écosystème de base de données.

Dans les anciennes versions de MySQL, un environnement multi-utilisateurs est établi de manière quelque peu monotone et répétitive.

Pourtant, la version 8 implémente une fonctionnalité standard SQL exceptionnelle et puissante - Rôles - qui atténue l'un des domaines les plus redondants de l'ensemble du processus :l'attribution de privilèges à un utilisateur.

Alors, qu'est-ce qu'un rôle dans MySQL ?

Vous pouvez sûrement visiter, MySQL en 2018 :What’s in 8.0 and Other Observations, j’ai écrit pour le blog de Manynines ici où je mentionne les rôles pour un aperçu de haut niveau. Cependant, là où je ne les ai résumés qu'ici, cet article actuel cherche à approfondir et à se concentrer uniquement sur les rôles.

Voici comment la documentation MySQL en ligne définit un rôle :"Un rôle MySQL est une collection nommée de privilèges".

Cette définition seule ne semble-t-elle pas utile ?

Mais comment ?

Nous allons le voir dans les exemples qui suivent.

Pour prendre note des exemples fournis

Les exemples inclus dans cet article concernent un poste de travail / environnement de développement et d'apprentissage personnel «à utilisateur unique». Assurez-vous donc de mettre en œuvre les meilleures pratiques qui vous sont utiles pour vos besoins ou exigences particuliers. Les noms d'utilisateur et mots de passe démontrés sont purement arbitraires et faibles.

Utilisateurs et privilèges dans les versions précédentes

Dans MySQL 5.7, les rôles n'existent pas. L'attribution de privilèges aux utilisateurs se fait individuellement. Pour mieux comprendre quels rôles fournissent, ne les utilisons pas. Cela n'a aucun sens du tout, je sais. Mais, au fur et à mesure que nous progresserons dans le message, cela arrivera.

Ci-dessous, nous créons quelques utilisateurs :

CREATE USER 'reader_1'@'localhost' IDENTIFIED BY 'some_password'; 
CREATE USER 'reader_writer'@'localhost' IDENTIFIED BY 'another_password'; 
CREATE USER 'changer_1'@'localhost' IDENTIFIED BY 'a_password';

Ensuite, ces utilisateurs se voient accorder certains privilèges :

GRANT SELECT ON some_db.specific_table TO 'reader_1'@'localhost';
GRANT SELECT, INSERT ON some_db.specific_table TO 'reader_writer'@'localhost';
GRANT UPDATE, DELETE ON some_db.specific_table TO 'changer_1'@'localhost';

Ouf, content que ce soit fini. Revenons maintenant à…

Et juste comme ça, vous avez une demande pour implémenter deux autres utilisateurs "en lecture seule"…

Retour à la planche à dessin :

CREATE USER 'reader_2'@'localhost' IDENTIFIED BY 'password_2'; 
CREATE USER 'reader_3'@'localhost' IDENTIFIED BY 'password_3';

Leur attribuer également des privilèges :

GRANT SELECT ON some_db.specific_table TO 'reader_2'@'localhost';
GRANT ALL ON some_db.specific_table TO 'reader_3'@'localhost';

Pouvez-vous voir à quel point cela est moins que productif, plein de répétitions et sujet aux erreurs ? Mais, plus important encore, avez-vous compris l'erreur ?

Bien à vous !

En accordant des privilèges à ces deux utilisateurs supplémentaires, j'ai accidentellement accordé TOUS les privilèges au nouvel utilisateur reader_3.

Oups.

Une erreur que n'importe qui pourrait faire.

Entrez les rôles MySQL

Avec les rôles, une grande partie de ce qui précède systématique l'attribution et la délégation de privilèges peuvent être quelque peu simplifiées .

La création d'utilisateurs reste fondamentalement la même, mais c'est l'attribution de privilèges via des rôles qui diffère :

mysql> CREATE USER 'reader_1'@'localhost' IDENTIFIED BY 'some_password';
Query OK, 0 rows affected (0.19 sec)

mysql> CREATE USER 'reader_writer'@'localhost' IDENTIFIED BY 'another_password';
Query OK, 0 rows affected (0.22 sec)

mysql> CREATE USER 'changer_1'@'localhost' IDENTIFIED BY 'a_password';
Query OK, 0 rows affected (0.08 sec)

mysql> CREATE USER 'reader_2'@'localhost' IDENTIFIED BY 'password_2';
Query OK, 0 rows affected (0.28 sec)

mysql> CREATE USER 'reader_3'@'localhost' IDENTIFIED BY 'password_3';
Query OK, 0 rows affected (0.12 sec)

En interrogeant la table système mysql.user, vous pouvez voir que ces utilisateurs nouvellement créés existent :

(Remarque :J'ai plusieurs comptes d'utilisateurs dans cet environnement d'apprentissage/de développement et j'ai supprimé une grande partie de la sortie pour une meilleure clarté à l'écran.)

mysql> SELECT User FROM mysql.user;
+------------------+
| User             |
+------------------+
| changer_1        |
| mysql.infoschema |
| mysql.session    |
| mysql.sys        |
| reader_1         |
| reader_2         |
| reader_3         |
| reader_writer    |
| root             |
|                  | --multiple rows remaining here...
+------------------+
23 rows in set (0.00 sec)

J'ai cette table arbitraire et des exemples de données :

mysql> SELECT * FROM name;
+--------+------------+
| f_name | l_name     |
+--------+------------+
| Jim    | Dandy      |
| Johhny | Applesauce |
| Ashley | Zerro      |
| Ashton | Zerra      |
| Ashmon | Zerro      |
+--------+------------+
5 rows in set (0.00 sec)

Utilisons maintenant les rôles pour établir et attribuer les privilèges permettant aux nouveaux utilisateurs d'utiliser la table des noms.

Commencez par créer les rôles :

mysql> CREATE ROLE main_read_only;
Query OK, 0 rows affected (0.11 sec)

mysql> CREATE ROLE main_read_write;
Query OK, 0 rows affected (0.11 sec)

mysql> CREATE ROLE main_changer;
Query OK, 0 rows affected (0.14 sec)

Remarquez à nouveau la table mysql.user :

mysql> SELECT User FROM mysql.user;
+------------------+
| User             |
+------------------+
| main_changer     |
| main_read_only   |
| main_read_write  |
| changer_1        |
| mysql.infoschema |
| mysql.session    |
| mysql.sys        |
| reader_1         |
| reader_2         |
| reader_3         |
| reader_writer    |
| root             |
|                  |
+------------------+
26 rows in set (0.00 sec)

Sur la base de cette sortie, nous pouvons supposer; qu'essentiellement, les rôles sont en fait les utilisateurs eux-mêmes.

Ensuite, attribution des privilèges :

mysql> GRANT SELECT ON practice.name TO 'main_read_only';
Query OK, 0 rows affected (0.14 sec)

mysql> GRANT SELECT, INSERT ON practice.name TO 'main_read_write';
Query OK, 0 rows affected (0.07 sec)

mysql> GRANT UPDATE, DELETE ON practice.name TO 'main_changer';
Query OK, 0 rows affected (0.16 sec)

Un bref intermède

Attendez une minute. Puis-je simplement me connecter et effectuer des tâches avec les comptes de rôle eux-mêmes ? Après tout, ce sont des utilisateurs et ils disposent des privilèges requis.

Essayons de nous connecter à la base de données d'entraînement avec le rôle main_changer :

:~$ mysql -u main_changer -p practice
Enter password: 
ERROR 1045 (28000): Access denied for user 'main_changer'@'localhost' (using password: YES

Le simple fait que l'on nous présente une invite de mot de passe est une bonne indication que nous ne pouvons pas (du moins pour le moment). Comme vous vous en souvenez, je n'ai défini de mot de passe pour aucun des rôles lors de leur création.

Que dit la colonne authentication_string des tables système mysql.user ?

mysql> SELECT User, authentication_string, password_expired
    -> FROM mysql.user
    -> WHERE User IN ('main_read_only', 'root', 'main_read_write', 'main_changer')\G
*************************** 1. row ***************************
                 User: main_changer
authentication_string: 
     password_expired: Y
*************************** 2. row ***************************
                 User: main_read_only
authentication_string: 
     password_expired: Y
*************************** 3. row ***************************
                 User: main_read_write
authentication_string: 
     password_expired: Y
*************************** 4. row ***************************
                 User: root
authentication_string: ***various_jumbled_mess_here*&&*&*&*##
     password_expired: N
4 rows in set (0.00 sec)

J'ai inclus l'utilisateur root parmi les noms de rôle pour la vérification du prédicat IN() pour simplement démontrer qu'il a une chaîne d'authentification, là où les rôles n'en ont pas.

Ce passage de la documentation CREATE ROLE le clarifie bien :"Un rôle lors de sa création est verrouillé, n'a pas de mot de passe et se voit attribuer le plug-in d'authentification par défaut. (Ces attributs de rôle peuvent être modifiés ultérieurement avec l'instruction ALTER USER, par les utilisateurs qui ont le privilège global CREATE USER.)"

Pour en revenir à la tâche à accomplir, nous pouvons désormais attribuer les rôles aux utilisateurs en fonction du niveau de privilèges dont ils ont besoin.

Notez qu'aucune clause ON n'est présente dans la commande :

mysql> GRANT 'main_read_only' TO 'reader_1'@'localhost', 'reader_2'@'localhost', 'reader_3'@'localhost';
Query OK, 0 rows affected (0.13 sec)

mysql> GRANT 'main_read_write' TO 'reader_writer'@'localhost';
Query OK, 0 rows affected (0.16 sec)

mysql> GRANT 'main_changer', 'main_read_only' TO 'changer_1'@'localhost';
Query OK, 0 rows affected (0.13 sec)

Cela peut être moins déroutant si vous utilisez une sorte de 'convention de nommage ' lors de l'établissement des noms de rôle, (je ne sais pas si MySQL en fournit un à ce moment… Communauté ?) si ce n'est pour aucune autre raison que de les différencier visuellement des utilisateurs réguliers "sans rôle".

Il reste encore du travail à faire

C'était super facile, n'est-ce pas ?

Moins redondant que l'ancienne méthode d'attribution de privilèges.

Mettons ces utilisateurs au travail maintenant.

Nous pouvons voir les privilèges accordés à un utilisateur avec la syntaxe SHOW GRANTS. Voici ce qui est actuellement attribué au compte utilisateur reader_1 :

mysql> SHOW GRANTS FOR 'reader_1'@'localhost';
+------------------------------------------------------+
| Grants for [email protected]                        |
+------------------------------------------------------+
| GRANT USAGE ON *.* TO `reader_1`@`localhost`         |
| GRANT `main_read_only`@`%` TO `reader_1`@`localhost` |
+------------------------------------------------------+
2 rows in set (0.02 sec)

Bien que cela fournisse une sortie informative, vous pouvez 'ajuster ' l'instruction pour obtenir des informations encore plus détaillées sur les privilèges exacts fournis par un rôle attribué en incluant une clause USING dans l'instruction SHOW GRANTS et en nommant le nom des rôles attribués :

mysql> SHOW GRANTS FOR 'reader_1'@'localhost' USING 'main_read_only';
+-------------------------------------------------------------+
| Grants for [email protected]                               |
+-------------------------------------------------------------+
| GRANT USAGE ON *.* TO `reader_1`@`localhost`                |
| GRANT SELECT ON `practice`.`name` TO `reader_1`@`localhost` |
| GRANT `main_read_only`@`%` TO `reader_1`@`localhost`        |
+-------------------------------------------------------------+
3 rows in set (0.00 sec)

Après vous être connecté avec reader_1 :

mysql> SELECT * FROM practice.name;
ERROR 1142 (42000): SELECT command denied to user 'reader_1'@'localhost' for table 'name'

Que diable? Cet utilisateur a reçu des privilèges SELECT via le rôle main_read_only.

Pour enquêter, visitons 2 nouvelles tables dans la version 8, spécifiquement pour les rôles.

La table mysql.role_edges montre quels rôles ont été accordés à tous les utilisateurs :

mysql> SELECT * FROM mysql.role_edges;
+-----------+-----------------+-----------+---------------+-------------------+
| FROM_HOST | FROM_USER       | TO_HOST   | TO_USER       | WITH_ADMIN_OPTION |
+-----------+-----------------+-----------+---------------+-------------------+
| %         | main_changer    | localhost | changer_1     | N                 |
| %         | main_read_only  | localhost | changer_1     | N                 |
| %         | main_read_only  | localhost | reader_1      | N                 |
| %         | main_read_only  | localhost | reader_2      | N                 |
| %         | main_read_only  | localhost | reader_3      | N                 |
| %         | main_read_write | localhost | reader_writer | N                 |
+-----------+-----------------+-----------+---------------+-------------------+
6 rows in set (0.00 sec)

Mais, je pense que l'autre table supplémentaire, mysql.default_roles, nous aidera mieux à résoudre les problèmes SELECT pour l'utilisateur reader_1 :

mysql> DESC mysql.default_roles;
+-------------------+----------+------+-----+---------+-------+
| Field             | Type     | Null | Key | Default | Extra |
+-------------------+----------+------+-----+---------+-------+
| HOST              | char(60) | NO   | PRI |         |       |
| USER              | char(32) | NO   | PRI |         |       |
| DEFAULT_ROLE_HOST | char(60) | NO   | PRI | %       |       |
| DEFAULT_ROLE_USER | char(32) | NO   | PRI |         |       |
+-------------------+----------+------+-----+---------+-------+
4 rows in set (0.00 sec)

mysql> SELECT * FROM mysql.default_roles;
Empty set (0.00 sec)

Ensemble de résultats vide.

Il s'avère que pour qu'un utilisateur puisse utiliser un rôle - et finalement les privilèges - l'utilisateur doit se voir attribuer un rôle par défaut.

mysql> SET DEFAULT ROLE main_read_only TO 'reader_1'@'localhost', 'reader_2'@'localhost', 'reader_3'@'localhost';
Query OK, 0 rows affected (0.11 sec)

(Un rôle par défaut peut être attribué à plusieurs utilisateurs dans une seule commande comme ci-dessus…)

mysql> SET DEFAULT ROLE main_read_only, main_changer TO 'changer_1'@'localhost';
Query OK, 0 rows affected (0.10 sec)

(Un utilisateur peut avoir plusieurs rôles par défaut spécifiés comme dans le cas de l'utilisateur changeur_1…)

L'utilisateur reader_1 est maintenant connecté...

mysql> SELECT CURRENT_USER();
+--------------------+
| CURRENT_USER()     |
+--------------------+
| [email protected] |
+--------------------+
1 row in set (0.00 sec)

mysql> SELECT CURRENT_ROLE();
+----------------------+
| CURRENT_ROLE()       |
+----------------------+
| `main_read_only`@`%` |
+----------------------+
1 row in set (0.03 sec)

Nous pouvons voir le rôle actuellement actif et également que reader_1 peut émettre des commandes SELECT maintenant :

mysql> SELECT * FROM practice.name;
+--------+------------+
| f_name | l_name     |
+--------+------------+
| Jim    | Dandy      |
| Johhny | Applesauce |
| Ashley | Zerro      |
| Ashton | Zerra      |
| Ashmon | Zerro      |
+--------+------------+
5 rows in set (0.00 sec)

Autres nuances cachées

Il y a une autre partie importante du puzzle nous devons comprendre.

Il existe potentiellement 3 "niveaux" ou "variantes" différents d'attribution de rôle :

SET ROLE …;
SET DEFAULT ROLE …;
SET ROLE DEFAULT …;

Je vais ATTRIBUER un rôle supplémentaire à l'utilisateur reader_1, puis me connecter avec cet utilisateur (non affiché) :

mysql> GRANT 'main_read_write' TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.17 sec)

Étant donné que le rôle main_read_write a le privilège INSERT, l'utilisateur reader_1 peut désormais exécuter cette commande, n'est-ce pas ?

mysql> INSERT INTO name(f_name, l_name)
    -> VALUES('Josh', 'Otwell');
ERROR 1142 (42000): INSERT command denied to user 'reader_1'@'localhost' for table 'name'

Que se passe-t-il ici ?

Cela peut aider...

mysql> SELECT CURRENT_ROLE();
+----------------------+
| CURRENT_ROLE()       |
+----------------------+
| `main_read_only`@`%` |
+----------------------+
1 row in set (0.00 sec)

Rappelez-vous, nous avons initialement défini pour l'utilisateur reader_1 un rôle par défaut de main_read_only. C'est là que nous devons utiliser l'un de ces "niveaux" distincts de ce que je nomme vaguement 'définition de rôle' :

mysql> SET ROLE main_read_write;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT CURRENT_ROLE();
+-----------------------+
| CURRENT_ROLE()        |
+-----------------------+
| `main_read_write`@`%` |
+-----------------------+
1 row in set (0.00 sec)

Maintenant, essayez à nouveau cet INSERT :

mysql> INSERT INTO name(f_name, l_name)
    -> VALUES('Josh', 'Otwell');
Query OK, 1 row affected (0.12 sec)

Cependant, une fois que l'utilisateur reader_1 se déconnecte, le rôle main_read_write ne sera plus actif lorsque reader_1 se reconnecte. Bien que l'utilisateur reader_1 dispose du rôle main_read_write, ce n'est pas la valeur par défaut.

Voyons maintenant le 3ème "niveau" de "définition du rôle", SET ROLE DEFAULT.

Supposons que l'utilisateur reader_1 n'ait pas encore de rôle attribué :

mysql> SHOW GRANTS FOR 'reader_1'@'localhost';
+----------------------------------------------+
| Grants for [email protected]                |
+----------------------------------------------+
| GRANT USAGE ON *.* TO `reader_1`@`localhost` |
+----------------------------------------------+
1 row in set (0.00 sec)

Accordons 2 rôles à cet utilisateur :

mysql> GRANT 'main_changer', 'main_read_write' TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.07 sec)

Attribuez un rôle par défaut :

mysql> SET DEFAULT ROLE ‘main_changer’ TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.17 sec)

Ensuite, avec l'utilisateur reader_1 connecté, ce rôle par défaut est actif :

mysql> SELECT CURRENT_ROLE();
+--------------------+
| CURRENT_ROLE()     |
+--------------------+
| `main_changer`@`%` |
+--------------------+
1 row in set (0.00 sec)

Passez maintenant au rôle main_read_write :

mysql> SET ROLE 'main_read_write';
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT CURRENT_ROLE();
+-----------------------+
| CURRENT_ROLE()        |
+-----------------------+
| `main_read_write`@`%` |
+-----------------------+
1 row in set (0.00 sec)

Mais, pour revenir au rôle par défaut attribué, utilisez SET ROLE DEFAULT comme indiqué ci-dessous :

mysql> SET ROLE DEFAULT;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT CURRENT_ROLE();
+--------------------+
| CURRENT_ROLE()     |
+--------------------+
| `main_changer`@`%` |
+--------------------+
1 row in set (0.00 sec)

Rôles non accordés

Même si l'utilisateur changeur_1 a 2 rôles disponibles pendant une session :

mysql> SELECT CURRENT_ROLE();
+-----------------------------------------+
| CURRENT_ROLE()                          |
+-----------------------------------------+
| `main_changer`@`%`,`main_read_only`@`%` |
+-----------------------------------------+
1 row in set (0.00 sec)

Que se passe-t-il si vous tentez de définir un utilisateur sur un rôle qui ne lui a pas été accordé ?

mysql> SET ROLE main_read_write;
ERROR 3530 (HY000): `main_read_write`@`%` is not granted to `changer_1`@`localhost`

Refusé.

Enlève

Aucun système de gestion des utilisateurs ne serait complet sans la possibilité de restreindre ou même de supprimer l'accès à certaines opérations en cas de besoin.

Nous avons à notre disposition la commande SQL REVOKE pour supprimer les privilèges des utilisateurs et des rôles.

Rappelez-vous que le rôle main_changer a cet ensemble de privilèges, essentiellement, tous les utilisateurs auxquels ce rôle a été accordé également :

mysql> SHOW GRANTS FOR main_changer;
+-----------------------------------------------------------------+
| Grants for [email protected]%                                       |
+-----------------------------------------------------------------+
| GRANT USAGE ON *.* TO `main_changer`@`%`                        |
| GRANT UPDATE, DELETE ON `practice`.`name` TO `main_changer`@`%` |
+-----------------------------------------------------------------+
2 rows in set (0.00 sec)

mysql> REVOKE DELETE ON practice.name FROM 'main_changer';
Query OK, 0 rows affected (0.11 sec)

mysql> SHOW GRANTS FOR main_changer;
+---------------------------------------------------------+
| Grants for [email protected]%                               |
+---------------------------------------------------------+
| GRANT USAGE ON *.* TO `main_changer`@`%`                |
| GRANT UPDATE ON `practice`.`name` TO `main_changer`@`%` |
+---------------------------------------------------------+
2 rows in set (0.00 sec)

Pour savoir quels utilisateurs cette modification a affectés, nous pouvons visiter à nouveau la table mysql.role_edges :

mysql> SELECT * FROM mysql.role_edges WHERE FROM_USER = 'main_changer';
+-----------+--------------+-----------+-----------+-------------------+
| FROM_HOST | FROM_USER    | TO_HOST   | TO_USER   | WITH_ADMIN_OPTION |
+-----------+--------------+-----------+-----------+-------------------+
| %         | main_changer | localhost | changer_1 | N                 |
+-----------+--------------+-----------+-----------+-------------------+
1 row in set (0.00 sec)

Et nous pouvons voir que l'utilisateur changer_1 n'a plus le privilège DELETE :

mysql> SHOW GRANTS FOR 'changer_1'@'localhost' USING 'main_changer';
+--------------------------------------------------------------------------+
| Grants for [email protected]                                           |
+--------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `changer_1`@`localhost`                            |
| GRANT UPDATE ON `practice`.`name` TO `changer_1`@`localhost`             |
| GRANT `main_changer`@`%`,`main_read_only`@`%` TO `changer_1`@`localhost` |
+--------------------------------------------------------------------------+
3 rows in set (0.00 sec)

Enfin, si nous devons nous débarrasser complètement d'un rôle, nous avons la commande DROP ROLE pour cela :

mysql> DROP ROLE main_read_only;
Query OK, 0 rows affected (0.17 sec)

Et en interrogeant la table mysql.role_edges, le rôle main_read_only a été supprimé :

mysql> SELECT * FROM mysql.role_edges;
+-----------+-----------------+-----------+---------------+-------------------+
| FROM_HOST | FROM_USER       | TO_HOST   | TO_USER       | WITH_ADMIN_OPTION |
+-----------+-----------------+-----------+---------------+-------------------+
| %         | main_changer    | localhost | changer_1     | N                 |
| %         | main_read_write | localhost | reader_1      | N                 |
| %         | main_read_write | localhost | reader_writer | N                 |
+-----------+-----------------+-----------+---------------+-------------------+
3 rows in set (0.00 sec)

(Bonus :cette fantastique vidéo YouTube a été une excellente ressource d'apprentissage pour moi sur les rôles.)

Cet exemple de création d'utilisateur, d'attribution de rôle et de configuration est au mieux rudimentaire. Pourtant, les rôles ont leur propre ensemble de règles qui les rendent loin d'être anodins. J'espère qu'à travers ce billet de blog, j'ai mis en lumière les domaines moins intuitifs que d'autres, permettant aux lecteurs de mieux comprendre les utilisations potentielles des rôles au sein de leurs systèmes.

Merci d'avoir lu.