Maîtrisez les outils et bonnes pratiques DevOps - DevOps Knowledge Hub Maîtrisez les outils et bonnes pratiques DevOps - DevOps Knowledge Hub

Bonnes pratiques pour accorder et révoquer les privilèges des utilisateurs MySQL

Utilisez GRANT, REVOKE, SHOW GRANTS et DROP USER de manière sécurisée avec des exemples de moindre privilège pour les comptes d'application et d'administration.

Bonnes pratiques pour accorder et révoquer les privilèges des utilisateurs MySQL

Les privilèges MySQL déterminent ce que vos applications, outils et administrateurs peuvent faire après s'être connectés. Un seul compte avec un accès large peut transformer un petit bug ou un mot de passe divulgué en une exposition complète de la base de données.

Utilisez GRANT, REVOKE et SHOW GRANTS avec le principe du moindre privilège : chaque compte ne doit avoir que les permissions nécessaires, et uniquement depuis les hôtes qu'il utilise.

Comprendre les privilèges MySQL

Avant de plonger dans GRANT et REVOKE, il est crucial de comprendre les différentes portées et types de privilèges disponibles dans MySQL. Les privilèges définissent les actions qu'un utilisateur peut effectuer et sur quels objets de la base de données.

Les privilèges MySQL peuvent être catégorisés par leur portée :

  • Privilèges globaux (*.*) : S'appliquent à toutes les bases de données et tables sur le serveur MySQL. Exemples : SUPER, PROCESS, RELOAD, CREATE USER.
  • Privilèges de base de données (nom_base.*) : S'appliquent à toutes les tables et objets dans une base de données spécifique. Exemples : SELECT, INSERT, UPDATE, DELETE, CREATE, DROP.
  • Privilèges de table (nom_base.nom_table) : S'appliquent à toutes les colonnes d'une table spécifique. Exemples : SELECT, INSERT, UPDATE, DELETE, ALTER.
  • Privilèges de colonne (nom_base.nom_table.nom_colonne) : S'appliquent à des colonnes spécifiques dans une table. C'est moins courant mais utile pour un contrôle très granulaire.
  • Privilèges de routine (nom_base.nom_routine) : S'appliquent aux procédures stockées et fonctions, contrôlant EXECUTE et ALTER ROUTINE.
  • Privilèges de proxy : Permettent à un utilisateur d'agir comme un autre, utile pour les applications qui gèrent les identités des utilisateurs.

Quelques privilèges spécifiques courants incluent :

  • SELECT : Lire les données des tables.
  • INSERT : Ajouter de nouvelles lignes aux tables.
  • UPDATE : Modifier les lignes existantes dans les tables.
  • DELETE : Supprimer des lignes des tables.
  • CREATE : Créer des bases de données, tables ou index.
  • DROP : Supprimer des bases de données, tables ou index.
  • ALTER : Modifier les structures des tables.
  • INDEX : Créer ou supprimer des index.
  • REFERENCES : Établir des contraintes de clé étrangère.
  • CREATE VIEW, SHOW VIEW : Gérer les vues.
  • CREATE ROUTINE, ALTER ROUTINE, EXECUTE : Gérer et exécuter des procédures stockées et fonctions.
  • FILE : Lire ou écrire des fichiers sur l'hôte du serveur (très puissant, à utiliser avec une extrême prudence).
  • GRANT OPTION : Permet à un utilisateur d'accorder ses propres privilèges à d'autres utilisateurs. C'est un privilège très puissant qui doit être accordé avec parcimonie.

La commande GRANT : Accorder les privilèges de manière sécurisée

La commande GRANT est utilisée pour attribuer des privilèges à un utilisateur MySQL. Lors de l'octroi de privilèges, il est crucial de considérer le principe du moindre privilège – n'accorder que ce qui est absolument nécessaire.

Syntaxe de base

La syntaxe générale de la commande GRANT est :

