See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/280685801

L’état de l’art de la sécurité dans le Cloud Computing

Conference Paper · November 2012

CITATIONS READS

0 12,041

3 authors:

Hassan El Alloussi Fetjah Laila

Université Hassan II de Casablanca Université Hassan II de Casablanca
10 PUBLICATIONS   24 CITATIONS    24 PUBLICATIONS   136 CITATIONS   

SEE PROFILE SEE PROFILE

Abderrahim Sekkaki
Université Hassan II de Casablanca
111 PUBLICATIONS   666 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Segmentation et classification des images mammaires pour l’aide au diagnostic du cancer du sein View project

Data Classification View project

All content following this page was uploaded by Fetjah Laila on 05 August 2015.

The user has requested enhancement of the downloaded file.

 L’état de l’art de la sécurité dans le Cloud Computing
Problèmes et solutions de la sécurité en Cloud Computing

Hassan EL ALLOUSSI, Laila Fetjah, Abderrahim SEKKAKI

Département Mathématique & Informatique

Faculté des Sciences Aïn Chock
Université Hassan II
Casablanca, Maroc

{halloussi@gmail.com, l.fetjah@fsac.ac.ma, a.sekkaki@fsac.ac.ma}

Abstract. Graduellement, le Cloud Computing est devenu une réalité pour les managers des
Systèmes d’Information. La possibilité d'externaliser des services qui étaient jusqu'à au-
jourd’hui considérés comme stratégiques, comme le courriel ou les applications ERP, prend
forme grâce à des offres de services comme Google Apps et SalesForce.com. L'infrastructure
informatique se tourne également vers le Cloud grâce à l'instanciation de machines virtuelles sur
des services comme Amazon EC2 ou Microsoft Azure.
Dans cet article, le phénomène Cloud Computing sera analysée, donnant un accent particulier à
l’état de l’art des menaces sécurité qui s'appliquent aux services Cloud et les solutions exis-
tantes.

Keywords : Cloud computing, Sécurité dans le cloud computing, Sécurité de la machine vir-
tuelle, proofs of retrievability, HAIL, RAID, SSL, Trusted Computing Group (TCG), Trusted
Computing Module (TPM)

1 Introduction
Le Cloud Computing est effectivement arrivé, ou plutôt revenu, dans la dernière décennie pour révo-
lutionner le monde de l’informatique. Chronologiquement, il y avait l’apparition dans les années 80
de la virtualisation, de l’infogérance et de l’externalisation; aussi la démocratisation de
l’informatique dans les années 90 – et surtout au cours de la dernière décennie – avec la généralisa-
tion d’Internet, le développement des réseaux à haut débit, la location d’application, le paiement à
l’usage et la quête de la mobilité, tout cela a donné la naissance au nouveau concept
d’infrastructures et de solutions IT nommé le Cloud Computing (l’informatique en nuage).
Le Cloud consiste en une interconnexion et une coopération de ressources informatiques, situées au
sein d’une même entité ou dans diverses structures internes, externes ou mixtes. Et dont les modes
d’accès sont basés sur les protocoles et standards Internet.
Les solutions Cloud reposent sur des technologies de virtualisation et d’automatisation. Trois carac-
téristiques clés du Cloud le différencient de solutions traditionnelles :

 Services à la place de produits technologiques avec mise à jour en continu et automatiquement

 Self-service et paiement à l’usage (en fonction de ce que l’on consomme)
 Mutualisation et allocation dynamique de capacité (adaptation élastique aux pics de charge).
 2

Dans le monde de la technologie de l'information, les entreprises de toutes tailles et de tous secteurs
sont moins regardantes des différentes solutions en ligne sur le marché. Certaines de ces entreprises
ont déjà migré leurs données et leurs services, comme les emails, les applications CRM et ERP ou
même des solutions de stockage à des services Cloud comme Google Apps, Salesforce.com, Zoho
ou Dropbox.
Aussi, plusieurs applications nouvelles sont basées sur des infrastructures ou des plates-formes of-
fertes sous forme du Cloud comme par exemple Amazon EC2 ou Microsoft Azure. L'analyse de ren-
tabilisation de ces types de solutions est très satisfaisante dans la mesure où les économies et les in-
vestissements sont concernés, parce que les fournisseurs de services Cloud bénéficieront d’économies
d'échelle afin d'offrir des prix à peine égalé par les solutions traditionnelles.
Toutefois, les clients de services de Cloud actuellement n’ont aucun moyen de vérifier la confiden-
tialité et l'intégrité de leurs données et de leurs traitements.

