Les ransomwares ne se contentent pas de chiffrer les fichiers d’un seul ordinateur. Lorsqu’ils atteignent un serveur d’entreprise, ils peuvent se propager via les dossiers partagés, exploiter les privilèges administrateur, désactiver les outils de sécurité et rechercher tous les systèmes de sauvegarde connectés. Les attaquants ne cherchent pas seulement à interrompre les opérations ; ils tentent aussi de supprimer votre capacité à récupérer vos données sans payer.
L’architecture de sauvegarde fait donc partie intégrante de la protection des serveurs contre les ransomwares. Une sauvegarde en ligne, accessible en écriture et contrôlée par les mêmes identifiants que l’environnement de production peut être attaquée en même temps que les données originales. Une copie présente uniquement sur un disque local peut être supprimée. Un fournisseur de sauvegarde capable de lire les données ou de réinitialiser l’accès sans votre approbation peut devenir un autre moyen de pression.
Les sauvegardes résistantes aux ransomwares reposent sur la séparation, la restriction des accès, le chiffrement, les contrôles de rétention et des tests réguliers de restauration. Ces recommandations s’appliquent aux serveurs que l’entreprise possède ou contrôle, notamment les serveurs physiques, les machines virtuelles et les infrastructures cloud dédiées. Elles ne décrivent pas une offre Safenix destinée aux sites web ou aux bases de données fonctionnant sur un hébergement mutualisé. Les clients d’un hébergement mutualisé doivent vérifier ce que leur hébergeur sauvegarde et la manière dont les restaurations sont gérées.
Comment les ransomwares utilisent les sauvegardes comme moyen de pression
Une attaque classique commence par un service exposé, un mot de passe volé, une pièce jointe malveillante ou une application non corrigée. Une fois à l’intérieur, l’attaquant cherche à augmenter ses privilèges et à se déplacer latéralement. Les serveurs sont particulièrement intéressants, car ils contiennent souvent des données d’entreprise et donnent accès aux applications, aux partages de fichiers, aux bases de données et aux systèmes d’identité.
L’attaquant peut prendre le temps d’explorer l’environnement avant de chiffrer quoi que ce soit. Durant cette période, il peut identifier les logiciels de sauvegarde, les consoles d’administration, les partages réseau et les tâches planifiées. Il peut voler les identifiants utilisés par les agents de sauvegarde ou les administrateurs, puis attendre de pouvoir toucher simultanément les systèmes de production et de récupération.
Lorsque la phase de chiffrement commence, les conséquences peuvent inclure :
- Les fichiers professionnels et les données applicatives deviennent inaccessibles.
- Les machines virtuelles, les bases de données ou les serveurs de fichiers sont chiffrés ou endommagés.
- Les agents de sauvegarde et les services d’administration sont arrêtés.
- Les disques de sauvegarde locaux et les partages réseau sont supprimés ou chiffrés.
- Les identifiants de récupération sont modifiés ou utilisés pour détruire les points de restauration.
- Les données sont copiées hors de l’environnement à des fins d’extorsion.
C’est pourquoi une organisation peut disposer d’une tâche de sauvegarde signalée comme réussie la veille et être pourtant incapable de récupérer ses données le lendemain. L’existence d’une sauvegarde n’est pas synonyme d’indépendance de la récupération. La question essentielle est de savoir si un attaquant contrôlant un serveur de production peut également modifier, effacer, lire la sauvegarde ou en bloquer l’accès.
Pour obtenir davantage de contexte avant d’évaluer un fournisseur ou de repenser un plan de récupération, recherchez les bonnes pratiques de sauvegarde des serveurs résistantes aux ransomwares et comparez la manière dont chaque approche gère les accès, la rétention et la restauration.
Pourquoi les sauvegardes locales et connectées en permanence échouent
Les copies locales sont exposées au même incident
Un disque USB, un second disque interne ou un serveur de sauvegarde situé dans les mêmes locaux peut être utile pour une récupération rapide, mais ne constitue pas une protection suffisante à lui seul. Un incendie, un vol, un incident électrique ou une panne matérielle peut affecter le serveur d’origine et ses copies locales. Un ransomware peut avoir la même portée si le périphérique de sauvegarde est monté, mappé ou accessible via le réseau.
Si un compte de sauvegarde dispose d’un accès en écriture à un référentiel local, un logiciel malveillant utilisant ce compte peut supprimer les versions historiques ou les remplacer par des fichiers chiffrés. Même si les données ne sont pas chiffrées, l’attaquant peut simplement supprimer le catalogue ou la configuration nécessaires à la restauration.
Les référentiels accessibles en écriture offrent une cible aux attaquants
Les logiciels de sauvegarde doivent normalement écrire de nouveaux points de récupération. C’est nécessaire au fonctionnement habituel, mais cela crée un risque lorsque le référentiel reste librement accessible en écriture pendant trop longtemps. Si un attaquant obtient les identifiants utilisés par le service de sauvegarde, il peut être capable de modifier ou de supprimer les points existants, en plus d’en créer de nouveaux.
Les contrôles de rétention modifient cet équilibre. Un point de récupération verrouillé ou immuable ne peut pas être modifié ou supprimé pendant sa période de protection, même si un identifiant administrateur est compromis. L’immuabilité n’empêche pas tous les incidents et ne remplace ni les contrôles d’accès ni les tests, mais elle élimine l’une des actions les plus dommageables pour un attaquant : détruire discrètement l’historique de récupération.
Les systèmes connectés peuvent partager la même défaillance
Un système de sauvegarde administré depuis la même plateforme d’identité, le même poste administrateur ou le même segment réseau que la production peut subir la même compromission. La gestion centralisée est pratique, mais cette commodité ne doit pas signifier qu’un seul mot de passe volé contrôle toutes les copies des données.
L’infrastructure de récupération doit être considérée comme une frontière de sécurité distincte. Moins un attaquant dispose de chemins entre un serveur de production et le référentiel, moins une compromission du serveur risque de se transformer en compromission totale de la récupération.
Ce que comprend une stratégie de sauvegarde anti-ransomware en plusieurs niveaux
Aucune fonctionnalité isolée ne rend une sauvegarde invulnérable aux ransomwares. La résilience repose sur plusieurs mesures de protection qui fonctionnent ensemble.
Des copies hors site séparées
Une sauvegarde hors site crée une distance avec l’incident. Elle peut protéger contre un incident dans la salle des serveurs, une panne généralisée du site ou un attaquant ayant pris le contrôle du réseau local. La séparation doit être réelle : un référentiel situé ailleurs mais administré avec le même compte compromis peut ne pas offrir une indépendance suffisante.
Safenix propose la sauvegarde hors site des serveurs d’entreprise, avec des données de sauvegarde stockées en Allemagne. Le service est destiné aux serveurs contrôlés par le client, et non aux sites hébergés sur une plateforme mutualisée. Les agences et les petites entreprises doivent recenser tous les serveurs importants, identifier leurs données et leurs applications, puis vérifier que la conception de sauvegarde choisie peut protéger ces systèmes.
Une rétention immuable
L’immuabilité signifie que les points de récupération sont protégés contre toute modification ou suppression pendant une période de rétention définie. Cette période doit couvrir la durée pendant laquelle une attaque pourrait passer inaperçue. Si un ransomware était présent depuis plusieurs semaines avant le chiffrement, une courte période de rétention pourrait ne conserver que des données déjà compromises.
Avec Safenix, les données de sauvegarde sont immuables pendant toute la durée de la période de rétention choisie. Le paramètre de rétention mérite donc une attention particulière. Il ne s’agit pas seulement d’une préférence de stockage ; il fait partie du plan de réponse aux incidents.
Un chiffrement avant le transfert
Le chiffrement protège la confidentialité des données de sauvegarde pendant leur transfert et leur stockage. Il reste important même lorsque le référentiel de sauvegarde se trouve dans une juridiction de confiance, car les opérateurs de stockage, les comptes compromis et les personnes internes non autorisées ne doivent pas pouvoir lire automatiquement les fichiers de l’entreprise.
Le chiffrement est plus efficace lorsqu’il est effectué avant que les données ne quittent l’environnement contrôlé par le client et lorsque le client contrôle la clé. Safenix chiffre les données avant leur transfert et la clé de chiffrement est contrôlée par le client ; Safenix ne la détient jamais. Ce dispositif vise à empêcher les attaquants ou le fournisseur de lire les données de sauvegarde sans la clé détenue par le client. En savoir plus sur les clés de chiffrement détenues par le client et la manière dont elles rendent les données de sauvegarde illisibles pour les attaquants et les fournisseurs.
La conservation de la clé implique une responsabilité autant qu’un avantage. Si l’entreprise perd la clé, elle peut perdre la capacité de déchiffrer ses propres points de récupération. Les procédures relatives aux clés doivent prévoir un stockage sécurisé, un accès limité, une propriété documentée et un processus de récupération testé. Une clé ne doit pas exister uniquement dans la mémoire d’un employé ou sur le même serveur qu’un ransomware pourrait compromettre.
Des accès fondés sur le moindre privilège
Les comptes de sauvegarde doivent disposer uniquement des autorisations nécessaires à leur tâche spécifique. Un compte de service capable d’écrire des données de sauvegarde n’a pas nécessairement besoin de pouvoir supprimer tous les points historiques, administrer le système d’exploitation ou accéder à des serveurs sans rapport.
Les contrôles pratiques comprennent :
- Des identifiants distincts pour les agents de sauvegarde, l’administration du référentiel et l’administration des serveurs.
- L’authentification multifacteur pour les interfaces d’administration lorsqu’elle est disponible.
- La restriction des accès selon le rôle, le périphérique, le réseau et l’horaire lorsque cela est pertinent.
- La suppression des comptes administrateur dormants et des mots de passe partagés.
- La surveillance des suppressions inhabituelles, des modifications de rétention et de l’activité de connexion.
- Le stockage sécurisé des identifiants de récupération en dehors du serveur de production.
Les accès doivent être réexaminés lors du départ d’un collaborateur, d’un changement de responsabilités ou de la perte d’un client par une agence. Un ancien administrateur disposant d’identifiants de sauvegarde valides peut être aussi dangereux qu’un attaquant externe.
Des tests de restauration
Une tâche de sauvegarde réussie prouve que les données ont été écrites. Elle ne prouve pas qu’une application peut démarrer, qu’une base de données est cohérente, que les identifiants fonctionnent ou que l’entreprise connaît la bonne séquence de récupération. Les tests de restauration transforment une hypothèse en preuve.
Les tests doivent couvrir les fichiers individuels ainsi que les systèmes complets. Pour une application critique, vérifiez que le serveur restauré démarre, que les services se lancent, que les bases de données s’ouvrent, que les autorisations des utilisateurs sont conservées et que les systèmes dépendants peuvent se connecter. Notez le temps nécessaire et les éventuelles étapes manuelles. Une restauration qui ne fonctionne que lorsqu’un employé indisponible se souvient d’une procédure non documentée ne constitue pas un plan de récupération fiable.
Choisir la bonne période de rétention
La rétention doit tenir compte à la fois des besoins opérationnels et de la durée probable de présence d’un attaquant dans l’environnement. Conserver davantage de versions n’est pas automatiquement préférable si l’entreprise ne peut pas financer le stockage ou ne sait pas identifier un point de récupération sain. Conserver trop peu de versions peut ne laisser aucune copie utilisable une fois l’infection découverte.
Les petites entreprises et les agences doivent prendre en compte :
- La rapidité avec laquelle le ransomware serait détecté après la première compromission.
- La fréquence à laquelle les données importantes changent et la quantité de données qu’il est acceptable de perdre.
- Les obligations légales, contractuelles ou comptables imposant la conservation d’archives.
- La durée pendant laquelle un projet client, une campagne ou une transaction peut devoir être consulté à nouveau.
- La durée pendant laquelle l’entreprise peut fonctionner pendant l’analyse et la reconstruction d’un système.
- La couverture des week-ends, des jours fériés et des absences du personnel par la période de rétention.
Une approche utile consiste à définir un objectif de point de récupération, qui correspond à l’ancienneté maximale acceptable des données restaurées, ainsi qu’un objectif de délai de récupération, qui correspond au délai acceptable pour rétablir le service. Ajoutez ensuite une rétention historique suffisante pour tenir compte d’une détection tardive. Une entreprise peut avoir besoin de points récents fréquents pour les erreurs quotidiennes et de points plus anciens protégés pour faire face à un ransomware.
La rétention doit être réévaluée après des changements importants, comme l’ajout d’un nouveau serveur, le déplacement d’une application, la modification d’obligations réglementaires ou la découverte qu’une attaque est restée inaperçue plus longtemps que prévu. L’immuabilité n’est utile que pendant la période où des données saines restent disponibles.
Comment vérifier les points de récupération avant un incident
La vérification doit être une routine, et non une opération tentée pour la première fois lors d’une panne. Commencez par vérifier que les tâches planifiées s’exécutent pour chaque serveur requis et que les échecs déclenchent une alerte dont une personne est chargée d’assurer le suivi.
Examinez un échantillon de points de récupération et confirmez leurs dates, leur statut de protection et leur taille attendue. Une sauvegarde anormalement petite peut indiquer un volume manquant, un agent défaillant ou un répertoire exclu. Une tâche réussie sans données récentes ne constitue pas un plan de récupération réussi.
Réalisez régulièrement des restaurations contrôlées. Pour les fichiers, ouvrez des documents représentatifs et vérifiez les autorisations. Pour les bases de données, utilisez un processus de récupération adapté aux applications et contrôlez la cohérence. Pour les serveurs complets, testez la procédure de reconstruction ou de restauration dans un environnement isolé, sans risque d’interférence avec la production.
Conservez un rapport de récupération contenant :
- Le serveur et l’application couverts.
- Le point de récupération sélectionné et la raison pour laquelle il a été considéré comme sain.
- La clé et les identifiants requis, sans exposer ces secrets dans le rapport.
- Les étapes réalisées et le temps nécessaire.
- Les erreurs, dépendances ou solutions de contournement manuelles.
- Le responsable chargé de corriger les défaillances.
Les preuves issues d’un test de restauration aident également une agence à démontrer à ses clients qu’elle applique des contrôles cohérents. Il est plus crédible d’indiquer la date du dernier test de récupération que de simplement affirmer que des sauvegardes existent.
Que faire des identifiants de sauvegarde avant une attaque
La protection des identifiants de sauvegarde mérite la même rigueur que celle des comptes administrateur de domaine. Ne les enregistrez pas en clair sur le serveur qu’ils protègent, dans un tableur non géré ou dans une conversation partagée. Utilisez un gestionnaire de mots de passe correctement sécurisé ou un processus contrôlé de gestion des secrets, et veillez à ce que plusieurs personnes autorisées puissent accéder à la procédure de récupération sans créer un mot de passe largement partagé.
Séparez les accès d’urgence des accès quotidiens. Le personnel courant ne devrait pas disposer de droits permanents pour supprimer des points de rétention ou modifier les politiques du référentiel. Dans la mesure du possible, utilisez une autorisation soumise à approbation ou limitée dans le temps pour les actions à fort impact. Examinez les journaux d’audit afin de détecter les modifications de la rétention, des paramètres de chiffrement, des destinations du référentiel et des rôles administrateur.
Décidez également de la manière dont l’organisation réagira si un identifiant est soupçonné d’avoir été volé. La procédure peut prévoir la désactivation du compte, la rotation des secrets, la conservation des journaux, l’isolement des serveurs et le contact avec l’administrateur de sauvegarde. Attendre la phase de chiffrement pour concevoir ce processus fait perdre un temps précieux.
Priorités lors de la découverte d’un ransomware
Le premier objectif est d’arrêter les dommages supplémentaires, et non de se précipiter vers une restauration qui pourrait réintroduire l’attaquant. Isolez les serveurs et les terminaux concernés conformément au plan de réponse aux incidents. Déconnectez les systèmes du réseau lorsque cela est approprié, préservez les éléments de preuve et impliquez les responsables de la sécurité, de l’infrastructure et des décisions juridiques ou réglementaires.
Établissez ensuite les faits connus. Identifiez les serveurs touchés, le moment où la première activité suspecte a pu se produire, les identifiants exposés et l’éventuel accès aux systèmes de sauvegarde. Ne présumez pas que le point de récupération le plus récent est sûr. Choisissez un point de restauration en vous fondant sur les éléments disponibles, l’historique des sauvegardes saines et la priorité métier du système.
Priorisez les systèmes dans un ordre défini :
- L’identité, l’authentification et les services réseau essentiels à la récupération.
- Les applications critiques nécessaires à la fourniture de produits, de services ou de fonctions liées à la sécurité.
- Les bases de données et les services de fichiers dont dépendent ces applications.
- Les systèmes de communication, financiers et administratifs.
- Les systèmes moins critiques et les données historiques.
L’ordre exact varie selon l’organisation. Une agence peut restaurer en premier les fichiers de projets et les systèmes destinés aux clients, tandis qu’un petit fabricant peut donner la priorité au contrôle de la production et aux stocks. Documentez les dépendances avant un incident afin de ne pas restaurer le système le plus visible avant les services dont il dépend.
Lorsque les sauvegardes sont inaccessibles, corrompues ou détenues par l’attaquant
Si les sauvegardes sont inaccessibles, l’entreprise peut subir une interruption plus longue, le temps de reconstruire les comptes, l’infrastructure et le stockage. Si elles sont corrompues, la récupération peut nécessiter de localiser un point plus ancien et de valider manuellement chaque système. Si l’attaquant a obtenu la clé ou contrôle l’unique copie de la clé, les données de sauvegarde chiffrées peuvent rester illisibles même si les fichiers existent toujours.
Des conséquences juridiques, contractuelles et réputationnelles peuvent également survenir. Les retards de livraison aux clients, la perte de documents financiers, les obligations de notification en matière de confidentialité et les coûts de récupération d’urgence peuvent tous découler d’une stratégie de sauvegarde défaillante. Le paiement d’une rançon ne garantit ni un déchiffrement complet, ni la suppression des données volées, ni un environnement sûr après la restauration.
La réponse pratique consiste à préserver ce qui peut l’être, à faire appel à des spécialistes si nécessaire, à notifier les parties concernées conformément aux obligations applicables et à reconstruire à partir du point de récupération sain contrôlé de manière indépendante qui est disponible. C’est précisément pourquoi la séparation hors site, la rétention immuable, les procédures relatives aux clés détenues par le client et les tests de restauration doivent être mis en place avant une attaque.
Liste de contrôle préventive pour renforcer la résilience des serveurs face aux ransomwares
Utilisez cette liste comme point de départ pour une revue trimestrielle et après toute modification importante de l’infrastructure :
- Répertoriez chaque serveur, application, base de données et ensemble de données critiques contrôlé par l’organisation.
- Confirmez que chaque serveur requis est inclus dans le périmètre de sauvegarde.
- Conservez au moins une copie hors site réellement séparée de l’environnement de production.
- Utilisez une rétention immuable ou verrouillée pendant la période définie par le plan de récupération.
- Confirmez où le chiffrement est effectué et qui contrôle la clé de déchiffrement.
- Stockez le matériel cryptographique de manière sécurisée, avec une propriété documentée et une procédure d’accès testée.
- Utilisez des identifiants de sauvegarde distincts, soumis au moindre privilège, et protégez l’accès d’administration par une authentification forte.
- Vérifiez les alertes concernant les tâches échouées, les données manquantes, les suppressions inhabituelles et les modifications de rétention.
- Testez régulièrement les restaurations de fichiers, d’applications et de serveurs complets.
- Consignez les objectifs de point de récupération, les objectifs de délai de récupération et les dépendances entre systèmes.
- Documentez l’ordre d’isolement, d’analyse et de restauration des systèmes.
- Veillez à ce qu’au moins deux personnes autorisées sachent démarrer le processus de récupération.
- Réévaluez la rétention après toute évolution des capacités de détection, du volume de données ou des besoins de l’entreprise.
Les sauvegardes doivent réduire le pouvoir de pression d’un attaquant, et non devenir un autre système qu’il peut contrôler. Pour les entreprises qui exploitent des serveurs sous leur contrôle, l’association d’un stockage hors site en Allemagne, d’un chiffrement effectué avant le transfert, d’une clé que Safenix ne détient jamais et d’une immuabilité pendant la période de rétention choisie constitue une base plus solide pour la récupération. Complétez cette base par des accès soumis au moindre privilège et des tests réguliers de restauration : le ransomware devient alors un incident grave à gérer plutôt qu’une demande déterminant si l’entreprise peut continuer son activité.