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

Comment gérer les privilèges avec les rôles dans MySQL


Introduction

Le contrôle d'accès et la gestion des utilisateurs sont deux domaines qui peuvent rapidement devenir complexes à mesure que le nombre d'utilisateurs et d'entités de base de données différentes au sein de votre système augmente. Gérer de nombreux privilèges différents sur divers objets de base de données, s'assurer que les utilisateurs qui ont les mêmes responsabilités ont le même niveau d'accès, et auditer et restreindre l'accès deviennent de plus en plus difficiles avec le temps.

Pour aider à résoudre ce problème, MySQL a un concept appelé "rôles" qui vous permet de regrouper des ensembles de privilèges sous un nom donné, vous permettant d'attribuer et de modifier les paramètres en masse. Dans ce guide, nous verrons comment les rôles fonctionnent dans MySQL et comment les utiliser pour faciliter la gestion de l'accès aux données pour vos utilisateurs.


Commandes

Voici les principales commandes SQL dont nous parlerons en relation avec la gestion des rôles MySQL.

  • CREATE ROLE  :Le CREATE ROLE La commande définit un nouveau rôle dans le système de base de données.
  • DROP ROLE  :Le DROP ROLE commande fait le contraire, en supprimant un rôle existant.
  • GRANT  :La GRANT La commande a deux objectifs distincts liés aux rôles :ajouter des privilèges aux rôles et ajouter des comptes d'utilisateurs en tant que membres des rôles.
  • REVOKE :Dans le contexte des rôles, le REVOKE La commande supprime les privilèges d'un rôle et supprime également l'appartenance au rôle des comptes d'utilisateurs.
  • SHOW GRANTS :Les SHOW GRANTS La commande affiche les privilèges du compte ou du rôle d'utilisateur donné.
  • SET ROLE :Le SET ROLE La commande modifie les rôles qu'un compte d'utilisateur utilise activement. Cela vous permet de déterminer quels ensembles d'autorisations s'appliquent au compte pour la session.
  • SET DEFAULT ROLE  :Le SET DEFAULT ROLE La commande définit les rôles qui sont automatiquement appliqués lorsqu'un client se connecte en tant que compte d'utilisateur spécifique.


Privilèges requis

Pour suivre ce guide, vous aurez besoin des privilèges suivants :

  • CREATE ROLE
  • GRANT OPTION
  • CREATE USER (pour définir les rôles par défaut pour un autre utilisateur)
  • ROLE_ADMIN (pour définir des variables système qui modifient le comportement du rôle)
  • SYSTEM_VARIABLES_ADMIN (pour définir des variables système qui modifient le comportement du rôle)

Le CREATE ROLE le privilège est une version inférieure du CREATE USER privilège, vous permettant de créer et de gérer des rôles. Les comptes qui ont déjà le CREATE USER disposent automatiquement de toutes les fonctionnalités requises pour gérer les rôles.

L'GRANT OPTION privilège est requis pour attribuer des privilèges à un rôle. Vous devez avoir GRANT OPTION activé pour tous les privilèges que vous souhaitez attribuer à un rôle.




Que sont les rôles ?

Dans MySQL, un rôle est une entité qui fonctionne comme un conteneur ou une collection de privilèges. Les administrateurs peuvent attribuer des privilèges aux rôles de la même manière qu'ils attribuent des privilèges aux comptes d'utilisateurs. Vous pouvez ensuite ajouter des comptes d'utilisateurs en tant que membres du rôle, permettant à ces comptes d'accéder aux privilèges associés au rôle.

Fondamentalement, les rôles fonctionnent comme un moyen de regrouper différents privilèges associés pour faciliter la gestion des privilèges. Au lieu de vous assurer que chaque utilisateur dispose du niveau d'accès exact dont il a besoin en attribuant des privilèges individuels, l'utilisation de groupes de privilèges nommés vous permet de gérer moins d'attributions, plus faciles à comprendre.

