le secours du si dans le cloud

LIVRE BLANC

Le secours du SI dans le CloudFaut-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

Par Matthieu BennasarVincent D’AdamoLétitia Combes

Le secours du SI dans le CloudFaut-il faire le grand saut du DRaaS ?

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.

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

B/ Phase d’exploitation

C/ Phase de sinistre

D/ Fin de contrat

R1 : Impossibilité d’intégration des architectures spécifiques 2

R2 : Perte de confidentialité des informations dans le Cloud 1 2 2

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

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 :

Réorganiser les compétences SI

Gérer la supervision du dispositif DRaaS

Faire des économies Faciliter l'accès aux tests Donner de la flexibilité Garantir un temps de reprise à budget constant Faciliter l'automatisation

Taille Criticité des données

Délais de reprise Volumétrie / "Dynamisme" des données

Niveau de standardisation de l'architecture

NÉCESSITE DE PERMET DE

DRaaS

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 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 inves-tissement majeur – entendez dispendieux - qui est rarement en tête des priorités.

Du côté des équipes SI aussi, on rechigne à envis-ager 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.

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 Enterprise5 HeraldOnline, (2013) Recovery-As-A-Service Market Worth $5.7 Billion by 2018

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 incontourna-bles à 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. »

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 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é.

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).

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é.

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 utili-sateurs 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 favori-sées par rapport à un site alternatif dans la limite des

Utilisateurs

AVANT

APRÈS

serveurs virtuels éteints

serveurs virtuels allumés

serveur actif

Salle principale

Salle principale

SINISTRÉE

Réplication

synchrone ou

asynchrone

Utilisateurs


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.

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éces-saires. 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.

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 condi-tions 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

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 challenges10 Equivalent Temps Plein

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.

FACILITER L’ACCES AUX TESTS

Les tests peuvent être mis en oeuvre avec un coût limité sans impacter la production. Dans les solutions tradi-tionnelles, 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

COûT DE L’INFRASTRUCTURE

TEMPS

Coût d’un site de secours traditionnel

Coût solution DRaaS

Economies liées au DRaaS

Surcoût liés au DRaaS

Test Test Test Secours

Figure 2 : Un modèle de coût différentSource : Deronzier, E., Bennasar, M., Grept, P. (2013)

année 1 année 2


Grâce au Cloud, les coûts d’infrastructure sont unique-ment liés à l’activation des serveurs de secours12 (voir Figure 2 : Un modèle de coût différent). Ainsi, la réalisa-tion 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 construc-tion que le Cloud est avantageux du fait de son modèle économique, de ses technologies et de ses fonction-nalité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é.

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.

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éali-sé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 super-vision 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.


REORGANISER LES COMPETENCES DES EQUIPES SI

Si les compétences techniques nécessaires à l’exploitation de la plateforme de secours sont grande-ment 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, surveil-lance 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 : externalisa-tion 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 perfor-mance, 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.

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 entre-prises, 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 entre-prises 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 entre-prises de taille moyenne, nous considérons que c’est aussi une opportunité pour les petites entre-prises 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 ?

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

Réduction des charges d'activation du secours après sinistre

Facilité d'activation

Facilité d'accès aux tests

Facilité de maintenance

Facilité de mise en oeuvre du PCI

3

2

1

0

Externalisation dans le CloudSalle 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


de chiffrement, d’authentification, etc. Malgré ces mesures de protection, la crainte de perte de confiden-tialité 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.

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.

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ême-ment é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.

17 Voir glossaire page 18.

dernière sauvegarde sinistre

Déclenchement PCSI Bascule Retour à la normale

Temps écoulé

PDMA DMIA

Figure 4 : Illustration du PDMIA et du DMIA


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 fonctionne-ment de l’ensemble des fonctions répliquées (en cas de sinistre ou de test). En d’autres termes, si la répli-cation 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 à évolu-tion 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épli-cation 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épli-cation 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.

€

10K

€€

50K

€€€

100K

€€€€

300K

TEMPS

Sinistre T0

Opt

imum

seconde

semaine

Classe 1

Classe 2

Classe 3

Classe 4Réplication sur bandes

Salle blanche

Salle miroir

CLASSE 22h ≤ DMIA < 8h

1 ≤ PDMA < 5h

CLASSE 38 ≤ DMIA < 24h

5h ≤ PDMA < 24h

CLASSE 424h ≤ DMIA < 1 sem

24h ≤ PDMA < 1 sem

CLASSE 10 ≤ DMIA < 2h

