Backup externalisé : une copie hors site ne suffit pas contre les ransomwares

Backup externalisé : une copie hors site ne suffit pas contre les ransomwares

Un backup externalisé est une copie de sauvegarde conservée en dehors du site où fonctionnent vos systèmes de production. Il protège vos données lorsqu’un incendie, un vol ou une panne rend vos équipements inutilisables. Mais déplacer une copie dans le cloud ne suffit pas : pour résister à une cyberattaque et permettre une reprise réelle, cette copie doit aussi être protégée, conservée suffisamment longtemps et testée.

Sortir les données du bâtiment, mais aussi du périmètre de risque

La sauvegarde locale reste précieuse pour récupérer rapidement un fichier ou un serveur. Sa limite apparaît lorsqu’elle partage les mêmes risques que la production : alimentation électrique, bâtiment, réseau ou comptes administrateurs. Un dégât des eaux peut détruire les deux équipements ; un ransomware peut chiffrer les données et supprimer les sauvegardes accessibles avec les identifiants compromis.

Schéma du backup externalisé avec les règles 3-2-1-1-0, l’immuabilité et la restauration isolée
Schéma du backup externalisé avec les règles 3-2-1-1-0, l’immuabilité et la restauration isolée

La sauvegarde hors site apporte une séparation géographique. La télésauvegarde automatise généralement le transfert vers une infrastructure distante, tandis qu’une externalisation physique repose, par exemple, sur des bandes transportées et conservées ailleurs. Dans les deux cas, l’indépendance des accès et des moyens de récupération compte autant que la distance.

Il faut également distinguer sauvegarde, synchronisation et réplication. Une synchronisation peut propager une suppression. Une réplication peut reproduire une corruption. Une sauvegarde conserve des points de récupération permettant de revenir avant l’incident. De même, un snapshot facilite certains retours arrière, mais ne remplace pas une copie indépendante si son stockage d’origine disparaît.

Enfin, externaliser ne signifie pas nécessairement déléguer l’exploitation. Selon le contrat, votre équipe continue de configurer les tâches et de surveiller les alertes, ou ces opérations sont confiées au prestataire. Cette répartition doit être explicite avant tout engagement.

Construire des copies qui restent utilisables après une attaque

Appliquer la règle 3-2-1-1-0 sans compter deux fois la même protection

La règle 3-2-1 prévoit 3 copies des données, dont la production, sur 2 supports différents, avec 1 copie hors site. Son extension, la règle 3-2-1-1-0, ajoute 1 copie immuable ou isolée et un objectif de 0 erreur de récupération constatée lors des vérifications. Ce dernier point demande des tests, pas seulement un voyant vert dans la console.

Un serveur, un dépôt local et une copie distante constituent une base possible. Encore faut-il éviter qu’un même compte puisse supprimer les trois. Séparez les identités d’administration, protégez les connexions par authentification multifacteur et prévoyez un accès de secours indépendant de l’environnement de production.

Combiner immuabilité, versioning et chiffrement

L’immuabilité interdit la modification ou la suppression d’une sauvegarde pendant une durée définie, selon le mécanisme et sa configuration. L’air gap désigne une isolation physique ou logique limitant son accessibilité. Le versioning conserve plusieurs états d’un objet ; il aide à revenir en arrière, mais ne garantit pas à lui seul qu’un attaquant ne pourra pas supprimer ces versions.

Le chiffrement protège la confidentialité, pendant le transfert et au repos. Vérifiez s’il intervient côté client ou côté serveur, qui détient les clés et comment celles-ci sont récupérées après un sinistre. Une clé perdue peut rendre une sauvegarde inutilisable.

Une empreinte cryptographique permet aussi de repérer une altération des données sauvegardées. Mais un fichier malveillant peut être copié fidèlement et présenter une intégrité parfaite : le hachage prouve une correspondance, pas l’innocuité. Associez donc les contrôles d’intégrité à une restauration isolée et à la recherche d’un point de reprise antérieur à la compromission.

Choisir une architecture adaptée plutôt qu’une simple destination

Cloud, datacenter et stockage S3 ne désignent pas des solutions équivalentes. Le datacenter est un lieu d’hébergement ; le cloud décrit un mode de fourniture de ressources ; S3 est une interface de stockage objet. Une même offre peut réunir ces trois caractéristiques.