Cela présente un net avantage lors de l'attribution des niveaux d'accès, car il est plus facile d'attribuer un developer , sysadmin , ou financeteam rôle à un utilisateur que de gérer individuellement des dizaines de privilèges. Cela permet également de modifier rapidement l'accès à plusieurs comptes à la fois. Si vous créez une nouvelle base de données pour l'équipe commerciale, vous pouvez donner à salesteam rôle y accéder au lieu de rechercher tous les comptes qui devraient y avoir accès.



Créer des rôles

Si vous avez un compte avec le CREATE ROLE privilège, vous pouvez gérer les rôles en utilisant le CREATE ROLE commande.


Quelle est la syntaxe de MySQL pour les rôles ?

Les noms de rôle doivent suivre un format spécifique pour que MySQL les considère valides. À bien des égards, ils reflètent le format utilisé pour définir les comptes utilisateur MySQL, mais avec quelques différences importantes.

Les rôles suivent le format suivant :

'<role>'@'<host>'

Comme les utilisateurs, les rôles ont deux composants :le nom du rôle et l'hôte à partir duquel le client se connecte. Cependant, la façon dont MySQL interprète ces composants diffère.

Avec les rôles, le '<role>' partie du nom ne peut jamais être vide. Il n'y a pas de concept de rôle "anonyme" comme c'est le cas avec les utilisateurs. D'autre part, en omettant le '<host>' partie est toujours autorisé, et MySQL utilisera % en tant qu'hôte. Cependant, le % dans ce contexte est interprété comme un caractère littéral et non comme un caractère générique.

En effet, cela signifie que bien que les noms de rôle partagent superficiellement le format des noms de compte d'utilisateur, ils ne subissent aucun type d'évaluation comme le font les comptes d'utilisateur et ne sont qu'une étiquette à deux composants. La raison pour laquelle ils font ont deux parties à leur nom est que vous pouvez créer des comptes d'utilisateurs qui peuvent fonctionner à la fois comme utilisateurs et comme rôles. Lorsqu'ils sont utilisés en tant qu'utilisateur, les composants sont soumis aux règles d'évaluation spéciales décrites dans l'article sur la gestion des utilisateurs et lorsqu'ils sont utilisés en tant que rôle, le nom est simplement mis en correspondance directement à l'aide des noms littéraux des composants.

En raison de ces règles, dans de nombreux cas, les administrateurs choisissent de définir des rôles en utilisant uniquement le '<role>' composant. Cela amène MySQL à substituer un % littéral caractère pour le '<host>' composant, rendant effectivement cette partie du nom invisible et sans conséquence. Si vous ne souhaitez pas qu'un nom soit utilisé à la fois comme compte d'utilisateur et comme rôle, vous pouvez faire de même.



Comment créez-vous des rôles ?

Pour créer de nouveaux rôles, utilisez le CREATE ROLE commande.

La syntaxe de base ressemble à ceci :

CREATE ROLE '<role>'@'<host>';

Vous pouvez également créer plusieurs rôles en même temps en séparant chaque nom de rôle par une virgule :

CREATE ROLE '<role_1>'@'<host>', '<role_2>'@'<host>', '<role_3>'@'<host>';

Si l'un des rôles que vous spécifiez existe déjà sur le système, la commande échouera avec une erreur.

Pour éviter cela et faire en sorte que MySQL n'émette qu'un avertissement, vous pouvez inclure le IF NOT EXISTS clause après le CREATE ROLE commande avant les noms de rôles :

CREATE ROLE IF NOT EXISTS '<role>'@'<host>';

Comme mentionné ci-dessus, les administrateurs omettent souvent le '<host>' partie du nom du rôle pour plus de simplicité, en la définissant implicitement sur le littéral % personnage. Ainsi, en pratique, bon nombre de vos commandes de création de rôle pourraient ressembler davantage à ceci :

CREATE ROLE '<role>';



