Le secours informatique SaaS, une responsabilité du fournisseur à formaliser

Un service SaaS (Software as a Service) est un logiciel mis à disposition et directement consommable depuis Internet. Il est géré et administré par un ou plusieurs fournisseurs.  Le client n’a donc pas la latitude nécessaire pour opérer le secours (pas d’accès aux données brutes, pas d’accès aux codes sources, ni aux applicatifs pour dupliquer l’infrastructure…), il doit donc s’en remettre au bon vouloir de son fournisseur.

Un niveau de couverture du secours informatique pour SaaS variable suivant la maturité du fournisseur

Trois grandes tendances se dessinent :

• Les fournisseurs qui disposent d’un plan de secours informatique inclus
  Dans le cadre de l’offre standard, le fournisseur assure un secours sur un datacenter distant, complété généralement par des sauvegardes externalisées. Il ne s’engage néanmoins que rarement sur les délais de reprise.
  Ex : les grands acteurs du SaaS (ex : Office 365, SalesForce, SAP…) , ainsi que certains acteurs de taille intermédiaire (ex : Evernote, Xero…) ;

• Les fournisseurs qui disposent simplement d’une sauvegarde externalisée
  En tant que tel, aucun plan de secours informatique n’est clairement établi. Le client doit alors s’interroger sur la capacité du fournisseur à restaurer les sauvegardes en cas de sinistre global sur le site principal.
  Ex : Des fournisseurs de taille intermédiaire (ex : Zervant, Sellsy…) ;

• Les fournisseurs qui ne communiquent pas ou n’en disposent pas
  Le sujet du secours informatique n’est pas abordé, il est donc préférable de considérer que rien n’est fait.
  Ex : Les acteurs de petite taille sont généralement dans ce cas.

L’importance de l’aspect contractuel

Dans la très grande majorité des cas, les fournisseurs SaaS ne s’engagent pas dans leur contrat sur leur façon de gérer le secours ; même lorsque ceux-ci mettent en avant leur capacité à traiter cette problématique. En effet, les contrats comportent généralement par défaut des clauses de Force Majeure stipulant que le fournisseur n’est pas responsable de manquement aux obligations du contrat dans la mesure où ce manquement est causé par un évènement en dehors de leur contrôle raisonnable. Le risque juridique doit donc être traité lors de la souscription et ces clauses supprimées pour s’assurer un bon niveau de couverture.

Lors de la souscription, comme pour des contrats classiques, les clients doivent s’assurer que figure bien des engagements de service, en particulier pour les secours informatiques :

• Le délai de reprise (Durée Maximale d’Interruption Acceptable ou DMIA) et les pertes de données (Perte de Données Maximale Acceptable ou PDMA) en cas de sinistre;
• Le plan de secours informatique du fournisseur incluant les modalités de gestion de crise ainsi que l’obligation de conduire plusieurs tests probants par an de ce plan avec la possibilité pour le client d’accès au rapport des tests ;
• Les pénalités financières et le droit de résilier le contrat (avec en particulier la récupération des données exploitables) en cas de manquement aux engagements.

Le secours informatique du IaaS/PaaS, une mise en oeuvre et une responsabilité du client

Le IaaS (Infrastructure as a Service) est une offre standardisée et automatisée de ressources de calcul, de moyens de stockage et de ressources réseau détenus et hébergés par un fournisseur et mis à disposition au client à la demande. L’offre PaaS (Platform as a Service) est similaire à celle du IaaS, à la différence près qu’elle ne concerne que les infrastructures applicative (définitions Gartner) Contrairement au cas du SaaS, le secours reste sous la responsabilité du client dans les deux cas : les fournisseurs IaaS/PaaS mettent à disposition des ressources dans différents datacenters et le client est responsable de l’usage et de la configuration qu’il en fait. Deux solutions s’offrent aux clients utilisant ces services : confier à un prestataire son secours ou bien le gérer lui-même.

Avoir recours à un prestataire de secours, un marché peu mature

Les prestataires de secours dans le Cloud sont désignés par l’acronyme « DRaaS » pour Disaster Recovery as a Service. Initialement, les fournisseurs DRaaS proposaient d’assurer dans le Cloud le secours de votre SI « on-premise ». Mais ils proposent également aujourd’hui d’assurer le secours de vos infrastructures déjà dans le Cloud, AWS ou Azure par exemple. La maturité reste très variable selon les fournisseurs et le cloud utilisé. Certains fournisseurs DRaaS imposent que le Cloud de destination du secours soit le leur, ne permettant pas ainsi de couvrir le secours de service PaaS.

Comme avec le SaaS, pas de garanties incluses par défaut quant aux pertes de données ou au délai de reprise, il faut les négocier. Les fournisseurs promettent de pouvoir s’adapter aux exigences du client ! Pour s’assurer que le secours fonctionne, le client doit prévoir la réalisation régulière de tests probants du secours (recommandation d’une fois par an).

