7 meilleures pratiques de sécurité MySQL pour protéger votre base de données
Sept vérifications pratiques de sécurité MySQL pour le contrôle d'accès, l'exposition réseau, TLS, les correctifs, la journalisation et le chiffrement.
Top 7 des bonnes pratiques de sécurité MySQL pour protéger votre base de données
La sécurité MySQL commence par réduire qui peut se connecter, ce qu'ils peuvent faire, et ce qui est exposé si un hôte est compromis. Les sept vérifications ci-dessous vous donnent une base pratique pour les bases de données de production sans prétendre qu'un seul paramètre peut rendre MySQL "sécurisé".
1. Gestion sécurisée des accès utilisateurs
Contrôler qui peut accéder à votre base de données et ce qu'ils peuvent faire est la première ligne de défense. Cela implique de créer des comptes utilisateurs spécifiques avec le principe du moindre privilège, ce qui signifie que les utilisateurs ne doivent avoir que les permissions nécessaires pour effectuer leurs tâches.
Créer des comptes robustes
Évitez les utilisateurs d'application partagés et les mots de passe faibles. Utilisez mysql_secure_installation sur les serveurs auto-gérés pour supprimer les utilisateurs anonymes, supprimer la base de données de test le cas échéant, et renforcer la configuration initiale du compte root.
Accorder des privilèges minimaux
Utilisez les instructions GRANT pour la base de données, la table et les actions spécifiques dont votre application a besoin. Évitez ALL PRIVILEGES pour les comptes d'application.
Exemple :
CREATE USER 'webapp_user'@'10.0.10.%' IDENTIFIED BY 'utilisez-un-vrai-secret-ici';
GRANT SELECT, INSERT, UPDATE ON mydatabase.* TO 'webapp_user'@'10.0.10.%';
Vous n'avez pas besoin de FLUSH PRIVILEGES après les instructions normales CREATE USER ou GRANT. MySQL met à jour automatiquement les tables de privilèges pour ces instructions.
Auditez régulièrement les comptes :
SELECT user, host, account_locked FROM mysql.user ORDER BY user, host;
SHOW GRANTS FOR 'webapp_user'@'10.0.10.%';
2. Restreindre l'accès réseau
Limitez les chemins réseau vers MySQL. La valeur par défaut effective dépend de votre version et paquet MySQL, alors inspectez votre serveur en cours d'exécution au lieu de supposer qu'il écoute uniquement localement.
Vérifiez les écouteurs :
ss -ltnp | grep 3306
Liez MySQL à localhost lorsque seuls des clients locaux ont besoin d'accès :
[mysqld]
bind-address = 127.0.0.1
Si des serveurs d'application se connectent à distance, liez à l'interface privée et utilisez des groupes de sécurité, des pare-feu ou des ACL réseau pour autoriser uniquement ces sources sur le port 3306.
3. Utiliser TLS pour les connexions
Chiffrer les données en transit empêche l'écoute clandestine et les attaques de l'homme du milieu. MySQL prend en charge le chiffrement SSL/TLS pour les connexions client-serveur.
La configuration du serveur ressemble généralement à ceci :
[mysqld]
ssl-ca=/chemin/vers/ca.pem
ssl-cert=/chemin/vers/server-cert.pem
ssl-key=/chemin/vers/server-key.pem
Exemple client :
mysql -h votre_hote -u votre_utilisateur -p --ssl-mode=REQUIRED
Pour une vérification plus stricte, utilisez --ssl-mode=VERIFY_IDENTITY avec un nom d'hôte qui correspond au certificat. REQUIRED chiffre la connexion mais ne vérifie pas aussi fortement l'identité du serveur.
4. Maintenir MySQL à jour
Des vulnérabilités logicielles sont fréquemment découvertes et corrigées. Exécuter une version obsolète de MySQL peut exposer votre base de données à des exploits connus.
Suivez le flux de versions que vous exécutez, appliquez les mises à jour de sécurité et testez les mises à niveau en staging avant la production. Si vous utilisez un service de base de données géré, examinez la politique de maintenance du fournisseur et définissez une fenêtre de maintenance que votre équipe surveille réellement.
5. Renforcer la configuration du serveur MySQL
Au-delà de la liaison réseau, plusieurs autres options de configuration peuvent améliorer la sécurité.
Désactivez local_infile sauf si vos applications ont besoin de LOAD DATA LOCAL INFILE :
[mysqld]
local_infile = 0
Gardez les fichiers de configuration, les clés TLS et les informations d'identification de sauvegarde lisibles uniquement par les utilisateurs système appropriés. Examinez également les plugins installés et supprimez ceux que vous n'utilisez pas.
6. Auditer et surveiller les journaux
La journalisation est cruciale pour détecter les activités suspectes et pour l'analyse médico-légale après un incident de sécurité.
MySQL Enterprise inclut un plugin de journal d'audit. Les déploiements communautaires utilisent souvent les journaux du système d'exploitation, les journaux d'erreurs, les journaux de proxy, les fonctionnalités d'audit de base de données cloud ou des plugins d'audit tiers selon votre environnement.
Au minimum, surveillez :
- Les échecs de connexion et les erreurs d'authentification.
- Les nouveaux utilisateurs, les privilèges modifiés et les instructions privilégiées.
- Les connexions depuis des hôtes inattendus.
- Les échecs de travaux de sauvegarde et les échecs de tests de restauration.
Ne laissez pas le journal des requêtes générales activé sur un serveur de production occupé sauf si vous avez un besoin spécifique de dépannage à court terme. Il peut créer des E/S lourdes et peut capturer des valeurs de requêtes sensibles.
7. Sécuriser les données au repos
Bien que SSL/TLS protège les données en transit, le chiffrement des données au repos les protège si le stockage sous-jacent est compromis.
Utilisez le chiffrement du stockage ou du volume pour la ligne de base large. Pour les champs sensibles, envisagez un chiffrement au niveau de l'application afin que la base de données ne contienne pas tout ce qui est nécessaire pour déchiffrer les données.
MySQL dispose également de fonctions de chiffrement telles que AES_ENCRYPT() et AES_DECRYPT(), mais ne codez pas en dur les clés dans SQL ou ne les stockez pas à côté des données.
Exemple simplifié :
UPDATE users
SET sensitive_data = AES_ENCRYPT('info_privee_utilisateur', @cle_chiffrement)
WHERE user_id = 1;
SELECT AES_DECRYPT(sensitive_data, @cle_chiffrement)
FROM users
WHERE user_id = 1;
Utilisez un processus de gestion des clés approprié pour les systèmes réels. Le chiffrement sans rotation des clés, contrôle d'accès et sauvegardes du matériel de clé peut transformer un incident récupérable en une perte de données permanente.
À retenir
Commencez par les contrôles qui suppriment le plus de risques : utilisateurs à moindre privilège, accès réseau privé, TLS, correctifs et sauvegardes testées. Ajoutez ensuite la journalisation d'audit et les contrôles de chiffrement qui correspondent à votre modèle de conformité et de menace. Révisez la configuration après chaque changement majeur de schéma, d'infrastructure ou d'accès.