Sauvegardes et restauration

C'est une règle simple pour survivre à la perte de n'importe quel élément : trois copies de vos données, sur deux types de supports différents, dont une hors site. L'original plus deux sauvegardes, par exemple l'une sur une appliance de sauvegarde locale et l'autre dans un cloud distinct ou sur un autre site, font qu'un incendie, une baie de disques en panne ou un serveur volé n'emportent pas tout. Comme les attaquants par rançongiciel cherchent désormais les sauvegardes pour les supprimer, beaucoup de guides étendent la règle à 3-2-1-1-0 : une copie hors ligne ou immuable, impossible à modifier ou supprimer même avec des droits d'administrateur, et zéro erreur lors de la vérification et des tests de restauration. Pour une petite entreprise, une version pratique : une sauvegarde locale pour les restaurations rapides, une copie cloud immuable avec des identifiants distincts, et un test de restauration régulier et documenté.

Une sauvegarde immuable est une copie qui ne peut être ni modifiée ni supprimée avant la fin d'une durée de conservation fixée, même par un compte administrateur. On l'obtient généralement avec un stockage à écriture unique : stockage objet avec verrou de rétention en mode conformité, dépôt de sauvegarde durci qui refuse les suppressions, ou bande retirée physiquement. L'enjeu, c'est le rançongiciel : les attaquants qui obtiennent des droits d'administration tentent systématiquement de supprimer ou de chiffrer les sauvegardes avant de chiffrer la production, pour que la victime n'ait d'autre issue que payer. Avec une copie immuable, cette étape échoue. Vérifiez trois points quand un éditeur parle d'immuabilité : si le verrou peut être raccourci ou levé depuis la console qu'un attaquant pourrait atteindre, la durée de rétention, et si le support du fournisseur de stockage peut le contourner. L'immuabilité protège contre la suppression, pas contre la sauvegarde de données déjà infectées : gardez plusieurs points de restauration.

C'est une copie de sauvegarde qui n'a pas de connexion réseau permanente avec vos systèmes, si bien qu'un attaquant présent dans le réseau ne peut pas l'atteindre. Exemples classiques : des bandes ou disques amovibles écrits, déconnectés et rangés ailleurs, et des coffres de sauvegarde dédiés qui n'ouvrent une connexion que pendant une courte fenêtre contrôlée. Certains services cloud appellent isolation logique une copie immuable gérée séparément : elle n'est pas physiquement déconnectée, mais reste hors de portée de vos comptes d'administration habituels. Les copies hors ligne sont plus lentes à restaurer et demandent de la discipline, car quelqu'un doit vraiment faire tourner les supports, vérifier que la tâche s'est exécutée et savoir ce qui se trouve où. Pour la plupart des petites entreprises, l'objectif réaliste est une copie physiquement hors ligne ou immuable avec des identifiants distincts, testée par restauration à intervalles réguliers. Une copie posée en permanence sur un partage accessible à tout le réseau n'est pas hors ligne, quel que soit son nom.

Au moins une fois par trimestre pour un échantillon de systèmes, après chaque changement important du dispositif de sauvegarde, et au moins une fois par an sous forme d'exercice complet de restauration d'un système critique à partir de zéro. Une sauvegarde jamais restaurée est une hypothèse, pas une sauvegarde : des tâches qui signalent un succès peuvent produire des fichiers incomplets, chiffrés avec une clé perdue ou sans une base de données qui était en cours d'utilisation. Un bon test choisit de vrais systèmes, les restaure dans un environnement isolé, vérifie que l'application démarre vraiment et que les données sont à jour, et note combien de temps cela a pris. Cette durée est votre délai de reprise réaliste, souvent bien plus long que prévu. Notez ce qui n'a pas marché et corrigez-le avant le test suivant. Faites tourner les systèmes testés pour que, sur un an, chaque système critique ait été restauré au moins une fois.

