Stratégie de sauvegarde contre les rançongiciels : sauvegardes immuables, air-gap et restauration rapide

Une stratégie de sauvegarde contre les ransomwares n’est aujourd’hui plus une question de « avons‑nous des sauvegardes ? » mais de « pouvons‑nous vraiment RESTaurer proprement après une attaque ciblée ? ». Les groupes de ransomware n’encryptent plus seulement les partages de fichiers : ils visent délibérément les serveurs de sauvegarde, les référentiels, les comptes administrateurs, les hôtes hyperviseurs et les bases de données. Dans de nombreux incidents, le véritable désastre n’est pas le chiffrement lui‑même, mais le fait que les sauvegardes sont soit chiffrées elles‑mêmes, soit supprimées, manipulées ou tout simplement non RESTaurables.

Cet article montre de manière pragmatique comment combiner trois composants : Immutable Backups (sauvegardes immuables), Air-Gap (séparation technique ou organisationnelle) et une RESTauration rapide via des runbooks testés. L’accent est mis sur la réalité opérationnelle : identités, droits, chemins réseau, retention, monitoring, validation de RESTauration – et sur les pièges typiques qui coûtent des minutes ou des jours en période de crise. Comme de nombreux environnements d’entreprise utilisent MariaDB (p. ex. pour des portails, de la supervision, des outils d’inventaire ou des logiciels métier sur mesure), le guide inclut aussi des bonnes pratiques concrètes pour des sauvegardes cohérentes avec MariaDB et le Point-in-Time-Recovery.

Backup-Strategie gegen Ransomware: Warum Ransomware Backups heute gezielt angreift

Le ransomware est désormais le plus souvent une attaque en plusieurs étapes : Initial Access (p. ex. via phishing, passerelles VPN exploitées, services web non patchés), mouvement latéral, Privilege Escalation et ensuite le déploiement ciblé du chiffrement. Les sauvegardes constituent une cible primaire, car des sauvegardes opérationnelles sapent le levier d’extorsion.

Points d’attaque typiques dans le contexte des sauvegardes :

• Backup-Server als „Single Point of Control“ : si la console de sauvegarde peut écrire/supprimer à l’échelle du domaine, un compte administrateur compromis suffit pour provoquer une défaillance totale.
• Repository-Manipulation : suppression de points de RESTauration, réduction de la conservation (Retention) ou sauvegardes « synthétiques » qui prolongent des données déjà chiffrées.
• VSS/Snapshots und Storage-Snapshots : Windows VSS (Volume Shadow Copy Service) et les snapshots de stockage sont supprimés pour éliminer les points de RESTauration rapides.
• Credential-Harvesting : les identifiants de sauvegarde se trouvent souvent en clair dans des scripts, sur des jump hosts ou en tant que comptes de service réutilisés.
• Backup-Ketten kompromittieren : les chaînes incrémentales (p. ex. forever incremental) peuvent être « empoisonnées » si la base n’est pas protégée.

La conséquence : la conception d’une stratégie de sauvegarde doit non seulement « copier des données », mais aussi limiter les vecteurs d’attaque, empêcher les manipulations et rendre la RESTauration prévisible.

Schutzziele sauber definieren: RTO, RPO und „Clean RESTore“

Avant de choisir une technologie, définissez les objectifs de protection :

• RPO (Recovery Point Objective) : quelle perte de données est acceptable au maximum ? Exemple : 15 minutes pour une MariaDB, 24 heures pour une archive.
• RTO (Recovery Time Objective) : à quelle vitesse un service doit‑il être remis en service ? Exemple : 2 heures pour l’authentification/intégrations ERP, 8 heures pour le reporting.
• Clean RESTore : RESTauration dans un état propre. Cela signifie : vous devez empêcher de réinjecter des logiciels malveillants, des comptes compromis ou des configurations manipulées.

Dans les scénarios de ransomware, la récupération échoue souvent en raison d’un manque d’ordre d’exécution (quoi d’abord ?), de l’absence d’identifiants (Break-Glass), de médias d’installation/clefs non disponibles ou parce que les processus de RESTauration sont trop lents, n’ayant jamais été testés de manière réaliste. Un bon concept de sauvegarde est donc toujours aussi un plan de reprise.

