MariaDB sur Debian 13 : installer, sécuriser et créer les comptes

MariaDB est un système de gestion de bases de données relationnelles (SGBD) libre, issu de MySQL et compatible avec lui : c'est le SGBD que Debian installe quand une application demande « MySQL ». GLPI, Zabbix, Nextcloud ou WordPress y rangent leurs données. Ce chapitre installe MariaDB 11.8 sur Debian 13, sécurise le compte root, crée la base et le compte d'une application selon le principe du moindre privilège, ouvre un accès réseau chiffré pour un outil de tableaux de bord, puis montre comment sauvegarder et dépanner.

Installer MariaDB 11.8

Sur srv-glpi, qui accueillera la base de GLPI :

sudo apt install mariadb-server
systemctl status mariadb --no-pager
mariadb --version
# mariadb from 11.8.x-MariaDB, client 15.2 for debian-linux-gnu (x86_64) …

MariaDB 11.8 est une version maintenue à long terme (LTS) par la fondation MariaDB. Les commandes portent le nom mariadb (mariadb, mariadb-dump, mariadb-admin) ; les anciens noms en mysql ne sont plus que des alias de compatibilité, à ne plus utiliser dans tes scripts. Le langage SQL et les commandes CREATE USER ou GRANT sont ceux du cours SQL, écrit pour MySQL : un encadré y signale les rares différences avec MariaDB.

Par défaut, Debian fait écouter MariaDB sur 127.0.0.1 seulement, port TCP 3306 : la base n'est joignable que depuis la machine elle-même. C'est le bon réglage tant qu'aucune autre machine n'en a besoin.

ss -tlnp | grep 3306
# LISTEN 0  80  127.0.0.1:3306  0.0.0.0:*  users:(("mariadbd",pid=1027,fd=21))

Se connecter en root sans mot de passe

sudo mariadb

Aucun mot de passe n'est demandé, et c'est voulu. Sous Debian, le compte root@localhost de MariaDB utilise l'authentification par socket Unix (unix_socket) : MariaDB demande au système quel utilisateur Linux est à l'autre bout du socket, et n'accepte root que si c'est le root du système. Personne ne peut donc se connecter en root à la base sans être déjà administrateur du serveur, et il n'existe aucun mot de passe de root à voler, à oublier ou à écrire dans un script.

SELECT User, Host, plugin FROM mysql.user;

+-------------+-----------+-----------------------+
| User        | Host      | plugin                |
+-------------+-----------+-----------------------+
| mariadb.sys | localhost | mysql_native_password |
| root        | localhost | mysql_native_password |
| mysql       | localhost | mysql_native_password |
+-------------+-----------+-----------------------+

La colonne plugin de la vue mysql.user est trompeuse : interroge plutôt SHOW GRANTS FOR 'root'@'localhost';, qui affiche IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socket. Le mot de passe invalid ne correspond à aucun mot de passe possible : seule l'authentification par socket fonctionne. Le compte mysql@localhost a le même fonctionnement, pour le compte système mysql ; mariadb.sys est un compte interne verrouillé.

Sécuriser l'installation

Le script mariadb-secure-installation passe en revue les réglages dangereux d'une installation neuve :

sudo mariadb-secure-installation

Sur une Debian neuve, plusieurs de ces points sont déjà réglés ; le script ne fait alors rien de plus. Lance-le quand même : c'est un geste qu'on attend de toi en recette, et il te protège si quelqu'un a modifié les comptes avant toi.

Créer la base et le compte d'une application

Chaque application a sa base et son compte, qui n'a de droits que sur cette base. Pour GLPI :

-- sudo mariadb
CREATE DATABASE glpi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'glpi'@'localhost' IDENTIFIED BY 'Mot-De-Passe-Long-Et-Unique';
GRANT ALL PRIVILEGES ON glpi.* TO 'glpi'@'localhost';
-- GLPI lit les fuseaux horaires dans la base système
GRANT SELECT ON mysql.time_zone_name TO 'glpi'@'localhost';

utf8mb4 est le vrai UTF-8 de MariaDB : il stocke tous les caractères, émojis compris, contrairement à l'ancien utf8. Le compte est déclaré @'localhost' : il ne peut se connecter que depuis la machine, par le socket. GRANT ALL PRIVILEGES ON glpi.* lui donne tous les droits sur la base glpi seulement, dont la création et la modification de tables, dont GLPI a besoin pour s'installer et se mettre à jour. Il n'a aucun droit sur les autres bases, ni sur la gestion des comptes (GRANT OPTION), ni sur les fichiers du serveur (FILE).

Vérifie :

mariadb -u glpi -p -e "SHOW GRANTS;"

Le mot de passe du compte applicatif se génère, il ne s'invente pas :

openssl rand -base64 24

Il est écrit une seule fois, dans le fichier de configuration de l'application, lisible seulement par le compte qui l'exécute, et rangé dans le gestionnaire de mots de passe de l'équipe.

Donner le moins de droits possible

