Cloud La reprise après sinistre commence au niveau de l'entreprise

Une opération de sauvegarde réussie constitue un élément utile. Elle ne prouve toutefois pas que les applications, les identités, les données et les processus métier puissent être restaurés ensemble.

Le véritable test consiste à déterminer si l'organisation est capable de rétablir un service opérationnel dans un délai convenu, avec un niveau acceptable de perte de données et une attribution claire des responsabilités pour chaque décision.

La sauvegarde et la reprise après sinistre répondent à des besoins différents

Les sauvegardes permettent de conserver des copies des données qui peuvent être restaurées en cas de suppression, de corruption ou d'attaque. Elles constituent un élément essentiel de la restauration, mais ne définissent pas à elles seules l'ensemble du processus de restauration.

La reprise après sinistre rassemble les technologies, les ressources humaines et les procédures nécessaires à la restauration des services informatiques après une interruption. En fonction du service et de l'incident, cela peut impliquer la restauration de sauvegardes, la reconstruction des systèmes ou le basculement vers un environnement alternatif.

La continuité d'activité recouvre un champ encore plus large. Elle examine comment l'organisation continue de fonctionner lorsque les services ne sont pas disponibles, en tenant compte notamment du personnel, des fournisseurs, des moyens de communication et des modes de travail temporaires.

Un plan de reprise doit donc aller au-delà de la simple question : « Avons-nous une copie ? »

Il convient de déterminer quels services sont prioritaires, de quoi ils dépendent, qui est habilité à autoriser leur reprise et comment l'entreprise s'assurera qu'ils sont prêts à être utilisés.

Définissez les objectifs RTO et RPO avant de choisir la technologie

Deux mesures permettent de traduire les priorités de l'entreprise en besoins en matière de reprise :

Il s'agit là de décisions stratégiques fondées sur une analyse technique. Une plateforme financière, une application destinée aux clients et une archive interne ne nécessitent pas nécessairement le même modèle de reprise.

Les définitions du RTO et du RPO établies par le NIST constituent un point de départ utile. L'étape suivante consiste à s'accorder sur ce que ces objectifs signifient pour chaque service critique.

Les objectifs doivent également s'appuyer sur des données concrètes. Un délai de reprise des opérations (RTO) inscrit dans un plan n'équivaut pas à un délai de reprise démontré lors d'un exercice réaliste.

Les ransomwares compliquent le choix du point de restauration

La sauvegarde la plus récente n'est pas toujours la plus sûre à restaurer.

Un pirate informatique peut avoir compromis un environnement avant que l'incident ne soit détecté. Les points de restauration récents peuvent donc contenir des logiciels malveillants, des données corrompues ou des modifications de configuration indésirables.

Cela ne modifie en rien la définition du RPO. Cela détermine simplement si l'organisation est en mesure d'atteindre son objectif en s'appuyant sur un point de reprise fiable.

Les équipes chargées de la reprise après sinistre doivent analyser la chronologie de l'incident, déterminer un point de reprise approprié et valider les systèmes restaurés dans un environnement contrôlé avant de les reconnecter à l'environnement de production.

Les recommandations de Microsoft en matière de restauration après une attaque par ransomware conseillent d'identifier le dernier point de restauration valide, d'effectuer la restauration sur un réseau isolé et de vérifier que les données restaurées ne sont pas infectées.

La détection des anomalies lors des sauvegardes peut permettre de signaler des changements inhabituels. Elle doit servir à faciliter l'analyse et la validation, et non être considérée comme la preuve qu'un point de restauration est intact.

Cloud offre des choix, et non une résilience automatique

Cloud Ces services proposent différentes solutions permettant de trouver le juste équilibre entre la vitesse de reprise, les coûts d'exploitation et les exigences des applications.

Certaines charges de travail peuvent être restaurées à partir de sauvegardes. D'autres nécessitent un environnement de reprise préparé ou des systèmes répliqués pour répondre à des objectifs de reprise plus stricts.

Le choix de l'approche appropriée dépend de l'impact des temps d'arrêt et de la perte de données sur l'activité, ainsi que des dépendances de l'application.

Cloud Cela n'exclut pas les coûts liés à la reprise après sinistre. Le stockage, la réplication, la mise en réseau, les licences, la capacité de secours et les tests doivent tous être pris en compte. Les options de reprise plus rapides nécessitent généralement un investissement plus important et une meilleure préparation opérationnelle.