0 ≤ PDMA < 1h

Figure 5 : Utilisation optimum du DRaaS

Salle rouge

Draas


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.

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.



TEMPS

TEMPS



Cas 1Peu de données dynamiques

Cas 2Beaucoup de données dynamiques

Cas 1Moyenne sur l’année

Cas 2Moyenne sur l’année

Test

Test

Test

Test

Test

Test

Secours

Secours

Figure 6 : Coût du DRaaS cas 1

Figure 8 : Cas d’utilisation optimale du DRaaS en fonction de la volumétrie et du dynamisme des données

Figure 7 : Coût du DRaaS cas 2

Faible Moyen Important TrèsImportant

VOLUMÉTRIE ET DYNAMISME DES DONNÉES

TEMPSD

MIA

/ P

DM

A

seconde

semaine

Classe 1

Classe 2

Classe 3

Classe 4

CLASSE 1 CLASSE 2 CLASSE 3 CLASSE 40 ≤ 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

année 1 année 2


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 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.

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 diffi-cile voire impossible de trouver une solution compat-ible. 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éali-sation 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.

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.).

22 P2V pour Physical to Virtual et V2V pour Virtual to Virtual. Ces solutions permettent de s’affranchir du type d’outil utilisé.


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 !

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 princi-pales 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éma-tiques 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

Taille Criticité des données DMIA/PDMA Volumétrie,

dynamismeType d'application ou d'architecture

PME/PMI Données peu sensibles

0 ≤ DMIA < 2h0 ≤ PDMA < 1h Faible Standard

ETI Données sensibles 2h ≤ DMIA < 8h1h ≤ PDMA < 5h Moyen Spécifique

Grande entreprise Données soumises à audit

8h≤ DMIA5h ≤ PDMA Important Très spécifique

Figure 9 : Synthèse - Est-ce pour moi ?


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

peut se produire en phase d’exploitation ou en cas de sinistre. Dans le premier cas, l’impact est relative-ment 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.

3

2

1

4

1 2 3 4 IMPACT

PROBABILITÉ

R4b R2b

R2a

R5b R7d

R6c

R8b

R2d R8c

R3c

R1a

R6b

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 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 R7 : Impossibilité de récupérer les données

R8b R8c R8 : Perte de gouvernance

Figure 10 : Cartographie des risques


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

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.

Audit de l'existant

Intégration des tests à l'offre et tarification as-

sociées

Compatibilité du débit des dif-

férents sites

Probléma-tique d'intégration

des progiciels

Conformité du prestataire

Conformité pour les besoins

clients

Transparence du prestataire sur ses incidents de sécurité

INTÉGRATION CONFORMITÉ

STRATÉGIE

Modèle de Cloud

Zone d'hébergement

CONFIDENTIALITÉ

Possibilité d'utilisation du

DRaaS

CONFIGURATION

Adaptation de l'infrastructure

existante

Pérennité du prestataire

Distance du lieu

d'hébergement

Plan de réversibilité

DISPONIBILITÉ

Gestion de secours de client

simultanés

Convention de niveau de ser-

vices (SLA)

Sécurité logique et physique

SÉCURITÉ

Niveau de sécurité

par défaut

Sécurisation de l'accès au SI secouru dans le

Cloud

Transparence du prestataire sur sa

stratégie interne

Figure 11 : Synthèse des points de passage pour réussir son PCA dans le Cloud

Sécurité des données

transférés et des flux échangées


ANNEXES

ANNEXE 1 : ECHELLES D’IMPACT ET DE PROBABILITE UTILISEES LORS DE L’ANALYSE DE RISQUES

NIVEAU D’IMPACT 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)

2

Moyen

Perturbe notablement le déroule-ment des activités de l'entreprise pendant une durée supérieure à une journée.

3

Grave

Perturbe considérablement le dérou-lement des activités de l'entreprise pendant une durée supérieure à 2 semaines.

4

Critique

Met en danger la survie de l'entre-prise en raison de perte financière, d’image, ou de désorganisation majeure.

NIVEAU DE PROBABILITÉ COMMENTAIRES

1

Exceptionnel

Situation possible mais peu de cas rencontrés. Survenance : occur-rence possible sur une période d’une dizaine d’années

2

Peu probable

Situation rare. Survenance : Occurrence sur une durée d’environ 4 ans

3

Plausible

Situation rencontrée assez fréquemment. Survenance : Annuelle

4

Quasi certainSituation très probable.Survenance : Plusieurs fois par an

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 conti-nuité 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 entre-prise 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 infra-structures 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…