I. La problématique
Cependant, d'un point de vue sécurité de l'information, un certain nombre de questions se posent sur
les différentes menaces que fait face le Cloud, et surtout les données stockées. Des questions lo-
giques se posent : Où sont les données physiquement? Sous quelle juridiction? Les données sont sur
le même serveur que les données de mes concurrents? Comment puis-je être sûr que mes concur-
rents ne puissent pas accéder à mes données? Que deviennent mes données lorsque je me désabon-
ner d'un service Cloud? Comment puis-je m'assurer que mes données sont supprimées? Quel niveau
de service puis-je avoir? Si ce niveau n'est pas atteint, contre qui et comment puis-je réclamer? Le
Cloud est accessible dans le monde - serait mon information d'entreprise donc pas être plus en sécu-
rité sur ma propre plateforme?
Dans cet article, nous expliquerons l'origine de l’informatique en nuage, ses principales caractéris-
tiques, ses modèles de service et de ses modèles de déploiements. Ayant posé les fondements princi-
paux de cette nouvelle approche de l'externalisation, les principaux risques sécurité et les l’état de
l’art des solutions existantes pour sécuriser le traitement seront étalés.

2 Rappel sur le Cloud Computing

Le Cloud Computing n'est pas une technologie nouvelle, mais plutôt une nouvelle façon d'utiliser les
ressources technologiques actuelles. En effet, le Cloud est la fourniture de services technologiques
de toutes sortes (e-mail, stockage, outils bureautiques, CRM,...) immédiatement et sur demande. Il
permet d'utiliser des moyens technologiques inédits jusqu'à présent en raison de sa souplesse.

Les principales caractéristiques du Cloud Computing sont les suivantes:

1. Haut niveau d'abstraction
2. Sur demande
3. La réduction des coûts résultant des économies d'échelle
4. Flexibilité et évolutivité
5. Payer à l’usage
6. Disposition presque instantanée
Selon les fonctionnalités du service offert par le Cloud, il y a trois modèles de service dans le Cloud
Computing :

Modalité de présenta- Plateforme de présen-

tion tation

APIs

Applications

Données Métadonnées Contenu

Intégration & Middleware

APIs
3

Fig. 1. Les modèles de services du Cloud

1. Software as a Service (SaaS) : concerne les applications d’entreprise : CRM, outils collaboratifs,
messagerie, BI, ERP,…etc. Le modèle SaaS permet d’externaliser une application chez un tiers.
Ce modèle convient à certaines catégories d’applications qui se doivent d’être globalement stan-
dard pour tout le monde, la standardisation étant un des principes du Cloud. Le terme SaaS
évoque bien un service dans le sens où le fournisseur vend une fonction opérationnelle, et non des
composants techniques requérant une compétence informatique. C'est le modèle dans lequel l'uti-
lisateur transfère presque l'entière responsabilité de la sécurité informatique au fournisseur de
services.
2. Platform as a Service (PaaS) : concerne les environnements middleware, de développement, de
test…etc. Le modèle PaaS consiste à mettre à disposition un environnement prêt à l’emploi,
l’infrastructure étant masquée. Une plate-forme PaaS permet par exemple d’avoir un environne-
ment de développement immédiatement disponible. Toutefois, les changements à la configuration
du système d'exploitation, la configuration du réseau ou système de stockage ne sont pas autori-
sés.
3. Infrastructure as a Service (IaaS) : concerne les serveurs, les équipements et solutions de
stockage, réseau, …etc. Le modèle IaaS consiste à pouvoir disposer d’une infrastructure informa-
tique disponible via un modèle de déploiement Cloud Computing. L’accès à la ressource est
complet et sans restriction, équivalent à la mise à disposition d’une infrastructure physique réelle.
Ainsi une entreprise pourra par exemple louer des serveurs Linux, Windows ou autres systèmes,
qui tourneront en fait dans une machine virtuelle chez le fournisseur de l’IaaS. L'utilisateur de ce
modèle n'a pas le contrôle sur l'infrastructure technologique sous-jacente, mais il a un contrôle to-
 4

tal sur la configuration réseau, système d'exploitation et les applications. Dans ce modèle, la res-
ponsabilité de la sécurité est presque transférée entièrement chez le client.
Le graphe ci-dessus montre une pile dans laquelle les composants de l'architecture de Cloud Compu-
ting sont classés. SaaS est considérée comme comprenant tous les éléments de la pile, le PaaS mo-
dèle inclut la couche middleware, et enfin le modèle IaaS comprend toute l'infrastructure.
Si le client de services Cloud contracte juste quelques niveaux de la pile situés en bas, le fournisseur
de Cloud ne sera pas responsable de la sécurité des systèmes utilisés par le client. Inversement, si le
client loue plusieurs couches couvrant de nombreux niveaux de la pile, le risque sera transféré au
fournisseur de services.

Ce qui précède est le point clé de la gestion de la sécurité dans les modèles de Cloud Computing. Le
principal inconvénient du transfert des risques sécurités informatiques aux fournisseurs, c'est qu’il
va limiter la flexibilité et des fonctionnalités dans les services de Cloud contracté.

