Les agences marketing reposent sur des fichiers : supports de campagne, contrats clients,
créations en cours et des années de contenus de marque répartis entre disques partagés et
outils de gestion de projet. La plupart fonctionnent avec de petites équipes, sans service
informatique dédié ; la sauvegarde est donc souvent configurée une fois pour toutes, puis
rarement réexaminée.
C’est précisément ce sur quoi comptent souvent les attaquants. Les ransomwares ciblent les
sauvegardes dans 4 attaques sur 5, dans le but de forcer le paiement d’une rançon en
détruisant votre capacité de restauration [1]. Pour une agence, perdre ces sauvegardes, c’est
perdre le travail réalisé pour ses clients et leur confiance. Les six erreurs ci-dessous laissent
les agences avec des sauvegardes impossibles à restaurer.
Points clés
Les dossiers synchronisés répliquent directement le chiffrement, et des copies qui
partagent le même emplacement ou les mêmes identifiants peuvent disparaître lors
d’un seul et même incident.
Une coche verte « réussite » confirme uniquement un transfert de données au moment
de la sauvegarde : des tests de restauration réguliers sont nécessaires pour prouver
qu’une sauvegarde fonctionnera.
Avec l’Immutabilité Absolue, personne ne peut modifier ni supprimer les données de
sauvegarde, même lorsque des identifiants administrateur sont compromis.
Six erreurs de sauvegarde des données à éviter
Aucune de ces erreurs n’apparaît dans un rapport de sauvegarde quotidien. Elles ne se
révèlent qu’au moment où l’agence tente une restauration. Chacune fait la différence entre
une sauvegarde qui tient sous pression et une sauvegarde qui n’est fiable que sur le papier.
- Confondre synchronisation de fichiers et sauvegarde
Les disques partagés et les dossiers synchronisés maintiennent des fichiers identiques sur
tous les appareils, ce qui explique pourquoi les agences les prennent souvent pour une
sauvegarde. La synchronisation fonctionne un peu comme une sauvegarde miroir, qui crée
une copie en temps réel des données sources.
Si les données sont chiffrées dans l’environnement source, le miroir reflète immédiatement
ce changement. Sans immuabilité ni snapshots à un instant donné, un miroir n’est qu’une
copie synchronisée d’un environnement compromis, et non une solution de restauration. - Conserver toutes les copies au même endroit
Une sauvegarde doit survivre à ce qui détruit l’original. Le risque de « sort partagé » (shared
fate) désigne la possibilité qu’un seul événement anéantisse à la fois les données de
production et la capacité à les restaurer. Lorsque les données de production et les
sauvegardes partagent le même stockage physique ou les mêmes identifiants
d’administration, une organisation n’est qu’à un incident d’une perte totale de ses données.
La séparation est inscrite dans la règle de sauvegarde 3-2-1-1-0 : au moins trois copies des
données sur deux types de supports différents, dont une copie stockée hors site et au moins
une conservée hors ligne ou immuable afin d’empêcher toute altération. - Partager les accès entre la production et les sauvegardes
Les identifiants partagés constituent un problème plus difficile à repérer. Les agences
ouvrent souvent rapidement l’accès aux fichiers clients à des freelances et à des
prestataires, et ces comptes ont tendance à se multiplier et à survivre aux projets pour
lesquels ils ont été créés.
Lorsque les systèmes de sauvegarde s’appuient sur le même fournisseur d’identité que la
production, la compromission du domaine peut donner aux attaquants le contrôle
administratif des politiques de sauvegarde, des planifications et des métadonnées, ce qui
rend souvent les copies hors site et immuables inutilisables pour la restauration, sans
même supprimer directement les données protégées. Le principe du moindre privilège, l’un
des fondements du Zero Trust, limite les autorisations des administrateurs. - Choisir une solution que l’équipe ne sait pas exploiter
Les petites agences emploient rarement un spécialiste de la sauvegarde, et encore moins un
ingénieur en sécurité. Une solution qui exige un paramétrage poussé, des compétences
Linux ou une surveillance constante risque d’être mal configurée, et une sauvegarde mal
configurée est une sauvegarde qui échoue au moment critique.
La simplicité n’est pas ici une question de confort : c’est un contrôle de sécurité. La solution
idéale s’installe rapidement, fonctionne sans expertise en stockage et se met à jour
automatiquement, de sorte que la protection ne dépend pas de la présence d’un expert dans
l’équipe. - Ne jamais tester de restauration
Un transfert de données réussi est souvent confondu avec une restauration réussie, alors
qu’il s’agit de deux indicateurs très différents en matière de protection des données. Un
échec de la sauvegarde peut se cacher derrière une coche verte « réussite » dans la console
et ne se révéler que lorsqu’une organisation tente de restaurer des services critiques en
pleine panne.
Pour une agence, cette découverte peut survenir alors qu’un client attend un livrable dont
les fichiers refusent de s’ouvrir. Le dernier zéro de la règle 3-2-1-1-0 correspond à zéro
erreur de restauration, vérifié par des tests réguliers.
6. Se fier à une immuabilité qu’un administrateur peut désactiver
Dans sa définition la plus simple, l’immuabilité garantit que les données ne peuvent être ni
modifiées ni supprimées une fois enregistrées, offrant ainsi un moyen sûr de protéger les
données critiques. Cette définition ne tient toutefois pas compte de la complexité de sa mise
en œuvre, ni des exceptions et failles cachées.
De nombreuses solutions revendiquent l’immuabilité, mais chez beaucoup d’entre elles, la
protection repose sur des politiques, ce qui signifie que toute personne disposant de droits
d’administration peut la désactiver. Des identifiants volés rendent alors cette protection
inutile. Une agence doit se tourner vers une solution de sauvegarde immuable dans laquelle
personne, pas même un administrateur ou un attaquant en possession d’identifiants valides,
ne peut modifier ou supprimer les données.
Ce niveau d’exigence s’appelle l’Immutabilité Absolue. Il n’est atteignable qu’avec un
système de stockage de sauvegarde Secure-by-Design, doté d’un Zero Access empêchant
toute action destructive, ce Zero Access devant pouvoir être vérifié par des tests menés par
des tiers.
Object First : un stockage de sauvegarde doté de l’Immutabilité Absolue
Lorsqu’un ransomware frappe (et la question n’est pas de savoir si, mais quand), votre
avenir dépend de votre cyberrésilience. Object First est votre défense ultime : un stockage
de sauvegarde doté de l’Immutabilité Absolue, conçu spécifiquement pour Veeam.
Fondé sur le Zero Trust, testé et vérifié par des tiers, Object First ne requiert aucune
expertise en sécurité et évolue avec votre activité.
David Bennett, CEO d’Object First, déclare : « Les organisations ne peuvent pas se permettre
de perdre du temps lorsqu’un ransomware frappe : leur chiffre d’affaires, leur réputation et
des emplois sont en jeu. La résilience ne se limite pas à protéger les données ; elle dépend de la
rapidité avec laquelle vous pouvez restaurer lorsque cela compte le plus. Object First offre aux
utilisateurs de Veeam une solution simple d’utilisation et à l’épreuve des ransomwares pour
restaurer plus rapidement et devenir tout simplement résilients. »
Références
[1] Omdia. « Recovery without Compromise: The Data-Backed Case for Backup Storage with
Absolute Immutability. » Commandé par Object First. 2026.
