Politique de Sauvegarde ISO 27001 : Modèle Word [A.8.13]

Le contrôle A.8.13 de la norme ISO 27001:2022 impose que les informations soient sauvegardées et que ces sauvegardes soient testées régulièrement conformément à une politique de sauvegarde. Dans un contexte de prolifération des ransomwares où la compromission des sauvegardes est devenue une tactique systématique des attaquants, la politique de sauvegarde est passée du statut de bonne pratique IT à celui de contrôle de sécurité critique. Le principe 3-2-1-1-0 — trois copies des données, sur deux types de supports différents, dont une hors site, une sur support immuable, et zéro erreur lors des tests de restauration — est aujourd'hui le standard de l'industrie pour une sauvegarde résiliente face aux cybermenaces modernes. La politique de sauvegarde doit couvrir l'ensemble du cycle de vie des sauvegardes : la définition des objectifs de restauration (RTO/RPO par classe d'actif), les mécanismes de sauvegarde, la protection des sauvegardes contre les menaces (chiffrement, immuabilité, ségrégation réseau), et le processus de test de restauration — souvent le maillon faible ignoré jusqu'au moment où une restauration est nécessaire en urgence.

Contexte normatif : le contrôle A.8.13 et ses articulations

Le contrôle A.8.13 « Sauvegarde des informations » est l'un des contrôles les plus opérationnels de la norme ISO 27001:2022. Il stipule que les copies de sauvegarde des informations, des logiciels et des systèmes doivent être conservées et régulièrement testées conformément à la politique de sauvegarde convenue. La politique doit définir les exigences de restauration incluant l'intégrité et la confidentialité des sauvegardes.

Les articulations normatives clés :

• A.5.9 — Inventaire des actifs d'information : la politique de sauvegarde s'applique aux actifs classifiés comme requérant une sauvegarde
• A.5.30 — Continuité de la sécurité de l'information : la sauvegarde est un pilier du Plan de Continuité d'Activité (PCA)
• A.8.10 — Suppression de l'information : articulation avec le cycle de vie et la rétention des données
• A.8.24 — Cryptographie : chiffrement des sauvegardes pour la confidentialité et la protection en cas de vol du support
• RGPD Art. 32 — Mesures techniques appropriées incluant la capacité à restaurer les données en cas d'incident
• ISO 22301 — Management de la continuité d'activité : complémentaire à ISO 27001 pour les PCA/PSI formels

Le principe 3-2-1-1-0 : le standard anti-ransomware

Le principe 3-2-1 est un classique de la gestion des sauvegardes. Son évolution vers 3-2-1-1-0 répond spécifiquement aux ransomwares modernes :

RTO et RPO : les objectifs qui gouvernent la politique

Les deux métriques fondamentales de la politique de sauvegarde sont le RPO (Recovery Point Objective) et le RTO (Recovery Time Objective). Ces métriques sont définies par classe d'actif en concertation avec les métiers, pas par l'équipe IT seule.

RPO (Recovery Point Objective) : la perte de données maximale acceptable exprimée en durée. Un RPO de 4 heures signifie qu'en cas d'incident, on peut perdre au maximum 4 heures de données. Le RPO détermine la fréquence des sauvegardes : pour un RPO de 4h, une sauvegarde toutes les 4h minimum est nécessaire. Pour certaines applications critiques (bases de données transactionnelles), le RPO peut être de quelques minutes, ce qui implique de la réplication en continu plutôt que des sauvegardes classiques.

RTO (Recovery Time Objective) : le temps maximum acceptable pour restaurer un service après un incident. Un RTO de 8 heures signifie que le service doit être opérationnel dans les 8 heures suivant le déclenchement de la procédure de restauration. Le RTO détermine la solution de sauvegarde, l'emplacement des sauvegardes (locales = RTO court, cloud = RTO potentiellement plus long), et les ressources mobilisables pour la restauration.

Protection des sauvegardes contre les ransomwares

La stratégie d'immuabilité

La menace principale pour les sauvegardes en 2024-2026 est le ransomware qui cible délibérément les sauvegardes avant de chiffrer les données primaires. Les groupes de ransomware sophistiqués passent en moyenne plusieurs semaines dans le système de la victime avant de déclencher le chiffrement, en partie pour identifier et compromettre les systèmes de sauvegarde. La réponse est l'immuabilité : des sauvegardes que même un attaquant disposant de droits administrateurs ne peut pas supprimer ou chiffrer.

Les solutions d'immuabilité disponibles : Object Lock S3 (AWS, Scaleway, OVH) avec mode WORM (Write Once Read Many), Azure Immutable Blob Storage, baies de stockage avec Veeam Hardened Repository sur Linux (sans root login), Zerto ou Rubrik avec des politiques d'immuabilité intégrées, et les sauvegardes sur bandes magnétiques physiquement déconnectées (air-gap).