Composant 1 : bien comprendre et bien utiliser les sauvegardes immuables

Les sauvegardes immuables sont des copies qui ne peuvent pas être modifiées ou supprimées pendant une durée définie — pas même par des administrateurs. Selon la technologie, cela se met en œuvre sous forme de WORM (Write Once, Read Many), de « Object Lock » dans un stockage d’objets compatible S3 ou d’une immutabilité propre au référentiel.

Ce qui importe pour l’immutabilité en pratique

L’immutabilité n’est efficace qu’autant que le contrôle sur les « Schalter » est strict :

• Identité indépendante : si les mêmes comptes d’administrateur de domaine peuvent également modifier les politiques d’Object-Lock, l’immutabilité devient vulnérable. L’objectif est une séparation claire entre les mondes d’identité et de droits.
• Protection « Write-Protect » au niveau politique : idéalement, la rétention ne doit pas pouvoir être raccourcie (mode Compliance/Governance vs. verrou réel). Vérifiez si un compte « Root » peut lever la protection.
• Sûreté temporelle : dans certains designs, le temps/horloge est un facteur. Si un attaquant manipule les sources de temps ou rend la politique « expirée », cela devient critique. Utilisez des sources NTP sécurisées et une supervision de la dérive temporelle.
• Minimiser le chemin réseau : moins il y a de systèmes disposant de droits d’écriture sur le dépôt immuable, mieux c’est.

Pièges typiques pour les sauvegardes immuables

• Immutabilité seulement « sur le papier » : un snapshot de stockage n’est pas automatiquement immuable si l’administrateur du stockage peut le supprimer.
• Rétention trop courte : de nombreuses attaques sont détectées tard. Si vos sauvegardes immuables ne conservent que 7 jours, cela peut être insuffisant.
• Pas de tests de RESTauration : immuable ne signifie pas automatiquement lisible ou cohérent. Corruption, catalogues erronés ou clés manquantes sont des risques réels.

Règle pratique : l’immutabilité est un mécanisme de contrôle contre la manipulation, pas un substitut à plusieurs copies ni à un Air-Gap.

Composant 2 : Air-Gap — technique, organisationnel ou les deux

Air-Gap signifie séparation : les sauvegardes ne sont pas en permanence accessibles depuis le réseau compromis. Cela peut être mis en œuvre de manière « dure » (médias physiquement séparés) ou « douce » (chemins réseau temporairement séparés, identifiants distincts, transferts unidirectionnels).

Variantes d’Air-Gap qui fonctionnent en exploitation

• Médias hors ligne : bande (LTO) ou unités de stockage amovibles, qui sont physiquement séparées après la sauvegarde. Avantage : très résistant aux attaques réseau. Inconvénient : discipline des processus, logistique, temps de RESTauration.
• Réseau de sauvegarde isolé : Serveur/Repository de sauvegarde dans un segment séparé, avec des règles de pare-feu RESTrictives et sans accès Internet général. Important : la segmentation n’est pas un air gap si un attaquant peut néanmoins se déplacer via des comptes administrateurs.
• Transfert unidirectionnel / Staging : Un dépôt de „landing“ reçoit les sauvegardes, un second système extrait (pull) les données et n’est pas inscriptible depuis la zone de production. Cela réduit le risque que des comptes de production suppriment le « dernier » stockage de sauvegarde.
• Stockage d’objets cloud avec Object Lock : Ce n’est pas un air gap classique, mais en combinaison avec une séparation stricte des identités et des droits API minimaux, c’est souvent un composant offsite très robuste.

L’important est la question : Comment votre conception empêche-t-elle qu’un Domain-Admin compromis administre également l’air gap ? La réponse est généralement : identités séparées, systèmes séparés, chemins d’accès séparés (Jump-Hosts) et, autant que possible, des flux de données basés sur le pull.

Composant 3 : la RESTauration rapide est un objectif de conception, pas un après-coup