ApprocheAtout principalPoint à vérifier
Sauvegarde localeRestauration rapide sur siteExposition au sinistre local et au réseau compromis
Support physique externaliséPossibilité d’isolation hors ligneRotation, transport et délai de récupération
Cloud public ou privéCapacité évolutive et accès distantDébit, coûts de sortie et responsabilités
Stockage objet compatible S3Intégration aux logiciels et rétention évolutiveCompatibilité exacte et verrouillage des objets
Datacenter distant dédiéInfrastructure et localisation identifiablesIndépendance des sites et moyens de reprise
Architecture distribuéeRépartition sur plusieurs nœudsDisponibilité des fragments, clés et exploitation

Pour une entreprise déjà équipée, partez du logiciel existant : Veeam, Acronis, Atempo, Rubrik, Commvault ou Nakivo. Vérifiez la version, les licences, les fonctions de restauration et la prise en charge de l’immuabilité. Veeam Cloud Connect constitue une piste pour externaliser depuis un environnement Veeam ; une cible S3 peut répondre à d’autres intégrations. SMB et NFS sont des protocoles d’accès aux fichiers, sans garantie intrinsèque d’isolation.

Leviia ou les approches distribuées telles que DATIS peuvent entrer dans une consultation, mais comparez leurs engagements précis plutôt que leurs seules catégories technologiques. La géo-répartition améliore la résistance à une perte de site ; elle ne prouve pas automatiquement l’existence d’une sauvegarde indépendante.

Dimensionner le backup à partir de la reprise attendue

Commencez par les applications critiques, les bases de données, les postes indispensables et les services SaaS. Pour chacun, définissez le RPO, soit la perte de données maximale acceptable exprimée dans le temps, et le RTO, soit le délai cible de remise en service. La fréquence des sauvegardes influence le premier ; le débit, l’infrastructure et les procédures influencent le second.

La sauvegarde complète copie l’ensemble du périmètre. L’incrémentielle copie les changements depuis la sauvegarde précédente ; la différentielle, ceux survenus depuis la dernière complète. Ces choix modifient les transferts, le stockage et la chaîne nécessaire à la restauration. La rétention doit aussi permettre de retrouver une version saine si l’incident est découvert tardivement.

  1. Identifier l’incident et isoler les systèmes touchés.
  2. Choisir un point de récupération présumé sain.
  3. Restaurer dans un environnement isolé avec les clés et accès prévus.
  4. Vérifier les fichiers, les applications et leurs dépendances.
  5. Mesurer le délai réel, faire valider le service puis autoriser sa remise en production.

Testez selon la criticité et après une modification importante de l’architecture. Incluez une restauration complète, pas uniquement quelques fichiers. Le plan de reprise d’activité organise le redémarrage ; le plan de continuité d’activité vise le maintien des services essentiels. Une sauvegarde les alimente, sans remplacer à elle seule les équipements, les équipes ou les procédures nécessaires.

Comparer les contrats sur le coût réel et les preuves

Un tarif au volume stocké ne représente pas toujours le coût total. Ajoutez les licences, la rétention, les versions, les transferts, les éventuels frais de sortie, l’assistance et les tests. Demandez une estimation en fonctionnement normal, mais aussi pour une restauration massive et une sortie du contrat. Vérifiez enfin que votre connexion permet les transferts dans les délais attendus.

Sur la souveraineté, demandez où se trouvent les données, les répliques et les équipes ayant accès au service. Un hébergement en France ne répond pas, à lui seul, à toutes les questions juridiques. Examinez les sous-traitants, les conditions d’accès et la maîtrise des clés. Les certifications ISO 27001 ou HDS doivent être vérifiées sur leur périmètre exact et selon vos obligations.

Avant de signer, exigez une démonstration de restauration avec vos contraintes : environnement existant indisponible, récupération des clés, assistance mobilisable et délai mesuré. Faites préciser qui surveille les échecs, qui déclenche la reprise et comment récupérer les données dans un format exploitable. Le bon backup externalisé est celui dont vous avez vérifié la récupération, pas seulement le stockage.

À découvrir ensuite

Bac pro cybersécurité : des réseaux à l’électronique, pas seulement du piratage · Fibre dédiée : le débit garanti ne suffit pas à assurer la continuité · VerifSites : une note sur 5 ne suffit pas pour acheter sans risque · Bac pro CIEL : 3 ans pour apprendre à installer et sécuriser réseaux, logiciels et équipements · Cours Internet : les bases du Web, des réseaux et de la sécurité