Un autre aspect des niveaux de services du Cloud Computing sont les différentes interfaces qui ap-
paraissent au sommet de chaque modèle. APIs (en IaaS), Intégration & Middleware (en PaaS) et
modalité & Plateforme de Présentation (en SaaS) sont des niveaux qui agissent comme intermé-
diaires entre le client de l'utilisateur (navigateur web) et le fournisseur de services Cloud Computing.

Le tableau suivant montre des exemples de services pour ces trois modèles:
Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Fig. 2. Exemples de services pour ces trois modèles

Le Cloud est aussi classé selon son modèle de déploiement :

1. Les Clouds privés sont exploités exclusivement par une organisation en particulier. Ils peuvent
être gérés par celle-ci ou par un tiers, et peuvent exister dans, ou hors de, ses locaux.
5

2. Les Clouds publics sont ouverts à l’ensemble du public ou à un grand groupe industriel et sont
exploités et dirigés par un fournisseur de services de Cloud.
3. Les Clouds hybrides regroupent deux Clouds ou plus (privés ou publics) qui demeurent des enti-
tés uniques mais sont reliées par une technologie autorisant le portage des données et des applica-
tions.
4. Les Clouds communautaires offrent une infrastructure qui est partagée par plusieurs organisations
et prend en charge une communauté spécifique. Ils peuvent être gérés par ces organisations ou par
un tiers et peuvent exister dans, ou hors des, locaux de celles-ci.

3 Les vulnérabilités dans la sécurité du Cloud

Cependant, le Cloud Computing représente un défi majeur pour les fournisseurs de services, pour
ses clients et, bien sûr, pour les attaquants externes. Des milliers de giga-octets d'informations pro-
venant de différents clients sont stockées au même endroit et sont exposés à l'Internet. Ceci repré-
sente une cible idéale pour des centaines d’utilisateurs malveillants. Ex. espions industriels : imagi-
nez combien sont-elles attractives les données de clients de milliers d'entreprises exposées à l'Inter-
net. C'est exactement ce qui est arrivé à un des plus célèbres fournisseurs de Cloud en ligne: Sales-
Force.com.

La sécurité est un aspect qui doit être pris en compte lors du déploiement d’un Cloud. L'adoption des
technologies basées sur le Cloud Computing est inévitable, mais des précautions doivent être prises
en compte pour éviter que les gains potentiels pour avoir adoptés ne soient pas ternis par une me-
nace de sécurité.

La sécurité informatique joue un rôle important dans le déploiement du Cloud Computing. En fait,
selon une étude récente, la sécurité est le plus grand défi à relever par les responsables informatiques
qui souhaitent adopter des solutions et des services hébergés dans le Cloud.
Selon un rapport élaboré par l'ENISA à la fin de l'année 2009, les menaces au Cloud Computing
peuvent être classées comme suit:

3.1 La perte de maîtrise de gouvernance :

Le client, contractant un service Cloud Computing, donne une partie de la gouvernance infrastruc-
ture IT au fournisseur. Dans ce cas, l'accord de niveau de service (SLA) doit jouer un rôle crucial
pour défendre l’intérêt du client.

3.2 Isolement des environnements et des données :

Le partage des ressources est l'une des caractéristiques les plus importantes du Cloud Computing.
Plusieurs clients peuvent, par exemple, partager le même serveur physique. Si la séparation des en-
vironnements n'est pas assez efficace, «invasions» entre les clients pourraient se produire.
Dans le cas d'un environnement partagé entre plusieurs "clients locataires", deux sortes d’attaques
sont possibles, la première de type "Guest-hopping" et la deuxième contre les hyperviseurs directe-
ment.
 6

3.3 Risques de conformité :

En externalisant certains services et processus de base, la conformité aux lois sur la protection des
données et les normes réglementaires telles que PCI DSS et ISO 27001 peut devenir très compliqué.
Les fournisseurs de services peuvent imposer des restrictions sur la conduite d’un audit de leurs
infrastructures.

3.4 La publication des interfaces de gestion

Les interfaces de gestion des services contractés (par exemple dans un modèle SaaS) sont publiées
directement sur le net. Cela augmente considérablement les risques par rapport aux systèmes tradi-
tionnels dans lesquels des interfaces de gestion sont accessibles uniquement à partir des réseaux
internes.

3.5 La protection des données :

Pour le client de services Cloud Computing, la protection des données est difficile. Il est très diffi-
cile de sécuriser les données qui se trouvent réparties dans plusieurs emplacements. S'assurer que les
données sont traitées correctement est également compliqué parce que le contrôle sur les transferts
de données est hors de la portée de son propriétaire.

3.6 La suppression dangereuse ou incomplète des données