La ségrégation réseau des sauvegardes

Le serveur de sauvegarde et les médias de sauvegarde doivent être dans un segment réseau isolé, accessible uniquement via des connexions initiées par le serveur de sauvegarde vers les agents clients (pas l'inverse). Cette architecture push évite qu'un poste compromis puisse atteindre le serveur de sauvegarde et le chiffrer. L'accès au serveur de sauvegarde depuis les postes utilisateurs doit être bloqué au niveau pare-feu.

Le chiffrement des sauvegardes

Le chiffrement des sauvegardes protège la confidentialité des données en cas de vol du support (disque externe envoyé hors site, bandes transportées). La clé de chiffrement doit être gérée séparément des sauvegardes elles-mêmes — une sauvegarde chiffrée dont la clé est stockée sur le même support ne protège rien. Le template inclut une section sur la gestion des clés de chiffrement des sauvegardes, un aspect souvent négligé qui peut rendre les sauvegardes inutilisables lors d'une restauration d'urgence si les clés ont été perdues avec le système principal.

Checklist d'audit — Contrôle A.8.13 ISO 27001

Points de vigilance spécifiques aux environnements modernes

La fausse sécurité du cloud natif

Beaucoup d'organisations supposent à tort que leurs données dans Microsoft 365 ou Google Workspace sont automatiquement sauvegardées et récupérables. En réalité, ces plateformes offrent une haute disponibilité (contre les pannes) mais pas une véritable sauvegarde contre la suppression accidentelle, la corruption de données, ou la suppression malveillante. Microsoft 365 ne conserve les éléments supprimés que 30 à 93 jours selon la configuration. Une solution de backup tierce dédiée au SaaS (Veeam pour M365, Acronis, Backupify) est indispensable pour les données critiques hébergées dans le cloud.

L'oubli des données de développement et de test

Les environnements de développement et de test contiennent souvent des données de production (parfois en violation du principe de minimisation RGPD). La politique de sauvegarde doit couvrir ces environnements, particulièrement si des correctifs de données critiques ou des scripts de migration y sont développés. La perte d'un environnement de développement peut avoir un impact sur la production si les scripts ou configurations ad hoc ne sont pas récupérables.

Les temps de restauration : toujours plus longs que prévu

Les estimations théoriques de RTO sont systématiquement optimistes. En situation de crise (stress, équipe réduite, documentation incomplète, environnement partiellement compromis), les temps réels de restauration sont souvent 3 à 5 fois supérieurs aux estimations. Les tests de restauration réguliers permettent d'identifier ces écarts et de calibrer les RTO sur des bases réalistes. Documenter chaque test avec le temps effectif de restauration constitue une donnée précieuse pour améliorer continuellement la politique.

FAQ — Politique de sauvegarde ISO 27001 A.8.13

La norme ISO 27001 impose-t-elle une fréquence minimale de sauvegarde ?

Non, la norme ne fixe pas de fréquence. Elle exige que les sauvegardes soient conformes à la politique de sauvegarde convenue, et que les sauvegardes soient testées régulièrement. La fréquence est déterminée par le RPO que l'organisation a défini pour chaque classe d'actif. En pratique, pour les données de niveau Confidentiel ou les applications critiques, une sauvegarde quotidienne est le minimum attendu par les auditeurs.

Comment prouver à un auditeur ISO 27001 que les sauvegardes fonctionnent ?

Les preuves d'efficacité des sauvegardes attendues par les auditeurs incluent : les rapports automatiques de sauvegarde montrant les succès et les éventuels échecs sur les 12 derniers mois, les comptes rendus de tests de restauration avec les données restaurées et le temps de restauration mesuré, les rapports d'exercices de disaster recovery, et le tableau de bord de supervision avec le taux de réussite des sauvegardes. La simple existence d'une solution de backup ne suffit pas — il faut démontrer qu'elle fonctionne réellement.

Architectures de sauvegarde résilientes face aux menaces actuelles

La politique de sauvegarde ne vaut que si son architecture sous-jacente résiste aux scénarios d'attaque contemporains. Les ransomwares modernes ciblent systématiquement les sauvegardes avant de chiffrer les données de production — selon Sophos, 94% des attaques ransomware en 2025 incluent une tentative de compromission ou de suppression des sauvegardes. Concevoir une architecture de sauvegarde résiliente nécessite donc d'intégrer le modèle de menace dès la conception, pas comme une couche additionnelle.

Le principe d'immutabilité des sauvegardes est devenu le pivot des architectures anti-ransomware. Une sauvegarde immuable ne peut être modifiée ou supprimée pendant une période définie, même par le compte qui l'a créée ou par un compte administrateur compromis. Les implémentations varient selon le tier de stockage : S3 Object Lock en mode WORM (Write Once Read Many) pour le cloud, bandes LTO-9 avec chiffrement physique pour l'air-gap, appliances de sauvegarde dédiées comme Veeam Immutable Backup ou Zerto avec journaux immuables pour les environnements on-premise. L'essentiel est que la suppression ou la modification de la sauvegarde nécessite une action physique hors de portée d'un attaquant ayant compromis le réseau.

L'air gap — l'isolation physique ou logique des sauvegardes par rapport au réseau de production — reste le seul moyen de garantir que les sauvegardes ne sont pas accessibles à un attaquant ayant compromis le domaine Active Directory ou les credentials cloud. Les implémentations modernes d'air gap logique incluent des comptes cloud séparés avec des politiques IAM strictes, des VPC ou VNets isolés sans peering avec l'infrastructure de production, et des politiques de rotation automatique des credentials d'accès. Un air gap logique bien configuré est plus pratique qu'une bande LTO physique tout en offrant une protection comparable contre la majorité des attaquants.

La sauvegarde des environnements cloud hybrides complexifie significativement la politique de sauvegarde. Les workloads cloud-natifs (containers Kubernetes, fonctions serverless, bases de données managées) ont des mécanismes de sauvegarde natifs différents des systèmes on-premise. Une politique cohérente doit couvrir : les snapshots EBS/Azure Disk pour les VMs cloud, les exports de bases de données managées (RDS, Azure SQL, Cloud SQL), les backups des configurations Kubernetes (etcd, manifestes GitOps), les données des services PaaS (Azure Blob, S3) et les configurations d'infrastructure as code (Terraform state). Chaque type de workload a son RTO/RPO naturel et ses contraintes de sauvegarde spécifiques.

Le test de restauration est l'indicateur de maturité le plus discriminant d'une politique de sauvegarde. Une sauvegarde non testée n'est pas une sauvegarde — c'est une illusion de sauvegarde. Les tests de restauration doivent être automatisés, fréquents (mensuels au minimum pour les données critiques), et couvrir des scénarios représentatifs : restauration d'un fichier unique, restauration d'une base de données entière sur un environnement isolé, restauration complète d'un serveur depuis zéro. Les résultats des tests — temps de restauration effectif, volume restauré, intégrité vérifiée — doivent être documentés et comparés aux objectifs RTO/RPO définis dans la politique. Tout écart doit déclencher une révision de l'architecture ou des objectifs.

La gestion du cycle de vie des sauvegardes doit équilibrer deux contraintes opposées : conserver suffisamment longtemps pour détecter les compromissions tardives (certains ransomwares patientent plusieurs semaines avant de chiffrer), et ne pas accumuler indéfiniment pour des raisons de coût et de conformité RGPD. Une politique de rétention différenciée — sauvegardes quotidiennes conservées 30 jours, hebdomadaires 6 mois, mensuelles 1 an — permet de couvrir la plupart des scénarios d'incident tout en maîtrisant les coûts. La rétention légale des données (obligatoire pour certains secteurs) peut nécessiter des durées plus longues pour des données spécifiques, distinctes des sauvegardes opérationnelles.

Indicateurs de maturité de la politique de sauvegarde

Évaluer la maturité de sa politique de sauvegarde nécessite des indicateurs concrets qui vont au-delà de la simple existence d'une documentation. Un modèle de maturité à cinq niveaux permet de situer l'organisation et d'identifier les prochaines priorités d'amélioration.

Au niveau 1 (ad hoc), les sauvegardes sont réalisées de manière irrégulière, sans politique documentée, sur des supports non inventoriés. Les restaurations n'ont jamais été testées formellement. Au niveau 2 (défini), une politique de sauvegarde existe et est appliquée de manière cohérente pour les systèmes critiques identifiés. Les RTO/RPO sont définis. Au niveau 3 (géré), les sauvegardes sont automatisées et monitored. Des tests de restauration sont planifiés et documentés. L'immutabilité est implémentée pour les données critiques. Au niveau 4 (mesuré), des métriques de couverture, de succès des sauvegardes et des temps de restauration sont collectées et analysées. Les exceptions sont formellement gérées. Au niveau 5 (optimisé), les politiques de sauvegarde s'adaptent automatiquement aux changements d'infrastructure, les tests de restauration sont continus et les architectures de sauvegarde intègrent nativement les nouvelles menaces. La plupart des organisations sous ISO 27001 visent le niveau 3 pour la certification et le niveau 4 pour les systèmes les plus critiques.