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

(1)

Club des Responsables

d’Infrastructures et de Production

L i VRE BLANC

Juin 2012

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

(2)

(3)

Table

matières ^des

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

(4)

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.

Bonne lecture !

Pilotes du Groupe de Travail Cloud Computing du CRiP

Stéphane GEISSEL Patrick JOUBERT

Intro

duction

(5)

CLOUD COMPUTING : Paas, Sécurité et Cloud, Sourcing, facturation et refacturation des services Cloud, Observatoire HPC

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’ex- pé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

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)

L i VRE BLANC

(6)

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.

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.

1

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.

(7)

L i VRE BLANC

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 elle- mê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é.

(8)

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 ? 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 à

(9)

L i VRE BLANC

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.

(10)

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

• 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

(11)

L i VRE BLANC

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 plates- formes 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

(12)

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.

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

(13)

L i VRE BLANC

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

(14)

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

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.

(15)

L i VRE BLANC

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.

(16)

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ées- sorties 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 plate- forme 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

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.

(17)

L i VRE BLANC

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.

(18)

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

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

2

(19)

L i VRE BLANC

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.

(20)

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 allez- vous 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

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.

(21)

L i VRE BLANC

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 ? OUI NON

• 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 NON

(22)

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.

• 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 ? OUI NON

• Le client peut-il demander sur une plate-forme IaaS la mise à disposition d’images d’OS

durcies ou sécurisées ? OUI NON

• Peut-il fournir ses propres images ? OUI NON

• Quels moyens d’interconnexion offrez-vous entre les datacenters du client et votre Cloud ?

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

(23)

L i VRE BLANC

LES 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’applica- tions : 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

3

(24)

• 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

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.

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