Sauvegardes immuables : sécuriser son hébergement en 2026

Pour un site e-commerce, une indisponibilité ne se limite jamais à une erreur technique : elle peut interrompre les ventes, bloquer la préparation des commandes, empêcher les équipes d’accéder au back-office et dégrader durablement la confiance des clients. Dans ce contexte, les sauvegardes proposées par un hébergeur ne doivent pas être évaluées comme une simple ligne incluse dans une offre, mais comme un composant de continuité d’activité.

Les attaques par ransomware, les erreurs humaines, les extensions compromises et les défaillances de mises à jour WordPress ou de plugins rappellent une réalité essentielle : une copie de données ne protège réellement l’entreprise que si elle est restaurable, isolée et inaccessible à l’attaquant. C’est précisément le rôle des sauvegardes immuables.

Ce guide explique comment distinguer une sauvegarde d’hébergement classique d’une stratégie de reprise solide, quels critères demander à un prestataire et comment bâtir un plan de restauration réaliste pour un site critique.

Pourquoi les sauvegardes classiques ne suffisent plus face aux ransomwares

Une sauvegarde traditionnelle consiste à copier des fichiers, une base de données ou une machine virtuelle vers un autre espace de stockage. Cette approche reste indispensable, mais elle comporte une faiblesse majeure : si l’attaquant obtient des privilèges suffisants, il peut parfois chiffrer, supprimer ou altérer les sauvegardes en même temps que l’environnement de production.

Les groupes de ransomware cherchent fréquemment à rendre la reprise impossible avant de déclencher le chiffrement ou d’exiger une rançon. Un compte d’administration compromis, une clé API exposée, un accès SSH réutilisé ou des identifiants de panneau d’hébergement peuvent offrir un chemin vers les données de sauvegarde si celles-ci sont gérées avec les mêmes accès que le serveur principal.

Les cas les plus problématiques présentent souvent l’un des défauts suivants :

les sauvegardes sont stockées sur le même serveur ou dans le même compte d’hébergement ;
l’utilisateur qui administre le site peut aussi supprimer toutes les copies ;
les archives ne contiennent que les fichiers, sans la base de données ;
la conservation est trop courte pour revenir avant une compromission discrète ;
aucune restauration complète n’a été testée ;
les copies sont automatisées, mais les erreurs de sauvegarde ne sont pas surveillées.

Un scénario courant sur WordPress illustre le problème. Un plugin vulnérable est exploité, un code malveillant est déposé dans les fichiers et l’attaquant crée un compte administrateur. Si l’intrusion reste invisible plusieurs jours, les sauvegardes quotidiennes peuvent toutes contenir le code malveillant. Si l’attaquant efface en plus les points de restauration auxquels il a accès, la sauvegarde « incluse » ne permet plus de revenir à un état sain.

Pour un e-commerce utilisant WooCommerce, PrestaShop, Magento ou Adobe Commerce, il faut aussi prendre en compte les données qui évoluent continuellement : commandes, comptes clients, stocks, paiements, bons de réduction ou statuts d’expédition. Restaurer une copie de la nuit précédente peut remettre le site en ligne, mais créer un écart entre le stock réel, les commandes encaissées et les données présentes dans l’administration.

L’ANSSI recommande notamment de prévoir des sauvegardes régulières, isolées du système d’information et testées. Cette dernière partie est déterminante : une archive inutilisable, incomplète ou trop lente à restaurer n’est pas un plan de reprise.

Comprendre l’immuabilité, le versioning et la règle 3-2-1-1-0

Une sauvegarde immuable est une copie qui ne peut pas être modifiée ni supprimée pendant une période de conservation prédéfinie. Le principe est souvent désigné par le terme WORM, pour Write Once, Read Many : les données sont écrites une fois, puis peuvent être lues sans être réécrites.

Dans les infrastructures cloud, l’immuabilité peut reposer sur des mécanismes de verrouillage d’objets. Amazon S3 Object Lock, par exemple, permet de conserver des objets selon des règles de rétention. D’autres fournisseurs de stockage objet proposent également des capacités comparables. Ce mécanisme n’est toutefois utile que si son paramétrage, ses droits d’administration et la durée de conservation correspondent réellement au niveau de risque du site.

L’immuabilité ne doit pas être confondue avec le versioning. Le versioning conserve plusieurs versions successives d’un même fichier ou objet. Il facilite le retour à une version antérieure après une suppression ou une modification accidentelle. Mais si un attaquant peut supprimer les versions ou modifier les règles de conservation, il ne s’agit pas nécessairement d’une protection immuable.

Une approche largement utilisée pour structurer les sauvegardes est la règle 3-2-1-1-0 :