Comment accordez-vous des privilèges à un rôle ?

Après avoir créé de nouveaux rôles, votre priorité suivante consiste généralement à leur donner un sens en leur accordant des privilèges.

Vous accordez des privilèges aux rôles de la même manière que vous accordez des privilèges aux comptes d'utilisateurs. Vous fournissez les privilèges exacts que vous souhaitez accorder, spécifiez une portée en fournissant la base de données et l'objet de base de données où le privilège est valide, et l'entité à laquelle les privilèges doivent être accordés - dans ce cas, un rôle :

GRANT <privileges> ON <database>.<object> TO '<role>'@'<host>';

Par exemple, pour accorder le SELECT privilège à un rôle appelé readapp sur appdb base de données et tous les objets qu'elle contient, vous pouvez taper :

GRANT SELECT ON appdb.* TO 'readapp';

De même, vous pouvez accorder des privilèges d'écriture sur la même base de données à un rôle appelé writeapp en tapant :

GRANT SELECT,INSERT,UPDATE,DELETE ON appdb.* TO 'writeapp';

Vous pouvez accorder des privilèges à des rôles et les révoquer exactement comme vous le feriez directement avec des comptes d'utilisateurs. Ainsi, vous pouvez toujours modifier les privilèges associés à un rôle si vous avez besoin d'ajuster le niveau d'accès que vous souhaitez fournir.



Comment accordez-vous aux utilisateurs l'adhésion à un rôle ?

Une fois que vous avez ajouté des privilèges à vos rôles, vous pouvez commencer à ajouter des membres au rôle pour leur accorder les privilèges associés.

Pour ce faire, MySQL utilise une forme différente du même GRANT nous utilisons pour accorder des privilèges aux utilisateurs et aux rôles. Cependant, ce nouveau formulaire ajoute des rôles à un utilisateur, permettant au compte d'utilisateur d'accéder à tous les privilèges accordés au rôle.

La syntaxe de base ressemble à ceci :

GRANT '<role>'@'<host>' TO '<user>'@'<host>';

Par exemple, si le 'reports'@'localhost' l'utilisateur doit pouvoir lire les données de appdb base de données pour générer des rapports, nous pouvons ajouter le readapp rôle au compte d'utilisateur, en lui donnant des privilèges sélectionnés :

GRANT 'readapp' TO 'reports'@'localhost';

De même, pour donner le 'appuser'@'localhost' la possibilité de gérer les données au sein de la même base de données, nous pouvons faire de cet utilisateur un membre de l'writeapp rôle :

GRANT 'writeapp' TO 'appuser'@'localhost';

Le 'appuser'@'localhost' compte aura désormais la possibilité d'insérer, de mettre à jour et de supprimer des données de la base de données. Si de nouveaux privilèges sont ajoutés à writeapp rôle, le 'appuser'@'localhost' compte obtiendra immédiatement ces privilèges.


Comment accordez-vous automatiquement certains rôles à chaque utilisateur ?

Parfois, il peut y avoir des rôles auxquels vous souhaitez que chaque utilisateur de votre système ait accès. Vous pouvez définir les rôles attribués automatiquement à chaque compte en définissant le mandatory_roles variables.

Pour modifier les mandatory_roles variable, votre utilisateur doit avoir le ROLE_ADMIN et SYSTEM_VARIABLES_ADMIN privilèges. Vous pouvez définir les rôles que vous souhaitez donner à chaque utilisateur en tapant :

SET PERSIST mandatory_roles = '`<role_1>`@`<host>`, `<role_2>`@`<host>`, `<role_3>`@`<host>`';

Ici, nous donnons automatiquement à chaque utilisateur du système trois rôles. Lors de la définition de la variable système, la valeur de mandatory_roles doit être une chaîne, nous encapsulons donc la liste complète des rôles entre guillemets simples et utilisons des backticks pour citer les composants de rôle individuels.

