La sauvegarde des données professionnelles ne se résume plus à copier des fichiers sur un NAS ou à planifier un job Veeam hebdomadaire. Les attaques par ransomware ciblent désormais les sauvegardes elles-mêmes, ce qui rend obsolète toute architecture de protection qui ne sépare pas strictement les rôles d’administration, le stockage et la supervision sécurité.
Séparation des privilèges et RBAC sur les jobs de sauvegarde
Un compte d’administration compromis qui dispose d’un accès complet aux jobs de sauvegarde peut supprimer ou chiffrer l’intégralité des copies en quelques minutes. Nous observons que la majorité des incidents graves ne proviennent pas d’une faille dans le logiciel de sauvegarde lui-même, mais d’une gestion des accès trop permissive.
Lire également : L'intelligence artificielle optimise la gestion des bases de données
La segmentation via RBAC et PAM appliqués aux sauvegardes distingue trois rôles : l’administrateur des jobs (planification, rétention), l’administrateur du stockage (volumes, réplication) et le responsable sécurité (supervision, alertes, validation des restaurations). Aucun de ces trois comptes ne peut, seul, modifier ou détruire une copie.
Cette approche impose un changement organisationnel. Dans une PME de vingt postes, le même technicien gère souvent l’ensemble. La solution passe alors par un mécanisme de double validation (quorum) sur les opérations destructives, fonctionnalité que proposent désormais plusieurs solutions cloud et certains agents on-premise.
A lire également : L'analyse prédictive s'invite dans la gestion des stocks informatiques
Règle 3-2-1-1-0 : ce que le dernier chiffre change vraiment
La règle 3-2-1 reste le socle de toute politique de sauvegarde d’entreprise : trois copies, deux supports différents, une copie hors site. Les contenus récents la font évoluer vers la règle 3-2-1-1-0, qui ajoute deux exigences concrètes.
Le premier « 1 » supplémentaire désigne une copie immuable ou hors ligne. Le stockage immuable empêche toute modification ou suppression pendant une durée définie, y compris par un administrateur. Le « 0 » exige zéro erreur vérifiée lors du dernier test de restauration.
Immuabilité logicielle ou immuabilité matérielle
L’immuabilité logicielle (object lock sur un bucket S3, par exemple) protège contre la suppression logique. L’immuabilité matérielle (bandes LTO déconnectées, air gap physique) protège contre un accès réseau total. Nous recommandons de combiner les deux selon la criticité des données :
- Données métier critiques (ERP, bases de production) : copie air gap physique avec rotation hebdomadaire et copie immuable cloud avec rétention de trente jours minimum
- Fichiers bureautiques et messagerie : copie immuable cloud suffisante si le RPO acceptable dépasse quelques heures
- Configurations système et images VM : snapshot immuable répliqué sur un second datacenter ou une seconde région cloud
Le choix entre ces niveaux dépend directement des objectifs RPO et RTO définis en amont, pas de l’inverse.
RPO et RTO comme critères d’architecture, pas comme indicateurs théoriques
Trop de projets de sauvegarde démarrent par le choix d’un logiciel, puis tentent d’adapter les objectifs de reprise à ses capacités. La démarche efficace est strictement inverse. Définir le RPO et le RTO avant de choisir la solution conditionne l’architecture cible : fréquence des sauvegardes incrémentales, bande passante réseau nécessaire, type de stockage, et capacité de restauration granulaire.
Un RPO de quatre heures sur une base de données de plusieurs centaines de gigaoctets n’impose pas la même infrastructure qu’un RPO de vingt-quatre heures sur un partage de fichiers bureautiques. Le premier cas oriente vers une réplication continue ou quasi continue avec journalisation. Le second se satisfait d’une sauvegarde incrémentale quotidienne classique.
Mesurer le RTO réel sur environnement isolé
Le RTO annoncé par un éditeur est un RTO théorique. Plusieurs retours terrain montrent des écarts significatifs entre le temps de restauration mesuré en laboratoire et celui constaté en conditions réelles (bande passante partagée, dépendances applicatives, vérifications d’intégrité).
La bonne pratique consiste à tester la restauration complète sur un environnement isolé au moins une fois par trimestre, en mesurant le délai effectif et en validant l’intégrité fonctionnelle des données restaurées. Un plan de reprise d’activité qui n’a jamais été testé n’est qu’un document.
Chiffrement des sauvegardes et protection contre leur propre compromission
Le chiffrement AES-256 en transit et au repos est devenu un standard. Il ne constitue plus un critère différenciant entre les solutions de sauvegarde. Le vrai enjeu porte sur la protection des sauvegardes contre leur propre compromission.
Une sauvegarde chiffrée dont la clé de déchiffrement est stockée sur le même système de gestion reste vulnérable. Nous recommandons une gestion des clés séparée, idéalement via un HSM (Hardware Security Module) ou un service de gestion de clés dédié, distinct de l’infrastructure de sauvegarde.
- Clés de chiffrement stockées hors de l’infrastructure de sauvegarde, avec rotation programmée
- Authentification multifacteur obligatoire pour toute opération de restauration ou de suppression de job
- Journalisation centralisée des accès aux sauvegardes, envoyée vers un SIEM séparé pour détecter les comportements anormaux
Cette séparation systématique entre les données sauvegardées et les mécanismes de contrôle réduit considérablement la surface d’attaque. Un attaquant qui compromet le serveur de sauvegarde ne dispose ni des clés de chiffrement ni de la capacité à supprimer les copies immuables.
Sauvegarde cloud, hybride ou on-premise : arbitrer selon la contrainte réelle
Le choix entre sauvegarde cloud, hybride ou on-premise ne relève pas d’une préférence technologique. Il dépend de trois contraintes mesurables : la volumétrie de données à protéger, la bande passante disponible pour la restauration, et les exigences réglementaires de localisation.
Une entreprise qui génère plusieurs téraoctets de données par jour et dispose d’un lien réseau limité n’a pas intérêt à tout externaliser vers le cloud. La restauration prendrait des jours. À l’inverse, une structure répartie sur plusieurs sites avec peu de volumétrie locale gagne à centraliser ses sauvegardes en cloud, en s’assurant que le fournisseur garantit un hébergement dans la zone géographique requise.
L’architecture hybride (sauvegarde locale pour la restauration rapide, réplication cloud pour la protection hors site) reste le meilleur compromis entre rapidité de reprise et résilience pour la majorité des entreprises de taille intermédiaire. Elle satisfait la règle 3-2-1-1-0 sans exiger une bande passante démesurée.
La sécurisation des données professionnelles par la sauvegarde repose moins sur le choix d’un logiciel que sur la rigueur de l’architecture déployée autour de lui. Séparation des rôles, immuabilité vérifiée, tests de restauration réguliers et gestion des clés indépendante forment un socle que chaque entreprise peut dimensionner selon ses contraintes réelles.