GRANT privileges ON object TO 'user'@'host' [WITH GRANT OPTION];
  • privileges : Une liste de privilèges séparés par des virgules (par exemple, SELECT, INSERT).
  • object : Spécifie la portée (par exemple, *.* pour global, nom_base.*, nom_base.nom_table).
  • 'user'@'host' : Le compte utilisateur, incluant le nom d'utilisateur et l'hôte depuis lequel il peut se connecter. L'hôte peut être une adresse IP, un nom d'hôte ou un joker (% pour tout hôte, localhost pour les connexions locales).
  • WITH GRANT OPTION : (Optionnel) Permet à l'utilisateur d'accorder les privilèges spécifiés à d'autres utilisateurs.

Créez ou modifiez les mots de passe avec CREATE USER et ALTER USER. Les anciennes versions de MySQL permettaient GRANT ... IDENTIFIED BY, mais la syntaxe MySQL moderne sépare la création du compte.

Exemples pratiques

Parcourons quelques scénarios courants.

  1. Créer un nouvel utilisateur et accorder un accès global en lecture seule (fortement déconseillé)

    CREATE USER 'lecteur_global'@'localhost' IDENTIFIED BY 'StrongPass123!';
GRANT SELECT ON *.* TO 'lecteur_global'@'localhost';

    Avertissement : Accorder SELECT sur *.* donne accès à toutes les bases de données et tables. C'est généralement trop large pour les utilisateurs d'application et doit être évité sauf si absolument nécessaire pour des tâches administratives spécifiques.

  2. Accorder un accès complet à une base de données spécifique pour un utilisateur d'application

    Un scénario courant pour un utilisateur d'application ayant besoin de gérer les données dans sa propre base de données.

    CREATE USER 'utilisateur_app'@'localhost' IDENTIFIED BY 'AppPassSecure!';
GRANT SELECT, INSERT, UPDATE, DELETE ON `ma_base_app`.* TO 'utilisateur_app'@'localhost';

    Ici, utilisateur_app peut effectuer des opérations CRUD de base uniquement dans la base de données ma_base_app, mais ne peut pas créer de nouvelles tables ni modifier le schéma.

  3. Accorder un accès en lecture seule à une table spécifique

    Pour un outil de reporting qui a seulement besoin de lire une table particulière.

    CREATE USER 'outil_rapport'@'%' IDENTIFIED BY 'ReportSecret!';
GRANT SELECT ON `base_ventes`.`commandes` TO 'outil_rapport'@'%';

    L'hôte '%' permet à outil_rapport de se connecter depuis n'importe quel hôte, mais uniquement avec un accès SELECT sur la table commandes dans base_ventes.

  4. Accorder GRANT OPTION (à utiliser avec une extrême prudence)

    Si un administrateur a besoin de déléguer la gestion des privilèges pour une base de données spécifique.

    CREATE USER 'admin_base'@'localhost' IDENTIFIED BY 'AdminPass#456';
GRANT ALL PRIVILEGES ON `base_inventaire`.* TO 'admin_base'@'localhost' WITH GRANT OPTION;

    admin_base peut désormais accorder n'importe quels privilèges sur base_inventaire à d'autres utilisateurs. C'est un privilège puissant qui contourne le contrôle central et ne doit être utilisé que lorsque c'est inévitable.

Conseils pour accorder les privilèges

  • Principe du moindre privilège : Accordez toujours l'ensemble minimal de privilèges requis pour qu'un utilisateur ou une application fonctionne. Évitez ALL PRIVILEGES sauf pour un compte d'administrateur de base de données dédié.
  • Hôtes spécifiques : Limitez les connexions des utilisateurs à des adresses IP ou noms d'hôte spécifiques ('user'@'192.168.1.10' ou 'user'@'serveurapp.exemple.com') plutôt que '%' lorsque c'est possible.
  • Utilisateurs séparés : Créez des comptes utilisateur distincts pour différentes applications ou services, même s'ils accèdent à la même base de données. Cela isole les potentielles failles de sécurité.
  • Pas de root pour les applications : N'utilisez jamais le compte utilisateur root pour vos applications. Créez des utilisateurs dédiés avec le moindre privilège.