3 copies des données au total, incluant l’original ;
2 types de supports ou emplacements techniquement distincts ;
1 copie hors site, séparée de l’infrastructure de production ;
1 copie hors ligne ou immuable, résistante à la suppression et au chiffrement par un attaquant ;
0 erreur constatée après vérification de la capacité de restauration.

Cette règle n’impose pas une technologie unique. Une entreprise peut associer les sauvegardes automatiques de son hébergeur, une exportation de base de données vers un stockage distinct, et une copie chiffrée avec rétention verrouillée. En revanche, trois copies dans le même compte cloud, pilotées par le même identifiant administrateur, ne constituent pas une séparation suffisante.

Une sauvegarde devient une protection contre le ransomware lorsque sa suppression exige un accès, un délai ou un processus que l’attaquant ne possède pas.

Pour les sites web, il faut protéger au minimum trois ensembles : les fichiers applicatifs, la base de données et la configuration. Oublier le fichier de configuration, les variables d’environnement, les clés de chiffrement, les réglages DNS ou les procédures de déploiement peut rallonger considérablement la reprise, même si les fichiers et la base sont disponibles.

Les critères pour évaluer les sauvegardes d’un hébergeur

Les mots « sauvegardes quotidiennes », « rétention », « snapshots » ou « restauration en un clic » sont utiles, mais insuffisants pour évaluer un hébergement. Avant de souscrire ou de confier un site important à un prestataire, il faut demander des réponses précises, idéalement écrites dans la documentation, le contrat ou les conditions du service.

Fréquence, périmètre et durée de conservation

La première question est simple : à quelle fréquence les sauvegardes sont-elles réalisées ? Une copie quotidienne peut convenir à un site vitrine peu modifié. Elle est souvent insuffisante pour une boutique active, notamment si des commandes sont enregistrées toute la journée.

Demandez également ce qui est réellement inclus :

fichiers du site et médias ;
base de données MySQL ou MariaDB ;
boîtes e-mail, si elles sont hébergées chez le même prestataire ;
configurations serveur et certificats ;
environnements de préproduction ;
volumes, machines virtuelles ou conteneurs dans le cas d’une infrastructure dédiée.

La durée de rétention compte autant que la fréquence. Une conservation de quelques jours peut être adaptée à une erreur immédiatement détectée, mais elle peut être insuffisante si une compromission est découverte tardivement. Il est prudent de disposer de points de restauration à plusieurs horizons : récents pour les incidents opérationnels et plus anciens pour remonter avant une intrusion persistante.

Immutabilité réelle et séparation des privilèges

Un hébergeur peut conserver des sauvegardes dans une infrastructure distincte sans que celles-ci soient immuables. La question centrale est donc : qui peut les supprimer, et selon quel processus ?

Vérifiez notamment :

si une période de rétention empêche toute suppression avant son expiration ;
si le client peut modifier cette rétention depuis son espace d’administration ;
si le compte de production est séparé du compte ou du projet de sauvegarde ;
si l’authentification multifacteur est disponible pour les accès administrateurs ;
si les journaux d’audit permettent d’identifier une suppression, une restauration ou une modification de politique ;
si le support peut intervenir en cas de compromission du compte client.

La séparation des privilèges est aussi importante que le stockage. Un même compte administrateur ne devrait pas pouvoir déployer une application en production, désactiver les alertes, modifier les politiques de conservation et détruire toutes les copies sans contrôle supplémentaire.

Localisation, chiffrement et accès aux données

La sécurité ne se réduit pas à l’immuabilité. Les données de sauvegarde doivent être protégées en transit et au repos, avec une gestion des accès cohérente. Interrogez le prestataire sur le chiffrement des transferts, le chiffrement des données stockées et les modalités de gestion des clés lorsque cette information est disponible.

La localisation des données peut aussi entrer dans les contraintes de votre organisation, notamment pour des données personnelles. Le RGPD impose un cadre pour les transferts de données personnelles. Un hébergeur doit pouvoir fournir des éléments clairs sur les lieux de traitement, les sous-traitants éventuels et les engagements contractuels applicables.

Enfin, une sauvegarde peut contenir des données sensibles : comptes clients, adresses, informations de commande, journaux applicatifs ou exports de bases de données. Il faut appliquer aux archives le même niveau d’exigence qu’à la production, voire un niveau supérieur puisqu’elles concentrent de nombreuses données dans des fichiers téléchargeables.

Définir des objectifs de reprise adaptés à un site e-commerce

Avant de choisir une fréquence ou une technologie, définissez deux objectifs opérationnels : le RPO et le RTO.

Le RPO, ou objectif de point de reprise, correspond à la quantité maximale de données que l’entreprise accepte de perdre. Avec une sauvegarde quotidienne, le RPO théorique peut atteindre près de 24 heures. Cela peut être acceptable pour un site institutionnel, mais rarement pour une boutique réalisant des ventes régulières.