Historiquement, la suppression sécurisée des données a été une question très complexe qui consistait
à développer une série de processus pour s'assurer qu'il n'y a pas de copie des données dans n'im-
porte quel endroit. La réutilisation des ressources matérielles est très commune dans le Cloud Com-
puting. Un nouveau client peut, par exemple, être affecté d'une section de stockage dans lequel,
jusqu'à récemment, les données d'un autre client ont eu lieu. Cela peut entraîner à un risque de perte
de confidentialité, si les données précédentes n’ont pas été supprimées complétement et en toute
sécurité.

3.7 Les utilisateurs malveillants

Cloud Computing a besoin des profils utilisateurs de haut niveau pour son administration. Un admi-
nistrateur système aura des privilèges complets sur différentes ressources de différents clients. Un
utilisateur malveillant qui compromet la sécurité du système avec succès et saisie une session admi-
nistrateur obtiendra l'accès à de nombreuses informations clientes.

4 Les risques classiques : application sur le Cloud

Les risques liés à la sécurité des données dans le Cloud ne sortent pas du périmètre des risques in-
formatiques globalement, mais ils présentent des vulnérabilités et doivent être prises en considéra-
tion lors de la prise en compte de la sécurité des données. Ces risques comprennent le hameçonnage,
les accès privilégiés dans le Cloud, et la source ou l'origine des données elles-mêmes.
7

