Club des Responsables d Infrastructures et de Production L OBSERVATOIRE CLOUD COMPUTING

Club des Responsables d Infrastructures et de Production LiVRE BLANC L OBSERVATOIRE des Directeurs d Infrastructures et de Production CLOUD COMPUTING PaaS, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC Patrick Joubert & Stéphane Geissel Assistance Editoriale : Renaud Bonnet Juin 2012

Table des matières Introduction 4 1. Le PaaS : définition, problématiques, usages 6 1.1. Etats des lieux, définitions, typologie des services PaaS 7 1.2. Gestion du cycle de vie : Build et Run dans le PaaS 9 1.3. Environnements spécifiques pour le Build et le Run 10 1.4. Qu héberger en mode PaaS public? 11 1.5. Frameworks 11 1.6. Gérer les architectures Hybrides avec le PaaS 12 1.7. Administration et Exploitation des offres PaaS 13 1.8. Modèles économiques et engagements de qualité de service 15 1.9. Réversibilité, portabilité entre plates-formes 16 1.10 Conclusion 16 2. Sécurité et Cloud Computing 18 2.1. Le Cloud vu par les RSSI 18 2.2. Questions de sécurité indiscrètes pour votre (futur?) fournisseur de Cloud 21 2.3. Perspectives / Conclusion 21 3. Les modèles de sourcing et le Cloud 23 3.1. typologie des modèles de Cloud en fonction des types d applications : quels Clouds pour quelles applications? 23 3.2. Les apports principaux du référentiel escm aux pratiques de sourcing du Cloud Computing 24 3.3. Recommandations d ordre juridique sur les Contrats portant sur les services Cloud, formulées par deux avocats ayant contribué au livre blanc 27 4. Facturation et refacturation dans le Cloud 28 4.1. Collecte des métriques 28 4.1.1 Métriques techniques 30 4.1.2 Métriques SLA s 31 4.1.3 Métriques Métiers ou Business 32 4.2. Reventilation des coûts : Showback ou Chargeback 33 4.3. Conclusion 34 5. CLOUD ET HIGH PERFORMANCE COMPUTING 36 6. RETOURS D EXPÉRIENCE 39 6.1. Valeo Vega 39 6.2. Stime (Informatique des Mousquetaires) 41 6.3. Unéo 44 6.4. Orange-FT Groupe 46 7. CONCLUSION Le Cloud est une réalité dans nos sociétés 48 A propos du CRiP 49 PAGE 3

Intro duction Le Cloud, la concrétisation Trois ans, trois Livres Blancs. C est en effet déjà la troisième production du Groupe de Travail Cloud Computing du CriP que vous lisez depuis 2010, année de sa création. Une fécondité due en particulier au dynamisme du domaine traité. Réduire le phénomène Cloud à un effet marketing était très tentant... il y a trois ans. Mais aujourd hui, le Cloud a atteint sa phase de maturation, celle qui précède le plein développement et en dessine déjà les grands traits. Et plus personne ne s avise de nier la valeur et l importance du phénomène Cloud, dont nous répétons une fois de plus qu il ne s agit pas d une technique, ou même d une famille de techniques, mais d une nouvelle façon de produire et de consommer les services informatiques. Cette année, le fruit des efforts Groupe Cloud Computing pour sa saison 2011-2012 est encore une belle réussite collective, un travail d équipe et nous tenons à remercier vivement les participants et contributeurs. Voici les sujets que vous allez découvrir dans ces pages : - Le PaaS, le jeune premier du Cloud, et pour entrer dans ce sujet aux contours encore flous nous poserons quelques jalons pour mettre en regard les problématiques et les usages. - Nous avons ensuite souhaité confronter les points de vue des membres du Groupe Cloud Computing avec ceux des RSSI (Responsables de la sécurité des systèmes d Information) de plusieurs adhérents du CRiP sur le sujet de l adoption du Cloud dans les entreprises et administrations. Pour découvrir que finalement les avis ne sont pas si opposés! Une check-list pratique vous permettra d aborder sereinement le sujet de la sécurité avec votre fournisseur préféré. - Notre troisième chapitre est issu du travail réalisé avec le Syntec Numérique pour traiter des modèles de Sourcing à l heure du Cloud, un focus particulier porte sur les référentiels tels escm qui constituent un support pour une bonne mise en œuvre de projets multi-sourcés. - Notre quatrième chapitre porte sur la facturation et la refacturation des services Cloud, des éléments d importance dans une démarche de maîtrise des coûts. C est l occasion de mieux se pencher sur ce sujet pointu. - Le domaine du HPC, abordé plus en détail l an dernier, a connu des évolutions ces douze derniers mois. Nous avons souhaité vous en tenir informé dans un bref observatoire de tendances qui souligne les points-clés de la maturation de ce domaine complexe et encore mouvant. - Enfin, notre dernier chapitre illustre, par des exemples de la vraie vie, des références de projets réalisés par les membres : IaaS, PaaS, SaaS. Les 3 composantes du Cloud y sont représentées, encore merci à tous pour vos témoignages. Patrick JOUBERT Bonne lecture! Stéphane GEISSEL Pilotes du Groupe de Travail Cloud Computing du CRiP PAGE 4

REMERCIEMENTS Ce Livre Blanc a été rédigé par les membres suivants du GT Cloud Computing du CRiP : Pascal Dechamboux Orange FT Groupe Stéphane Geissel SFR Alain Hutié EdF R&D Patrick Joubert CRiP Stéphane Lafon Sanofi Arnaud Lecomte STIME Kathleen Milsted Orange FT Groupe Pierre Oblin Orange FT Groupe Michel Raulet PSA PEUGEOT CITROËN François Stephan CRiP Arnaud Viselthier EdF Jacques Witkowski CRiP Les contenus de ce Livre Blanc ont bénéficié des échanges, débats, désaccords, discussions, retours d expériences et commentaires divers tenus au sein du Groupe de Travail Cloud Computing depuis septembre 2011. Que tous les participants soient chaudement remerciés pour leurs contributions : Marc Bégué CNES Denis Descamps Publicis Claude Fauconnet Total Stephane Gilmer Publicis Jean Guyot Société Générale Pierre Haslee Société Générale Franck Honnecker CA-CIB Alain Roy Generali Nous remercions pour leurs témoignages : Lamia Elias Société Générale Pierre Faure Boost Aérospace Annelise Massiera DISIC Benjamin Rameix Unéo Cédric Siben Ministère de l Economie et des Finances Jean Roy Valeo Nous remercions les RSSI participants à nos rencontres RSSI GT Cloud : Antoine Béligné PSA PEUGEOT CITROËN Alain Bernard L Oréal Martine Hanin Total Valérie Zorzi CNES LiVRE BLANC CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC Nous remercions les membres du Groupe de Travail Sourcing Cloud du Syntec Numérique et tout particulièrement Renaud Brosse Assistance et coordination éditoriale : Renaud Bonnet (CRiP) PAGE 5

1 Le PaaS : définition, problématiques, usages Le PaaS Platform-as-a-Service constitue la famille de services Cloud la plus en rupture avec l existant. En effet, dans le SaaS (Software-as-a- Service), tout le monde reconnait le modèle ASP développé au tournant du XXIème siècle. Et l IaaS ne fait que donner plus de souplesse et d agilité aux services de fourniture de serveurs préconfigurés par les hébergeurs que nous connaissons depuis les débuts du Web. Le PaaS présente un visage nettement plus original. Plus riche que l IaaS, il ne se limite pas à la machine nue ou juste équipée de son système d exploitation. Moins étroit que le SaaS, il ne fournit pas un service applicatif complet mais bien un environnement de développement et d exécution d applications plus ou moins complexe qui se compose de ressources système, d un système d exploitation et de diverses couches middleware : bases de données, répartiteurs de charges, serveurs d applications, serveurs d annuaires, etc. on pourrait allonger la liste sans fin. En bleu : composants contrôlés par le prestataire En rouge : composants contrôlés par le client En hachuré : composants fournis par le prestataire selon le choix du client. PAGE 6 Ce schéma rappelle que les différents types de services Cloud se distinguent par les composants de la pile informatique pris en charge par le prestataire pour leur exploitation et leur maintenance.

Le PaaS a été abordé en détail par le groupe de travail Cloud Computing du CRiP à l automne 2011 en réponse avant tout à une nette maturation du sujet à la fois chez les membres du CRiP qui commencent des expérimentations dans ce domaine (voir le retour d expérience Orange-FT en fin de ce volume) et chez les fournisseurs qui multiplient les offres. Le PaaS apparait à certaines entreprises comme un prolongement naturel de l IaaS. Au fil des ans, le processus de fabrication des logiciels a beaucoup progressé, s est structuré, ce qui a provoqué une diminution des délais de réalisation. Mais la mise en production de ces logiciels reste complexe, car elle demande de passer par de nombreux silos (développement, tests, recettes, pré-production, production), et de réaliser de nombreuses actions manuelles ou faiblement automatisées. Il existe en fait un immense écart entre environnements de développement et de production, le chemin qui va de l un à l autre prend du temps, trop pour beaucoup d entreprises. Le PaaS serait le moyen de réduire cet écart, en mettant à la disposition des développeurs un environnement adapté à leurs besoins mais en même temps déjà largement voire totalement conforme aux principes de la Production. Ainsi le cycle développement-tests-recettes-préproduction-production se déroulerait d une façon plus fluide, avec une moindre débauche d efforts. Une autre dimension doit être soulignée dans ce désir de consommer du PaaS. La virtualisation et l IaaS ont déjà apporté un gain significatif d agilité dans la mise à disposition de ressources. Mais savoir livrer une souche technique en quelques heures pour répondre à un besoin ponctuel ne suffit pas. Beaucoup d entreprises voudraient progresser dans l agilité en possédant un environnement d accueil qui en respectant un cahier des charges de développement idoine soit capable de fournir une élasticité d exécution, une plate-forme capable de prendre en charge ellemême les problèmes de dimensionnement de ressources en fonction de la charge d une application. La plate-forme PaaS devrait rapprocher les entreprises de ce mode de fonctionnement. On ne provisionne plus des serveurs, mais le comportement de l application détermine la mise à disposition de ressources par la plate-forme. 1.1 Etats des lieux, définitions, typologie des services PaaS La définition du PaaS est moins unifiée que celle de l IaaS, au point qu il serait plus juste de considérer une famille de définitions. Ces variations découlent à la fois du savoir-faire des offreurs et des besoins des entreprises, et peuvent même dans le cas de Cloud PaaS internes correspondre à la nécessité de développer le PaaS en continuité avec l existant de l entreprise. En effet, le besoin business définit les fonctionnalités à développer et par voie de conséquence les composants logiciels nécessaires, ainsi que les modules applicatifs indispensables ou utiles pour développer plus rapidement les fonctionnalités demandées. Or le PaaS possède une grande modularité, il commence dès que quelques briques intermédiaires (des composants middleware tels bases de données ou serveurs d applications) s ajoutent aux serveurs virtuels, mais peut atteindre un haut niveau de richesse fonctionnelle avec l intégration d environnements de développement complets par exemple, ou d outils perfectionnés de gestion de charge. Il n existe donc pas a priori de besoin unique identifiable dans ce domaine, du moins à ce stade de maturité. PAGE 7 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