« Rapide » ne dépend pas seulement de la bande passante et du stockage, mais des procédures et de la parallélisation. En cas de ransomware, vous devez souvent réinstaller en parallèle, changer les credentials, isoler le réseau, constituer des preuves forensiques et prioriser les services.

Priorités de RESTauration : ce qui doit redémarrer en premier

Élaborez une séquence technique de remise en service. Fréquemment recommandée :

1. Identité et services de base : DNS, NTP, services d’annuaire (avec une vigilance particulière), PKI / certificats, Jump-Host.
2. Couche virtualisation/compute : gestion des hyperviseurs, accès au stockage, le cas échéant orchestration de conteneurs.
3. Plateforme de données : MariaDB/PostgreSQL/SQL Server, queues de messages, services de fichiers centraux.
4. Applications cœur : logiciels métiers proches du processus, intégrations, interfaces (passerelles API).
5. Systèmes en aval : BI/Reporting, Dev/Test, archivage.

Cette séquence doit s’adapter à votre paysage. L’essentiel : évitez les dépendances qui bloqueraient la RESTauration (p.ex. « les clés de sauvegarde se trouvent dans le partage de fichiers chiffré »).

La règle 3-2-1-1-0 comme garde-fou (et ce qu’elle ne résout pas)

La règle connue 3-2-1 (3 copies, 2 médias, 1 offsite) est souvent étendue dans le contexte ransomware à la 3-2-1-1-0 :

• 3 copies : données de production + au moins deux copies de sauvegarde.
• 2 supports/targets différents : p.ex. disque + stockage d’objets ou disque + bande.
• 1 offsite : séparation géographique (cloud ou second centre de données).
• 1 copie hors ligne ou immuable : c’est le levier anti-ransomware.
• 0 erreurs lors de la vérification : contrôles réguliers et tests de RESTauration, pas seulement « le job était vert ».

Ce que la règle ne résout pas : droits erronés, comptes admin compromis, runbooks manquants, clés/mots de passe absents ou voies de RESTauration trop lentes. Pour cela, vous avez besoin de mesures opérationnelles concrètes.

Architecture de sauvegarde contre le ransomware : schéma de référence pour l’exploitation

Un modèle opérationnel pour des environnements de taille moyenne est une chaine de sauvegarde multiniveaux :

• Dépôt de sauvegarde primaire (rapide) : pour un RTO court, RESTaurations rapides (p.ex. les 7–30 derniers jours), idéalement proche du compute (mais segmenté séparément).
• Dépôt immuable/offsite : stockage d’objets avec immutabilité ou second système avec fonction WORM, rétention longue.
• Copie hors ligne optionnelle : bandes ou médias hors ligne exportés périodiquement pour « pire des cas » (p. ex. si des comptes Cloud sont affectés).

Les directions d’accès sont essentielles : accès en écriture uniquement là où c’est strictement nécessaire ; pour la copie « finale », privilégiez les mécanismes pull. Moins de systèmes peuvent supprimer les sauvegardes, mieux c’est.

Identitäten und Rechte: Der häufigste Grund, warum Backups mitsterben

De nombreuses architectures de sauvegarde échouent non pas à cause du stockage, mais à cause de la gestion des identités & des accès. Quelques principes robustes :

• Les comptes de sauvegarde ne sont pas des administrateurs de domaine : séparez les rôles. En règle générale, la sauvegarde nécessite des droits en lecture sur les sources et des droits définis sur les cibles, mais pas de privilèges étendus dans l’annuaire.
• Chemins d’administration séparés : console de sauvegarde et administration du dépôt uniquement via des Jump-Hosts durcis (pas un notebook administrateur ordinaire).
• MFA und Conditional Access : là où c’est possible, les imposer. Particulièrement pour les Cloud-APIs et la gestion des sauvegardes.
• Break-Glass-Accounts : accès d’urgence documentés hors ligne, strictement surveillés et utilisés uniquement pour la récupération.
• Secret-Management : ne « cachez » pas mots de passe/keys dans des scripts ou des planificateurs de tâches. Utilisez un coffre à secrets ou, au minimum, les stores d’identifiants sécurisés natifs de l’OS.

