LIVRE BLANC - LE SECOURS DU SI DANS LE CLOUD / PAR MATTHIEU BENNASAR, VINCENT D'ADAMO & LÉTITIA COMBES

Transcription

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? Les changements apportés par le DRaaS sont d ordre technique, organisationnel et financier : LE DRaaS : EST-CE POUR MOI? 5 critères permettent de statuer sur l opportunité d un secours du SI dans le Cloud : NÉCESSITE DE Réorganiser les compétences SI DRaaS Gérer la supervision du dispositif DRaaS PERMET DE Faire des économies Faciliter l'accès aux tests Donner de la flexibilité Garantir un temps de reprise à budget constant Faciliter l'automatisation Taille Délais de reprise Niveau de standardisation de l'architecture Criticité des données Volumétrie / "Dynamisme" des données 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 2 B/ Phase d exploitation C/ Phase de sinistre R2 : Perte de confidentialité des informations dans le Cloud R3 : Impossibilité du prestataire à assurer le service 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 2 R8 : Perte de gouvernance 2 3 D/ Fin de contrat

4 2 livre blanc LE SECOURS DU SI DANS LE CLOUD 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 entreprises 2. Alors même que ces PME sont plus sensibles aux sinistres que les grandes entreprises 3, 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 entreprises 4. 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 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.» 1 2 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

5 FAUT-IL FAIRE LE GRAND SAUT DU DRaaS? 3 Le DRaaS, pour Disaster Recovery as a Service, créé dans la lignée des SaaS, PaaS et IaaS 6, s appuie sur le Cloud Computing pour proposer des offres intégrées de secours du SI 7. 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. 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é. Salle principale AVANT Réplication synchrone ou asynchrone serveur actif serveurs virtuels éteints 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é. Utilisateurs Salle principale SINISTRÉE Utilisateurs APRÈS serveurs virtuels allumés 6 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). 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,02ETP 11 (1h/sem). Cela permet une réorganisation des compétences pour se concentrer sur les activités à forte valeur ajoutée. Les avantages du 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 économies 9 par rapport à une solution classique. Coût solution DRaaS Economies liées au DRaaS Coût de l infrastructure Coût d un site de secours traditionnel Surcoût liés au DRaaS 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,12ETP 10 (5h/sem environ) à l entretien d une solution de reprise traditionnelle en interne 9 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 Test Test Test Secours année 1 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 TEMPS 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. 11 EVault (2013) Reprise d activité dans le Cloud : A la portée des PME

