Duquesne Group Duquesne Group

English version
Recherche et Analyse

Pour éclairer les décideurs dans le domaine de la Continuité d'Activité et de la Sécurité de l'Information, Duquesne Group propose ses analyses et réflexions issues de ses réalisations concrètes en clientèle. Observation critique du terrain par nos experts, contacts permanents avec les principaux acteurs du domaine et expérience vécue dans nos missions de conseil sont nos principales sources. Contactez-nous pour en savoir +
French version
Research

To support decision makers in the management and optimisation of information systems, Duquesne Group delivers in-depth analyses of information technologies, their implementations and their markets. Our research is based on critical observation of the market by our analysts and their on-going contacts with the vendor community, together with hands-on, practical experience from our consulting work. Contact us to find out more


SaaS et Plan de continuité : comment y voir clair ?


La question vient souvent : le fait d'utiliser des services en cloud améliore-t-il ou détériore-t-il la capacité de l'entreprise en matière de Continuité ?

L'entreprise a de plus en plus recours à des services en mode SaaS ; la DSI est plus ou moins mise au courant. Les éventuels plans de reprise peu étudiés.

Le paysage de risque d'interruption est pourtant modifié complètement et subrepticement. Alors : est-ce mieux ou moins bien ?

Eléments de réponse.





DR
DR

Un usage de plus en plus répandu

Définissons le SaaS comme étant un mode de consommer du logiciel à l’usage, via Internet et un navigateur.

Les entreprises ont de plus en plus recours à des applications en mode SaaS et ce choix se fait un peu partout dans l’entreprise.

Il n’est pas rare de voir des situations mixtes avec une informatique interne (éventuellement d’ailleurs hébergée dehors) et des usages très nombreux d’outils en SaaS à l’initiative de services aussi divers que les ventes (ex : SalesForce), la comptabilité (ex : SAP en SaaS ou autre Cegid) ou encore l’avant-vente (ex : Jack-in-the Box en SaaS).

L’informatique interne elle-même peut quelquefois aussi recourir à de tels outils : ServiceNow pour de la gestion de tickets d’incidents ou autres outils de tests. Sans parler d’Office 365 pour tous.

Ainsi, au fil des années l’entreprise se retrouve dans une situation où son service IT interne cohabite avec une dizaine d’outils ou d’applications en SaaS. Les décisions qui ont mené à cet état de fait ne sont pas forcément traçables … mais ceci est une autre histoire.

En termes de Continuité d’activité cette répartition oblige à revoir l’approche habituelle en place.

Les PRA en place deviennent périmés !

Posons une liste de questions simples :

  • Quel pourcentage de vos applications critiques sont embarquées dans les PRA de votre entreprise ? A priori tout ce qui est en SaaS y échappe ! Or pourtant, vous avez des applications SaaS qui sont critiques.

  • Vos PRA servent-ils encore à quelque-chose si les applications qu’ils embarquent ont disparu en SaaS ou sont marginalisées ?

  • Poursuivons : quel pourcentage de vos données utiles est pris dans les sauvegardes de votre IT interne ?

  • Symétriquement : que valent les sauvegardes de vos données en SaaS et qui s’en occupe ? Savez-vous seulement s’il faut sauvegarder quelque-chose dans vos applications SaaS et quoi ?

  • Et enfin : vos PRA envisageaient la perte de votre data center et la bascule sur un secours. Que contiennent aujourd’hui vos data center qui vaille le coup d’être repris ? Probablement des données dont la confidentialité est telle qu’elles ne sont pas parties dans le SaaS ? Est-ce vraiment sûr ?

Pour le responsable de la continuité, l’inquiétude risque de croître à l’énoncé de ces simples questions.

En effet à quoi sert de dépenser de l’argent dans un PRA maison si celle-ci ne contient plus grand’chose ?

L’utilisation du SaaS oblige donc à revoir les approches PCA/PRA traditionnelles car elles sont de moins en moins pertinentes. Et ce qui serait pertinent de faire n’existe pas !

Une application en SaaS n’est pas une application traditionnelle

Autrefois vous aviez toute votre informatique concentrée sur un ou deux Data Centers et quelques salles techniques proches des bureaux ou usines. Vos applications résidaient au mieux sur deux data centers.

Avec le SaaS, la vision est différente, les architectures combinent en gros trois niveaux :

  • divers services frontaux granulaires (présentation, web, accès,…) que le prestataire multiplie partout assez proches de vous géographiquement et interchangeables voire sous-traitables

  • des applications réparties qui peuvent servir des charges informatiques ayant une logique fonctionnelle : ces applications là encore peuvent résider dans divers endroits géographiques, elles sont moins nombreuses que les premières, plus lourdes et plus sensibles avec des moniteurs de transactions par exemple, interchangeables à iso fonctionnalité et sous conditions

  • et enfin des données centralisées qui devront être accessibles de divers points du globe car elles ne sont pas aisément déplaçables et contiennent des informations uniques d’état ou de valeur de référence vous concernant. Celles-ci ne sont pas interchangeables.

Ainsi en utilisant une application SaaS on peut être amené à exploiter des moyens dans différents Data Centers (ou chez Amazon) de manière variable selon le moment de la journée ; tous vont avoir en commun l’Internet et ne seront pour vous qu’à un clic de souris de distance tout en couvrant un continent …

Une application en SaaS moderne n’est pas une application « normale » à l’ancienne mise dans un Data Center accessible via Internet, c’est une application conçue spécifiquement pour être géographiquement répartissable au mieux des demandes de charges et des performances de traitement disponibles.

En matière de risque, on le voit, cela change tout.

Un paysage de risques modifié

Pour tous les éléments cités plus haut, on voit bien que la sensibilité à la panne est très différente :