Si vous ne pouvez prioriser qu’une mesure : protégez les identités de sauvegarde aussi fortement que votre identité root de domaine ou cloud. En cas d’incident, c’est précisément ce levier qui détermine si vous êtes capable de RESTaurer.

MariaDB unter Ransomware-Druck: konsistente Backups, PITR und schnelle RESTores

MariaDB est souvent un composant central des solutions d’entreprise numériques. En cas de ransomware, la base de données est doublement critique : (1) elle contient des données opérationnelles, (2) elle est fréquemment la cible de dommages indirects (verschlüsselte Storage-LUN, manipulierte Binlogs, zerstörte InnoDB-Tabellenräume).

Quels types de sauvegarde MariaDB conviennent à quel usage

• Sauvegarde logique (dump) : exporte le contenu SQL. Avantage : portable, facile à vérifier. Inconvénient : lente sur de grands volumes, RESTauration longue, pas idéal pour un RTO court.
• Sauvegarde physique (basée sur fichiers/blocs) : copie les fichiers de la base de données (p. ex. InnoDB). Avantage : RESTauration plus rapide possible. Inconvénient : la consistance exige un mécanisme propre (outil de hot-backup ou snapshots correctement orchestrés).
• Point-in-Time-Recovery (PITR) : combinaison d’une sauvegarde complète + binlogs (journaux binaires). Avantage : RPO jusqu’à quelques minutes/secondes. Inconvénient : les binlogs doivent être complets, inchangés et temporellement cohérents.

Pour la récupération après ransomware, le PITR fait souvent la différence entre « la dernière sauvegarde de la nuit » et « nous perdons seulement quelques minutes ». Toutefois, le PITR n’est fiable qu’autant que votre discipline des binlogs (rotation, envoi, protection, surveillance).

Configuration pratique : sauvegarde complète + transfert des binlogs (avec destination immuable)

Un schéma éprouvé : sauvegardes complètes régulières (p. ex. la nuit) et copie continue des binlogs vers une cible séparée, idéalement immuable. Ainsi, vous pouvez revenir à un instant avant le chiffrement.

Conditions importantes dans MariaDB :

• Journalisation binaire activée : les binlogs sont les journaux des modifications. Sans eux, pas de PITR.
• GTID ou gestion propre des positions : facilite le replay reproductible, mais dépend de votre modèle de réplication/exploitation.
• Chemin d’export distinct : ne conservez pas les binlogs uniquement localement sur le même volume que la base de données.

Extraits de configuration d’exemple (ajustez le chemin/les paramètres à votre environnement) :

[mysqld]
log_bin = mariadb-bin
binlog_format = ROW
expire_logs_days = 3
sync_binlog = 1
server_id = 123

Pourquoi ce choix : les binlogs basés sur ROW sont en général plus fiables pour le PITR et la réplication dans des charges hétérogènes que STATEMENT (moins de surprises dues à des statements non déterministes). Une expiration locale courte ne protège pas contre les attaques, mais réduit l’espace disque local — le vrai concept de protection est le transfert hors-site/immuable.

Transfert des binlogs avec gestion robuste des erreurs (exemple via rsync over SSH vers une cible séparée, idéalement vers une destination qui n’autorise pas de droits de suppression en retour) :

#!/usr/bin/env bash
set -euo pipefail

SRC_DIR="/var/lib/mysql"
DEST_HOST="backup-ingest.example.net"
DEST_DIR="/data/mariadb-binlogs/$(hostname -f)/"

# Nur Binlogs übertragen, keine Löschungen auf der Gegenseite auslösen.
# So vermeiden Sie, dass lokale Rotation remote historische Logs entfernt.
rsync -av --ignore-missing-args 
  --include='mariadb-bin.*' --exclude='*' 
  "${SRC_DIR}/" "${DEST_HOST}:${DEST_DIR}"

Quand cela échoue : si le serveur cible appartient au même périmètre d’identité et d’administration que la production, un attaquant peut compromettre le serveur cible ou les clés SSH. Pour des scénarios sévères, un modèle de type pull est plus robuste : le serveur cible récupère les logs, la production n’a aucun droit d’écriture sur le stockage final immuable.

