Disaster Recovery as a Service (DRaaS) : la sau­ve­garde évoluée

Les en­tre­prises déploient de plus en plus leur in­fras­truc­ture in­for­ma­tique dans des en­vi­ron­ne­ments Cloud dis­tri­bués à l’heure actuelle. C’est certes pratique, mais que faire en cas de problème ? La reprise après sinistre comme com­po­sante de la gestion de la con­ti­nuité des activités joue un rôle important dans le maintien des processus d’en­tre­prise. Le Disaster Recovery as a Service (abrégé DRaaS, Plan de Reprise d’Activité as a Service, ou PRAaaS en français) consiste à ex­ter­na­li­ser la sau­ve­garde de services critiques auprès d’un par­te­naire spé­cia­lisé.

Le Disaster Recovery as a Service (DRaaS) est un service in­for­ma­tique géré. Le DRaaS est un cas par­ti­cu­lier du Disaster Recovery, soit reprise après sinistre ou reprise après incident, reprise d’activité ou ré­cu­pé­ra­tion d’urgence en français. La tâche est confiée à un parti tiers comme une pres­ta­tion de service d’in­fo­gé­rance ainsi que l’indique l’épithète « as a Service ». Disaster Recovery as a Service est l’une des pres­ta­tions in­for­ma­tiques les plus ap­pré­ciées et à plus forte crois­sance dans le domaine du cloud computing.

La reprise après sinistre est une com­po­sante à part entière du Business Con­ti­nuity Ma­na­ge­ment (BCM) ou gestion de la con­ti­nuité des activités en français. Le BCM recouvre des plans et des pré­pa­ra­tions pour la reprise des processus d’en­tre­prise en cas de panne complète ou partielle de systèmes critiques. La tâche du PRA consiste à assurer la reprise de l’état de fonc­tion­ne­ment normal en temps et en heure. Il est basé sur un Business Con­ti­nuity Plan (BCP) ou un Plan de Con­ti­nuité d’Activité (PCA) en français, qui décrit les com­po­sants et processus du BCM. Examinons les trois com­po­sants prin­ci­paux du PCA :

Le Cloud Disaster Recovery (Cloud-DR) est de plus en plus utilisé dans le cadre de la stratégie de reprise après sinistre de nos jours. Avec la Cloud-DR, ou reprise après sinistre sur le Cloud, les données requises pour la ré­cu­pé­ra­tion de systèmes affectés sont en­re­gis­trées sur le Cloud, au lieu de faire appel à des supports physiques de mémoire de masse sur site. La Cloud Disaster Recovery offre de nombreux avantages en com­pa­rai­son avec les méthodes con­ven­tion­nelles de sau­ve­garde et est en bonne voie de s’établir comme un standard.

Un trait ca­rac­té­ris­tique de la reprise après sinistre est qu’une en­tre­prise n’en a besoin qu’en cas d’incident. Quand un incident se produit, une reprise après sinistre sans faille revêt une im­por­tance cruciale. En temps de fonc­tion­ne­ment normal, la place de la reprise après sinistre passe toutefois com­plè­te­ment au second plan. Le risque de négliger la reprise après sinistre est ainsi latent ; en fin de compte, on n’en a jamais besoin tant qu’aucune ca­tas­trophe ne se présente.

Un PRA mal planifié re­pré­sente un grand danger pour les en­tre­prises. Car la dé­fail­lance de systèmes critiques peut entraîner des coûts élevés. Selon des es­ti­ma­tions du secteur, la durée d’in­dis­po­ni­bi­lité peut coûter de 100 000 $ à 1 000 000 $ par heure. Une série de motifs peuvent conduire à des incidents qui en­traî­nent la dé­fail­lance des systèmes ou la perte de données. Examinons les scénarios les plus fréquents.

Les évé­ne­ments suivants peuvent provoquer de graves in­ter­rup­tions du fonc­tion­ne­ment de l’activité et né­ces­si­ter une reprise après sinistre :

• arrêt de courant dans les locaux de l’en­tre­prise
• pannes ma­té­rielles et de réseau
• erreurs lo­gi­cielles et de système in­for­ma­tique
• panne du centre de données propre à l’en­tre­prise
• attaques dirigées contre la sécurité in­for­ma­tique

Dif­fé­rentes causes peuvent en être à l’origine :