La panne de certains moyens physiques ou logiques est de relativement peu d’importance : ils sont remplacés par d’autres, via des mécanismes assez rapides, l’usager ressent tout au plus un temps de réponse plus long que d’habitude.

En revanche pour des éléments plus lourds contenant des données de référence par exemple, le problème demeure le même : il faut pouvoir repartir ailleurs en cas de panne et il faut pouvoir revenir dans le passé en cas de corruption des données. La bascule et la sauvegarde sont toujours d’actualité. RTO et RPO survivent au SaaS !

Il faut remarquer pour être rigoureux que tout cet ensemble nécessite un ou plusieurs systèmes d’orchestration qui peuvent éventuellement s’avérer être des points uniques de défaillance.

Les situations de panne sont plus nombreuses mais leurs effets beaucoup plus contrastés. Il est possible que tout marche en lecture seule et bloque en écriture. Il est possible qu'une fonction soit très ralentie pour des raisons de saturation (ex : le logon).

Autre aspect dans ce contexte : la panne de data center peut s’avérer avoir pour vous des impacts très différents selon ce que votre offreur de SaaS y utilisait au moment du sinistre. Les cas les plus difficiles étant les pannes de data centers contenant vos données (exemple de SalesForce le 12 mai 2016 sur son centre de Washington). Vous pouvez vous logger, lancer une application mais si vous saisissez une donnée nouvelle vous êtes en attente pour longtemps, car elle ne peut pas aller s’écrire.

On le voit sur ces exemples, si vous avez cinq applications en SaaS vous accédez peut-être à dix Data Centers et quinze serveurs répartis sur un ou deux continents. Tout cela multiplie les pannes élémentaires mais rend très difficile une panne totale de toutes vos applications. (en mettant à part la panne de l'accès Internet que vous avez pris soin de rendre résilient).

Est-ce à dire que tout va bien et que tout PRA devient illusoire ?

Il faut un PRA par application en SaaS

Chaque logiciel en SaaS emploie, comme on l'a vu, des données qui ne peuvent être que centralisées à l'instant t. La pratique du "multi-tenant" (plusieurs sociétés dans la même application) ne fait qu'amplifier ce point marquant.

Lorsque cette base est sur du matériel en panne ou est corrompue, il faut recourir à un PRA traditionnel avec les deux mécanismes classiques que sont la copie (synchrone ou pas) et la sauvegarde. Seul votre fournisseur de SaaS peut s'en occuper.

La récente panne chez SalesForce donne des indications de ce qui existe en matière de PRA en SaaS :

  • suite à une panne électrique et à un plantage de machine, il est possible de basculer la charge vers d'autres éléments techniques accédant à des copies miroirs des données

  • en cas de copies miroirs problématiques (en performance ou corrompues) il est possible de redémarrer à distance sur des copies assez récentes transmises fraîchement.

  • en cas de corruption de ces données, il est possible de redémarrer sur un point de synchronisation passé assez proche.

  • ensuite, une application des "redo logs" permet de se rapprocher du temps de la panne et de réduire la perte de données, même si cela consomme beaucoup de puissance et ne peut se faire qu'au ralenti.

Toutes ces actions - de type PRA- permettent in fine un quasi retour à la normale en une dizaine d'heures pour un incident complexe. Encore faut-il que tout cela ait été prévu, soit connu des opérateurs et décidé assez vite.

Cet exemple montre qu'un opérateur SaaS est confronté à des difficultés de tout genre, comme tout exploitant. Il doit prévoir sa reprise dans diverses situations. Il doit avoir ses PRA.

En tant que consommateur de SaaS, vous ne pouvez rien faire. Tout au plus espérer que l'exploitant est réactif et a prévu les moyens de reprise.


Comment apprécier cette multitude de PRA ?

Le RPCA de l'entreprise utilisatrice se trouve donc confronté à une multitude de solutions en SaaS toutes plus ou moins dotées de PRA plus ou moins bien faits et gérés par des entités très différentes.

Comment peut-il en apprécier la solidité ?

Bien sûr, le risque de tout perdre n'existe quasiment plus (car tout est à priori réparti). Mais perdre une activité critique pour longtemps n'est pas admissible et demeure évidemment possible.

Il faut alors poser des questions et étudier la démarche de son fournisseur SaaS :

  • a-t-il réalisé une analyse de ses risques et traité les plus importants ?

  • fait-il attention en priorité aux fonctions et applications prioritaires pour ses clients ?

  • a-t-il prévu une stratégie de reprise pour faire face aux pannes ou incidents ?

  • existe-t-il des indicateurs de surveillance de la prestation qui vous est servie ?

  • est-il capable d'escalader vite et bien en cas de sinistre ?

  • sentez-vous une implication de son management en cas de panne ?

  • êtes-vous averti en cas de sinistre ? au bon niveau et au bon moment ?

  • fait-il des tests de ses mécanismes principaux et en parle-t-il ?

et ainsi de suite, restons-en aux principales questions.

Appréciez tous les PRA de vos fournisseurs SaaS vous amène à poser ces questions et à approfondir en cas de doute.

Bien sûr on se focalisera sur les applications les plus critiques, celles dont l'arrêt vous arrête.

Ces points, soulignons le, sont directement dérivés de la Norme ISO 22301 "système de management de la continuité d'activité" qui peut (et même doit) servir de fil rouge dans la démarche. Sinon plus personne ne pourra plus rien suivre ...


Emmanuel Besluau
Mercredi 18 Mai 2016

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Dans la même rubrique :
< >

Mercredi 5 Octobre 2016 - 17:48 Attention : un SMCA n'est pas un PCA !


Duquesne Research Newsletter