Par redaction , 4 janvier 2026
Conseil sauvegarde

Une sauvegarde n’est utile que si elle est restaurable, protégée et alignée sur les objectifs métier (RPO/RTO). Cet article détaille les bonnes pratiques essentielles (règle 3-2-1, copie hors ligne, chiffrement, tests de restauration, cloisonnement et supervision) pour renforcer la résilience face aux incidents et aux rançongiciels.

La sauvegarde est l’un des rares leviers capables de limiter durablement l’impact d’un incident : panne matérielle, erreur humaine, suppression accidentelle, corruption de données ou attaque par rançongiciel. Mais une sauvegarde “qui tourne” ne suffit pas : elle doit être fiable, protégée et testée, sinon elle échouera précisément le jour où vous en aurez besoin.

1) Partir du besoin métier : RPO/RTO avant la technique

Avant de choisir un outil ou une fréquence, définissez vos objectifs de reprise :

  • RPO (Recovery Point Objective) : quelle perte de données maximale est acceptable ?
  • RTO (Recovery Time Objective) : quel temps maximal d’indisponibilité est acceptable ?

Ces cibles doivent être fixées par application / service critique, avec une priorité de restauration. Sans cela, on sauvegarde “tout, pareil” et on découvre trop tard que la reprise prendra des jours.

2) Appliquer une stratégie simple et robuste : la règle 3-2-1 (au minimum)

Une bonne base consiste à respecter la règle 3-2-1 :

  • 3 copies distinctes : production + 2 copies de sauvegarde ;
  • sur 2 supports différents (ex. stockage disque + bande, ou deux technologies distinctes) ;
  • dont 1 copie hors ligne (déconnectée) ou, a minima, fortement isolée.

L’objectif est de conserver au moins une copie qui reste hors d’atteinte si le SI est compromis (chiffrement des volumes, suppression, sabotage…).

3) Se protéger contre le scénario “rançongiciel”

Les attaquants cherchent fréquemment à rendre les sauvegardes inutilisables (chiffrement, effacement, altération des catalogues). Pour réduire ce risque :

  • Isoler une sauvegarde hors ligne (support déconnecté) et/ou recourir à des mécanismes d’immutabilité correctement configurés ;
  • Éviter que les identifiants de sauvegarde soient accessibles depuis l’environnement utilisateur ou bureautique ;
  • Prévoir des “images de référence” (golden images) et conserver hors ligne les éléments nécessaires à la reconstruction (médias, binaires, scripts, configurations) ;
  • Tester régulièrement la restauration, pas seulement la “réussite” des jobs de sauvegarde.

4) Sécuriser l’infrastructure de sauvegarde comme un SI d’administration

Une infrastructure de sauvegarde doit être traitée comme un composant critique, avec des exigences proches d’un SI d’administration :

  • Cloisonnement réseau : placer les serveurs de sauvegarde dans une zone dédiée, distincte de la production ;
  • Filtrage strict des flux : limiter précisément les communications nécessaires ;
  • Annuaire / authentification indépendante lorsque possible, afin de limiter les effets d’un compromis du domaine de production ;
  • Journalisation des actions d’administration et centralisation des logs ;
  • Mises à jour proactives des composants (logiciels, micrologiciels) et suivi des alertes de sécurité.

5) Contrôler les accès : comptes dédiés, rôles séparés, privilèges minimaux

Les comptes de sauvegarde sont très sensibles : ils donnent accès à des données de grande valeur et peuvent accélérer une compromission. Bonnes pratiques :

  • Comptes d’administration dédiés et nominatifs (pas de comptes partagés) ;
  • Séparation des rôles (exploitation quotidienne vs administration avancée) selon un modèle RBAC ;
  • Secrets maîtrisés : rotation, stockage sécurisé, limitation des privilèges des comptes techniques ;
  • Restaurations encadrées : éviter les restaurations en libre-service sans contrôle et traçabilité.

6) Chiffrer et protéger les sauvegardes au même niveau que la production

Une sauvegarde contient souvent les données les plus sensibles (parfois toutes les données). Elle doit donc bénéficier d’un niveau de protection équivalent :

  • Chiffrement des sauvegardes (au repos) si le risque physique ou d’accès non autorisé existe ;
  • Chiffrement des flux lors des transferts (ex. TLS), surtout en cas d’externalisation ;
  • Gestion rigoureuse des clés : stockage sûr, accès limité, et sauvegarde des clés elle-même (y compris hors ligne si nécessaire).

7) Tester la restauration : le vrai indicateur de réussite

Beaucoup d’organisations découvrent trop tard que leurs sauvegardes sont inexploitables (rétention insuffisante, catalogue corrompu, données incohérentes, droits manquants, clés de chiffrement indisponibles…). Mettre en place :

  • des tests de restauration planifiés (sur un environnement isolé) ;
  • une procédure documentée de reprise et un ordre de restauration (dépendances DNS, annuaire, applicatifs critiques, etc.) ;
  • des contrôles d’intégrité et des vérifications fonctionnelles (pas uniquement techniques).

8) Surveiller et détecter les anomalies de sauvegarde

La supervision doit aider à repérer les signaux faibles :

  • volumes ou nombres de fichiers anormalement bas/élevés ;
  • lenteurs réseau inhabituelles ;
  • modifications non attendues des politiques de sauvegarde ;
  • échecs répétés, ou succès “suspects” (jobs trop rapides, durées incohérentes).

L’objectif est de détecter tôt un sabotage, une dérive de configuration ou une dégradation avant qu’elle ne devienne critique.

9) Penser au cycle de vie : rétention, externalisation, et fin de vie des supports

Une stratégie complète décrit aussi :

  • les durées de rétention (journalier, mensuel, annuel…) alignées sur les obligations et les risques ;
  • les conditions d’externalisation (contrats, responsabilités, exigences de sécurité, localisation, chiffrement) ;
  • la mise au rebut : effacement sécurisé et/ou destruction physique des supports selon leur sensibilité.

Checklist rapide : 12 questions à se poser

  1. Connaissez-vous le RPO/RTO de vos applications critiques ?
  2. Avez-vous une copie réellement hors ligne ou fortement isolée ?
  3. Appliquez-vous une stratégie 3-2-1 (au minimum) ?
  4. Les sauvegardes sont-elles chiffrées (au repos) et les flux protégés (en transit) ?
  5. Les comptes de sauvegarde sont-ils dédiés, nominatifs, et à privilèges minimaux ?
  6. Les serveurs de sauvegarde sont-ils cloisonnés et filtrés réseau ?
  7. Les sauvegardes sont-elles testées par des restaurations réelles et régulières ?
  8. Disposez-vous d’une procédure documentée et d’un ordre de restauration ?
  9. Supervisez-vous les anomalies de volumes, durées, échecs et changements de politiques ?
  10. Savez-vous reconstruire le SI de sauvegarde (catalogue, binaires, clés, procédures) ?
  11. Avez-vous prévu le risque de “restaurer l’attaquant” (contrôles avant redémarrage) ?
  12. Vos sous-traitants (si présents) sont-ils encadrés par des exigences de sécurité ?

Conclusion

Une bonne stratégie de sauvegarde vise un objectif simple : rendre la restauration possible, rapide et sûre, même si l’environnement est compromis. En pratique, cela passe par une combinaison de règles éprouvées (3-2-1, hors ligne), de protection (chiffrement, cloisonnement, contrôle d’accès) et d’opérationnel (tests de restauration, supervision, procédures). C’est un investissement qui paie le jour où tout le reste échoue.

Sources

Catégorie
Conseil