Runbook de RESTauration pour MariaDB : de « nous avons des sauvegardes » à « nous sommes de nouveau en ligne »

Un runbook minimalement utilisable pour le PITR contient toujours :

• Quelle version de sauvegarde est « propre » ? (point dans le temps, indicateurs, validation par le responsable de l’incident)
• Où se trouvent la sauvegarde complète, les clés, les sommes de contrôle, les binlogs ?
• Ordre de RESTauration : RESTaurer la sauvegarde complète, puis appliquer les binlogs jusqu’au point dans le temps cible
• Validation : contrôles des tables, vérifications de santé de l’application, vérification des utilisateurs/Grants
• Repli : si le PITR échoue, revenir au dernier état cohérent de la sauvegarde complète

Prévoyez en outre un environnement d’isolation pour la RESTauration : RESTaurer d’abord dans un réseau cloisonné (ne pas faire confiance aux clients « propres »), puis basculer.

Tests de RESTauration : ce que vous devez tester (et ce qui est souvent oublié)

«Backup-Job erfolgreich» n’est pas une garantie de RESTauration. Les tests de RESTauration doivent être réalistes, tout en RESTant scalables. En pratique, une combinaison des éléments suivants fait ses preuves :

• Échantillonnages automatisés : petites RESTaurations quotidiennes/hebdomadaires (un sous-dossier d’un partage de fichiers, une petite DB, une instance VM/container).
• Exercice de récupération trimestriel : redémarrage complet d’un service critique incluant ses dépendances, mesure du temps pour le RTO.
• Vérifications d’intégrité : sommes de contrôle, vérification de catalogue, comparaison des nombres de fichiers/ACL, contrôles de cohérence de DB.

Pour MariaDB, des validations pertinentes incluent par exemple la capacité à démarrer, les logs de récupération InnoDB, des requêtes ponctuelles et un contrôle de santé applicatif défini (par ex. connexion + transaction core). Important : les tests ne doivent pas mettre en danger le système de production ; effectuez la RESTauration dans un environnement de test ou sur des hôtes isolés.

Liste de contrôle : durcissement de l’infrastructure de sauvegarde contre les ransomwares

La liste ci‑dessous est conçue comme un « Quick Audit ». Elle ne remplace pas un concept de sécurité complet, mais couvre les vulnérabilités les plus fréquentes.

Repository et stockage

• Au moins une copie est immutable (WORM/Object Lock) ou hors ligne.
• La rétention ne peut pas être raccourcie par des administrateurs ordinaires.
• Le repository n’est pas joint au domaine, sauf si cela est strictement nécessaire.
• Pas de partages SMB/NFS généraux accessibles en écriture depuis de nombreux serveurs.
• Surveillance des opérations de suppression/réécriture inhabituellement fréquentes (si le système fournit des événements).

Réseau et chemins d’accès

• Le réseau de sauvegarde est segmenté ; les règles de pare‑feu sont minimales (sources → backup, pas « any‑any »).
• L’accès de gestion se fait uniquement via un jump‑host ; les accès administrateur sont consignés.
• Pas d’accès Internet direct pour les serveurs de sauvegarde, sauf exceptions dûment justifiées (mises à jour via proxy/repo).

Identités, secrets, exploitation

• Comptes de sauvegarde séparés, pas de réutilisation des mots de passe, MFA autant que possible.
• Rotation régulière des clés/mots de passe et processus défini pour la rotation d’urgence.
• Procédure de break‑glass documentée (hors ligne), testée et surveillée.
• Les runbooks sont à jour : chemins, IPs, processus de gestion des accès, priorités.

Débogage : scénarios d’erreur fréquents et contre-vérifications rapides

« Immutable » peut quand même être supprimé

Contre‑vérification : qui peut modifier les politiques ? Existe‑t‑il un admin root/tenant capable de réduire la rétention ou de désactiver l’Object Lock ? Vérifiez les rôles, les clés API et si le système de sauvegarde possède des droits « trop » étendus.

Les sauvegardes existent, mais la RESTauration est trop lente