4.1 Le hameçonnage :
Un des risques indirects aux données externalisées dans un Cloud est le hameçonnage. Bien qu'il soit
généralement considéré comme impossible, aujourd'hui, de briser l'infrastructure à clé publique PKI
(et donc casser l'authentification et le cryptage), il est possible de tromper les utilisateurs finaux par
le détournement de leurs informations d'identification au Cloud. Aussi, même si le hameçonnage ne
soit pas un risque nouveau dans le monde de la sécurité, il représente une menace supplémentaire
pour la sécurité dans le Cloud. Ci-après quelques exemples des méthodes de protection que certains
fournisseurs du Cloud ont mis en œuvre pour les aider à faire face à des attaques de hameçonnage :

 Filtrage de la connexion chez Salesforce.com : Salesforce.com a mis en place une fonctionnali-

té permettant de restreindre l'accès à une instance particulière de leur application de gestion de la
relation client. Par exemple, un client peut demander à Salesforce.com de ne pas accepter les
connexions, même si ont des références valides, à moins que la connexion est issue d'une plage
d'adresses IP en liste blanche. Cela peut être très efficace dans la prévention des attaques de ha-
meçonnage en empêchant une connexion pirate sauf s'il est issu d'une plage d'adresses IP con-
nues.
 Re-vérification des sessions connectées et de mot de passes chez Google Apps / Docs / Ser-
vices : De nombreux services de Google incitent au hasard les utilisateurs à ressaisir leurs mots
de passe, en particulier quand un événement suspect a été observée. Par ailleurs, de nombreux
services de Google affichent l'adresse IP à partir de la session de connexion précédent avec la no-
tification automatique d’un événement suspect, tels que le login de la Chine peu de temps après
une adresse IP à partir des Etats-Unis a été connectée pour le même compte.
 L'authentification chez Amazon Web Services : Amazon prend d'authentification aux res-
sources Cloud très au sérieux. Lorsqu'un abonné utilise EC2 pour alimenter un nouveau serveur
virtuel, par défaut, Amazon crée cryptographiquement une forte clés PKI et exige que ces clés
doivent être utilisées pour l'authentification à cette ressource. Si vous utilisez un nouveau LINUX
VM et que vous voulez utiliser le protocole SSH, vous devez utiliser SSH avec authentification
par clé et non pas par un mot de passe statique.
Cependant, ces méthodes ne sont pas forcément un bon remède contre le hameçonnage. La meilleure
protection est la formation de l’utilisateur du client et à le sensibiliser à reconnaître une connexion
frauduleuse. Ci-après quelques questions relatives à la protection contre le hameçonnage que le
fournisseur du Cloud doit apporter des éclaircissements :

 Surveillance de l’URL de référence : Est-ce que le fournisseur du Cloud surveille activement

les URL faisant référence aux sessions authentifiées? Une attaque de hameçonnage ciblant de
clients peut provenir d'une URL factice ou frauduleuses.
 Surveillance des comportements : Est-ce que le fournisseur Des services Cloud n’emploie pas
des politiques et procédures qui élit une marque en place (souvent les attaques de hameçonnage
d'utiliser les failles de marque pour tromper les utilisateurs)?

Est-ce que la politique de sécurité mise en place interdit les activités à faible sécurité (brèche) qui
pourraient être exploitées? Un exemple serait le cas si elles interdisent l'envoi d'e-mails avec des
liens que les utilisateurs peuvent cliquer pour interagir automatiquement avec leurs données. Un
autre exemple serait de permettre la réinitialisation du mot de passe sans s’assurer de l'identité utili-
sateur via un facteur confirmé d'authentification (i.e. initier une demande de changement de mot de
passe sur le Web et confirmer l'identité de l'utilisateur en se basant sur un message texte SMS en-
voyé sur le téléphone cellulaire de l’utilisateur).
 8

Le hameçonnage est généralement une menace parce que la plupart des services Cloud utilisent
actuellement une simple interface avec un nom utilisateur et une authentification de mot de passe. Si
un attaquant réussit à obtenir des droits, il serait très difficile de l’empêcher d'y accéder.

4.2 Personnel du fournisseur Cloud avec un accès privilégié :

Un autre risque potentiel pour la sécurité des données dans le Cloud concerne l'accès inapproprié
aux données sensibles des clients par le personnel du Cloud. Clairement affirmé, les services sous-
traités, que ce soit en Cloud ou non, peuvent contourner les contrôles typiques que les organisations
informatiques généralement appliquent à travers des contrôles physiques et logiques. Ce risque de
deux principaux facteurs : d'abord, il y a les données non cryptées et deuxièmement, il y a le person-
nel du fournisseur des services Cloud à accès privilégié. L'évaluation de ce risque engage ample-
ment à modifier les pratiques et les normes de sécurité du Fournisseur de Services Cloud pour que le
personnel de ce fournisseur avec un accès privilégié ne puisse pas accéder aux données des clients.

4.3 L’origine des données :

L'origine, l'intégrité, et la source des données est une préoccupation majeure dans le Cloud Compu-
ting. Prouver l'origine des informations ou des données revêt d’une importance dans de nombreux
domaines, y compris les brevets ou de preuve de propriété des ensembles de données précieuses qui
sont basées sur une analyse indépendante des sources d'information couramment disponibles. A des
fins de conformité, il peut être nécessaire d'avoir des enregistrements précis quant à ce que les don-
nées ont été placés dans un Cloud public, quand le stockage s'est produit, quel est le type de la ma-
chines virtuelles et stockage il résidait sur, et où il s’est traité. En fait, il peut être tout aussi impor-
tant d'être capable de prouver que certains ensembles de données n'ont pas été transférés à un Cloud.
Bien que les rapports sur la traçabilité des données et sa provenance puissent être très important à
des fins réglementaires, il peut être très difficile de le faire dans un Cloud public. Ceci est largement
dû au degré d'abstraction qui existe entre le rendement réel des ressources physiques, tels que lec-
teurs et serveurs et les ressources virtualisées qu'un utilisateur Cloud public ait accès. La visibilité
dans les opérations d'un fournisseur en termes de mécanismes techniques peut être impossible à
obtenir, pour des raisons de sécurité.
9

5 La colocation : un risque supplémentaire pour la sécurité dans le Cloud

Fig. 3. Cas d’une colocation

La colocation sécurisée consiste en l’hébergement sur le Cloud des applications et données de mul-
tiples clients (sociétés, organisations, entités métier…) au sein d’une seule et unique infrastructure
physique, mutualisée, tout en respectant la sécurité, notamment au sens de la confidentialité.

A juste titre, les sociétés-clientes du Cloud veulent être rassurées sur le fait que leurs données et
traitements seront bien isolés et protégés des autres environnements hébergés sur l’infrastructure
partagée. C’est souvent une obligation légale, par exemple lorsqu’une société stocke des numéros de
cartes bancaires ou des données personnelles, médicales…

Comment essayer de satisfaire ces deux impératifs de confidentialité et d’efficacité pour les infras-
tructures Cloud, et à tous les niveaux : machines virtuelles, serveurs hôte, réseaux (Ethernet et SAN)
et stockage ?

En plus d’appliquer rigoureusement les bases de la sécurité d’un système d’information mutualisé
(planification rigoureuse des droits d’accès, des privilèges administrateurs, sécurisation des mots de
passe, etc.…), certaines techniques ou architectures permettent de tendre vers ce but. En voici des
exemples.

5.1 Le cryptage des données :

Le cryptage est apriori séduisant, notamment la méthode classique à base de clé publique/clé privée :
seul le destinataire de l’information peut déchiffrer la donnée qui lui est destinée avec sa clé privée,
connue de lui seul, mais pas du fournisseur de la solution Cloud et moins encore d’un autre coloca-
taire. C’est une méthode très sécurisée (selon la taille de la clé) et sélective car on peut choisir de ne
chiffrer que ce qui le nécessite.
Toutefois le cryptage impose certaines réflexions quant à son implémentation. Notamment dans le
cas où des traitements sont nécessaires (calcul, indexation, sauvegarde), pouvant obliger à la mani-
pulation de données décryptées.
 10

5.2 Solutions d’étanchéité logiques :

Faire appel à des solutions d’étanchéité logiques permet de fournir les ressources à des groupes dif-
férents d’utilisateurs en toute sécurité.
Au niveau des VM, on peut utiliser un firewall virtuel sur la machine hôte qui cloisonne les VMS;
les VLANs permettent de cloisonner le trafic réseau sur Ethernet; des partitions virtuelles de stock-
age apportent l’étanchéité dans la baie de stockage.
Différentes approches sont possibles : on peut retenir la solution la plus pertinente et mature sur
chaque couche (selon une approche « best of breed » : la meilleure de sa catégorie), ce qui assure
une certaine indépendance dans le choix de chaque solution, mais nécessite d’être certain de la qua-
lité de l’intégration des différentes solutions de sécurisation de chaque couche. Comme souvent, ce
n’est pas parce que chaque couche est sécurisée que l’ensemble le sera (il faut faire attention au
maillon faible et à l’interfaçage entre les différentes couches).
Une autre approche consiste à retenir une solution d’infrastructure sur étagère, proposée par un
fournisseur unique ou un ensemble de fournisseurs. On perd en indépendance, car les différents
composants (serveur, réseau, stockage) sont imposés, mais on gagne en intégration et en sécurisa-
tion. En effet, pour simplifier les déploiements de solutions mutualisées et pour en améliorer la con-
fidentialité, certaines sociétés se sont alliées, ont coréalisé et co-validé des solutions « tout-en-un »
et/ou des guides de conception complets qu’ils mettent à disposition des fournisseurs de solution
Cloud.
Avantage de cette dernière approche : l’étanchéité est assurée logiquement et de bout en bout, de
l’application (la VM) aux disques (la baie de stockage mutualisée, cloisonnée en partitions virtuelles
étanches), en passant par le réseau, afin de ne jamais mettre en danger les informations sensibles.

6 Les différentes solutions

6.1 Plateforme de confiance basée sur le TPM :

Fig. 4. Une puce TPM

Le Trusted Computing Group (TCG), un consortium d'entreprises d'informatique (Compaq, HP,

IBM, Intel, Microsoft, AMD, etc.) visant à sécuriser les équipements et communications informa-
tiques, a proposé un ensemble de technologies matérielles et logicielles afin de permettre la mise en
œuvre de plates-formes de confiance. En effet, le TCG a proposé une norme pour la conception
d’une puce sécurisée TPM qui est maintenant livré avec du matériel de base. Le TPM (Trusted Plat-
form Module) contient une clé privée d’approbation qui identifie le module TPM (et donc l'hôte
physique), et certaines fonctions cryptographique qui ne peuvent pas être modifiés. Les fabricants
respectifs signent la clé publique correspondante pour garantir l'exactitude de la puce et la validité
de la clé.
11

Les plates-formes de confiance s’appuient sur les caractéristiques de puces TPM afin de permettre
une attestation à distance. Ce mécanisme fonctionne comme suit : Au démarrage de la plateforme,
l'hôte traite une liste L de mesure consistant en une séquence de tables de hachage du logiciel impli-
qué dans la séquence de boot, à savoir le BIOS, le bootloader et le logiciel qui met en œuvre la
plate-forme. Cette liste est stockée d’une façon sécurisée à l'intérieur du TPM de l'hôte. Pour attester
à la plate-forme, le côté distant défit la plateforme qui fonctionne sur le serveur avec un nonce nᵤ. La
plate-forme demande au TPM local de créer un message contenant à la fois la liste L et le nᵤ, crypté
avec la clé privée de la puce TPM. L'hôte envoie le message à la partie à distance qui peut le décryp-
ter en utilisant la clé publique correspondante, ce qui permet l'authentification de l'hôte. En vérifiant
que les nonces se correspondent et que la liste L correspond à une configuration qu'il juge digne de
confiance, le client à distance peut identifier de manière fiable la plateforme sur un hôte non fiable.

Fig. 5. Mécanisme d’accès dans une plate-forme de confiance

Étant donné que la plateforme traditionnelle de confiance peut sécuriser le traitement sur un seul
hôte, une approche naturelle pour sécuriser un service IaaS serait de déployer la plate-forme sur
chaque nœud du backend du service. Cependant, cette approche est insuffisante: un sysadmin peut
détourner un VM d'un client à un nœud ne fonctionnant pas sur la plateforme, soit lorsque le VMIS
lancé (en manipulant le CM), ou pendant l'exécution VM (en utilisant la migration). En consé-
quence, le mécanisme de certificat de la plate-forme ne garantit pas que la liste des mesures obte-
nues par le client à distance correspond à la configuration réelle de l'hôte où le VM a fonctionné (ou
sera exécuté dans le futur). Par conséquent, le TCCP doit fournir une attestation à distance qui ga-
rantit l'invariabilité de propriétés de sécurité de la plateforme dans le backend.