• erreur humaine
• agis­se­ments mal­veil­lants
• ca­tas­trophes na­tu­relles et incendie
• vol d’appareils in­for­ma­tiques et de supports de données
• matériels ou logiciels dé­fec­tueux

Tous ces cas de figure ont ceci en commun : en l’absence des pré­cau­tions adéquates, l’en­tre­prise affectée doit ra­pi­de­ment faire face à des con­sé­quences ex­trê­me­ment graves.

La règle la plus im­por­tante en relation avec la gestion de con­ti­nuité de l’activité et le plan de reprise après sinistre qu’elle contient, est l’im­pé­rieuse nécessité de leur bonne pré­pa­ra­tion au préalable. Il est gé­né­ra­le­ment déjà trop tard si l’on commence à y réfléchir seulement quand l’incident s’est déjà produit. Un exemple simple illustre ceci : vous avez stocké des photos d’une forte valeur sen­ti­men­tale sur votre or­di­na­teur portable. Le portable est volé, les photos ont disparu. Seule la création pré­ven­tive et régulière de sau­ve­gardes sur un support externe ou dans le Cloud offre une véritable pro­tec­tion.

La règle 3-2-1 est depuis longtemps la norme quand il s’agit de créer des sau­ve­gardes. Elle prévoit la con­ser­va­tion de trois versions pour toutes les données, à savoir l’original ac­com­pagné de deux copies. Il s’agit de la double re­don­dance. Une copie est conservée ici sur un support de données séparé mais dans les mêmes locaux que l’original (sau­ve­garde sur site). La seconde copie est conservée dans un site éloigné sur le plan physique (sau­ve­garde hors site).

Le Disaster Recovery as a Service s’inscrit dans une démarche de ré­pli­ca­tion continue des données et des systèmes de l’en­tre­prise. Ceci va au-delà de la simple création de sau­ve­gardes de données et recouvre l’ensemble des in­fras­truc­tures, systèmes, ap­pli­ca­tions et données critiques. L’objectif consiste à revenir aussi vite que possible à l’état initial en cas de pannes. Car les pannes sub­sis­tantes peuvent entraîner des coûts élevés.

Deux in­di­ca­teurs se sont imposés pour quan­ti­fier les approches de DRaaS. Le « Recovery Time Objective » (RTO, objectif de temps de reprise en français) et le « Recovery Point Objective » (RPO, objectif de point de reprise en français) sont définis selon les exigences de l’en­tre­prise spé­ci­fique. Des mesures adéquates sont alors mises en œuvre :

Des « sites de bas­cu­le­ment » sont utilisés afin de maintenir l’objectif de temps de reprise le plus bas possible. Il s’agit ici de mises en miroir complètes de systèmes critiques pouvant in­ter­ve­nir en cas de panne des sites originaux. La con­ti­nuité de l’activité de l'en­tre­prise est assurée jusqu’au ré­ta­blis­se­ment des propres capacités de l’en­tre­prise.

De nombreux four­nis­seurs proposent aujourd’hui le Disaster Recovery as a Service dans le cadre de leurs pres­ta­tions. Quel que soit le four­nis­seur de DRaaS vers lequel on se tourne, les offres sont réparties dans trois grandes ca­té­go­ries. Les offres de DRaaS se dis­tin­guent es­sen­tiel­le­ment selon le degré de liaison du client au four­nis­seur :

Toutes les offres de DRaaS ont ce dé­no­mi­na­teur commun : le four­nis­seur met à dis­po­si­tion des outils spé­ci­fiques de reprise après sinistre. Ceux-ci visent à mettre en miroir des en­vi­ron­ne­ments TI avec la totalité de leurs com­po­sants. La portée de la re­don­dance s’étend des données et ap­pli­ca­tions aux réseaux et systèmes complets. Le serveur et les terminaux sont sau­ve­gar­dés au-delà des limites du système d’ex­ploi­ta­tion en re­cou­vrant les fichiers, bases de données, machines vir­tuelles et con­te­neurs. Une fois mis en miroir, les com­po­sants sont mis à dis­po­si­tion en cas d’incident et viennent remplacer les systèmes dé­fail­lants.