7 FAUT-IL FAIRE LE GRAND SAUT DU DRaaS? 5 Grâce au Cloud, les coûts d infrastructure sont uniquement liés à l activation des serveurs de secours 12 (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. 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é. 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 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. 12 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.

8 6 livre blanc LE SECOURS DU SI DANS LE CLOUD REORGANISER LES COMPETENCES DES EQUIPES SI 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. Facilité d'activation Réduction des charges d'activation du secours après sinistre Facilité de mise en oeuvre du PCI 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. 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. Facilité d'accès aux tests 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 MES DONNEES ONT-ELLES UN NIVEAU DE CRITICITE APPROPRIE 13? 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, 13 Attention, le contenu de ce paragraphe n est pas spécifique au DRaaS, mais s applique à toute problématique Cloud

9 FAUT-IL FAIRE LE GRAND SAUT DU DRaaS? 7 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 sensibles 14. 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 sensibles 16. 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 DMIA 17. 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 Bascule Retour à la normale dernière sauvegarde sinistre Temps écoulé PDMA DMIA Figure 4 : Illustration du PDMIA et du DMIA 14 De type secret-défense par exemple. 15 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. 17 Voir glossaire page 18.

10 8 livre blanc LE SECOURS DU SI DANS LE CLOUD TEMPS Classe 1 0 DMIA < 2h seconde Sinistre T0 Classe 1 Salle miroir 0 PDMA < 1h Classe 2 2h DMIA < 8h 1 PDMA < 5h Classe 2 Optimum DRaaS Salle rouge Classe 3 8 DMIA < 24h 5h PDMA < 24h Classe 3 Salle blanche Classe 4 24h DMIA < 1 sem Classe 4 Réplication sur bandes 24h PDMA < 1 sem 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. 18 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 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? 9 Coût d un site de secours traditionnel Coût de l infrastructure Cas 1 Peu de données dynamiques Cas 1 Moyenne sur l année L utilisation du DRaaS peut néanmoins rester attrayante dans les cas où le PDMA peut être affaibli 19 et associé à d autres solutions de type déduplication 20. 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. Test Test Test Secours année 1 année 2 TEMPS seconde TEMPS Figure 6 : Coût du DRaaS cas 1 Classe 1 Coût d un site de secours traditionnel Cas 2 Beaucoup de données dynamiques DMIA / PDMA Classe 2 Classe 3 Coût de l infrastructure Cas 2 Moyenne sur l année Classe 4 semaine Faible Moyen Important Très Important VOLUMÉTRIE ET DYNAMISME DES DONNÉES Classe 1 Classe 2 Classe 3 Classe 4 0 DMIA < 2h 2h DMIA < 8h 8 DMIA < 24h 24h DMIA < 1 sem 0 PDMA < 1h 1 PDMA < 5h 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 19 Synchronisation toutes les heures par exemple. 20 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.

12 10 livre blanc LE SECOURS DU SI DANS LE CLOUD POINT D ATTENTION 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 passante 21. 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. 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. 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. 21 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. 22 P2V pour Physical to Virtual et V2V pour Virtual to Virtual. Ces solutions permettent de s affranchir du type d outil utilisé.

13 FAUT-IL FAIRE LE GRAND SAUT DU DRaaS? 11 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 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, exploitation, 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 3 R1a R2d R8b R8c 2 R4b R5b R2b R7d R3c 1 R6b R2a R6c impact A/ Phase d'étude B/ Phase d'exploitation C/ Phase de sinistre D/ Fin de contrat Risques R1a R1 : Impossibilité d intégration des architectures spécifiques R2a R2b R2d R2 : Perte de confidentialité des informations dans le Cloud R3c R3 : Impossibilité du prestataire à assurer le service R4b R5b R4 : Litiges juridiques dus à des non-conformités 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 R7 : Impossibilité de récupérer les données R8b R8c 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? 13 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 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 CONFORMITÉ Audit de l'existant Intégration des tests à l'offre et tarification associées Adaptation de l'infrastructure existante Compatibilité du débit des différents sites Problématique d'intégration des progiciels Conformité du prestataire Conformité pour les besoins clients CONFIDENTIALITÉ DISPONIBILITÉ Modèle de Cloud Zone d'hébergement Pérennité du prestataire Distance du lieu d'hébergement Convention de niveau de services (SLA) Gestion de secours de client simultanés Plan de réversibilité CONFIGURATION SÉCURITÉ Possibilité d'utilisation du DRaaS Sécurité logique et physique Sécurité des données transférés et des flux échangées Sécurisation de l'accès au SI secouru dans le 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 Commentaires Niveau de PROBABILITÉ Commentaires 1 Faible 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. 1 Exceptionnel 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 2 Moyen 3 Grave 4 Critique 2 Peu probable 3 Plausible 4 Quasi certain 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 fin de contrat). Nous détaillons dans le tableau ci-dessous uniquement les phases projet les plus pertinentes. N Risque SCÉNARIO 1a 4b 5b 6b 6c 7d 8b 8c Impossibilité d intégration des architectures spécifiques 2a Perte de confidentialité des 2b informations dans le Cloud 2d 3c Impossibilité du prestataire à assurer le service Litiges juridiques dus à des non conformités Non-respect de la réglementation Perte des données ou de l intégrité des données répliquées dans le Cloud Impossibilité de récupérer les données Perte de gouvernance Une mauvaise estimation des difficultés en début de projet (application personnalisée, architecture d infrastructure atypique non prise en compte, architecture réseau, etc.) peut mettre celui-ci en défaut. Les causes sont nombreuses: absence d isolement des environnements, usurpation, intrusion dans les locaux, absence de chiffrement, etc. PricewaterhouseCoopers souligne que seulement 17% des entreprises ayant des données hautement confidentielles s assurent que les prestataires chiffrent bien les données qui leur sont confiées 23. 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 à : Des données hébergées dans des Cloud au sein des pays dans lesquels la protection et le traitement des données n est pas approprié 24. Une perte de traçabilité des données dans le Cloud. Différentes réglementations peuvent s appliquer aux données hébergées chez le prestataire DRaaS. En cas de non-respect de ces réglementations, des sanctions juridiques et financières peuvent être prononcées notamment pour l hébergement des données de santé ou pour le standard PCI DSS. 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. Cela peut être lié au risque R3 : si le prestataire est indisponible, il est impossible d accéder aux données (pour migrer vers un nouveau prestataire par exemple). Cette menace peut aussi se réaliser dans le cadre d un conflit avec le prestataire. On constate fréquemment un empilement incontrôlé des sous-traitants ce qui entraine une perte de maîtrise pour le client. Phase du projet En phase d étude En phase d étude En phase d exploitation En fin de contrat En cas de sinistre En phase d exploitation En phase d exploitation En phase d exploitation En cas de sinistre En fin de contrat En phase d exploitation En cas de sinistre Conséquences Echec du projet Impossibilité d implémenter le DRaaS pour une partie de l architecture Dégradation de l image de l entreprise qui peut avoir un impact économique Poursuites juridiques Divulgation d informations confidentielles Secours impossible Faillite potentielle de l entreprise Poursuites juridiques causant des pertes financières et une dégradation de l image Sanctions juridiques Mauvaise image Perte de contrat Désorganisation importante si perte d intégrité détectée tardivement Impossibilité de secourir tout ou partie du SI Erreurs dans les données / systèmes secourus 2 2 non 2 2 non 2 1 non 3 1 oui Perte de données 3 2 oui Perte de gouvernance en cas de manque de visibilité sur la gestion des données Perte de gouvernance impliquant une perte de maitrise de la reprise Impact Probabilité 3 3 oui 3 1 Impact sur la reprise 3 2 non 3 3 non 4 3 oui Juridique Financier Opérationnel Image oui 23 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 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.

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 THÈMES N 1 2 DISPONIBILITE CONFIDENTIALITE CONFORMITE INTEGRATION Points de passage Audit de l existant Intégration des tests à l offre et tarification associée Adaptation de l infrastructure existante Compatibilité du débit réseau des différents sites Problématique d intégration des progiciels Conformité du prestataire Conformité pour les besoins clients Modèle de Cloud Zone d hébergement Pérennité du prestataire Distance du lieu d hébergement Convention de niveau de services (SLA) Détails 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. 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é. 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. 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. 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. 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 analyse 25 des solutions de Cloud en général. 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. 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). 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é. 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. 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.). 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. 25 ENISA (2009) Cloud Computing, Benefits, risks and recommendations for information security ; Cloud Security Alliance : Cloud Controls Matrix V 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? 17 THÈMES N STRATEGIE SECURITE CONFIGURATION DISPONIBILITE Points de passage Gestion des secours de clients simultanés Plan de réversibilité Possibilité d utilisation du DRaaS Niveau de sécurité par défaut Sécurité logique et physique Sécurité des données transférées et des flux échangés Sécurisation de l accès au SI secouru dans le Cloud Transparence du prestataire sur sa stratégie interne Transparence du prestataire sur ses incidents de sécurité Détails 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. 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. 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. 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é. 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. 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 homomorphique 27. Aucune solution prête à l emploi n existe aujourd hui. 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. 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 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.). 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. 27 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 DRaaS ETI ETP IaaS P2V PaaS PCSI PDMA PME PMI SaaS V2V Durée Maximale d Interruption Admissible Disaster Recovery as a Service Entreprise de Taille Intermédiaire Equivalent Temps Plein Infrastructure as a Service Physical to Virtual Platform as a Service Plan de Continuité du Système d Information Perte de Données Maximale Admissible Petites et Moyennes Entreprises Petites et Moyennes Industries Software as a Service 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.