6.2 Cryptage des données: applications et limites

Une des particularités de la sécurité des données et des traitements dans le Cloud est la différencia-
tion entre les données statiques et celles dites en mouvement. En effet, la pratique du cryptage des
données statiques est différente de l'utilisation de la cryptographie pour protéger les données en
transmission ou en mouvement.
En effet, la particularité est que les clés de cryptage doivent être éphémères, tandis que pour les
données statiques, les clés peuvent être conservés aussi longtemps que les données stockées sont
conservées cryptées. Ce modèle ne marche pas sur Internet. La plupart des données stockées sur
l'Internet sont destinées à un usage par des utilisateurs, c'est avant tout destiné à être utilisé par
d'autres ordinateurs. Et c'est là que réside le problème. Les clés de cryptage ne peuvent pas être
stockées par les gens. Ils doivent être stockés sur le même ordinateur, ou tout au moins le réseau où
les données résident. Et c'est beaucoup plus risqué.
 12

Application de cryptage pour les données en mouvement.

Les deux objectifs de la sécurisation des données en mouvement sont la prévention des données
d'être tronquées (intégrité) et veiller à ce que les données restent confidentielles alors qu'elles sont en
mouvement. A part l'expéditeur et le récepteur, aucune autre partie ne devraient être en mesure de de
modifier les données. La façon la plus commune pour protéger les données en mouvement est d'uti-
liser le Cryptage combinée à l'authentification pour créer un canal pour transmettre en toute sécurité
les données vers ou à partir du Cloud.
Le Cryptage est utilisé pour assurer que s'il y a une violation de l'intégrité de communication entre
les deux parties que les données doivent rester confidentielles. L'authentification est utilisée pour
assurer que les parties qui envoient entre elles les données sont authentiques. Le transfert de données
via des moyens programmatiques, par transfert de fichier manuel, ou via un navigateur utilisant le
protocole HTTPS, TLS ou SSL sont des protocoles de sécurisés utilisés pour ce type de probléma-
tique. Une clé PKI est utilisée pour authentifier la transaction, et les algorithmes de cryptage sont
utilisés pour protéger les données réelles.