Plusieurs cibles sont gé­né­ra­le­ment employées pour la sau­ve­garde des données. Au moins l’une des sau­ve­gardes est créée à un em­pla­ce­ment éloigné sur le plan géo­gra­phique con­for­mé­ment à la règle 3-2-1. Suivant la con­fi­gu­ra­tion du modèle DRaaS mis en œuvre, la cible de sau­ve­garde éloignée cor­res­pond au centre de données local ou à un support de stockage dans le Cloud. À ceci s’ajoute la pos­si­bi­lité de mettre en œuvre des approches hybrides. De manière analogue à la sau­ve­garde, la res­tau­ra­tion des données fonc­tionne selon la mé­tho­do­lo­gie de stockage faisant appel à des supports physiques, vir­tua­li­sés ou dans le Cloud. Les données trans­fé­rées par le réseau sont chiffrées pour le transport.

Outre la res­tau­ra­tion des données et systèmes affectés, les offres pro­fes­sion­nelles de DRAaaS com­por­tent souvent une autre fonction es­sen­tielle au maintien de l’activité de l’en­tre­prise. Un système de rem­pla­ce­ment est activé lors de la panne d’un système avec les « Failover En­vi­ron­ments » (en français, « en­vi­ron­ne­ments de bas­cu­le­ment ») sur le Cloud. Les uti­li­sa­teurs peuvent ainsi pour­suivre leur travail malgré de brèves in­ter­rup­tions.

La sur­veil­lance des systèmes sous pro­tec­tion et le pilotage des sau­ve­gardes et des en­vi­ron­ne­ments de bas­cu­le­ment sont assurés par le biais de consoles de gestion déployées dans la plupart des offres de DRaaS. Il s’agit gé­né­ra­le­ment d’ap­pli­ca­tions basées sur le Web qui sont utilisées à travers un na­vi­ga­teur. Même en cas de panne, on peut ainsi accéder à la console, qui fonc­tionne également sur des appareils mobiles. Certaines offres de DRaaS englobent plus avant une fonction de réseau privé virtuel RPV pour accéder aux données sé­cu­ri­sées et en­vi­ron­ne­ments de bas­cu­le­ment.

Depuis le dé­ve­lop­pe­ment de la tech­no­lo­gie de réseau et du rac­cor­de­ment de serveurs aux réseaux publics comme l’Internet, l’in­fras­truc­ture in­for­ma­tique des en­tre­prises subit des attaques. Tra­di­tion­nel­le­ment, les ad­mi­nis­tra­teurs et tech­ni­ciens assurent la pro­tec­tion des systèmes contre les accès non autorisés et les attaques par déni de service. Mais un autre mode d’attaque par­ti­cu­liè­re­ment in­quié­tant est apparu au cours des dernières années : les cy­ber­cri­mi­nels infectent un dis­po­si­tif par le tru­che­ment d’un « ran­çon­gi­ciel », un type de maliciel également désigné sous le terme de « crypto-cheval de Troie ». Ce logiciel mal­veil­lant s’infiltre sur l’appareil et chiffre les données qui s’y trouvent. Une fois chiffrées, les uti­li­sa­teurs en droit se re­trou­vent dans l’im­pos­si­bi­lité d’accéder aux données et se voient intimer le paiement d’une rançon.

Les crypto-chevaux de Troie re­pré­sen­tent une réelle menace à l’heure actuelle. Même des sau­ve­gardes con­ven­tion­nelles n’offrent aucune pro­tec­tion, car celles-ci sont chiffrées en parallèle dans le pire des cas et de­vien­nent ainsi inu­ti­li­sables.

En réaction à cette nouvelle menace, la pro­tec­tion anti-ran­çon­gi­ciel s’est établie comme un axe majeur des solutions de DRAaaS. Une autre copie de toutes les données sau­ve­gar­dées est utilisée ici. Elle est es­tam­pil­lée « immutable » (« inal­té­rable » en français). Une fois écrites, les données peuvent être lues et relues mais jamais modifiées. On évoque ici aussi la notion de « Write Once, Read Many » ou le modèle WORM.

Il existait déjà des solutions de Backup-as-a-Service (BaaS, « sau­ve­garde en tant que service » en français) avant l’avènement de la reprise après sinistre en tant que service. Il faut toutefois constater que la seule sau­ve­garde des données ne suffit plus de nos jours. Il est né­ces­saire de mettre en miroir les données et systèmes de manière per­ma­nente, afin que ceux-ci soient im­mé­dia­te­ment prêts à l’emploi si l’activité de l’en­tre­prise venait à s’in­ter­rompre. La DRaaS présente des avantages et des in­con­vé­nients comme tous les progrès tech­no­lo­giques. Nous les con­si­dé­rons sous la pers­pec­tive par­ti­cu­lière des solutions de sau­ve­garde con­ven­tion­nelles. Examinons dans un premier temps les avantages de la reprise après sinistre en tant que service.

