Un dossier de succession, un contrat de vente immobilière, une procédure de divorce : les pièces jointes déposées via un formulaire sécurisé sur le site d’un cabinet d’avocats contiennent des informations dont la confidentialité engage directement la responsabilité professionnelle du cabinet. Le constat de départ de ce dossier est simple : ces fichiers étaient stockés en clair dans wp-content/uploads, comme n’importe quel média de site vitrine.
Le chiffrement au repos répond à une menace précise, différente de celle couverte par le TLS ou par les sauvegardes chiffrées : un accès direct au disque du serveur, que ce soit par une compromission du serveur lui-même ou par un accès physique à une machine mal sécurisée chez un hébergeur peu rigoureux.
Pourquoi ne pas chiffrer au niveau applicatif
Une première piste envisagée consistait à chiffrer les fichiers directement depuis WordPress, via une extension ou du code personnalisé, avant l’écriture sur le disque. Cette approche a été écartée : elle complique l’affichage et le téléchargement des fichiers pour les utilisateurs légitimes, introduit un point de défaillance supplémentaire côté PHP, et ne protège pas les autres fichiers sensibles du serveur qui ne transitent pas par WordPress, comme les journaux applicatifs.
Le choix retenu : un volume LUKS dédié
La solution retenue s’appuie sur LUKS (Linux Unified Key Setup), qui chiffre un volume entier au niveau du système de fichiers, de façon totalement transparente pour WordPress une fois le volume monté. Un volume distinct, séparé de la partition système, a été créé spécifiquement pour héberger le dossier des pièces jointes sensibles.
cryptsetup luksFormat /dev/sdb1
cryptsetup open /dev/sdb1 volume_dossiers_clients
mkfs.ext4 /dev/mapper/volume_dossiers_clients
mount /dev/mapper/volume_dossiers_clients /var/www/dossiers-clients
Le dossier wp-content/uploads/dossiers-clients a ensuite été remplacé par un lien symbolique pointant vers ce volume monté, de sorte que WordPress continue d’écrire au même emplacement logique, sans avoir conscience du chiffrement sous-jacent.
Le point délicat : le déverrouillage au démarrage
Un volume LUKS chiffré nécessite une phrase de passe ou une clé pour être monté après chaque redémarrage du serveur. Automatiser entièrement ce déverrouillage, par exemple avec un fichier de clé stocké sur le même disque, réduit fortement l’intérêt du chiffrement : en cas de vol du disque, la clé serait accessible avec les données elles-mêmes.
- Clé de déverrouillage stockée sur un support distinct du volume chiffré
- Script de démarrage qui échoue explicitement si le volume ne peut pas être monté, plutôt que de démarrer WordPress sans ce dossier
- Alerte envoyée à l’équipe technique en cas d’échec de montage au redémarrage
Un chiffrement dont la clé de déverrouillage se trouve à côté des données chiffrées ne protège que contre un vol de disque isolé, jamais contre une compromission plus large du serveur. Le compromis entre automatisation et sécurité doit être assumé explicitement, pas subi par défaut.
Ce que ce dispositif ne couvre pas
Le chiffrement au repos ne protège pas les fichiers pendant qu’ils sont lus par PHP pour être servis au navigateur : à ce moment-là, ils transitent en clair en mémoire, comme n’importe quel fichier. Il ne remplace pas non plus un contrôle d’accès applicatif rigoureux : sans vérification correcte des permissions côté WordPress, un utilisateur non autorisé pourrait toujours accéder aux fichiers via le site lui-même, indépendamment du chiffrement du disque.
Les sauvegardes, un sujet traité séparément
Ce dossier ne couvre volontairement pas le chiffrement des sauvegardes elles-mêmes, qui pose des questions différentes en matière de gestion des clés sur le long terme et de conservation hors site. Le volume LUKS mis en place protège les données en production, mais une sauvegarde exportée vers un stockage externe doit faire l’objet d’un chiffrement propre, avec sa propre gestion de clés.
Ce que ce dossier retient
Mettre en place un chiffrement au repos pour des données réellement sensibles reste une opération accessible techniquement, mais qui demande d’accepter un compromis assumé entre automatisation du démarrage et niveau de protection réel. Sur ce dossier, le choix d’un échec explicite plutôt qu’un contournement silencieux du chiffrement a été jugé préférable, y compris au prix d’une intervention manuelle en cas d’incident au redémarrage du serveur.
