Trois étapes — export, chiffrement, transfert — chacune vérifiée indépendamment : c’est la chaîne construite pour qu’une archive de sauvegarde ne reste jamais lisible en clair entre le moment où elle quitte la base de données et celui où elle arrive sur son stockage final. Pour une plateforme WordPress qui gère les espaces personnels des adhérents d’une mutuelle, avec des documents liés à des remboursements de soins, une sauvegarde non chiffrée, même transitoirement, représente une fenêtre d’exposition inacceptable. Cet article détaille cette chaîne complète, du script d’export jusqu’au stockage distant, sans aborder la conformité contractuelle avec l’assureur partenaire, qui relève d’un sujet juridique distinct.
La contrainte de départ est simple à énoncer mais exigeante à tenir : à aucun moment de la chaîne, un fichier de sauvegarde ne doit exister en clair en dehors du serveur de production lui-même.
Étape 1 : exporter la base sans jamais l’écrire en clair sur le disque final
L’export de la base de données utilise wp db export, mais le résultat est immédiatement redirigé vers l’étape de chiffrement, sans jamais reposer, même temporairement, sur un disque partagé ou un stockage réseau accessible à d’autres services :
wp db export - | gzip | openssl enc -aes-256-cbc -pbkdf2 \
-salt -pass file:/etc/mutuelle-backup/cle.key \
-out /var/backups/mutuelle-$(date +%Y%m%d-%H%M).sql.gz.enc
Le tiret après wp db export indique à WP-CLI d’écrire le résultat sur la sortie standard plutôt que dans un fichier intermédiaire, ce qui permet de chaîner directement la compression puis le chiffrement sans jamais matérialiser de version non chiffrée sur le disque.
Étape 2 : séparer strictement la clé de déchiffrement de l’archive
Le fichier cle.key référencé ci-dessus ne réside jamais dans le même espace de stockage que les archives chiffrées elles-mêmes. Il est conservé dans un gestionnaire de secrets distinct, accessible uniquement par le compte système dédié à l’exécution du script de sauvegarde, avec des droits de lecture strictement limités à ce seul usage. Une archive chiffrée accompagnée de sa propre clé, stockée au même endroit, n’offre en réalité aucune protection réelle : quiconque accède au stockage accède alors aux deux éléments nécessaires pour tout déchiffrer.
Étape 3 : transférer l’archive déjà chiffrée vers le stockage distant
Une fois l’archive chiffrée générée localement, son transfert vers le stockage distant se fait via une connexion elle-même chiffrée, ce qui ajoute une seconde couche de protection en transit, redondante avec le chiffrement du contenu mais nécessaire pour ne pas exposer, même indirectement, les métadonnées de la sauvegarde :
rclone copy /var/backups/mutuelle-$(date +%Y%m%d)*.sql.gz.enc \
stockage-distant:sauvegardes-mutuelle/ --sftp-set-modtime=false
Cette étape ne transfère jamais l’archive avant que le chiffrement de l’étape précédente ne soit confirmé terminé sans erreur, condition vérifiée explicitement dans le script par le code de sortie de la commande openssl.
Vérifier la chaîne complète, pas seulement l’export
Une chaîne de sauvegarde qui fonctionne à l’export mais dont personne n’a jamais testé la restauration reste une fausse sécurité. La procédure retenue impose un test de restauration mensuel, sur un environnement isolé, qui déchiffre une archive récente et vérifie l’intégrité du contenu restauré :
- Récupérer une archive récente depuis le stockage distant, sans jamais la déchiffrer sur le serveur de production lui-même.
- Déchiffrer et décompresser l’archive sur un environnement de test isolé, dédié à cette seule vérification.
- Importer le contenu restauré et vérifier un échantillon représentatif d’espaces personnels d’adhérents.
- Journaliser le résultat du test, avec la date et la personne ayant effectué la vérification.
Ce qui rendrait cette chaîne inefficace
| Erreur fréquente | Conséquence |
|---|---|
| Écrire l’export en clair avant chiffrement | Fenêtre d’exposition sur le disque local |
| Stocker la clé avec l’archive chiffrée | Chiffrement rendu inutile en cas de compromission |
| Ne jamais tester la restauration | Sauvegarde potentiellement inutilisable en cas d’incident réel |
La règle que nous imposons sur ce type de projet : une sauvegarde qui n’a jamais été restaurée avec succès sur un environnement de test ne compte pour rien, quelle que soit la qualité de son chiffrement.
En résumé
Chiffrer les sauvegardes d’une plateforme qui manipule des données de santé sensibles impose de traiter chaque maillon de la chaîne comme un point de vulnérabilité potentiel, depuis l’instant de l’export jusqu’au stockage final. Chaîner l’export, la compression et le chiffrement sans jamais matérialiser de version en clair, isoler strictement la clé de déchiffrement, et tester régulièrement la restauration : ce sont ces trois disciplines combinées qui transforment une sauvegarde chiffrée en une protection réellement fiable.
