De la préoccupation informatique à la priorité d’affaires : mesurer l’impact et le retour sur investissement des programmes de sécurité modernes.
Reprise après sinistre vs. reprise cyberrésiliente après sinistre
Pour être clair, la reprise après sinistre traditionnelle et la reprise après sinistre cyber-résiliente sont liées, mais elles résolvent des problèmes différents. La reprise après sinistre traditionnelle vise à restaurer les fonctions informatiques lorsqu'un incident majeur survient. Une panne régionale due à une catastrophe naturelle peut mettre hors service une région infonuagique entière. Une panne de centre de données peut affecter un seul site au sein d'une région. Les pannes de réseau et d'infrastructure, les pannes d'applications et les changements de configuration peuvent tous entraîner des interruptions de service de gravité variable. L'objectif est de minimiser la perte de données (objectif de point de restauration, ou RPO) et le délai de restauration (objectif de temps de restauration, ou RTO) grâce à une infrastructure de secours à froid, tiède ou chaude, prête à prendre le relais. Dans les environnements d'infonuagique hyperconvergés ou modernes, l'infrastructure est associée à des outils robustes d'automatisation et d'orchestration afin d'assurer la restauration des fonctions d'affaires dans le bon ordre. La reprise après sinistre cyberrésiliente, quant à elle, aborde un scénario fondamentalement différent.Dans un événement cybernétique, les actifs ne sont pas nécessairement détruits, mais les données, les sauvegardes et même la solution de récupération elle-même peuvent être compromises. Cela peut nécessiter une isolation immédiate des charges de travail et des données critiques pendant que l’ampleur de la compromission est étudiée.
Pourquoi la cyber-résilience en gestion des données est la priorité en ce moment
Les données d'investissement révèlent une partie de la situation : les gestionnaires augmentent leurs dépenses face à une véritable évolution du paysage des menaces. Selon des enquêtes sectorielles, la plupart des dirigeants prévoient d'accroître les investissements dans la cybersécurité et la sécurité de l'information en 2026, les plaçant parmi les priorités absolues, au même titre que l'IA et l'IA générale. La demande de transfert de la responsabilité de la reprise après sinistre à une entité tierce s'accroît. Responsable de la sécurité des systèmes d'information (CISO), ce qui reflète une orientation organisationnelle plus large vers la cyber-résilience. Il s'agit d'un changement structurel. La reprise après sinistre est désormais pleinement intégrée aux discussions sur la sécurité, au même titre que la gestion des identités, la protection des terminaux et la réponse aux menaces, au lieu d'être considérée comme un dispositif opérationnel distinct.Pour les organisations qui utilisent des ERP critiques — SAP, Oracle EBS, JD Edwards et les écosystèmes applicatifs qui les entourent — cela compte encore plus. Les ERP détiennent les données que les adversaires veulent le plus corrompre ou chiffrer, ainsi que les systèmes dont l’indisponibilité nuit le plus à l’entreprise.
Avez-vous vraiment la reprise après sinistre?
C’est la question que les DSI et les OSC devraient se poser, car l’écart entre « nous avons un plan DR » et « nous avons un programme DR qui fonctionnera réellement » est souvent plus grand que prévu. Sept questions aident à révéler où se situe réellement une organisation.
1. La capacité de l'infrastructure infonuagique est-elle disponible ?
Une charge de travail exécutée dans le nuage ne bénéficie pas automatiquement d'une reprise après sinistre. Les ressources de calcul, de stockage et de réseau nécessaires au basculement doivent être réservées, provisionnées ou rapidement disponibles dans la région cible. À défaut, le plan de reprise après sinistre est voué à l'échec.
2. Les configurations d'infrastructure sont-elles répliquées ?
Les serveurs et le stockage ne suffisent pas à eux seuls. Les paramètres réseau, les règles de sécurité, l'intégration des identités, les agents de surveillance et des douzaines d'autres configurations doivent être présents dans l'environnement de reprise d'activité. Sans ça, les systèmes démarrent, mais restent inutilisables.
3. Les données sont-elles répliquées, et à quel intervalle ?
Voici ce qu'est un objectif de point de récupération (RPO) en pratique. La réplication continue permet d'atteindre un RPO quasi nul. Les sauvegardes quotidiennes entraînent jusqu'à 24 heures de perte de données potentielle. La solution optimale dépend du seuil de tolérance de l'entreprise, et de nombreuses organisations n'ont jamais défini ce seuil.
4. Les sauvegardes sont-elles cohérentes et récupérables ?
Une sauvegarde qui s'exécute avec succès ne signifie pas nécessairement qu'elle peut être restaurée avec succès. La cohérence de la base de données, les instantanés prenant en compte les applications et la validation par rapport à des configurations de référence fiables sont tous des éléments essentiels. Renforcer la cyberrésilience implique également de se poser la question suivante : cette sauvegarde est-elle immuable, isolée du réseau et validée contre les rançongiciels avant restauration ?
5. L'orchestration de tout ça est-elle automatisée ?
Les écosystèmes applicatifs complexes doivent être restaurés dans un ordre précis. Les systèmes ERP, les bases de données, les intergiciels, les intégrations et les systèmes frontaux sont tous interdépendants. C'est lors d'une restauration manuelle à 2 heures du matin que les plans de reprise d'activité (PRA) échouent généralement. L'automatisation est essentielle pour une reprise réussie et une interruption de service prolongée.
6. Le processus est-il documenté et accessible ?
La documentation n'est utile que si elle est accessible au moment opportun. Si les manuels d'exploitation sont hébergés sur un système hors service ou si leurs auteurs sont injoignables, le plan est incomplet. L'accessibilité en situation réelle est une exigence de conception, et non une simple option.
7. Avez-vous testé la solution avec succès ?
Un programme de reprise après sinistre (PRA) non testé intégralement demeure une hypothèse. La plupart des organisations effectuent des tests de continuité des activités, exécutés dans un environnement isolé, qui vérifient le bon fonctionnement des systèmes. Rares sont celles qui effectuent des tests de PRA complets, où la production est mise hors service et les opérations basculent réellement vers le site secondaire. Encore plus rares sont celles qui effectuent des tests de basculement et de restauration pour confirmer la réversibilité des procédures de reprise.
Plus les tests se rapprochent d’un scénario de catastrophe réelle, plus l’organisation peut être confiante dans le résultat.
Syntax: Votre reprise après sinistre en tant que partenaire de service
Moderniser un programme de réduction des données n’est pas un projet en une étape, et il ne nécessite pas de démolir complètement ce qui existe déjà. La plupart des organisations peuvent améliorer leur objectif de point de récupération et leur objectif de temps de récupération, et ajouter une protection contre les rançongiciels sans augmenter considérablement les coûts. Ils ont juste besoin d’un partenaire en reprise après sinistre en tant que service (DRaaS) qui puisse voir l’ensemble des applications, de l’infrastructure et du nuage.Syntax Services de sécurité
Le risque de cybersécurité demeure l’une des plus grandes menaces pour la plupart des entreprises, et les analystes de l’industrie estiment que la prolifération des cyberattaques activées par l’IA ne fera qu’augmenter avec les avancées des grands modèles de langage (LLM).
Auteur