Dans l offre actuelle très diversifiée, deux tendances se dégagent dès à présent : 1. Des plates-formes IaaS enrichies parfois baptisées IaaS+ : elles se composent de machines virtuelles unitaires avec différentes versions de systèmes d exploitation et de logiciels de base (serveurs d applications, serveurs de bases de données, middlewares, etc.) pré-chargées. Avec ce type de service, le client doit composer lui-même son architecture technique et définir le dimensionnement nécessaire à son application. Il lui faut donc choisir chaque machine virtuelle avec les logiciels de base associés dans un catalogue. Notons cependant que les assemblages sont le plus souvent prédéfinis et les versions disponibles limitées en nombre, ce qui borne les combinaisons effectivement possibles (le nombre de ces combinaisons peut toutefois se montrer déroutant pour les entreprises). Nous classons dans cette catégorie Amazon EC2 avec les Amazon Image Machines (AMI) (chacune pouvant embarquer au choix du catalogue un SGBD, et un serveur d application web en plus de l OS) et les offres IBM SmartCloud Application Services. 2. Des environnements d exécution PaaS complets fondés sur des architectures techniques prédéfinies par le fournisseur avec plusieurs machines virtuelles sur lesquelles sont répartis les composants logiciels de base. A ce niveau, le client ne choisit pas des machines individuellement, ni par exemple leur taille, mais choisit un environnement logiciel, c est-à-dire principalement un langage de programmation, un framework Web et un SGBD. Les packages sont prédéfinis avec plus ou moins de flexibilité. Les éditeurs de ces solutions proposent souvent des services logiciels complémentaires (ex. middlewares, composants logiciels réutilisables). La plate-forme prend en charge automatiquement la flexibilité et la scalabilité lors de l exécution de l application. On trouve dans cette catégorie Google App Engine, DotCloud, Cloud Foundry, Microsoft Azure, Amazon Elastic Beanstalk, CloudBees, RedHat OpenShift. On notera que dans cet écosystème cohabitent des acteurs connus et déjà anciens (IBM, Microsoft), des entreprises ayant assis leur réputation sur leurs opérations Web (Google, Amazon) et de nouveaux acteurs. Bien qu il soit pour le moment difficile de proposer un tableau général des clients de ce type de services, on notera l existence d une première génération d adopteurs qui ont choisi de s appuyer sur des plates-formes PaaS pour réduire au maximum leurs délais de mise sur le marché et de se lancer avec un minimum de mise en œuvre physique. En France, l entreprise d assistants à la conduite Coyote, dont l App sur iphone a rencontré un immense succès, a démarré ce service sur Google App Engine. Limitation du modèle : comment intégrer des applications complexes au PaaS? PAGE 8 Envers du décor, la plupart des offres PaaS actuelles ne supportent pas nativement les architectures logicielles complexes et relèvent d un paradigme de type une application = une plate-forme PaaS. La mise en œuvre d un système informatique pour un domaine métier, ou d une application elle-même constituée de sous-applications ou de modules applicatifs n est pas facilitée dans l état présent de l offre. En effet, les entités gérées actuellement par les PaaS sont des applications, ou des modules applicatifs autonomes. Il s agit concrètement d applications web, étroitement associées à

un point d entrée sur le web (url). La notion de système informatique composé de plusieurs applications n est pas gérée dans un tel modèle. Les opérations de communication inter-applicatives doivent alors mettre en œuvre des interfaces web qui ne possèdent à ce jour que des fonctionnalités de communication élémentaires. En résumé, les fournisseurs PaaS vont devoir évoluer au-delà du modèle actuel qui fait qu une application se résume souvent à l association d un point d accès web et d une base de données pour aller vers un modèle ou une application fonctionne comme la combinaison d un ensemble d autres applications. Ces différents facteurs pousseront sans doute des entreprises à se tourner vers des solutions de PaaS privées, en construisant en interne leur plate-forme. L une des questions importantes à se poser sera celle de la standardisation : quels composants et combinaisons de composants privilégier concernant les bases de données, les versions de moteurs et de langages, les frameworks? De plus, ces PaaS privés risquent de se trouver en concurrence avec les PaaS publics, au sens où les équipes de développement risquent de se tourner vers des plates-formes externes afin de développer en toute autonomie, sans aucun contrôle de la DSI. Or, cela posera un véritable problème de gouvernance lors de la ré-internalisation des applications ou de leur nécessaire maintenance dans le temps. 1.2 Gestion du cycle de vie : Build et Run dans le PaaS Le PaaS va exercer un impact organisationnel important sur l ensemble des intervenants sur les différentes couches du SI d entreprise utilisateurs finaux exceptés -. Il devrait aussi provoquer l apparition de nouveaux rôles, exploitant d applications PaaS par exemple. De ce point de vue, le PaaS présente une dimension plus disruptive que le SaaS ou l IaaS car, comme expliqué plus haut, il affaiblit la frontière entre environnements de Développement-Tests-Recette et environnements de Production, et ce au prix de la mise en place de nouvelles règles de fonctionnement. La liste des métiers impactés se compose de : Equipes de conception/développement : elles devront intégrer les contraintes spécifiques liées au PaaS, par exemple de ne plus exprimer leurs demandes sous forme de spécifications techniques, mais de pures spécifications applicatives : accès Web, base de données, serveur, etc. Architectes techniques : leur rôle diminuera éventuellement auprès des équipes projets, puisque le cadre d architecture se trouvera inscrit en dur directement dans la plate-forme PaaS. Mais leur contribution reste essentielle. D abord pour constituer l architecture technique de l offre d une plate-forme PaaS (offre qui pourra ensuite se démultiplier sans eux ou presque), ensuite pour constituer l architecture d une application par assemblage de multiples serveurs d une offre IaaS+ (interne ou externe). Leur rôle reste d actualité dans la gestion du cycle de vie des plates-formes. PAGE 9 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

Architectes logiciels : Pour eux aussi une partie importante de l architecture se retrouvera cadrée directement par la plate-forme. Mais leur rôle va s amplifier au sein des projets. D une part, ils devront assimiler les spécifications techniques et les règles de fonctionnement des plates-formes, au service des projets candidats. D autre part, ils devront valider auprès d eux une conception logicielle et une mise en œuvre conformes aux règles et optimisées sur le plan technique et économique. Dans un autre contexte, leur rôle reste essentiel pour constituer l architecture logicielle de l offre d une plate-forme PaaS (qu elle soit interne ou externe, aussi bien pour les architectes des entreprises utilisatrices que pour les architectes des fournisseurs). Intégrateurs techniques, aussi connus comme Intégrateurs d Exploitation (cf. nomenclature cigref 2011, chapitre 4.6) : Eux aussi devront assimiler au minimum les spécifications techniques des plates-formes des projets et applications dont ils ont la responsabilité. Ils devront surtout assimiler les outils, les interfaces techniques et les processus imposés par ces plates-formes, pour la fabrication des applications et pour leur exploitation en vie courante. Exploitants en vie courante, Exploitants applicatifs, Exploitants d infra PaaS, Exploitants d infra IaaS, Pilotes d Exploitation (cf. nomenclature Cigref 2011, chapitre 4.7).En phase de vie courante, ils devront exploiter les applications déployées sur des plates-formes PaaS au même titre que les autres applications historiques. Ils devront assimiler les modes de fonctionnement, procédures et gammes opératoires imposées par ces plates-formes. Les plates-formes internes développées sur mesure par une entreprise utilisatrice pourront respecter les standards d exploitation déjà en vigueur. Les plates-formes acquises, hébergées en interne ou les plates-formes externes imposent actuellement leur propre modèle d exploitation auquel ces métiers doivent s adapter (à ce jour, les premières plates-formes ne mettent pas en œuvre de standards en la matière). Développeurs de grands groupes, en Sociétés de services ou Indépendants : Quelle que soit leur origine, les concepteurs et les développeurs doivent assimiler les composants logiciels proposés (middleware, plugins), leurs spécifications, et les interfaces programmatiques des plates-formes qu ils mettent en œuvre afin de concevoir et développer les applications. Sociétés marketing/évènementiel, Vendeurs de solutions SaaS : tout fournisseur qui souhaite proposer une offre de service sur Internet (qu elle soit proposée en mode SaaS ou non) bâtie à l aide d une plate-forme PaaS, doit assimiler la technologie de la plate-forme pour chacun des métiers intervenant. 1.3 Environnements spécifiques pour le Build et le Run Dans les premières offres de PaaS les outils de gestion de cycle de vie des applications étaient peu répandus. Cette situation évolue actuellement. On observe deux tendances. PAGE 10 Une partie des fournisseurs promeut un modèle de développement intégralement interne au Cloud. Ils proposent l équivalent d une suite d applications de

développement des applications en mode SaaS (des services de développement tels un gestionnaire de versions et de contenus, un système de gestion de droits, un serveur d intégration, etc.) en frontal de leur plate-forme PaaS. C est par exemple le cas de CloudBees. D autres fournisseurs s orientent plutôt vers une logique de développement local avant chargement vers le PaaS, quitte à fournir des outils additionnels pour communiquer avec le service PaaS. Par exemple Cloud Foundry propose une machine virtuelle à faire tourner en local sous VMPlayer, Google propose un plugin Eclipse Google App Engine pour de la simulation. Dans l ensemble, nous considérons que le lien entre outils de développement et environnements d exécution PaaS reste faible et lacunaire. Notons aussi que certains fournisseurs proposent dès maintenant de piloter les opérations de développement et d exploitation depuis une console unique. Ce mode de fonctionnement intéressant reste rare. 1.4 Qu héberger en mode PaaS public? Les fournisseurs de services PaaS assurent que leurs plates-formes sont totalement polyvalentes et adaptées au développement, aux tests utilisateurs, à la réalisation de Proof-of-Concepts (prototypes, maquettes, PoC), mais aussi capables de recevoir des applications en production. Et de fait, de leur point de vue, il n existe pas de différence entre plates-formes de développement et de production ; seul l utilisateur décide de ce qu il fait avec le service. Le problème qui se pose est ici exactement le même qu avec les plates-formes de type IaaS. Il n existe pas d engagements de SLA comparables à ce qu une grande entreprise est en mesure d exiger d un hébergeur par exemple (ceci est souvent vrai pour l engagement sur la disponibilité de la plateforme, et pratiquement systématique pour l engagement sur les performances). Il paraît donc prématuré d envisager l utilisation de ces platesformes en production. L adoption de ce type de solutions par les développeurs sans consultation préalable de la Production, risque pourtant parfois d obliger la Production à prendre en charge des applications PaaS dans des conditions encore précaires. Le PaaS public constitue donc un bon candidat pour la création de prototypes (PoC) et de pilotes. Pour le reste, le problème du passage en production n est pas encore résolu, personne ne sait comment ré-internaliser proprement un développement effectué sur une plate-forme PaaS. Il y a là un point d attention que devront lever les fournisseurs. 1.5 Frameworks Les plates-formes PaaS publiques réduisent souvent les possibilités de choix d un framework de développement, puisqu elles n en proposent qu un ou quelques-uns. Le Framework n est toutefois pas systématiquement imposé, néanmoins, chaque PaaS comporte son propre cadre, avec des outils logiciels, des API, des composants spécifiques. Les entreprises savent que la normalisation des frameworks de développement est une bonne chose, sauf qu avec le PaaS les choix appartiennent plus à l offreur du service qu à l entreprise qui doit se plier aux décisions de son PAGE 11 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