Très souvent, oui. Avant de lancer le chiffrement, les attaquants cherchent le serveur de sauvegarde, la console du logiciel de sauvegarde et les instantanés ou clichés instantanés, puis les suppriment, les chiffrent ou les corrompent pour que la victime ne puisse pas se rétablir sans payer. MITRE ATT&CK classe cela sous Inhibit System Recovery (T1490), et la suppression des clichés instantanés figure dans de nombreux avis de la CISA sur les rançongiciels. Les comptes d'administration des sauvegardes et les serveurs de sauvegarde joints au même domaine que tout le reste sont des points faibles fréquents. Défenses : garder au moins une copie immuable ou hors ligne, exploiter le système de sauvegarde avec des identifiants distincts et l'authentification multifacteur, le sortir si possible du domaine principal et limiter les machines autorisées à s'y connecter. Côté réseau, des connexions au serveur de sauvegarde depuis des machines qui ne lui parlent jamais sont un signal d'alerte. La carte du réseau de NetSenX montre quels hôtes atteignent chaque serveur, et les connexions internes inhabituelles sont signalées comme mouvement latéral possible.

Parce qu'un rançongiciel chiffre tous les lecteurs qu'il peut atteindre, et qu'un lecteur monté ressemble pour lui à n'importe quel autre dossier. Si la cible de sauvegarde est montée en permanence sur un serveur ou un poste, ou accessible par un partage avec les mêmes identifiants, le rançongiciel présent sur cette machine chiffrera les fichiers de sauvegarde avec tout le reste, et les sauvegardes disparaîtront au moment précis où vous en aurez besoin. Il en va de même pour un disque USB externe toujours branché et pour les outils de synchronisation qui répercutent chaque changement, chiffrement compris, vers l'emplacement de sauvegarde. Mieux vaut que le logiciel de sauvegarde écrive sur sa cible avec son propre compte de service, que les utilisateurs et serveurs ordinaires n'ont pas, que la cible n'apparaisse pas dans les partages consultés, et qu'il existe une copie immuable ou hors ligne. Vérification rapide dès aujourd'hui : quelles machines ont une lettre de lecteur ou un partage pointant vers le stockage de sauvegarde ? Retirez ceux qui n'en ont pas besoin.

Le moins possible : le serveur de sauvegarde lui-même, les systèmes qu'il sauvegarde pendant leur fenêtre de sauvegarde, et le poste d'administration des administrateurs. Les postes ordinaires n'ont aucune raison d'ouvrir des partages de fichiers, le bureau à distance ou des ports d'administration sur le serveur de sauvegarde. Écrivez cela sous forme de courte liste de règles et appliquez-la par des règles de pare-feu ou une segmentation, idéalement en plaçant le système de sauvegarde dans son propre segment réseau. Vérifiez ensuite que la réalité correspond. Les données de flux montrent quels hôtes parlent réellement au serveur de sauvegarde, sur quels ports et quand ; dans NetSenX, la carte du réseau le montre dans toutes les offres, si bien qu'un portable du service commercial qui se met à se connecter au serveur de sauvegarde ressort aussitôt. Une telle connexion n'est pas toujours une attaque, mais elle mérite toujours une explication, car atteindre les sauvegardes est une étape typique juste avant le chiffrement par rançongiciel.

Oui, de deux façons différentes. Les fichiers de sauvegarde eux-mêmes peuvent être chiffrés ou supprimés si le rançongiciel ou l'attaquant atteint le stockage de sauvegarde, d'où l'importance des copies immuables et hors ligne. Moins évident : les sauvegardes peuvent contenir fidèlement la présence de l'attaquant. Les attaquants sont souvent dans le réseau pendant des jours ou des semaines avant de chiffrer, si bien que les sauvegardes récentes peuvent inclure leurs portes dérobées, tâches planifiées, nouveaux comptes d'administration ou fichiers malveillants, prêts à reprendre vie après une restauration. C'est pourquoi on conserve plusieurs points de restauration sur une période plus longue, on restaure d'abord dans un environnement isolé, on analyse les systèmes restaurés et on recherche les comptes et outils d'accès à distance qui ne devraient pas s'y trouver. Savoir quand l'intrusion a réellement commencé, grâce aux journaux et à l'historique réseau, indique quel point de restauration a des chances d'être sain.

