Construire un modèle de moindre privilège avec des rôles (CREATE ROLE, DEFAULT ROLE)

Commande

CREATE ROLE IF NOT EXISTS 'app_read', 'app_write';
GRANT SELECT ON shop.* TO 'app_read';
GRANT INSERT, UPDATE, DELETE ON shop.* TO 'app_write';

-- Application account: network range, TLS required, roles active by default
CREATE USER 'svc_app'@'10.0.%' IDENTIFIED BY 'S3cure#App2024' DEFAULT ROLE 'app_read', 'app_write' REQUIRE SSL;
CREATE USER 'ana'@'%' IDENTIFIED BY 'An4#Report2024';
GRANT 'app_read' TO 'ana'@'%';
SET DEFAULT ROLE ALL TO 'ana'@'%';

-- Show grants with roles expanded
SHOW GRANTS FOR 'svc_app'@'10.0.%' USING 'app_read', 'app_write';
SELECT FROM_USER, FROM_HOST, TO_USER, TO_HOST FROM mysql.role_edges;

Ce que fait la commande

Accorde les privilèges à des rôles plutôt qu'à des utilisateurs individuels ; les comptes obtiennent leurs privilèges par appartenance à un rôle. Les modifications se font en un seul endroit, et l'audit comme le départ d'un collaborateur sont simplifiés.

Quand l'utiliser

Lors de la création de nouveaux comptes d'application / d'équipe et du nettoyage d'anciens serveurs aux privilèges enchevêtrés.

Attention

Un rôle qui n'est pas un rôle par défaut n'est pas actif dans la session (CURRENT_ROLE() NONE) et l'utilisateur semble manquer de privilèges ; utilisez SET DEFAULT ROLE ALL ou activate_all_roles_on_login=ON. Un rôle est aussi un compte (verrouillé, sans mot de passe) et apparaît dans mysql.user. Utilisez une plage réseau au lieu de '%' pour les comptes d'application. N'accordez jamais ALL, SUPER, FILE, PROCESS ou CONNECTION_ADMIN à un compte d'application. Révoquer un privilège d'un rôle affecte aussi les sessions actives.