Le RTO, ou objectif de temps de reprise, correspond au temps acceptable avant que le service soit de nouveau opérationnel. Il comprend non seulement la restauration technique, mais aussi les vérifications : intégrité de la base, connexion au paiement, mise à jour des DNS si nécessaire, contrôle des e-mails transactionnels et validation du tunnel de commande.

Un plan réaliste différencie les composants. Par exemple :

la page de maintenance peut être remise en ligne rapidement ;
le front-office peut être restauré avant certains outils internes ;
les commandes doivent être rapprochées avec les données du prestataire de paiement ;
les stocks peuvent nécessiter une réconciliation avec l’ERP ou le logiciel de gestion.

Les services de paiement ne doivent pas être oubliés. Stripe, PayPal ou les établissements de paiement conservent leurs propres traces de transaction, mais votre site doit pouvoir rapprocher ces informations avec les commandes restaurées. Cette étape relève autant de l’organisation métier que de la technique.

La stratégie doit donc faire l’objet d’un arbitrage clair. Viser un RPO faible et un RTO court implique généralement plus d’automatisation, des sauvegardes plus fréquentes, des répliques ou des mécanismes de journalisation, ainsi qu’un budget adapté. Le bon objectif n’est pas le plus ambitieux sur le papier : c’est celui que l’entreprise peut financer, documenter et tester.

Construire une architecture de sauvegarde résiliente

Pour un site critique, il est prudent de ne pas dépendre d’une seule sauvegarde gérée par l’hébergeur, même lorsque cette dernière est de qualité. Le prestataire protège l’infrastructure qu’il exploite ; l’éditeur, l’agence ou l’équipe interne reste responsable de la cohérence applicative, des accès et de la capacité de remise en service.

Une architecture pragmatique peut combiner plusieurs couches :

les sauvegardes automatiques de l’hébergeur, utiles pour une restauration rapide des incidents courants ;
une sauvegarde indépendante des fichiers et de la base de données ;
un stockage externe avec contrôle d’accès séparé ;
une rétention immuable pour des points de restauration de référence ;
un inventaire sécurisé des secrets, configurations et procédures nécessaires à la reprise.

Pour WordPress, une sauvegarde cohérente comprend habituellement le répertoire contenant les médias, les thèmes, les extensions et les fichiers spécifiques, ainsi que l’export de la base de données. Mais restaurer l’ensemble sans vérifier la version de PHP, la configuration du serveur web, les tâches planifiées et les variables d’environnement peut provoquer de nouvelles erreurs.

Dans une architecture plus avancée, l’infrastructure peut être décrite avec des outils comme Terraform ou Ansible. Ces outils ne remplacent pas les sauvegardes de données, mais ils peuvent accélérer la reconstruction d’un environnement après incident. Pour les applications conteneurisées, les images de conteneurs, manifestes Kubernetes, secrets et volumes persistants doivent être traités séparément : une image Docker seule ne restaure pas une base de données.

Il faut également protéger le plan de reprise lui-même. Stocker les mots de passe d’urgence, les contacts d’escalade, les procédures DNS et les clés de récupération uniquement sur le serveur de production est une erreur classique. Un gestionnaire de mots de passe doté de contrôles d’accès, ainsi qu’une copie hors ligne des éléments critiques, réduisent ce risque.

Tester la restauration : la seule preuve qu’une sauvegarde fonctionne

Une sauvegarde terminée avec succès indique seulement qu’un processus a produit un fichier ou un point de restauration. Elle ne prouve ni que les données sont complètes, ni qu’elles sont lisibles, ni que l’application redémarrera. Le test de restauration transforme une hypothèse technique en preuve opérationnelle.

Un test sérieux ne consiste pas forcément à écraser la production. Il peut être réalisé dans un environnement isolé : sous-domaine temporaire, serveur de préproduction ou instance distincte. L’objectif est de restaurer une copie, puis de vérifier les fonctions essentielles sans exposer de données clients ni envoyer de messages transactionnels non souhaités.

Voici une checklist adaptée à un site e-commerce :

restaurer les fichiers et la base de données à partir d’un point choisi ;
vérifier que l’application se connecte correctement à sa base ;
contrôler les pages produits, images, catégories et recherche ;
tester la connexion à l’administration avec un compte autorisé ;
vérifier le panier et le parcours de commande dans un environnement de test ;
contrôler les webhooks, les tâches planifiées et les intégrations critiques ;
rechercher des erreurs dans les journaux applicatifs et serveur ;
mesurer le temps réellement nécessaire entre le lancement et le retour à un service validé ;
documenter les écarts entre le RTO visé et le résultat obtenu.