Ne commencez pas à restaurer avant de savoir comment les attaquants sont entrés et d'avoir fermé cette voie, sinon vous restaurez dans un réseau qu'ils contrôlent encore. Procédez ensuite dans l'ordre : reconstruire ou vérifier d'abord un serveur de sauvegarde et une console de restauration sains, avec de nouveaux identifiants ; changer tous les mots de passe des comptes d'administration et de service, y compris ceux du logiciel de sauvegarde ; restaurer les systèmes dans un segment réseau isolé, pas directement en production ; choisir un point de restauration antérieur au début de l'intrusion, pas seulement au chiffrement ; analyser les systèmes restaurés et rechercher comptes, tâches planifiées et outils d'accès à distance inattendus ; puis les reconnecter pas à pas en observant leur comportement réseau. Gardez les originaux chiffrés intacts jusqu'à être sûr, comme preuve et au cas où un déchiffreur apparaîtrait. Avec NetSenX, les hôtes restaurés qui commencent des contacts sortants réguliers ou des connexions internes inhabituelles apparaissent dans les alertes.

D'abord les fondations, puis ce dont l'activité a le plus besoin, puis le reste. Un ordre type : les bases réseau et sécurité, comme le pare-feu, les commutateurs, le DNS, le DHCP et la surveillance sur laquelle vous allez vous appuyer ; l'identité, c'est-à-dire les contrôleurs de domaine ou l'identité cloud, reconstruits ou vérifiés sains, puisque tous les autres systèmes en dépendent ; l'infrastructure de sauvegarde elle-même ; ensuite les applications critiques dans la priorité décidée à l'avance, par exemple le traitement des commandes, le pilotage de la production ou la paie ; et enfin les partages de fichiers ordinaires, les postes et les services moins importants. Chaque étape doit comporter une vérification avant la suivante. Cet ordre a sa place dans votre plan de reprise, validé par la direction avant tout incident, avec la durée de reprise admise pour chaque système. Sans cet accord, les premiers jours après une attaque tournent aux disputes sur le système le plus important, pendant que le temps passe.

Ce sont les deux chiffres qui transforment un plan de sauvegarde en décision d'entreprise. L'objectif de point de reprise (RPO) est la quantité de données que vous pouvez vous permettre de perdre, mesurée en temps : avec des sauvegardes nocturnes, votre RPO va jusqu'à 24 heures, soit une journée de travail potentiellement perdue. L'objectif de délai de reprise (RTO) est la durée pendant laquelle un système peut être arrêté avant que les dommages deviennent inacceptables, mesurée de l'incident au redémarrage du système. Fixez les deux par système avec les responsables du processus métier, pas seulement avec l'informatique : la comptabilité peut supporter deux jours d'arrêt mais aucune perte de données, tandis qu'une boutique en ligne sera peut-être l'inverse. Vérifiez ensuite que vos sauvegardes et vos tests de restauration les atteignent vraiment. Une restauration qui prend trois jours en test ne peut pas tenir un RTO de quatre heures, quelle que soit la qualité du logiciel de sauvegarde.

Pas à elle seule. Les outils de synchronisation sont conçus pour garder toutes les copies identiques : quand des fichiers sont supprimés, écrasés ou chiffrés par un rançongiciel sur un appareil, la modification est recopiée dans le cloud et sur tous les autres appareils en quelques minutes. La plupart des services conservent un historique des versions et une corbeille, et certains permettent de ramener toute une bibliothèque à un point antérieur, ce qui peut sauver la mise après un incident. Mais cet historique a une durée de conservation limitée, il est contrôlé par le même compte que l'attaquant a peut-être pris, et personne ne le teste comme une sauvegarde. Considérez la synchronisation comme un outil de confort et de collaboration. Pour les données importantes, ajoutez une vraie sauvegarde : une copie séparée, avec des identifiants distincts, une durée de conservation que vous choisissez et des restaurations testées. Cela vaut aussi pour les serveurs de fichiers synchronisés avec le cloud.

En général, oui. Les fournisseurs SaaS fonctionnent selon un modèle de responsabilité partagée : ils assurent la disponibilité du service et le protègent contre leurs propres pannes matérielles, mais protéger vos données contre une suppression, un initié malveillant, un compte compromis ou une durée de conservation expirée relève largement de vous. Le contrat de services de Microsoft recommande lui-même aux clients de sauvegarder régulièrement leur contenu. Les filets de sécurité intégrés, comme les dossiers d'éléments supprimés, les corbeilles et l'historique des versions, ont une conservation limitée et peuvent être vidés par quelqu'un disposant des bons accès. Une sauvegarde tierce des boîtes mail, de SharePoint et de OneDrive, ou l'équivalent pour Google Workspace, le CRM et la comptabilité, vous donne une copie indépendante avec une conservation que vous maîtrisez. Vérifiez aussi la restauration : restaurer une boîte mail et restaurer tout un tenant après une attaque sont des tâches très différentes.

