<p>Avoir une sauvegarde et pouvoir restaurer sont deux choses différentes. Les deux chiffres à écrire avant de choisir un outil, pourquoi les...
Le scénario se répète avec une régularité déprimante. Un incident survient, on va chercher la sauvegarde, et l'on découvre l'un des trois problèmes suivants: elle échouait silencieusement depuis des semaines, elle ne contenait pas les données réellement critiques, ou elle a été chiffrée en même temps que le reste. Dans les trois cas, l'entreprise croyait être protégée. Elle avait un dispositif de sauvegarde; elle n'avait pas de capacité de restauration.
C'est la distinction fondamentale, et elle explique pourquoi la question « faites-vous des sauvegardes? » ne sert presque à rien. Tout le monde répond oui. La question utile est: « quand avez-vous restauré pour la dernière fois, et combien de temps cela a-t-il pris? » Avant de choisir un outil, il faut répondre à deux questions, et elles se posent en termes de gestion, pas de technique.
Combien de données pouvez-vous vous permettre de perdre? Si votre sauvegarde tourne chaque nuit à 22 heures et que l'incident survient à 17 heures, vous perdez une journée entière de saisie. Pour un cabinet comptable en période de bilan ou une société qui enregistre des commandes en continu, c'est inacceptable. Pour une entreprise dont les données évoluent lentement, c'est parfaitement tenable. Ce seuil détermine la fréquence de vos sauvegardes, et rien d'autre.
Combien de temps pouvez-vous rester à l'arrêt? Restaurer plusieurs téraoctets depuis un stockage distant peut demander une journée ou deux, simplement à cause du débit disponible. Si votre activité ne survit pas à deux jours d'interruption, une sauvegarde uniquement distante ne suffit pas: il faut une copie locale, plus rapide à remonter.
Ces deux chiffres, écrits noir sur blanc, transforment une discussion vague en cahier des charges. Sans eux, on achète une solution sans savoir ce qu'on lui demande.
Ce que les rançongiciels ont changé
Pendant longtemps, on se protégeait contre la panne matérielle, l'incendie et l'effacement accidentel. Ces risques existent toujours, mais ils ont été rejoints par un adversaire qui, lui, cherche activement vos sauvegardes.
Un rançongiciel moderne ne se contente pas de chiffrer les postes de travail. Il parcourt le réseau, identifie les partages accessibles, et s'attaque en priorité aux sauvegardes — parce que leur destruction est précisément ce qui vous contraindra à payer. Une sauvegarde stockée sur un disque connecté en permanence au réseau, accessible avec les mêmes identifiants que le reste, sera chiffrée avec le reste.
D'où une exigence devenue non négociable: au moins une copie doit être hors d'atteinte. Soit physiquement déconnectée, soit protégée par un mécanisme d'immuabilité qui interdit toute modification ou suppression pendant une durée définie, y compris par un compte d'administration compromis. La formulation classique tient en trois nombres: trois copies de vos données, sur deux supports différents, dont une hors site. Elle est ancienne mais elle reste pertinente, à condition d'en comprendre l'intention.
Les trois copies couvrent la défaillance simultanée. Les deux supports différents évitent qu'un même défaut de fabrication ou une même erreur de configuration n'emporte tout. La copie hors site protège contre ce qui détruit un bâtiment: incendie, dégât des eaux, cambriolage. Une entreprise dont toutes les sauvegardes se trouvent dans le local technique, à côté du serveur, n'a pas de sauvegarde hors site — elle a plusieurs copies du même risque. Un rapport de sauvegarde affichant « succès » indique que les fichiers ont été copiés. Il ne dit rien de leur exploitabilité. Une base de données sauvegardée à chaud sans mécanisme de cohérence peut produire une copie inutilisable dont le rapport signale pourtant la réussite.
Le seul test valable consiste à restaurer réellement, et à chronométrer. Restaurez un fichier au hasard: combien de temps pour le retrouver? Restaurez un système complet sur une machine de test: démarre-t-il, l'application fonctionne-t-elle? Ce chronomètre vous donne votre vrai délai de reprise, qui s'avère presque toujours plus long que celui annoncé.
Une fréquence trimestrielle suffit pour la plupart des PME. Ce qui compte est la régularité, et le fait de noter le résultat: la date, la durée, ce qui a coincé. Le jour de l'incident, les systèmes sont indisponibles. C'est le moment où l'on cherche la procédure de reprise — et où l'on découvre qu'elle était stockée sur le serveur chiffré, ou dans une boîte de messagerie inaccessible.
Cette procédure doit exister sur un support indépendant: qui appelle qui, dans quel ordre remonter les systèmes, où se trouvent les identifiants d'administration, quel est le numéro du prestataire. Une version imprimée, conservée hors du bâtiment, a l'air désuète jusqu'au jour où elle est le seul document lisible. Si votre dispositif actuel n'a jamais été éprouvé, trois actions donnent l'essentiel du bénéfice. Écrivez vos deux chiffres: perte de données tolérable, durée d'arrêt tolérable. Vérifiez qu'une copie au moins est hors d'atteinte d'un chiffrement. Puis restaurez quelque chose, cette semaine, en notant le temps que cela prend.
Ce dernier point est le plus instructif. La plupart des entreprises découvrent à cette occasion que leur sauvegarde fonctionne, mais que leur reprise d'activité prendrait trois fois plus de temps qu'elles ne l'imaginaient.
- ANSSI — Attaques par rançongiciels, tous concernés: comment les anticiper et réagir en cas d'incident
- Cybermalveillance.gouv.fr — Fiche réflexe: rançongiciel
Article rédigé par TIA, l'assistant éditorial de TICLIC, et relu avant publication.