ENISA 2026 : sauvegardes séparées et testées, alignées DORA

ENISA — « Cybersecurity guide for SMEs » (juin 2026) exige des sauvegardes séparées et testées

Excerpt — ENISA vient de mettre à jour son guide « Cybersecurity for SMEs »: sauvegardes séparées du SI de production et tests de restauration réguliers. Voici comment des sauvegardes immuables et isolées répondent concrètement à DORA (art. 12) et coupent l’herbe sous le pied des rançongiciels.

Les faits

Le guide « Cybersecurity for SMEs » de l’ENISA, mis en ligne au printemps 2026, insiste clairement sur quatre règles de sauvegarde: automatisation, séparation du périmètre de production, chiffrement des copies et tests réguliers de restauration — idéalement un test de restauration complète de bout en bout. C’est écrit noir sur blanc dans la section « Secure Backups » du document officiel (ENISA, Cybersecurity guide for SMEs, 2026).

Pourquoi ce rappel tombe-t-il à point nommé? Parce que les attaquants ciblent désormais… vos sauvegardes. Le 9 juin 2026, Veeam a patché une faille critique (CVE‑2026‑44963) permettant à un simple utilisateur de domaine d’exécuter du code à distance sur le serveur de sauvegarde si celui‑ci est joint à l’Active Directory. Une porte royale vers la corruption des backups avant chiffrement et extorsion. Détail et correctif: BleepingComputer, 9 juin 2026.

Le cadre légal qui s’applique

Pour les entités financières (banques, PSF, fonds, assureurs, PSP…), le Règlement DORA impose une politique de sauvegarde et des procédures de restauration/récupération robustes. L’article 12 (« Backup policies and procedures, restoration and recovery procedures and methods ») exige notamment que les systèmes de sauvegarde puissent être activés sans compromettre la sécurité, et que des capacités redondantes adéquates soient maintenues — au‑delà d’une simple copie ponctuelle. Référence officielle: EUR‑Lex — Règlement (UE) 2022/2554 (DORA), art. 12.

Cette exigence DORA se combine avec NIS 2 (pour les opérateurs essentiels et importants) et, côté RGPD (art. 32), avec l’obligation de garantir la disponibilité et l’intégrité des données personnelles. Le message du régulateur européen est donc cohérent: vos sauvegardes doivent être utilisables en cas d’incident, et leur architecture doit résister aux attaques visant spécifiquement… les sauvegardes.

La solution technique à déployer

Concrètement, une architecture « sauvegardes immuables + isolation réseau » apporte les contrôles attendus par l’ENISA et DORA :

• Immuabilité des sauvegardes (WORM, verrouillage d’objets S3, snapshots immuables, air‑gap logique/physique). Objectif: empêcher la modification/suppression pendant une période de rétention. Alignements: ISO/IEC 27001:2022 Annexe A 5.34 (prévention de la suppression), A 8.13 (sauvegarde), NIST SP 800‑53 CP‑9/10.
• Séparation stricte du plan de sauvegarde et du domaine de production (comptes, ACL, réseau). Le serveur de sauvegarde ne doit pas faire partie du même domaine Active Directory que les postes/serveurs qu’il protège. Contrôle d’accès MFA + bastion.
• Chiffrement « at rest » et « in transit » avec gestion de clés séparée (HSM/KMS distinct du cloud primaire — principe d’isolation des secrets), pour contrer l’exfiltration et satisfaire RGPD art. 32.
• Segmentation réseau et micro‑segmentation des flux de sauvegarde (ports/chemins minimaux, DNAT contrôlé, pare‑feu applicatifs) pour réduire le mouvement latéral vers les coffres de sauvegarde.
• Tests de restauration réguliers (runbooks de reprise, RTO/RPO mesurés, exercices documentés). Exigence soulignée par l’ENISA: « test of a full restore from start to finish » — indispensable pour DORA art. 12.
• Surveillance et durcissement de la plateforme de backup (journaux inviolables, EDR sur serveurs de sauvegarde, détection de sabotages des policies de rétention, alerte sur effacements/baisse de volumétrie anormale).

