Quand on parle de “sécurité WordPress”, on pense souvent au durcissement du site, aux mises à jour et à la gestion des droits. Pourtant, dans beaucoup d’organisations, le maillon faible se trouve ailleurs: les sauvegardes. Pas seulement leur existence, mais leur capacité à être restaurées vite, sans surprises, et surtout sans que des tiers puissent en lire le contenu.
J’ai déjà vu une situation simple en apparence: un hébergeur annonçait des sauvegardes, un plugin faisait des exports, et tout semblait couvert. Le test de restauration a révélé un autre problème. Le chiffrage était bien “quelque part”, mais les clés étaient distribuées à plusieurs personnes, stockées de façon hétérogène (captures d’écran, documents partagés, notes locales), et personne n’avait une procédure claire pour retrouver la bonne clé pour le bon dump. Résultat, la restauration a pris des heures de plus que prévu, et l’incident est resté plus longtemps visible. Ce n’était pas une attaque spectaculaire, c’était une faiblesse de gouvernance.
L’objectif de cet article est de guider un audit pragmatique, orienté résultats, pour vérifier vos sauvegardes chiffrées et l’accès aux clés. On va parler de ce qu’il faut contrôler, de ce qui casse dans la vraie vie, et des arbitrages à prévoir.
Pourquoi l’audit des sauvegardes ne peut pas se limiter au “c’est chiffré”
Le chiffrement est une bonne idée, mais il ne sert à rien si la clé n’est pas récupérable au moment où vous en avez besoin. Une sauvegarde chiffrée se juge à trois niveaux.
D’abord, la sauvegarde elle-même: base de données, fichiers, éventuels objets externes (médias sur un stockage à part, cache, uploads, configurations). Ensuite, l’intégrité: on veut pouvoir vérifier que l’archive n’est pas corrompue. Enfin, la clé et la politique d’accès: qui peut déchiffrer, comment on la retrouve, et ce qui se passe si une personne quitte l’équipe ou si un outil tombe.
Sur WordPress, les sauvegardes “complètes” ne sont pas toujours complètes. Beaucoup d’installations ont des médias externalisés (S3 compatible, stockage CDN, stockage fournisseur). Si le chiffrage ne couvre que les dumps SQL et pas la couche média, la restauration peut sembler fonctionner au début, puis donner un site “vide” ou incomplet. À l’inverse, si vous chiffrez les uploads mais oubliez une partie des configurations, vous restaurez un WordPress cassé au premier démarrage.
C’est là que l’audit et sécurisation WordPress prend une dimension opérationnelle, au-delà des paramètres de sécurité visibles.
Définir le périmètre avant de toucher à quoi que ce soit
Avant de lancer des tests et d’ouvrir des exports, prenez dix minutes pour cadrer. Le plus fréquent, c’est de confondre sauvegarde et restauration.
Pour éviter les faux résultats, j’aime clarifier quatre points:
Quelles sauvegardes sont produites (database, fichiers, archives, instantanés). Où elles sont stockées (disque du serveur, stockage externe type S3, compte hébergeur, espace cloud). Comment elles sont chiffrées (chiffrement côté serveur, chiffrement applicatif, chiffrement au niveau du stockage). Comment on restaure (procédure documentée, automatisation, manuels, scripts, consoles).À ce stade, l’équipe apprend souvent qu’il y a plusieurs “sources de vérité”. Par exemple, l’hébergeur garde des snapshots, un plugin exporte la base et compresse les fichiers, et un autre outil exporte des sauvegardes vers un second endroit. Chacun a sa propre logique de rétention, de chiffrement et de clés.
Le but de l’audit n’est pas de tout remplacer immédiatement. C’est de savoir ce qui existe, ce qui est sûr, ce qui est fragile, et ce qui doit être clarifié.
Cartographier les flux: base de données, fichiers, médias et métadonnées
L’audit doit traiter le système comme un ensemble, pas comme “WordPress dans un dossier”.
Sur WordPress, les éléments structurants sont généralement:
- Base de données: tables WordPress, mais aussi tables d’extension (champs des formulaires, logs, paramètres de plugins). Fichiers WordPress: code, thèmes, plugins, fichiers de configuration. Uploads: souvent dans wp-content/uploads, parfois redirigés ou synchronisés vers un stockage externe. Fichiers de configuration: wp-config.php, variables d’environnement, secrets d’intégration. Données de plugins: certains plugins stockent des fichiers ou des configurations ailleurs, par exemple dans des répertoires spécifiques ou dans un stockage tiers.
Quand vous “chiffrez une archive”, il faut comprendre ce que contient réellement l’archive et ce qui est laissé en clair à côté.
Un cas courant: on chiffre les sauvegardes de la base, mais les médias sont stockés en clair dans un bucket externe. Si l’objectif est la confidentialité totale, ce point n’est pas secondaire. À l’inverse, un autre cas existe: les médias sont chiffrés au repos côté stockage, mais les dumps SQL ne le sont pas, ou pas systématiquement.
L’audit doit donc identifier les surfaces de données et vérifier où le chiffrement s’applique.
Chiffrer au bon endroit: ce que vous devez comprendre (et vérifier)
Il existe plusieurs schémas de chiffrement. On peut les considérer par “où se trouve la clé au moment du chiffrement”.
- Chiffrement côté serveur/hébergeur: le fournisseur gère souvent la couche de chiffrement. Vous n’avez pas toujours la maîtrise de la clé ni la certitude sur la procédure de restauration en cas de demande spécifique. Chiffrement applicatif: un plugin ou un outil chiffre avant envoi. La clé est généralement gérée côté instance ou via une configuration spécifique. Chiffrement au niveau du stockage: le stockage chiffre au repos. Mais la question devient: est-ce que vous savez comment restaurer si vous devez livrer un fichier déchiffré, et quel est le contrôle d’accès réel.
L’audit consiste à répondre à une question très concrète: si demain vous perdez la capacité de restaurer, qu’est-ce qui vous empêche de déchiffrer les sauvegardes?
Voici les signaux que je recherche pendant les audits:
- Les paramètres de chiffrement sont documentés, mais la clé est uniquement “dans la mémoire d’une personne”. Le chiffrement dépend d’une variable d’environnement qui n’est plus définie sur les machines actuelles. Les sauvegardes chiffrées changent de format entre versions (le plugin a évolué, le schéma de chiffrement aussi). Les archives peuvent être “déchiffrées”, mais pas validées, car on ne sait pas vérifier l’intégrité.
Le point important est l’alignement entre la capacité de restauration et la gestion des secrets.
Audit des sauvegardes: vérifier le contenu, l’intégrité et la cohérence
Un audit utile ressemble à un scénario d’incident, même si vous ne déclenchez rien d’explosif. Vous cherchez à prouver que les sauvegardes sont restaurables.
Commencez par contrôler les éléments accessibles sans risque:
- Vérifiez les tailles et la date des sauvegardes. Une sauvegarde de 2 Ko n’est pas “chiffrée”, c’est probablement un export incomplet. Contrôlez le format des archives (extensions, type de contenu, présence d’un manifeste). Certains outils déposent un fichier “index” et les archives séparément. Vérifiez la cohérence entre base et fichiers. Une restauration “mélangée” (dump SQL récent, fichiers plus anciens) peut produire un site qui démarre mais qui contient des incohérences, notamment dans les tables de plugins ou les références d’uploads.
Ensuite, l’intégrité. L’objectif n’est pas d’être cryptographe, mais de s’assurer que le chiffrement n’a pas masqué une corruption.
Selon les solutions, vous pouvez avoir des sommes de contrôle, des mécanismes d’upload atomiques, ou des checks intégrés. Si rien de tout cela n’existe, vous pouvez au minimum faire un test contrôlé de déchiffrement et de restauration dans un environnement isolé.
L’environnement de test est crucial. J’insiste sur un point que j’ai appris trop tard: restaurez sur une machine ou un environnement qui n’a aucun accès direct à la production, afin d’éviter toute confusion de secrets ou d’identité.
Clés d’accès et gestion des secrets: le vrai cœur du problème
L’audit des clés d’accès doit être traité comme une discipline à part entière. Une clé, ce n’est pas juste “un mot de passe”. C’est un contrat: elle doit être disponible, stable, et protégée, avec une politique de rotation et de révocation.
Commencez par lister ce qui permet le déchiffrement et l’accès aux sauvegardes:
- Clé(s) de chiffrement applicatif (passphrase, clé de chiffrement, clé par tenant, clé dérivée). Identifiants d’accès au stockage (compte, clés API, rôles). Variables d’environnement ou secrets utilisés par l’outil de sauvegarde. Permissions sur le lieu de stockage (bucket, dossier, partage). Éventuels mécanismes d’authentification intermédiaire (accès via SSO, accès temporaire, jetons).
Le danger classique, c’est la dispersion. J’ai vu une équipe partager une phrase secrète via un outil de chat “juste pour dépanner”, puis oublier de la retirer. Le risque n’est pas seulement le vol. C’est aussi la traçabilité https://gardewp.fr/securite-wordpress/ et l’auditabilité: vous ne pouvez pas prouver qui savait quoi, et à quelle date.
Dans un audit, vous voulez des réponses claires sur trois questions:
- Où la clé est stockée (coffre, variables d’environnement centralisées, fichier local, documentation). Qui y a accès et comment ce sont gérées les sorties de personne (désactivation d’accès). Quelle est la procédure de rotation et si elle est compatible avec vos sauvegardes existantes (les clés rotatives cassent parfois l’accès aux anciennes archives si le système ne garde pas le mapping).
Exemple concret de test de restauration chiffrée (sans écrire un roman)
Lors d’un audit, j’ai proposé un test en deux temps, assez simple pour être réalisable sans immobiliser l’équipe.
1) On a pris une sauvegarde chiffrée récente, on a récupéré l’archive, puis on a lancé le déchiffrement dans un environnement de staging. 2) Une fois déchiffré, on a vérifié le contenu attendu, puis on a restauré dans une base et des fichiers “vierges”.
Ce qui a révélé le problème n’était pas un bug technique. C’était une inconsistance dans la procédure: la clé était stockée dans un coffre, mais le coffre était référencé par une page différente de celle utilisée par l’outil de sauvegarde. Pendant une restauration réelle, l’équipe aurait cherché au mauvais endroit. Le test a permis de corriger la documentation et d’aligner la source de vérité.
Ce genre de “friction de process” est fréquent. Les sauvegardes peuvent être parfaitement chiffrées et quand même ne pas être restaurables rapidement, parce que la clé est difficile à retrouver.
Contrôles à mener pendant l’audit (checklist courte)
Voici les contrôles que je mène systématiquement. Ils sont courts, mais chaque point correspond à un risque réel.
- Identifier tous les mécanismes de sauvegarde actifs (hébergeur, plugins, scripts, stockage externe) et le contenu réel produit. Vérifier le chiffrement sur chaque type de données (base, fichiers, uploads, configurations), pas uniquement “sur l’archive”. Tester un déchiffrement et une restauration dans un environnement isolé avec des données de test. Auditer la provenance et l’emplacement des clés (coffre, variables, documentation partagée) et la liste des personnes habilitées. Valider la procédure en cas de rotation ou de perte d’accès (qui fait quoi, et en combien de temps).
Si vous faites déjà une partie de ces points, l’audit n’est pas “un travail supplémentaire”, c’est un moyen de rendre la sécurité démontrable.
Accès au stockage: permissions, périmètres et chiffrement au repos
Même si vos archives sont chiffrées avant envoi, l’accès au stockage compte. Un fichier chiffré peut rester confidentiel, mais la disponibilité dépend des permissions, et la restauration dépend souvent d’un ensemble d’accès.
Pensez en “principe du moindre privilège”. Les identifiants utilisés pour la sauvegarde ne devraient pas pouvoir faire autre chose. Idéalement:
- le rôle d’upload ne supprime pas des objets existants sans raison, le rôle de lecture ne peut pas modifier les archives, les clés sont limitées à un bucket ou à un préfixe précis.
Un autre aspect est la gestion de la restauration. Beaucoup d’outils restaurent en téléchargeant l’archive chiffrée puis en la déchiffrant localement. Si les permissions de lecture ne sont pas alignées, vous pouvez vous retrouver avec une confidentialité intacte mais une restauration impossible.
Enfin, le chiffrement au repos dans le stockage peut vous aider, mais ne remplace pas la gestion de vos clés applicatives. Si vous chiffrez côté application, vous devez vérifier que la restauration utilise bien les clés applicatives, pas une logique “implicite” qui dépend de la configuration du stockage.
Politique de rotation des clés: ce qui doit être décidé en amont
La rotation des clés est un sujet délicat. En théorie, elle réduit la fenêtre de risque. En pratique, elle peut briser l’accès aux sauvegardes existantes, selon la manière dont le système stocke les clés.
Deux cas se rencontrent souvent:
- Chiffrement avec une clé unique: rotation rare, mais procédure de remplacement claire. Les anciennes archives restent déchiffrables avec la même clé. Chiffrement avec clés par période: rotation régulière, mais il faut conserver l’association “archive de telle date” vers “clé correspondante”, et cette association doit elle-même être protégée.
Pendant un audit, il faut poser la question suivante: si on tourne la clé demain, est-ce qu’on peut restaurer les sauvegardes de la semaine dernière? Si la réponse est “non”, il faut le savoir et documenter une compensation, par exemple une ré-archivage ou un mécanisme d’archivage des clés.
Le trade-off est réel. Plus vous multipliez les rotations, plus vous augmentez la complexité opérationnelle. Et c’est cette complexité qui se transforme en erreur pendant un incident.
Où les audits trébuchent le plus souvent
Dans mes retours terrain, les problèmes reviennent avec une régularité qui en dit long sur les “angles morts”:
- Les sauvegardes chiffrées “existent”, mais le déchiffrement échoue faute de clé au format attendu (espaces, encodage, passage de paramètres dans l’outil). La clé est accessible, mais uniquement via un compte personnel, pas via un coffre ou un rôle collectif. La restauration dans le test fonctionne, mais pas dans le scénario exact de production (réseau, droits sur la base, variables d’environnement différentes). L’équipe dépend d’un plugin spécifique, et personne ne sait le retirer ou le remplacer pour restaurer.
Un bon audit ne cherche pas la perfection. Il cherche surtout les points de rupture probables, ceux qui font perdre du temps dans un incident.
Documentation et “accessibilité des secrets” pour une équipe
On peut chiffrer correctement, et garder un niveau de sécurité élevé. Mais si l’équipe n’a pas une documentation claire et une méthode fiable pour retrouver la clé, la sécurité se dégrade quand arrive le moment critique.
Je recommande une approche simple: séparer le contenu sensible du “mode d’emploi”.
- Le secret lui-même doit rester dans un coffre ou un mécanisme de secrets approuvé. La documentation doit indiquer où le secret est récupéré, quel outil l’exige, et quelles étapes sont nécessaires pour restaurer.
Dans une entreprise, j’ai déjà vu un dossier “Procédure restauration” qui contenait des captures d’écran avec des clés. Ce dossier n’était pas un bug isolé, c’était un modèle de fonctionnement. Lorsqu’on a supprimé ces captures et qu’on a remplacé par des références au coffre, la restauration est devenue plus rapide, paradoxalement, parce que chacun savait immédiatement où regarder.
Une règle utile: la procédure doit être utilisable par une personne qui n’est pas celle qui a configuré le système. C’est souvent le meilleur test de qualité.
Une deuxième liste, utile: comment rendre le test de restauration vraiment probant
Voici une courte liste de paramètres que je vérifie pour que le test ne soit pas un exercice “qui rassure sans valoir”. (C’est la deuxième et dernière liste de l’article.)
- Utiliser une sauvegarde récente et une sauvegarde plus ancienne, pour couvrir les changements de format. Contrôler la restauration des médias (présents ou cohérents) en plus de la base SQL. Valider la correspondance des identifiants de base (droits, user, schéma) avec ce que la restauration exige. Vérifier que l’environnement de test n’a pas besoin d’accès secrets supplémentaires non documentés. Confirmer que la procédure est reproductible après un changement (mise à jour du plugin ou rotation programmée).
Si ces points passent, vous avez un signal fort sur la robustesse de vos sauvegardes chiffrées et sur l’accès aux clés.
Et si vous n’avez pas de chiffrement applicatif?
Parfois, on hérite d’un WordPress dont les sauvegardes ne sont pas chiffrées côté application. Il reste alors un choix: remplacer l’approche, ou renforcer autour, par exemple en mettant en place un chiffrement enveloppe avant export vers un stockage externe, ou via une couche de chiffrement au niveau des archives.
Je reste prudent sur les “solutions magiques”. Le bon compromis dépend de votre architecture (hébergeur, stockage, contraintes de restauration, équipe). L’important n’est pas de coller une technologie, c’est de garantir que:
- les sauvegardes sont réellement lisibles uniquement par ceux qui doivent les lire, la restauration est faisable dans le délai attendu, les clés sont gouvernées de façon stable.
Si vous déployez un mécanisme de chiffrement, faites-le tester tôt, pas à la veille d’une migration. Une mise en place qui semble simple en laboratoire peut échouer en production à cause de variables d’environnement, de droits réseau, ou d’un encodage de clé différent.
Arbitrages réalistes: sécurité, délai de restauration et complexité
La sécurisation des sauvegardes n’est pas gratuite.
Chiffrer partout peut complexifier la rotation des clés et la restauration. A l’inverse, trop simplifier la gestion des clés augmente le risque de divulgation et rend l’audit moins convaincant.
Dans les arbitrages, je regarde surtout trois choses:
- Délai maximal acceptable de restauration, même approximatif. Si vous visez “moins d’une heure”, tout ce qui dépend de recherches manuelles de clés devient suspect. Risque de divulgation selon la menace: fuite interne, incident fournisseur, accès non autorisé au stockage. Risque d’indisponibilité: un mécanisme de chiffrement qui vous enferme dans un outil unique est un risque.
Une bonne stratégie de sécurité, c’est celle qui vous laisse le choix au moment où vous en avez besoin.
Plan d’action pour rendre l’ensemble solide
Si vous devez prioriser, je proposerais une logique en trois mouvements, sans tout refaire d’un coup.
D’abord, faites l’état des lieux: quelles sauvegardes existent, comment elles sont chiffrées, où sont les clés, et qui a accès. Ensuite, exécutez un test de restauration réel avec une vérification de cohérence (base et médias). Enfin, verrouillez la gouvernance: coffre, permissions, rotation, documentation sans secrets.
C’est un travail plus “systèmes et processus” que “code”, mais sur WordPress, c’est souvent là que se gagnent les heures perdues et les scénarios non couverts.
Dernier point qui change tout
Un audit sérieux ne se contente pas d’évaluer. Il produit une preuve de restauration, avec une clé retrouvable et une procédure répétable. Le chiffrement est un verrou. Sans la clé, c’est un coffre fermé de l’intérieur. Et sur un incident, ce détail devient le vrai sujet.
Si vous voulez, décrivez votre configuration (hébergeur, plugin de sauvegarde, stockage utilisé pour les archives, méthode de chiffrement, qui détient la clé). Je peux vous aider à construire une grille d’audit plus ciblée, adaptée à votre architecture, sans supposer de détails qui pourraient être faux.