Oui. Si le même compte administrateur de domaine qui gère tout le reste peut aussi supprimer les sauvegardes, un attaquant qui vole ce seul compte contrôle à la fois vos systèmes et votre voie de retour. Donnez au système de sauvegarde ses propres comptes d'administration, qui ne sont pas membres du domaine ou de l'annuaire principal, protégez-les par une authentification multifacteur, de préférence résistante au phishing, et ne les utilisez que depuis un poste d'administration dédié. Les comptes de service que le logiciel utilise pour lire les données des serveurs ne doivent avoir que les droits nécessaires, avec des mots de passe longs, uniques et conservés en sécurité. Si le produit le permet, exigez la validation d'une seconde personne pour supprimer des sauvegardes ou réduire la rétention, le principe des quatre yeux. Revoyez qui détient les droits d'administration des sauvegardes au moins deux fois par an et à chaque départ. Ces mesures coûtent peu et ferment l'une des failles les plus exploitées par les attaquants par rançongiciel.

Assez longtemps pour revenir à un point antérieur au début d'une intrusion et pour satisfaire vos besoins légaux et métier, mais pas plus que nécessaire pour les données personnelles. Les attaquants restent souvent des semaines dans un réseau avant d'agir, et des fichiers corrompus ou supprimés ne sont parfois remarqués que des mois plus tard : quelques jours de rétention suffisent rarement. Un schéma courant : sauvegardes quotidiennes gardées quelques semaines, hebdomadaires quelques mois, mensuelles ou trimestrielles un an ou plus, avec au moins la partie la plus récente immuable. Les règles légales de conservation, par exemple pour les documents comptables, fixent des minimums pour certaines données, tandis que le principe de limitation de la conservation du RGPD signifie que les données personnelles ne doivent pas être gardées indéfiniment simplement parce qu'elles sont dans une sauvegarde ; documentez le traitement des demandes d'effacement pour les copies de sauvegarde. Rédigez le plan de rétention et vérifiez que le système de sauvegarde l'applique réellement.

Oui, surtout les copies qui quittent vos locaux ou se trouvent chez un fournisseur cloud. Sinon, une bande, un disque ou un compartiment cloud volé est une copie complète des données de l'entreprise, et le chiffrement en fait des octets inutilisables pour le voleur ; dans le RGPD, le chiffrement figure parmi les mesures de sécurité citées à l'article 32 et peut déterminer si les personnes concernées doivent être informées de la perte d'une copie. Le point délicat est la clé. Si la clé de chiffrement n'est stockée que sur le serveur de sauvegarde et que ce serveur est détruit ou chiffré par un rançongiciel, vos sauvegardes deviennent illisibles pour vous aussi. Gardez la clé, ou la clé de récupération, dans un endroit séparé et documenté qui ne dépend pas des systèmes sauvegardés, comme un gestionnaire de mots de passe accessible hors ligne ou une copie scellée dans un coffre, et intégrez sa récupération à vos tests de restauration. Chiffrer les sauvegardes protège la confidentialité ; cela ne remplace pas l'immuabilité.

Traitez-les comme vos systèmes les plus précieux, car après une attaque, ils le sont. Placez le système de sauvegarde dans son propre segment réseau et n'autorisez que les connexions nécessaires : le trafic de sauvegarde des systèmes protégés et l'accès d'administration depuis un petit nombre de postes d'administrateurs. Fermez le bureau à distance et le partage de fichiers sur le serveur de sauvegarde sauf nécessité stricte, et ne l'utilisez jamais pour naviguer ou lire des e-mails. Corrigez vite son système d'exploitation et le logiciel de sauvegarde ; les produits de sauvegarde eux-mêmes ont eu de graves vulnérabilités exploitées par des acteurs du rançongiciel. Utilisez des comptes d'administration distincts avec MFA, sortez le serveur du domaine principal si possible et gardez au moins une copie immuable ou hors ligne. Enfin, surveillez-le : de nouveaux hôtes qui s'y connectent, des connexions à des heures inhabituelles et de grosses lectures du stockage de sauvegarde par d'autres machines que le serveur de sauvegarde méritent toutes une enquête, et toutes se voient dans le trafic réseau.