Le Disaster Recovery as a Service s’inscrit dans une approche cen­tra­li­sée. L’ensemble des données et systèmes est sau­ve­gardé en continu. Ce phénomène est connu : il s’agit en majorité des données d’une en­tre­prise lé­gè­re­ment tombées dans l’oubli ou « Dark Data ». Sau­ve­gar­der toutes les données avec des méthodes co­hé­rentes mi­ni­ma­lise le risque d’oublier des données lors de la sau­ve­garde ou de la res­tau­ra­tion et d’en perdre en cas d’incident. Comme il est d’usage de conserver plusieurs versions des données sau­ve­gar­dées, le DRaaS constitue aussi une étape im­por­tante en direction de la con­for­mité à l’archivage sécurisé à valeur probante.

La règle 3-2-1 stipule qu’au moins trois copies de chaque donnée doivent être con­ser­vées, dont une comme une sau­ve­garde hors site. L’uti­li­sa­tion du DRaaS avec le Cloud comme cible des sau­ve­gardes hors site permet d’atteindre un bref objectif de point de reprise (RPO). À titre de rappel, le RPO définit la période qui s’étale entre deux sau­ve­gardes des mêmes données. L’uti­li­sa­tion de systèmes de bas­cu­le­ment hébergés dans le Cloud dans le cadre du DRAaaS se traduit par des économies con­sé­quentes. Car pour disposer d’une capacité com­pa­rable, il convient de maintenir des res­sources ma­té­rielles tra­di­tion­nel­le­ment re­don­dantes en re­pla­ce­ment face à une ca­tas­trophe.

Con­trai­re­ment à la sau­ve­garde en tant que service, la reprise après sinistre en tant que service n’englobe pas seulement la sau­ve­garde des données, mais la mise en miroir de systèmes complets. Elle recouvre également la sau­ve­garde de machines vir­tuelles et de con­te­neurs d’ap­pli­ca­tion, qui cons­ti­tuent les com­po­sants de base des ar­chi­tec­tures TI modernes. Le système complet est re­cons­ti­tué à partir de ces dif­fé­rents éléments lors de la res­tau­ra­tion. Afin de résoudre cor­rec­te­ment les in­ter­dé­pen­dances des dif­fé­rents com­po­sants entre eux, les solutions de DRaaS per­met­tent de définir la séquence des dif­fé­rentes étapes de res­tau­ra­tion. Ceci est d’une im­por­tance cruciale dans le domaine de l’ar­chi­tec­ture de mi­cro­ser­vices très répandue.

Examinons main­te­nant les in­con­vé­nients de la reprise après sinistre en tant que service. Nous cons­ta­tons tout d’abord que l’uti­li­sa­tion du DRaaS entraîne gé­né­ra­le­ment des coûts plus élevés que l’uti­li­sa­tion de la sau­ve­garde en tant que service. En con­tre­par­tie, les solutions de DRaaS offrent beaucoup plus de pres­ta­tions, ce qui dis­cré­dite le com­pa­ra­tif direct des prix ainsi bancal. Comme dans toutes les pres­ta­tions du type « as-a-Service », la menace de l’en­fer­me­ment pro­prié­taire plane aussi sur le DRaaS. Pour cette raison : le contrôle est placé entre les mains d’un seul four­nis­seur duquel on se met en situation de dé­pen­dance. De même, il convient de men­tion­ner la perte de sou­ve­rai­neté des données comme un in­con­vé­nient potentiel des solutions de DRaaS. Ce faisant, l’im­plan­ta­tion du siège de la société pres­ta­taire du DRaaS joue un rôle dé­ter­mi­nant.

Le Disaster Recovery as a Service est dis­po­nible auprès de nombreux four­nis­seurs de services sur le Cloud. Des four­nis­seurs bien connus se sont spé­cia­li­sés dans les solutions de reprise après sinistre et de sau­ve­garde. La sau­ve­garde en tant que service est tra­di­tion­nel­le­ment aussi proposée par les four­nis­seurs de services managés, ou mise en œuvre par des en­tre­prises du service du numérique dans des cas spéciaux.

