Stratégie de reprise après sinistre : cinq lignes d'action

Selon Rapport d'enquête sur les violations de données 2019 de Verizon les attaques de ransomware représentent 24 % des incidents de malware analysés. En Suisse aussi, le nombre d'attaques continue d'augmenter : ce n'est qu'en juillet que le trio de ransomware Emotet, Trickbot et Ryuk a paralysé les systèmes informatiques du groupe Offix. Pour les décideurs d'entreprise, il est donc de plus en plus important de placer la continuité des activités et la protection des données en tête de l'agenda, afin de pouvoir continuer à travailler même en cas de catastrophe. Dans ce contexte, une stratégie de reprise après sinistre s'impose d'urgence. Nous montrons en cinq étapes comment les entreprises peuvent se préparer à un scénario catastrophe.

1. Fixer les RTO et les RPO

Toutes les applications commerciales n'ont pas la même importance pour les entreprises. Les exigences en matière de temps de récupération sont donc individuelles. Les décideurs informatiques devraient évaluer à l'avance quelles applications sont critiques pour l'entreprise : Si une entreprise ne peut pas fonctionner sans un certain service, celui-ci ne doit pas être interrompu pendant plus de 15 minutes. Le Recovery Time Objective (RTO) définit le délai maximal qui devrait s'écouler avant que tous les éléments d'une application ne soient à nouveau opérationnels. Le Recovery Point Objective (RPO), quant à lui, indique le niveau maximal de perte de données qui doit être atteint pour maintenir la continuité des activités. Toute stratégie de récupération doit s'aligner sur les RTO et RPO définis.

2. Automatiser les processus

L'automatisation est l'alpha et l'oméga d'une stratégie de reprise après sinistre réussie. Les processus de restauration exécutés manuellement comportent un risque d'erreur significatif. C'est pourquoi les entreprises devraient par exemple mettre en place des processus de basculement et de reprise automatique. Un basculement automatisé est particulièrement important pour la continuité des activités. Si une application critique tombe en panne, elle veille dans le meilleur des cas à ce que l'utilisateur ne remarque même pas la panne du système. Pour cela, le basculement initie la commutation sur un autre système qui prend le relais de celui qui est tombé en panne. Une fois le système initial rétabli, le failback consiste à rétablir le service dans sa situation initiale. Le système primaire est mis à jour avec les charges de travail qui ont été produites entre-temps dans le système secondaire.

3. Évaluer individuellement les scénarios de défaillance

Les entreprises doivent décider de manière flexible, en fonction de la situation, quelles applications et quels systèmes doivent être restaurés. Cela peut concerner des machines virtuelles, un grand nombre d'applications complexes ou un centre de données entier. La stratégie de récupération de l'entreprise doit être suffisamment adaptable pour que différents scénarios puissent être gérés sans problème et que le travail puisse reprendre rapidement. Un plan d'urgence détaillé et complet y contribue.

4. Créer des politiques uniformes pour les environnements multi-cloud

Si plusieurs environnements cloud différents sont touchés par une panne, la complexité des processus de restauration peut augmenter - par exemple parce qu'il faut impliquer plusieurs collaborateurs qui connaissent les différents clouds. Il en résulte des coûts d'exploitation plus élevés et des temps d'arrêt plus longs. En outre, la probabilité de perte de données augmente. Les environnements multi-cloud doivent donc être gérés de manière centralisée. Les solutions de sauvegarde en nuage basées sur des snapshots, spécialement conçues pour les charges de travail dynamiques multi-cloud, peuvent y contribuer. Avec une solution Snapshot adaptée, les entreprises peuvent appliquer des politiques uniformes pour une sauvegarde transparente de différents clouds.

5. Mettre régulièrement les processus au banc d'essai

C'est justement cette étape qui est souvent négligée dans la pratique. Les entreprises doivent tester régulièrement si le processus de reprise après sinistre établi fonctionne et combien de temps il prend. Les phases de test se déroulent en arrière-plan et ne perturbent pas les opérations en cours. La Veritas Resiliency Platform, par exemple, permet au client de configurer l'ensemble du processus de Disaster Recovery par simple glisser-déposer. Des analyses en temps réel peuvent être consultées via un tableau de bord intégré. Les entreprises peuvent ainsi contrôler si les objectifs temporels sont respectés. En un clic de souris, elles obtiennent des valeurs fiables sur la durée totale du processus de basculement et sur la quantité de données productives perdues. Les responsables informatiques peuvent ainsi décrire les situations d'urgence avec des valeurs déterminées dans des conditions réelles et les situations de crise deviennent prévisibles.

Auteur :
Sascha Oehl est directeur des ventes techniques DACH chez Veritas