AZ Monica paralysé par rançongiciel: pourquoi des sauvegardes immuables

Un hôpital belge (AZ Monica, Anvers) a dû couper tous ses serveurs le 13 janvier 2026, annuler des opérations et transférer des patients après une cyberattaque, vraisemblablement par rançongiciel. Voici comment des sauvegardes immuables et isolées évitent le pire — et répondent à DORA/NIS 2.

Les faits

Le 13 janvier 2026, l’hôpital AZ Monica (Anvers/Deurne) a « débranché » l’intégralité de ses serveurs à 06:32, suspendu les procédures programmées et redirigé des patients critiques, son service des urgences ne fonctionnant qu’en capacité réduite. L’établissement a parlé d’une cyberattaque en cours, avec bascule en mode dégradé et cellule de crise activée. Des sources locales ont rapidement évoqué un rançongiciel. BleepingComputer a confirmé l’arrêt des serveurs et les transferts de patients dans la foulée de l’attaque, en publiant la déclaration de l’hôpital. Voir l’article de référence: BleepingComputer.

Dans les 24–48 heures, plusieurs médias belges et européens ont fait état d’un nombre significatif d’interventions reportées: jusqu’à 70 opérations annulées sur la première journée selon Techzine (Techzine). The Register a, de son côté, décrit l’arrêt de serveurs, des annulations d’interventions et des transferts de patients critiques vers d’autres hôpitaux (The Register). Un mois après, le retour aux opérations normales n’était pas encore total selon des suivis de presse spécialisés (Cyberwarzone). Bilan: des soins reportés, plusieurs jours d’arrêt de systèmes cliniques, et une mobilisation d’urgence coûteuse.

Ce cas n’est pas isolé: les campagnes rançongiciels visent encore les services essentiels en Europe, et les délais de reprise dépassent souvent la semaine quand les sauvegardes sont atteintes ou chiffrées.

Le cadre légal qui s’applique

Pour les établissements financiers, DORA impose des exigences très claires en matière de continuité et de sauvegardes: DORA, article 12: « politiques et procédures de sauvegarde, méthodes de restauration et de reprise »; l’activation des sauvegardes ne doit pas mettre en péril la disponibilité, l’intégrité ou la confidentialité des données. Référence officielle: EBA — DORA, art. 12 et texte EUR‑Lex EUR‑Lex 2022/2554. Pour un panorama pratique côté Luxembourg, voir également nos pages sur les exigences DORA en matière de résilience opérationnelle.

Pour les entités essentielles/importantes hors secteur financier (santé incluse), NIS 2 exige des mesures de gestion des risques couvrant la continuité et la reprise: NIS 2, article 21(2)(c): « continuité des activités, telle que la gestion des sauvegardes et la reprise après sinistre, et gestion de crise ». Référence officielle: EUR‑Lex 2022/2555. Au Luxembourg, l’ILR rappelle aussi le devoir de notifier un incident significatif dans les 24 heures (alerte précoce), puis 72 h et rapport final à 1 mois: ILR — FAQ NIS 2. Pour les responsables conformité, notre synthèse des obligations NIS 2 pour les entités essentielles peut servir de guide.

Traduction opérationnelle: un organisme soumis à NIS 2 ou à DORA doit prouver qu’il peut restaurer rapidement ses services à partir de sauvegardes intègres, non altérables par l’attaquant, stockées dans des environnements isolés et testées régulièrement.

La solution technique à déployer

Objectif: survivre à un chiffrement massif et à l’exfiltration en restaurant vite, sans payer.

1) Sauvegardes immuables (WORM)

• Principe: rendre les copies non modifiables/non supprimables pendant une rétention donnée (verrouillage objet S3/Object Lock, snapshots immuables, WORM sur baies, coffres numériques).
• Effet: même avec des comptes compromis, le rançongiciel ne peut ni chiffrer ni purger l’historique des sauvegardes.

2) Isolation réseau et séparation d’autorité

• Stocker la sauvegarde primaire hors domaine Active Directory de production, avec cloisonnement réseau (air‑gap logique/physique) et comptes d’administration distincts (tiering).
• Accès via bastion, MFA renforcée et délégation minimale. Pas de montages permanents; privilégier des fenêtres d’export/ingest contrôlées.

3) Règle 3‑2‑1‑1‑0 modernisée

• 3 copies, 2 médias, 1 copie hors site, 1 immuable/offline, 0 erreur vérifiée via tests de restauration automatisés et contrôles d’intégrité (checksums).
• Ajoutez la rotation de clés et la rétention alignée sur vos RPO/RTO (ex. 7/30/90 jours).

4) Contrôles d’accès et durcissement

• MFA phishing‑resistant pour consoles de sauvegarde; coffre‑fort d’identités pour les comptes « break‑glass »; journaux inviolables.
• Filtrage egress/ingress des dépôts de sauvegarde; signatures des backups; chiffrement au repos/en transit avec clés HSM.

5) Tests réguliers de reprise

