Un ransomware n’entraîne pas un seul type d’arrêt. En PME, les scénarios les plus fréquents sont souvent des combinaisons de blocage technique, de décisions de sécurité et de contraintes métiers.

Scénario 1 : chiffrement des serveurs et des postes

L’attaque se propage via un compte compromis, une vulnérabilité, un poste exposé ou une pièce jointe malveillante. Les partages de fichiers, serveurs applicatifs et postes deviennent indisponibles. La production peut s’arrêter faute d’accès aux plans, aux ordres de fabrication, aux données clients ou aux outils de supervision.

Scénario 2 : services « critiques mais invisibles » hors service

Même si certaines applications semblent intactes, l’authentification (annuaire), la messagerie, le DNS, les certificats, ou les outils de gestion peuvent être impactés. Résultat : l’ERP ou la facturation sont techniquement présents, mais inexploitables.

Scénario 3 : sauvegardes inutilisables

C’est un cas redouté : les sauvegardes ont été chiffrées, supprimées, ou rendues incohérentes. Parfois, elles existent mais la restauration dépasse les capacités (temps, bande passante, compétences disponibles) ou dépend de mots de passe perdus.

Scénario 4 : arrêt volontaire pour contenir

Face au doute, l’entreprise coupe des accès, isole des segments réseau, ou arrête des serveurs par précaution. L’impact opérationnel est immédiat, même si le chiffrement n’a pas touché partout.

Pour cadrer un PRA, il faut traduire ces scénarios en « impacts » concrets : impossibilité de livrer, de facturer, de produire, ou de répondre aux obligations légales et contractuelles. Cette clarification permettra ensuite de prioriser la reprise, plutôt que de chercher à tout rétablir en même temps.

RTO et RPO sont les deux axes qui transforment un PCA/PRA en plan actionnable, parce qu’ils forcent à arbitrer entre rapidité, perte de données acceptable, complexité et coût.

Définitions opérationnelles

• RTO (Recovery Time Objective) : délai cible pour remettre un service en fonctionnement après un incident majeur. Concrètement : « à partir de quand l’application doit redevenir utilisable ».
• RPO (Recovery Point Objective) : quantité de données que l’on accepte de perdre, mesurée comme un « retour en arrière » maximal. Concrètement : « jusqu’à quel point dans le passé les données restaurées doivent être à jour ».

Méthode pragmatique en PME

1. Lister les processus vitaux (facturation, production, ERP, messagerie, portail client, gestion des achats, etc.) et les dépendances (annuaire, stockage, réseau, accès internet).
2. Qualifier l’impact métier si le processus est indisponible : pertes de revenus, pénalités contractuelles, rupture de production, désorganisation interne, atteinte à l’image, obligations de conservation.
3. Définir une priorité de reprise : ce qui doit revenir d’abord, ensuite, et ce qui peut attendre. Un bon indicateur est la question : « quelle activité l’entreprise doit pouvoir faire même en mode dégradé ? ».
4. Fixer des RTO/RPO par service, pas “par entreprise”. L’ERP n’a pas forcément les mêmes exigences que la messagerie ou qu’un serveur de fichiers.
5. Valider la faisabilité : le RTO/RPO doit être compatible avec l’architecture, les volumes, les compétences et le budget. Si l’objectif est irréaliste, il doit être renégocié, ou l’architecture doit évoluer.

Le bon RTO/RPO est celui que la direction comprend, accepte et finance, et que l’équipe IT sait démontrer lors d’un test de restauration ou de bascule.

Une architecture PRA anti-ransomware combine généralement plusieurs mécanismes. Le choix dépend des RTO/RPO, mais aussi du scénario : restauration après chiffrement n’est pas la même chose qu’une continuité après panne matérielle.

Sauvegarde : la base pour reconstruire

La sauvegarde sert à revenir à un état sain. Elle est indispensable contre le ransomware, mais son point faible est le temps : restaurer des volumes importants peut être long. Elle exige aussi une bonne hygiène : inventaire des données, politiques de rétention, et restauration maîtrisée.