Obstacles du cryptage dans le Cloud.

Par exemple, un Cloud public de modèle SaaS, et en raison de sa nature même, ne pourrait pas per-
mettre aux abonnés de crypter leurs données. Cela peut être dû à des limitations fonctionnelles avec
le service lui-même. Pour les réseaux sociaux actuellement disponibles, y compris Facebook,
MySpace, et Linkedin, il n'est pas possible d'utiliser le cryptage pour assurer la confidentialité des
renseignements personnels. Malheureusement, cela touche même ses modèles de revenues. En effet,
si Facebook permettait le cryptage dans son SaaS, alors comment pourrait-on cibler les clients avec
des publicités qui sont plus efficaces et qui se rapportent à vos activités affichés? Si vos données ont
été cryptées, alors les aspects du business model du fournisseur seraient compromis.

6.3 Le HAIL : une solution RAID pour le Cloud

La Couche d'intégrité et de haute disponibilité HAIL (High-Availability and Integrity Layer) est un
système cryptographique distribué qui permet à un ensemble de serveurs de prouver à un client
qu'un fichier stocké est intacte et récupérable. Il renforce, unifie formellement, et rationalise les
approches distinctes de la communauté cryptographique et distribué-systèmes.
Les preuves dans le HAIL sont efficacement traitables par les serveurs et très compacte, générale-
ment quelques dizaines ou centaines d'octets, indépendamment de la taille du fichier.
La HAIL vérifie cryptographiquement et réaffecte ré-activement les partages de fichiers. Il est ro-
buste contre un actif, adversaire mobile, i.e. qui peuvent progressivement corrompu l'ensemble des
serveurs.
Elle propose un modèle solide et contradictoire officiel pour Hail, et une analyse rigoureuse et des
choix de paramètres. Nous montrons comment la HAIL améliore la sécurité et l'efficacité des outils
existants, comme la preuve de récupération (PoR) déployée sur des serveurs individuels.

Comment ça marche ?
Dans la HAIL, un client diffuse un fichier F avec une redondance entre n serveurs et garde son état
au niveau local. L'objectif de la HAIL est d'assurer la résilience face à un adversaire mobile. Ce type
d’adversaire puissant peut potentiellement corrompre tous les serveurs à travers la durée de vie
complète du système.
13

Supposant qu’un adversaire mobile qui a pu contrôler que b sur n serveurs à un moment. Nous nous
référons à un pas de temps dans ce contexte comme une Période.