prestataire. Ne soyons pas caricaturaux, et reconnaissons à certains fournisseurs une large ouverture. Mais d autres se montrent plus restrictifs : CloudFoundry impose par exemple d utiliser le Framework Spring dès lors que l on choisit la filière Java. Imposer des frameworks, et donc des normes aux développeurs, constitue un moyen de raccourcir les délais de développement en réduisant la procédure de prise de décision et en unifiant les développements autour d un socle commun sur lequel capitaliser de l expérience et de l expertise. Ceci étant, cette rationalisation imposée ne convient pas forcément aux grands groupes qui possèdent un historique important, voire même une «culture technique» accumulée au fil du temps, et qui effectuent des choix stratégique de normalisation sur des environnements de développement qu ils définissent eux-mêmes au plus près de leurs besoins métier. 1.6 Gérer les architectures hybrides avec le PaaS Le modèle du Cloud public ne constitue pas une panacée pour les grands groupes qui se montrent plus intéressés par le fonctionnement sur un modèle hybride où les applications résultent de combinaisons de traitements internes et de traitements abrités sur le Cloud public. Ceci résulte en particulier de la volonté de rester maître de certaines données sensibles et de certains traitements critiques dont le déplacement vers l extérieur ne paraît pas envisageable pour des raisons stratégiques, légales et de politique technique interne. Cependant, le mode de fonctionnement hybride suppose de disposer de bonnes possibilités d interfaçage entre IT interne et Cloud, couvrant les différentes dimensions techniques mises en jeu dans ce mode de fonctionnement : interfaçage logiciel par le biais d APIs et de SDKs, interfaçage de sécurité par le biais d outils d IAM (Identity and Access Management), transferts de données, et même interfaçage des fonctions d administration et de monitoring que nous traiterons plus bas. Voici une liste de points de vigilance et de constats sur les domaines Sécurité, Identity and Access Management, Transfert de données : IAM : De façon générale, l interfaçage des solutions PaaS avec les annuaires d entreprise pour la mise en place de chaînes IAM est théoriquement largement faisable, mais dans la réalité mal pris en compte à ce jour. PAGE 12 Il est difficile d intégrer les annuaires d entreprise avec les plates-formes PaaS (y compris lorsqu un même éditeur fournit les deux, comme dans le cas d Active Directory avec Azure!) Le protocole LDAP ne s avère pas fonctionnellement suffisant pour la gestion du mode hybride. Connections / versions / NTLM... des problèmes techniques rendent cette feature Microsoft affichée difficile à mettre en œuvre au sein des applications (en effet, ce sont les développeurs qui doivent la mettre en place, qui ne sont pas forcéments des expertes IAM). Le protocole standard d échange d informations de sécurité SAML reste peu répandu L intégration d une PKI avec un service de Cloud public reste difficile Des protocoles d authentification comme OpenID et OAuth sont encore rarement supportés nativement par les offres PaaS.

Relevons cependant qu une meilleure prise en compte des fonctions de gestion d Identités figure dans le calendrier d évolution de plusieurs fournisseurs. Sécurité : Les souscripteurs à un service PaaS ne disposent que de peu de visibilité sur les mécanismes de la plate-forme. Rien n est prévu pour leur permettre de descendre dans les couches basses du système, et le niveau de contrôle reste faible. Les garanties de service sont faibles ou inexistantes. Il y a donc encore un problème de sécurité avec le PaaS alors que les équipes sécurité ont commencé à accepter l utilisation de services IaaS. La question des droits à attribuer aux consommateurs de PaaS (administration complète, partielle, temporaire, etc.) reste ouverte en l absence de bonnes pratiques claires. Ces bonnes pratiques doivent en général être établies, appliquées et surveillées par les équipes sécurité des clients du PaaS. Transfert de données : De façon générale, nous constatons la faiblesse actuelle de la prise en compte des besoins d import et d export de données depuis et vers les plates-formes PaaS. Ce point est difficile à adresser efficacement, en particulier du fait des importantes volumétries à faire transiter entre infrastructures publiques et privées. Pour l initialisation de bases de données (du fait du volume initial) ou la récupération de données, la méthode manuelle qui consiste à envoyer un disque dur vers son prestataire de services reste très efficace. Les outils et protocoles classiques et standards sont peu adaptés au Cloud public et pas toujours intégrés ou intégrables. Le fonctionnement en mode échanges de fichiers reste souvent impossible : - CFT pour les gros transferts de fichiers est inutilisable - la fiabilisation des échanges nécessiterait de réinventer un mécanisme de sécurité par-dessus http par exemple, sachant que ce protocole n assure pas de garantie d acheminement. Quelques vendeurs commencent à proposer des solutions (appliances de transfert, logiciels dédiés, partenariats) pour gérer et optimiser les transferts. Sur l ensemble de ces sujets, une offre de type Middleware-as-a-Service voit le jour afin de prendre en compte les problématiques d acheminement et les connecteurs. Les fournisseurs Cloud ont compris qu il y avait un marché à explorer. 1.7 Administration et Exploitation des offres PaaS Ce domaine souffre lui aussi d une maturité peu avancée au regard des standards auxquels sont habituées les grandes entreprises avec leurs outils internes. Deux tendances se dégagent actuellement, pas toujours mutuellement exclusives : La mise à disposition d une console Web d administration La mise à disposition d un système de commandes shell avec options (CLI pour le déploiement et l administration). PAGE 13 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

Les fonctions standards actuelles fournies par les prestataires PaaS sont : gestion du compte, upload, paramétrage, supervision, contrôle de l usage (facturation), etc. De nombreuses faiblesses persistent concernant l intégration de ces outils avec les processus d exploitation des entreprises, ainsi que pour la gestion des opérations de sauvegarde et restauration. L interface en mode CLI offre l avantage de pouvoir être intégrée assez aisément dans des automatismes existants, qu il s agisse de scripts de pilotage préexistants ou construits pour l occasion, ou bien encore de logiciels de pilotage ou d orchestration dès lors qu ils disposent de la capacité d invoquer des commandes externes. Mais dans ce contexte, si tout est possible, tout reste à faire pour intégrer l administration et l exploitation d une plate-forme PaaS dans un dispositif existant. A contrario, une console web d administration offre l avantage d une prise en main plus rapide, avec des fonctions plus évoluées de pilotage et de gestion de la performance, mais elle impose alors un outil supplémentaire aux métiers (intégrateurs d exploitation, pilotes d exploitation) ce qui n est pas souhaité lorsque l on cherche à optimiser son exploitation en rationalisant les outils. Exemple ci-dessous : le dashboard de la console web Google App Engine PAGE 14 En matière d administration, un problème particulièrement préoccupant apparait. Les montées de versions des composants de la plate-forme PaaS ne sont pas négociables, et parfois imposées sans information préalable et suffisamment claire du client. Cette façon de procéder impacte le cycle de vie des applications, et en particulier le financement de leurs évolutions par les métiers utilisateurs. En effet dans un tel modèle il devient impossible après un développement initial de laisser fonctionner plusieurs années durant une application sans lui apporter de modifications ; il y a contrainte de mise à jour technique et donc de coûts de mise à jour avec une valeur ajoutée métier nulle.

Les fonctions de supervision, de gestion de performances et d émission d alertes restent limitées. En conclusion : quelques fournisseurs en pointe proposent une console web avec un niveau fonctionnel qui permet de piloter et superviser la plate-forme. D autres se contentent pour démarrer du mode CLI. Pour une petite entreprise, une console web peut éventuellement suffire en l état pour piloter une application en PaaS à condition d accepter d intégrer un outil spécifique. Pour les entreprises plus cadrées au niveau exploitation, c est le problème d intégration avec les outils existants et les processus d exploitation qui peut être rédhibitoire. Ci-dessous quelques exemples de points d attention et questions opérationnelles à se poser avant de se lancer dans le PaaS public : Alertes de disponibilité et informations de performance (capacity management) : qui les consomme et devrait les recevoir : développeurs? Équipes de production? qu a-t-on réellement besoin de superviser sur une plateforme PaaS (à choisir judicieusement car superviser du PaaS est plus complexe que de l IaaS)? doit-on installer des frameworks dédiés à la gestion et l analyse des performances? y en a-t-il de fournis dans les offres PaaS? Backup : à quel niveau sauvegarder les données: IaaS (basique, générique) ou PaaS (intelligent, portable, par objet métier)? doit-on utiliser les outils de sauvegarde du fournisseur (PaaS public) ou implémenter ses propres méthodes (ex snapshots)? 1.8 Modèles économiques et engagements de qualité de service Les modèles économiques du Cloud restent complexes, et le PaaS n échappe pas à la règle. Les modèles suivants se rencontrent tous, et parfois même plusieurs d entre eux cohabitent chez un même fournisseur : Facturation à la ressource avec des niveaux de détail très variable dans la définition de cette ressource (puissance processeur, entrées-sorties disques, écritures dans des bases de données, mémoire vive, volume de stockage, etc.) Packs forfaitaires avec produits d appels et planchers, plafonds, seuils d utilisation. Facturation modulaire par services sous forme de plug-in payants ajoutés sur une base. PAGE 15 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

Cette complexité incite à se poser la question de l optimisation des coûts, éventuellement en prenant en compte les spécificités du modèle de facturation pour les intégrer dans le développement. Si un fournisseur facture les entréessorties d une base de données à un coût plus élevé que celui qu il ne facture pour de la mémoire vive, il faudra privilégier un fonctionnement de type en mémoire dans la conception des applications pour de simples raisons économiques. Le mode de facturation pourrait dicter dans une certaine mesure l architecture interne du développement, ce qui serait contraire aux bonnes pratiques d architecture. L architecte doit parvenir à conserver sur le Cloud des principes d architectures indépendants des modalités de facturation de ses fournisseurs, en raison de leur caractère hautement volatile en comparaison de la durée de vie des applicatifs. La complexité de cette tarification se double de risques de modifications unilatérales du modèle économique, peu de fournisseurs s engageant à conserver sur des durées raisonnables un mode de facturation. Fin 2011, Google a par exemple décidé de modifier les paramètres de facturation de sa plate-forme App Engine (en passant du mode bêta qui existait auparavant au mode actuel). Enfin, comme nous l avons déjà souligné, les engagements de SLA et de disponibilité restent faibles, et les garanties en matière de sécurité ou de temps de réponse quasi nulles. 1.9 Réversibilité, portabilité entre plates-formes Comment en sortir? Comment déplacer des applications développées sur une plateforme PaaS vers une autre, ou comment les rapatrier en interne? Pour le moment la situation n est pas réellement adressée par les fournisseurs. Dans certains cas, l utilisation d API et de frameworks propriétaires, le manque de contrôle sur les versions des composants utilisés constituent autant de freins à la portabilité. Même pour un PaaS fondé sur une pile relativement standardisée comme LAMP (Linux, Apache, MySQL, PHP) ou ses équivalents, le prestataire de services conserve la main sur les versions de socle qu il met en œuvre. Et pour des raisons de coût d exploitation il ne maintiendra probablement qu une mince combinaison de socles. Dans ces conditions, il paraît assez difficile à ce jour d être certain de trouver une plate-forme concurrente de celle sur laquelle a été effectué un premier développement et qui offre une compatibilité suffisante pour autoriser un portage. La récupération des données n a pour sa part pas été prévue, il faudra donc traiter en mode applicatif ce type d opération, en développant une passerelle spécifique. Il n existe de fait aucun standard qui garantirait la portabilité entre plates-formes, même si quelques initiatives commencent à voir le jour. Nous ne pouvons qu appeler à un travail de la part d organisations internationales qui seraient en mesure de définir un cadre de portabilité. 1.10 Conclusion PAGE 16 A ce stade, le PaaS apparaît comme un domaine en pleine croissance, et de ce fait en quête de maturité. On oserait dire que le PaaS a la figure d un adolescent du Cloud : prometteur, mais pas encore totalement formé, même si certains éléments se laissent deviner.