Les recommandations d'AWS concernant la reprise après sinistre d'cloud expliquent pourquoi les stratégies de reprise doivent être réévaluées en fonction de l'impact sur l'activité, des risques et des coûts.

La même rigueur s'applique aux environnements hybrides et multicloud. Le fait d'utiliser plusieurs plateformes ne suffit pas, à lui seul, à garantir un plan de reprise opérationnel. L'identité, la connectivité, la compatibilité des applications et la responsabilité opérationnelle doivent encore être définies et testées.

L'objectif est d'adapter le niveau de protection à l'importance stratégique des activités, sans avoir à payer pour un modèle de reprise trop exigeant pour toutes les charges de travail.

Intégrer les services d'IA dans le plan de relance

À mesure que les entreprises déploient l'IA en production, la planification de la reprise après sinistre doit aller au-delà des applications classiques et du stockage de fichiers.

Un service basé sur l'IA peut dépendre :

• Versions des modèles et artefacts de réglage fin.
• Documents sources, ensembles de données et droits d'accès correspondants.
• Bases de données vectorielles et index de recherche.
• Configuration de l'application, messages d'invite et définitions des flux de travail.
• Services d'identité, identifiants et fournisseurs de modèles externes.

Certains éléments doivent faire l'objet d'une sauvegarde. D'autres peuvent être restaurés à partir de sources protégées, à condition que le délai de restauration soit conforme aux exigences de reprise du service.

En ce qui concerne les modèles hébergés en externe, l'organisation doit également bien comprendre les responsabilités du prestataire et savoir ce qui se passe si ce service venait à être indisponible.

La question pratique est simple : que faut-il restaurer, reconstruire ou reconnecter pour que l'entreprise puisse à nouveau utiliser le service d'IA ?

Trois piliers pour une reprise plus sûre

Ces mesures de contrôle fonctionnent de concert. Les données protégées n'ont qu'une valeur limitée si personne ne peut accéder aux outils de restauration, ou si les applications restaurées sont immédiatement reconnectées à un environnement qui reste compromis.

Testez le service métier, et pas seulement la tâche de restauration

Les dispositifs de reprise doivent évoluer au fur et à mesure que les applications, les intégrations, les identités et les priorités métier changent.

Un exercice utile devrait permettre de vérifier que le service fonctionne, plutôt que de se contenter de confirmer que le serveur démarre.

Cela implique de tester les dépendances des applications, les droits d'accès, la cohérence des données, les contrôles de sécurité ainsi que la capacité de l'équipe métier à mener à bien les tâches essentielles.

L'automatisation peut faciliter les contrôles répétitifs. Elle ne dispense toutefois pas de la nécessité de mener des exercices coordonnés et d'obtenir l'aval des services opérationnels.

Consignez ce qui s'est passé, comparez les résultats avec les RTO et RPO convenus, et désignez les responsables pour chaque écart constaté. Répétez les tests concernés après toute modification importante.

Avant que le prochain incident ne se produise, la direction devrait être en mesure de répondre aux questions suivantes :

• Quels sont les services aux entreprises qui doivent se redresser en premier ?
• Quels temps d'arrêt et quelles pertes de données leurs propriétaires ont-ils acceptés ?
• À quand remonte la dernière reprise économique significative ?
• Comment allons-nous sélectionner et valider un point de restauration valide ?
• L'équipe de récupération peut-elle intervenir si les services d'identification habituels ne sont pas disponibles ?
• Qui autorise le basculement, la reconnexion et le retour au fonctionnement normal ?

Un plan de relance n'est crédible que si ces réponses s'appuient sur des éléments probants.

Comment Getronics vous aide

Les services de gestion de la continuité des services informatiques proposés par Getronics accompagnent la planification de la reprise d'activité à travers l'analyse des besoins, l'évaluation des risques, la définition des objectifs RTO et RPO, l'élaboration d'une stratégie de reprise après sinistre et la réalisation de tests gérés.

Nos services «Cloud » et «Infrastructure» assurent la liaison entre cette planification et les opérations d'cloud s privées, publiques et hybrides, notamment les options de sauvegarde, de réplication et de reprise après sinistre.

Il faut commencer par cerner les besoins de l'entreprise en matière de reprise d'activité, puis concevoir et tester une stratégie de reprise adaptée à ces besoins.

Votre plan de reprise est-il en mesure de répondre aux besoins de votre entreprise ?

Discutez avec Getronics de vos services critiques, de vos objectifs de reprise d'activité et de vos lacunes en matière de tests.