Tutoriel Expert : Durcissement d'un Serveur MariaDB/MySQL

Introduction : Protéger le Cœur des Données

La base de données est la cible finale de nombreuses attaques. Une compromission peut entraîner des fuites de données catastrophiques. Ce guide expert couvre les quatre piliers de la sécurisation d'un serveur MariaDB/MySQL en production : l'isolation réseau, le chiffrement des communications, le durcissement des comptes et l'audit avancé.

Section 1 : Isolation Réseau - Réduire la Surface d'Attaque

La première règle est simple : si un attaquant ne peut pas atteindre le service, il ne peut pas l'attaquer. Par défaut, un serveur de base de données ne devrait jamais être exposé sur Internet.

• Option 1 (la plus sûre) : Désactiver le réseau. Si votre application et votre base de données sont sur le même serveur, forcez la communication via le socket Unix local. C'est la méthode la plus sécurisée.
  Dans votre fichier de configuration (/etc/mysql/mariadb.conf.d/50-server.cnf par exemple) :

  [mysqld]
  # Le serveur n'écoutera plus sur aucun port TCP/IP
  skip-networking

• Option 2 (la plus courante) : Écoute locale uniquement. Si votre application a besoin de se connecter via TCP (ex: si elle est dans un conteneur Docker sur le même hôte), forcez le serveur à n'écouter que sur l'interface de loopback.

  [mysqld]
  # Le serveur n'acceptera les connexions que depuis la machine elle-même
  bind-address = 127.0.0.1

• Couche de défense supplémentaire : le Pare-feu. Quelle que soit l'option choisie, configurez toujours votre pare-feu (voir le tutoriel `nftables`) pour bloquer explicitement le port 3306 depuis toute source externe.

Section 2 : Chiffrement des Communications avec TLS

Même en local, il est recommandé de chiffrer la communication entre votre application et la base de données pour se prémunir contre l'écoute du trafic sur le serveur. C'est obligatoire si la base de données est sur un serveur distant.

1. Générez ou obtenez des certificats SSL/TLS pour votre serveur.
2. Configurez le serveur MariaDB/MySQL pour utiliser TLS.

   [mysqld]
   # Chemins vers vos certificats
   ssl-ca = /etc/mysql/ssl/ca.pem
   ssl-cert = /etc/mysql/ssl/server-cert.pem
   ssl-key = /etc/mysql/ssl/server-key.pem
   

3. Forcez les utilisateurs à se connecter uniquement via TLS.

   -- Créer un utilisateur qui DOIT utiliser TLS
   CREATE USER 'mon_app'@'localhost' IDENTIFIED BY 'mot_de_passe_solide' REQUIRE SSL;
   
   -- Modifier un utilisateur existant
   ALTER USER 'mon_app'@'localhost' REQUIRE SSL;

Section 3 : Durcissement des Comptes et des Permissions

Le principe du moindre privilège est roi. Un compte compromis ne doit pas donner accès à toute la base.

• Forcer des mots de passe robustes : Utilisez le plugin `validate_password` (MySQL) ou `simple_password_check` (MariaDB) pour imposer des règles de complexité.

  # Pour MariaDB, dans my.cnf
  [mariadb]
  plugin_load_add = simple_password_check
  # Options : simple_password_check_...
  
  # Pour MySQL, installation
  INSTALL PLUGIN validate_password SONAME 'validate_password.so';
  

• Permissions granulaires : N'utilisez JAMAIS `GRANT ALL PRIVILEGES`. Créez des utilisateurs dédiés avec uniquement les droits nécessaires.

  # Un utilisateur pour une application web standard
  GRANT SELECT, INSERT, UPDATE, DELETE ON `ma_db`.* TO 'app_user'@'localhost';
  
  # Un utilisateur pour les sauvegardes, qui n'a besoin que de lire les données
  GRANT SELECT, LOCK TABLES ON `ma_db`.* TO 'backup_user'@'localhost';

Section 4 : Journalisation et Audit Avancé

Savoir qui a fait quoi, et quand, est essentiel pour l'analyse post-incident et la conformité.

• Le Plugin d'Audit de MariaDB (`server_audit`) : C'est l'outil le plus puissant pour une traçabilité complète. Il peut enregistrer les connexions (réussies et échouées), les requêtes, et bien plus, dans un fichier de log séparé.

  # Dans my.cnf, activez et configurez le plugin
  [mariadb]
  plugin_load_add = server_audit
  server_audit_events = CONNECT,QUERY,TABLE
  server_audit_logging = ON
  server_audit_file_path = /var/log/mysql/audit.log
  

• Slow Query Log : Bien qu'il serve à l'optimisation, le journal des requêtes lentes peut aussi aider à détecter des requêtes anormales ou des tentatives d'exfiltration de données massives.