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.

Des sinistres de cette ampleur ont permis d’alerter les DSI sur leur exposition face aux risques naturels. La régularité et la violence de ces évènements climatiques ont poussé les entreprises à prendre des mesures pour faire face à de futures tempêtes de la dimension de «Sandy». Les leçons du passé ont-elles pour autant été retenues ? Ont-elles toutes réussi ce test grandeur nature ? si oui, comment y sont- elles parvenues ?

Les conséquences de l’ouragan « Sandy »

Annoncé comme une catastrophe majeure dans l’histoire des États-Unis, l’ouragan « Sandy » a capté l’attention de la plupart des DSI des acteurs économiques de la côte Est qui ont mobilisé leurs efforts pour déclencher leurs plans de continuité informatique. Ces PCI, mis à niveau depuis les attentats du 11 Septembre 2001, sont fondés notamment sur des procédés de géo-réplication.

Les acteurs du web et plus largement du marché du cloud sont plus enclins à communiquer sur leur capacité de reprise et à faire des retours sur les incidents subis que les entreprises traditionnelles. Les informations disponibles proviennent donc essentiellement de ces acteurs.

De nombreuses pannes d’électricité causées par la tempête, ont entraîné une indisponibilité partielle ou totale de services (Huffington Post, Gawker, Cafemon, Gizmodo, Buzzfeed, etc.) dans bon nombre de datacenters. Les hébergeurs et fournisseurs de services cloud Datagram et 75 Broad ont été indisponibles à causes d’inondations ou réserves insuffisantes de carburant pour le fonctionnement des groupes électrogènes.

« Sandy » a ainsi rendu apparente la vulnérabilité des nombreux datacenters présents dans cette zone (New York, New Jersey, et Virginie) des États-Unis. En effet, plusieurs centres de données géo-répliqués n’étaient distants que d’une centaine de kilomètres (150 datacenters) et donc dans le rayon d’impact de Sandy.

Ces dysfonctionnements mettent en exergue la nécessité, même pour des PCI bien pensés comme ceux de Wall Street, d’être mis à l’épreuve dans des conditions proches de la réalité, avant d’être jugés comme fiables.

 Des PCI à l’épreuve des ouragans

Certains opérateurs de datacenter, comme Telx, ont résisté à Sandy car ils avaient appliqué précédemment des tests simulant jusqu’au bout un sinistre. Par cette initiative, Telx a pu identifier certaines insuffisances dans son PCI comme la surchauffe de ses générateurs en mode dégradé et a donc pu limiter l’impact de Sandy.

Un cas d’école est celui de Buzzfeed qui, malgré le crash de Datagram qui hébergeait ses serveurs primaires, a réussi à réduire considérablement le temps d’indisponibilité de ses services. Cette réussite s’explique par :

• la mise en cache de la plupart de ses pages chez Akamai, le gestionnaire et diffuseur de contenu
• l’hébergement dans un second datacenter des données répliquées en temps réel.

La réplication de ces données a permis le rétablissement des services de Buzzfeed chez Amazon Web services (AWS). Quelques heures ont suffi pour assurer la migration complète des données vers AWS et ainsi basculer leur service sur les infrastructures d’Amazon. Cet exploit est à relativiser car il a nécessité la configuration manuelle d’une bonne partie du socle technique de Buzzfeed et reste donc peu applicable en l’état à un SI complexe.

Les leçons de « Sandy »

Chaque incident majeur est une façon pour les Grands Comptes d’apprendre par le réel et d’anticiper les futures catastrophes. Au-delà d’une stratégie multi-datacenters, Sandy a  mis en exergue la nécessité d’anticiper, de tester et d’adapter le PCI.

Elle a aussi révélé le cloud comme une alternative envisageable pour réaliser un PCI. Alternative que les offreurs cloud commencent à mettre en avant par le biais de leurs offres packagées de Disaster Recovery As A Service.