Il monte en puissance à la fois comme une extension logique de l IaaS, mais aussi comme une déclinaison du SaaS, puisque certains éditeurs proposent des extensions PaaS à leurs offres SaaS. Il porte plusieurs promesses. Accélérer radicalement la mise à disposition d environnements complets. Contribuer à l agilité du cycle Développement/Production, en réduisant en particulier les écarts existant aujourd hui entre ces environnements. Une telle évolution peut s inscrire dans une démarche comme celle proposée par le mouvement Devops. Il s agit au bout du compte de réduire les temps de Time-to- Market lors de la création de nouvelles applications et de la mise à disposition de nouveaux services. Automatiser les opérations de provisioning mais aussi de libération de ressources lorsqu elles ne se trouvent plus sollicitées. Ce point vise un double objectif : apporter une réponse calquée au mieux sur les besoins des métiers d une part, optimiser les coûts en ajustant l usage des ressources de l autre. Le PaaS dessine et cadre de nouveaux patterns d architecture technique et logicielle (web 2.0) qui amèneront une évolution des métiers de l informatique chargés de sa mise en œuvre. Intéressantes promesses, mais qui restent baignées de beaucoup de flou. L offre jeune, en phase de croissance, est encore très diversifiée, avec des acteurs majeurs et des challengers, pas stabilisée ni standardisée, et cette absence de standards lui nuit. De plus il s agit pour le moment le plus souvent d offres externes, de type public. Cela correspond dès maintenant aux besoins des petites structures, mais ne rentre pas dans les exigences des grandes entreprises qui exercent un contrôle plus étroit sur leurs environnements techniques. Et le modèle économique reste sinon confus du moins peu lisible. Il devra être simplifié. Bien sûr, les concepts du PaaS s avèrent dès maintenant en phase avec les besoins de certains projets, mais les offres ne correspondent pas à une possibilité de mise en production maîtrisée comme cela se pratique dans les grandes structures. Des fonctionnalités manquent : le fonctionnement en mode hybride, les outils de pilotage nous semblent les plus critiques, ainsi que l absence de réversibilité. Les fournisseurs promettent de prochaines déclinaisons de leurs plates-formes sous forme de PaaS privés, mais en attendant, les entreprises intéressées doivent concevoir leur PaaS elles-mêmes. Aujourd hui le PaaS constitue déjà une plate-forme de choix pour la réalisation de maquettes, ou pour des applications à cycle de vie rapide, jetables au bout de quelques mois, et qui ne réintégreront jamais pleinement le SI de l entreprise. Mais il ne semble pas encore mûr pour une production pleinement contrôlée. Cela ne saurait qu évoluer dans les prochains mois. PAGE 17 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

2Sécurité et Cloud Computing On sait que la sécurité fonctionne transversalement à toute démarche d Infrastructure et Production ; tout projet demande donc de se poser une double question : Quels risques de sécurité découlent de ce nouveau projet? Quels moyens faudra-t-il mettre en œuvre pour assurer la sécurité? Et à quel coût? La sécurité se pense donc toujours sur deux fronts : une démarche technique de sécurisation et une démarche de réflexion sur les impacts de l introduction d un nouveau composant du Système d Information. Le Cloud Computing n échappe pas à la règle, on peut même dire qu il l illustre de façon excellente. Non seulement assurer la sécurité du Cloud pose problème, mais en plus les effets de bord de ses usages sur la sécurité restent encore difficiles à appréhender. Nous souhaitons ici exposer l état de nos réflexions sur le sujet, mais aussi affirmer que la défiance ne suffit pas. Le Cloud Computing provoque une série de ruptures dans la Production comme dans la consommation des services informatiques. Ces ruptures affecteront les organisations et doivent s accompagner d une réflexion sur la sécurité. De même que le modèle client-serveur a remis en cause les modèles de sécurité issus de l Informatique centralisée, de même que les architectures Web ont remis en cause les modèles de sécurité des architectures client-serveur, le Cloud Computing demandera une extension des paradigmes de sécurité. Il n y va d ailleurs pas que de la protection des avoirs numériques de l entreprise et de sa réputation, mais aussi de son futur fonctionnement et de sa future agilité. 2.1. Le Cloud vu par les RSSI La pression mise par les utilisateurs et les métiers sur les directions informatiques rend incontournable à plus ou moins brève échéance le recours au Cloud. Mais les questions de sécurité et d intégration à l existant constituent un frein majeur à une adoption rapide et massive de ces solutions. PAGE 18 Les RSSI, dont c est la fonction, rappellent qu il n est pas question de laisser leurs données circuler n importe où, et en particulier dans des environnements tiers dont le contrôle échappe entièrement à l entreprise. L exigence de confidentialité doit s appliquer. Une première solution consisterait à trier, à définir dans une politique de sécurité d entreprise quelles données peuvent ou ne peuvent pas sortir de l enceinte numérique directement sous contrôle de la RSSI. Plus facile à dire qu à faire, car comme le rappelle un RSSI : Passer sur le Cloud pose le difficile problème de la qualification des données. Comment définir ce qui est confidentiel et ce qui ne l est pas?.

Ce problème possède lui aussi une double composante. Il n est pas toujours simple de savoir et de décrire dans une politique d entreprise ce qui est confidentiel, si on en excepte les documents soumis à réglementation. Mais il est encore moins simple d exiger des utilisateurs qu ils classifient tout document, tout fragment d information qu ils produisent, sur une échelle de confidentialité. Il faut donc atteindre le bon niveau d automatisation, mais aussi de responsabilisation pour les informations qui ne peuvent se voir automatiquement cataloguées. Comme l affirme un autre RSSI : La sécurité ne se juge pas seulement en termes de confidentialité des données, nous avons aussi une responsabilité dans leur disponibilité. Ce point n a pas moins d importance que le précédent. Les problèmes de confidentialité et de sécurité se trouvent de plus en plus liés. Une faille de sécurité risque très souvent de se traduire par un problème d indisponibilité (s il faut remonter une base de données corrompue, faire le ménage dans des informations modifiées hors de tout contrôle, mettre fin à une attaque par déni de service, etc.). La disponibilité n est que l autre face de la sécurité. Or, les fournisseurs Cloud externes ne brillent pas par la qualité de leurs clauses contractuelles en matière de disponibilité. Nous pouvons étendre ce problème en considérant que le Cloud pose aujourd hui un problème global de contrôle qui se manifeste dans de multiples objections à son usage : contrôle des politiques de sécurité des fournisseurs au sein de leur Cloud, contrôle de la disponibilité des services, contrôle des échanges entre l IT interne et les différentes formes de Cloud, contrôle des conditions de cohabitation entre applications et entre clients. D autre part, les DSI ne peuvent que constater que l utilisation du Cloud se propage au sein de leur écosystème via l adoption sauvage par les salariés de services proposés par des sociétés tierces telles Dropbox, Google Docs, icloud, etc. Ces usages, difficiles à bannir dans un contexte d environnements de travail de plus en plus mobiles et connectés, posent les mêmes questions que l adoption du Cloud en interne : quid de la sécurité des données? Comment éduquer efficacement les utilisateurs sans empiéter sur leur vie privée? Comment sensibiliser aux risques une population pour laquelle l usage du Cloud représente avant tout un gain de productivité? a) Craintes liées au Cloud Les principales craintes évoquées lorsque l on parle de Cloud concernent la confidentialité, la disponibilité et l étanchéité des données et des charges applicatives. Ce dernier point, celui de la promiscuité applicative, est particulièrement critique. L isolation des workloads sensibles et/ou critiques est une règle rarement ignorée en entreprise. Le Cloud, reposant sur un principe de mutualisation systématique et poussée ne connaît pas ce mode de fonctionnement. L entreprise ne contrôle pas le placement de ses applications, ce qui constitue une menace potentielle pour leur disponibilité comme pour l intégrité des données qui y résident. Le premier élément de réponse réside dans le choix du type de Cloud à adopter : privé ou public, interne ou externe. Il est à noter que de par sa nature, ce choix n est le plus souvent pas du ressort du CTO, mais de la DSI et du RSSI. PAGE 19 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

Alors qu un Cloud public-externe présente à priori un intérêt financier plus grand qu un Cloud privé-interne ou même qu un Cloud privé-externe, il pâtit souvent du manque de confiance que les RSSI ont en leur prestataire et de l imparfaite transparence dont font preuve ces prestataires quant aux garanties qu ils apportent à leurs clients. Il existe avec le Cloud pour le moment un problème de confiance, on ne sait pas à quel point faire confiance à ces acteurs., confirme un troisième RSSI. Si le Cloud public convient à certains usages (développement, tests, recette), l utilisation d un Cloud privé externe offre davantage de garanties, notamment via la possibilité d auditer la plateforme dédiée à l entreprise. Cependant, certains RSSI 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. Certaines clauses contractuelles permettent cependant d engager le fournisseur à mettre en œuvre les mesures préconisées. Alors que la certification apparaît comme un recours possible, d autres réticences apparaissent : Les certifications telles qu elles existent ne nous disent rien sur la sécurité réelle mise en place. Même au travers d une certification, comment allezvous apprendre que votre prestataire a par exemple déplacé ses administrateurs en Inde?. Les RSSI s accordent à partir de là à considérer qu un usage du Cloud modéré - est acceptable pour certaines catégories de données, non-sensibles, ou dans un contexte de chiffrement qui lève les problèmes de confidentialité. Mais comme le rappelle un membre du Groupe de Travail : 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. De plus, les RSSI constatent que l application à grande échelle des pratiques de chiffrement reste complexe, et d autant plus complexe que l utilisateur conserve la responsabilité de pratiquer ou pas ce chiffrement. Il faut garder à l esprit que le point de vue d un responsable de production informatique d une PME qui remplit en général également les fonctions de DSI/RSSI peut être très voire radicalement différent. En effet, certaines PME se considèrent plus sécurisées sur un cloud opéré par un grand fournisseur que lorsque c est la PME elle-même qui opère l infrastructure (problématique des compétences et de la masse critique des équipes). b) Avantages/Inconvénients PAGE 20 Il est nécessaire de rappeler les avantages et les limites que le Cloud procure en raison de son modèle de fonctionnement. Ces avantages sont principalement économiques. En effet, le Cloud présente de très bons coûts initiaux, mais qui évoluent ensuite linéairement; tandis qu avec des plates-formes internes les coûts initiaux élevés tendent à s affaiblir avec le volume d utilisation. La tarification à l usage permet d envisager des gains importants sur les environnements de tests ou de recettes qui ne font pas l objet d un usage intensif mais qui immobilisent des ressources de l entreprise.