La feuille de route suivante s’impose dès lors qu’on souhaite iden­ti­fier le four­nis­seur DRaaS adéquat :

1. Il convient de dresser un état des lieux dans un premier temps : on établit un relevé de la situation réelle et on mesure la portée des données et systèmes à sau­ve­gar­der.
2. L’étape suivante consiste à spécifier les besoins et les objectifs, où l’objectif de temps de reprise (RTO) et l’objectif de point de reprise (RPO) tiennent une place im­por­tante con­cer­nant les données, ap­pli­ca­tions et services impliqués.
3. Une fois les con­nais­sances con­cer­nant la con­fi­gu­ra­tion de son in­fras­truc­ture réunies et les besoins et objectifs cernés, on peut se tourner vers le choix des four­nis­seurs candidats. Outre les capacités tech­niques, la con­for­mité des four­nis­seurs avec les spé­ci­fi­ca­tions établies ainsi qu’une grille tarifaire équitable et trans­pa­rente sont des aspects pri­mor­diaux.
4. Il s’agit main­te­nant de sé­lec­tion­ner le four­nis­seur adapté parmi les candidats iden­ti­fiés. Des tests doivent être conduits au plus tard à ce stade afin de mettre les capacités tech­niques du four­nis­seur au banc d’essai.

Observons les points clés sur lesquels un four­nis­seur DRaaS pro­fes­sion­nel doit pouvoir donner sa­tis­fac­tion.

La sau­ve­garde au­to­ma­tique et continue des données et systèmes critiques est fon­da­men­tale pour une solution de DRAaaS. La sau­ve­garde devrait fonc­tion­ner au-delà des limites du système d’ex­ploi­ta­tion et englober tous les types de données im­por­tants. Ceci recouvre les fichiers, bases de données, en­vi­ron­ne­ments de serveur et appareils d’uti­li­sa­teur final, ainsi que les en­vi­ron­ne­ments vir­tua­li­sés dans des machines et con­te­neurs virtuels. Quand la pro­tec­tion des données en continu (Con­ti­nuous Data Pro­tec­tion, CDP) est mise en œuvre, l’état d’un centre de données complet est sau­ve­gardé selon une gra­nu­la­rité à la seconde près.

Les données doivent être au­to­ma­ti­que­ment chiffrées lors de l’en­re­gis­tre­ment des données saisies avant le transfert vers le four­nis­seur DRaaS. Les données et systèmes de sau­ve­garde doivent être soumis à une procédure au­to­ma­ti­sée per­ma­nente de vé­ri­fi­ca­tion des erreurs et des di­ver­gences. Il convient d’utiliser des systèmes re­don­dants et géo­gra­phi­que­ment répartis à l’échelle du globe pour stocker les données.

En cas d’incident, le four­nis­seur DRaaS doit pouvoir assurer au moins deux pres­ta­tions : il s’agit d’une part de restaurer les systèmes affectés. La res­tau­ra­tion doit porter sur toutes les données, ap­pli­ca­tions et systèmes es­sen­tiels. Lors du choix du four­nis­seur, n’oubliez pas qu’une res­tau­ra­tion dans des en­vi­ron­ne­ments mul­ti­cloud peut être né­ces­saire. D’autre part, le four­nis­seur DRaaS devrait in­ter­po­ser et activer des systèmes de bas­cu­le­ment au cours de la res­tau­ra­tion, afin de permettre le dé­rou­le­ment de l’activité avec un minimum d’in­ter­rup­tions du point de vue de l’uti­li­sa­teur.

Au-delà de ces attentes de base, il convient de se tourner vers un four­nis­seur DRaaS dont l’offre s’étend à des anti-ran­çon­gi­ciels au vu des menaces actuelles. Les clients pré­sen­tant des attentes exor­bi­tantes en termes de volumes de données à stocker devraient pri­vi­lé­gier de tels four­nis­seurs dans leur choix. Le transfert d’énormes volumes de données peut durer plusieurs années via Internet dans des cas extrêmes. Ce délai est bien trop long pour une res­tau­ra­tion efficace. Il est fait appel à des supports de données mobiles spé­ci­fiques, à l’image du célèbre « Amazon Snow­mo­bile » dans un tel cas :