Fig. 6. La répartition d’un fichier selon le modèle HAIL

Dans chaque Période, le client qui possède F (ou potentiellement une autre entité pour le compte du
client) effectue un certain nombre de vérifications afin d'évaluer l'intégrité de F dans le système. Si
des corruptions ont été détectées sur certains serveurs, alors F peut être reconstitué à partir de la
redondance dans des serveurs intacts et les serveurs connus défectueux remplacé. Ces tests d'intégri-
té périodiques et réparation sont une partie intégrante pour garantir la disponibilité des données
contre un adversaire mobile: Sans les vérifications d'intégrité, l'adversaire mobile peut corrompre
tous les serveurs à tour de rôle sur des périodes différentes et de modifier ou de purge F à volonté.

Système de réplication :

Un premier concept pour HAIL est de répliquer F sur chacun des n serveurs. A travers ces serveurs,
la redondance peut être utilisée pour vérifier l'intégrité. Pour effectuer une vérification de l'intégrité,
le client choisit simplement un fichier aléatoire de blocs position j et récupère le bloc correspondant
Fj de F de chaque serveur. Pourvu que tous les blocs retournés soient identiques, le client conclut
que F est intact dans cette position. S’il détecte des incohérences, alors il reconstitue F (à l'aide de
décodage majoritaire dans serveurs) et supprime / remplace des serveurs défectueux. Par multiple
échantillonnage du fichier, le client peut augmenter sa probabilité de détecter de corruptions.
Cependant, une limitation de cette approche est que le client ne peut pratiquement inspecter qu’une
petite portion de F. Une autre limitation est que tandis que le client vérifie la cohérence entre les
serveurs, il ne vérifie pas directement l'intégrité, c'est à dire, que le bloc pour la position j récupéré
est celle initialement stockés avec F. Par conséquent, cette approche simple est vulnérable à une
attaque rampante. L’attaqueur prend une position aléatoire i et change le bloc d'origine Fᵢ valeur à
une valeur corrompue Eᵢ dans tous les serveurs corrompus dans une période donnée.

Système de réplication avec PoR :

Pour obtenir une meilleure résilience contre une attaque, il est recommandé d’employer un système
de PoR (Proof of Retrievability) sur chacun des n serveurs. Dans un système de PoR à serveur
unique, F est codée sous un code correcteur d'erreurs (ou code d'effacement) que nous nous référons
dans la HAIL par le code du serveur. Le code du serveur rend chaque exemplaire du F robuste
contre une tentative de corruption de bloc.
 14

Code de dispersion avec les PoR :

Pour améliorer la surcharge de stockage de la réplication avec le PoR il y a une approche plus intel-
ligente pour créer une redondance entre les serveurs de fichiers. Plutôt que de répliquer le fichier F à
travers les serveurs, il est possible de le distribuer à l'aide d'une correction d'erreur (ou l'effacement)
de code. Il est connu dans la HAIL comme code de dispersion. Dans le HAIL, chaque bloc du fi-
chier est individuellement répartit sur les serveurs sous le code n dispersions.

Fig. 7. La répartition d’un fichier selon le modèle HAIL et en utilisant le code de dispersion

7 Conclusion
Le phénomène du Cloud Computing est inéluctable. Beaucoup de responsables informatiques se
méfient de la gestion de la sécurité nécessaire pour le Cloud Computing. Toutefois, ces risques sont
équilibrés par les avantages apportés par le Cloud Computing. Les économies de coûts est l'argu-
ment favorisée par les PDG et directeurs financiers, et le responsable Sécurité aura à résoudre les
différents risques liés à la sécurité du Cloud Computing. Le Cloud n'est pas une technologie nou-
velle, mais une nouvelle façon de faire les choses en matière de technologie de l'information. Résis-
ter au changement est toujours difficile, des spécialistes de la sécurité de l'information auront à ac-
compagner le développement du Cloud, afin de permettre à ses usagers de bénéficier de grands
avantages que le Cloud offre.

[1]V. Winkler, “Securing the Cloud : Cloud Computer Security Techniques and Tactics,” Syngress 2011
[2]N. Santos, K. Gummadi, R. Rodrigues, Towards Trusted Cloud Computing, 2010.
[3]TCG. https://www.trustedcomputinggroup.org..
[4]K. Bowers, A. Juels, A. Oprea, HAIL: A High-Availability and Integrity Layer for Cloud Storage – Novembre 2009
RSA Laboratories.
[5]Security Guidance for Critical Areas of Focus in Cloud Computing – April 2011. Cloud Security Alliance.
[6]Cloud Computing - Benefits and recommendations for information Security - November 2009. European Network and
Information Security Agency (ENISA)
[7]CloudSecurity.org
[8]Clouds or storm clouds? Cloud Computing Security – May 2010 Security Acts issue

View publication stats