Rapport de Stage - VF

Master 2, Advanced Communication Networks
Rapport de stage : Sécurisation d’une plateforme multicloud
Réalisé par : Katia Si Hamdi
 Tuteur pédagogique : Pascal Urien

 Maître de stage : Vincent Gervais
Année Universitaire : 2017/2018

Note
Ce document contient des informations confidentielles qui sont la propriété de la société

Devoteam. Il ne peut être diffusé ou transféré sans l’autorisation écrite d’une personne
habilitée par Devoteam. Il ne peut être copié ou reproduit sous quelque forme que ce soit.
Les contrefacteurs seront jugés responsables pour le paiement des dommages. Tous droits
réservés y compris pour les brevets, modèles d’utilité, dessins et modèles enregistrés.
I
Remerciements
En premier lieu, je tiens à témoigner ma profonde gratitude et mes remerciements les

plus sincères à l’équipe du cursus ACN pour la richesse d’enseignement et l’engagement
des professeurs qui m’ont permis de développer la rigueur et les connaissances nécessaires
pour participer à un stage de cette envergure, plus particulièrement à Jean-Louis Rougier
pour son soutien, son suivi et ses conseils.
Je remercie également l’équipe Devoteam pour leur accueil et leur intérêt, notamment mon
maître de stage Vincent Gervais pour ses précieux conseils, ses orientations, et aussi pour
ses qualités humaines d’écoute, de soutient et de compréhension tout au long de ce stage.
Dans un cadre plus personnel, je remercie mes très chers parents, pour leur soutien incon-
ditionnel, leur amour et sacrifices inestimables et pour m’avoir inlassablement poussé à
aller de l’avant. Tout mot dit, je ne les remercierais jamais assez. Je remercie également
mes adorables soeurs: Cylia, Akila, Liza et notre ange Yasmine, sans lesquelles rien ne
serait autant agréable.
Je ne saurais terminer mes remerciements sans remercier toute ma famille qui a cru
en moi ainsi que tous mes amis, notamment ceux du master ACN et mes collègues de
Devoteam auprès desquels j’ai passé les meilleurs moments durant cette année.
II
Abstract
Abstract
This report presents an overview of my work during my internship. This internship was a
part of Advanced Communication Networks Master operated by Telecom ParisTech and
Ecole Polytechnique within the Paris-Saclay university. I worked at Devoteam in the Risk
and Security division based in Levalloit-Perret, France. I joined for 22 weeks the Cloud
and Security team on April 2018.
The topic of this internship was the study of the security of multicloud infrastructures. I
was new in both security and Cloud computing, so I had first to study the cloud and the
related technologies. Then, in a second part, I had to go deeper by studying the security
issues related to the cloud and the solutions offered by different cloud providers. A final
part is devoted to Multicloud.
Keywords: Cloud, Multicloud, Security.
1
Table des matières
Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Introduction Générale 1
1 Organisme d’accueil : Devoteam 2

1.1 Présentation de l’entreprise Devoteam . . . . . . . . . . . . . . . . . . . . . 2
1.2 Domaines d’activité et clients . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Bilan financier et secteur d’activité . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Organisation de Devoteam . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Offer Unit Risk Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Généralités sur le cloud 8

2.1 Définition du cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Les caractéristiques du Cloud . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Les modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Le Cloud privé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Le cloud communautaire . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Le cloud public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.4 Le cloud hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Les modèles de services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 SaaS (Software as a service) . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 PaaS (Platform as a Service) . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 IaaS (Infrastructure as a Service) . . . . . . . . . . . . . . . . . . . 11
2.4.4 Autre modèle de service . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 La responsabilité partagée dans le cloud . . . . . . . . . . . . . . . . . . . 12
2.5.1 La trus boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 L’effet de la sécurité sur l’adoption du cloud . . . . . . . . . . . . . . . . . 13
2.7 La sécurité du cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7.1 La sécurité physique (sécurité de l’infrastructure) . . . . . . . . . . 15
2
Abstract
2.7.2 La gestion des identités et des accès . . . . . . . . . . . . . . . . . 16

2.7.2.1 Les questions à se poser avant de mettre en place un cloud
IAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7.2.2 Mise en place d’un cloud IAM . . . . . . . . . . . . . . . 18
2.7.2.3 Les contrôles . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.3 La protection des données . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.3.1 L’outil : DLP . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.3.2 Cas de perte de données : Contre-mesures . . . . . . . . . 22
2.7.4 Le chiffrement des données . . . . . . . . . . . . . . . . . . . . . . . 22
2.7.4.1 Mécanismes de chiffrement . . . . . . . . . . . . . . . . . 23
2.7.4.2 Stratégie de gestion des clés . . . . . . . . . . . . . . . . 23
2.7.4.3 Solution HSM . . . . . . . . . . . . . . . . . . . . . . . . 23
2.7.5 Protection des données personnelles : RGPD . . . . . . . . . . . . . 23
2.7.5.1 Anonymisation des données . . . . . . . . . . . . . . . . . 24
2.7.5.2 Pseudonymisation des données . . . . . . . . . . . . . . . 24
2.7.5.3 Anonymisation VS Pseudonymisation . . . . . . . . . . . 25
2.7.6 La sécurité du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7.6.1 Les ACL et les Security groups . . . . . . . . . . . . . . . 25
3 Le Multicloud 26
3.1 Les avantages du Multicloud . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Les challenges du multicloud . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 La sécurité du multicloud . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1.1 SLA : Service-Level Agreement . . . . . . . . . . . . . . . 28
3.3 Les fournisseurs de cloud publics . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Comparaison entre les services de sécurité des fournisseurs Cloud . 29
3.3.1.1 AD as a service . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1.2 Certificate Manager . . . . . . . . . . . . . . . . . . . . . 30
3.3.1.3 Dedicated HSM . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1.4 IAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1.5 Key Storage Management . . . . . . . . . . . . . . . . . . 31
3.3.1.6 Security assessment . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1.7 Threat detection and monitoring . . . . . . . . . . . . . . 31
3.3.1.8 Web Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1.9 ACL et groupes de sécurité . . . . . . . . . . . . . . . . . 31
3
Abstract
4 DEVOLAB 33
4.1 Presentation of DEVOLAB . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Architecture de DEVOLAB . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1 Cas d’usage de Devolab : Dans les universités . . . . . . . . . . . 34
4.3 Sécuriser DEVOLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1 Terraform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1.1 Infrastructure as a code IAC . . . . . . . . . . . . . . . . 36
4.3.2 Construction d’une plateforme Multicloud . . . . . . . . . . . . . . 36
4.3.2.1 Découverte de service et répartition de charge . . . . . . 37
4.3.2.2 Stockage et réplication des données en mode Multicloud . 37
4.3.2.3 Réplication synchrone et asynchrone . . . . . . . . . . . . 38
4.3.3 La sécurisation de la plateforme . . . . . . . . . . . . . . . . . . . . 38
Sytnthèse et Conclusion 39
Références 40
4
Table des figures
1 Les axes de développement de Devoteam . . . . . . . . . . . . . . . . . . . 3

2 Clients de Devoteam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Secteurs d’activité Devoteam . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 Répartition par branche des actions de R&D . . . . . . . . . . . . . . . . 5
5 Organisation de Devoteam Technology Consulting . . . . . . . . . . . . . 5
6 Les modèles de déploiement du cloud . . . . . . . . . . . . . . . . . . . . . 9

7 Les modèles de service du cloud . . . . . . . . . . . . . . . . . . . . . . . . 11
8 La trust boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9 La trust boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10 Gestion des Identités et des Accès "IAM" . . . . . . . . . . . . . . . . . . . 16
11 Cloud IAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12 Les axes de la DLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13 Architecture de la DLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
14 Statistiques sur l’utilisation des stratégies multicloud par les entreprises en