Les tests doivent aussi porter sur les droits. Une archive peut être présente, mais inaccessible en pratique parce que l’unique personne connaissant le compte de stockage est absente ou parce qu’une authentification multifacteur n’est plus récupérable. Prévoyez un accès d’urgence encadré, des rôles nominaux et une procédure d’escalade vers l’hébergeur.

Après chaque test, consignez le point de restauration utilisé, les étapes effectuées, les difficultés rencontrées, le temps consommé et les actions correctives. Cette documentation est particulièrement utile lors d’un changement d’hébergeur, d’une refonte, d’une migration de PHP ou d’une évolution majeure du CMS.

Les signaux d’alerte dans une offre de sauvegarde incluse

Une offre d’hébergement avec sauvegardes automatiques n’est pas forcément insuffisante. En revanche, certains éléments doivent inciter à demander des précisions ou à prévoir une couche indépendante.

La documentation ne précise pas la fréquence ni la durée de conservation.
Le prestataire parle de « sauvegardes » sans indiquer les données couvertes.
La restauration est facturée, manuelle ou uniquement disponible via le support sans délai annoncé.
Les sauvegardes sont présentées comme un service de courtoisie sans engagement de disponibilité.
Aucune information n’est fournie sur l’isolement, l’immuabilité ou les droits de suppression.
Il est impossible d’exporter une copie indépendante ou de récupérer facilement les données.
Le client ne dispose d’aucun journal d’activité sur les restaurations et suppressions.

Dans tous les cas, lisez les conditions du service. Certains hébergeurs indiquent explicitement que les sauvegardes constituent une facilité et que le client reste responsable de ses propres copies. Cette clause n’est pas anormale : elle confirme simplement qu’une stratégie de résilience ne doit pas reposer sur une seule promesse commerciale.

La qualité globale de l’hébergement reste également importante. Une infrastructure performante, une bonne supervision et des mécanismes de sécurité réduisent certains incidents, sans remplacer la reprise. Vous pouvez compléter cette réflexion avec notre guide sur l’évaluation d’un hébergement premium face à une offre standard et notre dossier consacré à PCI DSS et l’hébergement e-commerce.

Mettre en place un plan de restauration exploitable par les équipes

Un plan de restauration efficace doit être court, précis et accessible en situation de crise. Il ne doit pas reposer sur la mémoire d’un administrateur ni sur une succession de décisions improvisées. Pour un e-commerce, il doit associer les équipes techniques, le responsable métier, le support client et, si besoin, le prestataire de paiement ou l’agence de développement.

Le document peut inclure :

les critères qui déclenchent une restauration plutôt qu’une simple correction ;
la liste des personnes habilitées à décider et à agir ;
les coordonnées de l’hébergeur, du registrar, de l’agence et des fournisseurs critiques ;
l’emplacement des sauvegardes et la procédure d’accès ;
les étapes techniques dans leur ordre d’exécution ;
les contrôles de sécurité avant remise en ligne ;
la procédure de communication aux équipes et, si nécessaire, aux clients ;
la méthode de rapprochement des commandes, paiements et stocks après reprise.

En cas de suspicion de ransomware, évitez de restaurer précipitamment sur l’environnement compromis. Il faut d’abord contenir l’incident, préserver les éléments utiles à l’analyse, réinitialiser les accès potentiellement exposés et identifier un point de restauration antérieur à la compromission. La remise en ligne doit s’accompagner d’une revue des comptes administrateurs, des clés API, des extensions, des journaux et des mécanismes d’accès distant.

Enfin, une restauration ne clôt pas automatiquement l’incident. Il faut analyser la cause initiale afin d’éviter une récidive : correctif de sécurité, suppression d’un plugin vulnérable, durcissement des accès, rotation des secrets, activation du MFA, limitation des privilèges ou amélioration de la supervision.

Conclusion : faire de la sauvegarde un mécanisme de reprise, pas une option

Les sauvegardes immuables ne dispensent ni de sécuriser les accès, ni de mettre à jour les applications, ni de surveiller son infrastructure. Elles apportent cependant une protection essentielle lorsque les défenses préventives échouent : la possibilité de retrouver un état exploitable sans dépendre d’une copie que l’attaquant a pu supprimer ou chiffrer.

Pour un site e-commerce ou une plateforme critique, la bonne démarche consiste à vérifier la couverture réelle des sauvegardes de l’hébergeur, définir un RPO et un RTO cohérents avec l’activité, conserver au moins une copie indépendante et tester régulièrement une restauration complète. Avant de choisir ou renouveler une offre, transformez ces points en questions concrètes à poser au prestataire : c’est le moyen le plus sûr de savoir si votre hébergement est réellement prêt à vous aider le jour où la reprise devient nécessaire.