Un plan de sauvegarde répond à ces questions : qu'est-ce qui est copié, à quelle fréquence, où et pour combien de temps. Un plan de reprise après sinistre répond à celle-ci : comment faire repartir l'activité quand quelque chose de grave casse, c'est-à-dire qui décide, quels systèmes reviennent en premier, où ils tournent si le site ou le matériel d'origine a disparu, combien de temps chaque étape peut prendre, comment informer le personnel et les clients, et comment savoir qu'on a terminé. Les sauvegardes sont un ingrédient de la reprise, pas toute la recette. Des entreprises dotées d'excellentes sauvegardes perdent quand même des semaines après un rançongiciel, parce que personne ne connaissait l'ordre de restauration, que la console de sauvegarde dépendait d'un domaine qui n'existait plus, ou que la seule personne connaissant les mots de passe était en vacances. Rédigez le plan de reprise, gardez-en une copie hors de vos propres systèmes, y compris sur papier, et testez-le par un exercice réaliste au moins une fois par an, comme vous testez les restaurations.

Sauvegardez les machines virtuelles avec un outil qui comprend l'hyperviseur, afin de pouvoir restaurer rapidement une machine entière, et protégez aussi la couche hyperviseur elle-même. Beaucoup de familles de rançongiciels actuelles ont des versions conçues pour chiffrer directement les hôtes VMware ESXi, ce qui arrête d'un coup toutes les machines virtuelles qu'ils hébergent. En pratique : gardez les interfaces d'administration des hyperviseurs hors du réseau général et accessibles seulement depuis les postes d'administration ; utilisez des comptes distincts, protégés par MFA, pour l'administration des hyperviseurs et des sauvegardes ; désactivez les services inutiles, comme SSH sur les hôtes en dehors des maintenances ; corrigez vite les hyperviseurs ; et assurez-vous qu'au moins une copie de sauvegarde se trouve hors de l'environnement virtuel qu'elle protège, immuable ou hors ligne. Les instantanés de l'hyperviseur sont utiles pour revenir vite en arrière mais ne sont pas des sauvegardes : ils résident sur le même stockage et disparaissent avec lui. Testez la restauration d'une machine virtuelle complète sur un autre matériel, car après une attaque l'hôte d'origine peut être indisponible.

Il s'agit de restaurer d'abord les systèmes dans un environnement séparé et isolé, coupé du réseau de production et d'internet, où l'on peut les vérifier avant de leur faire de nouveau confiance. Après un rançongiciel, on sait rarement au départ si les sauvegardes contiennent les outils ou les comptes de l'attaquant, ni si celui-ci a encore accès au réseau. Dans une salle blanche, on reconstruit de zéro un petit ensemble d'infrastructure saine, souvent avec de nouveaux services d'identité ; les systèmes restaurés sont analysés, leurs comptes et tâches planifiées passés en revue et leur comportement observé, avant d'être seulement alors remis en production. Les grandes entreprises préparent un tel environnement à l'avance, parfois avec l'aide de leur fournisseur de sauvegarde ; les plus petites peuvent prévoir un serveur de réserve ou un compte cloud gardé à cet effet. Le but n'est pas la perfection, mais d'éviter l'échec de reprise le plus courant : restaurer directement dans un réseau compromis et se faire chiffrer une seconde fois.

On ne peut pas en être certain, mais on peut réduire nettement le risque. Commencez par la chronologie : à partir des journaux, des données des postes et de l'historique réseau, déterminez quand l'intrusion a réellement commencé, et non quand le chiffrement a eu lieu, et privilégiez pour les systèmes critiques un point de restauration antérieur à cette date. Restaurez dans un environnement isolé et analysez le résultat avec des outils de sécurité à jour, y compris les indicateurs de compromission issus de votre enquête ou de l'avis CISA correspondant. Cherchez ce qui ne devrait pas s'y trouver : nouveaux comptes locaux ou de domaine, tâches planifiées, services et éléments de démarrage, outils d'accès à distance, et web shells sur les serveurs web. Comparez la configuration restaurée avec la documentation ou une copie saine. Observez ensuite le comportement réseau du système restauré avant de lui faire confiance. NetSenX aide ici : un hôte restauré qui entame des connexions sortantes régulières ou scanne d'autres machines apparaît dans les alertes, tandis que plusieurs jours calmes sont un signe utile, mais pas absolu.