Dans l estimation de ces gains, il faudra pour être complet prendre en compte les coûts de mise en place de l infrastructure de sécurité permettant de faire dialoguer les serveurs mis sur le cloud et ceux qui restent dans l entreprise (les cas où on peut mettre des serveurs sur le cloud sans avoir ensuite besoin de dialoguer avec l interne sont marginaux). Le Cloud bénéficie aussi des avantages de standardisation et de mises à jour continues qui permettent de résoudre les problèmes de gestion de l obsolescence ou encore d apporter une réponse aux clients sur le no software (éviter les fastidieux processus d installation et de mises à jour de logiciels). Toutefois, certaines limites apparaissent dans ce modèle. En particulier le fait que les mises à jour soient déclenchées par le fournisseur. Le client doit suivre, en espérant que la mise à jour ne casse rien, ne provoque aucun désordre. Notons au passage que ces problématiques ne sont, en général, pas traitées, vu des DSI ou RSSI, de façon satisfaisante et que le passage au cloud est, de ce point de vue, perçu comme une véritable opportunité (on se débarrasse du problème en passant au cloud). 2.2. Questions de sécurité indiscrètes pour votre (futur?) fournisseur de Cloud A la lumière des échanges du Groupe de Travail Cloud, voici une liste de questions à poser à un prestataire concernant la dimension sécurité et disponibilité de son offre Cloud. Vos politiques de sécurité sont-elles écrites et consultables? OUI NON Quels sont les indicateurs relatifs à la sécurité que vous publiez? Quelle est votre politique d application des patches de sécurité critique? Le client a-t-il un droit de regard/veto sur ce type de mise à jour? OUI NON Est-il informé du passage d un patch critique? OUI NON Proposez-vous des sauvegardes? OUI NON Les échanges de données et les sauvegardes sont-ils chiffrés? OUI NON Vérifiés? OUI NON Selon quelles procédures? Comment faites-vous la gestion des clés de chiffrement? Quels sont les débits offerts en sauvegarde/restauration? Votre solution complète est-elle certifiée? (ISO 27001, SAS 70,...) OUI NON Avant mise en production (d un nouveau palier sur l infrastructure Cloud), des tests d intrusion sont-ils réalisés? Si oui, ces tests sont-ils effectués par des équipes maison ou par des équipes tierces? OUI NON Quelle est votre politique de remédiation sur les failles rencontrées? Proposez-vous des modes d interfaçage avec les annuaires de vos clients? OUI NON Le client peut-il gérer directement des pools de ressources mis à disposition sur le Cloud? (une réponse positive à cette question indique l existence d accès depuis l extérieur à des interfaces d administration de ressources qui constituent un danger potentiel de sécurité élevé, et donc aussi la question de leur sécurisation) OUI OUI NON NON PAGE 21 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

Quels moyens de sécurité mettez-vous en œuvre en Interne? Quelles remontées sur ces outils faites-vous vers vos clients (statistiques, logs partiels, au travers de quelles interfaces)? Le client peut-il demander la mise en place de sondes IPS/IDS? OUI NON Comment gérez-vous la mise à disposition de firewalls à vos clients? Quel est le niveau de maîtrise par le client du filtrage de ports sur sa VM par exemple? Idem pour les VLAN : quel est le niveau de délégation de la gestion du réseau donné au client? Les réseaux d administration sont-ils séparés des réseaux de fonctionnement normal comme c est la règle dans une majorité de salles informatiques? Le client peut-il demander sur une plate-forme IaaS la mise à disposition d images d OS durcies ou sécurisées? Peut-il fournir ses propres images? OUI NON Quels moyens d interconnexion offrez-vous entre les datacenters du client et votre Cloud? OUI OUI NON NON Quels sont les moyens mis en œuvre lors de la destruction d une VM? Comment blanchissez-vous les données hébergées sur votre infrastructure? (cf. effacement sécurisé type DoD 5220.22-M) 2.3. Perspectives / Conclusion Le concept de Cloud inclut de nombreuses nuances dont chacune peut être un élément de réponse à l optimisation de votre SI. Si l utilisation d un Cloud public externe pose de nombreux problèmes de sécurité, il peut s avérer tout à fait adéquat pour l hébergement d une plate-forme temporaire liée à un évènement ponctuel dont l impact n est pas clairement défini (exemple : jeu concours, campagne marketing ponctuelle, besoin urgent d un serveur de développement pour un PoC). La mise en œuvre sera facilitée si cette plate-forme présente peu ou pas (cas idéal) d adhérence avec le SI existant. A l opposé, l adoption d un Cloud Privé interne, simple implémentation d une solution sur étagère proposée par un éditeur ou un constructeur, réduit considérablement l impact des questions de sécurité tout en permettant de bénéficier de beaucoup d avantages du Cloud tels que la fluidification de la mise à disposition de ressources, la simplification de la refacturation interne, l assainissement de la gestion des cycles de vie, etc. Mais pour certaines entreprises, l adoption de services Cloud externes et internes constitue également une opportunité de repenser leur politique de sécurité globale, en l appuyant notamment sur la forte standardisation qu implique son adoption et en visant une simplification. Les réflexions en cours sur l évolution des modèles de sécurité, pour passer en particulier à une logique de prise en compte de contexte global de connexion (qui se connecte à quoi depuis quel terminal et à quel endroit?), montrent que le Cloud fera aussi sentir son effet dans ce domaine. PAGE 22