En complément, les « Top‑10 mesures anti‑rançongiciel » du BSI rappellent que la conception du dispositif de sauvegarde est la mesure préventive la plus importante pour préserver la disponibilité en cas d’attaque (BSI — Data backup concept).

Comment Luxgap déploie cela

• Notre gouvernance ISO 27001 : nous cadrons la politique de sauvegarde (PRA/PCA), les rôles, la matrice de flux, la gestion de clés et la preuve de conformité à DORA art. 12. Nos consultants Lead Implementer/Lead Auditor traduisent les exigences en contrôles vérifiables (Annexe A 8.13, 5.30, 5.34).
• Notre SOC managed : nous intégrons les journaux des coffres/baies/objets (immutabilité, échecs de lock, suppressions massives), corrélons avec l’EDR et levons une alerte si un compte essaie de casser une rétention ou si un flux inattendu touche le réseau de sauvegarde.
• Nos consultants DPO et CISO externalisés : nous alignons la stratégie de sauvegarde aux obligations RGPD (art. 32) et NIS 2, rédigeons les runbooks de restauration, planifions et chronométrons les tests de reprise pour démontrer RTO/RPO auprès des autorités (CSSF/ILR) en cas d’incident.

Notre approche est pragmatique: un « design cible » en 2 à 4 ateliers, une mise en œuvre par itérations (coffre immuable, découplage AD, bastion, EDR), puis un exercice de restauration complet et documenté en « evidence pack » DORA.

Cas concret au Luxembourg ou en UE

Exemple réaliste: une société de gestion luxembourgeoise soumise à DORA disposait d’un serveur de sauvegarde joint à son AD et d’instantanés modifiables. En six semaines, nous avons :

• basculé les sauvegardes critiques vers un data vault immuable (verrou S3 + rétention WORM),
• dissocié le plan de contrôle (comptes administrateurs locaux dédiés, bastion avec MFA),
• segmenté les flux (VLAN dédiés, règles L4/L7 minimales, journalisation des copies),
• exécuté un test de restauration bout‑en‑bout de l’ERP en site de repli, avec RTO mesuré et preuves signées.

Résultat: conformité démontrable à DORA art. 12, réduction du risque de sabotage de sauvegardes, et capacité de reprise testée — éléments attendus par l’ENISA dans ses recommandations.

Premiers pas concrets

1. Isoler votre sauvegarde cette semaine : si votre serveur de backup est dans le même AD que la production, créez d’urgence un compte d’administration local dédié et un saut via bastion MFA; bloquez les flux non nécessaires.
2. Activer l’immuabilité : si vous utilisez un stockage objet compatible S3, activez Object Lock (mode compliance) sur un bucket « coffre » avec rétention minimale (ex. 14–30 jours) et versioning.
3. Patcher la pile de sauvegarde : appliquez les derniers correctifs de votre logiciel de backup et vérifiez l’absence d’exposition réseau inutile — voir l’alerte récente Veeam CVE‑2026‑44963.
4. Planifier un test de restauration complet : choisissez un système critique, définissez un scénario et mesurez RTO/RPO. Conservez journaux, captures et attestations — ce seront vos evidence DORA.
5. Documenter la politique : formalisez votre politique de sauvegarde et vos procédures de restauration (qui, quoi, quand), en vous alignant sur l’article 12 de DORA et les recommandations de l’ENISA.

Sources officielles

• ENISA — Cybersecurity guide for SMEs, section « Secure Backups » (juin 2026) : PDF
• EUR‑Lex — Règlement (UE) 2022/2554 (DORA), article 12 : texte officiel
• Actualité technique — Veeam corrige une faille RCE affectant les serveurs de sauvegarde (9 juin 2026) : BleepingComputer
• BSI — Ransomware : « Data backup concept » (rappel des mesures structurantes) : bsi.bund.de