Sécuriser une base de données

Une base de données mal réglée est l'une des causes d'incident les plus banales : un service qui écoute sur toutes les interfaces, une application connectée en administrateur, ou un export non chiffré copié sur un partage. Le risque ne vient pas d'une attaque sophistiquée, mais de ces trois écarts. Voici comment les constater et les corriger sur Debian 13, avec MariaDB et PostgreSQL.

Vérifier l'écoute réseau

Commencez par observer ce qui écoute réellement :

sudo ss -lntp | grep -E ':(3306|5432)\b'

Une sortie sur 0.0.0.0:3306 ou [::]:5432 signifie que la base accepte des connexions distantes. Une application locale n'a aucune raison d'être joignable depuis Internet.

Redémarrez le service (sudo systemctl restart mariadb ou postgresql@17-main), puis vérifiez que le port n'écoute plus que sur la boucle locale. Ajoutez une règle de pare-feu en refus explicite : sudo ufw deny 3306/tcp ou sudo ufw deny 5432/tcp. Si vous devez ouvrir la base à un autre serveur, limitez la source à son adresse et imposez TLS.

Réduire les privilèges

L'application ne doit jamais se connecter avec root ou postgres. Créez un compte dédié, avec un mot de passe long et unique :

CREATE DATABASE appdb;
CREATE USER 'app'@'localhost' IDENTIFIED BY 'mot-de-passe-fort';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'app'@'localhost';
FLUSH PRIVILEGES;

Accordez les droits suivants un par un (CREATE, ALTER, INDEX) quand une migration en a besoin, pas avant. Côté PostgreSQL :

CREATE ROLE app LOGIN PASSWORD 'mot-de-passe-fort';
CREATE DATABASE appdb OWNER app;
REVOKE ALL ON SCHEMA public FROM PUBLIC;

Le propriétaire d'une base n'est pas un superutilisateur : c'est suffisant pour l'application. Contrôlez le résultat avec SHOW GRANTS FOR 'app'@'localhost'; ou \du app.

Chiffrer les échanges et les sauvegardes

Sur la boucle locale, le socket Unix suffit. Dès qu'une connexion traverse le réseau, activez TLS : require_secure_transport=ON côté MariaDB, ssl=on et une ligne hostssl dans pg_hba.conf côté PostgreSQL. Utilisez un certificat dédié, pas celui du site web.

Les sauvegardes contiennent les mêmes données sensibles. Chiffrez-les avant de les sortir du serveur :

mysqldump --single-transaction --routines appdb | age -r AGE_PUBLIC_KEY -o appdb.sql.age
pg_dump -Fc appdb | age -r AGE_PUBLIC_KEY -o appdb.dump.age

Conservez la clé privée ailleurs que sur la machine sauvegardée, et testez une restauration avant d'en dépendre. Le disque du VPS est un conteneur système : LUKS sur la racine n'est pas disponible. Compensez par des sauvegardes chiffrées et, pour les colonnes très sensibles, par un chiffrement applicatif.

Vérification

Depuis une autre machine, une connexion au port 3306 ou 5432 doit expirer ou être refusée. Sur le serveur, contrôlez l'écoute, les droits et les comptes :

sudo ss -lntp | grep -E ':(3306|5432)\b'
sudo mariadb -e "SHOW GRANTS FOR 'app'@'localhost';"
sudo -u postgres psql -c "\du"

Restaurez un export chiffré sur un hôte de test. Après un départ ou une fuite, changez le mot de passe applicatif, révoquez l'ancien et vérifiez qu'aucune session ouverte ne subsiste.