3Les modèles de sourcing et le Cloud Le Groupe de Travail Cloud Computing du CRiP l affirme depuis plusieurs années : le Cloud ne constitue pas une rupture technique mais d abord une nouvelle façon de produire et de consommer des services IT. Cette évolution se produit cependant sur un fond continu de problématiques, dont celle de l approvisionnement et de la contractualisation que les anglo-saxons rassemblent sous le terme de sourcing. En effet, dès lors qu il n est plus strictement privé et internalisé, le Cloud Computing se présente sous la forme d une prestation extérieure comparable mais pas similaire à des pratiques existantes comme l infogérance, l externalisation, l hébergement, etc., ce qui pose la question des modalités d achat et de suivi de la prestation Cloud. En 2011, le CRIP et l Ae-SCM (association de promotion des bonnes pratiques de sourcing et du Sourcing Capability Model, http://www.ae-scm.fr/) ont collaboré avec le Comité Infrastructures du Syntec Numérique pour la rédaction de son troisième livre blanc consacré au Cloud Computing et intitulé «Cloud Computing : nouveaux modèles!» Ce livre blanc, est accessible sur l url : http://www.syntec-numerique.fr/actualites/livre-blanc-cloud-computing- Nouveaux-modeles Il se compose de 6 chapitres allant des définitions de base et des modèles économiques aux conséquences du Cloud sur le rôle de la DSI. Il aborde en particulier les effets du modèle Cloud sur le «sourcing» des services IT. Les lignes qui suivent présentent une synthèse de ce document sur les thèmes suivants : typologie des modèles de Cloud en fonction des types d applications apports principaux du référentiel escm au mode de sourcing du Cloud Computing recommandations d ordre juridique, formulées par deux avocats ayant contribué au livre blanc 3.1. Typologie des modèles de Cloud en fonction des types d applications : quels Clouds pour quelles applications? Le Livre Blanc Cloud Computing Nouveaux Modèles du Syntec Numérique décrit divers modèles de déploiement du Cloud : Privé internalisé : les infrastructures et les réseaux sont propriété de l entreprise PAGE 23 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

Privé externalisé : les infrastructures et les réseaux sont dédiés à l entreprise mais éventuellement gérés par un tiers Public : infrastructure et réseaux sont externes à l entreprise et partagés Hybride : un mélange des modèles précédents avec une partie interne à l entreprise et une partie externe. Le livre blanc positionne sur un graphe le mode de déploiement actuellement privilégié des applications en fonction de leur degré de spécificité et de criticité. Ce graphe prend en compte quatre zones possibles de déploiement : le Cloud Public, le Cloud Privé (Internalisé ou externalisé), les zones de virtualisation (les serveurs équipés d hyperviseurs qui permettent donc un certain degré de consolidation) et enfin les silos d applications (qui sont les ressources IT les plus spécifiques et critiques de l entreprise, souvent issues de son héritage technique, et faiblement mutualisées). Ce graphe présente des lignes directrices générales telles qu elles sont constatées aujourd hui, qui seront amenées à évoluer rapidement dans le temps. Il illustre bien le fait que le Cloud se caractérise d abord par sa capacité importante à la flexibilité. 3.2. Les apports principaux du référentiel escm aux pratiques de sourcing du Cloud Computing PAGE 24 L escm (e-sourcing Capability Model) est un référentiel de bonnes pratiques pour la gestion de la relation entre clients et fournisseurs de services utilisant les technologies de l information. Il a été conçu puis publié en 2002 par l Université Carnegie Mellon qui l a ensuite confié à sa spin-off l ITSqc qui fournit des services de formation et assure la promotion de ce modèle, l Ae-SCM est l association qui favorise la diffusion et l adoption du référentiel escm par le plus grand nombre d entreprises en France.

Le référentiel escm souhaite prendre place auprès des autres grands référentiels IT (ITIL, CMMI, etc.) avec lesquels il est compatible. Il prend en compte des modèles de fourniture d IT de nature très variable : outsourcing, hébergement, TMA, fourniture de services réseaux et autres. Le Cloud Computing comportant une dimension d externalisation, c est tout naturellement que l escm propose un référentiel pour le pilotage économique du Cloud Computing et la gestion des relations entre clients et fournisseurs de Services Cloud, externes ou internes à l entreprise. Dans cette démarche, l escm recommande en particulier d élaborer et de faire évoluer dans le temps un modèle économique («business case») des Services Cloud en considérant : l évolution de la demande, en prenant en compte la montée à l échelle et l impact de la tarification, les bénéfices et coûts, y compris indirects et internes, par exemple la réduction grâce au Cloud de certains risques (disponibilité), ou bien l accroissement par le Cloud de coûts indirects comme ceux des réseaux, etc. les bénéfices et coûts de transition, comme par exemple l allocation automatique des ressources, la réduction de la durée des cycles Projets, etc. escm recommande ensuite de prendre en compte les opportunités de création de valeurs apportées par le Cloud pour les clients, en articulant ces opportunités autour d une liste de catégories : agilité/juste à temps, optimisation des ressources, coûts, conformité, qualité de service, cohérence technologique et interopérabilité, innovation par l offre, innovation métier, différenciation. PAGE 25 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

En ce qui concerne la contractualisation de services Cloud, escm propose une liste de plus de 50 points de contrôle, dont on citera les principaux : PAGE 26 escm identifie le besoin émergent, côté Clients, d un rôle de Contrôleur de Services Cloud. Cette fonction pourrait être tenues par des acteurs indépendants à l instar des auditeurs financiers. Le Contrôleur de Services Cloud aurait pour mission de s assurer de la bonne réalisation des clauses contractuelles.

Enfin, escm identifie une évolution concernant les activités de pilotage opérationnel, tactique, ou stratégique des services Cloud, amenant à une nouvelle Gouvernance de l externalisation. Ce tableau résume les éléments clé de ce paysage du pilotage opérationnel en environnement Cloud : Comme on le voit, ces éléments de réflexion s inscrivent dans la continuité directe de nos remarques sur l évolution des Métiers présentes dans notre Livre Blanc 2011. 3.3. Recommandations d ordre juridique sur les Contrats portant sur les services Cloud, formulées par deux avocats ayant contribué au livre blanc Le Livre Blanc du Syntec numérique fait un point sur les considérations juridiques afférentes aux contrats de services Cloud. Nous en isolons les points suivants, qui nous semblent les plus saillants. - Veiller aux garanties sur les données à caractère personnel en application de la loi Informatique et Libertés pour les données hébergées en France ; clause spécifique couvrant la confidentialité et l intégrité des données confiées, avec des dispositions (audits de sécurité) afin de s assurer de l effectivité des garanties offertes en matière de protection des données. Point d attention particulier pour les entreprises : savoir si le prestataire propose ou non les «model clauses» décidées par la Commission Européenne en 2010. Privilégier les contrats comprenant cette garantie importante. - Le contrat doit aborder de manière précise la question des niveaux de service aussi bien dans leur description que dans les procédures attachées à leur suivi : périmètre d engagement, mécanismes de calcul de respect ou de non-respect de ces niveaux de service, conservation des éléments de preuve, conséquences en cas de non-respect de ces engagements, mécanismes d escalade en cas de désaccord entre les parties. PAGE 27 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

- Il ne faut pas oublier la question de la réversibilité : comprendre la fin du Contrat et définir les modalités de reprise de ce qui a été fourni en mode Cloud. - Il importe de préparer la conclusion d un contrat de service Cloud avec des équipes de travail transverses impliquant notamment les DSI, les métiers, les achats, ainsi que les juristes et les avocats. 4 Facturation et refacturation dans le Cloud La facturation à l usage est un des piliers du Cloud Computing : cela se comprend simplement. Si nous voulons «l informatique à la demande», nous voulons que son impact financier apparaisse «à la demande» aussi! Le principe établi, restent quelques questions : Dans le cadre du déploiement d un Cloud de type privé, comment mettre en place une facturation des services à l usage, quels sont les critères pertinents sur lesquels fonder cette facturation? Ce Cloud privé peut-il être une étape vers un service de refacturation interne? Comment aborder le Cloud public en terme de refacturation et métriques dans les usages budgétaires d une société? Sans oublier des approches qui peuvent être différentes dès que l on parle de IaaS, PaaS ou SaaS Toutes ces questions ont été discutées lors des réunions du Groupe de Travail Cloud Computing. Ce document reprend les thématiques abordées et propose des pistes d investigation. 4.1. Collecte des métriques PAGE 28 Dans un contexte de réduction des coûts IT, préoccupation permanente des directions Infrastructures, les projets de consolidation et de mutualisation de la Production informatique, en s appuyant sur une virtualisation de plus en plus poussée, ne sauraient être menés sans une gestion des capacités appropriée. La virtualisation des infrastructures se généralise, elle exige effectivement ce type de démarche : connaître la capacité disponible, optimiser le taux d usage, anticiper l accroissement des ressources en fonction des besoins, pour ne citer que les points clés.

Avant même la transformation d une infrastructure de production en Cloud privé, l identification des indicateurs signifiants pour la maîtrise du «Capacity Management» constitue une étape essentielle. A titre d illustration, le «schéma capacitaire» ci-dessous, représente les différents indicateurs et leur niveau d agrégation : Au-delà des métriques techniques, qui correspondent à l usage effectif des ressources d infrastructures (Processeurs utilisés, mémoire, stockage, bande passante réseau, nombre de requêtes, etc.), il convient aussi de mesurer le niveau de service (taux de disponibilité, temps de réponse, etc.) et des indicateurs sur la nature même de l activité métier (nombre de transactions réalisées, nombre d utilisateurs d un service, quantité de flux échangés, etc.) PAGE 29 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

4.1.1 Métriques techniques Les premiers indicateurs sont des métriques techniques qui mesurent l utilisation et la disponibilité des infrastructures, par exemple : Taux d usage des serveurs : CPU, Mips, nombre de serveurs virtuels, etc., Occupation de la mémoire : RAM, Stockage : espace alloué, taux d utilisation (nombre d I/O), taille des blocs, type de supports utilisés (high-end, mid-range, archivage), Réseau : taux d usage de la bande passante, (Mo entrants, Mo sortants). Dans cette classe d indicateurs, la mise en équivalence des taux d usage des serveurs (taux CPU) permet d introduire une unité d œuvre indépendante de la nature et de la puissance individuelle des différents serveurs. Cette unité de mesure «équivalente 1» constitue ainsi un indicateur d usage de la puissance serveur consommée, quelle que soit la puissance spécifique du type de processeur utilisé et de l operating System (Linux, Windows, Unix). Ce type d unité d œuvre est effectivement utile pour mesurer et refacturer l usage des serveurs en fonction des projets ou des applications. Pour les fournisseurs de service «IaaS», la facturation se calcule généralement en fonction du trafic, du stockage et de la puissance des processeurs utilisés. Selon le type et le nombre de machines virtuelles mises à disposition, le fournisseur détermine la puissance processeur utilisée. Dans le cadre de services «PaaS», des variables complémentaires peuvent être prises en compte, en complément des métriques propres à l usage «IaaS». Cette seconde classe de métriques s adresse à l usage des middlewares par exemple : Nombre de requêtes SGBD (Oracle, Mysql, etc.), Nombre de requêtes HTTP, Temps de traitement des requêtes transactionnelles (Tomcat, Jboss). Cette classe de métriques rend possible la ventilation des coûts logiciels Middlewares, en fonction de leur usage, par application ou projet. PAGE 30 Le coût prévisionnel d une infrastructure «IaaS», voire «PaaS», compte tenu de la variabilité des indicateurs retenus, peut s avérer complexe à déterminer. A titre d exemple, l hébergeur Amazon propose une grille d évaluation pour estimer le coût mensuel d hébergement 2 sur ses infrastructures : 1 A titre d exemple, on peut citer des unités de mesure standardisées comme celles que propose le Transaction Processing Performance Council (TPC-C, TPC-H, etc) ou le Standard Performance Evaluation Corporation (SpecCPU, SpecVirt, etc.) ou des unités propriétaires comme le SMIPS proposé par Systar 2 Amazon Simple Monthly Calculator (http://calculator.s3.amazonaws.com/calc5.html)

On pourrait imaginer, à l instar de l usage de l électricité, que les services Cloud deviennent une «commodité» dont la facturation fasse abstraction de la complexité et de la nature des composantes d infrastructures sous-jacentes. Ainsi, la facturation pourrait être consolidée sur la base d un coût fixe (CAPEX) et d une unité d œuvre (OPEX) inspirée de l énergie : [ABO > accès au service Cloud] Coût fixe (~abonnement) [CUH > Cloud Unit per hour] Coût variable (~consommation) 4.1.2 Métriques SLA s Cette catégorie de métriques permet de mesurer le niveau de service et d appliquer ensuite une facturation en fonction d une grille adaptative, par application et selon la nature du contrat SLA. Cette catégorie de métriques comprend par exemple : Le taux de disponibilité, Le temps de reprise sur incident, Le temps de réponse, Système de pénalités en cas de non-respect des clauses du SLA, Etc. Une unité d œuvre incluant les «métriques SLA s» ou impactant le total par un coefficient de pondération permettrait d établir une facturation en fonction des engagements de service et impliquerait par conséquent de la part du fournisseur d infrastructures (hébergeur ou Cloud privé) un engagement sur les moyens mis en œuvre et sur les résultats. PAGE 31 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

4.1.3 Métriques Métiers ou Business Pour le responsable de projet, les métriques techniques ne parviennent pas forcément à qualifier de façon pertinente la nature des flux qui auraient plutôt du sens d un point de vue «métier». L engagement sur le résultat importe plus du point de vue métier que l engagement sur les moyens. Ce constat s applique en premier lieu aux solutions de type «SaaS», où l utilisateur achète un service final comme une boite mail, une feuille de paie Pour bien comprendre : la garantie d un taux de disponibilité (engagement de moyens) de 99,999 % pour des serveurs en mode «IaaS» rassure le métier. Mais cela ne garantit pas que les pages Web se chargeront dans un délai raisonnable pour l internaute lors de pics de trafic, ni que la gestion de capacité associée aux infrastructures permettra la livraison effective du service, notamment dans un mode «SaaS» (exemple : un site évènementiel mis en place pour une durée définie et couplé à une campagne marketing : le site doit être en mesure d encaisser une forte montée en charge, qui peut dépasser les prévisions). L alignement des services d infrastructure sur les indicateurs métiers plutôt que sur les indicateurs techniques implique aussi la mise à plat des composantes du contrat de service et des indicateurs pris en compte pour facturer à l usage. Ces métriques devraient constituer également autant «d indicateurs pertinents» en fonction de la nature du métier et de l application. Pour un site de e-commerce par exemple, le nombre de transactions réellement abouties est plus critique que le nombre de pages vues. Dans ce cas, baser la facturation à l usage sur ce nombre de transactions suppose effectivement que les métriques techniques, qui restent significatives pour suivre et adapter l usage de l infrastructure sous-jacente, soient suffisamment efficientes pour adapter l infrastructure en fonction du trafic. La mise en place d une solution BAM 3, permettant la collecte et l agrégation d indicateurs clés (KPI 4 ) correspondant à l activité réelle des processus métiers, pourrait être déployée pour «mesurer» l activité métier supportée par l infrastructure Cloud et par suite intégrer ces «métriques métiers» dans le système de facturation. L adoption d un modèle de facturation aligné avec les indicateurs métiers ne présente pas a priori d obstacle technique. Elle implique cependant un profond changement de culture et d adaptation pour répondre aux exigences des métiers, en termes de «commodité» d usage des services Cloud (hébergés ou via un «cloud privé») et de transparence des coûts (payer au juste prix ce que l on consomme!). 3 Business Activity Monitoring Supervision des activités de l entreprise 4 Key Performance Index ou «Indicateurs clés de performance» PAGE 32

4.2. Reventilation des coûts : Showback ou Chargeback La collecte des différentes métriques (techniques, SLAs, Métiers), via un ou plusieurs logiciels appropriés, permet de constituer une base d indicateurs à destination d usages divers : Gestion de capacités, Etudes de performances, Tableaux de bords, Planification budgétaire, Etc Sur lesquels il convient d ajouter la composante financière (Opex / Capex & amortissement) dont la source doit-être la DAF : Contrôle de gestion In fine, cette base d indicateurs permet la ventilation des coûts vers les différents clients (hébergeur de services Cloud) ou aux clients internes de l entreprise (Business Units, métiers) dans le cas d un Cloud privé. C est généralement l entité «pilotage économique» de la direction technique ou DSI qui porte le sujet et possède la maîtrise des calculs, tout en y associant de près le Contrôle de gestion afin d obtenir le tampon financier, sésame souvent indispensable pour la diffusion des coûts vers les clients internes. La facturation des services à l intérieur de l entreprise, pour l usage d un Cloud privé ou pour l ensemble des services d Infrastructure, reste un problème complexe. Dans la plupart des cas, les entreprises sont structurées en silos autonomes avec pour chacun leurs budgets propres et peuvent ainsi facturer les services entre les différents silos («Cross-Sharing»). Le fait de facturer les services en fonction des ressources utilisées, pour les organisations qui ne possèdent pas de système de refacturation interne, constitue un changement important. Avant de passer à la phase de facturation effective des services («ChargeBack»), il est préférable d adopter une phase «éducative» visà-vis des clients, visant à afficher les coûts à facturer en fonction des ressources utilisées (solution de «ShowBack»). Le «ShowBack» peut aussi être utilisé pour mettre au point un système de tarification adapté, vérifier son impact en fonction de l usage des ressources, avant de le généraliser dans le système réel de «ChargeBack» De plus, l arrivée de toute nouvelle technologie (i.e. le Cloud Computing au sein d une entreprise) impose une pénalité au premier qui s engage : la première entité PAGE 33 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

qui a un besoin paie généralement tout ce socle ou cette phase d installation! Les projets complémentaires ont alors le bon rôle, pouvant s appuyer sur l existant et demander une facturation dite incrémentale (les coûts supplémentaires liés à la mise en œuvre uniquement) en faisant abstraction de l utilisation «gratuite» d une quote-part du socle existant. La méthode ABC 5 constitue par ailleurs une méthode d analyse des coûts par processus ou activités, qui peut s avérer judicieuse dans l application d une matrice de ventilation des coûts, en tenant compte des métriques collectées. Néanmoins, cette facturation devient un état de fait dans le cas d un Cloud public : du fait de sa nature de service externe acheté (une sorte d «utility»), l utilisateur connaît alors directement sa consommation et le montant des coûts associés en OPEX / CAPEX qui se trouvent directement imputés sur son budget. La complexité se déplace alors vers la maitrise du budget global transverse à l entreprise afin de garantir que la somme des petites facturations ne s avérera pas prohibitive par rapport à une solution interne ou ne nécessite pas un plafonnement contractuel que les achats pourraient prévoir, sans oublier la gestion du parc et son décommissionnement. 4.3. Conclusion La construction de la facturation à l usage du Cloud Computing se décline suivant 2 axes : la métrique la facturation Axes sur lesquels le type de Cloud (privé, hybride, public) et le mode de service (IaaS, PaaS, SaaS) se répartissent. Ce graphique résume la tendance actuelle : 5 Activity Based Costing, prise en compte dans le modèle développé par le Groupe de Travail Analyse des coûts de la Production. PAGE 34

Où nous retrouvons logiquement le «IaaS en mode Cloud privé» sur des métriques techniques en facturation ShowBack pour aller jusqu au «SaaS en mode Cloud public» s appuyant sur des métriques plutôt métiers lié à une refacturation directe des utilisateurs. De plus, le tableau ci-dessus illustre les natures de métriques envisageables : IaaS PaaS SaaS Privé Hybride Public Privé Hybride Public Privé Hybride Public CPU, Go de RAM et To de stockage CPU, Go de RAM et To de stockage Configuration petit-moyen-large : CPU, Go de RAM et To de stockage CPU, Go de RAM et To de stockage + requêtes http, serveur d applications et SGDB Non défini Requêtes http, serveur d applications et SGDB + taux de disponibilité et temps de réponse http (qui garantit la monté en charge) Capacité http, serveur d applications et SGDB + taux de disponibilité et temps de réponse applicatif Non défini Nombre de services (type boite mail) avec nombre d options (collaboratif à 10) Nb. : le Cloud Hybride sans existence industrielle à date, reste à définir ainsi que les métriques qui permettront, par exemple, d avoir avec un même sous-traitant un Cloud privé en interne exploité par ce sous-traitant connecté à son Cloud externe. Aujourd hui les questions de facturation et de refacturation restent peu développées dans de nombreuses entreprises, et de ce fait rarement utilisées. Les métriques métiers pour leur part manquent presque partout car elles ne correspondent pas aux façons traditionnelles d envisager l outil informatique. Cette situation devrait rapidement évoluer sous l effet du Cloud Computing : En premier lieu parce que le Cloud généralise le principe de la consommation d informatique sur un mode service. En second lieu car le Cloud incitera de plus en plus les fournisseurs internes à imposer aux métiers l utilisation de services refacturables, et donc comparables à ceux du marché. Encore émergent, le sujet de la facturation et de la refacturation des services Cloud devrait rapidement progresser. PAGE 35 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

5Cloud et High Performance Computing Le Livre Blanc Cloud Computing 2011 du CRiP comportait un chapitre consacré au sujet Cloud et HPC (calcul scientifique et technique) appuyé sur les réflexions en cours chez quelques membres du Groupe de Travail engagés sur ce sujet. Après avoir posé quelques éléments de qualification des plates-formes HPC, ce chapitre dressait le tableau suivant de la situation : Une offre en souffrance : il existait un manque d acteurs nationaux, européens ou mondiaux sur le territoire français. Un modèle Cloud pas toujours adapté au HPC et ceci aussi bien dans ses éléments techniques qu économiques. Des points de résistance spécifiques : la sécurité, le problème du transfert de forts volumes de données, le respect des modes d exploitation spécifiques au HPC. En l absence de progrès réels dans l adoption des solutions de Cloud HPC par les membres du Groupe de Travail, nous n avons pas jugé utile de rédiger un nouveau chapitre sur le sujet. Cependant, nous voulons ici rendre brièvement compte de quelques faits marquants intervenus au cours des douze derniers mois, et particulièrement de quelques évolutions importantes. La question de la constitution d une offre bien représentée sur le territoire français reste posée, et la situation ne progresse que lentement. Cependant, mi-mai 2012, nous apprenons le lancement du projet NumInnov qui vise à la création d un opérateur indépendant de services de calcul intensif en mode Cloud à l échelle européenne. Le projet, porté par Bull et la Caisse des Dépôts, disposera d une trentaine de millions d euros de financement. Une façon de répondre à l activité forcenée d Amazon Web Services, qui, avec la mise en production de son service de HPC Cloud Cluster Compute Eight Extra Large a atteint la 42ème place du classement Top 500 des super calculateurs. PAGE 36 L utilisation de services de HPC Cloud commerciaux tels qu il en existe déjà quelques-uns constitue désormais une alternative économiquement rentable à la construction d un cluster interne pour des utilisations temporaires. Le Cloud HPC parvient donc déjà à se substituer dans certaines conditions aux clusters HPC, même s il ne peut encore prétendre fournir les performances des plus puissantes plates-formes traditionnelles. Une étude menée par l Université de Berkeley indique que les opérations de base conduites dans un Cloud reviendraient de 5 à 7 fois moins cher que les mêmes opérations effectuées sur une grille ou un centre de données classique.

Parmi les fournisseurs, Cycle Computing, éditeur spécialisé dans les outils et services d administration des flux de calculs sur fermes HPC, commercialise désormais une offre de Cloud HPC baptisée Cycle Cloud appuyée sur le Cloud d Amazon. Cycle Computing a ainsi mis en œuvre pour un client de l industrie pharmaceutique à l été 2011 un cluster composé de 30 000 cœurs, 26,7 To de mémoire et 2 Po de disques au prix de 1 279 dollars de l heure. Depuis, Cycle Computing a réalisé un cluster de plus de 50 000 cœurs. La particularité de Cycle Cloud est d utiliser des instances Amazon standard (et non pas des instances HPC plus coûteuses), instances réparties dans plusieurs datacenters pour des questions de disponibilité, et d offrir à ses clients un guichet unique tant pour l administration (et la sécurité) que pour la facturation de la ressource. Le prix atteint, environ 1 000 euros de l heure, s avère très compétitif pour des besoins ponctuels, même si les performances obtenues sont probablement moindres que celles à attendre d un cluster HPC traditionnel interne du fait des surcouches de virtualisation et d automatisation utilisées. Une autre approche du calcul HPC dans le cloud, adoptée par la société Vcodyne, consiste à adapter le modèle Cloud Computing (utilisation de ressources informatiques externalisées en mode service) aux exigences du monde du calcul intensif (performance et sécurité). L idée est de mettre à disposition des utilisateurs des nœuds de cluster physique gérés avec les principes du cloud computing. Il est possible, selon ce modèle, d avoir un accès sécurisé à des ressources HPC physiques dédiées (cpu, stockage, réseaux) avec un contrôle total sur ces ressources. Il est possible de redimensionner dynamiquement le cluster en fonction de la charge (intégration avec l ordonnanceur local inclus). Comme pour les autres services de Cloud le paiement s effectue à l usage. Vcodyne a choisi de développer son offre sur des data-centers (certification SAS70 llb Sox) en France ou en Allemagne. Le problème de l accroissement des volumes de données, et partant celui de leurs mouvements a connu un renforcement ces derniers mois où il fut beaucoup question de Big Data. En réponse à ces problèmes, un membre du CRiP a initié un projet pour la mise en place d une plate-forme de stockage, de traitement et de partage de données basée sur Hadoop MapReduce, soit un type de Cloud interne HPC. Les obstacles restent importants : complexité du développement, difficulté à paramétrer efficacement les schedulers pour éviter l engorgement sur les nœuds, quasi impossibilité de sauvegarder efficacement des quantités de données énormes, et défaut de support. Le problème de la confiance et de la sécurité des données reste largement en suspens. Plusieurs démarches visent à remédier à cet état de fait. L ENISA (European Network and Information Security Agency) s associe ainsi à la démarche CAMM (Common Assurance Maturity Model), une méthode qui vise à mettre en place des indicateurs de sécurité partagés concernant le niveau de sécurité des différentes plates-formes Cloud. Pour le moment, la seule démarche sécurisée consiste à mettre en œuvre un Cloud de type privé. PAGE 37 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

Le problème de la gestion des licences dans le Cloud HPC appelle des réponses originales car les modèles traditionnels, souvent liés à des identifications physiques de machines ne fonctionnent plus. Des architectures de type Licenceas-a-Service devraient voir le jour pour assurer la distribution temporaire de droits de licence à un utilisateur par Internet, avec une sécurisation renforcée des clés logicielles pour éviter les risques de craquage. Comme nous le voyons, en particulier en matière de sécurité, le Cloud HPC rencontre des problématiques générales au Cloud. La grande particularité du domaine reste ses exigences importantes en termes de bande passante et de réduction de la latence, domaines dans lesquels les infrastructures publiques actuelles ne semblent pas à même d apporter de solution satisfaisante. PAGE 38

6RETOURS D EXPÉRIENCE 6.1. Valeo Vega Entreprise : Valeo Secteur : Industrie, équipements automobiles Type de Cloud : public SaaS Mise en service : 2009 Le contexte Entreprise de dimension internationale 124 sites dans 28 pays et plus de 60 000 collaborateurs, avec de forts objectifs de développement dans les pays émergents, Valeo se trouve confronté en 2006 au besoin de remplacer sa plate-forme de communications interne. Basée jusqu ici sur Lotus Notes, cette infrastructure se dirigeait alors vers sa fin de vie, tandis que de nouvelles attentes des utilisateurs se profilaient. La question se pose donc : quels besoins pour la future plate-forme? Comment y répondre? Valeo distingue alors quatre axes stratégiques à prendre en compte : Besoin métier : mettre plus de temps réel dans les échanges entre les équipes, savoir gérer des interactions et partenariats multiples de type entreprise étendue, savoir répondre aux besoins de communication des utilisateurs multiples dont le nombre et la diversité culturelle augmente rapidement. Flexibilité : augmenter l agilité du système en le rendant plus réactif, mais aussi introduire un modèle de paiement à l usage, et respecter les standards ouverts pour faciliter les évolutions futures. Maîtrise des coûts : une constante de cette industrie qui sait que son évolution se joue sur sa capacité à innover d une part et sur sa capacité à maîtriser et réduire ses coûts d autre part. Amélioration continue : gagner en agilité dans la fourniture de nouvelles fonctionnalités en conformité avec les besoins des métiers, dépasser les limites des outils jusqu ici en place, simplifier les process. Enfin, Valeo a la conviction que l innovation se tient à ce moment du développement des techniques informatiques plutôt dans le domaine grand public que dans celui des solutions pour entreprises. L entreprise se fixe quelques principes : Universalité du client : l accès aux outils devra se faire par de simples navigateurs du marché Universalité de l accès : tous les utilisateurs devront pouvoir accéder au service de façon identique de partout depuis tout type de terminal. Le Cloud La solution déployée se nomme VeGa pour Valeo empowered by Google apps. Elle se compose d un ensemble de services Cloud de diverses origines, mis à disposition de l organisation La suite Google Apps (messagerie, chat, calendrier, Google Docs, outils de création de sites, de partage de vidéos, etc.) Une couche de sécurité et d archivage fournie par Google Postini Une plate-forme de développement d applications de Workflows administratifs fournie par Cordys Process Factory Et un cœur de système d intégration et de gouvernance de l ensemble qui comporte les services d authentification, les annuaires, le Master Data Management la gestion du support et le pilotage des interfaces avec le Système d information. Ce cœur de système est fourni en partenariat avec Cap Gemini PAGE 39 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

Ce qu il faut savoir VeGa est actuellement utilisé au quotidien par 35 000 collaborateurs dans 28 pays. La chaîne de gestion d un compte utilisateur a été complètement automatisée, le système RH (PeopleSoft) la pilote directement : provisionnement et gestion du cycle de vie de l identité numérique de l employé Valeo VeGa fonctionne selon une logique d indépendance de plate-forme : toute plate-forme cliente, tout navigateur, doivent pouvoir accéder aux services. Ce qui ne signifie pas que l utilisateur possède le choix inconditionnel de son terminal d accès, mais que la décision de standardisation côté client revient à l entreprise : elle n est pas dictée par le fournisseur. Pour le premier cycle d utilisation, Valeo retient le navigateur Firefox, installé sur tous les postes de travail de l entreprise, et Android comme plate-forme mobile. Ces choix ne traduisent pas un sacrifice du principe d indépendance de plate-forme, mais seulement une décision temporaire de standardisation de ses clients. Une migration vers Google Chrome est prévue en 2012 pour bénéficier de certaines fonctions avancées des Google Apps que seul ce navigateur procure. Conceptuellement, le système se compose de quatre couches. Trois d entre elles sont fonctionnelles et prennent en charge les usages personnels, d équipe, d entreprise. En dessous se tient une couche technique aux mains de l entreprise pour la délivrance de services génériques fondamentaux : l authentification, le Master Data Management, la gestion des interfaces avec les applications business SAP BW, Peoplesoft, le PLM, etc. Un service de migration a été mis en place pour faciliter, le plus automatiquement possible, les nécessaires transferts de données entre l ancien système et le nouveau. Ce projet incorpore une forte volonté de concentrer l IT sur l axe accompagnement des métiers plus que sur l axe technique et de gestion des infrastructures, et de réduire la part d activité consacrée à ce dernier (intérêt du mode SaaS). Les profils d utilisation du réseau ont été complètement transformés par ce projet. Les échanges notoirement internes ont maintenant migré sur Internet. Il a, ainsi, fallu séparer les flux métiers (VeGA ou autres SaaS) des flux sociaux (autres), ces derniers ayant toujours tendance à occuper beaucoup de bande passante. Les solutions mobiles, précédemment basées sur Blackberry, passant sur Android, ont fait exploser les charges de roaming en mobilité. Cela a entrainé des négociations «musclées» avec les opérateurs mobiles. La sécurité a été centrée sur les terminaux des utilisateurs. Mais les comportements des utilisateurs restent la plus grande source de soucis. Points positifs Performances, évolutivité, disponibilité, sécurité Il y a un retour IT (remplacement d un système vieillissant) mais surtout un retour métier avec une meilleure diffusion de l information et une collaboration étendue Le système permet la mise à disposition rapide de nouveaux environnements selon un modèle de paiement à l usage Les services sont standardisés au niveau de l entreprise et évoluent rapidement avec la puissance de la plate-forme du fournisseur Simplicité d utilisation PAGE 40 Points de vigilance Attention à la consommation réseau La gestion de la réversibilité reste problématique Le fournisseur se trouve en situation quasi-hégémonique (imposition de Chrome) Les comportements des utilisateurs engendrent des risques accrus de sécurité Ce système est sensible aux risques politiques : dans certains pays du monde, Google n est pas le bienvenu et ses services sont difficiles d accès Etre bien armé pour accompagner le changement auprès des utilisateurs, en termes techniques, mais surtout en termes d usages métier (formation des utilisateurs) Respecter les standards Internet et ses choix d architecture (REST)

Conserver le contrôle des paramètres-clé du fonctionnement du service : par exemple les règles de partage Assembler et intégrer mais éviter voire proscrire le spécifique sur les parties conservées dans l entreprise Prendre la mesure de l impact sur les compétences internes. Un tel projet demande de la maturité en ce qui concerne le pilotage de contrats d externalisation, un haut niveau d expertise sur les solutions cloud et l architecture 6.2. Stime (Informatique des Mousquetaires) Entreprise : Groupement des Mousquetaires Secteur : grande distribution Type de Cloud : IaaS privé interne Mise en service : 2011 Le contexte Le Groupement des Mousquetaires est un acteur majeur de la grande distribution en Europe : 3 500 points de vente, 130 000 collaborateurs, 37 milliards d euros en 2011. Sa filiale Stime est en charge de la conception, du déploiement, de l exploitation et du support des tous les projets informatiques. Elle emploie 750 collaborateurs dont 200 au sein de sa Direction des Opérations Amont qui exploite quatre datacenters pour un total d environ 1 000 serveurs (MVS, AIX, Linux, Windows). En 2010, la Direction des Opérations Amont décide d ajouter une offre Cloud IaaS à son catalogue de services. L objectif est de disposer d une offre «agile» pour répondre aux demandes urgentes ou temporaires de mise à disposition d environnements serveurs, demandes que les processus existants ne permettaient pas de traiter dans des délais satisfaisants. En effet le séquençage des intervenants dans le déroulement de ces processus de mise à disposition de serveurs engendrait un délai habituel d une à plusieurs semaines. Dans ces conditions, le risque était fort de voir les demandeurs se tourner vers des services externes, ou renoncer à certaines opérations. L orientation retenue consiste à créer un Cloud privé interne afin de pérenniser et d optimiser les investissements existants dans les datacenters. Quelques éléments de cadrage ont été établis : La Stime doit rester libre de ses choix de fournisseurs de serveurs, réseaux, stockage et hyperviseurs La solution devra gérer des serveurs Windows, Linux et, ultérieurement, Unix Les serveurs gérés seront principalement des machines de développement et de recette. La solution doit toutefois permettre de gérer des serveurs de production La solution devra automatiquement mettre à jour la CMDB Stime existante et proposer une interface avec l outil de facturation déjà en place Le Cloud La solution mise en œuvre repose sur l offre ISDM d IBM (IBM Service Delivery Manager). Elle permet à la Stime de créer des serveurs Windows ou Linux en moins de 30 minutes. L utilisateur choisit le système d exploitation, le nombre de CPUs, la quantité de RAM, la surface disque, la localisation réseau et détermine le client (Business Unit par exemple) à facturer. Il peut choisir l installation automatique de packs logiciels additionnels. La solution permet de modifier, à la demande, la configuration des serveurs déjà créés. Elle permet aussi d enregistrer l image d un serveur à des fins de restauration ultérieure (pour un retour arrière après une opération échouée par exemple). Les utilisateurs accèdent à la solution au travers d un portail intranet. Ce portail s appuie sur un moteur de workflows, un orchestrateur qui pilote les opérations techniques et un outil de comptabilisation. Les serveurs demandés sont fournis par une plateforme VMWare déployée sur plusieurs datacenters afin de garantir un plan de reprise d activité. Cette plate-forme a été dimensionnée et évoluera de manière à disposer en permanence de ressources disponibles pour respecter l aspect «à la demande» de l offre Cloud. PAGE 41 CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC LiVRE BLANC

L usage du portail est réservé aux Chefs de projets techniques. Ceux-ci vérifient l éligibilité de chaque demande avant de souscrire un service Cloud. Divers critères entrent en jeu dans ce processus : support de la virtualisation, versions des OS et des logiciels, flux réseaux, adéquation du SLA aux capacités de la plate-forme, contraintes sur les licences à ajouter... Les Chefs de projets techniques agissent donc comme un filtre d expertise pour aiguiller les Clients vers la meilleure solution répondant à leurs besoins. Selon le cas d usage, les serveurs créés sont soit directement fournis au client (hébergement sec), soit administrés par les équipes de la Stime (hébergement avec exploitation). Ce qu il faut savoir Le projet a inclus deux grandes phases : la recherche de la solution logicielle idoine puis son déploiement. Comme expliqué plus haut, la Stime souhaitait conserver la totale maîtrise de ses approvisionnements en matière de matériels informatiques ainsi que le choix de ses hyperviseurs. L adoption d une solution tout-intégrée matériel + orchestrateur et outils d administration + hyperviseurs - ne convenait donc pas à son cahier des charges. Le planning a été le suivant : La phase de rédaction du cahier des charges a été importante. Une formalisation précise et exhaustive du service attendu constitue un facteur clé de réussite. L intégration a été menée par IBM avec formation et transfert de connaissances auprès de l équipe Stime. Au cours du projet, certaines demandes fonctionnelles ont été adaptées afin de se rapprocher du fonctionnement standard du produit. Cette façon de procéder a permis de maîtriser la part de personnalisation et ainsi d alléger les futurs cycles de maintenance. Toutes les fonctions importantes pour la Stime ont été maintenues et implémentées. PAGE 42 Le pan sécurité a porté sur la mise en œuvre de règles renforcées de routage réseau, de contrôle de conformité et de gestion des mots de passe ainsi que sur le déploiement d une technologie d isolation de bas niveau sur le réseau virtuel (Private VLAN Cisco).