Dix ans : c’est la durée de conservation imposée à certaines collectivités pour des archives incluant des données de délibérations publiques et des informations relatives aux administrés, une obligation qui pousse mécaniquement vers l’externalisation des sauvegardes, un hébergement local ne garantissant ni la pérennité ni la résilience nécessaires sur une telle durée.
Cette externalisation, souvent confiée à un prestataire spécialisé dans l’archivage à long terme, change la nature du risque associé aux sauvegardes WordPress : une base de données et un dossier wp-content/uploads qui quittent l’infrastructure maîtrisée de la collectivité pour transiter et séjourner chez un tiers, avec toutes les questions de confiance et de contrôle que cela soulève.
Pourquoi une sauvegarde non chiffrée reste une donnée exposée
Une sauvegarde de base de données WordPress contient, dans son intégralité, tout ce que la base contient en production : mots de passe hachés des utilisateurs, contenus de formulaires, métadonnées parfois sensibles selon les extensions installées, et pour une collectivité, potentiellement des informations relatives à des administrés (demandes de subvention, réclamations, données d’état civil selon les téléservices intégrés). Traiter cette sauvegarde comme un simple fichier d’archive, sans les mêmes protections que la base de production, revient à ignorer que le risque de fuite se déplace, mais ne disparaît pas, une fois le fichier transféré chez un tiers.
La checklist de chiffrement avant externalisation
- Chiffrer avant l’envoi, jamais après réception : le fichier doit quitter l’infrastructure de la collectivité déjà chiffré, de sorte que le prestataire de stockage ne manipule à aucun moment une version en clair, y compris de manière transitoire.
- Utiliser un chiffrement authentifié comme AES-256-GCM plutôt qu’un mode de chiffrement simple, pour détecter toute altération du fichier en plus d’en garantir la confidentialité.
- Séparer la clé de chiffrement du fichier chiffré : la clé ne doit jamais transiter ni être stockée aux côtés du fichier qu’elle protège, sous peine de rendre le chiffrement purement cosmétique.
- Documenter la procédure de restauration : une sauvegarde chiffrée dont la procédure de déchiffrement n’est connue que d’une seule personne constitue un risque opérationnel autant qu’un risque de sécurité.
- Tester une restauration complète périodiquement, chiffrement et déchiffrement inclus, pour vérifier que la chaîne fonctionne réellement au moment où elle sera nécessaire.
Chiffrer une archive WordPress avec des outils standards
Sur un serveur Linux, l’extension sodium, intégrée nativement à PHP depuis la version 7.2, permet de chiffrer une archive de sauvegarde directement depuis un script exécuté après la génération du dump SQL et de l’archive des fichiers :
$cle = sodium_hex2bin(getenv('BACKUP_ENCRYPTION_KEY'));
$contenu = file_get_contents('/var/backups/site-2021-03-07.tar.gz');
$nonce = random_bytes(SODIUM_CRYPTO_SECRETBOX_NONCEBYTES);
$chiffre = sodium_crypto_secretbox($contenu, $nonce, $cle);
file_put_contents(
'/var/backups/site-2021-03-07.tar.gz.enc',
$nonce . $chiffre
);Le nonce, bien que public par nature, est concaténé au début du fichier chiffré pour permettre le déchiffrement ultérieur, tandis que la clé BACKUP_ENCRYPTION_KEY reste stockée séparément, idéalement dans un coffre-fort de secrets distinct de l’infrastructure d’hébergement web elle-même.
Où stocker la clé, la vraie question difficile
Le chiffrement d’une sauvegarde ne vaut que par la protection de sa clé. Pour une collectivité, la bonne pratique consiste à séparer physiquement et organisationnellement la garde de la clé de celle du fichier chiffré : un exemplaire conservé par le responsable informatique de la collectivité, un second déposé auprès d’une autorité désignée en interne (direction générale des services, par exemple), sans jamais confier la clé au même prestataire qui héberge le fichier chiffré.
En résumé
L’obligation légale d’archivage à long terme d’une collectivité ne se limite pas à choisir un prestataire fiable pour l’externalisation : elle impose de traiter chaque sauvegarde comme une donnée aussi sensible que la base de production dont elle est issue, chiffrée avant tout transfert, avec une clé gérée séparément et une procédure de restauration testée régulièrement, plutôt qu’une confiance déléguée entièrement au prestataire de stockage.