La commande REVOKE : Révoquer les privilèges efficacement

La commande REVOKE est utilisée pour supprimer des privilèges d'un utilisateur MySQL. Elle est tout aussi importante que GRANT pour maintenir un environnement de base de données sécurisé, surtout lorsque les rôles changent ou que des applications sont désaffectées.

Syntaxe de base

La syntaxe générale de la commande REVOKE est :

REVOKE privileges ON object FROM 'user'@'host';
  • privileges : Une liste de privilèges à révoquer, séparés par des virgules.
  • object : La portée depuis laquelle révoquer (doit correspondre à la portée où les privilèges ont été accordés).
  • 'user'@'host' : Le compte utilisateur dont révoquer les privilèges.

Exemples pratiques

  1. Révoquer le privilège DELETE d'un utilisateur d'application

    Si une application n'a plus besoin de supprimer des données, ou si vous souhaitez réduire ses permissions.

    REVOKE DELETE ON `ma_base_app`.* FROM 'utilisateur_app'@'localhost';

    Désormais, utilisateur_app peut toujours SELECT, INSERT et UPDATE, mais ne peut pas DELETE dans ma_base_app.

  2. Révoquer GRANT OPTION d'un administrateur délégué

    Si admin_base n'a plus besoin de gérer les permissions des autres utilisateurs pour base_inventaire.

    REVOKE GRANT OPTION ON `base_inventaire`.* FROM 'admin_base'@'localhost';

    Remarque : Pour révoquer GRANT OPTION, vous devez explicitement spécifier GRANT OPTION dans l'instruction REVOKE.

  3. Révoquer tous les privilèges sur une base de données spécifique

    Pour supprimer tous les privilèges qu'un utilisateur a sur une base de données particulière.

    REVOKE ALL PRIVILEGES ON `ancienne_base`.* FROM 'ancienne_app'@'%';

    Avertissement : REVOKE ALL PRIVILEGES sur *.* révoquera tous les privilèges globaux, ce qui peut inclure SUPER, CREATE USER, etc. Soyez prudent lorsque vous utilisez cette portée globalement.

  4. Supprimer un compte utilisateur

    Lorsqu'un utilisateur ou une application n'est plus nécessaire, il est préférable de supprimer complètement l'utilisateur.

    DROP USER 'outil_rapport'@'%';

    Cette commande supprime l'utilisateur et tous ses privilèges associés.

Conseils pour révoquer les privilèges

  • Correspondance de la portée : Lors de la révocation, assurez-vous que la portée de l'objet (*.*, nom_base.*, etc.) correspond exactement à la façon dont le privilège a été initialement accordé. Si vous avez accordé SELECT sur nom_base.*, vous devez le révoquer depuis nom_base.*, pas nom_base.nom_table.
  • Vérifiez : Utilisez toujours SHOW GRANTS FOR 'user'@'host'; après avoir accordé ou révoqué des privilèges pour confirmer les modifications.
  • Évitez les vidages inutiles : FLUSH PRIVILEGES n'est pas nécessaire après GRANT, REVOKE, CREATE USER ou DROP USER ; MySQL applique ces instructions immédiatement.
  • Considérez les effets en cascade : Si un utilisateur avec GRANT OPTION a accordé des privilèges à d'autres, révoquer son GRANT OPTION ne révoque pas automatiquement les privilèges qu'il a accordés. Vous devrez les révoquer séparément.

Bonnes pratiques pour la gestion des privilèges des utilisateurs MySQL

Implémenter une stratégie robuste de gestion des privilèges est crucial pour la sécurité de la base de données.

1. Principe du moindre privilège (PoLP)

