Ein Backup ist kein Backup-Konzept: Wiederherstellung nach Ransomware

Presque toutes les entreprises disposent aujourd'hui de sauvegardes. Pourtant, lorsque ransomware frappe, on s'aperçoit régulièrement que : les données sont bien sauvegardées, mais que la La restauration ne fonctionne pas — trop lent, incomplet ou chiffré simultanément. La différence ne réside pas dans le logiciel, mais dans le concept sous-jacent.

Pourquoi les sauvegardes échouent en cas d'urgence

• Cible de sauvegarde dans le même contexte : Le système de sauvegarde est rattaché au même domaine avec les mêmes comptes administrateur. Les attaquants chiffrent délibérément les sauvegardes en priorité.
• Restauration non testée : La restauration n'a jamais été testée. En cas d'incident réel, elle prendrait des jours au lieu d'heures — ou échouerait silencieusement.
• Ordre imprécis : Personne n'a défini quels systèmes doivent être rétablis en priorité. La restauration s'effectue au feeling.
• Manque de responsabilité La sauvegarde 'tourne', mais personne ne vérifie les notifications de succès quotidiennes.

La règle 3-2-1-1-0 comme standard minimum

• 3 Copies de vos données.
• 2 différents supports ou systèmes.
• 1 Sauvegarde hors site
• 1 Les copies doivent être hors ligne ou immuables — elles ne doivent pas pouvoir être écrasées, même par les administrateurs.
• 0 Restaurations non testées : chaque test de restauration doit être effectué sans erreur.

L'immuabilité est le point crucial.

Les ransomwares modernes suppriment ou chiffrent ciblément les sauvegardes en ligne avant d'attaquer les systèmes de production. La réponse est Stockage immuable (Object Lock) : Les données de sauvegarde sont en lecture seule pendant une période de rétention définie — même avec des droits d'administrateur complets. Ainsi, un état sain est toujours préservé pour permettre une restauration.

La restauration est un processus, pas un bouton

• Définir l'ordre : D'abord les identités et le réseau, puis les systèmes centraux, puis les applications métier — et non l'inverse.
• Définir le RTO et le RPO par système : Combien de temps un système peut-il être indisponible, et quelle perte de données est acceptable ? Ce sont des décisions métier, et non des questions informatiques.
• Maintenir un manuel d'urgence en version hors ligne : Qui appelle qui, quels systèmes sont prioritaires, où se trouvent les accès ? Imprimés, pas sur le serveur qui est chiffré.
• S'exercer au moins une fois par an : Une restauration sous la pression du temps est le mauvais moment pour un premier essai.

La référence à NIS2

La transposition allemande de la directive NIS2 exige explicitement, dans le cadre de la gestion des risques, une gestion des sauvegardes, une planification d'urgence et la preuve de leur mise en œuvre. Un concept de sauvegarde documenté et testé n'est donc plus un effort volontaire pour environ 30 000 entreprises, mais une obligation — engageant la responsabilité personnelle de la direction générale.

Remarque : Cet article ne remplace pas un conseil juridique. Il sert d'orientation initiale ; l'examen contraignant de votre situation doit être confié à des experts.

← tous les guides