2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
15 Les parts de marché des différents fournisseurs de cloud public . . . . . . . 30
16 Comparatif des services de sécurité des providers cloud ( AWS, Azure, GCP
& IBM Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
17 Cas d’usage de la plateforme Devolab . . . . . . . . . . . . . . . . . . . . . 33

18 Architecture globale Devolab . . . . . . . . . . . . . . . . . . . . . . . . . . 34
19 Architecture niveau 2 Devolab . . . . . . . . . . . . . . . . . . . . . . . . . 35
20 Exemple d’utilisation de DEVOLAB dans les universités . . . . . . . . . . 35
21 Infrastructure multicloud (AWS et GCP) . . . . . . . . . . . . . . . . . . . 37
5
Introduction Générale
Introduction Générale
Les technologies de l’information et de la communication évoluent et révolutionnent nos
modes de vie et de travail. Le cloud computing ou informatique virtuelle, est apparu ces
dernières années comme un nouveau modèle de gestion et d’utilisation des systèmes in-
formatiques. Le concept consiste à déporter sur des serveurs distants les traitements et
stockages habituellement effectués en local afin d’y accéder sous forme de service.
En fonction des besoins, les services du cloud computing peuvent s’étendre du simple
approvisionnement de machines virtuelles, services IaaS (Infrastructure as a service) aux
services de type applications SaaS (Software as a service). Plusieurs modes de déploie-
ment de ces services peuvent être employés selon l’ « institut national des normes et de
la technologie » des Etats-Unis (National Institute of Standard and Technology NIST)
parmi lesquels on peut distinguer le mode public et le mode privé.
Le Cloud génère de nouveaux risques, tant du côté du prestataire que du côté du client,
notamment au niveau de la pérennité des données. Il est donc nécessaire de s’assurer que
ces nouveaux risques sont maîtrisés avant de choisir sa solution Cloud.
Le déploiement de plusieurs plateformes Cloud offre plus de marge de manoeuvre et de
choix. Mais, pour les responsables IT, cette gestion multicloud reste un point épineux.
Comme les infrastructures traditionnelles, l’utilisation des services d’infrastructure Cloud

requièrent donc la mise en oeuvre de mesures et contrôles de sécurité par leurs utilisateurs.
Pour ce faire, les entreprises doivent adapter leur politique de sécurité à ces nouvelles
technologies pour profiter de leur puissance sans augmenter leur surface d’exposition aux
cyberattaques.
Contexte et Objectifs
L’objectif de ce stage consiste à intérvenir dans la sécurisation d’une plateforme multi-
cloud au sein de l’équipe "Cloud Architecture" de Vincent Gervais et de participer au
développement de l’offre Cloud Cyber Security ainsi qu’aux activités de conseil réalisées
pour des prospects ou des clients de grands comptes.
Le présent rapport fera l’objet d’une description synthétique de ce que j’ai pu acquérir
comme compétences durant le stage, il comporte plusieurs parties organisées comme suit :
La première partie est consacrée à la présentation de l’organisme d’accueil "Devoteam" et
à la présentation du contexte du stage et de la problématique traitée. Puis vient la seconde
partie, elle comporte essentiellement les généralités sur le cloud ainsi que des problèmes de
sécurité qui y sont liés. La troisième partie traite les plateformes multicloud. Finalement,
le rapport est clôturé par un cas pratique : sécurisation de DEVOLAB, une plateforme
multicloud de Devoteam.
1
Chapitre 1
Organisme d’accueil : Devoteam
1.1 Présentation de l’entreprise Devoteam

Devoteam est un acteur majeur du conseil en technologies innovantes et management
pour les entreprises. La révolution des réseaux IP pousse en 1995 les frères Godefroy et
Stanislas de Bentzmann à créer une enseigne permettant de répondre aux problématiques
de sécurité soulevées par l’avènement des réseaux IP.
Au cours des 20 dernières années, Devoteam a aidé ses clients à tirer parti des opportunités
technologiques pour transformer leurs actifs et activités au travers de 3 grands axes :
• Favoriser la construction d’infrastructures informatiques globales grâce à l’intercon-

nexion des réseaux, des Data Centers et aujourd’hui des solutions Cloud.
• Transformer les services informatiques en outils agiles orientés services répondant

aux besoins des entreprises.
• Repenser les processus pour optimiser l’efficacité opérationnelle tout en développant

d’excellentes expériences utilisateurs pour les consommateurs et les utilisateurs.
Actuellement Devoteam compte plus de 5200 collaborateurs engagés dans la bataille digi-
tale des clients. Les collaborateurs sont présents dans 17 pays majoritairement en Europe
et Moyen Orient. Le groupe présente cependant une volonté de développement à l’interna-
tional forte d’ici 2020, l’objectif étant de doubler le nombre de pays dans lequel Devoteam
est implanté d’ici 2 ans.
Depuis 2005 Devoteam a diversifié son secteur d’activité en s’attaquant à la transforma-

tion des services informatiques avec l’utilisation du framework Information Technology
Infrastructure Library (ITIL) qui est une liste de bonnes pratiques permettant d’aligner
les services informatiques avec les besoins de chaque entreprise.
Aujourd’hui Devoteam cherche à aller au-delà des sujets IT en accompagnant ses clients
dans leur transformation digitale et appliquer pleinement son rôle de conseil grâce à son
expertise dans le milieu. Le slogan de Devoteam montre cette volonté d’accompagnement
dans les transformations transverses de leurs clients, car chez Devoteam "We are Digital
Transformakers".
2
Chapitre 1 : Organisme d’accueil, Devoteam
Figure 1 – Les axes de développement de Devoteam
1.2 Domaines d’activité et clients

Depuis sa création, l’entreprise Devoteam ne cesse de croitre. Elle accompagne ses clients
dans leur transformation digitale, devenue indispensable en cette ère d’expansion numé-
rique.
Devoteam accompagne de multiples entreprises dans tous les secteurs d’activités, tels
que : Bancaire, Automobile, Retail, Energie, Industrie et Service public, ainsi que des
entreprises présentes dans le CAC40. Nous pouvons citer : TOTAL, BNP PARIBAS,
AXA, AIRBUS, BUREAU VERITAS, etc.
Figure 2 – Clients de Devoteam
1.3 Bilan financier et secteur d’activité

L’activité de Devoteam est séparée en 7 offres distinctes représentées sur le schéma suivant
et explicitées par la suite :
1. Agile IT : Transformer l’informatique de base en une plate-forme numérique orientée

services, pour répondre aux besoins des entreprises en matière de rapidité, d’agilité
et de qualité.
3
Figure 3 – Secteurs d’activité Devoteam
2. Transformation management : Soutenir les projets de transformation globale et

transversale des clients, depuis la définition de la stratégie jusqu’à son implémenta-
tion : organisation, culture, solutions.
3. Digital Workplace : Créer un environnement de travail qui rend les employés plus
efficaces et des organisations plus agiles.
4. Cyber Security : Comprendre les menaces et contrer les cyberattaques avec des
personnes talentueuses, une expertise technique et une connaissance approfondie de
l’industrie.
5. Data as a service : Accélérer la prise de décision en fournissant aux entreprises des
services de données rapides, intelligents et de haute qualité.
6. Business Process Excellence : Tirer parti du numérique pour améliorer l’excellence
opérationnelle et créer des processus qui changent l’entreprise.
7. Customer Experience : Concevoir des services et des expériences numériques qui
engagent les consommateurs et les employés.
Devoteam est une société majeure dans le monde du conseil. Il n’y a pas de production
de bien car il s’agit d’une entreprise du secteur tertiaire.
En 2016 Devoteam a enregistré un chiffre d’affaire de 479 M réparti au travers des filiales
internationales. Devoteam a fait le pari fou de doubler leur chiffre d’affaire, nombre d’em-
ployés ainsi que nombre de pays dans lequel elle est représentée d’ici 2020, ce programme
se nomme Scale !2020. Ce programme ambitieux est une opportunité pour développer le
business rapidement, en 2017 le chiffre d’affaire était de plus de 540 M, dans la ligné de
ce programme.
Le leitmotiv de Devoteam est la proactivité, une volonté d’être perpétuellement actif
même lorsque les consultants ne sont pas en mission est inculquée. Voici la répartition des
activités de RD en 2017.
1.4 Organisation de Devoteam

Devoteam a été créé en 1995 par les frères De Bentzmann à ce jour plusieurs branches
ont été créées. La plus importante de ces branches est Devoteam Technology consulting,
4
Figure 4 – Répartition par branche des actions de R&D
Figure 5 – Organisation de Devoteam Technology Consulting
elle regroupe les Offer Units (OU) les plus développées, notamment l’OU Risk Security
que j’ai intégrée au cours de mon stage.
Cette organisation par branche permet d’adopter une stratégie de management plus di-
recte. Chaque directeur d’OU possède une équipe de managers et d’opérateurs dépendants
d’eux, l’intérêt de séparer les branches en OU est que toute personne de l’OU aura au
maximum deux managers entre lui et la direction ce qui facilite les relations de proximité.
Au sein même de chaque OU, tous les consultants sont encadrés par :
5
Un Carrière Manager (CM) qui a pour objectif de gérer la carrière du consultant en

étant à l’écoute, en lui proposant des formations, missions et certifications adaptées à sa
trajectoire professionnelle. Le CM va présenter les performances du consultant lors des
comités carrières.
• Un Skill Center Manager (SCM) il s’agit d’un manager proche du consultant, qui
s’occupe de superviser le consultant dans les phases d’avant-vente et de production.
• Un Delivery Responsible Manager (DRM) qui s’occupe du bon déroulement des

missions et évalue le consultant à la fin de celle-ci.
La proximité du management permet de réagir rapidement si le consultant rencontre un

problème dans sa mission ou souhaite modifier sa trajectoire professionnelle. En effet les
informations ne sont pas forcées de remonter jusqu’au directeur de l’OU, ce qui pourrait
affecter la vitesse de réaction et la prise de décision.
1.5 Offer Unit Risk Security

L’OU Risk Security est scindée en trois offres sous-jacentes directement liées à la cy-
bersecurité : l’offre Risques et stratégie avec pour directeur Julien BUI, l’offre Protection
de donnée avec pour directeur Benoît MICAUD et l’offre continuité d’activité avec pour
directeur Julien BEAUSSART.
Cette OU compte en 2018, 154 employés répartis dans les 3 offres citées ci-dessus, l’objectif
de l’OU est de compter 220 consultants d’ici 2020.
En 2017 le chiffre d’affaire cible était de 12,965 M, le chiffre d’affaire réalisé et de 13,580M
e grâce à une grosse activité de toute l’équipe et notamment des commerciaux qui visitent
les clients pour trouver des missions. L’objectif de l’année 2018 pour l’OU est d’augmenter
le chiffre d’affaire de 3, 711 M.
La volonté d’excellence de cette entreprise se ressent au sein même de cette OU qui a pour
objectif de devenir dans les années à venir un des top 3 cabinet de conseil en traitement
des risques, sécurité et continuité d’activité. Durant ce stage j’ai intégré l’équipe de Julien
BUI, cette équipe a un éventail d’expertise très large divisé en 7 grandes catégories :
• Évaluation de la maturité cyber sécurité et résiliences aux risques : Soutenir les

transformations numériques des clients, piloter la Cyber Sécurité au niveau appro-
prié de la gouvernance d’entreprise et considérer l’informatique comme une question
de risque, de conformité et de compétitivité.
• Évaluation et soutient dans la mise en place de projet numérique : Identifier et

évaluer les risques sur les projets numériques. Définir un plan de traitement des
risques hiérarchisé.
• Conformité et réglementation : Atteindre le niveau de conformité souhaité pour les

politiques et réglementations de sécurité applicables.
• Protection des infrastructures critiques : Établir et maintenir une gouvernance de

la cyber-sécurité des systèmes de contrôle industriel (SCI).
6
• Sensibilisation : Produire des contenus pour des modules d’e-learning avec des ap-
proches spécifiques prenant en compte les besoins des clients (pédagogie, matériels,
etc.).
• Trust Governance Framework (GRC) : Mettre en œuvre un cadre de gouvernance,

de risque et de conformité (GRC).
• Cybersécurité cyberassurance : Assurer la résilience aux risques résiduels inaccep-

tables.
J’ai intégré l’équipe « Cloud Architecture » de Vincent GERVAIS pour participer au dé-
veloppement de l’offre Cloud Cyber Security et participer aux activités de conseil réalisées
pour des prospects ou des clients grands comptes.
Ma principale mission au sein de l’équipe était dans un premier temps connaitre et mai-
triser les risques associés au Cloud Computing et pour ce faire avoir donc une bonne
compréhension du domaine du cloud, afin de proposer des solutions et des bonnes pra-
tiques pour sécuriser de la plateforme multicloud DEVOLAB.
7
Chapitre 2
Généralités sur le cloud
Le recours au Cloud Computing est devenu de plus en plus remarquable compte tenu de
plusieurs services qu’il offre, notamment le service PaaS qui représente une plateforme
optimisée pour développer, tester, déployer et gérer le fonctionnement des applications et
des logiciels, tout en assurant un cout réduit.
Au cours de ce chapitre, nous allons présenter les différents aspects liés au cloud, à savoir
les caractéristiques, les modèles de déploiement, les modèles de services et les problèmes
de sécurité liés au cloud.
2.1 Définition du cloud

Plusieurs organisations informatiques et sociétés d’études de marché telles qu’IBM(2009),
Sun Microsystems(2009) et Forrester Research(2008) ont essayé de donner leur propre
définition du Cloud Computing. Ces discussions aboutissent à une définition standard
proposée par l’Institut National des Standards et de la Technologie( ou NIST pour Na-
tional Institute of Standards and Technology) qui décrit le Cloud Computing comme un
modèle permettant d’établir un accès par le réseau à un réservoir partagé des ressources
informatiques standards et configurables (réseau, serveurs, stockage, applications et ser-
vices) qui peuvent être rapidement mobilisées et mises à disposition en minimisant les
efforts de gestion ou les contacts avec le fournisseur de service »
2.2 Les caractéristiques du Cloud

Le Cloud Computing a cinq caractéristiques essentielles qui permettent de le distinguer
de tout autre modèle de calcul. Ces cinq caractéristiques, telles qu’elles sont définies par
le NIST, sont :
1. Libre-service à la demande : La capacité de stockage et la puissance de calcul

sont adaptées automatiquement au besoin du consommateur sans nécessité d’une
intervention humaine avec le fournisseur des services.
2. Accès ubiquitaire au réseau : l’ensemble des services offerts par le Cloud Com-
puting sont mis à disposition sur l’internet. L’accès se fait à travers des techniques
8
Chapiter 2 : Généarlités sur le cloud
standardisées qui permettent de s’en servir aussi bien avec un ordinateur qu’un
téléphone ou une tablette.
3. Mise en commun des ressources : A l’aide d’un modèle multi-locataire, des res-
sources telles que la bande passante, les machines virtuelles, la mémoire, la puissance
de traitement et la capacité de stockage sont partagées entre plusieurs consomma-
teurs. ces ressources sont affectées dynamiquement et réaffectées en fonction des
besoins des clients.
4. Élasticité rapide : Les utilisateurs peuvent rapidement et automatiquement aug-
menter et diminuer les ressources informatiques selon le besoin. Cela donne aux
consommateurs l’impression que les ressources sont infinies. Lorsque les ressources
ne sont plus utilisées, elles sont renoncées dans le réservoir des ressources.
5. Service mesuré : la quantité des ressources consommées (stockage, CPU, bande
passante, comptes utilisateurs actifs, etc.) dans le Cloud est mesurée de façon précise,
à des fins de contrôle, d’adaptation des moyens techniques et de facturation. Par
conséquent les clients paient seulement ce qu’ils utilisent réellement.
2.3 Les modèles de déploiement

Il y a des nombreuses considérations à tenir en compte lors du déplacement de l’envi-
ronnement d’une entreprise au Cloud. Par exemple, des prestataires de services semblent
s’intéresser au coût d’exploitation, tandis que d’autres préfèrent la fiabilité et la sécurité.
En conséquence, selon le besoin du client il existe différents types du Cloud tel illustrés
dans la figure 6 :
Figure 6 – Les modèles de déploiement du cloud
2.3.1 Le Cloud privé

Dans ce modèle, l’infrastructure Cloud est dédiée à l’utilisation exclusive d’une seule
organisation. Cette infrastructure est détenue ou louée par une organisation et elle est
9
gérée par l’organisme lui-même, un tiers ou une combinaison des deux, et elle peut exister
dedans ou en dehors des locaux. Elle fournit un contrôle maximum sur les données, la
sécurité et la qualité du service. Cependant, elle est souvent critiquée pour être similaire
aux serveurs propriétaires traditionnels.
2.3.2 Le cloud communautaire

Dans ce modèle, l’infrastructure est partagée entre plusieurs organisations ayant des pré-
occupations similaires (par exemple, les exigences de sécurité, de la politique et des consi-
dérations de conformité à des règles spécifiques). Ce modèle peut être hébergé au sein de
l’organisation ou en dehors des locaux, et elle peut être gérée en interne ou par des tiers.
2.3.3 Le cloud public

Dans ce modèle, l’infrastructure du Cloud est mise à la disposition des utilisateurs publics.
Elle peut être détenue, gérée et exploitée par une entreprise, un établissement scolaire, un
organisme gouvernemental, ou une combinaison entre eux. Il est hébergé dans les locaux
du prestataire de Cloud.
2.3.4 Le cloud hybride

C’est une combinaison du modèle public et privé dont une partie de l’infrastructure de
service s’exécute dans un Cloud privé tandis que la partie restante est exécutée dans un
Cloud public. Cela se fait lorsque le Cloud privé a besoin d’un service spécial de Cloud
public.
L’infrastructure de déploiement de ce modèle est gérée par l’organisation et par un four-
nisseur tiers. Ce modèle offre un niveau élevé d’évolutivité et de tolérance aux pannes.
2.4 Les modèles de services

Selon NIST, les services Cloud sont délivrés selon trois (03) principaux modèles : Infrastructure-
as-a-service (IaaS), Platform-as-a-service (PaaS) et Software-as-a-service (SaaS), suivant
une approche ascendante.
Afin de mieux comprendre cette classification, dans le modèle classique, l’environnement
informatique standard peut être composé par plusieurs couches qui partent du bas niveau
(le matériel physique) vers le haut niveau (les applications à utiliser). La classification
selon le type du service correspond au niveau de responsabilité dans la gestion de ces
couches que ce soit par les fournisseurs ou par les utilisateurs.
Traditionnellement, toutes les couches sont gérées par l’utilisateur lui-même. Avec le Cloud
Computing, l’utilisateur n’a plus en charge la totalité des couches et en fonction du niveau
des sous-ensembles de couches nous distinguons ces trois types de services tels illustrés
dans la figure 7 :
10
Figure 7 – Les modèles de service du cloud
2.4.1 SaaS (Software as a service)

SaaS ou parfois appelé «logiciel à la demande», consiste à la mise en disposition des
logiciels fonctionnant sur l’infrastructure Cloud, livrés à la demande à plusieurs clients
via l’internet à travers d’une interface légère (navigateur web par exemple). Une seule
occurrence du logiciel s’exécute sur le Cloud et offre des services à plusieurs utilisateurs
finaux. Les principaux leaders du marché offrant le SaaS sont : Google offre Google Apps
(messagerie et bureautique), SalesForce offre CRM (Customer Relationship Management)
et Microsoft offre Office 365 (messagerie, outils collaboratifs, bureautique).
2.4.2 PaaS (Platform as a Service)

Ce modèle fournit aux développeurs une plate-forme constituée d’un environnement de
développement avec des outils de programmation, de compilation, de débogage et de test.
Cela pour leurs donner la flexibilité de développer des applications réelles. Les principaux
leaders du marché offrant le PaaS sont : Microsoft avec Windows AZURE, Google avec
Google App Engine et Orange Business Services.
2.4.3 IaaS (Infrastructure as a Service)

IaaS se réfère au partage des ressources matérielles pour l’exécution des services, en uti-
lisant généralement la technologie de virtualisation. Il est considéré comme le niveau le
plus bas dans les modèles de livraison du Cloud. IaaS offre aux consommateurs la capacité
d’acquérir du traitement, du stockage, des réseaux et d’autres ressources informatiques
fondamentales.
Aussi il leur permet de déployer et d’exécuter leur propre logiciel, qui peut inclure le
système d’exploitation et les applications. Les principales offres IaaS proposées sont :
11
Amazon Web Services (AWS) avec Elastic Compute Cloud (EC2), Microsoft avec Azure
et Google avec Compute Engine.
2.4.4 Autre modèle de service

Le SaaS, le PaaS et l’IaaS sont les modèles de services standardisées par le NIST, bien que
d’autres modèles de services puissent être générés lorsqu’un fournisseur de l’un des trois
services mentionnés ci-dessous exploite un autre type de service. Cela donne la naissance
aux services suivants : Data base as a Service (DBaaS), Business Process as a Service
(BPaaS), Desktop as a Service (DaaS), Storage as a Service (STaaS), Workplace as a
Service (WaaS), etc.
2.5 La responsabilité partagée dans le cloud
2.5.1 La trus boundary

La responsabilité partagée dans le cloud, « Trust Boundary » en anglais, est un périmètre
logique qui s’étend généralement au-delà des limites physiques pour représenter la mesure
dans laquelle les ressources informatiques sont fiables. Dans le Cloud, la limite est associée
à la confiance émise par les clients(les organisations), voir la figure 8.
Figure 8 – La trust boundary
La responsabilité de la sécurité dans le cloud est toujours partagée. Le graphique suivant

9 montre l’évolution de la “trust boundary” dans les trois modèles de service du cloud
IaaS (Infrastructure as a Service), PaaS (Platform as a Service) et SaaS (Software as a
Service).
L’impact majeur de la “trust Boundary” est principalement d’étendre la limite de confiance
tout en maintenant la responsabilité de chaque partie.
12
Figure 9 – La trust boundary
Il faut savoir que la sécurité du cloud n’est pas en la délégation de la sécurité aux four-
nisseurs. Les clients, en plus des fournisseurs, ont une responsabilité non négligeable dans
la sécurité du cloud. Il est donc important d’insister sur le fait que la sécurité du cloud
n’est pas une sécurité déléguée.
On peut définir deux niveaux de responsabilités partagées entre le fournisseur du cloud

et le client.
1. Le fournisseur cloud : Responsable de la sécurité de l’infrastructure cloud (Ser-

veurs physiques, stockage, accès aux centre de données réseau, base de données).
Pour se faire, le fournisseur s’appuie sur des solutions de pare-feu ou de reconnais-
sance d’empreintes.
2. Le client : Responsable de la sécurité de tout ce qui est déployé dans son infra-
structure cloud( Services de bases comme le calcul, le réseau, le stockage, . . . etc).
Le client a donc pour rôle de définir les règles de son pare-feu, mettre en place les
solutions de chiffrement, sauvegarde, restreindre les privilèges et les droits d’accès
utilisateurs.
Le client doit donc appliquer un certain nombre de pratiques qu’on peut résumer dans la
liste non exhaustive suivante :
• Intégrer une équipe de sécurité interne au seine de l’entreprise

• Ajouter le cloud aux responsabilités d’équipe SOC/Sécurité.
• Inclure la sécurité du cloud dans les rapports
• Évaluer et contrôler les mesures de sécurités mises en place
• Construire et tester la gestion des incidents
2.6 L’effet de la sécurité sur l’adoption du cloud

Le Cloud offre divers avantages aux entreprises et aux utilisateurs finaux. La flexibilité
engendrée par la facilité d’augmenter ou de diminuer les capacités des ressources selon le
besoin, la réduction des coûts et la rapidité de déploiement sont les principaux facteurs
qui attirent les industries vers les services Cloud.
Toutefois, comme toute technologie avancée, le Cloud apporte aussi son lot de risques et
de challenges. Les différents facteurs freins qui empêchent les entreprises d’aller vers le
Cloud peuvent se résumer dans les critères recensés suivants :
13
• Performance
• Control
• Complexité de construire un cloud privé
• Gestion de couts
C’est vrai que chacune de ces questions affecte l’adoption du Cloud mais le problème
majeur, qui est souvent considéré comme le frein principal à l’adoption du Cloud, est
le problème de la sécurité. Les principales menaces de sécurité affectant le paradigme
du Cloud qui ont été identifiées par le Cloud Security Alliance (CSA) sont les douze
suivantes :
1. Violations des données : le risque que les données (sensibles) de l’organisation

tombent entre des mains mauvaises.
2. Contrôle d’identification insuffisant : La violation des données peuvent survenir
à cause du plusieurs raisons : du manque d’un système de gestion d’identification
évolutif, du manque de l’authentification multi-facteur et de l’utilisation de mot de
passe faible.
3. API non sécurisées : les fournisseurs de services Cloud(ou CSP pour Cloud Service
Provider) offrent un service qui permet aux consommateurs d’interagir avec certaines
API basiques. Il est donc clair que la sécurité de ces API ne devrait pas contenir de
faiblesses exploitables.
4. Les vulnérabilités des systèmes : Ce sont des bugs exploitables dans les diffé-
rents composants du système d’exploitation (kernel, applications et bibliothèques de
système, etc.) que les attaquants peuvent utiliser pour infiltrer un ordinateurs afin
de voler des données, prendre le contrôle du système ou perturber les opérations du
service.
5. Détournement de compte : le piratage des comptes peut être établi par l’attaque
de phishing et l’exploitation des vulnérabilités du software. Ces attaques sont encore
courantes.
6. Les menaces avancées persistantes (APT pour Advanced Persistent Threats) :
Ce sont une forme de cyberattaque qui infiltre des systèmes pour s’insérer dans l’in-
frastructure informatique d’une entreprise cible.
Les APT poursuivent leurs objectifs furtivement sur de longues périodes de temps,
en s’adaptant souvent aux mesures de sécurité destinées à se défendre contre eux.
Le Spearphishing, les systèmes de piratage direct, la livraison du code d’attaque via
les périphériques USB, l’utilisation de réseaux non sécurisés ou tiers sont des points
d’accès courants pour les APT.
Une fois en place, les APT peuvent se déplacer latéralement à travers des réseaux
de centre de données et se fondre dans le trafic réseau normal pour atteindre leurs
objectifs.
7. Perte de données : Cela peut être causé par de nombreux scénarios indésirables
par exemple, se produire en raison d’attaques sur le Cloud ou des faute des CSP.
14
8. Manque de rigueur de l’organisation : il faut tenir compte des risques de

sécurité causés par une compréhension insuffisante de l’environnement et des services
déployés.
9. Utilisations frauduleuses : le Cloud permet aux consommateurs de louer une

grande quantité de puissance informatique pendant un certain temps sans la né-
cessité d’investissements matériels. Les services en Cloud sont donc également in-
téressants pour les consommateurs malveillants qui pourraient vouloir utiliser ces
services pour des activités illégales.
10. Déni de service : les attaques basées sur le déni de services (ou DOS pour Deny
of service) se sont avérées être viables contre de nombreux types d’infrastructures,
y compris celles des fournisseurs de Cloud.
Il convient, toutefois, d’indiquer que, bien que les services en Cloud soient vulné-
rables aux attaques (distribuées) de déni de services, ils offrent également une cer-
taine protection contre les DOS dans leur nature élastique qui peuvent être exploités
par les CSP pour fournir une meilleure protection des consommateurs.
11. Problèmes de technologie partagée : causés par le partage des services évolu-
tifs en termes d’infrastructure, de plate-forme et d’application entre plusieurs utili-
sateurs.
12. Les initiés malveillants : Cela peuvent être décrits par plusieurs définitions.
Le CSA utilise la définition du CERN qui dit que : " Un initié malveillant est un
employé actuel ou ancien, un entrepreneur ou un autre partenaire qui a ou a eu
un accès autorisé au réseau, au système ou aux données d’une organisation et qui
il a excédé ou fait mauvais usage de ce pouvoir et qui a une incidence négative
sur la confidentialité, l’intégrité ou la disponibilité des systèmes d’information de
l’organisation ".
Une autre définition qui peut être donnée à un malveillant initié est celle qui décrit
le modèle« honnête mais curieux ». Ce modèle est un modèles de menaces populaire
dans la majorité des schémas. Dans ce modèle, chaque entité est honnête dans le
sens où elle ne fournit pas de fausses entrées ou sorties, mais curieuse dans le sens
qu’elle essaie d’obtenir des informations supplémentaires, si le protocole le permet.
2.7 La sécurité du cloud

Afin de pallier aux problèmes de sécurité liés au cloud tels mentionnés précédemment,
plusieurs moyens sont mis en oeuvre par les clients et les fournisseurs cloud. On peut
distinguer deux niveaux : sécurité physique et Logique.
2.7.1 La sécurité physique (sécurité de l’infrastructure)

La sécurité physique concerne l’environnement du déploiement. Il faut s’assurer que :
• L’emplacement des serveurs est isolé avec un accès restreint.
15
• Protection contre les coupures et les variations de courant, ceci avec l’utilisation des
ondulateurs et des générateurs
• Climatisation : s’assurer que les salles sont équipées d’un système de climatisation
avec des capteurs de chaleur, détecteur d’incendie, etc.
2.7.2 La gestion des identités et des accès

La sécurité dans tout système consiste principalement à s’assurer que les données sont
uniquement accessibles à qui de droit dans le format, l’endroit et à l’instant autorisé.
La gestion des identités et des accès, abrégée en IAM pour Identity Access Management
en anglais, désigne le processus interne d’une entreprise permettant d’administrer et de
gérer les comptes utilisateurs et les ressources du réseau de l’entreprise, y compris les
droits d’accès des utilisateurs aux applications et aux systèmes.
L’IAM comporte principalement l’authentification des utilisateurs sur le réseau ainsi que
la traçabilité des droits d’accès (Autorisations).
l’IAM permet aux administrateurs un bon nombre de fonctionnalités dont les principales
sont :
• Accorder les autorisations nécessaires aux utilisateurs intervenant sur des ressources
spécifiques.
• Contrôler l’accès aux ressources cloud et leur visibilité afin de centraliser la gestion.
• Offre une vue unifiée des règles de sécurité pour l’ensemble de l’organisation, avec
un système d’audit intégré qui simplifie les processus de conformité.
Figure 10 – Gestion des Identités et des Accès "IAM"
La gestion des identités comporte quatre fonctions principales :
16
• La fonction d’identification : Création, gestion et suppression d’identités sans

considération d’accès ni de droits.
• La fonction d’identité pure : création, gestion et suppression d’identités sans

considération d’accès ou de droits ;
• La fonction d’accès utilisateur (log-on) : Par exemple : une carte à puce et

ses données associées utilisées par un client pour se connecter à un service ou à des
services (une vue traditionnelle) ;
• La fonction de service : un système qui fournit des services personnalisés, basés

sur les rôles, en ligne, à la demande, multimédia (contenu), basés sur la présence
aux utilisateurs et à leurs appareils.
• L’identité fédérée : un système qui s’appuie sur l’identité fédérée pour authentifier
un utilisateur sans connaître son mot de passe. C’est le moyen de relier l’ identité
électronique et les attributs d’ une personne , stockés sur plusieurs systèmes de
gestion d’identité distincts. Le modèle fédéré définit des services d’identité tels que
le « Single Sign On », la fédération d’identités et l’échange d’attributs, une fois
l’utilisateur authentifié, il peut avoir accès aux services fournis par d’autres sans
authentification supplémentaire.
2.7.2.1 Les questions à se poser avant de mettre en place un cloud IAM
Avant d’établir un système IAM, il est important de se poser les questions suivantes :
1. Combien d’utilisateurs auront accès au système ?
2. Combien de ressources système utiles pour chaque utilisateur ?
3. Est-ce qu’un seul username peut être utilisé pour plusieurs connexions simultanées ?
(Cela impacte la capacité de planification)
4. Est-ce qu’un client peut ajouter autant d’utilisateurs qu’il souhaite ?
5. Quelle est la scalability (monté en charge) requise dans les prochains mois ?
6. Est-ce que l’infrastructure actuelle répond à ce besoin (Montée en charge) ?
7. Quels sont les processus qui assurent que l’administrateur du système est informé
de la création et de la suppression des utilisateurs du système ?
8. Est-ce qu’un utilisateur sera supprimé ou désactivé après qu’une requête soit faite
pour ?
9. Est-ce qu’on conserve les données des anciens utilisateurs ou on ne garde aucune
trace ? ( Pour savoir si les anciens comptes peuvent être réinitialiser ou pas)
17
2.7.2.2 Mise en place d’un cloud IAM
Afin de mettre en place un IAM, quatre approches sont à considérer :
• Le service de gestion des identités définit les identités des utilisateurs et des res-
sources, et fournissent une gestion centralisée pour stocker et lire les identités.
• Le service de gestion des accès qui fonctionne avec le service de gestion des identités
pour contrôler quels utilisateurs ont accès à quelleS ressources. Ces services peuvent
utiliser la connexion unique (SSO/ Single Sign-On), la gestion d’accès basée sur les
rôles et d’autres fonctionnalités.
• Le service de gouvernance d’identité créé des stratégies pour la gestion des identités
afin de garantir le respect des exigences de conformité et de gouvernance.
• Le service d’authentification améliore la sécurité grâce à l’authentification multifac-
teur ou hors bande pour vérifier l’identité.
Figure 11 – Cloud IAM
2.7.2.3 Les contrôles
En plus du contrôle des autorisations relatives aux ressources, il est important de mettre
à la disposition des administrateurs l’historique complet des attributions, suppressions et
délégations des autorisations. Pour simplifier le contrôle et l’audit de l’IAM, un ensemble
de pratiques sont mises à disposition des administrateurs et qu’on peut regrouper dans
les points suivants :
Analyse et alertes :
Les fonctionnalités d’analyse et d’alerte permettent d’implémenter des indicateurs, alertes
et tableaux de bord propres au contexte client en appliquant un certain nombre de règles
de cohérence des données et des droits d’accès.
Contrôler et simplifier l’accès aux applications : L’objectif est double :
18
• Simplifier l’accès de l’utilisateur en limitant les demandes d’authentification : ne plus

authentifier l’utilisateur, après une première authentification, durant une période
déterminée.
• Contrôler l’accès aux applications : vérifier que l’utilisateur est bien autorisé à réa-
liser l’accès demandé, et tracer cet accès. Pour parvenir à cet objectif, il existe
plusieurs approches techniques, qui visent des situations différentes. Les solutions
associées s’appuient sur des référentiels d’identités et assurent l’audit et la traçabilité
des authentifications et des habilitations.
19
2.7.3 La protection des données

La sécurité des données impose avant tout une réflexion sur leur valeur. L’investissement
ne sera pas le même en fonction de leur niveau de criticité.
Plusieurs critères de sécurité doivent être appliqués sur les données afin de garantir leur
sécurité, nous en citons :
• La confidentialité : c’est de ne permettre l’utilisation des ressources qu’aux per-

sonnes autorisées, tout autre accès doit être refusé ;
• l’intégrité : les données sont complètes, exactes et licites ;
• la disponibilité : le système d’information fonctionne correctement avec le moins
d’interruptions possibles. La disponibilité des données est sujette à deux problèmes
principaux : L’indisponibilité du service lui-même du côté fournisseur et l’indispo-
nibilité des moyens d’accès au service notamment les problèmes réseaux.
• La réversibilité et la portabilité : c’est la possibilité de pouvoir obtenir une copie
de l’intégralité de ses données dans un format structuré et couramment utilisé. Ceci
permet au responsable de traitement de s’assurer qu’il puisse changer de solution si
besoin sans perte d’information et de ne pas être confronté à une situation de "prise
d’otage" des données.
2.7.3.1 L’outil : DLP
La protection contre les pertes de données connue sous le nom de LDP pour Data Loss Pre-
vention est un outil spécialisé, géré de manière centralisée par une console de commandes
et déployé sur le réseau, qui permet de réduire le risque d’une exposition (délibérée ou
accidentelle) d’un contenu électronique. Le LDP permet d’identifier, surveiller et protéger
les données utilisées, transférées et stockées par l’inspection approfondie des contenus et
l’analyse contextuelle des transactions.
Mise en place d’une politique DLP :
Afin de mettre en place une politique DLP efficace, cinq principales étapes sont à suivre :
• Définir le niveau de sécurité au sein de l’organisation, il est nécessaire de rappeler

que la DLP ne résoudra ni ne diminuera les risques au sein de l’entreprise.
• Localiser les données au sein de la société, on peut s’aider des questions suivantes :
– Combien de données sont stockées sur le réseau ?

– Quelle proportion de ces données est archivée ?
– Quelle est la quantité des données en circulation ?
– Qui a accès aux données ?
• Classer les données selon leur criticité, afin de définir l’ordre de protection de chacune
d’elles.
• Faire intervenir toutes les entités qui composent l’entreprise et s’assurer qu’aucune
loi n’a été enfreinte (le respect du RGDP).
20
• Déployer le produit de la DLP et tester plusieurs cas d’utilisation et analyser le

produit dans différents scénarios.
Les différents axes de la DLP :

La DLP comprend plusieurs axes tels représentés sur la figure ci-dessous :
Figure 12 – Les axes de la DLP
Architecure d’un DLP :
Figure 13 – Architecture de la DLP
On peut identifier trois briques composant une solution DLP : Storage, Network et End-
point.
21
-DLP Storage : Pour sécuriser les données, il faut être en mesure de définir leur empla-
cements ainsi que les personnes qui les manipulent, c’est ce que fait L’identification puis
dans un second temps les protéger.
-DLP Network : Les données en transit, via la messagerie électronique et le web, sont
plus vulnérables que d’autres (perte de données malveillantes et accidentelles découlant
d’attaques externes ou de menaces internes). Deux opérations sont à prévoir : la sur-
veillance des données en transit ainsi que les comportements et les anomalies afin d’iden-
tifier les utilisateurs présentant un risque dans le réseau ainsi que la protection de ces
dernières.
-DLP Endpoint : sert à contrôler les données aux terminaux qu’ils soient ou non connec-
tés au réseau. Il doit permettre aussi le partage en toute sécurité des données présentes
sur un dispositif de stockage amovible grâce à un chiffrement des fichiers basé sur des
politiques.
2.7.3.2 Cas de perte de données : Contre-mesures
En cas de perte de données dans l’entreprise, il est primordial d’appliquer les contre-
mesures suivantes afin d’amortir les conséquences :
• Identifier l’origine de la perte de données et les données perdues
• Limiter l’impacte de la fuite de données en supprimant les données perdues si pos-

sible
• Mise en place de mesures correctives
• Analyse des points non couverts ainsi que leur criticité
• Mesure de sécurité complémentaires
• Conduite du changement
• Étendre les mesures aux autres entités de l’organisation et communiquer auprès des
équipes.
2.7.4 Le chiffrement des données

Comme déjà mentionné, la sécurité du cloud est une responsabilité partagée entre les
clients et les fournisseurs clouds. Il en est de même pour le chiffrement des données dans,
et allant vers, le cloud. Le chiffrement est une solution incontournable pour sécuriser les
données des organisations, il est aussi question de trouver le bon équilibre entre ce qui
doit rejoindre le cloud et ce qui doit demeurer dans l’entreprise, comme les clés privées.
On peut distinguer deux niveaux de chiffrement :
22
• Chiffrement des données côté client Les clients ont une grande part de res-
ponsabilité concernant la sécurité de leur propres données et doivent se conformer
aux règles européennes et internationales vis à vis de la protection des données et
leur non divulgation, spécialement celles comportant des caractères personnels. Le
chiffrement des données côté client doit se faire à la fois sur les données locales,
allant vers le cloud et transitantes sur le réseau de l’organisation.
• Chiffrement des données côté fournisseur Il est du devoir du fournisseur de

fournir la géolocalisation des données de ses clients ainsi que des mesures mises en
place pour garantir leur sécurité. Cela offre une certaine transparence et visibilité
pour les clients. Le fournisseur a la responsabilité de chiffrer les données qu’il héberge
et est responsable de leur intégrité.
2.7.4.1 Mécanismes de chiffrement
Le chiffrement est basé sur des algorithmes avancés de chiffrement. La majorité d’entre
eux sont fondés sur des algorithmes basés sur des clés, utilisant soit une clé partagée ou
une paire de clés publique-privée. Sinon, il est aussi possible d’utiliser la segmentation en
unités, un processus qui consiste à substituer aux champs de valeurs précises des valeurs de
données anonymes (ce qui peut permettre ou non la récupération des données originales).
Pour choisir une solution de chiffrement, il faut prendre en compte la capacité de l’appli-
cation ainsi que le fournisseur cloud auquel on fait appel.
2.7.4.2 Stratégie de gestion des clés
Une stratégie de gestion de clés porte sur la manière dont une organisation contrôle les
clés de chiffrement. De nombreux fournisseurs intègrent des solutions de gestion des clés
dans leurs services. Cela fait perdre le contrôle aux clients en délégant à quelqu’un d’autre
le contrôle de l’accès à l’information.
Le mieux est donc de garder le contrôle des clés au sein de l’organisation. Grâce à une
bonne solution de gestion de clés, on peut garantir une meilleure atténuation des risques.
2.7.4.3 Solution HSM
Un HSM est un module de sécurité matérielle qui permet de générer et d’utiliser facile-
ment ses propres clés de chiffrement. C’est un appareil considéré comme inviolable offrant
des fonctions de cryptographie. Il s’agit d’un matériel électronique offrant un service de
sécurité qui consiste à générer, stocker et protéger les clés.
Les HSMs apportent beaucoup de flexibilité puisqu’ils intègrent plusieurs API standards
en plus de répondre aux standards de sécurité internationaux.
2.7.5 Protection des données personnelles : RGPD

Le Règlement Général sur la Protection des Données (RGPD) est entré en vigueur le 25
mai 2018. Avec la digitalisation et l’augmentation accrue du nombre de données, cette
nouvelle réglementation européenne demande à toute entreprise manipulant des données
23
personnelles et toute information permettant d’identifier une personne, de mettre en place

les moyens techniques adéquats pour assurer la sécurité des données des citoyens euro-
péens.
Au delà du chiffrement et des techniques de protection des données, les entreprises en
recours à l’anonymisation et pseudonymisation des données, deux techniques incontour-
nables pour se conformer à cette réglementation.
2.7.5.1 Anonymisation des données
L’anonymisation est une opération qui consiste à transformer des données personnelles de
façon à ne plus permettre l’identification de la personne concernée. Cette transformation
doit être irréversible. C’est-à-dire qu’il ne doit pas exister de méthode directe ou indirecte
permettant de rattacher les données à la personne d’origine.
Pratiquement, il existe plusieurs méthodes pour anonymiser les données, les plus connues
sont :
1. La K-Anonymity Une base est k-anonymisée si l’information concernant chaque

individu contenu dans la base ne peut pas être distinguée d’au moins k-1 autres
individus qui apparaissent également dans la base Chaque quasi-identifiant doit
apparaître dans au moins k enregistrements
Principe de la K-Anonymity
• Algorithme de généralisation
• Remplacer chaque quasi-identifiant par des valeurs moins spécifiques jusqu’à
obtenir un groupe de k valeurs identiques
• Plusieurs algorithmes ont été définis
2. La L-Diversity Le principe de la L-Diversity est de moidifier les poids

L’anonymisation des données comprend cinq étapes principales et qui sont :
• Classification des attributs

• Définition des nomenclatures
• Choix des valeurs de K et L selon les deux méthodes
• Génération de l’Open Data
• Traitement des cas rares si besoin
2.7.5.2 Pseudonymisation des données
La pseudonymisation est le traitement de données à caractère personnel de telle façon

qu’elles ne puissent plus être attribuées à une personne concernée sans avoir recours à
des informations supplémentaires, pour autant que celles-ci soient conservées séparément
et soumises à des mesures techniques et organisationnelles afin de garantir cette non-
attribution à une personne identifiée ou identifiable.
24
2.7.5.3 Anonymisation VS Pseudonymisation
La différence entre l’anonymisation et la pseudonymisation est que l’anonymisation est

irréversible tandis que la pseudonymisation ne l’est pas.
2.7.6 La sécurité du réseau

Beaucoup de données sont échangées sur les réseaux, qu’ils soient internes ou publiques.
Il est donc important de sécuriser le réseau afin de garantir la sécurité des données en
transit et leur disponibilité. Parmi les pratiques :
• L’utilisation du HTTPS lors de la consultation d’un service en ligne ou d’une API,
• L’utilisation de connexions VPN. Ces protocoles permettent, entre autres, de ga-

rantir que la donnée ne sera pas modifiée pendant son transit.
2.7.6.1 Les ACL et les Security groups
La sécurité des VPC se fait à travers les ACL et les groupes de sécurité. Il est de la
responsabilité des clients de définir les listes ACL associées aux différents sous réseaux
afin de contrôler le trafic autorisé dans le sous-réseau. Les règles du groupe de sécurité
quant à elles, sont associées à une instance bien précise pour contrôler le trafic autorisé
sur une instance et donc avoir une granularité plus fine.
25
Chapitre 3
Le Multicloud
Une stratégie multicloud consiste à faire appel à plusieurs fournisseurs de services cloud
pour profiter des avantages de chacun et élaborer des solutions parfaitement adaptées aux
besoins de l’entreprise.
En d’autres termes, c’est l’utilisation de plusieurs services de calcul et de stockage dans
une seule architecture hétérogène. Avec une architecture multicloud typique utilisant deux
clouds publics ou plus ainsi que plusieurs clouds privés, un environnement multicloud vise
à éliminer la dépendance vis-à-vis d’un seul fournisseur de cloud et de tirer d’avantage
profit des avantages de chacun.
Selon une récente étude faite en 2018 par RIGHT SCALE, plus de 81% des entreprises
ont une stratégie multicloud au sein de leur infrastructure cloud. La figure 14 illustre celà.
Figure 14 – Statistiques sur l’utilisation des stratégies multicloud par les entreprises en
2018
3.1 Les avantages du Multicloud

Le premier avantage du multicloud est de ne pas dépendre d’un seul fournisseur cloud,
qui est l’idée même derrière ce concept. Puis, avoir une plateforme multicloud permet aux
26
Chapiter 3 : Le Multicloud
clients d’avoir plus de choix et plus de flexibilités en termes de services. Ci-dessous une
liste non exhaustive des avantages recensés auprès des clients :
• Réduction du risque de verrouillage (lock-in) avec un fournisseur donné.
• Utilisation de l’environnement le plus adapté en fonction des critères fonctionnels

et de services (SLA) demandés
• Réduction des Opex pour un service donné en permettant la sélection de l’option la

plus rentable, avant de déployer une charge de travail.
• Capacité à satisfaire les exigences en matière de localisation des données et de confor-

mité (en particulier avec la GDPR) grâce aux activités d’enregistrement (traçabilité
des données) et à un catalogue de services plus large.
• Pouvoir sélectionner et combiner des services de niveau supérieur (par exemple,

Machine Learning-as-a-Service, IoT-as a-Service, etc.) dans une approche « best of
breed ».
• Capacité à comparer les coûts de fonctionnement des services informatiques internes

et les services externes du cloud.
• Réduction du TTM (Time To Market) : provisioning des services au plus proche de

son lieu de consommation.
3.2 Les challenges du multicloud

Au-delà des avantages multiples des infrastructures multicloud, celles-ci sont sujette à
plusieurs problèmes, en plus des problèmes des infrastructures cloud classiques. Elles
s’avèrent être plus complexes et présentent plus de vulnérabilités dont les plus importantes
sont :
• Complexité liée à la gestion de plus de fournisseurs
• Manque de compétences dans des domaines spécifiques et surtout dans la gestion

des Cloud
• Coût d’intégration possible lié au développement de logiciels personnalisés
• Risque de sécurité lié au transfert de données cross-cloud (pour les scénarios dyna-
miques uniquement)
• Complexité liée à la gestion de l’ensemble de l’infrastructure.
• Garantir un même niveau de sécurité sur tous les clouds.
• Latence du réseau et / ou bande passante en particulier dans les scénarios dyna-

miques.
27
Comme nous pouvons le constater, en plus de la complexité, la sécurité est un problème

majeur auquel les équipes IT sont confrontées au quotidien. Dans ce qui suit, nous pré-
sentons dans un premier temps les principaux défis que doivent relever les équipes IT.
Puis, dans un second temps, et c’est la partie la plus consistante de notre étude, nous
présentons les différents moyens mis en œuvre par les fournisseurs cloud public afin de
répondre aux exigences de sécurité de leurs clients et nous terminons cette partie avec un
tableau synthétique comparant les principaux fournisseurs.
3.2.1 La sécurité du multicloud

La meilleure approche pour assurer le bon déploiement et la sécurité des applications dans
les environnements multicloud est de faire en sorte que toutes les ressources d’hébergement
soient unifiées et se comportent de la même manière. Chaque fournisseur de cloud ainsi
que le cloud privé des entreprises disposent de cadres d’hébergement indépendants qui
doit être sécurisé en plus du flux de travail qui représente une partie importante dans ce
défi de sécurité.
Les technologies de sécurité multi-cloud doivent répondre à quatre types de sécurité :
1. Ils doivent fournir une sécurité d’accès pour les applications et les composants hé-
bergés dans n’importe quel cloud public, quel que soit le cloud utilisé et le nombre
d’applications déplacées ou diffusées parmi les fournisseurs de cloud public.
2. Les outils de sécurité doivent fournir une sécurité de l’information pour les données
de l’entreprise hébergées ou connectées à chaque fournisseur pour assurer la sécurité
de l’ensemble de l’infrastructure multi-cloud.
3. Ils doivent maintenir la sécurité que ça soit lors d’une défaillance ou d’une montée
en charge (mise à l’échelle).
4. Les technologies de sécurité doivent s’adapter aux nouveaux fournisseurs de services

et aux nouvelles fonctionnalités.
3.2.1.1 SLA : Service-Level Agreement
Afin de garantir aux clients certains niveaux de sécurité dans le stockage et la gestion des
données à caractère personnel. Il faut définir de façon très précise différents indicateurs
de qualité pouvant être mesurés, analysés et contrôlés régulièrement. Il convient enfin de
prévoir des sanctions qui seront appliquées si le prestataire ne répond pas à ses obligations
mentionnées dans le SLA.
Dans le Cloud, les SLAs peuvent être exprimés entre différentes couches contractualisant
de fait des dépendances de ressources entre les différentes couches XaaS et faisant émerger
les différents protagonistes des contrats.
SLA pour Service-Level Agreement est un contrat passé entre un fournisseur de service et
ses clients internes ou externes. Ce contrat documente les services que le fournisseur met
à disposition et des paramètres comme leurs disponibilités ou les temps de réponse.
Les SLA mesurent les performances et la qualité du fournisseur de services de différentes
manières. Ainsi, un SLA peut spécifier les éléments de mesure ou indicateurs suivants :
28
• Disponibilité : représentée par le pourcentage de temps durant lequel les services

sont disponibles
• Nombre d’utilisateurs pouvant être pris en charge simultanément
• Banc d’essai de performances spécifiques à l’aune desquels sont mesurés périodique-

ment les performances réelles
• Temps de réponse des applications
• Calendrier des notifications préalables à des modifications du réseau susceptible

d’affecter les utilisateurs
• Délai de réponse du service d’assistance pour différentes catégories de problèmes
• Statistiques d’utilisation des mises à disposition
Parallèlement à la mise en place de mesures de performances, un SLA peut inclure un

plan de gestion des interruptions de service et des clauses portant sur le dédommagement
des clients par le fournisseur de service en cas de rupture de contrat.
Une fois entrés en vigueur, les SLA doivent être périodiquement révisés et mis à jour pour
refléter les changements au niveau des technologies et l’incidence d’éventuelles nouvelles
réglementations.
3.3 Les fournisseurs de cloud publics

La sécurité est la priorité de tous les fournisseurs cloud, AWS, Azure, Google et IBM ont
en fait leur priorité numéro un à travers différentes solutions. C’est la raison pour laquelle
Les fournisseurs mettent en place un centre de données et une architecture réseau conçus
pour répondre aux exigences des organisations les plus pointilleuses en termes de sécurité.
Les différents fournisseurs cloud se partagent les parts du marché, avec AWS en tête de
liste suivi par Azure,figure 15. Dans ce qui suis nous nous limitons à une comparaison
des services de sécurité que nous présentons brièvement des trois géants : AWS, Azure et
Google.
3.3.1 Comparaison entre les services de sécurité des fournisseurs

Cloud
Afin de répondre aux exigences des clients, les fournisseurs cloud proposent des solutions
diverses et complémentaires pour accompagner le client et l’aider dans sa démarche de
sécurité. Les autres services (calcul et stockage) étant pas notre principal centre d’intérêt,
nous nous limitons à une comparaison des services de sécurité proposés par chaque four-
nisseur. Dans un premier temps, nous allons lister les principales solutions présentes sur le
marché, puis dans un second temps, nous allons établir un tableau comparatif soulignant
les principales différences entre les différents fournisseurs de cloud public.
29
Figure 15 – Les parts de marché des différents fournisseurs de cloud public
3.3.1.1 AD as a service
L’objectif principal de l’AD est de fournir des services centralisés d’identification et d’au-
thentification à un réseau d’ordinateurs utilisant le système Windows. Il répertorie les
éléments d’un réseau administré tels que les comptes utilisateurs, les serveurs, les postes
de travail, les dossiers partagés et les imprimantes.
Cela permet aux utilisateurs de retrouver facilement les ressources partagées, et les admi-
nistrateurs peuvent contrôler leur utilisation grâce à des fonctionnalités de distribution, de
duplication, de partitionnement et de sécurisation de l’accès aux ressources répertoriées.
3.3.1.2 Certificate Manager
Le certificate Manager est un service qui permet de mettre en service, de gérer et de dé-
ployer facilement des certifications Secure Sockets Layer/Transport Layer Security (SSL/TLS)
afin de les utiliser avec les services et les ressources internes connectées.
Les certificats SSL/TLS sont utilisés pour sécuriser les communications réseau et pour
établir l’identité des sites Web par Internet ainsi que celle des ressources présentes sur des
réseaux privés.
Posséder un Certificate Manager évite le processus manuel d’achat et de changement et
de renouvellement de certificats en le rend plus facile et moins coûteux.
3.3.1.3 Dedicated HSM
HSM (Hardware Security Module) est un module de sécurité matérielle qui permet de
générer et d’utiliser facilement vos propres clés de chiffrement sur le cloud. Il permet de
gérer les clés de chiffrement à l’aide des HSM validés. Les solutions HSM apportent, grâce
aux API (les bibliothèques PKCS#11, Java Cryptography Extensions JCE, et Microsoft
CryptoNG), la flexibilité nécessaire pour s’intégrer aux applications.
30
3.3.1.4 IAM
La sécurité dans tout système consiste principalement à s’assurer que les données sont
uniquement accessibles à qui de droit dans le format, l’endroit et à l’instant autorisé.
La gestion des identités et des accès, abrégée en IAM pour Identity Access Management
en anglais, désigne le processus interne d’une entreprise permettant d’administrer et de
gérer les comptes utilisateurs et les ressources du réseau de l’entreprise, y compris les
droits d’accès des utilisateurs aux applications et aux systèmes.
L’IAM comporte principalement l’authentification des utilisateurs sur le réseau ainsi que
la traçabilité des droits d’accès (Autorisations).
3.3.1.5 Key Storage Management
C’est un service géré qui permet de créer et contrôler facilement les clés de chiffrement
utilisées pour chiffrer les données. C’est un service offert par les
3.3.1.6 Security assessment
C’est un service d’évaluation de la sécurité automatisé qui permet de renforcer la sécurité

et la conformité des applications déployées sur le cloud. Il évalue automatiquement les ap-
plications afin de détecter les éventuelles vulnérabilités ainsi que les écarts par rapport aux
bonnes pratiques. Après avoir effectué une évaluation, une liste détaillée de constatations
en matière de priorité, classées par niveau de gravité est établie.
3.3.1.7 Threat detection and monitoring
Intégré par les fournisseurs cloud Amazon, Azure et Google, Threat Detection and mo-
nitoring est un service de détection intelligente des menaces, qui surveille en continu
les comportements malveillants ou non autorisés pour la protection des comptes et des
charges de travail.
3.3.1.8 Web Firewall
Le Web Firewall est un système de sécurité qui contrôle le trafic entrant et sortant des
applications et sites Web hébergés dans le Cloud public. Il protège ces applications et
sites des attaques Web courantes susceptibles d’avoir une incidence négative sur leurs
performances et leur disponibilité.
3.3.1.9 ACL et groupes de sécurité
Comme déjà mentionné dans le chapitre précédent, les listes de contrôle d’accès réseau
font office de pare-feu pour les sous-réseaux associés en contrôlant le trafic entrant et
sortant au niveau du sous-réseau. Les groupes de sécurité compte à eux font office de
pare-feu pour les instances, en contrôlant le trafic entrant et le trafic sortant au niveau
de l’instance.
31
Figure 16 – Comparatif des services de sécurité des providers cloud ( AWS, Azure, GCP
& IBM Cloud
32
Chapitre 4
DEVOLAB
4.1 Presentation of DEVOLAB

Devoteam dans le cadre de son entité DTC (Devoteam Technology Consulting) s’est
doté d’une architecture technique hébergée dans un datacenter parisien pérenne (Equinix)
permettant :
• La mise en place de véritable PoC (pour toutes les entités du groupe) pour tester
des outils, des OS, des distributions, des hyperviseurs et toutes solutions techniques
arrivant sur le marché.
• De mettre en place des plateformes de formation et de reskilling avec la possibilité

de d’opérer réellement.
• De permettre à nos clients de tester les outils que nous leur recommandons
• D’héberger des event, des hackathon.
• De servir de plateforme technique à la DRI pour ses laboratoires d’innovation, voir

figure 17.
Figure 17 – Cas d’usage de la plateforme Devolab
33
Chapiter 4 : DEVOLAB
Figure 18 – Architecture globale Devolab
4.2 Architecture de DEVOLAB

La plateforme se compose d’un rack hébergé à EQUINIX sur PA2 avec des composants
réseau :
• Switch/Routeur, Firewall
• Des Serveurs
• Des Accès dédiés aux cloud public : AWS, Azure et GCP
• Un AS et un range d’IP associé possédés par Devoteam
4.2.1 Cas d’usage de Devolab : Dans les universités

Dans les environnements de forte utilisation des systèmes informatiques, il est utile de
disposer de l’infrastructure en privé. Les machines virtuelles du service IaaS sont octroyées
dynamiquement aux étudiants pour accomplir les tâches d’expérimentation en réseau
informatique.
Le but est de mettre en oeuvre de façon rapide des logiciels didactiques utilisés pour les
étudiants 20. En embarquant ces derniers dans des machines virtuelles et en les attribuant
aux étudiants suivant un mode de réservation ou de demande de la part de ces derniers.
4.3 Sécuriser DEVOLAB

La sécurité de la plateforme comporte plusieurs axes, pour notre cas d’étude nous nous
limitons à la sécurité de la partie hébergée chez les fournisseurs cloud publique. Il est
34
Figure 19 – Architecture niveau 2 Devolab
Figure 20 – Exemple d’utilisation de DEVOLAB dans les universités
important de mettre en place les souscriptions auprès des trois grands providers de Cloud
Public et d’assurer le management centralisé dans un outils CMP (Cloud Management
Platform).
Devolab sera déployée au travers de Terraform, dont l’une des forces est de centraliser tous
ces providers dans un outil unique, et surtout, d’en décrire leur configuration seulement.
Le descripteur de ressources utilise le Hashicorp Configuration Language (Syntaxe utilisée
par Terraform), permettant de profiter des spécificités de chaque provider, même s’ils
proposent le même type de service. Dans ce qui suit nous présentons l’outil Terraform
utilisé ainsi qu’un exemple de déploiement d’une plateforme multicloud (AWS et Google).
35
4.3.1 Terraform
Terraform est un outil open source d’infrastructure as code, il permet la définition d’une
architecture aussi hétérogène que possible ainsi faire cohabiter des instances de différents
fournisseurs cloud(Amazone EC2 et Google Cloud Engine par exemple).
Il permet de décrire, dans une syntaxe unique, basée sur un formalisme JSON légèrement
simplifié pour une meilleure lisibilité, de l’infrastructure à provisionner chez différents
fournisseurs.
Terraform enregistre les plans d’exécution sous forme de fichier, afin de pouvoir les relire
et de les vérifier.
4.3.1.1 Infrastructure as a code IAC
L’infrastructure As a Code est un type d’infrastructure IT que les équipes opérationnelles

peuvent administrer et mettre à disposition automatiquement, via du code, plutôt qu’en
recourant à un traitement manuel.
Elle réfère à la méthode en rapide expansion consistant à utiliser des scripts pour configu-
rer une infrastructure informatique au lieu de la configurer manuellement. L’infrastructure
autant que code(IaC) appelée aussi Infrastructure programmable, elle commence par es-
tomper les
Parfois appelée "infrastructure programmable," l’infrastructure en tant que code (IaC)
aborde la configuration d’infrastructure exactement de la même manière que la program-
mation de logiciel. En effet, elle commence par estomper les limites entre la rédaction
d’applications et la création des environnements où celles-ci sont exécutées. Les applica-
tions peuvent contenir des scripts qui créent et orchestrent leur propres machines virtuelles
(VM). C’est une partie fondamentale du cloud computing et essentielle aux DevOps.
4.3.2 Construction d’une plateforme Multicloud

Dans chaque cloud, il faut préparer une zone réseau, procéder à une connexion VPN pour
permettre la communication directe, et s’assurer que le routage est effectif entre les deux
zones. Un bastion qui servira de point d’entrée est créé au sein de chaque fournisseur de
cloud.
Etapes de création de l’architecture, voir figure 21 :
1. Créer un VPC au sein de chaque cloud
2. Il faut interconnecter les deux clouds, chose dépendante du fournisseur d’accès,

pour aws : déclarer une passerelle VPN AWS, une passerelle AWS cliente (GCP
pour nous), et la connexion entre les deux, pour GCP : déclarer l’IP d’entrée, les
règles de pare-feux, et créer enfin les deux tunnels VPN avec AWS via IPSec.
3. Lancer terraform
4. Créer les points d’entrée d’administration dans chaque VPC, ainsi que les points de
sortie pour les machines virtuelles qui seront hébergées.
36
5. Configurer les composants de routages afin de permettre la connexion entre les deux
VPC.
Figure 21 – Infrastructure multicloud (AWS et GCP)
4.3.2.1 Découverte de service et répartition de charge
Le but est de permettre aux applications de se découvrir mutuellement dans les deux
cloud. Deux outils sont utilisés au sein de chaque fournisseur :
• Consul : permet de découvrir les services déployé en interne de chaque fournisseur,

il faut les relier entre eux pour assurer la découverte mutuelle et de déterminer où
sont les services.
• Træfik : Modern HTTP reverse proxy and load balancer. It’s made to deploy
microservices and supports several backends (Docker, Swarm mode, Kubernetes,
Marathon, Consul, Etcd, Rancher, Amazon ECS, and a lot more) to manage its
configuration automatically and dynamically.
Il faut indiquer à Traefik de se connecter à un Consul local pour retrouver la liste des
backend et des frontend à configurer. Pour assurer une haute disponibilité, on peut choisir
de déployer deux instances de Traefic au sein de chaque fournisseur.
4.3.2.2 Stockage et réplication des données en mode Multicloud
Un des éléments les plus importants à prendre en compte lors de la construction d’un
stockage répliqué est de prendre en compte l’état du réseau reliant les différents cloud.
Pour ce faire, des tests de latence et de débits sont effectués et permettent d’orienter le
choix d’une solution de stockage.
37
4.3.2.3 Réplication synchrone et asynchrone
L’objectif est de s’assurer d’une disponibilité maximale même en perdant un des fournis-
seurs cloud, c’est pour ça qu’il est très important de bien choisir le stockage et la conception
des applications. Aussi, il faut prendre en compte la particularité de l’infrastructure pour
garantir une compatibilité multicloud.
Il existe deux types de réplications du stockage des données :
1. Réplication Synchrone : chaque nœud de stockage doit acquiescer les écritures

avant que la transaction soit réellement réalisée. Ce mode permet de garantir la
cohérence du stockage et une bascule vers n’importe quel nœud du stockage, s’ils
ne sont pas déjà tous actifs. Néanmoins, ce type de réplication a des contraintes
importantes notamment quant aux performances réseaux et disques.
2. Réplication Asynchrone : permet un peu plus de souplesse car les données sont
d’abord écrites localement au nœud de stockage, et sont ensuite répliquées plus tard
suivant une politique définie. Cette politique peut être de type streaming, ce qui
implique une réplication au fur et à mesure, ou de type batch, ce qui signifie que les
données seront envoyées selon un intervalle.
La réplication du stockage conditionnée par l’état du réseau, ce point est critique dans les
infrastructures multicloud par le simple fait que les deux cloud peuvent être potentielle-
ment déployés dans deux continents différents (Distants, plusieurs routeurs entre les deux
ce qui rend la latence peut devenir importante).
Cela impacte surtout les réplications synchrones, puisque les écritures ne sont validées
que si tous les nœuds acquissent, donc c’est la latence du cluster est importante ou/et la
quantité des données (le débit maximal) à écrire est importante, ça peut engendrer des
temps de latences trop importants..
4.3.3 La sécurisation de la plateforme

• Il est important de relier les deux clouds à l’aide d’un lien VPN contenant deux
tunnels. Ce choix protège contre la perte d’un tunnel.
• Mise en place des ACL et des groupes de sécurité
• Appliquer les critères de sécurité ainsi que les bonnes pratiques au sein de chaque
cloud
• Etablissement des connexions sécurisées, les clients seront connectés au portail VPN
SSL du fortinet.
• la sécurité de l’infrastructure physique
• La sécurisation des flux de données à travers l’établissement de connexions sécurisées
(VPN)
• La sécurisation des données dans le cloud à travers les différents mécanismes men-
tionnés dans le chapitre précédent
• Etablissement de SLA avec les différents fournisseurs
38
Sytnthèse et Conclusion
Synthèse et Conclusion
Ce stage au sein de l’équipe Cloud Architecture de Devoteam, m’a permis de découvrir le
vaste univers qu’est le Coud. Il m’a également donné l’opportunité d’effleurer le domaine
de la sécurité en général et celle des infrastructures cloud plus précisément. J’ai eu l’oc-
casion de mettre à profit mes compétences acquises lors de mon parcours scolaire via les
tâches de recherche et d’intégration qui m’ont été confiées, lesquelles ont participé à la
mise en place de l’architecture de Devolab ainsi qu’à sa sécurisation.
Il est évident que le déploiement de plusieurs plateformes Cloud offre plus de marge de
manœuvre et de choix. Mais, pour les responsables IT, cette gestion multicloud reste un
point épineux. L’utilisation des services d’infrastructure Cloud requiert donc la mise en
oeuvre de mesures et contrôles de sécurité par leurs utilisateurs.
Les problèmes de sécurité relatifs à cette avancée ne sont pas pris à la légère, la sécurité
du Cloud tout comme celle de tout projet de digitalisation doit passer par une analyse
détaillée des risques et des éventuelles vulnérabilités auxquelles le système pourrait faire
face dans l’optique d’avoir une bonne visibilité et une maitrise absolue de son infrastruc-
ture et des données de son SI. Les entreprises doivent adapter leur politique de sécurité
à ces nouvelles technologies pour profiter de leur puissance sans augmenter leur surface
d’exposition aux cyberattaques.
Ce présent rapport englobe mes différentes participations au travers de mes missions
effectuées au cours de ma période de stage, dont la plus significative est la sécurisation
de la plateforme Devolab. Dans un premier temps, j’ai présenté l’entreprise d’accueil, le
milieu d’évolution et d’échange et exposé les motifs de choix et les valeurs de l’entreprise.
Ensuite, j’ai défini le contexte du stage ainsi que l’enjeu principal qu’est la sécurité du
multicloud. Un volet important a été dédié au cloud et à sa sécurité étant notre cœur
du sujet. La dernière partie est une illustration d’un cas pratique « Devolab » où il est
question de sécuriser la partie multicloud en mettant en application les bonnes pratiques
et les mécanismes de sécurité évoqués au préalable.
Ma participation aux projets Devolab m’a permis de prendre conscience des enjeux ma-
jeurs de la sécurité et de réaliser la complexité de sa mise en place dans les environnements
cloud. De plus cette première expérience dans une ESN, outre le fait d’avoir consolidé mes
connaissances, a renforcé mon envie d’évoluer vers un milieu à la fois technique et fonc-
tionnel. En effet, le quotidien spécifique des cabinets de conseil fait que l’effervescence
permanente des actions cariées nécessite le développement d’un large panel de compé-
tences. Au cours de ce stage, j’ai pu consolider mes compétences en les mettant en pra-
tique. Et je pourrai par la suite améliorer ces connaissances et compétences en participant
aux prochaines missions aux côtés de Devoteam en tant que Consultante Cloud Security
junior.
39
Références
Références
- Cloud Computing Top Threats in 2016 The Treacherous 12. Cloud Security Alliance,
(February), 1–35.
- Sécurité dans le Cloud AWS. Disponible sur https ://aws.amazon.com/fr/security/.
Consultée le 11/06/2017.
- Divya, S. (2017). Homomorphic Encryption : Working and Analytical Assessment.
Master’s thesis, Faculty of Computing Blekinge Institute of Technology SE-371 79
Karlskrona Sweden.
- RightScale 2016 Cloud Report. Disponible sur https ://www.rightscale.com/lp/state-
of-the-cloud. Consultée le 17/12/2016.
- Hussein, N. H., Khalid, A. (2016). A survey of cloud computing security challenges
and solutions. International Journal of Computer Science and Information Security,
14(1), 52–56.
- Kalpana, G., Kumar, P. V, Krishnaiah, R. V. (2015). A brief Survey on Security
Issues in Cloud and its service models,
- Kaur, R. (2015). Cloud Computing Security Issues and its Solution : IEEE, 0–2.
- Jia, W., Sun, S. (2013). Research on the security issues of cloud computing. Ad-
vances in Intelligent Systems and Computing, 180 AISC, 845–848.
- Samarati, P. (2014). Data security and privacy in the cloud. In Information Security
Practice and Experience (pp. 28–41). Springer.
- Mell, P., Grance, T., Grance, T. (2011). The NIST Definition of Cloud Computing
Recommendations of the National Institute of Standards and Technology.
- https ://news.digicomp.ch/fr/2017/08/30/la-gouvernance-dans-le-cloud/
- https ://blog.wescale.fr/2017/07/31/saga-de-lete-e01-construction-dune-infrastructure-
multi-cloud/
- https ://blog.wescale.fr/2017/10/16/saga-multi-cloud-e04-stockage-et-replication-des-
donnees-en-mode-multi-cloud/
- https ://www.terraform.io/
- https ://www.journaldunet.com/solutions/expert/64500/iam–dag–pam—des-outils-
indispensables-pour-une-bonne-securite-informatique.shtml
- https ://www.computerweekly.com/tip/Identity-and-access-management-IAM-in-the-
cloud-Challenges-galore
- https ://www.clusir-rha.fr/public/fichiers/presentation/2016-2017/20170225-gestion-
et-gouvernance-des-identites-et-des-acces-guide-pratique-mise-en-
- https ://searchcloudcomputing.techtarget.com/feature/How-to-get-started-with-IAM-
services-in-the-cloud
- https ://perso.liris.cnrs.fr/sara.bouchenak/publications/ComPAS-MyCloud-2013.pdf
40

Rapport de Stage - VF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Rapport de Stage - VF

Загружено:

Авторское право:

Доступные форматы

Master 2, Advanced Communication Networks

Rapport de stage : Sécurisation d’une plateforme multicloud

Réalisé par : Katia Si Hamdi

 Tuteur pédagogique : Pascal Urien

Année Universitaire : 2017/2018

Ce document contient des informations confidentielles qui sont la propriété de la société

En premier lieu, je tiens à témoigner ma profonde gratitude et mes remerciements les

Keywords: Cloud, Multicloud, Security.

1 Organisme d’accueil : Devoteam 2

2 Généralités sur le cloud 8

2.7.2 La gestion des identités et des accès . . . . . . . . . . . . . . . . . 16

1 Les axes de développement de Devoteam . . . . . . . . . . . . . . . . . . . 3

6 Les modèles de déploiement du cloud . . . . . . . . . . . . . . . . . . . . . 9

14 Statistiques sur l’utilisation des stratégies multicloud par les entreprises en

17 Cas d’usage de la plateforme Devolab . . . . . . . . . . . . . . . . . . . . . 33

Comme les infrastructures traditionnelles, l’utilisation des services d’infrastructure Cloud

Organisme d’accueil : Devoteam

1.1 Présentation de l’entreprise Devoteam

• Favoriser la construction d’infrastructures informatiques globales grâce à l’intercon-

• Transformer les services informatiques en outils agiles orientés services répondant

• Repenser les processus pour optimiser l’efficacité opérationnelle tout en développant

Depuis 2005 Devoteam a diversifié son secteur d’activité en s’attaquant à la transforma-

Figure 1 – Les axes de développement de Devoteam

1.2 Domaines d’activité et clients

Figure 2 – Clients de Devoteam

1.3 Bilan financier et secteur d’activité

1. Agile IT : Transformer l’informatique de base en une plate-forme numérique orientée

Figure 3 – Secteurs d’activité Devoteam

2. Transformation management : Soutenir les projets de transformation globale et

1.4 Organisation de Devoteam

Figure 4 – Répartition par branche des actions de R&D

Figure 5 – Organisation de Devoteam Technology Consulting

Un Carrière Manager (CM) qui a pour objectif de gérer la carrière du consultant en

• Un Delivery Responsible Manager (DRM) qui s’occupe du bon déroulement des

La proximité du management permet de réagir rapidement si le consultant rencontre un

1.5 Offer Unit Risk Security

• Évaluation de la maturité cyber sécurité et résiliences aux risques : Soutenir les

• Évaluation et soutient dans la mise en place de projet numérique : Identifier et

• Conformité et réglementation : Atteindre le niveau de conformité souhaité pour les

• Protection des infrastructures critiques : Établir et maintenir une gouvernance de

• Trust Governance Framework (GRC) : Mettre en œuvre un cadre de gouvernance,

• Cybersécurité cyberassurance : Assurer la résilience aux risques résiduels inaccep-

Généralités sur le cloud

2.1 Définition du cloud

2.2 Les caractéristiques du Cloud

1. Libre-service à la demande : La capacité de stockage et la puissance de calcul

2.3 Les modèles de déploiement

Figure 6 – Les modèles de déploiement du cloud

2.3.1 Le Cloud privé

2.3.2 Le cloud communautaire

2.3.3 Le cloud public

2.3.4 Le cloud hybride

2.4 Les modèles de services

Figure 7 – Les modèles de service du cloud

2.4.1 SaaS (Software as a service)

2.4.2 PaaS (Platform as a Service)

2.4.3 IaaS (Infrastructure as a Service)

2.4.4 Autre modèle de service

2.5 La responsabilité partagée dans le cloud

2.5.1 La trus boundary

Figure 8 – La trust boundary

La responsabilité de la sécurité dans le cloud est toujours partagée. Le graphique suivant

Figure 9 – La trust boundary