MySQL : créer un utilisateur et gérer les droits

Créer un utilisateur MySQL proprement consiste à définir le couple exact utilisateur-hôte, choisir l’authentification compatible, imposer TLS si la connexion traverse le réseau, puis accorder seulement les opérations nécessaires sur la bonne base. Contrôlez ensuite le résultat avec SHOW GRANTS avant de donner les identifiants à l’application.

Commencer par le vrai nom du compte

Dans MySQL, le nom seul ne suffit pas à identifier un compte. Le nom complet est formé de l’utilisateur et de l’origine autorisée : ‘app_reader’@’localhost’, ‘app_reader’@‘10.20.0.15’ ou ‘app_reader’@‘10.20.0.%’. Omettre la partie hôte revient à utiliser %, donc toutes les origines susceptibles d’atteindre le serveur. C’est rarement le bon réglage initial.

Le pare-feu reste nécessaire : la partie hôte MySQL est un contrôle d’identité, pas un remplacement du filtrage réseau.

Créer le compte sans lui donner de droits

MySQL 8.4 choisit normalement caching_sha2_password. Laissez le serveur appliquer son plugin par défaut, sauf contrainte de compatibilité documentée et testée avec votre connecteur.

CREATE USER 'app_rw'@'10.20.0.15'
  IDENTIFIED BY 'mot-de-passe-long-et-unique'
  REQUIRE SSL;

Le compte est créé sans privilèges. REQUIRE SSL refuse une connexion qui ne chiffre pas le transport. Ne placez pas le vrai secret dans un dépôt, un ticket ou une commande conservée dans l’historique : injectez-le par le mécanisme de secrets de votre environnement.

mysql_native_password est déprécié et désactivé par défaut dans MySQL 8.4. Le réactiver pour un vieux client prolonge une dette de compatibilité. Mieux vaut mettre à niveau le connecteur et tester caching_sha2_password sur une liaison TLS.

Accorder le minimum utile

Accordez des opérations, pas un statut d’administrateur. Une application transactionnelle a souvent besoin de lire et modifier ses tables, mais pas de créer des utilisateurs, lire toutes les bases ou déléguer ses privilèges.

GRANT SELECT, INSERT, UPDATE, DELETE
ON app_prod.*
TO 'app_rw'@'10.20.0.15';

Un processus de reporting peut recevoir seulement SELECT :

CREATE USER 'report_ro'@'10.20.0.22'
  IDENTIFIED BY 'autre-secret-unique'
  REQUIRE SSL;

GRANT SELECT
ON app_prod.*
TO 'report_ro'@'10.20.0.22';

Évitez GRANT ALL ON . comme recette universelle. La portée . est globale : elle transforme une fuite de secret applicatif en incident sur tout le serveur. Même ALL sur une base est souvent plus large que le chemin normal de l’application.

Vérifier avant de livrer les identifiants

L’audit précède la livraison. SHOW GRANTS affiche les privilèges et rôles attribués :

SHOW GRANTS FOR 'app_rw'@'10.20.0.15';
SHOW CREATE USER 'app_rw'@'10.20.0.15';

La première commande valide la portée. La seconde permet de contrôler les propriétés du compte, notamment le plugin et les exigences TLS, sans recopier le mot de passe en clair.

Testez aussi depuis l’origine réelle. Un succès local ne prouve pas que le compte distant sélectionné est le bon : MySQL choisit la ligne de compte selon le couple utilisateur-hôte.

Changer le mot de passe ou les contraintes

La rotation ne doit pas reconstruire le compte. ALTER USER modifie le compte sans recréer ses privilèges. Pour changer le secret et maintenir TLS :

ALTER USER 'app_rw'@'10.20.0.15'
  IDENTIFIED BY 'nouveau-secret-unique'
  REQUIRE SSL;

Avant une rotation, vérifiez que l’application sait recharger le secret et prévoyez le retour arrière. Une rotation correcte possède deux preuves : la nouvelle connexion fonctionne et l’ancienne ne fonctionne plus.

Ne forcez un plugin avec IDENTIFIED WITH que si vous maîtrisez sa disponibilité côté serveur et côté client. L’étiquette technique est facile à changer ; la compatibilité du connecteur décide si l’application redémarre.

Retirer un droit sans supprimer le compte

Retirez une capacité sans supprimer l’identité. REVOKE retire précisément une capacité :

REVOKE DELETE
ON app_prod.*
FROM 'app_rw'@'10.20.0.15';

SHOW GRANTS FOR 'app_rw'@'10.20.0.15';

Il ne supprime pas le compte. C’est utile lorsqu’un service passe en lecture seule ou qu’une fonction disparaît. Attention aux droits cumulatifs : un privilège global reste valable même si vous l’omettez au niveau de la base. Commencez bas dans la hiérarchie, sinon le nettoyage devient un inventaire de cave.

Supprimer proprement un compte

Une suppression commence par l’inventaire des dépendances. Quand le service est retiré, contrôlez d’abord ses objets DEFINER, ses tâches et ses connexions, puis supprimez le compte :

DROP USER IF EXISTS 'app_rw'@'10.20.0.15';

DROP USER supprime le compte et ses privilèges, mais une session déjà ouverte n’est pas fermée automatiquement. La suppression prend effet pour cette session lorsqu’elle se termine. Les objets créés par l’ancien compte ne disparaissent pas non plus ; un DEFINER orphelin peut casser une vue ou une routine plus tard.

Choisir la bonne opération

Les commandes de gestion de comptes appliquent directement leurs changements. FLUSH PRIVILEGES n’est pas requis après CREATE USER, GRANT, REVOKE, ALTER USER ou DROP USER.

À conserver dans la fiche d’exploitation :

• le compte complet avec sa partie hôte ;
• la portée et la liste des privilèges ;
• le propriétaire de la rotation du secret ;
• les dépendances DEFINER avant suppression.

Si l’application doit être déplacée vers un autre serveur, traitez le nouveau couple utilisateur-hôte comme un changement d’accès, pas comme une simple copie de mot de passe. Pour isoler davantage la base et l’application, comparez aussi les options de VPS avant de mutualiser plusieurs charges sensibles.