L i VRE BLANC
Juin 2014
L’OBSERVATOIRE
des Directeurs d’Infrastructures et de Production
CLOUD COMPUTING 5
Accompagnement du changement Equilibre financier du Cloud
Sécurité : l’effet Prism Cloud et PRA
SaaS : cas d’usages Clouds hybrides
Groupe de Travail Cloud Computing
Pilotes : Stéphane Geissel et Stéphane Lafon Coordination : Philippe Roux, Pierre Mangin
Club des Responsables
d’Infrastructures et de Production
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
Table
matières des
REMERCIEMENTS 4 EDITORIAL 5 1 L’ACCOMPAGNEMENT AU ChANGEMENT DANS LES PROJETS CLOUD 6
1 -Problématiques accompagnement au changement : témoignages de Generali, Air France… 6
2- Accompagnement au niveau global 7
3- Accompagnement au niveau local 9
2 EqUILIBRE fINANCIER DU CLOUD 12
La vie du Catalogue de services 13
Le budget du Cloud 14
3 SéCURITé : L’EffET PRISM / NSA 20
La mutualisation et ses conséquences en matière d’étanchéité 21
La classification des données par ordre de sensibilité 22
L’ affaire Prism / NSA : l’électrochoc de l’été 2013 23
Conséquences de l’affaire PRISM / NSA 25
Réglementations nationales ou communautaires, et chiffrement 26
Chiffrement : les limites 27
Les clauses de ‘risk assessment’ 28
Des réserves sur la Messagerie dans le Cloud 28
Clouds souverains, Numergy et Cloudwatt, et position de l’Administration 29
4 CLOUD, PRA ET CONTINUITé D’ACTIVITé 33
Virtualisation et PRA 33
Cloud et Virtualisation 34
DRaaS : mythes et limites 34
Le DRaaS est-il identique pour le IaaS, le PaaS et le SaaS ? 36
PRA dans le cadre d’un Cloud Privé 37
Le PRA d’une application dans le Cloud 38
Les améliorations attendues avec le Cloud hybride 39
5 SAAS : LES CAS D’USAGES 40
Se poser les bonnes questions au bon moment 40
La connectivité et l’intégration par les interfaces 43
Quel modèle financier ? 44
La gestion au quotidien et l’amélioration continue 45
6 LES CLOUDS hyBRIDES : DéfINITIONS ET SCéNARIOS 48
Définition du Cloud hybride 48
Typologies et Usages 49
Les scénarios de mise en œuvre d’un Cloud hybride 52
Exemples de mise en œuvre de solutions hybride 53
Défis et points de vigilance 54
Performances réseau 55
Compatibilité des applications 56
7 EN CONCLUSION 58
L i VRE BLANC
Remerciements
Nous remercions vivement tous les participants du Groupe de Travail Cloud computing du CRiP qui ont contribué à ce 5ème Livre blanc et, en particulier, ceux qui ont rédigé. Leur témoignage, leurs retours d’expérience, leur questionnement et leurs discussions, traduisant des prises de position parfois divergentes, ont permis d’enrichir et d’objectiver le contenu de ce document de travail collégial.
Stéphane Lafon SANOFI (pilote du Groupe de Travail)
Stéphane Geissel SFR (pilote du Groupe de Travail)
Catherine Aldebert AIR FRANCE
Françoise Bariset EDF
Cyril Bartolo LAGARDERE RESSOURCES
Antoine Cao DISIC
Laurent De Berti VOLVO IT
Joël De Amorin ERAMET
Marc Demerlé GDF SUEZ
Denis Descamps RE:SOURCES
Alain Hutié EDF
Alain Merle MINISTERE DE L’ECOLOGIE & DEVELOPPEMENT DURABLE
Kathleen Milsted ORANGE
Michel Raulet PSA PEUGEOT CITROEN
Alain Roy GENERALI
Jacques Witkowski CRiP
Ce Livre blanc a été réalisé avec la contribution éditoriale de Philippe Roux (chef de projet, CRiP) et Pierre Mangin (directeur des études du CRiP).
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
Pilotes du Groupe de Travail Cloud Computing du CRiP
Le Cloud continue d’être un sujet d’intérêt pour l’ensemble des entreprises, ce qui explique ce 5ème Livre Blanc. La maturité des entreprises d’un côté, des solutions techniques de l’autre proposent de nouvelles pistes d’exploration et de mise en pratique.
Ce livre blanc est le résultat des travaux menés par le Groupe de Travail Cloud Computing au sein du CRiP tout au long de la saison 2013- 2014.
Six thèmes sont développés dans cette édition 2014 :
1- Accompagnement du changement
Comme pour tout projet structurant dans l’entreprise, la réussite d’un projet Cloud ne tient pas uniquement à l’excellence technique de son déploiement. Il faut « marketer » le projet en interne, former les équipes et les utilisateurs, faire évoluer les compétences et les organisations.
2- Equilibre financier du Cloud
S’il est porteur de souplesse grâce au paiement à l’usage, le Cloud pose de nouvelles difficultés de prévisions financières à la DSI. Le calcul et le respect d’un budget, nécessitent de bien estimer le montant des OPEX liés au Cloud. Comment le faire au mieux, cela dépend du modèle de déploiement du Cloud au sein de l’entreprise.
3- Sécurité
Après les révélations très médiatisées de l’été 2013 sur les méthodes de la NSA américaine et l’application du Patriot Act, les projets de déploiement sur Cloud public ont été mis à mal – s’agissant notamment de la messagerie sur le Cloud. On assiste depuis quelques mois à
un durcissement sécuritaire et à une adoption plus rigoureuse de la réglementation. Les so- lutions de sécurisation existent – chiffrement, classement sur la sensibilité des données. Le Cloud souverain est une alternative à étudier.
Mais tout n’est pas résolu pour autant.
4- Utilisation du Cloud pour le PRA
Le PRA peut-il bénéficier des avantages du Cloud, en réduire ainsi ses coûts ? Divers fournisseurs proposent des prestations de DRaaS (pour Disaster Recovery as a Service).
Mais le Cloud est-il la réponse universelle aux contraintes spécifiques d’un PRA ? Le livre blanc examine quelques scénarios.
5- SaaS
La décision de recourir à des solutions SaaS pose les questions de localisation des données, d’interfaçage avec les données de l’entreprise et de gouvernance. Souvent déployées pour (et parfois par) des Directions Métiers, l’irruption de solutions SaaS demande à la DSI de traiter de nouveaux périmètres, de nouveaux enjeux.
Comment faire ? 6- Clouds hybrides
Incontestablement, c’est le sujet dont on parle en 2014. Quelle est la maturité des solutions techniques ? Dans quels cas d’usage est-il per- tinent ? Quelles sont les difficultés potentielles de mise en œuvre ? Nous essayons d’apporter quelques réponses.
Nous espérons que ce 5ème livre blanc appor- tera des éléments à vos réflexions sur ce vaste sujet du Cloud.
Edito rial
Stéphane LAfON SANOfI Stéphane GEISSEL
SfR
1 L’ACCOMPAGNEMENT AU ChANGEMENT DANS LES PROJETS CLOUD
A retenir:
Beaucoup de personnes voient le Cloud comme une facilité offerte à tous, particuliers ou entreprises, à se dégager des problématiques de gestion des infrastructures : le Cloud s’occupe de cela pour nous, il y a bien des logiciels qui font cela pour nous, il y a bien des infrastructures qui hébergent nos applications ou nos données...
C’est trop vite oublier d’où l’on vient et sous-estimer que l’infrastructure et les logiciels ne sont rien sans organisation ni processus !
Mise en œuvre : les bonnes questions
Quels sont les impacts sur les organisations, les processus de nos entreprises et les compétences ?
Quelles sont les mesures d’accompagnement au changement à mettre en place pour passer dans le monde du Cloud sans écueil ?
Ces questions doivent être traitées comme une réponse au risque humain sous- jacent à ce genre de projet qui touche à la fois l’organisation et les hommes.
1 - Problématiques accompagnement au changement : témoignages de Generali, Air France…
Voici, à titre indicatif, les questions que Generali s’est posées : Qui, quoi, combien, comment ?
Who are the customers ?
What are their needs (sandbox…) ? How many annual demands ?
Il est en effet primordial de s’intéresser aux besoins des utilisateurs, d’identifier les apports que le Cloud pourrait pourvoir. Chez Generali, le Cloud peut en effet permettre de proposer aux développeurs de créer eux-mêmes des environnements bac à sable. Il faudra également prioriser les offres en fonction de la fréquence d’utilisation.
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
What does the customer do to get his environments ? What’s the process validation ?
Who pays ?
Si la livraison des environnements est beaucoup plus rapide grâce au Cloud, il ne faut pas que des étapes de validation mal calibrées viennent annihiler ces bénéfices.
Par exemple, comme chez Generali, pour éviter la prolifération d’environnements bac à sable mais ne pas introduire d’étape de validation manuelle, la mise en place de quotas est une réponse simple et automatique.
Le Cloud introduit des notions de paiement à l’usage.
What is the billing process ?
L’ensemble des processus étant à revoir, l’ensemble des acteurs qui seront de près ou de loin impliqués doivent participer au projet dès son lancement pour que leurs besoins soient pris en compte et pour qu’ils y adhèrent.
Membership Participation ASAP Training
L’accompagnement
Ce chapitre zoome sur la partie accompagnement à mettre en place.
L’accompagnement au changement et la communication se situent à 2 niveaux
• au niveau global (entreprise)
• au niveau local (les équipes)
2- Accompagnement au niveau global
Comme vu en préambule, le Cloud dépasse largement le cadre de l’ingénierie système. Comment peut-on « entraîner » l’entreprise vers le monde du Cloud ? Comment évaluer les améliorations apportées par le Cloud ?
Le Cloud doit apporter aux utilisateurs une plus grande agilité, une meilleure réactivité et une meilleure qualité des environnements provisionnés. Plutôt que d’autoproclamer que le Cloud a permis d’améliorer les choses, Generali a décidé de lancer une enquête de satisfaction concernant le ressenti sur la mise à disposition des environnements infrastructure (IaaS voire PaaS) afin de mesurer réellement la satisfaction des utilisateurs du Cloud.
Cette enquête est une enquête miroir qui est réalisée en deux temps. Miroir car effectuée à la fois auprès des clients des environnements et auprès des fournisseurs de ces environnements. En deux temps car l’objectif étant de mesurer concrètement les apports du Cloud auprès des utilisateurs de celui-ci, le sondage est effectué une première fois avant la mise à disposition du Cloud pour faire un état des lieux, confirmer les axes d’amélioration attendus et une seconde fois lorsque le Cloud sera largement utilisé.
40 utilisateurs ont répondu à l’enquête de satisfaction. Les principaux enseignements et donc enjeux du Cloud sont confirmés par les utilisateurs eux-mêmes. Cette enquête a en effet montré des insatisfactions quant aux délais de livraison des environnements, à la qualité de ceux-ci et à l’absence de visibilité sur l’offre de services. L’atteinte ou non de l’objectif ne sera pas auto proclamée par un juge de paix mais prononcée (ou non) par les utilisateurs eux-mêmes.
Bien que le périmètre soit bien spécifié, un des écueils potentiels de cette enquête est que les utilisateurs ne limitent pas leur appréciation aux seules parties « infrastructure » prises en charge par le Cloud et englobent d’autres actions nécessaires à la livraison des environnements applicatifs complets.
La communication
Autre point, comme tout projet de transformation, il est important de donner un nom au projet, de lui associer un logo.
Air France a constaté toute l’importance de créer un logo : « cela permet de porter une identité forte, de susciter l’adhésion au projet ». Generali a également donné un nom fort au projet et a créé un logo associant le lion Generali à un nuage bordeaux représentant le Cloud.
La DISIC a également donné des noms aux projets Cloud « G Cloud » et « Open G Cloud ».
Afin de démystifier le Cloud et partager les impacts sur la transformation à la fois des processus et des métiers, Generali a organisé dans un premier temps des forums ouverts aux personnes de la production informatique et l’étendra aux collaborateurs des directions Etudes dans un second temps. En effet le Cloud permettra aux études informatiques de provisionner des environnements bac à sable en mode self-service. La DISIC a également organisé des présentations aux acteurs de la sphère numérique, des directions métier, et y ont associé un spécialiste de la communication. De même, Air France s’est lancé ces derniers mois dans une communication vers les différentes directions métiers et techniques afin de promouvoir les services et catalogues proposés.
De son côté Re-Source (Publicis) a dû faire tout un travail de marketing autour du Cloud puisque ses clients sont les développeurs des différentes agences ou entités du groupe. Il était important de prendre en compte leurs besoins afin d’éviter leur évasion vers des solutions de Cloud public telles que Amazon. Le Cloud a ainsi été présenté de manière différente afin de sensibiliser des populations non technophiles.
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
3- Accompagnement au niveau local
Une démarche participative :
Le Cloud permettant d’offrir de nouveaux services, il est primordial de bien cerner les besoins que le Cloud peut satisfaire. Publicis a ainsi, dès le lancement du projet, impliqué les différents métiers pour intégrer leur processus au sein du cahier des charges. Afin d’obtenir une bonne adhésion, un catalogue simple et digeste a été mis en place. Une bonne connaissance des besoins a permis également de définir une roadmap priorisant les ‘quicks wins’. De son côté, Generali a intégré, dès le départ du projet, un représentant des études informatiques et a inclus dans son catalogue une offre « bac à sable ».
L’implication des équipes techniques au démarrage du projet est primordiale puisque le principal impact sera dans ces équipes. Generali a ainsi associé les équipes techniques notamment lors de la phase de POC. L’avis de ces équipes a été pris en compte. Car ce n’est pas simplement un Cloud qui est mis en œuvre mais la solution qu’ils ont choisie, argumentation à l’appui.
Identification des nouvelles activités, des nouveaux rôles
Une fois les équipes techniques imprégnées du Cloud, en face de chacune des étapes de constitution des environnements (VM pour faire simple), il faut déterminer qui est l’acteur actuel, quelle est son action et quelle charge de travail cela représente.
Il faut ensuite déterminer avec le Cloud la manière dont cela sera automatisé.
Voici, par exemple, le processus de constitution d’une VM x86 Windows avec un client Oracle avant la mise en place du Cloud.
Ce schéma montre le nombre important de tâches manuelles exécutées avant la mise en œuvre du cloud
Les tâches récurrentes, principalement de la responsabilité des administrateurs système, peuvent être automatisées (les rectangles gris «tâches manuelles» ont été remplacés
par des rectangles rayés «tâches automatisées»).
Si certaines tâches manuelles peuvent être automatisées, certaines nouvelles tâches apparaissent. Par exemple, il reste encore beaucoup à faire s’agissant des tâches d’administration du Cloud ou de gestion du catalogue de services.
Les tâches récurrentes sont orientées vers le maintien en condition opérationnelle, l’administration du Cloud, l’intégration des ressources d’infrastructure au sein du Cloud, le reporting et la gestion de la capacité du Cloud.
Les nouvelles tâches relatives au catalogue de services sont celles d’identification des besoins (par priorisation), de conception des services, de réalisation, de mise en œuvre et de qualification de ces nouveaux services.
Pour atteindre un niveau optimal de service, toute la veille technologique relative au Cloud entre dans le nouveau périmètre. Les montées de niveau, les contacts avec les éditeurs sont également à intégrer dans les tâches relatives au Cloud.
La mise en place de l’organisation
Une fois les tâches obsolètes et les nouvelles tâches identifiées, il faut mettre en place une organisation autour du Cloud. Deux découpages a minima sont possibles : - un découpage par technologie où, par exemple les équipes ingénierie Windows
ont en charge à la fois les socles Windows, leur intégration dans le Cloud, leur administration ;
- un découpage où l’on distingue les fournisseurs d’infrastructure nécessaire au Cloud et les administrateurs du Cloud qui ont en charge les tâches précitées.
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
Generali a choisi la seconde organisation où les équipes infrastructure organisées par silos sont fournisseurs (socles techniques, VLAN, etc.). Le centre de service Cloud intègre ces ressources au Cloud et réalise l’ensemble des nouvelles tâches
« Cloud ». Ce cloisonnement permet que les responsabilités soient bien identifiées et que les modifications du Cloud soient concentrées sur un nombre très faible de personnes.
Pour staffer l’organisation définie, le fait que le centre de service ait la responsabilité globale du Cloud et de son évolution, y compris de la veille technologique, facilite l’adhésion des candidats.
Chez Air France, il est avéré, avec des éléments concrets, que les activités s’enrichissent et gagnent en intérêt, les tâches répétitives, rébarbatives allant en diminuant. On constate que les objections des plus réticents sont tombées. Mieux que cela, ces derniers contribuent à l’enrichissement et à l’amélioration de l’existant.
Les personnes amenées à intervenir sur le Cloud doivent non seulement suivre les formations éditeur mais aussi participer à sa mise en œuvre, dans le cadre du projet. En complément, l’intégrateur de Generali a réalisé 10 sessions de 2 heures de transfert de compétences vers le centre de service.
Il peut être également intéressant de mettre en place un livret d’accueil pour les utilisateurs et un pour les administrateurs.
Synthèse
Le Cloud est un vrai projet de transformation. A ce titre, il ne faut pas sous-estimer l’importance et les charges de l’accompagnement au changement. Sa prise en compte dès le début du projet comme un réel risque permet de réaliser une transition « en douceur ».
2 EqUILIBRE fINANCIER DU CLOUD
Dans une IT traditionnelle, la DSI travaillait classiquement sur des cycles budgétaires annuels. L’exercice budgétaire annuel consistait à prévoir d’une année sur l’autre l’évolution du périmètre global du SI (postes de travail, réseau, serveurs, stockage, licences logicielles, ressources humaines…) et d’en déduire un budget qu’il fallait défendre auprès de la Direction Financière et/ou Générale. Lorsque la DSI se comportait comme Centre de Services Partagés auprès des diverses Directions Fonctionnelles de l’entreprise, elle pouvait imaginer des scénarios de refacturation de ses services sur la base d’un prorata de consommation moyenne sur l’année.
Chez l’un de nos adhérents, les DSI disposent d’une sorte d’abaque pour estimer les coûts des différents projets IT, en pourcentages relatifs (tant de % pour l’infra, tant de % pour le développement, etc…). Ces chiffres n’étaient pas basés sur la réelle utilisation ou consommation des ressources. Ils étaient plutôt le résultat de prévisions budgétaires des années écoulées, et d’estimations de croissance fournies par les Métiers. La DSI avait une compréhension des coûts très globalisés sans forcément savoir finement qui utilisait quoi précisément.
Le Cloud (notamment le Cloud public) apporte la notion de paiement à l’usage, qui séduit les utilisateurs de tous ordres, car elle promet (peut-être parfois de façon un peu abusive) une plus grande transparence des coûts, et une variabilité que l’on peut lier à celle du business de l’entreprise. Mais cette liberté apparente peut avoir des revers. Lorsque par simple clic, vous pouvez consommer instantanément des ressources soi-disant illimitées, la facture risque d’apporter de mauvaises surprises. Autrement dit, même si, sur la base d’hypothèses business, on avait intégré au budget un montant OPEX de « x » dizaines de milliers d’euros par an, au bout du compte, on peut réellement dépenser deux fois moins ou trois fois plus…
Par conséquent, cette variabilité des OPEX apportées par le Cloud impacte significativement la maîtrise du budget de la DSI, et pose de nouvelles questions sur la prévision des coûts, l’arbitrage financier entre infrastructures/services mutualisés et infrastructures/services IT purement métiers, sans oublier les ressources humaines qui servent le S.I. de l’entreprise au global.
La réflexion sur l’équilibre économique doit amener à piloter les recettes de la DSI et implique donc de bénéficier d’une vue au plus juste des besoins du Métier,
A retenir : la facturation à l’usage
Si l’on imagine bien a priori les bouleversements techniques, organisationnels que l’arrivée du Cloud dans l’entreprise va amener aux équipes IT et à la DSI, on prévoit moins les impacts financiers et budgétaires qu’il va amener … Et pourtant, la facturation à l’usage est un des piliers du Cloud !
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
une projection de l’évolution des volumes d’utilisation des services Cloud, et si nécessaire de formaliser des scénarios d’évolution. Cette concertation DSI / Métiers permet d’obtenir un engagement mutuel entre la DSI et les Métiers.
La DSI est une entité qui n’a pour objectif ni de faire du profit ni d’accumuler des pertes, mais plutôt de travailler dans le respect du budget qui lui a été accordé. Comment peut-elle assurer cette mission lorsque le Cloud peut perturber notablement cet exercice d’équilibrisme ?
La vie du Catalogue de services
La partie visible du Cloud par ses utilisateurs, c’est le catalogue de services, qui présente les différents services IT proposés (pour l’utilisateur final, le développeur, l’administrateur IT, le responsable projet, les directions métier, etc…) avec le coût associé à chacun. En cliquant sur le service, l’utilisateur est sensé connaître le coût qui sera associé au service qu’il ou elle invoque.
Lorsque le service proposé est un service qu’on peut trouver sur un Cloud public, certains ne se privent pas de comparer – parfois un peu rapidement - les prix de la DSI à ceux du Cloud public.
La lisibilité des coûts n’est pas chose simple, car en face d’un coût en euros il faut mettre en regard la qualité du service proposé. Et les prix d’appel qui clignotent sur les home-pages des sites de fournisseurs de services Cloud ne sont pas toujours les prix réellement payés à l’arrivée.
En raison du potentiel benchmark permanent que les métiers peuvent imposer à la DSI, celle-ci ne peut totalement ignorer les tarifs proposés sur le marché, et doit tenter de se positionner au mieux en regard de ceux-ci.
Une entreprise essaie de se comparer à Amazon, et veut pouvoir justifier de ses tarifs.
Le catalogue de services a été conçu de façon très modulaire au départ. En créant cette modularité, ils ont constaté qu’ils pouvaient être moins chers qu’Amazon.
Mais si Amazon propose des tarifs à la journée ou à la minute, le quantum de facturation dans cette entreprise est le mois. Pour des activités ne justifiant pas d’une utilisation très importante des ressources, la facturation d’Amazon peut se révéler plus attractive.
Ce que confirme un autre membre, estimant avoir des tarifs compatibles avec ceux d’Amazon, même si quelques différences existent.
Certains comparatifs (Cloudscreener.com par exemple) permettent de positionner
plusieurs fournisseurs de Cloud public sur plus de 100 critères (donc pas uniquement sur le prix facial), ce qui peut permettre à la DSI de mieux se benchmarker dans un environnement sans cesse changeant.
Mais face à la guerre des prix permanente que se livrent les géants mondiaux du Cloud, la DSI peut-elle suivre en temps réel (ou à peu près) ces réajustements financiers ?
Il faut cadencer la fréquence de mise à jour du catalogue des services de façon différenciée. Pour les services Cloud consommés chez des prestataires externes, la mise à jour est déclenchée par le changement de la grille du fournisseur. Pour les services Cloud produits en interne, ce sont plutôt un exercice de capacity planning ou une évolution des taux d’utilisation qui provoqueront une mise à jour.
Le budget du Cloud
Budget d’un SaaS
Le SaaS est la locomotive du Cloud. Pierre Marty, associé chez PwC en charge du secteur des technologies déclare : « On estime que d’ici 2016, environ 25% des achats de logiciels professionnels seront orientés service. Le SaaS pèsera pour 14%
de l’ensemble des dépenses liées au logiciel et pour 18% du budget investi dans les applications ». Il prévoit que « Le taux moyen de croissance annuelle pour le SaaS devrait être de l’ordre de 21%, ce qui laisse entrevoir le potentiel économique offert par ces solutions». La progression du SaaS dans l’entreprise est donc un facteur important pour la DSI dans sa prévision budgétaire.
Dans le cadre du SaaS, la majorité des services proposés (CRM, RH, Comptabilité, etc…) sont destinés en préférence à des utilisateurs métier. Mais d’autres services SaaS plus horizontaux (messagerie, agenda, collaboratif,…) peuvent concerner une population d’entreprise plus large.
Pour les premiers, l’exercice budgétaire de la DSI devrait être facilité par une expression claire des besoins quantifiés par les métiers en estimant les unités d’œuvre qu’ils consommeront dans le mois ou l’année à venir. La simple multiplication du nombre d’unités consommées par le prix unitaire doit normalement donner une assez bonne estimation de la facture à acquitter…
Reste cependant que les critères de facturation des fournisseurs de solution SaaS ne sont pas standardisés. Certains tarifient l’utilisateur physique, d’autres les utilisateurs concurrents.
Une entreprise a mis en place un portail de self-provisionning qui doit satisfaire un
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
grand nombre d’entités différentes ayant chacune ses règles financières spécifiques.
L’accès à Amazon via le portail va déclencher un charge-back, qui sera répercuté sur les entités demandeuses. L’idée est de faire la même chose avec l’environnement SAP. Pour faire le lien entre la facturation des entités et ses capacités de fournisseur, cette société a étendu au Cloud les indicateurs de ‘capacity planning’ utilisés dans ses activités IT traditionnelles. Les chiffres sont révisés tous les mois voire tous les 15 jours. Le dépassement d’un seuil d’alerte à 80% de consommation de capacité est le signal pour pouvoir rajouter des ressources. Mais la validation financière de l’opération n’est pas toujours aussi rapide que souhaité, surtout lorsque l’entreprise traverse une période momentanée de gel budgétaire.
Le Cloud et notamment le SaaS tranche du modèle économique connu, par des coûts à l’usage … évolutifs dans le temps et non fixes (ex. schéma de gauche sur les coûts de licence). Mais la promesse
du Cloud reste une rupture sur les coûts unitaires en sortant des coûts fixes par des coûts à l’usage et en forte baisse (ex. schéma de droite CAPEX fixes vs OPEX variables) (source : Open Group).
Le moyen d’éviter ces effets paliers tient dans l’efficacité des prévisions de consommation qu’établissent les directions utilisatrices de ces services SaaS. Dans une autre entreprise, le recensement des besoins métiers s’effectue en fin d’année pour préparer l’année suivante. Reste à prévoir la largeur de la plage d’incertitude pour ne pas trop sur-provisionner, ni sous-dimensionner, au risque d’un déficit de licences logicielles répréhensible.
Les accords d’entreprise permettent de réajuster les quantités de licences légalement nécessaires, c’est l’option de « true up » que l’on trouve par exemple chez bon nombre d’éditeurs de logiciel. Une fois par an, vous indexez à votre accord entreprise toutes les licences logicielles acquises lors des 12 mois écoulés. Cette capacité d’extension à la hausse du parc de licences doit en toute logique trouver son équivalent dans le « true down », lorsque vous avez réduit votre périmètre.
Lorsque certaines Directions Métier décident de recourir au SaaS sans passer par la DSI, la question budgétaire relève de la souplesse des Directions Métier à obtenir l’aval de la Direction Financière. Dans certaines entreprises, les métiers font passer en note de frais des dépenses de ce type. Ces dépenses, si elles restent dans certaines limites, sont assimilables aux frais de téléphonie mobile.
Dans cette situation, la DSI n’a plus la gouvernance globale de l’accès aux ressources informatiques, au choix des applications, ni le respect de la politique d’entreprise sur la localisation et la gestion des données. La relation entre DSI et Directions Métier peut se tendre, même si l’utilisation de mesures répressives est plutôt à bannir.
Pour conclure, l’estimation financière dans un cadre SaaS nécessite un dialogue avec les Directions Métier qui expriment leurs besoins, qu’il faudra traduire en volumes d’unités d’œuvre facturées par le fournisseur. La DSI pourra s’appuyer sur des métriques business (nombre d’employés, nombre de clients, nombre de factures, etc…) pour réaliser cet exercice budgétaire.
Budget d’un IaaS ou d’un PaaS
A priori, les notions de IaaS et de PaaS intéressent plus les équipes de développement et les équipes IT que les utilisateurs métier. Dans ce cadre, la quadrature du cercle budgétaire ne nécessite donc pas forcément d’associer les Directions Métier dans le processus.
Mais la planification des besoins reste d’actualité pour évaluer le budget que l’on consacrera aux fournisseurs si l’on fait appel au Cloud public, ou pour rentabiliser les investissements internes liés à un Cloud privé.
Lorsque l’on fait appel à un prestataire IaaS ou PaaS externe, le coût facturé est normalement le résultat d’une simple multiplication du coût unitaire des services consommés par le volume de consommation (mesuré selon les cas en Méga-octets, en nombre de VM’s, en nombre d’utilisateurs, en nombre de transactions, etc…).
Dans le cas où l’on opte pour la mise en place d’un Cloud privé, la responsabilité de la grille de tarification incombe directement à la DSI. Si elle doit consentir les investissements initiaux (achat des infrastructures, des logiciels…), elle supportera également les coûts humains de l’exploitation. Dans le cadre de la recherche d’un équilibre budgétaire, face à ces coûts, elle doit compter sur des recettes plus ou moins en ligne avec ces coûts si elle veut rester dans l’estimation du ROI chère aux financiers.
La question est loin d’être simple. Pour construire une grille de tarification, il faut prendre en compte les composants que l’on peut diviser en 3 groupes :
1. des composants directement liés à la consommation des services : les disques, la mémoire, les CPU, mais aussi les licences hyperviseurs s’il y a lieu… ; 2. des composants transverses et communs à l’ensemble des services du Cloud :
par exemple le portail du Cloud, les équipements cœurs de réseaux ou les serveurs d’administration du service de Cloud … Leur utilisation est faiblement corrélée au volume de consommation des services ;
3. des composants directement proportionnels à l’instanciation des services : le plus souvent des logiciels ou des services d’administration : par exemple l’administration d’un OS (dont le coût est indépendant de la taille de la VM administrée) ou des licences de supervision.
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
De la Virtualisation (point d’entrée du Cloud) au SaaS public, la montée « en gamme » du Cloud pour une entreprise est bénéfique au ROI, sous la forme de rupture ; notamment le IaaS et le
PaaS comportent de nombreuses déclinaisons (privé, public, hybride …) très bénéfique au budget de la DSI ! (source : Open Group )
Certaines fonctions peuvent se trouver réparties entre ces trois groupes. Par exemple, la sauvegarde aura des composants proportionnels à la « taille » du service (les volumétries sauvegardées et la politique de rétention), des composants communs à l’ensemble des services (l’administration, l’ordonnanceur…), et enfin des composants liés à l’instanciation des services, comme par exemple le service de gestion de la sauvegarde.
Le calcul du tarif est plus compliqué qu’il n’y paraît, car il faut trouver la bonne clé de répartition entre ces trois groupes de coûts.
Pour les éléments transverses à tous les services, on peut choisir de distribuer les coûts dans chaque service refacturé, ou les facturer à part sous forme d’abonnement.
Si l’on opte pour une intégration dans chaque service, quelle clé utiliser pour calculer le coût marginal d’une VM par rapport à l’instanciation d‘un service IaaS complet, intégrant en outre les coûts logiciels ? Et si l’on préfère un abonnement, faut-il avoir un tarif unique quelle que soit la consommation, ou indexer son montant sur le volume ?
Même pour les composants directement liés à la consommation, une banale règle de trois entre le coût d’un Gigaoctet et le volume utilisé ne suffit pas. Le disque doit être intégré dans une baie, supervisé et éventuellement en miroir. De même pour l’ajout d’une nouvelle VM, si celle-ci oblige à l’achat d’un nouveau serveur (ou pire, d’un nouveau châssis de lames), sous quel prétexte cette VM devra-t-elle incorporer la totalité de ces coûts additionnels dans l’attente de futures VM sur ce même serveur ?
Dans la vie réelle où 100% des baies de disques, des serveurs, des composants réseau ne sont pas utilisés à 100%, l’objectif d’équilibre budgétaire de la DSI nécessite de faire des hypothèses financières, au risque d’une surconsommation (ou pire, une sous-consommation) des services.
Enfin, pour des services comparables à ce que l’on peut trouver sur le marché du Cloud public, le choix des tarifs ne peut se faire totalement sans se comparer à ceux pratiqués sur le marché, sous peine de voir certains utilisateurs s’adresser ailleurs.
Etablir le « juste coût » du service est donc loin d’être simple, nécessite des hypothèses plus ou moins nombreuses suivant les modélisations retenues et des choix très arbitraires. Plus on veut affiner le modèle, plus celui-ci devra s’appuyer sur des hypothèses ou d’estimations préliminaires qui peuvent s’avérer très loin de l’usage réel de votre Cloud privé. La sophistication du modèle de pricing ne doit pas se faire au détriment de la lisibilité par les utilisateurs.
Si l’on fait appel à des prestataires externes IaaS ou PaaS, l’exercice financier que doit réaliser la DSI est plus délicat que dans le cadre de prestataires SaaS. La granularité des unités de facturation IaaS (par exemple le paiement à la vCPU, à l’heure voire à la minute) est bien plus fine que dans le SaaS (par exemple paiement mensuel voire annuel par utilisateur).
Puisqu’il est impossible de prévoir à la minute près le nombre de minutes annuel d’utilisation d’une VM, la DSI devra faire des hypothèses basées sur des abaques de consommation. A partir du nombre de projets de développement prévus dans le trimestre ou dans l’année, elle estimera le nombre de ressources nécessaires pour les phases de développement, de tests, de pré-production et de production.
Par exemple pour la phase de développement, le nombre de développeurs, la durée estimée du développement donnera une estimation du volume de ressources informatiques nécessaires (puissance, typologie des OS et middlewares, volumétrie des données, etc.).
La DSI devra prendre garde de vérifier, mensuellement par exemple, l’écart entre les quantités facturées et les quantités prévues. Cela permettra notamment de vérifier que les ressources qui ne sont plus utiles à la phase concernée ont bien été décommissionnées, et éviter de continuer à être facturé pour des VMs vides.
En conclusion
La mise en concurrence de la DSI avec des fournisseurs de service externes à l’entreprise s’est accélérée avec la floraison de fournisseurs de Cloud publics, tous services confondus (Iaas, PaaS, SaaS et au-delà). Dans un monde où les budgets IT restent encore en majorité contraints, la DSI doit faire le grand écart entre la tenue de contrats de niveaux de services exigeants et la concurrence potentielle de providers « low-cost ».
La promesse commerciale faite par les fournisseurs de Cloud avec le paiement à l’usage, séduisante pour les Directions Métiers, peut se traduire pour la DSI par quelques difficultés à estimer, puis à tenir son budget.
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
Si dans le cas des services SaaS, la bonne intelligence avec les directions fonctionnelles est un élément clé dans la prévision budgétaire, la DSI doit également pouvoir disposer d’éléments et d’outils pour suivre la consommation, et s’assurer qu’elle reste dans l’épure des prévisions.
Pour les services PaaS et IaaS, un peu plus éloignés du cœur d’activité de l’entreprise, la DSI est plus autonome pour suivre l’évolution des usages par rapport aux prévisions, et simplifier la tenue du budget.
Le recours à des fournisseurs de services Cloud externes apporte une apparente lisibilité des coûts (sous réserve de bien avoir lu les petites lignes des contrats). Et si l’on opte pour une solution de Cloud privé, l’établissement d’une grille tarifaire est un processus complexe, et qui doit cependant se benchmarker par rapport aux services de Cloud public.
La maîtrise budgétaire du Cloud, qu’il soit public ou privé, et quel que soit son domaine, est donc un exercice de haute voltige pour la DSI, qui nécessite une bonne collaboration avec les Directions Métiers, et une excellente gouvernance pour anticiper les dérives, en particulier pour le mode SaaS. Dans le cadre d’un IaaS ou d’un PaaS, la DSI doit davantage compter sur elle-même pour estimer le budget Cloud, comme l’explique le diagramme ci-dessous.
TAXONOMIE DES METRIQUES BUDGETAIRES SELON LES DIFFERENTS SERVICES CLOUD
(source : CRIP, GT Cloud computing )
Enfin, il ne faut pas oublier qu’actuellement le Cloud ne représente que quelques pourcents en bas de page du budget de la DSI. Un manque d’exactitude dans l’estimation des budgets Cloud ne met donc pas en péril l’exercice budgétaire global. Le fait de trop, ou pas assez, refacturer les coûts du Cloud est encore peu perceptible.
Mais il faut se préparer à la situation à venir où le Cloud représentera une part très significative du budget de la DSI. Dès lors, l’acuité des estimations de dépenses Cloud sera un gage de la fiabilité du budget annuel de la DSI.
3 SéCURITé : L’EffET PRISM / NSA
A retenir:
Malgré un réel gain en maturité, le Cloud continue de soulever diverses objections, dont une grande part renvoie à la sécurité. Ces objections sont accentuées par la médiatisation des affaires WikiLeaks et Snowden, et les révélations sur l’activité des agences de sécurité d’Etat, dont la NSA américaine.
En pratique, un certain nombre de questions se posent en matière de sécurité:
• quelles sont les mesures de sécurité appliquées par les fournisseurs de services Cloud ?
• quels sont les engagements sur la disponibilité des services ?
• quels sont les échanges entre l’IT interne et les différentes formes de Cloud ? Avec quel niveau d’adhérence? Dans quelles conditions s’exerce la cohabitation entre applications et postes clients, mobiles ou non ?
L’utilisation du Cloud tend à se propager dans et autour de l’entreprise et ce de façon parfois incontrôlée voire sauvage. Les métiers et les salariés, au risque de mêler données d’entreprise et données privées, personnelles, accèdent directement à des services tels que iCloud, Dropbox, Google Drive, SkyDrive et autres. La palette ne serait pas complète si on omettait les messageries et agendas ‘personnels’ utilisés sur le Cloud (dont Gmail) et qui sont souvent synchronisés voire connectés aux outils de l’entreprise sans l’aval de la DSI.
L’utilisation banalisée de terminaux personnels (phénomène ByoD, bring your own device), et les gains d’efficacité et de productivité généralement reconnus (y compris par le top-management) rendent ces usages difficiles à interdire.
Pour faire face aux risques de piratage, d’intrusion ou d’évasion de données critiques il faut impérativement que ces pratiques soient encadrées.
En matière de sécurité, tout l’enjeu consiste à sensibiliser et à former les utilisateurs afin qu’ils respectent les règles ou ‘policies’ de l’entreprise. Celles- ci sont généralement résumées dans une charte. Pour utiliser des services sur le Cloud, en particulier les solutions SaaS et les messageries sur le Cloud, il est indispensable que ces règles existent, soient communiquées et respectées.
Le Cloud Computing apporte des ruptures dans la Production IT comme dans la consommation des services informatiques. Son utilisation, notamment sous la forme de ‘Cloud public’, se banalise, souvent avec la poussée des utilisateurs et des métiers. L’avènement du Cloud hybride (cf. chapitre 6), mixant Cloud privé et public, ne simplifie pas la donne en matière de protection des données.
Il est impossible de faire l’impasse d’une réflexion sur la sécurité.
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
Il ne s’agit pas seulement de la protection des avoirs numériques de l’entreprise et de sa réputation. C’est son efficacité, son fonctionnement et sa future agilité qui sont concernés.
La sécurité est une préoccupation transverse dans le SI de l’entreprise. Etre en position de vigilance ne signifie pas être systématiquement en défiance. Au moins deux questions clés doivent être posées sereinement :
• A quels risques sont exposés les nouveaux projets ? C’est le point clé de l’analyse des risques (cf. en particulier, la BIA [Business Impact Analysis])
• Quels moyens, a minima, faut-il mettre en œuvre, en face, pour les prévenir et les empêcher ? Et à quel prix, raisonnable ?
Donc, la sécurité procède à la fois d’une démarche technique et d’une démarche organisationnelle ou stratégique (dont les réflexions sur les impacts, etc...)
Il n’est pas imaginable de laisser les données circuler n’importe où, et en particulier dans des environnements de tierces parties où le contrôle échappe entièrement à la DSI et à l’entreprise.
Pour rappel, trois exigences sont intrinsèques à la sécurité du SI de l’entreprise :
• la confidentialité des données,
• leur intégrité,
• leur disponibilité.
En face, on peut croiser diverses contraintes opérationnelles qui doivent être prises en compte, en les combinant: fiabilité, performances, coûts (ou ROI).
Des organisations se sont constituées pour traiter de la sécurité dans le Cloud, dont notamment la Cloud Security Alliance, fondée dès novembre 2008.
Avec plus de 170 entreprises membres, cette organisation non-gouvernementale a pour mission de promouvoir l’utilisation des meilleures pratiques pour assurer la sécurité du Cloud computing, et de sensibiliser les utilisateurs sur les usages sécurisés du Cloud.
La mutualisation et ses conséquences en matière d’étanchéité
Le Cloud computing apporte une difficulté supplémentaire : l’étanchéité des données et des ‘workloads’ (ou charges applicatives) est encore source de questionnement.
Car l’un des principes fondateurs du Cloud, c’est le levier des réductions de coûts qu’il promet grâce à la mutualisation des ressources (serveurs physiques, baies de stockage, réseau…).
Or, cette question de la « promiscuité applicative » reste critique. Elle renvoie à la réalité de l’isolation des workloads sensibles et/ou critiques.
En outre, l’entreprise faisant appel à un prestataire (hébergeur, ‘Cloud brocker’…) risque de ne plus pouvoir contrôler le placement de ses applications. C’est une menace potentielle pour leur disponibilité comme pour l’intégrité des données qui y résident.
Une faille de sécurité risque très souvent de se traduire par un problème d’indisponibilité (ne serait-ce que le temps de corriger les anomalies, de rétablir le service, comme dans le cas, par exemple, d’une attaque DoS [Deny of Service].
Sur ce terrain, les fournisseurs de Cloud externes ne jouissent pas d’une réputation incontestée. Les clauses contractuelles en matière de disponibilité et de qualité de service prêtent souvent à discussion.
La classification des données par ordre de sensibilité
L’exigence de confidentialité s’applique partout. La question triviale est : quelles sont les données sensibles, confidentielles ou strictement confidentielles ? Lesquelles peuvent ou ne peuvent pas sortir de l’entreprise ? C’est le point clé de la qualification de la confidentialité des données.
La classification conventionnelle, entre C1 et C4 (schéma ci-dessous), apporte une partie de la réponse. Mais, dans une stratégie de sécurité d’entreprise, il n’est pas toujours facile de déterminer ce qui est sensible, strictement confidentiel, secret.
Par ailleurs, en vertu de cette qualification /classification, le transfert de certaines données sur le Cloud public est soumis à des restrictions réglementaires, incluant le respect de certaines conditions d’exploitation (dont la localisation du data centre, le pays, le lieu où résident les données en exploitation et en sauvegarde).
En outre, il n’est pas évident d’obtenir des utilisateurs qu’ils classifient leurs documents et les fragments d’information qu’ils produisent, sur une échelle de confidentialité. Ce processus de classement peut s’automatiser, mais en partie seulement. La responsabilisation des utilisateurs et leur implication en la matière sont essentielles.
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
L’ affaire Prism / NSA : l’électrochoc de l’été 2013
Après les révélations très médiatisées à partir de juin 2013, faites par Edward Snowden, ex-consulant de l’agence américaine NSA (National Security Agency), sur les pratiques d’espionnage et de surveillance mondiale des Etats-Unis, beaucoup de projets de déploiement sur Cloud public ont été mis à mal en Europe – s’agissant notamment de la messagerie sur le Cloud ou des transferts de data via des ‘SafeHarbors’ ou non.
Dès le début des années 2000, les révélations sur le système d’espionnage Echelon (américano-britannique), avaient alerté les professionnels de l’IT qui connaissaient l’existence de vastes dispositifs d’écoute et de surveillance sur les réseaux de télécommunications, radio ou filaires, et donc, potentiellement, sur Internet.
Depuis quelques années, l’actualité regorge de récits sur des intrusions ou tentatives d’intrusion sur des systèmes de grandes administrations ou de grands opérateurs, à très grande échelle et provenant de divers pays suspects, parmi lesquels figuraient la Chine, l’Union Soviétique, mais aussi déjà les Etats-Unis…
L’affaire Snowden, juste après celle de Julian Assange (Wikileaks), informé par le soldat Bradley Manning, a été très médiatisée parce qu’elle a révélé, de l’intérieur, l’ampleur des moyens déployés par l’agence américaine NSA pour mettre le monde entier sur écoute ou presque (y compris via les fibres optiques sous-marines, au large des côtes… )
Edward Snowden a révélé aux journaux Guardian (britannique) et Washington Post (américain) l’ampleur du système de captation des métadonnées des appels téléphoniques aux États-Unis, ainsi que les systèmes d’écoute sur internet des programmes de surveillance PRISM, XKeyscore, notamment, informant le gouvernement américain, ainsi que les programmes de surveillance Tempora, Muscular et Optic Nerve du gouvernement britannique.
Selon ces révélations, le gouvernement US a une prise directe sur les données européennes des fournisseurs US, et la volonté de disposer de toutes les données mondiales.
Edward Snowden.
Cliché WPost, DR
Le Washington Post, dans son édition du 30 octobre 2013, faisait paraître un dessin illustrant comment la NSA pouvait accéder aux données de Google Mail
Source : Washington Post, 10/2013, DR.
En conséquence, dans les jours et les semaines qui ont suivi ces révélations, un durcissement sécuritaire a marqué les esprits et une adoption plus rigoureuse de la réglementation en matière de protection des données a été prescrite.
« Deux choses ont été retenues de l’affaire Snowden, c’est d’une part l’insatiable curiosité des gouvernements à recueillir toutes sortes d’informations à travers le monde, et l’impérative nécessité de sécuriser le SI face aux diverses formes d’écoute et de hacking », constate un membre du GT Cloud Computing.
Le focus sur cette affaire a sans doute été un peu exagéré, très médiatisé, et mis en exergue du fait qu’elle suivait de quelques mois un débat sur les conséquences du PatriotAct américain (cf. Livre blanc Cloud Computing n°4). Un an après les révélations sur les agissements de la NSA, le niveau d’inquiétude est un peu retombé. On sait qu’il existe certains garde-fous, comme le fait que, pour avoir accès à des données, les autorités américaines doivent saisir un juge. Mais le fait est que le gouvernement américain s’est donné la possibilité de lancer des requêtes hors contexte terrorisme, initialement invoqué.
Les questions soulevées ici remontent en réalité à l’avenant à la loi FISA de 2008, permettant aux Etats-Unis de ‘sniffer’ partout dans le monde. « A l’origine, semble- t-il, c’était sous réserve que la société ait son siège aux USA, ensuite cela s’est étendu aux filiales partout dans le monde », constate un membre du GT.
En parallèle, le parlement européen, qui s’est ému de la situation, a voté la suspension du principe ‘Safe Harbor’, qui gère les règles d’encadrement du flux des données avec des prestataires américains, en les élargissant à Internet. L’Union européenne a entamé des discussions avec les USA pour établir une nouvelle version de ce
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
«Il y a des lacunes ; le dispositif est trop permissif par rapport aux affaires PRISM /NSA provenant de l’avenant FISA », explique un membre du Groupe de Travail. « Les juristes semblent préférer les SCC (Standard Contractual Clauses) de la Commission européenne au SafeHarbor, mieux encadrées, plus récentes et mieux adaptées aux Européens ».
(cf. encadré 2 ci-contre).
Conséquences de l’affaire PRISM / NSA
Beaucoup de baies informatiques sont managées à distance, d’un continent à un autre. Or, sans parler des ‘back-doors’, on sait désormais qu’il y a des risques d’infiltration par des services d’espionnage.
Autre constat : la cible des services d’espionnage ne se réduit pas au Cloud, mais concerne aussi la téléphonie, donc les smartphones (cf. les écoutes dirigées vers Angela Merkel à Berlin) et le webmail !
Des plaques régionales et contre-mesures
Géographiquement, il existe 3 grandes régions ou plaques qui fournissent des équipements susceptibles de laisser passer des intrusions ou infiltrations :
• l’Occident (Europe, Etats-Unis…),
• la Chine (que le Canada et le Royaume-Uni refusent en tant que ‘sourcing’)
• la Russie (à noter, au passage, que Moscou a décidé de faire le ménage et de remplacer tous ses équipements).
Un autre membre du GT Cloud computing, confirme qu’il y a bien eu un «effet Prism».
Des directives nouvelles ont conduit à réviser l’existant en matière de messagerie sur le Cloud et à geler certains projets. La direction de son groupe a également évoqué explicitement le cas de la banque Saudi Aramco qui s’est fait pirater voire détruire 30000 postes de travail. Plusieurs études sur la sécurisation du SI, dont la partie Cloud, ont été lancées : gestion des ID, cas d’usurpation d’ID, protection par double chiffrement, etc.
Sur le Cloud public, la classification des données a été complétée et renforcée, avec des outils ad-hoc, en fonction des critères de disponibilité, d’intégration ou non au SI, etc.
Des directives internes et à destination des partenaires sont venues rappeler qu’aucune donnée sensible ne doit être mise en ligne. Certaines branches de ce même groupe n’ont pas attendu ces évènements pour proscrire tout hébergement sur le Cloud public. Même un hébergement Outlook «privatif», pas réellement public, n’est plus admis.
Des contre-mesures supplémentaires ont été mises en place : code de bonnes pratiques, rappel sur les chartes engageant les personnels, etc. Le référencement
des fournisseurs a été refait, y compris pour imposer le chiffrement des communications avec eux (les clés étant détenues par le groupe, évidemment).
Des certifications devenues encore plus nécessaires
Face à ce contexte, des solutions de sécurisation existent – chiffrement, classement sur la sensibilité des données. Le Cloud souverain est une alternative à étudier.
Mais tout n’est pas résolu pour autant.
« En réaction, certaines entreprises en Europe dont la nôtre, témoigne le même membre du GT, ont ajusté leur infrastructure qui reboucle sur leur VPN interne, ainsi qu’une classification de la sensibilité des données, et une possibilité d’encrypter avec leurs propres certificats privés, les données/mails sensibles, incluant la certification ISO 27001 de Microsoft qui n’est pas spécifique au Cloud, mais qui est peut-être une certification meilleure sur la sécurité en la matière, ‘meilleure’ ne voulant pas dire
‘suffisante’. Il faudra des certifications dédiées au Cloud. Pour cela, il faudra que les entreprises utilisatrices se mobilisent afin de les définir au niveau européen. Faute de quoi, les fournisseurs vont les définir à notre place et à leur avantage. Car l’ajout des SCC est optionnel ».
La responsabilité de l’hébergeur
On sent poindre des améliorations sur la question de la responsabilité de l’hébergeur, qui, en Europe, remonte à 1995. Il existe un nouveau texte -Règlement Européen sur la Protection des Données- proposé en janvier 2012 par la Commission européenne (et qui a fait l’objet de plus de 3 000 avenants, provenant d’on ne sait où, probablement pas des entreprises utilisatrices mais plutôt les fournisseurs de Cloud…).
« Ce règlement reste à discuter avec les utilisateurs pour conduire à un vote final par la Commission, prévu en 2014 mais qui risque d’être décalé en 2015 et pourrait entrer en application en 2017. Il y a urgence, car la Directive de 1995 est très insuffisante », estime le même membre du GT Cloud.
Propriété intellectuelle et analyse de risques
Cette question de la « curiosité des Etats » pose aussi celle de la « propriété intellectuelle » des données et celle de l’évaluation des risques encourus. «Vers quels fournisseurs de services Cloud se tourner, avec quelle exposition à quels risques
? Avec quel niveau de confiance ? Voici le dilemme actuel», observe un autre membre du GT Cloud Computing, dont l’organisation, classée OIV (Opérateur d’Importance Vitale), a décidé d’établir un recensement de tous les incidents sérieux de fuites de données ou cyber-attaques dans le monde (affaires Adobe, Target, banque Saudi Aramco, etc.).
Réglementations nationales ou communautaires, et chiffrement
« Il existe avec le Cloud pour le moment un problème de confiance ; on ne sait pas à quel
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
La possibilité d’auditer la plateforme dédiée à l’entreprise, qui s’applique au cas d’un Cloud privé externe et non pas au Cloud public, n’est pas la panacée.
Certains responsables n’accordent que peu de crédit à la pratique d’audits :
« Je ne crois pas à la clause d’audit. On paie pour envoyer un auditeur, très bien, mais finalement le prestataire peut très bien ne pas respecter les recommandations que nous lui faisons. »
Des clauses contractuelles permettent cependant d’engager le fournisseur à mettre en œuvre les mesures préconisées. Ces clauses sont, du reste, rendues obligatoires dans certains métiers ou domaines (bancaire, administratif, santé…).
« Les certifications telles qu’elles existent ne nous disent rien sur la sécurité réellement mise en place. Même au travers d’une certification, comment allez-vous apprendre que votre prestataire a par exemple déplacé ses administrateurs en Inde ? », observe un autre manager IT.
Chiffrement : les limites
Le chiffrement peut-il pallier les problèmes de confidentialité ? Un membre du Groupe de Travail observe : « Le problème avec les données n’est pas tant leur isolement, leur protection, que leur sélection avant de leur appliquer des politiques et traitements ».
En outre, l’application à grande échelle des pratiques de chiffrement reste souvent complexe, - d’autant plus complexe si l’utilisateur conserve la responsabilité d’appliquer ou pas le chiffrement.
Le cryptage est peut-être un frein, mais la question est de savoir qui peut détenir et utiliser les clés des algorithmes utilisés.
« Le cryptage peut s’avérer essentiel à mettre en place dans le Cloud. Bien exécuté (c’est- à-dire sans l’existence de ‘backdoors’ ou trappes d’accès arrière sur les équipements réseau), le chiffrement pourrait même freiner voire empêcher les gouvernements de consulter nos données - même si, dans la pratique, pour un bon fonctionnement, les données ne peuvent pas toujours être cryptées. Donc a minima le fournisseur de Cloud pourrait avoir accès aux données. Si le fournisseur y a accès, le gouvernement dont il dépend peut techniquement y avoir accès ».
A propos des clés de chiffrement, les membres du GT observent que beaucoup, utilisant par exemple le chiffrement des bases Oracle ou d’autres éditeurs, s’interrogent. Personne ne peut lire dans les interfaces de ces éditeurs, qui détiennent les clés de cryptage (et donc, le cas échéant, peuvent être conduits à satisfaire les requêtes de services spéciaux comme le FBI ou d’agences d’état comme la NSA...).
Une question revient souvent : comment crypter les communications vers l’extérieur, vers les partenaires? Au vu des différentes affaires fiscales ou judiciaires (réseaux mafieux, trafics d’armes, blanchiment d’argent sale...), notamment ces deux dernières années, la question du statut des ‘private banks’ se pose.
On sait également que les fuites de données ont souvent une origine interne. De ce fait, des règles de sécurité draconiennes ont été mises en place (comme le demande, entre autres, le rapport sur les salles de marché). Un membre du GT commente :
« Tous les droits ont été restreints (environnements Unix, compris, bien sûr). Puis des restrictions ont été imposées sur les bases de données. Ce qui a suscité une sorte de vague de paranoïa et des ambiances de travail détestables! ».
Pour les données financières, bancaires, une recentralisation a été opérée sur les grands pôles, mais on sait que certains pays, dont la Turquie, y sont opposés.
En raison de telles contraintes réglementaires nationales, on a vu des cas où les données étaient traitées sur mainframe dans un pays (par exemple, la Suisse) alors que les données pouvaient être stockées, sauvegardées ailleurs...
Les clauses de ‘risk assessment’
Certaines contraintes réglementaires obligent les acteurs de certains secteurs (santé, pharmacie, etc.) à appliquer des dispositions particulières. Ainsi, chaque fois qu’un projet implique d’envoyer des données à l’extérieur, le contrat avec le prestataire doit inclure une clause de ‘ risk assessment ’. Elle est obligatoire.
« Cela sous-entend la possibilité d’un audit de sécurité, lui aussi rendu impératif.
Les juristes sont très sensibles sur cette question », témoigne un pilote du GT.
Une telle mesure s’impose à tous les services au sein des organisations concernées.
La sensibilisation et la communication en interne et dans l’écosystème des partenaires sont également très poussées. En clair, il ne suffit pas de travailler sur les technologies comme celles du chiffrement ou autres : « Il faut établir les bons processus et faire appliquer les bonnes pratiques ».
Un autre membre du GT ajoute : «La Production IT se donne les moyens d’auditer, de contrôler mais elle oublie souvent de mettre systématiquement les juristes ‘corporate’
dans la boucle suffisamment tôt. Ceci se paie cher par des retards importants dans le planning des projets ».
Pour la sécurisation des communications entre collègues jusqu’au middle management, de telles mesures fonctionnent bien, observe-t-on. « En revanche, il n’est jamais aisé de faire comprendre au top management qu’il doit aussi respecter les règles et montrer le bon exemple, appliquer les bonnes pratiques ». Or tout le monde s’accorde sur une pression croissante en la matière.
Des réserves sur la Messagerie dans le Cloud
Certains grands comptes comme les opérateurs ont refusé d’externaliser leur messagerie, tout en évaluant les risques soulevés par l’offre Office 365 de Microsoft, par exemple.
Au moins deux points faibles sont relevés:
• la mise à disposition des ‘logs’ pour faire des audits de sécurité: cela peut constituer un point dur avec l’éditeur. Les données proposées n’ont pas paru suffisantes pour permettre de mener de véritables audits ;
• l’utilisation d’Office 365 supposait que toutes les informations d’annuaire soient transférées sinon accessibles chez l’éditeur, pour que soit activés des connecteurs. C’est tout l’annuaire d’entreprise qui risque ainsi de partir à l’extérieur !
CLOUD COMPUTING : Aspects juridiques, RoI du Cloud, Achat des prestations Cloud, Offres IaaS, Tendances PaaS
L i VRE BLANC
Du reste, pour toute application en mode SaaS, les contrats de ‘sourcing’
généralement signés avec les éditeurs européens disposent d’une clause spécifique sur la sécurité, qui leur donne certains accès. De telles clauses sont légales, car elles relèvent de contrats privés ou négociations commerciales bipartites.
Un autre membre du GT précise : «Selon nous, le cas d’Office 365 pose le problème des mises à jour ou des changements de version, relativement fréquents, qui, chez nous, pourraient risquer de paralyser jusqu’à 15 000 postes de travail. Les mises à jour peuvent intervenir, inopinément ou presque, tous les 3 mois. Or, ceci a des impacts en cascade sur d’autres logiciels ».
Mais force est de constater aujourd’hui qu’il n’y a guère d’autre choix, à coût égal, pour un grand nombre de services, comme les Google Apps. Beaucoup acceptent de faire avec.
Confiance envers les tierces-parties ? Quels services d’audit ?
Certains fournisseurs proposent des services d’audit du data centre à travers des prestataires partenaires. Mais qui est prêt à faire confiance à un tiers comme certains grands cabinets d’audit ?
Et les solutions de tracking ne sont paraissent pas constituer une alternative.
Clouds souverains, Numergy et Cloudwatt, et position de l’Administration En matière de sécurité, les Clouds souverains sont-ils bien positionnés?
« Nous constatons que les Clouds souverains disposent d’une offre encore peu développée dans ce domaine. Leur vraie pertinence fonctionnelle par rapport aux autres n’est pas encore très perceptible », observe un membre du GT, d’un grand groupe de l’énergie.
Autre remarque, d’un autre membre : « Dans notre administration (interministérielle), un groupe de travail a été mis en place, depuis cet été, entre l’Administration et les éditeurs sur la sécurisation du Cloud (interne) ». Les résultats étaient prévus pour le premier semestre 2014. «Il faut, entre autres, que des audits puissent être menés avec les fournisseurs, éditeurs ou distributeurs/ intégrateurs, ou tiers de confiance. Des labélisations de type ITIL ou ISO 27001 sont préconisées mais il convient de détailler lesquelles doivent être mises en avant, au niveau national et parfois, à l’international ».
L’argument « mutualisation » tombe
Après cette analyse des risques, l’entreprise doit prendre ses dispositions : « C’est la décision de l’entreprise, face aux lois et aux textes réglementaires. Mais, en France, constate un autre membre du GT appartenant à un ministère, l’agence nationale ANSSI invoque l’homologation des Clouds souverains de l’Etat. Or, parfois, une telle approche peut conduire à des mesures trop radicales : ils peuvent nous demander un partitionnement des données du Cloud hors de l’hébergeur. Ce qui signifiera perdre un avantage économique clé, celui de la mutualisation ».
Et le ‘multi-sourcing’ national ?
Ce même témoin ajoute qu’il a été décidé de travailler sur la classification des
