Sur un serveur mutualisé, une base de données n’est isolée que si sa configuration l’isole réellement — l’argument commercial de la « séparation des comptes » ne suffit pas à lui seul. C’est le constat qui a lancé cette mission : un cabinet de recouvrement de créances, hébergé chez un prestataire mutualisé classique aux côtés d’une dizaine d’autres sites clients du même revendeur, souhaitait une garantie technique vérifiable que sa base de données, contenant des dossiers de créances en cours, ne soit accessible depuis aucun autre compte du même serveur.
La conformité RGPD du traitement des créances lui-même — durée de conservation, base légale, droits des personnes concernées — relève d’un travail juridique distinct et n’est pas abordée ici. Le sujet se limite strictement à l’architecture technique d’isolation entre bases de données sur un serveur mutualisé partagé.
L’audit initial : quatre bases visibles depuis un compte tiers
Le point de départ de l’audit a consisté à se connecter avec les identifiants MySQL du cabinet et à lister les bases visibles avec SHOW DATABASES;. Résultat : quatre bases appartenant à d’autres sites clients du même hébergeur apparaissaient dans la liste, signe qu’un compte MySQL unique, partagé au niveau du serveur, disposait de droits SELECT hérités bien au-delà de sa propre base.
L’architecture cible
L’architecture retenue repose sur un principe simple à énoncer mais rarement appliqué avec rigueur : chaque base de données dispose de son propre utilisateur MySQL, disposant de droits limités à cette seule base, et connectable uniquement depuis l’hôte du serveur applicatif concerné.
-- Suppression des droits hérités trop larges
REVOKE ALL PRIVILEGES ON *.* FROM 'ancien_utilisateur'@'%';
-- Création d'un utilisateur dédié, limité à une base et un hôte précis
CREATE USER 'cabinet_recouvrement'@'127.0.0.1' IDENTIFIED BY 'mot_de_passe_genere';
GRANT SELECT, INSERT, UPDATE, DELETE
ON cabinet_recouvrement_db.*
TO 'cabinet_recouvrement'@'127.0.0.1';
FLUSH PRIVILEGES;Le détail qui change tout ici, souvent négligé, est le remplacement du caractère générique '%' comme hôte autorisé par une adresse précise : 127.0.0.1 lorsque le serveur applicatif et le serveur de base de données sont colocalisés, ou l’adresse IP interne exacte du serveur applicatif dans une architecture distribuée. Un utilisateur limité à une seule base mais accessible depuis n’importe quel hôte du réseau reste vulnérable si un autre compte du serveur venait à obtenir ce mot de passe.
Arborescence de l’isolation retenue
Serveur mutualisé
├── Compte cabinet_recouvrement
│ ├── Utilisateur MySQL : cabinet_recouvrement@127.0.0.1
│ ├── Base : cabinet_recouvrement_db (droits stricts)
│ └── Répertoire wp-content isolé (permissions 750, propriétaire dédié)
├── Compte site_client_a
│ ├── Utilisateur MySQL : site_client_a@127.0.0.1
│ └── Base : site_client_a_db (droits stricts, aucun croisement)
└── Compte site_client_b
├── Utilisateur MySQL : site_client_b@127.0.0.1
└── Base : site_client_b_db (droits stricts, aucun croisement)Isoler aussi le système de fichiers
L’isolation ne s’arrête pas à la base de données. Les permissions du répertoire wp-content ont également été revues : chaque compte cliente dispose d’un propriétaire système distinct, avec des permissions fixées à 750 plutôt qu’à 755, empêchant tout autre compte du même serveur de lire, même en lecture seule, le contenu du répertoire par simple navigation sur le système de fichiers partagé.
- Suppression de tout droit
GRANT OPTIONhérité, qui aurait permis à l’utilisateur de redistribuer lui-même ses propres droits à d’autres comptes. - Audit trimestriel des droits effectifs via
SHOW GRANTS FOR 'cabinet_recouvrement'@'127.0.0.1';, comparé à une référence documentée. - Chiffrement au repos activé sur la base, en complément de l’isolation d’accès, pour une couche de protection supplémentaire en cas de compromission du serveur lui-même.
- Sauvegardes chiffrées et stockées hors du serveur mutualisé, avec des droits d’accès distincts de ceux du serveur de production.
Un principe qu’on applique systématiquement sur ce type d’audit : une base n’est isolée que si on peut le démontrer avec une commande
SHOW GRANTS, jamais parce que le contrat d’hébergement l’affirme sur le papier.
Notre verdict
Sur un hébergement mutualisé, l’isolation entre comptes clients n’est jamais garantie par défaut de façon uniforme : elle dépend directement de la configuration des droits MySQL et des permissions du système de fichiers, souvent héritée d’une configuration ancienne jamais revue depuis la création du compte. Un audit régulier des droits GRANT effectifs, couplé à une architecture d’utilisateurs dédiés et restreints par hôte, reste la seule façon de transformer une promesse commerciale d’isolation en garantie technique vérifiable.
