« On a une sauvegarde » est la phrase la plus rassurante et la moins vérifiée d'une petite entreprise. Un disque branché en permanence sur le serveur, une copie qui n'a jamais été restaurée, un ransomware qui chiffre la sauvegarde avec le reste : le scénario se répète. Voici comment je construis une sauvegarde qui survit à un rançongiciel, avec des objectifs chiffrés (RPO, RTO) et un plan de reprise d'activité réaliste pour une TPE.
Ce guide complète le guide général de la sauvegarde, qui s'adresse à tout le monde. Ici, l'angle est celui de l'entreprise : serveur, postes, messagerie, logiciel métier, et le jour où il faut redémarrer.
Une sauvegarde n'est utile que si on sait la restaurer, à temps
Deux questions décident de tout, et on les pose avant de choisir un outil :
- RPO (Recovery Point Objective) : combien de données pouvez-vous accepter de perdre ? C'est l'écart maximal entre la panne et la dernière copie exploitable. Une sauvegarde nocturne donne un RPO de 24 heures au pire.
- RTO (Recovery Time Objective) : combien de temps pouvez-vous rester à l'arrêt ? C'est le délai entre la panne et le retour à un service utilisable.
Ces deux chiffres ne sont pas techniques, ce sont des décisions de direction. La technique vient ensuite et coûte plus cher à mesure qu'on les resserre.
| Cas illustratif | Perte tolérable (RPO) | Arrêt tolérable (RTO) | Conséquence technique |
|---|---|---|---|
| Cabinet de 5 personnes, fichiers bureautiques | 1 jour | 1 à 2 jours | Sauvegarde nocturne, restauration fichier par fichier |
| Entreprise avec logiciel de facturation en continu | 1 à 4 heures | Demi-journée | Sauvegarde de la base plusieurs fois par jour, serveur de secours ou machine virtuelle prête |
| Commerce dont la caisse dépend du serveur | Quasi nulle | Moins d'une heure | Réplication, redondance, mode dégradé écrit |
Le tableau est un exemple de raisonnement, pas un barème : vos valeurs viennent de ce que coûte une heure d'arrêt chez vous. Demandez-vous simplement : si tout s'arrête lundi à 9 h, que perd-on par jour (chiffre d'affaires, pénalités, salaires payés à ne rien faire) ? Ce montant justifie ou non l'investissement.
La règle 3-2-1, et ce qu'elle ne dit pas
La règle est connue : 3 copies des données (l'original et deux sauvegardes), sur 2 supports différents, dont 1 hors site. Cybermalveillance.gouv.fr recommande les mêmes principes de fond : plusieurs sauvegardes sur des supports différents, un support déconnecté du réseau quand il ne sert pas, une copie dans un autre lieu (fiche sauvegardes).
Ce que la règle 3-2-1 ne dit pas, et que les rançongiciels ont rendu essentiel : au moins une copie doit être impossible à modifier ou à effacer depuis le réseau de l'entreprise, même par un administrateur dont le compte est compromis. D'où la variante parfois appelée 3-2-1-1-0 : une copie hors ligne ou immuable en plus, et zéro erreur lors des vérifications de restauration.
Immuable, hors ligne, hors site : trois protections différentes
On mélange souvent ces termes. Ils répondent à des risques distincts :
| Protection | Ce qu'elle protège | Exemple de mise en oeuvre | Limite |
|---|---|---|---|
| Hors site | Incendie, vol, dégât des eaux, panne du local | Copie chiffrée vers un hébergeur en Europe, ou disque rangé dans un autre lieu | Une copie hors site modifiable reste attaquable |
| Hors ligne (air gap) | Rançongiciel, compte administrateur compromis | Disques en rotation, débranchés après la sauvegarde | Dépend d'une personne qui change les disques |
| Immuable | Suppression ou chiffrement par un attaquant, erreur humaine | Stockage objet avec verrouillage (Object Lock) pour une durée définie | Coût de stockage pendant la durée de verrou, paramétrage à bien faire |
L'immuabilité s'appuie sur des fonctions documentées des fournisseurs de stockage objet. Par exemple, le verrouillage d'objets d'Amazon S3 (« Object Lock ») interdit la suppression et l'écrasement d'une version pendant une période de rétention (documentation AWS) ; d'autres fournisseurs proposent un mécanisme équivalent. Le principe compte plus que la marque : le mode de verrouillage doit être celui où même le propriétaire du compte ne peut pas raccourcir la durée avant son terme.
Point de vigilance souvent oublié : les identifiants de la sauvegarde ne doivent pas être ceux du domaine. Si l'attaquant obtient le compte administrateur de l'entreprise et que la console de sauvegarde accepte ce compte, il supprime les sauvegardes avant de chiffrer. Compte distinct, mot de passe unique, MFA, et accès à la console limité à un poste d'administration.
Que sauvegarder : la liste qu'on oublie de faire
Avant de parler d'outil, dressez la liste de ce qui fait tourner l'entreprise. Un inventaire d'une page suffit, avec pour chaque ligne : où sont les données, qui en est responsable, quel RPO.
- Fichiers partagés (serveur, NAS, OneDrive, SharePoint) et dossiers locaux des postes qui échappent au partage.
- Messagerie : hébergée chez Microsoft ou Google, elle n'est pas sauvegardée par défaut au sens d'une copie indépendante. Voir notre checklist de sécurisation Microsoft 365.
- Logiciels métier et leurs bases de données : copier les fichiers d'une base en cours d'utilisation donne souvent une copie inutilisable. Il faut une sauvegarde cohérente (export, instantané, ou outil conscient de l'application).
- Configurations : pare-feu, commutateurs, bornes Wi-Fi, DNS, certificats. Quand tout est à reconstruire, ces fichiers de quelques kilo-octets font gagner des heures.
- Machines virtuelles ou image complète du serveur si le RTO exige de redémarrer vite sans tout réinstaller.
- Secrets et clés : clé de chiffrement de la sauvegarde, codes de récupération BitLocker, accès au registrar du nom de domaine. Une sauvegarde chiffrée dont on a perdu la clé est une sauvegarde perdue.
La fréquence découle du RPO, la durée de conservation du risque
Un schéma simple pour une TPE : une sauvegarde quotidienne conservée quelques semaines, des copies hebdomadaires conservées quelques mois, et des copies mensuelles conservées plus longtemps selon les obligations légales ou contractuelles. L'historique est précieux contre un rançongiciel qui a dormi : si l'infection date de trois semaines, une rétention de sept jours ne contient que des données déjà corrompues.
Faites une estimation du volume et du débit. Exemple de calcul à reproduire avec vos chiffres : 500 Go à restaurer par une liaison qui débite réellement 100 Mbit/s demandent environ 11 heures de transfert, sans compter la vérification. Ce simple calcul explique pourquoi un RTO d'une demi-journée impose souvent une copie locale rapide en plus de la copie hors site. Les débits théoriques de l'abonnement ne sont jamais atteints en pratique : mesurez.
Le test de restauration, seule preuve qui compte
Un voyant vert dans la console prouve que le logiciel a fini son travail, pas que vous pouvez redémarrer. Trois niveaux de test, du plus simple au plus complet :
- Restauration d'un fichier au hasard, chaque mois : on choisit un fichier précis, on le restaure ailleurs, on l'ouvre.
- Restauration d'une application complète (la base du logiciel de facturation, par exemple) sur une machine de test, chaque trimestre ou après chaque changement important. On vérifie que l'application démarre et que les dernières données sont là.
- Exercice de reprise, chaque année : on simule la perte du serveur et on chronomètre. Le temps mesuré est votre vrai RTO, pas celui du devis.
Consignez chaque test dans un registre d'une ligne : date, ce qui a été restauré, durée, anomalies. C'est aussi la preuve utile en cas de contrôle ou de demande d'un assureur ou d'un client.
Le plan de reprise d'activité : quatre pages, pas quarante
Un PRA de TPE n'a pas besoin d'être un classeur. Il doit tenir sur quelques pages que quelqu'un d'autre que vous peut lire un jour de crise, imprimées et rangées hors du système informatique (le jour où le réseau est chiffré, le document en ligne n'est plus lisible).
- Qui décide et qui appelle qui : une personne de direction, un référent technique, le prestataire informatique, l'assureur, le numéro à contacter pour déposer plainte.
- Ordre de redémarrage : quels services reviennent en premier (messagerie, facturation, téléphonie) et ce dont chacun dépend (DNS, annuaire, base de données).
- Où sont les sauvegardes et comment y accéder : emplacements, comptes, clés, avec la procédure de restauration pas à pas.
- Mode dégradé : comment travailler pendant l'arrêt (devis papier, téléphone mobile, messagerie provisoire) et qui prévient les clients.
Côté méthode d'ensemble, l'ANSSI publie un guide pour se préparer et réagir face aux rançongiciels (Attaques par rançongiciels, tous concernés) et Cybermalveillance.gouv.fr propose une fiche réflexe rançongiciel à imprimer. Les deux insistent sur la même priorité : isoler les machines touchées, ne pas payer sans conseil, et partir d'une sauvegarde saine.
Obligations et assurance
La sauvegarde et la continuité d'activité figurent parmi les mesures exigées par la directive NIS2 pour les entités concernées (notre guide NIS2). Même hors périmètre, un assureur cyber ou un grand client donneur d'ordre demande de plus en plus de preuves : copie hors ligne ou immuable, tests documentés, MFA sur les accès d'administration. Un registre de tests à jour répond à ces questionnaires en quelques minutes.
Checklist de contrôle
- RPO et RTO écrits, validés par la direction.
- Au moins trois copies, deux supports, une copie hors site.
- Au moins une copie immuable ou hors ligne.
- Identifiants de sauvegarde distincts de ceux du domaine, avec MFA.
- Messagerie, SaaS et bases de données couvertes, pas seulement les fichiers.
- Clé de chiffrement et codes de récupération conservés à part.
- Test de restauration mensuel (fichier) et trimestriel (application), exercice annuel, tout consigné.
- PRA imprimé, avec contacts et ordre de redémarrage.