Vous ne pouvez pas ajouter de rôle aux mandatory_roles liste contenant le SYSTEM_USER privilège. Il s'agit d'une mesure de sécurité pour s'assurer que toutes les sessions sur le système ne sont pas automatiquement des sessions système.




Comment utilisez-vous les privilèges des rôles ?

Une fois que vous avez accordé des comptes d'utilisateurs à des rôles, comment les utilisez-vous ? Pour accéder aux privilèges accordés à un compte par un rôle, celui-ci doit être activé.


Affichage des rôles actifs actuels

Avant d'activer de nouveaux rôles, vous pouvez vérifier quels rôles sont actuellement actifs pour votre session utilisateur.

Pour afficher les rôles actifs de votre session, saisissez :

SELECT CURRENT_ROLE()

La sortie affichera zéro ou plusieurs rôles actifs dans votre session en cours. Les privilèges associés à ces rôles s'ajouteront aux actions que vous êtes autorisé à effectuer.



Comment activer les rôles pour la session

Pour modifier les rôles actifs pendant votre session, utilisez le SET ROLE commande. Vous pouvez utiliser cette commande de différentes manières.

La syntaxe de base ressemble à ceci :

SET ROLE '<rolename>'@'<host>';

Cela activera le rôle en question. Il est important de noter que tous les rôles précédemment actifs non mentionnés dans le SET ROLE commande sera maintenant désactivée.

Pour activer plusieurs rôles à la fois, séparez chaque rôle par une virgule :

SET ROLE '<role_1>'@'<host>', '<role_2>'@'<host>', '<role_3>'@'<host>';

Pour activer tous les rôles qui ont été accordés à votre compte, vous pouvez spécifier ALL au lieu d'un rôle spécifique :

SET ROLE ALL;

Vous pouvez également dire à MySQL d'activer tous vos rôles avec une exception spécifique en utilisant ALL EXCEPT :

SET ROLL ALL EXCEPT '<role_1>'@'<host>';

Une autre option consiste à désactiver tous les rôles sur votre compte en spécifiant NONE :

SET ROLE NONE

Cela désactivera tous vos rôles d'utilisateurs pour la session, vous donnant uniquement les privilèges attribués spécifiquement à votre compte d'utilisateur.

Pour revenir à la liste par défaut des rôles définis pour votre compte, utilisez le DEFAULT mot-clé :

SET ROLE DEFAULT


Comment définir les rôles par défaut pour un compte utilisateur

Les rôles automatiquement activés lorsque vous vous connectez en tant qu'utilisateur et ceux qui sont réactivés lorsque vous utilisez SET ROLE DEFAULT sont configurables.

Pour définir les rôles qui seront activés par défaut, utilisez le SET DEFAULT ROLE commande similaire à la façon dont vous utilisez le SET ROLE commande :

SET DEFAULT ROLE '<role_1>'@'<host>';

Cela définira les rôles par défaut qui seront activés pour votre propre compte lors de la connexion ou lors de l'utilisation de SET ROLE DEFAULT .

Si votre utilisateur a le CREATE USER privilège, vous pouvez définir les rôles par défaut pour d'autres comptes :

SET DEFAULT ROLE ALL TO '<user>'@'<host>';

Ici, nous précisons que le '<user>'@'<host>' le compte doit automatiquement activer tous ses rôles lors de l'authentification.

Cette syntaxe peut également être utilisée pour définir les rôles par défaut pour plusieurs comptes en séparant chaque utilisateur par une virgule :

SET DEFAULT ROLE ALL TO '<user_1>'@'<host>', '<user_2>'@'<host>';


Activation par défaut de tous les rôles pour tous les utilisateurs

Si vous souhaitez que chaque compte de votre serveur MySQL active tous ses rôles par défaut, vous pouvez modifier un paramètre système pour le faire.

Lorsque le activate_all_roles_on_login est définie sur true, MySQL activera automatiquement tous les rôles associés à un compte lors de la connexion. Cela remplace les paramètres spécifiés par SET DEFAULT ROLE .