4b

Litiges juridiques dus à des non conformités

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.

En phase d’exploita-tion

Poursuites juridiques causant des pertes finan-cières et une dégradation de l’image

2 2 non

5bNon-respect de la réglementation

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 notam-ment pour l’hébergement des données de santé ou pour le standard PCI DSS.


Sanctions juridiques Mauvaise image Perte de contrat

2 2 non

6b Perte des données ou de l’intégrité des données 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.


Désorganisation impor-tante si perte d’intégrité détectée tardivement

2 1 non

6c En cas de sinistre

Impossibilité de secourir tout ou partie du SI Erreurs dans les données/ systèmes secourus

3 1 oui

7dImpossibilité de récupérer les données

Cela peut être lié au risque R3 : si le prestataire est indis-ponible, 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.

En fin de contrat Perte de données 3 2 oui

8bPerte de gouvernance

On constate fréquemment un empilement incontrôlé des sous-traitants ce qui entraine une perte de maîtrise pour le client.


Perte de gouvernance en cas de manque de visibilité sur la gestion des données

3 3 non

8c En cas de sinistre

Perte de gouvernance impliquant une perte de maitrise de la reprise

4 3 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 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.

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ÉNARIOPhase

du projetConséquences

1a

Impossibilité d’intégration des archi-tectures spécifiques

Une mauvaise estimation des difficultés en début de projet (application personnalisée, architecture d’infrastruc-ture atypique non prise en compte, architecture réseau, etc.) peut mettre celui-ci en défaut.

En phase d’étude

Echec du projet Impossibilité d’implé-menter le DRaaS pour une partie de l’architecture

3 3 oui

2aPerte de confi-dentialité des informations dans le Cloud

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 confiden-tielles s’assurent que les prestataires chiffrent bien les données qui leur sont confiées23.

En phase d’étude

Dégradation de l’image de l’entreprise qui peut avoir un impact économique Poursuites juridiques Divulgation d’informations confidentielles

3 1

non

2bEn phase d’exploita-

tion3 2

2d En fin de contrat 3 3

3c

Impossibilité du prestataire à 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.

En cas de sinistre

Secours impossible Faillite potentielle de l’entreprise

4 2 oui

Impa

ct

Prob

abili

té

Jurid

ique

Fina

ncie

r

Opér

atio

nnel

Imag

e

Impa

ct s

ur la

re

pris

e


ANNEXE 3 : CHECKLIST DES POINTS DE PASSAGE POUR CHOISIR SON PRESTATAIRE ET REUSSIR SON PCSI DANS LE CLOUD

THÈMES N° POINTS DE PASSAGE DÉTAILS

1Audit 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 assure-rait que le DRaaS est adaptable à tout sans chercher à connaître votre architecture en détail.

2

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é.

3Adaptation 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.

5Problé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.

6Conformité 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.

7Conformité

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.

8Modèle de

Cloud

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).

9Zone

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é.

10Pé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.

11Distance 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.).

12Convention

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.

25 ENISA (2009) Cloud Computing, Benefits, risks and recommendations for information security ; Cloud Security Alliance : Cloud

Controls Matrix V1.426 Plus de détails sur les normes dans le guide du Cloud Computing 2013 publié par la CIGREF-IFACI et AFAI

INTE

GR

ATIO

NC

ON

FOR

MIT

EC

ON

FID

EN

TIA

LITE

DIS

PO

NIB

ILIT

E


THÈMES N° POINTS DE PASSAGE DÉTAILS

13Gestion 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.

14Plan 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.

15Possibilité

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.

16Niveau 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é.

17Sécurité logique

et physique

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.

18

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

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.

20Transparence 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.

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.

DIS

PO

NIB

ILIT

ECO

NFI

GU

RAT

ION

SE

CU

RIT

ES

TRAT

EG

IE


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 dispo-nible 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 miroirIl 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 rougeIl 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.


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-And-Drivers-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 pratiquesWinkler, V., (2011) La sécurité dans le Cloud, Technique pour une informatique en nuage sécurisée [Securing the Cloud], Paris, Pearson Education


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é informa-tique, 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, sensibilisa-tion, 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.


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

SIEGE SOCIALTours Mercuriales Ponant40 rue Jean Jaurès93170 Bagnolet

TÉL. (+33) 01 55 86 88 88FAX. (+33) 01 55 86 88 89

www.lexsi.fr

LEXSI - INNOVATIVE SECURITYPARIS, LYON, LILLE, MONTREAL, SINGAPOUR