• Exercices mensuels de restauration granulaire et trimestriels de reprise applicative bout‑en‑bout (EHR/ERP, bases, fichiers, VM/containers).
• Mesure systématique des RPO/RTO, preuves horodatées et traçabilité (chaîne de conservation) pour audits et notifications.

Référentiels

• ISO/IEC 27001:2022 Annexe A.8.13 (Sauvegarde), A.5.30 (Continuité TIC).
• NIST CSF 2.0: PR.DS‑08 (données sauvegardées et protégées), RS.RP‑01/02 (plans de réponse/reprise testés).
• CIS Controls v8: Control 11 (Data Recovery), Control 4 (Access Management — comptes admin séparés).

Comment Luxgap déploie cela

• Gouvernance ISO 27001: cadrage des exigences DORA/NIS 2, définition des RTO/RPO par processus métier, cartographie des applications critiques, et rédaction des politiques « Backup & Recovery » alignées sur l’art. 12 DORA / art. 21 NIS 2. Nous opérons avec des Lead Implementer/Auditor certifiés pour documenter les preuves attendues par les auditeurs. Pour accélérer votre démarche, notre offre plan de continuité et reprise (BCP/DRP) orientée DORA apporte méthode et outillage.

• SOC managé 24/7: supervision des consoles de sauvegarde et dépôts immuables (alertes suppression/modification anormale, échecs de jobs, exfiltration), détection de patterns ransomware (burst d’écritures, extensions suspectes), intégration SIEM pour forensique et chronologie d’incident. En pratique, notre SOC managé pour la détection d’incident s’interface avec vos sauvegardes et vos EDR/XDR.

• Consultants CISO/DPO externalisés: orchestration des tests de restauration, plan de communication de crise, et préparation des notifications ILR/CNPD/CER selon les délais (24h/72h/1 mois) avec journalisation des décisions et de la chaîne de conservation des preuves.

En pratique, nous:

1. Auditons votre architecture (domaines AD, chemins de sauvegarde, surfaces d’attaque des appliances).
2. Déployons une cible immuable isolée (WORM + réseau dédié), avec comptes et rôles séparés.
3. Mettons en place des playbooks SOAR pour enclencher « backup isolation » dès détection ransomware.
4. Industrialisons les tests de restauration (runbooks automatisés, métriques RTO/RPO, preuve horodatée).
5. Alignons la documentation de conformité et les indicateurs pour DORA/NIS 2.

Cas concret au Luxembourg ou en UE

Une institution financière européenne soumise à DORA opérait des sauvegardes « connectées » à son domaine de production. En 6 semaines, nous avons:

• migré les dépôts vers un stockage objet avec verrouillage WORM 30/90 jours;
• séparé l’administration (comptes break‑glass hors SSO, bastion, MFA FIDO2);
• ajouté une réplication chiffrée vers un site secondaire isolé;
• scripté des tests de restauration mensuels (bases + VM critiques) avec rapport automatique.

Résultat: RTO de 6h démontré pour l’ERP et 2h pour la messagerie; preuves prêtes pour audit interne, et scénario de notification ILR/CSSF documenté.

Premiers pas concrets

1. Évaluez vos sauvegardes: où sont‑elles stockées, qui peut les supprimer, et quelle est la dernière restauration testée « bout‑en‑bout »?
2. Activez l’immuabilité: si vous êtes sur objet (S3/compatibles), activez Object Lock (mode Compliance) et définissez une rétention adaptée; sinon, utilisez snapshots immuables/appliances WORM.
3. Isolez: sortez vos dépôts du domaine de prod, créez un réseau dédié avec bastion et accès just‑in‑time; interdisez les montages permanents.
4. Séparez les rôles: comptes d’admin de sauvegarde distincts, MFA phishing‑resistant, coffre‑fort pour secrets et clés.
5. Testez et mesurez: restaurez un service critique cette semaine; capturez RTO/RPO, écarts et actions; planifiez un exercice mensuel et un test de crise trimestriel.

Sources officielles

Actualité — AZ Monica (Anvers), 13–14 janvier 2026:

• BleepingComputer (arrêt serveurs, urgences réduites, transferts).
• The Register (annulations d’opérations, transferts).
• Techzine (≈70 opérations annulées jour 1).

Réglementaire — obligations de sauvegarde/continuité:

• DORA, Règlement (UE) 2022/2554, art. 12 — EBA — DORA art. 12 et EUR‑Lex.
• NIS 2, Directive (UE) 2022/2555, art. 21(2)(c) — EUR‑Lex.
• Luxembourg — Notification des incidents (24h/72h/1 mois) — ILR — FAQ NIS 2.

En clair: l’attaque AZ Monica a montré que « couper pour sauver » immobilise les soins et coûte cher. Avec des sauvegardes immuables isolées, testées et gouvernées selon DORA/NIS 2, vous restaurez vite — sans payer. Luxgap peut vous y amener en 4 à 8 semaines, preuves d’audit incluses.