Presque personne, et personne seul. Supprimer des sauvegardes ou réduire leur rétention est l'action que les attaquants veulent le plus accomplir avant le chiffrement : elle doit donc être plus difficile que toute tâche d'administration ordinaire. Règles pratiques : seul un petit nombre d'administrateurs de sauvegarde nommément désignés détient ce droit, avec des comptes séparés du domaine principal et protégés par une MFA résistante au phishing ; toute suppression ou modification de rétention exige la validation d'une seconde personne si le produit le permet ; personne ne peut supprimer les copies immuables avant l'expiration de leur verrou ; et chaque suppression est journalisée dans un endroit que les administrateurs de sauvegarde ne peuvent pas modifier. Le personnel informatique ordinaire peut lancer et surveiller les sauvegardes et restaurer des fichiers sans pouvoir les supprimer. Revoyez régulièrement la liste des titulaires de ces droits et retirez immédiatement ceux qui partent. Si une suppression est réellement requise, par exemple par une décision de justice ou une demande d'effacement au titre du RGPD, documentez la décision et la validation.

Non. NetSenX est un service de détection et réponse réseau (NDR) : il observe la façon dont les appareils de votre réseau communiquent et vous alerte sur les signes d'intrusion, comme le beaconing, les scans, le mouvement latéral et les volumes sortants inhabituels. Il ne copie ni vos fichiers, ni vos bases de données, ni vos boîtes mail, ni vos serveurs, et ne peut pas les restaurer après un incident. NetSenX conserve ses propres données sur votre réseau : l'inventaire des appareils, les métadonnées de connexion et l'historique des alertes, avec la durée de conservation de votre offre. Cet historique est utile lors d'une reprise, car il aide à déterminer quand une intrusion a commencé et quels hôtes étaient concernés, donc quel point de restauration a des chances d'être sain. Pour les sauvegardes elles-mêmes, il vous faut une solution dédiée, idéalement avec une copie immuable ou hors ligne. NetSenX la complète en montrant les accès inhabituels au serveur de sauvegarde et le comportement suspect des systèmes restaurés.

Oui, et on l'oublie souvent. Les équipements réseau contiennent une configuration construite au fil des années : règles de pare-feu, paramètres VPN, VLAN, routage et listes d'accès. Si un pare-feu tombe en panne, est effacé par un attaquant ou doit être remplacé après une compromission, reconstruire cette configuration de mémoire prend des jours et introduit généralement des erreurs. Exportez la configuration automatiquement après chaque modification et au moins chaque semaine, stockez les copies en dehors des équipements eux-mêmes, idéalement dans un gestionnaire de versions pour voir ce qui a changé et quand, et gardez au moins une copie hors ligne. Protégez les exports, car ils contiennent des détails sensibles et parfois des identifiants ou des clés. Un historique de configuration a aussi un intérêt de sécurité : une nouvelle règle, un compte ou une redirection de port inattendus sont un signe classique qu'on a touché à un équipement en bordure de réseau. Intégrez la restauration d'une configuration d'équipement à vos tests de reprise, idéalement sur un appareil de rechange.

Pas à lui seul. Un instantané, sur une baie de stockage, une machine virtuelle ou un système de fichiers, enregistre l'état des données à un moment donné, généralement en suivant les blocs modifiés plutôt qu'en faisant une copie complète. Il est rapide et très utile pour annuler une mise à jour ratée ou récupérer un fichier supprimé. Mais il réside normalement sur le même système de stockage que les données d'origine, se gère depuis la même console avec les mêmes identifiants, et disparaît si ce stockage tombe en panne ou si un attaquant le supprime, ce que les opérateurs de rançongiciels tentent systématiquement. Un instantané devient partie d'une vraie stratégie de sauvegarde lorsqu'il est répliqué sur un stockage séparé, protégé contre la suppression et testé par restauration. Utilisez les instantanés pour réparer vite les erreurs du quotidien, et gardez des sauvegardes indépendantes, immuables ou hors ligne pour le jour où c'est le stockage lui-même qui pose problème.