Sauvegarde anti-ransomware : concevoir une restauration crédible

Une sauvegarde n'est utile que si elle reste disponible lorsque le système principal est compromis. Copier des fichiers chaque nuit ne suffit pas. Il faut protéger la copie contre la suppression, connaître les dépendances de l'application et répéter la restauration dans un environnement maîtrisé.

Le périmètre avant l'outil

Le périmètre inclut les données, les configurations, les clés, les annuaires, les scripts de déploiement et la documentation d'exploitation. Pour chaque service, l'entreprise doit choisir la perte de données maximale acceptable et le délai de remise en route. Ces objectifs orientent la fréquence, l'isolement et l'ordre de reprise.

Commencez par une unité que l'équipe sait nommer : un service, un processus, une classe de données ou un chemin d'accès. Associez-lui un propriétaire, une dépendance métier et une conséquence observable. Cette discipline évite les programmes trop larges où chaque équipe attend qu'une autre commence.

Les contrôles qui changent la situation

Conserver au moins une copie non modifiable depuis le système courant. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Séparer les identités d'administration de la sauvegarde. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Chiffrer les copies et protéger les clés. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Tester une restauration complète avec un chronomètre. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Documenter l'ordre des dépendances. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.

Un contrôle n'est pas une intention. Il existe lorsque sa portée est connue, qu'une personne peut montrer sa configuration et qu'un test révèle son échec. Si l'une de ces conditions manque, classez-le comme chantier en cours avec une date de reprise.

Ce que disent les sources primaires

Le point de référence est Rançongiciel, fiche réflexe . La fiche conseille d'isoler les équipements touchés, de préserver les éléments utiles au diagnostic, de demander de l'aide et de préparer la restauration sans payer comme réflexe automatique.

Pour vérifier le cadre, consultez Guide d'hygiène informatique. Le guide organise les mesures de base autour de la connaissance du système, de l'authentification, des mises à jour, des sauvegardes, de la journalisation et de la réaction aux incidents.

La méthode peut être rapprochée de Cybersecurity Framework . Le cadre structure la gouvernance et les activités de cybersécurité autour de fonctions qui couvrent l'identification, la protection, la détection, la réponse et la restauration.

Ces références donnent un cadre commun, pas une réponse automatique au cas particulier. Reprenez les termes applicables à votre système et indiquez ce qui reste à confirmer. Une source peut soutenir plusieurs décisions sans être répétée à chaque phrase.

Un scénario pour éprouver la méthode

Un atelier sauvegarde ses fichiers mais pas la configuration de son logiciel de production. Après une attaque, les documents reviennent tandis que l'application reste inutilisable. Le test suivant ajoute l'export de configuration, l'identité de service et une fiche d'ordre de redémarrage, puis mesure le temps réel de reprise.

Le scénario sert à tester l'enchaînement des décisions. Changez une hypothèse, comme l'absence d'un responsable ou l'indisponibilité d'un fournisseur, puis observez si le plan garde un chemin praticable. Un dispositif robuste ne dépend pas d'une seule personne ni d'une seule console.

Le plan de travail en cinq passages

Choisir un service critique et écrire son arbre de dépendances. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Restaurer d'abord une copie sur un réseau isolé. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Comparer les données restaurées à un échantillon attendu. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Simuler la perte d'un compte administrateur. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Corriger le plan puis programmer le prochain test. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.

Chaque passage doit rester assez petit pour être repris. La progression vient de la fermeture des écarts, pas du nombre de réunions. Lorsque le test contredit la documentation, corrigez d'abord l'état réel, puis la procédure qui devra le reproduire.

Les preuves à conserver

Rapport de succès des sauvegardes
Empreinte d'un échantillon restauré
Temps de restauration mesuré
Liste des dépendances
Décision après chaque écart

Une preuve utile est datée, liée à un périmètre et compréhensible par une personne qui n'a pas participé au projet. Évitez les captures isolées sans contexte. Préférez un rapport court qui nomme la commande, le résultat attendu, l'écart et l'action décidée.

Les pièges qui affaiblissent le programme

Laisser les copies montées en permanence. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Utiliser le même compte administrateur partout. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Tester seulement la récupération d'un fichier. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Oublier les clés et certificats. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Annoncer un délai jamais mesuré. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.

Ces pièges viennent souvent d'une volonté d'aller vite. Leur antidote est un retour au service réel, à la personne qui en dépend et au test que l'on peut rejouer. Une décision prudente peut être temporaire, à condition que sa date de réexamen soit explicite.

La prochaine décision utile

Commencez par une restauration modeste, mais complète. Le test doit révéler qui a les droits, quelle donnée manque et quelle étape dépend d'une personne absente. Chaque écart devient une action datée. Cette preuve vaut davantage qu'un tableau de bord entièrement vert.

Écrivez la décision avec son responsable, sa date et la condition qui permettra de la fermer. Le sujet devient alors pilotable : l'entreprise sait ce qu'elle protège, ce qu'elle ignore encore et comment vérifier la prochaine étape.