ALL PRIVILEGES sur sa base convient à une application qui gère elle-même son schéma. Pour les autres usages, on donne seulement ce qu'il faut :

Ouvrir un accès réseau, chiffré et restreint

L'équipe veut afficher dans Grafana, sur srv-journaux (192.168.10.180), le nombre de tickets ouverts par catégorie, lu directement dans la base de GLPI. Trois choses changent : MariaDB doit écouter sur le réseau, un compte doit exister pour cette adresse, et la connexion doit être chiffrée.

1. L'adresse d'écoute. Crée /etc/mysql/mariadb.conf.d/60-sorbier.cnf plutôt que de modifier le fichier de Debian, que les mises à jour peuvent remplacer :

[mariadbd]
bind-address = 192.168.10.184
require_secure_transport = ON

require_secure_transport refuse toute connexion TCP qui n'est pas chiffrée en TLS ; les connexions locales par le socket restent possibles. Depuis la version 11.4, MariaDB active TLS sans configuration : s'il n'a pas de certificat, il en génère un autosigné au démarrage, et le client vérifie par défaut le certificat du serveur, à l'aide du mot de passe du compte (pour les méthodes d'authentification qui le permettent, comme mysql_native_password ou ed25519). Pour un service en production, installe plutôt un certificat signé par l'autorité interne (ssl_cert, ssl_key, ssl_ca dans la même section), obtenu comme au chapitre 6.

sudo systemctl restart mariadb
ss -tlnp | grep 3306
# LISTEN 0  80  192.168.10.184:3306  0.0.0.0:*  users:(("mariadbd",…))

2. Le compte, lié à l'adresse du client, avec les seuls droits utiles.

CREATE USER 'grafana_lecture'@'192.168.10.180'
    IDENTIFIED BY 'Autre-Mot-De-Passe-Long' REQUIRE SSL;
GRANT SELECT ON glpi.glpi_tickets TO 'grafana_lecture'@'192.168.10.180';
GRANT SELECT ON glpi.glpi_itilcategories TO 'grafana_lecture'@'192.168.10.180';
GRANT SELECT ON glpi.glpi_entities TO 'grafana_lecture'@'192.168.10.180';

Le compte ne peut se connecter que depuis srv-journaux, en TLS, et ne lit que trois tables. Il ne voit pas la table glpi_users, qui contient les empreintes des mots de passe des comptes locaux de GLPI. Un GRANT SELECT ON glpi.* aurait été plus simple, et beaucoup trop large.

3. Le pare-feu local n'accepte le port 3306 que de cette adresse (le pare-feu nftables est configuré au chapitre 13) :

ip saddr 192.168.10.180 tcp dport 3306 accept

Le test, depuis srv-journaux :

mariadb -h srv-glpi.ad.sorbier.example -u grafana_lecture -p glpi \
  -e "SELECT COUNT(*) FROM glpi_tickets WHERE status < 5;"
mariadb -h srv-glpi.ad.sorbier.example -u grafana_lecture -p -e "\s" | grep -i ssl
# SSL:                    Cipher in use is TLS_AES_256_GCM_SHA384

Les deux serveurs sont dans le même VLAN : ce flux ne traverse pas le pare-feu pfSense, et le filtrage local de srv-glpi est la seule barrière entre eux. Ne l'oublie pas.

Sauvegarder et restaurer une base

mariadb-dump produit une sauvegarde logique : un fichier SQL qui recrée les tables et leurs données. Pour une base InnoDB comme celle de GLPI, l'option --single-transaction prend une image cohérente de la base sans bloquer l'application.

sudo mariadb-dump --single-transaction --routines --triggers --events glpi \
  | gzip > /var/backups/glpi-$(date +%F).sql.gz

La restauration se fait dans une base vide :

sudo mariadb -e "CREATE DATABASE glpi_test CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
gunzip -c /var/backups/glpi-2026-10-21.sql.gz | sudo mariadb glpi_test

Restaurer dans une base de test, et non dans la base de production, permet de vérifier la sauvegarde sans rien risquer : une sauvegarde qu'on n'a jamais restaurée n'est qu'un espoir. Pour une grosse base, mariadb-backup fait une sauvegarde physique (une copie des fichiers de données, cohérente), plus rapide à restaurer. La planification, la rétention, la copie hors du serveur et le test de restauration sont l'objet du cours Sauvegarde, PCA et PRA ; le chapitre 9 envoie ces fichiers sur un partage NFS.

Dépanner une connexion

sudo mariadb-admin status
# Uptime: 86400  Threads: 3  Questions: 51234  Slow queries: 0  Opens: 312 …
sudo mariadb -e "SHOW PROCESSLIST;"

Exercices

CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'Mot-De-Passe-Genere-1';
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';

CREATE USER 'rapport'@'192.168.10.209' IDENTIFIED BY 'Mot-De-Passe-Genere-2' REQUIRE SSL;
GRANT SELECT ON zabbix.hosts TO 'rapport'@'192.168.10.209';