Réaliser soi-même son secours en utilisant les outils proposés par le fournisseur

Comme sur une infrastructure « on-premise », il est nécessaire de réfléchir et définir sa stratégie de secours dès la conception. Cette stratégie doit intégrer la capacité de réaliser des tests probants permettant d’assurer un niveau de confiance suffisant dans son plan.

La mise en place est simplifiée par les outils mis à disposition par les fournisseurs Cloud et la forte standardisation des environnements Cloud. Les grands acteurs publient dans des livres blancs les grandes lignes directrices pour mettre en place un tel projet (par exemple AWS ou Azure).

Les concepts des stratégies du secours informatique restent proches de celles pour les datacenters on-premise.

On peut en dénombrer quatre principales :

• la sauvegarde et restauration: simple sauvegarde des données et images des machines sur un site distant, restaurées en cas de sinistre ;
• la veilleuse: réplication des bases de données et mise à disposition des machines sous forme d’images prêtes à être démarrées en cas de sinistre ;
• le secours à chaud: réplication complète du site primaire (données et machines), le site de secours est sous-dimensionné en termes de performances et est prêt à monter en charge en cas sinistre ;
• le multi site (ou actif-actif): les deux sites sont identiques et se partagent la charge des utilisateurs. En cas de sinistre, le site restant peut monter en charge pour accueillir la totalité des utilisateurs.

Des solutions hybrides pouvant mieux s’adapter aux exigences de délai de reprise, coût et complexité de la solution peuvent être envisagées.

Le véritable apport du Cloud pour le secours concerne les nombreux outils mis à disposition simplifiant la mise en œuvre et le déclenchement.

La réplication des données est ainsi simplifiée pour les options de géo-réplication asynchrones (plusieurs copies répliquées dans d’autres régions). La PDMA est variable en fonction des types de données et des outils proposés. Au-delà de cette option, une redondance locale des données est presque systématiquement incluse.

La forte standardisation permet également d’automatiser la reprise : les scripts ou API mis à disposition par les fournisseurs permettent d’automatiser le déploiement des infrastructures, le redimensionnement des instances en fonction de métriques précédemment définies, la répartition des charges et du trafic ou, l’adressage IP etc… afin d’accélérer de façon significative l’activation d’un site de secours.

Les outils de surveillance et alerte qui sont également proposés visent à faciliter le Maintien en Conditions Opérationnelles (MCO) du secours et peuvent être utilisés pour détecter au plus tôt un incident voire, dans certains cas, automatiser partiellement le déclenchement du secours.

Enfin la capacité à provisionner des nouvelles ressources en quelques minutes permet de limiter l’OPEX. A stratégie équivalente, il est ainsi possible d’avoir des gains de 40 à 70% sur le coût du secours !

Vers une plus grande prise en charge par le fournisseur ?

Azure prévoit une option, courant 2017, pour assurer le secours des machines virtuelles hébergées au sein de leur plateforme via la complétion de leur service « Site Recovery ». En effet, « Site Recovery » propose à l’heure actuelle de prendre en charge le secours de site traditionnel en utilisant le cloud Azure pour accueillir le site secondaire, mais Microsoft souhaite étendre ce service au secours de leurs propres infrastructures. Cet outil permettrait un déploiement automatique du site secondaire (de type actif-passif), une réplication automatique des données et une mise en place de tests facilitée.

Cette option est passée en « public preview » fin mai 2017. Un projet équivalent n’est pas d’actualité chez les autres principaux fournisseurs IaaS/PaaS.

Le cloud face au risque systémique des fournisseurs

Le secours informatique des services hébergés dans le cloud s’aborde différemment selon le type de service utilisé. Le secours du SaaS doit être géré contractuellement et est sous la responsabilité du fournisseur tandis que le secours du IaaS/PaaS, simplifié par les outils, reste sous la responsabilité du client.

Le risque de défaillance généralisé d’une région d’hébergement d’un fournisseur existe comme le montre les derniers incidents. Même si aujourd’hui, les incidents ont été de courte durée ou avec des impacts fiables, une défaillance généralisée ne peut pas être ignorée. Reste donc à traiter la problématique de cyber-résilience. L’utilisation d’un 2^ème fournisseur cloud permet de couvrir le risque de destruction ou d’indisponibilité majeure des infrastructures du premier. Cette solution reste très complexe car la portabilité d’un fournisseur à un autre est délicate. Pour l’instant, peu d’entreprises s’y sont risquées, même si l’on peut citer l’exemple de Snapchat qui utilise le cloud Google pour sa production et prévoit d’utiliser celui d’Amazon pour son secours d’ici à 5 ans.