C'est la règle d'or. Accordez uniquement les privilèges minimum absolus nécessaires pour qu'un utilisateur ou une application remplisse sa fonction prévue. Par exemple :

  • Un outil de reporting a besoin de SELECT.
  • Une application web a généralement besoin de SELECT, INSERT, UPDATE, DELETE.
  • Un processus ETL pourrait avoir besoin de INSERT, UPDATE, DELETE, CREATE TABLE, DROP TABLE (mais seulement sur des schémas de staging spécifiques).

2. Comptes utilisateur dédiés

  • Évitez les comptes partagés : Chaque application, service ou utilisateur administratif doit avoir son propre compte utilisateur MySQL unique. Cela facilite l'audit et le suivi des activités.
  • Pas de root pour les applications : Ne configurez jamais vos applications pour se connecter en tant qu'utilisateur root. L'utilisateur root a un accès illimité et ne doit être utilisé que pour des tâches administratives critiques par des administrateurs humains.

3. Mots de passe forts et rotation des mots de passe

  • Imposez des mots de passe forts et uniques pour tous les comptes utilisateur MySQL. Utilisez les plugins de validation de mot de passe de MySQL si disponibles.
  • Mettez en œuvre une politique de rotation régulière des mots de passe, surtout pour les comptes hautement privilégiés.

4. Restrictions d'hôte

  • Limitez les connexions des utilisateurs à des adresses IP ou noms d'hôte spécifiques lorsque c'est possible. Remplacez '%' par localhost, l'IP d'un serveur d'application ou un sous-réseau ('user'@'192.168.1.%'). Cela empêche les tentatives d'accès non autorisées depuis des emplacements inconnus.

5. Audits et révisions réguliers

  • Examinez périodiquement tous les comptes utilisateur et leurs privilèges associés. Supprimez les comptes obsolètes ou les privilèges inutiles.
  • Utilisez SHOW GRANTS FOR 'user'@'host'; pour inspecter les permissions.
  • Envisagez des outils automatisés pour auditer les grands environnements.

6. Documentez les permissions

  • Maintenez une documentation claire de vos utilisateurs de base de données, de leurs rôles et des privilèges accordés à chacun. Cela aide à maintenir la cohérence et facilite les audits de sécurité.

7. Séparez les environnements de développement, de staging et de production

  • N'utilisez jamais les identifiants de production dans les environnements de développement ou de staging. Chaque environnement doit avoir son propre ensemble d'utilisateurs et de privilèges distincts.

8. Évitez GRANT OPTION sauf si absolument nécessaire

  • Accorder WITH GRANT OPTION délègue la gestion des privilèges à cet utilisateur, ce qui peut contourner les politiques de sécurité centrales. Réservez cela aux utilisateurs administratifs hautement fiables uniquement et sur la portée la plus restrictive possible.

Voir les privilèges actuels

Pour vérifier les privilèges attribués à un utilisateur, utilisez la commande SHOW GRANTS :

SHOW GRANTS FOR 'nom_utilisateur'@'hôte';

Exemple :

SHOW GRANTS FOR 'utilisateur_app'@'localhost';

La sortie pourrait ressembler à :

+-------------------------------------------------------------+
| Grants for utilisateur_app@localhost                        |
+-------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'utilisateur_app'@'localhost'         |
| GRANT SELECT, INSERT, UPDATE ON `ma_base_app`.* TO 'utilisateur_app'@'localhost' |
+-------------------------------------------------------------+

La ligne GRANT USAGE ON *.* indique que l'utilisateur n'a aucun privilège global, seulement la capacité de se connecter.

À retenir

Gardez la gestion des privilèges MySQL étroite et vérifiable. Créez des comptes dédiés, restreignez les hôtes, accordez uniquement les actions nécessaires sur la plus petite portée utile, et vérifiez chaque changement avec SHOW GRANTS. Lorsqu'une application ou une personne n'a plus besoin d'accès, révoquez le privilège ou supprimez le compte au lieu de laisser des identifiants obsolètes derrière.