Les entreprises européennes et notamment françaises, qui ont moins l’occasion de mettre à l’épreuve de la réalité leur PCI, devraient néanmoins s’inspirer des retours d’expériences plus nombreux acquis par les américains. D’autant plus que les hébergeurs de cloud ne rechignent pas à communiquer sur leur stratégie PCI gagnante afin d’en faire un argument marketing. En effet, même si moins fréquentes, l’Europe n’est pas à l’abri de catastrophes équivalentes en termes d’impact à « Sandy ».

Cet article Les plans de continuité informatique des cloud à l’épreuve de l’ouragan Sandy est apparu en premier sur RiskInsight.

Si la continuité d’activité fait partie depuis longtemps des préoccupations de bon nombre d’entreprises, elle demeure néanmoins un sujet d’actualité pour 2011. Même sur le volet informatique, souvent le plus mûr, des évolutions sont à prévoir. Quasiment tous les grands comptes disposent aujourd’hui d’un plan de continuité informatique (PCI) performant, bâti à l’initiative des DSI pour répondre à la dépendance croissante des organisations au SI. Mais cela n’est plus suffisant.

Un PCI soumis aux innovations et aux nouvelles menaces

Le PCI se doit de suivre l’évolution rapide de la production informatique, pour en profiter au mieux. Parmi les innovations marquantes figurent la virtualisation et le cloud computing. La première peut faciliter grandement les opérations de bascule et de redémarrage, parfois même « à chaud » et sans interruption de service. Le second, par la révolution qu’il impose au SI, nécessite la révision intégrale du dispositif de secours.

Au-delà, le cloud computing peut également constituer une solution de secours en soi, alternative aux sites de secours classiques. Mais comme pour la production, il induit des risques pour la sécurité des données, et est souvent encore insuffisamment rassurant quant à la capacité réelle de reprise qu’il apporte.

Parallèlement, les exigences envers les PCI évoluent : en effet, de nouvelles menaces apparaissent régulièrement et ne sont pas couvertes par les plans actuels. La plus prégnante aujourd’hui est sans doute le risque de cyber attaque, choc « extrême » à propos duquel la réflexion s’engage à peine.

Faire mûrir le volet opérationnel

La continuité d’activité ne se limite pas à celle de l’informatique : les réflexions sur la continuité des opérations progressent également. Là encore, les chocs extrêmes constituent une limite forte aux plans actuels. La plupart des organisations savent faire face à l’indisponibilité d’un bâtiment, mais restent souvent démunies face à un sinistre de plus grande ampleur, type crue de Seine. Le traitement de cette problématique sera un des enjeux des années à venir.

Les prestations de services externalisées constituent également un sujet d’attention, compte tenu de leur importance majeure pour la plupart des organisations : comment identifier les prestations réellement clés, quelles exigences fixer aux prestataires, et comment s’assurer du respect des engagements ?

Enfin, la capacité à maintenir dans le temps les plans de continuité d’activité (PCA) est une problématique majeure : adapter en permanence le plan aux évolutions rapides des organisations et du SI nécessite une méthodologie rigoureuse pour capter l’évolution des besoins et des solutions, et vérifier en permanence leur adéquation.

Le déploiement progressif d’une norme ISO sur le sujet en serait-il un levier ? Largement issue de la norme BS 25999, elle adapte la notion de système de management aux processus de continuité d’activité. Les responsables PCA devront bientôt choisir entre se contenter de suivre les bonnes pratiques, ou aller jusqu’à l’alignement voire la certification.

Ne pas oublier les fondamentaux

Bien entendu, ces sujets d’actualité ne doivent par occulter les problématiques classiques de la continuité. Du bilan d’impact sur l’activité au maintien en condition opérationnelle en passant par le choix de la stratégie, le PCA doit rester un processus vivant, sous peine de disposer d’un plan inutile le jour J. Le maintien de cet effort dans un contexte budgétaire contraint est capital. Outre qu’il permettra d’assurer la continuité de l’activité au besoin, ce souci constant offre  aux organisations l’opportunité de progresser sur un sujet de plus en plus sensible, la connaissance et la maîtrise de leurs risques. A ce titre, le PCA est bien plus qu’une simple assurance, et doit rester un sujet d’attention majeur pour les années à venir.

Cet article La continuité d’activité : de nouveaux défis pour 2011 est apparu en premier sur RiskInsight.