Cet article Le Cloud, la fin ou renouveau du secours informatique ? est apparu en premier sur RiskInsight.

La mise en place d’un Plan de Continuité Informatique est souvent vue comme un poste de coût supplémentaire, une forme d’assurance pour couvrir des évènements rares. Dès lors, le bon sens conduit souvent à vouloir en réduire les coûts et donc à favoriser le secours sur des serveurs existants « hors production »  (développement, recette, qualification, intégration, test, formation, pré-production) et notamment ceux de pré-production (plus proches de l’environnement réel).

Mettre ainsi à profit des ressources qu’on ne juge pas essentielles en cas de crise semble permettre d’optimiser leur usage – et au final les coûts du PCI. Cette assertion mérite cependant d’être confrontée au contexte de chaque organisation. Un tel secours est-il vraiment une source d’économie ? Réellement plus simple à mettre en œuvre ? Éligible pour toutes les applications ?

Prendre en compte les contraintes applicatives pour évaluer la complexité de mise en œuvre

Les environnements « hors-production » peuvent présenter des enjeux aussi forts pour les Métiers que leur environnement de production, notamment lorsque :

• les applications doivent évoluer rapidement ou régulièrement,
• les incidents applicatifs nécessitant correctifs sont fréquents.

Ces besoins métiers entrent ainsi en concurrence avec ceux liés à la mise en place du secours (construction du PCI, recette, tests, etc.). Si le métier est en charge de définir les priorités d’utilisation de ces environnements, il y a fort à parier que le planning de mise en œuvre du PCI devra être défini en fonction des plages d’usage laissées vacantes par les autres besoins.

Autant dire que pour les applications évoluant souvent ou victimes d’incidents à répétition, le projet de secours sera complexifié ; les phases de construction et de test du secours ne pouvant être déroulées, le métier exigeant la disponibilité de ces ressources pour d’autres besoins plus prioritaires à ses yeux. Contrainte d’autant plus forte dans un contexte au sein duquel la mise en production (MEP) ne serait pas complètement industrialisée.

Dès lors, la mise en œuvre d’un secours sur pré-production ne peut être envisagée sereinement que pour des organisations au sein desquelles la DSI priorise seule l’accès et l’utilisation des ressources hors-production. Il conviendra alors de privilégier les applications les mieux maîtrisées et les plus stables, afin de réduire au maximum les conflits avec les chantiers d’évolution applicative ou de correction de problèmes.

Ne pas conclure trop vite à une économie substantielle en évaluant les coûts cachés

Si le secours sur pré-production est considéré comme moins coûteux, c’est qu’il réduit le volume des investissements et la mise en œuvre de serveurs. Mais cette vision apparaît réductrice dès qu’on identifie les autres coûts à prendre en considération.

En effet, la majeure partie des coûts d’un projet de secours informatique réside souvent dans le pilotage, les études, les travaux d’infrastructures et le secours des données. Au final, les serveurs ne représentent parfois que 10 à 20% de l’investissement total. L’économie réalisée n’est donc pas nécessairement conséquente.

Par ailleurs, le secours sur pré-production peut également impliquer des coûts spécifiques. Bien souvent il s’agira de déménager les serveurs de pré-production, en général situés à proximité de ceux de production, et de les mettre à niveau en termes de configuration avec ces derniers. Il s’agira également d’études techniques complémentaires (ex : comment faire cohabiter des environnements de pré-production et de secours sur un même serveur?) pouvant nécessiter des enveloppes de charges supplémentaires. Enfin, en cas de coordination avec les métiers pour prise en compte de leurs contraintes (application en cours d’évolution, correction de bugs récurrents, …), des charges de gestion de projet complémentaires sont à prévoir.

Autant de points pouvant rendre le secours sur pré-production aussi voire plus onéreux qu’une solution dédiée de secours. Il convient donc de bien évaluer son coût en fonction de ces différents paramètres et de le comparer aux coûts des autres solutions envisagées.

Ne pas réduire le secours sur pré-production à sa composante économique

« La solution du bon sens est la dernière à laquelle songent les spécialistes » citait l’éditeur Bernard Grasset.

Nous l’avons vu, et contrairement à ce que le bon sens nous le laissait imaginer, le secours sur pré-production n’est pas une garantie d’économie.

Cette solution est à privilégier dans des contextes matures (maîtrise forte du processus de mise en production et des environnements hors production par la DSI), pour des applications stables (n’évoluant pas ou peu) et des environnements techniques adaptés.

Autant d’éléments à prendre en compte avant d’acter ou non la mise en œuvre de cette solution, notamment à l’aide de projets de virtualisation des environnements…

Cet article La pré-production constitue-t-elle la meilleure solution de continuité informatique ? est apparu en premier sur RiskInsight.