Le secours du SI dans le Cloud
 

Like this? Share it with your network

Share

Le secours du SI dans le Cloud

on

  • 465 views

Le Cloud Computing se développe depuis quelques mois déjà, entraînant de nombreuses adaptations au sein des entreprises. On entend par ailleurs beaucoup parler des avantages du DRaaS (plan de ...

Le Cloud Computing se développe depuis quelques mois déjà, entraînant de nombreuses adaptations au sein des entreprises. On entend par ailleurs beaucoup parler des avantages du DRaaS (plan de secours du système d'information dans le Cloud), mais qu’en est-il réellement ? Quels sont les impacts de son usage sur les organisations ? Les réponses dans ce livre blanc pour mener à bien un projet de DRaaS.

Statistics

Views

Total Views
465
Views on SlideShare
404
Embed Views
61

Actions

Likes
0
Downloads
27
Comments
0

1 Embed 61

http://www.zdnet.fr 61

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Le secours du SI dans le Cloud Document Transcript

  • 1. LIVRE BLANC Le secours du SI dans le Cloud Faut-il faire le grand saut du DRaaS ? LIVRE BLANC - LE SECOURS DU SI DANS LE CLOUD / PAR MATTHIEU BENNASAR, VINCENT D'ADAMO & LÉTITIA COMBES
  • 2. Le secours du SI dans le Cloud Faut-il faire le grand saut du DRaaS ? Par Matthieu Bennasar Vincent D’Adamo Létitia Combes
  • 3. Pour aller à l’essentiel L’IDEE EN BREF Le développement des offres de Cloud Computing et leur adoption au sein des entreprises de toutes tailles et de tous secteurs ouvre la porte à de nouvelles pratiques. L’une d’elles est le secours du système d’information dans le Cloud, appelée DRaaS pour Disaster Recovery as a Service. Les offres se multiplient et vantent les nombreux avantages qu’apportent le DRaaS concernant à la fois les aspects financiers, la simplicité de mise en œuvre, l’efficacité et la sécurité du dispositif. Mais qu’en est-il réellement ? Quels sont les impacts de l’usage du DRaaS sur les organisations ? A qui se destine le DRaaS  ? Quels sont les risques encourus  ? Et enfin, quels sont les points de passage clés à considérer avant de se lancer dans une démarche de secours du SI dans le Cloud ? Ce livre blanc s’efforce d’apporter des éléments de réponse à ces points d’interrogations et d’identifier les jalons clés permettant de mener à bien un projet de secours du SI dans le Cloud. L’IDÉE EN PRATIQUE Le DRaaS : qu’est-ce que ça CHANGE ? LE DRaaS : EST-CE POUR MOI ? Les changements apportés par le DRaaS sont d’ordre technique, organisationnel et financier : 5 critères permettent de statuer sur l’opportunité d’un secours du SI dans le Cloud : NÉCESSITE DE PERMET DE  Faire des économies  Réorganiser les  Faciliter l'accès aux compétences SI tests DRaaS  Donner de la flexibilité  Gérer la  Garantir un temps de supervision du reprise à budget constant dispositif DRaaS  Faciliter l'automatisation Taille Criticité des données Délais de reprise Volumétrie / "Dynamisme" des données Niveau de standardisation de l'architecture CATEGORIES DE RISQUES IDENTIFIES L’équipe LEXSI a identifié 8 risques principaux propres à un projet de DRaaS. Ces risques varient parfois en fonction de la phase du projet. Ils sont classés ci-dessous par niveau de criticité croissante (échelle allant de 1 à 3) : RISQUES A/ Phase d’étude R1 : Impossibilité d’intégration des architectures spécifiques 1 C/ Phase de sinistre D/ Fin de contrat 2 R2 : Perte de confidentialité des informations dans le Cloud B/ Phase d’exploitation 2 R3 : Impossibilité du prestataire à assurer le service 2 2 R4 : Litiges juridiques dus à des non-conformités 1 R5 : Non-respect de la réglementation 1 R6 : Perte des données ou de l’intégrité des données répliquées dans le Cloud 1 1 R7 : Impossibilité de récupérer les données R8 : Perte de gouvernance 2 2 3
  • 4. 2 CLOUD COMPUTING, LE NOUVEAU GRAAL POUR LE SECOURS DU SI ? L’adhérence des métiers aux systèmes d’information (SI) ne fait que se renforcer. De plus en plus d’activités critiques sont entièrement dépendantes de leur SI. Et pourtant, seulement 41% des organisations possèdent un plan de continuité du système d’information (PCSI) en place, maintenu et régulièrement testé1. Ce manque de maturité est particulièrement visible dans les petites et moyennes entreprises2. Alors même que ces PME sont plus sensibles aux sinistres que les grandes entreprises3, une très faible proportion d’entre elles possèdent un PCSI ou même un projet de PCSI. Elles perçoivent le plan de continuité du SI comme un investissement majeur – entendez dispendieux - qui est rarement en tête des priorités. Du côté des équipes SI aussi, on rechigne à envisager ces projets parce qu’on les considère comme complexes à mettre en oeuvre, à maintenir, à tester et à manager en cas de crise et qu’on craint parfois qu’ils soient le signe avant-coureur d’une externalisation. Bien qu’encore à ses débuts, le concept de secours du SI dans le Cloud propose une solution simplifiée. Très populaire aux Etats-Unis, cette solution séduit là-bas près de deux tiers des entreprises4. Si elle n’apporte pas de meilleures performances que les meilleures techniques actuelles de secours, la reprise du SI dans le Cloud offre une solution flexible et abordable. En France pour autant, le marché est encore assez peu mature, avec peu de retours d’expériences. Dans le futur, les estimations prévoient qu’un grand nombre d’entreprises de taille moyenne franchissent le pas du secours du SI dans le Cloud stimulant ainsi le marché mondial qui passerait d’environ 500 millions d’euros aujourd’hui à 4,4 milliard d’ici 20185. 12 et 3 Bennasar, M., Keat, L., (2010) PCA, Le chemin de la maturité 4 Sondage effectué aux Etat Unis, UK et Inde, Forrester Consulting, (2012) Cloud-Based Disaster Recovery Barriers And Drivers In The Enterprise 5 HeraldOnline, (2013) Recovery-As-A-Service Market Worth $5.7 Billion by 2018 livre blanc | LE SECOURS DU SI DANS LE CLOUD Ce livre blanc se veut le compagnon pratique du décideur SI, pour éclairer sa lanterne au moment où il envisage sérieusement la possibilité de secourir le SI dont il a la charge dans le Cloud. Pour l’aider dans sa réflexion, il trouvera ci-après matière à alimenter ses réflexions pour :  Poser les définitions et présenter les concepts structurants, en particulier la notion de DRaaS (Disaster Recovery as a Service) ;  Inventorier les avantages et contraintes associées à la mise en oeuvre du secours du SI dans le Cloud ;  Analyser les recommandations relatives aux cas d’utilisation préconisés, suivant le contexte et l’activité ;  Analyser les risques induits par le recours au secours dans le Cloud ;  Répertorier les points de vigilance incontournables à l’heure où il analyse une offre de service en ce sens. COMMENT LE CLOUD PEUT-IL REPONDRE AUX BESOINS DE CONTINUITE DU SI ? Le National Institute for Standards and Technology (NIST) définit le Cloud Computing comme « l’ensemble des disciplines, technologies et modèles commerciaux utilisés pour délivrer des capacités informatiques (logiciels, plateformes, matériels) comme un service à la demande. »
  • 5. FAUT-IL FAIRE LE GRAND SAUT DU DRaaS ? Le DRaaS, pour Disaster Recovery as a Service, créé dans la lignée des SaaS, PaaS et IaaS6, s’appuie sur le Cloud Computing pour proposer des offres intégrées de secours du SI7. Ces offres sont proposées par des prestataires de différents types :  Les prestataires historiques de la continuité du SI (comme IBM, Sungard, etc.)  Les prestataires pure players de Cloud Computing et d’hébergement élargissant leurs offres à la reprise d’activité dans le Cloud (comme FusionStorm, Hosting, Iland, Veristor, RightScale, EVault, etc.)  Les prestataires de secours dans le Cloud uniquement qui profitent de l’engouement actuel pour innover (comme NScaled, InMage, Doyenz, Vision Solutions, etc.)8. Dans le cadre de ces offres, l’ensemble des données (données applicatives, données systèmes, etc.) de l’entreprise est répliqué dans le Cloud. Des serveurs virtuels répartis dans le Cloud sont dédiés à la reprise du SI. Ils ne sont démarrés qu’en cas de sinistre, en fonction des besoins. Lorsqu’un sinistre est avéré, les données répliquées sont affectées sur ces serveurs virtuels jusque-là inactifs. Il y a alors reprise totale (ordonnancée si besoin) des données, des serveurs et des liens télécom. Les utilisateurs peuvent se connecter aux applications métier secourues au travers d’une connexion internet ou d’un réseau privé. Software as a Service, Platform as a Service et Infrastructure as a Service 7 Certaines entreprises préfèrent se charger elles-mêmes d’assembler les différentes briques de leur PCSI sur la base de solution de type SaaS, PaaS, IaaS. Il s’agit de choisir un prestataire de Cloud et une solution de réplication de données, de faire l’intégration et d’administrer le système. Attention toutefois à ne pas confondre PCSI dans le Cloud et backup dans le Cloud. Cette dernière solution permet d’assurer la reprise des données uniquement alors que le PCSI dans le Cloud inclut la reprise d’un périmètre beaucoup plus important  : reprise des données, des serveurs et des télécoms. 8 Il est à noter que certains de ces prestataires possèdent leur propre Cloud (Iland, NScaled, Doyenz, etc.) alors que d’autres se basent sur des Clouds publics (RightScale, Vision Soutions). 6 3 Le retour à la normale est assuré de façon similaire : les données traitées après le déclenchement du sinistre sont stockées dans le Cloud et peuvent être rapatriées sur les machines physiques et/ou virtuelles de la salle informatique nominale dès lors que le processus de crise est clôturé et que l’infrastructure technique le permet. Des mécanismes intelligents de bascule inverse existent pour déterminer ce qui a été perdu ou ce qui a évolué. AVANT Salle principale R syn éplic asy chronation nch e o ron u e serveurs virtuels éteints serveur actif Utilisateurs Salle principale ÉE STR SINI APRÈS serveurs virtuels allumés Utilisateurs Figure 1 : Principe de secours du SI dans le Cloud avant et après sinistre QU’EST-CE QUE ÇA CHANGE ? Le DRaaS est une solution transparente pour les utilisateurs en cas de sinistre. En termes d’organisation, tout reste possible : relocalisation sur un autre site de l’entreprise ou sur un site externalisé, télétravail, etc. Seuls un accès Internet et un poste de travail sont essentiels pour l’utilisateur. En cas de sinistre total du site, les solutions de télétravail sont bien souvent favorisées par rapport à un site alternatif dans la limite des
  • 6. 4 livre blanc | LE SECOURS DU SI DANS LE CLOUD contraintes métiers et organisationnelles. En revanche, pour les équipes SI, le DRaaS apporte de nombreux changements tant d’un point de vue technique que d’un point de vue organisationnel ou financier. pourrait réduire le temps consacré à la solution de reprise en affectant seulement 0,02ETP11 (1h/sem). Cela permet une réorganisation des compétences pour se concentrer sur les activités à forte valeur ajoutée. Coût solution DRaaS FAIRE DES ECONOMIES Le modèle pay-as-you-go (paiement à l’usage) permet de limiter le coût du secours du SI en évitant les redondances traditionnellement nécessaires. Le paiement s’effectue en fonction du volume de stockage consommé et non de l’infrastructure inactive. Les serveurs, par exemple, ne coûtent à l’organisation qu’en cas de secours ou en cas de test (voir Figure 2  : Un modèle de coût différent). En fonction des organisations, l’externalisation de la reprise du SI dans le Cloud peut générer jusqu’à 85% d’économies9 par rapport à une solution classique. Wood, T., Cecchet, E., Ramakrishnan, K., Shenoy, P., Van der Merwe, J. & Venkataramani, A., (2010), Disaster Recovery as a Cloud Service : Economic Benefits & Deployement challenges 10 Equivalent Temps Plein Surcoût liés au DRaaS Coût de l’infrastructure De telles économies sont néanmoins à relativiser et ne concernent pas toutes les entreprises. Il convient de prendre en considération le coût du trafic réseau qui peut être conséquent en cas de synchronisation d’une grande quantité de données. Par ailleurs, en fonction du nombre, de la puissance et des conditions de mise à disposition des machines virtuelles, des coûts supplémentaires pourront être facturés. La solution DRaaS permet de réduire la complexité d’administration du secours pour les équipes DSI et donc de diminuer les coûts associés aux effectifs dédiés à la maintenance et à la mise à jour de la solution de secours. Par exemple, une entreprise qui affecterait 0,12ETP10 (5h/sem environ) à l’entretien d’une solution de reprise traditionnelle en interne Coût d’un site de secours traditionnel Economies liées au DRaaS Les avantages du draas Test Test année 1 Secours TEMPS Test année 2 Figure 2 : Un modèle de coût différent Source : Deronzier, E., Bennasar, M., Grept, P. (2013) FACILITER L’ACCES AUX TESTS Les tests peuvent être mis en oeuvre avec un coût limité sans impacter la production. Dans les solutions traditionnelles, il faut bien souvent faire des exclusions de périmètre car il serait trop cher de tout tester : certains limitent les tests aux applications critiques ; d’autres les espacent pour les mener à grande échelle ; d’autres enfin, organisent une rotation des tests entre différents groupes d’applications ou de plateformes techniques. 9 EVault (2013) Reprise d’activité dans le Cloud : A la portée des PME 11
  • 7. FAUT-IL FAIRE LE GRAND SAUT DU DRaaS ? Grâce au Cloud, les coûts d’infrastructure sont uniquement liés à l’activation des serveurs de secours12 (voir Figure 2 : Un modèle de coût différent). Ainsi, la réalisation des tests est encouragée par un coût d’infrastructure plus faible, augmentant ainsi l’assurance du caractère opérationnel du plan de secours du SI. PERMETTRE UNE PLUS GRANDE FLEXIBILITE Les solutions de reprise d’activité dans le Cloud sont flexibles en termes de dimensionnement des ressources nécessaires dans le Cloud. Il est bien plus aisé pour les équipes d’étendre ou de réduire le périmètre du PCSI sur demande auprès du prestataire sans avoir à déployer une nouvelle infrastructure ou à modifier le processus de réplication des données. Ainsi, la prise en compte de nouvelles applications dans le PCSI ou le changement d’outils applicatifs, assuré par une bonne gestion du prestataire, peut s’avérer plus simple à réaliser. 5 FACILITER L’AUTOMATISATION DU PCSI La majorité des solutions actuelles de bascule en secours manquent de fiabilité en raison de leurs dépendances à des actions manuelles. L’activation des serveurs ainsi que le processus de bascule dans le Cloud peuvent être automatisés dès la détection d’un sinistre pour permettre la restauration des services métiers sans aucune intervention des équipes DSI. Le savoir-faire et le retour d’expérience des fournisseurs de DRaaS permettent de faciliter la bascule dans le Cloud. Certaines tâches devront néanmoins être réalisées manuellement comme la redirection réseau, la modification des IP et des configurations pare-feu. LES CHANGEMENTS A METTRE EN OEUVRE DEPLOYER UNE SUPERVISION PLUS « SERREE » DES SYSTEMES ASSURER UN MEILLEUR TEMPS DE REPRISE A BUDGET CONSTANT Les solutions de type DRaaS assurent facilement une reprise du SI en quelques heures sous réserve de synchronisation des données. Cette durée de reprise détermine bien souvent la différence entre succès et échec lors d’une opération de reprise du SI. Si ce faible temps de reprise est tout aussi envisageable avec les solutions traditionnelles, il s’avère, à temps de reprise équivalent, nettement plus onéreux. C’est par construction que le Cloud est avantageux du fait de son modèle économique, de ses technologies et de ses fonctionnalités intrinsèques. Quoi qu’il en soit, plus le temps de reprise est réduit, plus le coût de la solution sera élevé. Attention, il ne faut pas négliger les coûts annexes liés à la définition, à la réalisation des tests et à la validation par les métiers qui sont très similaires à ceux des tests d’une solution traditionnelle. 12 Afin d’assurer le bon fonctionnement du dispositif DRaaS, la mise en oeuvre de mécanismes de supervision est essentielle tant du côté du client que du côté du prestataire. Cette supervision doit permettre de surveiller le bon fonctionnement des mécanismes assurant la réplication des données (applications, télécoms), la détection de dysfonctionnement et l’alerte en cas d’incident. Du côté du prestataire, la supervision est essentielle en cas d’utilisation de services applicatifs actifs. C’est le cas tant pour une solution synchrone avec de nombreux serveurs actifs en mode de réplication que lors de la bascule du système d’information vers le Cloud. Du côté client, il est recommandé de demander l’accès à la supervision du prestataire afin de pouvoir contrôler en direct le fonctionnement du dispositif DRaaS.
  • 8. 6 livre blanc | LE SECOURS DU SI DANS LE CLOUD REORGANISER LES COMPETENCES DES EQUIPES SI Si ce schéma tend à montrer que le DRaaS est la solution la plus efficace opérationnellement, elle ne représente pas une opportunité pour toutes les entreprises, ni toutes les circonstances. Si les compétences techniques nécessaires à l’exploitation de la plateforme de secours sont grandement réduites et peuvent être réorganisées, la gestion de contrats devient une activité essentielle. Il faut alors disposer de l’arsenal de compétences qui y est associé  : négociation, mise en place efficace, surveillance et pilotage, suivi managérial, etc. COMPARAISON DE 3 MODES DE SECOURS SELON DES CRITERES OPERATIONNELS La Figure 3 compare les modes opérationnelles sur les équipes DSI de 3 solutions de secours du SI : externalisation dans le Cloud, salle de secours sur site interne distant et externalisation du secours informatique (secours à froid chez un prestataire). Ces trois solutions sont évaluées sur 5 axes selon une notation de 0 à 3 (0 : mauvaise performance, 3  : excellente performance). On constate que la solution la moins performante est l’externalisation du secours informatique. Selon nos axes de comparaison opérationnels, la reprise d’activité dans le Cloud est avantageuse par rapport au secours interne en termes de facilité de maintenance et de charge en cas de sinistre. Réduction des charges d'activation du secours après sinistre 3 2 Facilité d'activation 1 Facilité de mise en oeuvre du PCI 0 Facilité d'accès aux tests LA REPRISE D’ACTIVITE DANS LE CLOUD : EST-CE POUR MOI ? Cinq critères permettent de juger de la pertinence du DRaaS pour une entreprise. Ces critères intrinsèques sont exclusifs : si, pour l’un des 5 critères, l’entreprise ne possède pas les caractéristiques recommandées, la pertinence du DRaaS est alors remise en cause. Il est important de noter que certains de ces critères sont interdépendants. AI-JE LA BONNE TAILLE ? Gartner prévoit que le marché du DRaaS soit stimulé par les entreprises de taille moyenne (entre 115 et 750 millions d’euros de revenus par an). Les entreprises plus importantes ont, en effet, bien souvent des moyens de réplication puissants ou sont parfois distribuées sur plusieurs datacenters ce qui leur permet de faire du secours entre leurs différents sites. Les petites entreprises quant à elles n’ont bien souvent pas de stratégie de reprise formalisée. S’il est clair que le DRaaS est tout destiné aux entreprises de taille moyenne, nous considérons que c’est aussi une opportunité pour les petites entreprises de définir et mettre en oeuvre un plan de continuité d’activité à moindre coût organisationnel et financier. MES DONNEES ONT-ELLES UN NIVEAU DE CRITICITE APPROPRIE13 ? Facilité de maintenance Externalisation dans le Cloud Salle de secours sur site interne distant (800 kms) Externalisation du secours informatique (reprise à froid) Figure 3 : Benchmark de l’impact d’une reprise d’activité dans le Cloud Les prestataires de DRaaS ont la capacité d’assurer un niveau de sécurité des données externalisées élevé au travers de solutions de cloisonnement logique, Attention, le contenu de ce paragraphe n’est pas spécifique au DRaaS, mais s’applique à toute problématique Cloud 13
  • 9. FAUT-IL FAIRE LE GRAND SAUT DU DRaaS ? de chiffrement, d’authentification, etc. Malgré ces mesures de protection, la crainte de perte de confidentialité persiste chez les DSI qui ont l’impression que la sécurité de leurs données leur échappe  : divulgation due à une erreur du prestataire, problématique de conformité, perte de gouvernance, etc. Ces risques sont-ils uniquement perçus par peur du changement ? Au vue du faible niveau de maturité de l’offre, nous considérons que le DRaaS est à déconseiller aux entreprises :  traitant des données hautement sensibles14.  dont les données sont soumises à de fortes contraintes d’audit.15 Dans ce dernier cas, l’implication d’un prestataire DRaaS peut rendre l’audit plus complexe à gérer (contractuellement ou dans la pratique des audits). Il peut néanmoins être pertinent pour les entreprises de « découper » leur SI afin d’utiliser le DraaS pour secourir les applications les moins sensibles16. QUEL EST MON DELAI DE REPRISE ? Le schéma ci-après (figure 4  : illustration du PDMIA et du DMIA) permet de rappeler les notions de PDMA et DMIA17. Les entreprises très exigeantes seront heureuses d’apprendre que le DRaaS permet d’assurer un DMIA et un PDMA très faibles. Cependant, des exigences très élevées associées à d’autres facteurs (besoin en synchronisation et solution de synchronisation des données retenue par exemple) peuvent rendre la solution DRaaS économiquement peu attrayante. De manière optimale, le DRaaS est une excellente réponse pour les entreprises dont le niveau d’exigence DMIA/PDMA n’est ni extrêmement faible ni extrêmement élevé. Le DRaaS permet notamment de rendre les DMIA et PDMA exigeants accessibles aux entreprises avec un coût réduit. Cette solution permet de réduire l’écart entre les solutions très performantes actuelles (salle miroir) et le secours salle blanche ou même la sauvegarde sur bandes. Déclenchement PCSI dernière sauvegarde Bascule sinistre Retour à la normale Temps écoulé PDMA DMIA Figure 4 : Illustration du PDMIA et du DMIA De type secret-défense par exemple. De type données comptables et financières. 16 Notamment si elles nécessitent d’être secourues avec une durée d’indisponibilité et une perte de données maximale qui ne peut être atteint avec les solutions traditionnelles dans un budget raisonnable. 7 14 15 17 Voir glossaire page 18.
  • 10. livre blanc | LE SECOURS DU SI DANS LE CLOUD 8 TEMPS seconde Salle miroir Sinistre T0 Classe 1 0 ≤ DMIA < 2h Classe 1 0 ≤ PDMA < 1h Classe 2 1 ≤ PDMA < 5h Classe 3 8 ≤ DMIA < 24h DR Optimum Classe 2 2h ≤ DMIA < 8h Salle rouge S aa Classe 3 Salle blanche 5h ≤ PDMA < 24h Classe 4 24h ≤ DMIA < 1 sem 24h ≤ PDMA < 1 sem Réplication sur bandes Classe 4 semaine € €€ €€€ €€€€ 10K 50K 100K 300K Figure 5 : Utilisation optimum du DRaaS La figure 5 ci-dessus, illustre la plage optimale d’utilisation du DRaaS. Cette plage comble un vide fonctionnel actuel et répond à un besoin répandu. QUELS SONT LE « DYNAMISME » ET LA VOLUMETRIE DE MES DONNEES HEBERGEES ?18 Le DRaaS est financièrement intéressant si le coût de la réplication est très inférieur au coût de fonctionnement de l’ensemble des fonctions répliquées (en cas de sinistre ou de test). En d’autres termes, si la réplication nécessite peu de stockage et peu de machines virtuelles en fonctionnement comparé aux besoins de stockage et de machines virtuelles en cas de secours, alors le DRaaS représente un avantage financier. Wood,T., Cecchet, E., Ramakrishnan ,K., Shenoy, P.,Van der Merwe, J. & Venkataramani, A., (2010) Disaster Recovery as a Cloud Service: Economic Benefits & Deployment Challenges 18 Il s’agit des cas pour lesquels la volumétrie des données est faible et les données peu dynamiques. Par données dynamiques, on entend les données à évolution permanente nécessitant l’utilisation incessante de serveurs pour leur intégration dans le Cloud. Par exemple (cas 1, figure 6), si une entreprise secourt des applications de type multi-tiers avec une seule base de données, l’attrait économique est notable. Il y a en effet peu de données dynamiques qui nécessitent l’activation de l’infrastructure de Cloud pendant la réplication des données. En revanche (cas 2, figure 7), dans le cas où une entreprise nécessite une forte capacité de stockage en perpétuelle augmentation et la disponibilité de nombreux serveurs en permanence pendant la réplication des données (ex : réplication d’un data warehouse), le coût mensuel du DRaaS est beaucoup plus élevé que dans le cas précédent et ce mode de secours peut coûter plus cher.
  • 11. FAUT-IL FAIRE LE GRAND SAUT DU DRaaS ? Coût d’un site de secours traditionnel Cas 1 Peu de données dynamiques Cas 1 Moyenne sur l’année Coût de l’infrastructure 9 L’utilisation du DRaaS peut néanmoins rester attrayante dans les cas où le PDMA peut être affaibli19 et associé à d’autres solutions de type déduplication20. La figure 8 explicite le lien entre dynamisme et volumétrie des données et PDMA/DMIA  : l’intérêt économique du DRaaS peut être accru en abaissant le PDMA et DMIA des données à fort dynamisme et volumétrie. Il faut néanmoins faire attention à ce que les synchronisations programmées n’engendrent pas des pics de transfert plus importants qu’en temps réel. Chaque entreprise choisira le mode de synchronisation le plus adapté à sa situation. TEMPS Test Test Test année 1 Secours TEMPS seconde année 2 Figure 6 : Coût du DRaaS cas 1 DMIA / PDMA Cas 2 Beaucoup de données dynamiques Coût d’un site de secours traditionnel Classe 1 Cas 2 Moyenne sur l’année Coût de l’infrastructure Classe 2 Classe 3 Classe 4 semaine Faible Moyen Important Très Important VOLUMÉTRIE ET DYNAMISME DES DONNÉES Classe 1 0 ≤ DMIA < 2h Classe 2 2h ≤ DMIA < 8h 0 ≤ PDMA < 1h 1 ≤ PDMA < 5h Classe 3 8 ≤ DMIA < 24h Classe 4 24h ≤ DMIA < 1 sem 5h ≤ PDMA < 24h 24h ≤ PDMA < 1 sem Figure 8 : Cas d’utilisation optimale du DRaaS en fonction  de la volumétrie et du dynamisme des données Test Test Test Secours TEMPS Figure 7 : Coût du DRaaS cas 2 Synchronisation toutes les heures par exemple. Technique permettant de réduire les capacités de stockage et de bande passante en identifiant dans les données, les séquences redondantes afin de les stocker une seule fois. 19 20
  • 12. 10 livre blanc | LE SECOURS DU SI DANS LE CLOUD POINT D’ATTENTION Le type de serveur utilisé par une entreprise n’est, lui, en aucun cas un facteur limitant pour le DRaaS. Les prestataires proposent des offres de DRaaS à la fois de serveurs physiques vers des serveurs virtuels (P2V) et de serveurs virtuels vers des serveurs virtuels (V2V)22. Le volume des données échangées avec le DRaaS (du fait de la synchronisation des données) induit la nécessité d’augmenter et de fiabiliser la largeur de la bande passante21. On n’oubliera pas que certaines contraintes peuvent réduire l’intérêt du DRaaS  : le positionnement géographique des sites peut limiter le débit et donc rendre la solution de DRaaS impossible à mettre en oeuvre. Par ailleurs, les coûts des liens télécoms haut débit peuvent être très élevés dans des zones mal desservies et donc diminuer l’attrait économique du DRaaS. De la même manière concernant la partie réseau, le caractère exotique de l’architecture peut être un sérieux frein à l’utilisation du DRaaS. Il convient de définir au plus tôt avec le prestataire l’architecture client à répliquer chez celui-ci (VLAN, routage, DMZ, etc.). MON TYPE D’ARCHITECTURE (STANDARD/ NON STANDARD) S’ADAPTE-T’IL AU DRAAS ? Certaines architectures ne sont pas prises en compte par les prestataires de DRaaS. Les technologies Windows et Linux sont évidemment couvertes. Mais, pour les OS de mainframe (z/OS, GECOS...), UNIX propriétaires (AIX, HP/UX...) ou OS/400, il est plus difficile voire impossible de trouver une solution compatible. De même, avec les applications développées en interne qui utilisent des technologies très spécifiques. Si une entreprise possède plusieurs applications critiques qui ne peuvent pas être prises en compte, la solution de DRaaS perd toute sa pertinence. Il en va de même dans le cas d’utilisation de progiciel qui entraine l’implication de nombreux acteurs  : le fournisseur du logiciel, le fournisseur de DRaaS et le client. La multiplication des acteurs complexifie la réalisation des projets de DRaaS. Il est nécessaire pour les entreprises de disposer d’une connexion fiable, performante, sécurisée autant pour le lien principal que pour le lien de secours. Cependant, le lien télécom du site principal n’est pas le seul lien à prendre en compte. Il ne faut pas oublier les liens des sites distants qui pourraient être isolés en cas de sinistre du site principal. 21 P2V pour Physical to Virtual et V2V pour Virtual to Virtual. Ces solutions permettent de s’affranchir du type d’outil utilisé. 22
  • 13. FAUT-IL FAIRE LE GRAND SAUT DU DRaaS ? SCHÉMA DE SYNTHÈSE : EST-CE POUR MOI ? Le schéma ci-dessous offre une vision synthétique des critères préalablement explicités. Les cases en dégradé de couleur indiquent les cas dans lesquels certains 11 critères ne peuvent, à eux seuls, déterminer la pertinence d’une solution de DRaaS. Dans ces configurations, une étude au cas par cas est nécessaire pour conclure. Vous vous situez uniquement sur les cases claires  ? Alors le DRaaS est fait pour vous ! Taille Criticité des données DMIA/PDMA Volumétrie, dynamisme Type d'application ou d'architecture PME/PMI Données peu sensibles 0 ≤ DMIA < 2h 0 ≤ PDMA < 1h Faible Standard ETI Données sensibles 2h ≤ DMIA < 8h 1h ≤ PDMA < 5h Moyen Spécifique Grande entreprise Données soumises à audit 8h≤ DMIA 5h ≤ PDMA Important Très spécifique Figure 9 : Synthèse - Est-ce pour moi ? REUSSIR SON PCSI DANS LE CLOUD… La suite de ce livre blanc vise à guider les entreprises souhaitant externaliser la reprise de leur SI dans le Cloud. Afin que cette externalisation soit réussie, il est essentiel de comprendre les risques associés et d’avoir en tête les points critiques à préciser avec un prestataire de DRaaS pour y répondre. DU COTE DES RISQUES LEXSI a réalisé une analyse de risques qui a abouti à l’identification de 8 risques principaux liés à la mise en oeuvre du secours du SI dans le Cloud. Cette liste n’est pas exhaustive, elle reprend les principales sources d’échecs des projets de DRaaS. Certains de ces risques sont partagés avec tout projet lié au Cloud Computing, comme la perte de confidentialité des données ; d'autres sont spécifiques aux problématiques de DRaaS, comme l’impossibilité d’intégration d’architectures spécifiques. Chaque risque a été placé dans l’étape du projet DRaaS qui lui correspond : phase d’étude, phase d’exploitation, sinistre ou fin de contrat. Les conséquences de la matérialisation de chaque risque ont été analysées en termes d’impact juridique, financier, opérationnel et image. Les niveaux d’impact et de probabilité ont ensuite été cotés de 1 à 4 selon l’échelle présentée en Annexe 1. (voir le tableau regroupant l’ensemble de cette analyse en Annexe 2). L’ensemble de ces risques a ensuite été représenté sous forme de cartographie en fonction du niveau d’impact et de probabilité, sur une grille symétrique (afin de ne privilégier ni l’impact, ni
  • 14. 12 livre blanc | LE SECOURS DU SI DANS LE CLOUD la probabilité). Les trois couleurs mettent en évidence les niveaux de risques (respectivement : faible criticité, criticité moyenne et criticité importante). Le dégradé de gris représente les différentes phases (étude, exploi- tation, sinistre et fin de contrat) durant lesquelles un sinistre peut se produire. En fonction de ces phases, l’impact et la probabilité peuvent varier. Par exemple, le risque de perte des données répliquées dans le Cloud PROBABILITÉ 4 R1a 3 R2d R8c R8b R4b 1 R7d B/ Phase d'exploitation 3 D/ Fin de contrat R1a R2a R6c 2 C/ Phase de sinistre R3c R2a R6b 1 A/ Phase d'étude R2b R5b 2 4 impact Risques R1 : Impossibilité d’intégration des architectures spécifiques R2b R2d R3c R2 : Perte de confidentialité des informations dans le Cloud R3 : Impossibilité du prestataire à assurer le service R4b R4 : Litiges juridiques dus à des non-conformités R5b R5 : Non-respect de la réglementation R6b R6c R6 : Perte des données ou de l’intégrité des données répliquées dans le Cloud R7d R8b R8c R7 : Impossibilité de récupérer les données R8 : Perte de gouvernance Figure 10 : Cartographie des risques peut se produire en phase d’exploitation ou en cas de sinistre. Dans le premier cas, l’impact est relativement limité  : il s’agira d’identifier le problème, de le résoudre et de s’assurer de la bonne synchronisation des données. Si la perte des données répliquées a lieu lors d’un sinistre, cela entraine alors l’impossibilité de reprendre l’activité dans les temps prévus par le PCSI. Il s’agit alors d’effectuer la reprise d’activité à partir des sauvegardes… L’impact est notablement plus important. L’analyse exhaustive de risques est présentée en Annexe 2 dans un tableau de synthèse.
  • 15. FAUT-IL FAIRE LE GRAND SAUT DU DRaaS ? FAIRE FACE AUX RISQUES ET REUSSIR SON SECOURS Le tableau suivant (Figure 11 : Synthèse des points de passage pour réussir son PCA dans le Cloud) identifie 21 points de passage clés pour assurer toutes les chances de réussite à un projet de PCSI dans le Cloud 13 en répondant aux risques détaillés précédemment. Ces points de passage sont regroupés au sein de 7 thématiques et mettent en évidence les sujets cruciaux à discuter et à définir précisément avec le prestataire de DRaaS. C’est en passant par ces étapes que vous pourrez juger du sérieux et de la pertinence de la réponse d’un prestataire pour être sûr que votre projet est entre de bonnes mains. SYNTHESE DES POINTS DE PASSAGE POUR REUSSIR SON PCSI DANS LE CLOUD INTÉGRATION Audit de l'existant CONFORMITÉ Intégration des tests à l'offre et tarification associées Adaptation Compatibilité Problémade l'infrastructure du débit des dif- tique d'intégration existante férents sites des progiciels CONFIDENTIALITÉ Modèle de Cloud Conformité du prestataire Conformité pour les besoins clients DISPONIBILITÉ Zone d'hébergement Pérennité du prestataire CONFIGURATION Sécurité logique et physique Convention de niveau de services (SLA) Gestion de secours de client simultanés Plan de réversibilité SÉCURITÉ Possibilité d'utilisation du DRaaS Distance du lieu d'hébergement Sécurité Sécurisation des données de l'accès au SI transférés et des flux secouru dans le échangées Cloud Niveau de sécurité par défaut STRATÉGIE Transparence du prestataire sur sa stratégie interne Transparence du prestataire sur ses incidents de sécurité Figure 11 : Synthèse des points de passage pour réussir son PCA dans le Cloud Le code couleur met en évidence le niveau d’importance de ces points de passage. Plus le nuage est foncé, plus cette étape nous semble cruciale. Le détail pour chaque point de passage assorti de spécifications et de conseils est présenté dans un tableau de synthèse en Annexe 3.
  • 16. 14 livre blanc | LE SECOURS DU SI DANS LE CLOUD CONCLUSION Sans offrir la solution miracle aux problématiques de secours du SI, le DRaaS est sans aucun doute une pierre marquante à l’édifice de la continuité d’activité. Les offres de PCSI dans le Cloud ouvrent de nouvelles voies vers une démocratisation de la continuité d’activité supportée par un PCSI fonctionnel et testé. Néanmoins, la réussite des offres de DRaaS passe avant tout par une réflexion de chaque entreprise sur elle-même pour estimer l’applicabilité de ces solutions, une analyse rigoureuse des offres pour cibler le modèle idéal, un suivi méticuleux des risques pour répondre au manque de maturité actuel et un travail en proche collaboration avec le prestataire pour assurer un partenariat efficient et efficace pendant toutes les phases du contrat. En guise de point final, une suggestion pour les décideurs : la mise en oeuvre d’une démarche de secours dans le Cloud peut tout à fait constituer un projet pilote pour qu’une entreprise teste son appétence à la bascule éventuelle de son SI dans le Cloud : les risques opérationnels sont réduits, les infrastructures existantes ne sont que peu touchées, les impacts organisationnels sont minimes et l’opportunité de valider la solution est bien réelle. Et si la mise en place ne se révèle pas probante, l’impact sur le SI et l’entreprise est bien moindre qu’en cas de bascule effective dans le Cloud… ANNEXES ANNEXE 1 : ECHELLES D’IMPACT ET DE PROBABILITE UTILISEES LORS DE L’ANALYSE DE RISQUES Niveau d’impact 1 Faible 2 Moyen 3 Grave 4 Critique Commentaires Gêne le bon déroulement des activités de l'entreprise pendant une faible durée (inférieure à une journée) Perturbe notablement le déroulement des activités de l'entreprise pendant une durée supérieure à une journée. Perturbe considérablement le déroulement des activités de l'entreprise pendant une durée supérieure à 2 semaines. Met en danger la survie de l'entreprise en raison de perte financière, d’image, ou de désorganisation majeure. Niveau dE PROBABILITÉ 1 Exceptionnel 2 Peu probable 3 Plausible 4 Quasi certain Commentaires Situation possible mais peu de cas rencontrés. Survenance : occurrence possible sur une période d’une dizaine d’années Situation rare. Survenance : Occurrence sur une durée d’environ 4 ans Situation rencontrée assez fréquemment. Survenance : Annuelle Situation très probable. Survenance : Plusieurs fois par an
  • 17. FAUT-IL FAIRE LE GRAND SAUT DU DRaaS ? 15 ANNEXE 2 : TABLEAU D’ANALYSE DES RISQUES LIES AU DRAAS L’ensemble des risques listés ci-dessous peuvent s’appliquer à tout ou partie des différentes phases d’un projet (étude, exploitation, sinistre et Impossibilité d’intégration 1a des architectures spécifiques Une mauvaise estimation des difficultés en début de projet (application personnalisée, architecture d’infrastruc- En phase ture atypique non prise en compte, architecture réseau, d’étude etc.) peut mettre celui-ci en défaut. 2a Les causes sont nombreuses: absence d’isolement des environnements, usurpation, intrusion dans les locaux, Perte de confiabsence de chiffrement, etc. dentialité des PricewaterhouseCoopers souligne que seulement 17% 2b informations des entreprises ayant des données hautement confidendans le Cloud tielles s’assurent que les prestataires chiffrent bien les 2d données qui leur sont confiées23. Impossibilité du prestataire 3c à assurer le service L’indisponibilité du prestataire peut provenir d’une faillite, d’une impossibilité à secourir simultanément plusieurs entreprises par manque d’expérience ou de ressources mutualisées, d’une impossibilité à reprendre pour cause de sinistre du prestataire en cas de sinistre à grande échelle, etc. Des litiges juridiques peuvent être dus à : Litiges  Des données hébergées dans des Cloud au sein des juridiques dus pays dans lesquels la protection et le traitement des 4b à des non données n’est pas approprié24. conformités  Une perte de traçabilité des données dans le Cloud. 3 3 oui En phase  Dégradation de l’image 3 d’étude de l’entreprise qui En phase peut avoir un impact d’exploita- économique 3 tion  Poursuites juridiques En fin de  Divulgation d’informations 3 contrat confidentielles  Secours impossible En cas de  Faillite potentielle de sinistre l’entreprise  Poursuites juridiques En phase causant des pertes finand’exploitacières et une dégradation tion de l’image Différentes réglementations peuvent s’appliquer aux données hébergées chez le prestataire DRaaS. En cas Non-respect En phase  Sanctions juridiques de non-respect de ces réglementations, des sanctions d’exploita-  Mauvaise image 5b de la juridiques et financières peuvent être prononcées notamréglementation tion  Perte de contrat ment pour l’hébergement des données de santé ou pour le standard PCI DSS. 6b Perte des données ou de l’intégrité des données 6c répliquées dans le Cloud Des problèmes d’exploitation du Cloud, des erreurs dans le mécanisme de sauvegarde des données, une malveillance de personnes à hauts privilèges en termes d’administration etc. : tout cela peut engendrer une perte de données. En phase  Désorganisation impord’exploita- tante si perte d’intégrité tion détectée tardivement En cas de sinistre Cela peut être lié au risque R3 : si le prestataire est indisImpossibilité de ponible, il est impossible d’accéder aux données (pour En fin de 7d récupérer les migrer vers un nouveau prestataire par exemple). Cette contrat données menace peut aussi se réaliser dans le cadre d’un conflit avec le prestataire. 8b Perte de gouvernance 8c 1 2 Image  Echec du projet  Impossibilité d’implémenter le DRaaS pour une partie de l’architecture Opérationnel Conséquences Financier Phase du projet Juridique SCÉNARIO Impact sur la reprise Risque Probabilité N° Impact fin de contrat). Nous détaillons dans le tableau ci-dessous uniquement les phases projet les plus pertinentes.     non 3       4 2 oui    2 2 non    2 2 non    2 1 non    Impossibilité de secourir tout ou partie du SI  Erreurs dans les données / systèmes secourus 3 1 oui  Perte de données 3 2 oui 3 non En phase  Perte de gouvernance en d’exploita- cas de manque de visibilité 3 On constate fréquemment un empilement incontrôlé des tion sur la gestion des données sous-traitants ce qui entraine une perte de maîtrise pour  Perte de gouvernance le client. En cas de impliquant une perte de 4 sinistre maitrise de la reprise    3    oui Ces statistiques incluent l’ensemble des données intégrées dans le Cloud que ce soit dans le cadre de la reprise du système d’information ou uniquement du stockage dans le Cloud. Source : cloud busting, Continuity Magazine, July/August 2010 24 Par exemple, le Patriot Act, loi américaine, autorise les perquisitions sur les logs, hors contrôle d’un juge, même menées de façon cachée sans en avertir le propriétaire des données. Par contre, l’accès aux données doit être fait sous contrôle d’un juge et doit être déclaré. Ainsi, tout Cloud hébergé aux États-Unis est soumis au Patriot Act qui va à l’encontre de la loi française Informatique et Liberté. Cette non-conformité peut aboutir à des litiges juridiques. 23
  • 18. 16 livre blanc | LE SECOURS DU SI DANS LE CLOUD ANNEXE 3 : CHECKLIST DES POINTS DE PASSAGE POUR CHOISIR SON PRESTATAIRE ET REUSSIR SON PCSI DANS LE CLOUD Détails Audit de l’existant Certaines architectures (infrastructure ou réseau) et certaines applications ne peuvent pas être prises en compte dans une stratégie DRaaS. Avant toute chose, commencez par détailler votre architecture au prestataire (audit de l’existant) pour évaluer si sa solution de DRaaS est utilisable sur votre SI. Méfiez-vous d’un prestataire qui assurerait que le DRaaS est adaptable à tout sans chercher à connaître votre architecture en détail. Intégration des tests à l’offre et tarification associée Les tests nécessitent d’allumer les serveurs en veille dans le Cloud, assurez-vous que la tarification des tests est acceptable et qu’aucun faux frais n’est dissimulé. 3 Adaptation de l’infrastructure existante Certains prestataires exigent de leur client un certain niveau de virtualisation de la salle principale. Relativisez ces exigences car les prestataires travaillent avec des technologies différentes. Il est en général possible de trouver des prestataires s’adaptant à toutes les technologies traditionnelles standards. 4 Compatibilité du débit réseau des différents sites Le volume des données échangées avec le DRaaS induit la nécessité d’augmenter et de fiabiliser la largeur de la bande passante.  Vérifiez la fiabilité, la performance et la sécurité de votre connexion sur vos différents liens sans négliger les liens des sites distants.  Identifier l’ensemble des contraintes sur ces liens télécom : le positionnement géographique des sites peut limiter le débit et donc rendre la solution de DRaaS impossible à mettre en oeuvre. Par ailleurs, les coûts de ces liens télécoms haut débit peuvent être très élevés dans des zones mal desservies et donc réduire l’intérêt économique du DRaaS. 5 INTEGRATION Points de passage 2 CONFORMITE N° 1 THÈMES Problématique d’intégration des progiciels L’usage de progiciels implique la participation d’acteurs supplémentaires lors de la mise en oeuvre d’une offre de DRaaS : le fournisseur de progiciels, le fournisseur de DRaaS et le client. Se pose alors la question des rôles et responsabilités entre les différentes parties prenantes notamment concernant la maintenance des progiciels. Les interventions, le support, les mises à jour concerneront la participation de l’ensemble de ces acteurs. C’est pourquoi la problématique d’intégration des progiciels doit être traitée dès le début du projet de DRaaS. 6 Conformité du prestataire Vous pouvez demander voire exiger de votre prestataire la conformité à certaines normes (ISO, PCI-DSS, SAS-70 type II, etc.). N’oubliez pas de vérifier l’ensemble des prestataires en cas d’empilement. Des organismes comme l’ENISA (European Network and Information Security Agency) ou la Cloud Security Alliance ont mis à disposition des grilles de critères d’analyse25 des solutions de Cloud en général. 7 Conformité pour les besoins clients Vous devez garantir la conformité des données notamment vis-à-vis de la CNIL et vous assurer du bon respect de ces règles par le prestataire. En cas d’hébergement des données hors de l’Union Européenne, assurez-vous de la conformité avec les règlements traitant des transferts internationaux de données. Différentes clauses ou mécanismes peuvent être mis en oeuvre pour assurer cette conformité (ex : Binding Corporate Rules)26. CONFIDENTIALITE DISPONIBILITE Modèle de Cloud 9 Zone d’hébergement Le lieu d’hébergement du Cloud peut aller à l’encontre de la législation française en termes de confidentialité des données (Nbp 24 : Patriot Act). Renseignez-vous sur les lieux d’hébergement et les législations qui les régissent pour vérifier l’absence de toute contradiction et s’assurer contractuellement que vos données resteront bien dans un pays ou une zone géographique donné. 10 25 8 Les différents modèles de Cloud doivent être consciencieusement analysés (privé, public, hybride) en fonction de la criticité des ressources, des coûts et des exigences règlementaires qui pèsent sur les données à héberger dans le Cloud. Afin d’effectuer ce choix en connaissance de cause, identifiez l’ensemble des processus métier et des interfaces SI concernées par l’hébergement dans le Cloud afin d’en assurer le secours. Les clouds publics sont à déconseiller pour des données très sensibles. En cas de partage des infrastructures, demandez à connaitre les mesures de sécurité qui protègent vos données en particulier (firewall dédié par exemple). Pérennité du prestataire Renseignez-vous précisément sur l’état des finances du prestataire, sur ses expériences ou références ainsi que sur le niveau de formation et d’expérience de son personnel (politique de formation, recours à la sous-traitance, etc.). Cela permet d’avoir une vision générale de l’état de l’entreprise du prestataire. 11 Distance du lieu d’hébergement Le lieu d’hébergement du Cloud doit être choisi assez éloigné du site principal pour assurer sa disponibilité en cas de sinistre majeur étendu (tempête, inondation, catastrophe climatique, etc.). 12 Convention de niveau de services (SLA) Les pénalités du prestataire en cas de non-respect des engagements doivent être définies avec soin. Les critères suivants doivent au moins être inclus : le DMIA, le PDMA, la période d’occupation maximale du Cloud en mode secours, les frais d’occupation de la solution de secours au-delà de la période fixée, la capacité à fournir des infrastructures supplémentaires si nécessaire ainsi que les clauses de rupture du contrat. ENISA (2009) Cloud Computing, Benefits, risks and recommendations for information security ; Cloud Security Alliance : Cloud Controls Matrix V1.4 26 Plus de détails sur les normes dans le guide du Cloud Computing 2013 publié par la CIGREF-IFACI et AFAI
  • 19. FAUT-IL FAIRE LE GRAND SAUT DU DRaaS ? THÈMES N° Points de passage 17 Détails DISPONIBILITE Plan de réversibilité Définissez un plan de réversibilité pour avoir la garantie de pouvoir récupérer l’ensemble de données présentes dans le Cloud (en cas d’impossibilité à secourir le site ou simplement pour changer de prestataire). Ce plan doit comprendre : le délai de suppression des données et le planning de réversibilité, les facteurs déclencheurs du plan, la possibilité d’effectuer un audit de réversibilité, le transfert de compétence vers le client ou le nouveau prestataire, etc. 15 Possibilité d’utilisation du DRaaS Vous devez définir avec le prestataire l’ensemble des possibilités d’utilisation du DRaaS afin de pouvoir configurer de manière appropriée le Cloud. Dans la pratique, ce sont souvent des oublis ou des imprécisions qui sont causes d’erreurs au moment du déclenchement du secours. Il faut par exemple s’assurer que le prestataire :  Configure les firewalls du Cloud pour permettre l’accès aux ressources,  Configure le Cloud afin de rendre le secours accessible depuis un site distant, par télétravail ou sur le site par défaut en cas de sinistre partiel,  S’assure que le flux de mail SMTP soit redirigé vers l’environnement de secours,  Etc. 16 CONFIGURATION Gestion des secours de clients simultanés Il est du droit du client de demander à connaitre la répartition des clients sur les Datacenters du prestataire (de manière anonymisée) pour garantir la reprise en cas de besoins de reprise simultanés. Assurez-vous que les prestataires utilisent un modèle de risque similaire à ceux utilisés dans le secteur des assurances. Cette gestion des risques est indispensable pour estimer combien de serveurs sont nécessaires dans un datacenter pour un certain nombre de clients et comment répartir les clients sur les différents datacenters. Niveau de sécurité par défaut Les offres en boite noire, même celles incluant un certain niveau de sécurité, ne sont pas toujours conçues pour prendre en compte les besoins de sécurité métier différents d’une entreprise à l’autre. N’acceptez jamais d’offre en boite noire ! De plus, il ne faut jamais considérer que la sécurité est incluse par défaut. Plus vous serez informés, plus vous maîtriserez le niveau de sécurité. 13 14 SECURITE Sécurité des données transférées et des flux échangés La sécurité ne doit pas être négligée pendant le transfert des données depuis le système d’information de l’entreprise vers le Cloud. Assurez-vous à minima du chiffrement des données transférées. Par ailleurs, pensez à vérifier que le prestataire garantit l’impossibilité d’utiliser les flux échangés pour accéder au SI de l’entreprise. En revanche, l’exécution d’opérations dans le Cloud sur des données chiffrées reste extrêmement complexe car elle nécessite l’usage du chiffrement homomorphique27. Aucune solution prête à l’emploi n’existe aujourd’hui. 19 STRATEGIE Sécurité logique et physique 18 27 17 Redondance des firewalls, utilisation de VLANs privés, chiffrement des zones de stockage, systèmes de vidéo-surveillance, badge, protection incendie, etc. demandez au prestataire d’effectuer des audits de sécurité réguliers pour tester à la fois la sécurité physique et la sécurité logique de son infrastructure (sécurité des systèmes en termes de configuration, sécurité des réseaux, sécurité des accès logiques, etc.). Il est fortement recommandé d’intégrer une clause d’audit dans l’offre du prestataire. Nous réalisons au quotidien de nombreux audits de sous-traitants et les écarts conséquents régulièrement identifiés sont listés ci-dessous :  Mauvaise gestion de la sécurité au quotidien,  Ecart de compréhension entre le prestataire et le client,  Plan de secours inexistant, partiel et ne couvrant pas les attentes du client,  Mauvaise gestion des accès partenaires,  Apparition de sous-traitants inattendus,  Localisation des données hors d’Europe,  Cloisonnement incomplet entre les clients,  Développement sans prise en compte des exigences métier de sécurité,  Pas ou peu de contrôle lors des mises en production,  Sauvegardes non sécurisées et externalisées (y compris les sauvegardes du prestataire),  Etc. Sécurisation de l’accès au SI secouru dans le Cloud L’accès au SI secouru s’effectue par internet. Vérifiez le type d’authentification, de chiffrement et de traçabilité pour éviter toute problématique d’intrusion en mode secouru. 20 Transparence du prestataire sur sa stratégie interne Il est légitime de connaitre la stratégie et le mode de management du prestataire. Un management basé sur de l’ITIL v3 ou une certification ISO 20000 peut être une preuve de maitrise du service. Néanmoins, il est toujours bon de vérifier que le prestataire intègre bien les bases de la sécurité (RSSI, Charte, Politique de sécurité, etc.). 21 Transparence du prestataire sur ses incidents de sécurité Vous pouvez exiger la transparence sur les autres clients qui partageraient la même infrastructure que vous et sur la stratégie de gestion des incidents et de la vie privée. De même, vous pouvez demander à recevoir périodiquement un bilan des incidents de sécurité qui vous concernent. Le chiffrement homomorphique permet de réaliser des traitements sur les données stockées dans le Cloud (calcul, requête sur base de données, etc.) sans avoir à déchiffrer les données, réaliser les traitements puis chiffrer de nouveau les données comme c’est le cas aujourd’hui.
  • 20. 18 livre blanc | LE SECOURS DU SI DANS LE CLOUD glossaire DMIA Durée Maximale d’Interruption Admissible DRaaS Disaster Recovery as a Service ETI Entreprise de Taille Intermédiaire ETP Equivalent Temps Plein IaaS Infrastructure as a Service P2V Physical to Virtual PaaS Platform as a Service PCSI Plan de Continuité du Système d’Information PDMA Perte de Données Maximale Admissible PME Petites et Moyennes Entreprises PMI Petites et Moyennes Industries SaaS Software as a Service V2V Virtual to Virtual DEFINITIONS Salle blanche Il s’agit d’une infrastructure distante de type salle informatique dédiée et disponible en cas de déclenchement du plan de secours. En cas de déclenchement du plan de secours, l’entreprise vient intégralement « peupler » la salle blanche  : équipement informatique, données et applicatifs, personnel, etc. Salle miroir Il s’agit de salles pleinement redondantes par rapport à la salle à secourir. On entre dans le domaine de la haute disponibilité. C’est la solution la plus coûteuse, la plus fiable et la plus disponible. Salle rouge Il s’agit d’une salle blanche qui possède l’ensemble des équipements informatiques nécessaires au secours, maintenu en état de marche. Les données et applicatifs ne sont en revanche installés qu’en cas de déclenchement du plan de secours.
  • 21. FAUT-IL FAIRE LE GRAND SAUT DU DRaaS ? 19 BIBLIOGRAPHIE  DOCUMENTS ELECTRONIQUES Deronzier, E., (n.d.) Le monde du DRaaS, [Online] Available from : http://www.scoop.it/t/le-monde-du-DRaaS [Accessed 19/06/2013] Forrester Consulting, (2012), Cloud-Based Disaster Recovery Barriers and Drivers in the Enterprise, [Online] Available from : http://www-935.ibm.com/services/us/leveragingit/Cloud-Based-Disaster-Recovery-Barriers-AndDrivers-In-The-Enterprise.pdf [Accessed 19/06/2013] Kumar, S., Chaitanya, K, (n.d.) DRaaS –Start to Finish in 30 days, [Online] Available from : http://www.worldhostingdays.com/downloads/2012-india/hS2i2.pdf [Accessed 19/06/2013] Morency, J., (n.d.) Recovery as a Service – The Hype and the Reality [Online] Available from : http://fr.slideshare.net/gregorycc1/gartner-recovery-as-a-service-the-hype-and-the-reality [Accessed 19/06/2013] Rohan, (2013) Recovery-As-A-Service Market Worth $5.7 Billion by 2018 [Online] Available from : http://www.marketsandmarkets.com/PressReleases/recovery-as-a-service.asp [Accessed 19/06/2013] Wood,T., Cecchet, E., Ramakrishnan ,K., Shenoy, P.,Van der Merwe, J. & Venkataramani, A., (2010) Disaster Recovery as a Cloud Service : Economic Benefits & Deployment Challenges, [Online] Available from : http://static.usenix.org/event/hotCloud10/tech/full_papers/Wood.pdf [Accessed 19/06/2013] Ysosecure (n.d.) DRaaS, une solution de PRA dans le Cloud, [Online] Available from : http://www.ysosecure.com/PCA-PRA/DRaaS-disaster-recovery-as-a-service.html [Accessed 19/06/2013] IBM (2012) Virtualizing disaster recovery using Cloud computing, [Online] Available from : http://www-935.ibm.com/services/uk/en/it-services/vsr_whitepaper.pdf [Accessed 19/06/2013]  DOCUMENTS PAPIERS Allen, N., (2010) Cloud busting : Tackling virtual security risks, Continuity Magazine, 13, July/August 2010 Caicoya, S., Saury, J-G., (2011) Cloud Computing, Le guide complet, Paris, Micro Application Deronzier, E., Bennasar, M., Grept, P., (2013) Utiliser le Cloud pour manager son PRA et son PCA, CLUSIR Rhônes-Alpes, 17 Avril 2013 ENISA (2009) Cloud Computing, Benefits, risks and recommendations for information security EVault (2013) Reprise d’activité dans le Cloud : A la portée des PME Syntec Numérique (2010) LIVRE BLANC SÉCURITÉ DU CLOUD COMPUTING, Analyse des risques, réponses et bonnes pratiques Winkler, V., (2011) La sécurité dans le Cloud, Technique pour une informatique en nuage sécurisée [Securing the Cloud], Paris, Pearson Education
  • 22. 20 livre blanc | LE SECOURS DU SI DANS LE CLOUD QUELQUES MOTS SUR LEXSI Créé en 1999, LEXSI est un cabinet de conseil indépendant français spécialisé en sécurité informatique et gestion des risques. Axant sa stratégie sur l’innovation, sa singularité réside dans une alliance unique de technologies, de méthodes et de talents, pour préserver les intérêts de ses clients. Cabinet leader sur son marché, LEXSI est implanté à Paris, Lyon, Lille, Singapour et Montréal (Canada) et délivre ses prestations aussi bien en France qu’à l’international. Avec 170 experts à la pointe du secteur de la sécurité informatique, LEXSI intervient à travers 4 pôles de compétences :  Cybercrime : Veille technologique & lutte contre la fraude  Conseil  : Conseil en sécurité de l’information, gestion des risques, résilience et continuité d’activité  Audit : Audit des systèmes d’information  Université LEXSI : Formation SSI : Hacking, SMSI, sensibilisation, PCA LEXSI est le partenaire de plus de 600 clients dans des secteurs variés et stratégiques comme la banque, la finance ou encore l’industrie… LEXSI est la plus importante équipe CERT (Computer Emergency Response Team) accréditée en Europe et collabore activement avec la communauté internationale et les services de lutte contre la fraude.
  • 23. FAUT-IL FAIRE LE GRAND SAUT DU DRaaS ? LES AUTEURS Matthieu BENNASAR dirige le pôle Conseil de LEXSI à Lyon. Consultant en management des risques et sécurité de l’information depuis 15 ans, il a accompagné des clients de tous secteurs et toutes tailles dans la définition de leur plan de continuité d’activité ou du SI. Il est l’auteur de deux ouvrages de référence : « Plan de Continuité d’Activité et Système d’Information » (2006 et 2010, prix AFISI 2006), et « Manager la Sécurité du SI » (2007) tous deux publiés chez Dunod. Matthieu est diplômé de l’Ecole Centrale de Nantes et ancien élève de l’INSEAD. Il enseigne dans différents Masters et a obtenu les certifications MBCI et CISM. Vincent D’ADAMO est consultant en sécurité de l’information et continuité d’activité chez LEXSI. Il a participé à la conception et au test de plan de continuité du SI pour des entreprises du secteur bancaire, de l’assurance et de la santé. Vincent est issu d’un Master en Management et Stratégie des Systèmes d’Information obtenu à l’IAE de l’Université Lyon 3. Il est certifié ITIL Foundation V3. Létitia COMBES est consultante en sécurité de l’information et en continuité d’activité chez LEXSI. Elle a récemment mené une mission de mise en oeuvre d’un plan de continuité d’activité dans le domaine de la santé. En collaboration avec Matthieu, elle a publié un livre blanc sur la Sensibilisation à la Sécurité de l’Information 2.0. Létitia est diplômée de l’Ecole Centrale de Nantes et possède un Master en Management de l’Imperial College of London. En savoir plus : mbennasar[at]lexsi.com 21
  • 24. SIEGE SOCIAL Tours Mercuriales Ponant 40 rue Jean Jaurès 93170 Bagnolet TÉL. (+33) 01 55 86 88 88 FAX. (+33) 01 55 86 88 89 www.lexsi.fr LEXSI - INNOVATIVE SECURITY PARIS, LYON, LILLE, MONTREAL, SINGAPOUR