Réplication : utile, mais pas une protection ransomware par défaut

La réplication (synchrone ou asynchrone) réduit le délai de reprise, mais elle peut répliquer le problème : si un chiffrement ou une suppression logique se propage, la copie répliquée peut être contaminée. Elle devient pertinente si elle s’accompagne de mécanismes de points de restauration, d’immutabilité, et de contrôles d’accès solides.

Site de secours : continuité, mais dépendances fortes

Un site de secours (deuxième salle, hébergeur, ou site mutualisé) aide à redémarrer des services critiques. Limites fréquentes en PME : maintien en condition opérationnelle, cohérence des configurations, capacités réseau, disponibilité des licences et des compétences pour opérer en mode dégradé.

Cloud : flexibilité, mais exigences d’architecture

Le cloud peut accélérer certaines reprises (redéploiement, stockage de sauvegardes, capacités à la demande), mais n’élimine pas la nécessité de concevoir : segmentation des comptes, contrôles d’accès, gestion des clés, et procédures de restauration. Il faut aussi considérer la dépendance à l’accès internet et aux identités.

En pratique, une PME obtient souvent un bon équilibre en combinant : sauvegarde robuste (pour revenir à sain), mécanismes de reprise accélérée pour un petit périmètre prioritaire, et un mode dégradé documenté pour tenir pendant la reconstruction.

Dans de nombreuses attaques, l’assaillant cherche explicitement à rendre la restauration impossible : suppression des points de sauvegarde, chiffrement des dépôts, vol d’identifiants d’administration. Deux principes réduisent fortement ce risque : l’immutabilité et la séparation.

Immutabilité : empêcher la modification ou la suppression

Une sauvegarde « immuable » est conservée de façon à ne pas pouvoir être altérée pendant une période définie. Les mises en œuvre varient (stockage avec verrouillage, politiques de conservation non modifiables, snapshots protégés), mais l’objectif est le même : même avec des droits élevés, l’effacement ou l’altération doit être bloqué ou fortement contraint.

Séparation des accès : casser le chemin d’attaque

Un ransomware profite souvent d’un contrôle centralisé : un compte admin compromis, et tout tombe. Mesures clés :

• Comptes dédiés à la sauvegarde, distincts des comptes d’administration du domaine et des comptes utilisateurs.
• Authentification forte sur les consoles de sauvegarde et les portails cloud.
• Moindre privilège : droits limités au strict nécessaire, y compris pour les opérateurs IT.
• Chemins d’administration séparés (réseau d’admin, bastion) pour réduire l’exposition.
• Procédures “break-glass” : accès d’urgence contrôlé, tracé, et régulièrement vérifié.

Indicateur simple : « qui peut supprimer mes sauvegardes ? »

Si la réponse est « un compte utilisé au quotidien » ou « le même compte que pour administrer les serveurs », le risque est élevé. L’objectif n’est pas la perfection, mais une défense en profondeur qui rend la destruction des sauvegardes beaucoup plus difficile et détectable.

Ces mesures s’alignent avec les recommandations de bonnes pratiques publiées par des organismes publics dédiés à la cybersécurité et à la résilience.

Un PRA sans tests est une hypothèse. Le test n’est pas un “exercice IT” : c’est la démonstration que les RTO/RPO sont atteignables, que les équipes savent quoi faire, et que les dépendances invisibles ont été identifiées.

Table-top : tester le scénario sans toucher la production

Le table-top est une simulation structurée (direction, IT, métiers, éventuellement prestataires) : qui décide l’isolement, qui contacte qui, quels services reprennent en premier, quels critères définissent “retour à la normale”. On y valide aussi les éléments non techniques : communication interne, clients, assurances, obligations.

Tests de restauration : la preuve la plus utile

Les tests de restauration consistent à restaurer réellement : une machine, une base de données, un fichier critique, une application complète. Bonnes pratiques :