Pour activer cette fonctionnalité, vous devez disposer du SYSTEM_VARIABLES_ADMIN et ROLE_ADMIN privilèges. Activez la fonctionnalité en tapant :

SET PERSIST activate_all_roles_on_login = ON;

Cela entraînera l'activation automatique de tous les rôles par les comptes d'utilisateurs lors de la connexion. Cependant, SET ROLE DEFAULT vous permettra toujours d'activer uniquement les rôles par défaut associés à un compte.




Afficher les privilèges existants obtenus à partir des rôles

Pour comprendre quels privilèges sont disponibles sur votre compte, vous pouvez utiliser le SHOW GRANTS commande.

Pour vérifier les autorisations activées pour un utilisateur, saisissez :

SHOW GRANTS FOR '<user>'@'<host>';

La sortie vous montrera tous les privilèges directement attribués au compte d'utilisateur ainsi que tous les rôles dont l'utilisateur est membre.

Après avoir pris connaissance des rôles dont un compte est membre, vous pouvez vérifier les privilèges que ces rôles offrent à l'utilisateur en tapant :

SHOW GRANTS FOR '<user>'@'<host>' USING '<role>'@'<host>';

Par exemple, pour vérifier les privilèges du 'reports'@'localhost' utilisateur, y compris ceux accordés par son appartenance à readapp rôle, vous pouvez utiliser :

SHOW GRANTS FOR 'reports'@'localhost' USING 'readapp';

Cela vous montrera tous les privilèges explicitement accordés au 'reports'@'localhost' compte utilisateur ainsi que ceux ajoutés par le readapp rôle.



Révoquer un rôle d'un utilisateur

Que se passe-t-il lorsque vous souhaitez supprimer un rôle d'un utilisateur ? Semblable à la façon dont le GRANT La commande peut soit ajouter de nouveaux privilèges à un utilisateur ou à un rôle, soit ajouter des rôles à un utilisateur, le REVOKE La commande peut supprimer les privilèges d'un utilisateur ou d'un rôle et peut également supprimer l'appartenance à un rôle d'un utilisateur.

La syntaxe de base utilisée pour supprimer un rôle d'un compte utilisateur ressemble à ceci :

REVOKE '<role>' FROM '<user>'@'<host>';

Après avoir exécuté une instruction comme celle-ci, l'utilisateur n'aura plus accès aux privilèges accordés par le rôle.

Par exemple, nous pouvons révoquer le writeapp rôle du 'appuser'@'localhost' compte utilisateur en saisissant :

REVOKE 'writeapp' FROM 'appuser'@'localhost';

Si l'utilisateur s'est vu accorder un privilège par d'autres moyens (soit directement, soit par le biais d'une adhésion avec un rôle différent), il aura toujours accès à ce privilège. Donc, si le 'appuser'@'localhost' l'utilisateur était également membre de readapp rôle que nous avons accordé plus tôt, ils auraient toujours SELECT privilèges sur appdb base de données.



Conclusion

L'utilisation de rôles pour distribuer des privilèges dans vos bases de données MySQL peut aider à simplifier la surcharge de gestion et la complexité de votre système de contrôle d'accès. Il est beaucoup plus facile de s'assurer que les utilisateurs ayant les mêmes responsabilités disposent des mêmes privilèges en utilisant des rôles que d'accorder directement de nombreux privilèges différents.

De même, les rôles vous permettent d'être explicite sur l'intention derrière votre octroi de privilèges. Plutôt que d'accorder un grand nombre de privilèges aux comptes sans aucun commentaire, des noms de rôle soigneusement choisis peuvent aider à distinguer les différentes raisons d'accès. En prenant le temps de créer et d'organiser les rôles à l'avance, votre capacité à gérer l'accès des utilisateurs à différentes parties de vos données sera plus simple à long terme.