Contre‑vérification : le chemin de RESTauration est souvent différent du chemin de sauvegarde. Mesurez le débit de RESTauration vers le système cible (I/O, réseau, décompression/dédoublonnage). Prévoyez des RESTaurations parallèles, des données priorisées (p.ex. uniquement les DB critiques en premier) et des RESTaurations en phases (« staged RESTore »).

La sauvegarde MariaDB démarre, mais le PITR échoue

Contre‑vérification : segments de binlog manquants, base temporelle incorrecte, rotation supprimée trop tôt, ou binlogs manipulés lors d’une attaque. Vérifiez la complétude (séquence sans trou), la dérive temporelle et si les binlogs sont stockés dans une destination résistante à la manipulation.

La RESTauration ramène des données chiffrées/compromises

Contre-vérification : le choix du moment et l’autorisation de « Clean RESTore » font défaut. En situation de ransomware, il est courant que des données aient déjà été exfiltrées ou manipulées avant le chiffrement. Définissez un point « Known Good » et validez-le par des contrôles d’anomalies (extensions de fichiers, modifications massives, mises à jour DB suspectes).

Mise en œuvre par étapes : un parcours de migration réaliste sans Big Bang

Si vous gérez aujourd’hui une sauvegarde disque classique dans le même domaine, la transition vers des sauvegardes résilientes face aux ransomwares peut se faire progressivement :

1. Prouver la capacité de RESTauration: introduire des RESTaurations d’échantillonnage automatisées, mesurer RTO/RPO.
2. Renforcer les identités: séparer les comptes de sauvegarde, mettre en place un Jump-Host, améliorer la gestion du MFA et des secrets.
3. Ajouter une cible immuable: activer Object Lock/WORM pour une copie supplémentaire, définir la rétention.
4. Ajouter un composant Air-Gap: conception offsite hors ligne ou basée sur le pull.
5. Runbooks & exercices: exercice de reprise au minimum trimestriel pour les services critiques.

Ainsi, vous réduisez le risque dès le départ, sans tout modifier en une seule fois.

Stratégie de repli : que faire si l’écosystème de sauvegarde est lui aussi compromis ?

Une stratégie de repli n’est pas du pessimisme, mais de la maturité opérationnelle. Planifiez pour le cas où des serveurs/comptes de sauvegarde seraient compromis :

• Copie hors ligne indépendante: périodique et vérifiable, incluant une documentation expliquant comment la lire.
• Reconstruction à partir d’un « Bare Metal »: Golden Images, IaC/gestion de configuration, dépôts de paquets, archive des licences/clés.
• DNS/NTP d’urgence: base petite et isolée, pour pouvoir exécuter proprement les RESTaurations.
• Processus de communication et d’autorisation: qui décide du « clean point », qui autorise la RESTauration, qui documente.

Le point décisif : les sauvegardes ne sont qu’une partie. En situation de ransomware, vous devez parallèlement récupérer les identités, réaffecter les droits et vous assurer de ne pas rouvrir directement la même vulnérabilité.

Conclusion : des sauvegardes résilientes face aux ransomwares sont un système global

Une stratégie de sauvegarde solide contre les ransomwares naît de l’interaction entre des sauvegardes immuables, un Air-Gap réel (technique ou procesuel) et une RESTauration rapide régulièrement exercée. Ce qui importe moins que les produits individuels, c’est une architecture propre : identités séparées, droits minimisés, flux de données clair, rétention traçable et validation stricte des RESTaurations.

Si vous retenez trois choses de cet article : (1) protégez les identités de sauvegarde comme des joyaux de la couronne, (2) constituez au moins une copie immuable ou hors ligne, (3) testez la RESTauration de façon à rendre RTO/RPO mesurables – en particulier pour MariaDB, y compris les binlogs et la récupération point-in-time. Ainsi la sauvegarde passe d’une tâche obligatoire à un outil fiable de redémarrage.

Pour ce sujet, les sauvegardes Air-Gap et la récupération après ransomware sont également importantes. L’article place ces aspects de manière compréhensible et montre ce qui compte au quotidien.