• Restaurer avec des objectifs (temps, point de reprise) et mesurer les écarts.
• Tester la cohérence applicative (dépendances, services, certificats, comptes de service).
• Vérifier la lisibilité : procédure, accès, mots de passe d’urgence, disponibilité des médias.

Tests de bascule : pour les services prioritaires

La bascule (failover) est pertinente quand on vise une reprise rapide d’un périmètre critique. Elle doit inclure le retour arrière (failback) et la gestion du mode dégradé.

Fréquence : pilotée par le changement

Plutôt qu’un calendrier arbitraire, l’enjeu est de tester après les changements significatifs : migration d’ERP, modification d’infrastructure, changement de prestataire, évolution majeure du stockage. Un minimum consiste à conserver un rythme régulier de tests ciblés et à refaire un exercice complet quand le contexte évolue.

Le livrable attendu : un compte-rendu de test avec écarts, décisions, et actions correctives, intégré au pilotage de la sécurité et de la continuité.

Le ransomware est un risque d’entreprise. Un PRA qui fonctionne suppose donc une gouvernance claire : les métiers expriment le besoin, la direction arbitre, l’IT conçoit et opère, et chacun accepte ses responsabilités.

Décisions à faire porter par la direction

• Priorités de reprise : quelles activités doivent repartir en premier, et en mode normal ou dégradé.
• RTO/RPO cibles : acceptation explicite du compromis entre coût, complexité et risque.
• Niveau de risque résiduel : ce qui reste possible malgré les protections.

Ce que l’IT doit cadrer et maintenir

• Cartographie des services et dépendances (y compris identité, DNS, certificats, supervision).
• Procédures de restauration : pas seulement “où sont les sauvegardes”, mais “comment remettre en service”.
• Gestion des accès : séparation des rôles, comptes d’urgence, traçabilité.
• Indicateurs de préparation : succès des restaurations de test, écarts RTO/RPO, dette technique.

Comment éviter le PRA “sur étagère”

• Intégrer le PRA au cycle de changement : tout projet qui modifie une application critique doit mettre à jour la reprise.
• Contractualiser avec les prestataires : responsabilités, délais d’intervention, accès d’urgence, documentation.
• Prévoir du temps : la résilience n’est pas un achat ponctuel, c’est un fonctionnement.

Un PRA réaliste n’est pas forcément “le plus rapide”. C’est celui qui reflète les priorités métiers, qui tient compte des ressources d’une PME, et dont la capacité de reprise est régulièrement démontrée.

Cette checklist aide à transformer le cadrage en actions concrètes, sans chercher à tout faire d’un coup.

Cadrage métier

• Identifier les processus vitaux (facturation, production, relation client, achats, paie, etc.).
• Associer à chaque processus une application principale et ses dépendances (identité, stockage, réseau, accès).
• Valider la priorité de reprise avec la direction et les responsables métiers.

Objectifs RTO/RPO

• Définir un RTO et un RPO par service prioritaire.
• Documenter les hypothèses : volumes de données, fenêtres de sauvegarde, disponibilité des équipes.
• Valider que les objectifs sont testables (critères de succès clairs).

Sauvegardes et reprise

• Vérifier l’existence de copies de sauvegarde séparées de la production.
• Mettre en place une protection d’immutabilité ou un mécanisme équivalent selon l’environnement.
• Séparer les accès : comptes dédiés, authentification forte, moindre privilège, accès d’urgence.
• Documenter une procédure de restauration “pas à pas” (y compris prérequis et dépendances).

Tests et amélioration continue

• Planifier un exercice table-top (rôles, décisions, communications, escalades).
• Planifier des restaurations réelles sur un périmètre prioritaire et mesurer les écarts.
• Consigner les résultats, décider les corrections et les prioriser.
• Mettre à jour le PRA après les changements majeurs d’infrastructure ou d’applications.

Gouvernance

• Nommer un responsable de la continuité (métier) et un responsable PRA (IT).
• Définir qui déclenche la reprise, qui autorise les actions risquées, qui valide le retour en production.
• S’assurer que les coordonnées, accès et éléments critiques sont disponibles même en cas d’indisponibilité interne.