Chapitre 3: Modèles de

Déploiement et Services Cloud

Matière: Introduction au Cloud Computing

Enseignante: Nourhene Ellouze

Niveau: GLSI3 et IoT3

Plan
1. Modèles de Déploiement Cloud
▪ Cloud public
▪ Cloud privé
▪ Cloud communautaire
▪ Cloud Hybride
2. Modèles de Service Cloud
▪ Software as a Service
▪ Platform as a Service
▪ Infrastructure as a Service
▪ Autres modèles de service
3. Prendre la décision
▪ Choix de migrer vers le cloud ou pas
▪ Choix du modèle de service cloud
▪ Choix du modèle de déploiement cloud
▪ Choix du fournisseur de services de cloud public
2
1. Modèles de Déploiement
Cloud
▪ Cloud public
▪ Cloud privé
▪ Cloud communautaire
▪ Cloud Hybride

3
Introduction
▪ National Institute of Standard and Technology (NIST) définit quatre modèles de
déploiement cloud:
▪ Cloud public
▪ Cloud privé,
▪ Cloud communautaires, et
▪ Cloud hybride.

▪ Un modèle de déploiement cloud est défini en fonction de l'emplacement de

l'infrastructure pour le déploiement et de la personne qui contrôle cette
infrastructure.
4
Introduction
▪ Le choix du modèle de déploiement à utiliser est l'une des décisions de
déploiement cloud les plus importantes à prendre.
▪ Chaque modèle de déploiement cloud
▪ répond à différents besoins organisationnels,
▪ a une proposition de valeur différente, et
▪ a des coûts différents associés.
▪ Le choix d’un modèle qui répondra aux besoins de l’organisation.
▪ Dans de nombreux cas, le choix d'un modèle de déploiement cloud peut
simplement se résumer à une question d'argent.
▪ Pour pouvoir prendre une décision éclairée, il faut être conscient des
caractéristiques de chaque environnement.
5
1.1. Cloud Public: Présentation
▪ Les cloud publics sont des environnements entièrement gérés et entretenus
par un fournisseur de services externe.
▪ Lorsque la plupart des gens pensent aux cloud, ce sont les cloud publics
auxquels ils pensent.
▪ La plupart des articles et du matériel que vous trouvez concernant les cloud font en fait
référence aux cloud publics.
▪ Les premiers environnements cloud étaient des cloud publics.
▪ Les autres modèles de déploiements cloud ont mis un peu de temps à se développer.

▪ Les cloud publics sont toujours les environnements cloud les plus déployés.
6
1.1. Cloud Public: Avantages
▪ Le nombre d'implémentations de cloud public continue de croître à un rythme
rapide en raison des nombreux avantages qu'offrent les cloud publics.
▪ La proposition de valeur pour une offre publique est très forte, même si elle
présente certains inconvénients.
▪ Les avantages:
▪ Disponibilité
▪ Évolutivité (Scalability)
▪ Accessibilité
▪ Réduction des coûts
7
Disponibilité
▪ Les déploiements de cloud public peuvent offrir une disponibilité accrue par
rapport à ce qui est réalisable en interne.
▪ Chaque organisation a:
▪ un quotient de disponibilité qu'elle souhaite atteindre
▪ un quotient de disponibilité qu'elle est capable d'atteindre
▪ Parfois, les deux correspondent, parfois non.
▪ Le problème est que la disponibilité a un coût (coût du matériel, du logiciel, de la
formation ou du personnel).
▪ Une organisation peut ne pas être en mesure de se le permettre
→Elle doit donc se contenter de ce qu'elle a
→Elle n’est pas en mesure d'atteindre le niveau de disponibilité qu'elle souhaite
8
Disponibilité
▪ La plupart des fournisseurs de cloud public
▪ disposent du matériel, des logiciels et du personnel nécessaires pour rendre leurs offres
hautement disponibles.
▪ peuvent facturer un peu plus pour le service afin de fournir une disponibilité accrue,
mais ce sera loin du coût de le faire en interne.
▪ Noté que:
▪ Optez pour un fournisseur de cloud public ne signifie pas obligatoirement que vous
bénéficiez d’une haute disponibilité ou une tolérance aux pannes.
▪ Il faut demander au fournisseur ce qui est offert avec le service
▪ Si une disponibilité accrue est un complément, vous devez le savoir lorsque vous calculez le coût.
▪ Il faut également s’assurer que la disponibilité souhaitée fait partie du contrat de niveau
de service (SLA).
▪ Votre SLA peut donner un niveau d'assurance que vos besoins de disponibilité seront satisfaits.
9
Disponibilité
▪ Bien que les cloud publics puissent augmenter votre disponibilité, vous devez
vous assurer que vous connaissez ce qui sera disponible.

▪ Cela dépend de l'offre de service:

▪ Dans une offre SaaS, l'application elle-même sera disponible.

▪ Pour une offre PaaS ou IaaS, bien que la plate-forme ou l'infrastructure soient
disponibles, l'application peut ne pas l'être. Les problèmes d'application ne seront pas
atténués par l'utilisation d'une offre publique IaaS ou PaaS.

10
Évolutivité (Scalability)
▪ Les implémentations de cloud public offrent une architecture hautement évolutive.
▪ Ce que les implémentations de cloud public offrent que les cloud privés n'offrent
pas, c'est la possibilité de faire évoluer la capacité de votre organisation sans avoir à
créer votre propre infrastructure.
▪ Les implémentations de cloud public peuvent offrir une capacité de rafale
temporaire ou une capacité permanente, selon les besoins de votre organisation.
▪ Si votre organisation utilise un service SaaS, vous pouvez ajouter des utilisateurs à
l'application sans ajouter l'infrastructure associée.
▪ Si vous utilisez un service IaaS ou PaaS, vous aurez une capacité accrue pour créer des
applications et des services, mais vous devrez toujours vous assurer que l'application que
vous avez créée peut gérer la charge accrue. 11
Accessibilité
▪ Une grande importance est accordé à l'accessibilité dans le cloud public
▪ Pour élargir leur clientèle potentielle, les fournisseurs essaient de s'assurer qu'ils
peuvent desservir autant de types de clients différents que possible.
▪ Leur objectif est de s'assurer que leurs services sont accessibles par n'importe quel
appareil sur Internet sans avoir besoin de VPN ou de logiciel client spécial.
▪ De nos jours, l’accès à Internet et aux applications basées sur Internet se fait
via les nouveaux navigateurs Web en utilisant les tablettes et les smartphones.
▪ L’utilisation de simples navigateurs traditionnels sur des ordinateurs portables et des
ordinateurs de bureau traditionnels est de plus en plus réduite
▪ Les navigateurs web des nouveaux appareils ne sont pas complets.
▪ Pour prendre en charge ces appareils, les pages Web et les applications Web doivent être
simplifiées et doivent adhérer à des normes de développement interopérables.
12
Accessibilité
▪ Prendre en charge plusieurs systèmes d'exploitation et plusieurs navigateurs
Web pourra être très coûteux.
▪ Les coûts de développement et d'assurance qualité (AQ) peuvent être
extrêmement élevés.
▪ Même si de nombreuses organisations souhaitent fournir ce type de support
aux utilisateurs, le coût peut être prohibitif.
▪ Étant donné que les fournisseurs de services se concentrent davantage sur
l'offre d'un seul ensemble de services, ils sont plus disposés à accepter ces
coûts.

13
Réduction des coûts
▪ Les cloud publics sont attractifs en raison des économies de coûts qu'ils offrent.
▪ Il faut être prudent. Il faut avoir une bonne compréhension non seulement du montant
des économies, mais également du type d'économies.
▪ Les cloud publics offrent le plus d'économies en termes de coûts initiaux.
▪ Les entreprises n'ont pas à se soucier de dépenser de l'argent pour les déploiements
matériels et logiciels initiaux. Le fournisseur de services paie ces coûts.
▪ Le client n'a à payer que les services utilisés. La plupart de ces coûts initiaux seraient des
coûts en capital en raison du matériel à acheter.
▪ Des économies de support, de maintenance, et d’environnement seraient
réalisées
▪ Économie d'espace, d’électricité et des coûts de refroidissement.
▪ Ce sont le coût des économies qui poussent réellement les entreprises vers le
cloud. 14
1.1. Cloud Public: Inconvénients
▪ Les implémentations de cloud public ont leurs limitations et inconvénients.
▪ Beaucoup de ces problèmes peuvent être attribués au fait que l'infrastructure
est en fait détenue et contrôlée par une autre organisation.
▪ Inconvénients
▪ Limitations d'intégration
▪ Flexibilité réduite
▪ Temps d'arrêt forcé

15
Limitations d'intégration
▪ Dans les cloud publics SaaS, les systèmes sont externes à votre organisation et
donc les données sont également externes
▪ Le fait que les données soient hébergées en externe peut entraîner des problèmes lors
de la création des rapports ou lors du passage à des systèmes sur site.

▪ S’il faut exécuter des rapports ou effectuer des analyses de Business Intelligence (BI) par
rapport aux données, il faut transmettre les données via Internet. Cela peut soulever des
problèmes de performances ainsi que des problèmes de sécurité.

▪ Les rapports s'affichent beaucoup plus rapidement lorsqu'ils sont générés au même
emplacement que les données.
16
Limitations d'intégration
▪ L'intégration d'applications est également un problème dans les offres SaaS
publiques.
▪ Différentes applications peuvent utiliser des fonctionnalités partagées.

▪ Pour ne pas répéter la fonctionnalité dans deux applications différentes, si la

fonctionnalité existe dans une application, l’autre application doit pouvoir l’appeler. Cela
peut être un problème dans les applications de cloud public.

▪ Le fournisseur d'applications doit exposer des API ou des services Web qu'un client peut
utiliser pour que cela se produise.

▪ Sinon, on risque de se retrouver dans une situation où la fonctionnalité se répète.

17
Flexibilité réduite
▪ Lors de l’utilisation d’un fournisseur de cloud public, on est soumis au
calendrier de mise à niveau de ce fournisseur.
▪ Dans la plupart des cas, vous aurez peu ou pas d'influence sur le moment où les mises à
niveau sont effectuées.

▪ Même s'il vous est possible d'exécuter une instance différente de celle d'autres clients,
de nombreux fournisseurs hésitent à déployer plusieurs versions d'une application ou
d'un système en ligne. Cela augmenterait leurs frais généraux administratifs.

▪ Les utilisateurs devront être formés au nouveau système, ce qui peut avoir un
impact sur la productivité.
18
Temps d'arrêt forcé
▪ Lors de l’utilisation d’un fournisseur de cloud public, le fournisseur contrôle le
moment où les systèmes sont mis hors ligne pour maintenance.
▪ La maintenance peut être effectuée à un moment qui n'est pas pratique pour vous et
votre organisation.

▪ En fonction de la manière dont le système est partitionné, vous pourrez peut-être

reporter la maintenance pendant une courte période et convenir d'une heure convenant
à la fois à votre organisation et au fournisseur.

▪ Cependant, il est hautement improbable que la maintenance puisse être reportée

pendant une longue période.
19
1.1. Cloud Public: Responsabilités
▪ Avec le cloud public, la plupart des responsabilités incombent au fournisseur de services.
▪ Le fournisseur est responsable de:
▪ la maintenance et du support.
▪ l’assurance que le personnel d'assistance est correctement formé.
▪ tous les composants nécessaires à la mise en œuvre du service. Ces composants varient en fonction du
service offert. Ils peuvent inclure des serveurs, du stockage, des applications et des données.
▪ développement de l'application côté client et offrir un soutien pour le faire fonctionner correctement.
▪ Le client est responsable de:
▪ tout ce qui est nécessaire pour consommer le service. Il existe quelques exceptions, telles que les
implémentations dans lesquelles une application côté client est impliquée.
▪ l'installation de l'application côté client et de son bon fonctionnement.
▪ s'assurer que les mises à jour et les correctifs nécessaires ont été installés sur les systèmes clients.
▪ fournir la connectivité réseau au fournisseur. Le fournisseur sera accessible au public, mais le client doit
s'assurer que les clients ont un itinéraire ou un chemin vers le fournisseur.
20
1.1. Cloud Public: Considérations relatives à la sécurité
▪ Assurer la sécurité est difficile dans les scénarios de cloud public.
▪ Étant donné que vous ne gérerez probablement pas l’accès aux systèmes fournissant les
services, il est très difficile de s’assurer qu’ils sont sécurisés.
▪ Il faut essentiellement faire confiance aux capacités du fournisseur
▪ Sécurité des Données:
▪ Les fournisseurs de cloud public soulèvent un réel problème de sécurité des données. Il y
a une question de propriété des données.
▪ Étant donné que le fournisseur de services possède les systèmes sur lesquels résident vos données, le
fournisseur pourrait potentiellement être considéré comme le véritable propriétaire des données.
▪ Il y a aussi un problème d'accès aux données.
▪ Théoriquement, toute personne travaillant chez le fournisseur de services pourrait potentiellement
avoir accès à vos données.
21
1.1. Cloud Public: Considérations relatives à la sécurité
▪ Conformité
▪ C’est une grande préoccupation pour les fournisseurs de services publics, puisque le
client n’a pas de visibilité sur ce qui se passe sur le back-end.
▪ Le fournisseur peut avoir un certificat SAS-70, mais sans pouvoir l'examiner par le client,
il faut juste être sûr que l'audit SAS a été suffisamment réalisé.
▪ Audit
▪ Dans le cas des fournisseurs de cloud public, les capacités d'audit fournies sont limitées.
▪ Le client ne peut pas accéder directement à des journaux ou à des systèmes de gestion
d'événements. Il ne serait probablement pas en mesure de mettre en œuvre ses propres
alertes ou journaux back-end. Il devra se satisfaire de ce que le fournisseur lui fournit.
▪ De nombreux fournisseurs de cloud public permettront aux client d'accéder à au moins
une forme de journaux d'application. Ces journaux peuvent être utilisés pour afficher
l'accès des utilisateurs et prendre des décisions concernant les licences.
22
1.2. Cloud Privé: Présentation
▪ Les cloud privés sont entièrement gérés et maintenus par l’organisation, elle-même
▪ Toute l'infrastructure de l'environnement sera hébergée dans un centre de données contrôlé par
l’organisation. L’organisation est responsable de l'achat, de la maintenance et du support.

▪ De nombreuses personnes ont une compréhension du cloud telle qu'elles ne croient

pas que les cloud privés sont en fait des cloud.
▪ Ils croient que seuls les cloud publics sont de vrais cloud. Mais, en regardant les caractéristiques
des cloud, on peut voir qu’il y a pas une exigence spécifiant où le cloud est hébergé.

▪ La proposition de valeur du cloud change lorsque on parle de cloud privés par opposition aux
cloud publics; mais la proposition de valeur ne détermine pas s'il s'agit d'un cloud ou non.

23
1.2. Cloud Privé: Avantages
▪ De nombreux avantages à opter pour un modèle de cloud privé.

▪ La plupart de ces avantages sont centrés sur la capacité de l’organisation à

surveiller et à contrôler ce qui se passe dans l'environnement cloud.

▪ Avantages:
▪ Assistance et dépannage

▪ Maintenance

▪ Surveillance

24
Assistance et dépannage
▪ Les environnements de cloud privé peuvent être plus faciles à dépanner que les
environnements de cloud public.
▪ Dans un environnement de cloud privé, il y a un accès direct à tous les
systèmes.
▪ Il est possible d’accéder aux journaux, exécuter des traces réseau, exécuter des traces de
débogage ou faire tout ce qui est nécessaire pour résoudre un problème.
▪ Il n’y a pas besoin de compter sur un fournisseur de services pour obtenir de l’aide.
▪ Si l’organisation effectue sa propre assistance et dépannage, elle peut
théoriquement fournir des délais d'exécution beaucoup plus rapides, ce qui
contribuera à maintenir la satisfaction du client.
▪ En fin de compte, la satisfaction du client est primordiale pour maintenir le succès de
l’environnement de l’organisation.
25
Maintenance
▪ Avec les cloud privés, l’organisation est responsable de contrôler le cycle de
mise à niveau.
▪ Elle n’est pas obligée d’effectuer les mises à jour lorsqu’elle ne le souhaite pas.
▪ Elle n’est pas obligée d'effectuer des mises à niveau à moins que la version récente ne
dispose d'une fonctionnalité ou d'une fonctionnalité dont elle souhaite profiter.
▪ Elle peut contrôler le moment où les mises à niveau sont effectuées.
▪ Si l’organisation a des fenêtres de maintenance planifiées régulièrement, les mises à
niveau et autres activités de maintenance peuvent être planifiés pendant cette période
spécifiée. Cela peut aider à réduire l'impact global d'une panne du système.
▪ Avec un cloud interne, il est possible d'exécuter plusieurs versions d'une
application en cas de besoin.
▪ Cette flexibilité donne à l’organisation une capacité accrue à répondre aux
besoins de ses clients.
26
Surveillance
▪ Étant donné que l’organisation a un accès direct aux systèmes de son
environnement de cloud privé, elle sera en mesure d'effectuer toute
surveillance dont elle a besoin.

▪ L’organisation peut tout surveiller, de l'application au matériel du système.

▪ Un grand avantage de cette capacité est que l’organisation peut prendre des
mesures préventives pour éviter une panne, ce qui lui permet d'être plus
proactif dans le service à ses clients.

27
1.2. Cloud Privé: Inconvénients
▪ Bien que le contrôle de l'environnement offre à l’organisation plusieurs avantages
dans un environnement cloud, cela lui pose également des problèmes.
▪ Lors de l’implémentation d’un cloud privé, l’organisation rencontre certains
inconvénients qu’elle peut rencontrer en implémentant une solution interne
traditionnelle.
▪ Il faut mettre ces problèmes en balance avec les avantages pour savoir si un cloud
interne est le bon environnement pour l’organisation.
▪ Inconvénients:
▪ Coût
▪ Compatibilité matérielle et logicielle
▪ Expertise requise
28
Coût
▪ La mise en œuvre d'un cloud privé nécessite des coûts initiaux importants.
▪ Il faut mettre en œuvre une infrastructure qui peut non seulement répondre
aux besoins actuels, mais également aux besoins futurs.
▪ Il faut estimer les besoins de toutes les unités commerciales que l’organisation
soutiendra.
▪ Il faut mettre en place une infrastructure capable de prendre en charge les
heures de pointe.
▪ Tous les systèmes nécessaires pour prendre en charge les heures de pointe ne doivent
pas toujours fonctionner s’il y a un moyen de les démarrer automatiquement lorsque
cela est nécessaire.

29
Compatibilité matérielle et logicielle
▪ Il faut s’assurer que le logiciel implémenté est compatible avec le matériel de
l’environnement.

▪ Il faut également s’assurer que le logiciel implémenté est compatible avec les
clients de l’environnement.
▪ Il se peut qu’il y en a besoin de matériel spécialisé (stockage, par exemple) pour
implémenter une application particulière.

30
Expertise requise
▪ Besoin d'une expertise dans toutes les applications et le système à déployer.
▪ Le besoin d'une expertise interne peut conduire à une formation et une
éducation coûteuses.
▪ L’organisation sera responsable de l’installation des applications et du système,
de leur maintenance et de leur prise en charge
▪ Il faut s’assurer que l’organisation dispose des connaissances internes pour le faire ou de
la capacité de faire appel à des entrepreneurs ou à des consultants externes pour l’aider.
▪ La création d'un environnement cloud nécessite un personnel connaissant le
matériel, le stockage, la mise en réseau, la sécurité et la virtualisation.
▪ Il peut être très difficile de trouver des employés qui possèdent toutes ces
connaissances.
▪ L’organisation aura besoin de quelqu'un qui possède une expertise dans la plate-forme
cloud particulière à implémenter.
31
1.2. Cloud Privé: Responsabilités
▪ Dans un environnement de cloud privé, la répartition des responsabilités est
assez simple.

▪ L’organisation est la responsable de la solution de bout en bout.

▪ Elle est responsable des systèmes qui fournissent le service, des applications client et de
la maintenance des systèmes clients.

32
1.2. Cloud Privé: Considérations relatives à la sécurité
▪ Avec une implémentation de cloud privé, l’organisation aura un contrôle
complet sur les systèmes, les applications et les données.
▪ C’est possible de contrôler qui a accès à quoi.
▪ Garantir la sécurité est plus facile dans un environnement de cloud privé.
▪ À cause du contrôle complet sur les systèmes, il est donc possible mettre en œuvre tous
les moyens de sécurité souhaités.
▪ La réalisation des audits de sécurité et de conformité est possible.
▪ Cela donnera à l’organisation une plus grande confiance, sachant que ses systèmes
répondent à ses besoins en matière de sécurité et de conformité.

33
1.2. Cloud Privé: Considérations relatives à la sécurité
▪ Conformité
▪ L’organisation doit s’assurer qu’elle suit toutes les réglementations de conformité applicables.
→Si l’organisation possède les compétences et la technologie nécessaires pour garantir le respect
des réglementations de conformité, alors disposer des systèmes et des données en interne peut
être un gros avantage.
→Sinon, elle devra acquérir les compétences, ou elle pourrait faire face à de graves problèmes
▪ Données
▪ L’organisation possède les données et les systèmes qui hébergent les données.
→Avoir plus de contrôle sur qui peut accéder aux données et ce qu'ils peuvent en faire.
→Avoir une plus grande assurance que les données sont en sécurité.
▪ Audit
▪ Accès complet à tous les journaux d'application et système.
→Possibilité de voir qui a accédé à quoi et ce qu'il en a fait.
→ Le plus grand avantage est la possibilité de voir tout cela en temps réel, ce qui vous permet de
prendre toutes les mesures correctives nécessaires pour garantir l'intégrité de vos systèmes.
34
1.3. Cloud Communautaire: Présentation
▪ Les cloud communautaires ne sont pas autant utilisés que les cloud publics ou
privés
▪ Il s'agit du modèle de déploiement cloud le moins connu et le moins utilisé.

▪ Dans un cloud communautaire, le cloud est partagé par un groupe

d'organisations qui ont un but ou un objectif commun.
▪ L'environnement cloud est généralement conçu pour les aider à atteindre ce but ou cet
objectif.

35
1.3. Cloud Communautaire: Avantages
▪ De nombreux avantages à avoir un cloud communautaire. Ces avantages sont
centrés sur le fait que l'infrastructure et le coût sont partagées
▪ Coût
▪ Coûts partagés entre les membres de la communauté.
▪ Achat d'infrastructures qu'une organisation membre unique n'aurait peut-être pas pu se permettre.
▪ Réalisation de plus grandes économies d'échelle.

▪ Il faut faire attention, des problèmes peuvent survenir:

▪ Qui est responsable de quels coûts.
▪ Qui «possède» quelles composantes de l'infrastructure.
▪ Ces aspects doivent être clairement définis au début de l'initiative.

36
1.3. Cloud Communautaire: Avantages
▪ Locations multiples
▪ La mutualisation peut aider à tirer parti de certaines économies d'échelle.
▪ Une organisation à elle seule peut ne pas être assez grande pour tirer parti de certaines des
économies de coûts, mais en travaillant avec une autre organisation ou plusieurs organisations, elle
peut être suffisamment grande pour voir ces avantages.

▪ La mutualisation permet également le partage des activités de support et de

maintenance.
▪ Au lieu d'une organisation devant avoir toutes les compétences nécessaires pour soutenir et
maintenir l'environnement, chaque organisation peut apporter sa contribution dans les domaines où
elle possède une expertise.
37
1.3. Cloud Communautaire: Inconvénients
▪ Chaque fois que plusieurs organisations travaillent ensemble, il y a un risque de
conflit. Des mesures doivent être prises pour atténuer les problèmes
potentiels.
▪ La propriété (la possession)
▪ La propriété dans un cloud communautaire doit être clairement définie.
▪ Si plusieurs organisations se réunissent pour assembler une infrastructure, il faut
déterminer un accord de copropriété.
▪ Si une organisation achète des ressources en capital, ces ressources doivent aller à
l’encontre du budget de cette organisation.
▪ Dans certains cas, les organisations se réunissent pour créer le cloud communautaire
peuvent créer une organisation commune unique qui peut «posséder» les ressources.

38
1.3. Cloud Communautaire: Responsabilités
▪ Dans un cloud communautaire, les responsabilités sont partagées entre les
organisations membres.

▪ Il peut y avoir des problèmes pour décider à qui appartient quoi et qui est
responsable de quoi, mais une fois ces questions décidées, la responsabilité
partagée peut être très bénéfique.

▪ La responsabilité partagée réduit le fardeau administratif de toute organisation.

39
1.3. Cloud Communautaire: Considérations relatives à la
sécurité
▪ Les cloud communautaires présentent un ensemble de circonstances
particulières en matière de sécurité, car plusieurs organisations accèderont à
l'environnement et le contrôleront.
▪ Données
▪ Tous les participants de la communauté peuvent avoir accès aux données.
▪ Conformité
▪ La conformité peut être particulièrement délicate.
▪ Les systèmes seront soumis à toutes les réglementations de conformité auxquelles
chacune des organisations membres est soumise.
▪ Ainsi, une organisation peut être soumise à des réglementations avec lesquelles elle a
peu de connaissances.
40
1.3. Cloud Communautaire: Considérations relatives à la
sécurité
▪ Audit
▪ Les organisations membres auront un accès partagé à tous les journaux d'audit des
applications et du système.

▪ Il faut y avoir un accord sur qui exécutera quelles activités.

▪ L’analyse des journaux peut être particulièrement fastidieuse et prendre du temps

41
1.4. Cloud Hybride: Présentation
▪ À mesure que l'ère du cloud computing arrive à maturité, les cloud hybrides
deviendront probablement l'implémentation cloud la plus courante.
▪ Il y a une légère idée fausse sur ce qu'est réellement un cloud hybride.
▪ Beaucoup pensent qu'un cloud hybride est un environnement cloud dans lequel certains
composants sont publics et d'autres privés. Ce n’est pas le cas.
▪ Un environnement de cloud hybride est un environnement dans lequel plusieurs
environnements de cloud distincts sont connectés ensemble.
▪ Les cloud hybrides peuvent offrir le meilleur et le pire des deux modes
▪ Les cloud hybrides offrent la liberté de mettre en œuvre tout ce qui est nécessaire
pour répondre aux besoins d’une organisation; mais ils peuvent être complexes et
coûteux à mettre en œuvre.
42
1.4. Cloud Hybride: Avantages
▪ En plus des avantages apportés par chacun des modèles de cloud, le modèle de
cloud hybride apporte une flexibilité accrue.
▪ Si l’objectif ultime est de tout transférer vers un fournisseur de services publics, un
environnement hybride permet de passer à un environnement cloud sans être obligé de
tout déplacer public jusqu'à ce que le moment soit venu.
▪ Pour certaines applications, les offres de service public sont très coûteuses. Une
organisation peut conserver ces applications en interne jusqu'à ce que le prix baisse.
▪ S’il y a des problèmes de sécurité concernant le transfert de certains types de données
vers un fournisseur de services publics, le modèle de cloud hybride permet à
l’organisation de laisser ces données internes jusqu'à ce qu’elle soit assuré qu'elles
seront en sécurité dans un environnement de cloud public.
▪ Plusieurs entreprises utilisent un modèle de cloud hybride pour offrir une
tolérance aux pannes et une haute disponibilité.
▪ Possibilité d’héberger certaines applications dans deux environnements. De cette façon,
si un environnement tombe en panne, il est toujours possible d’accéder à l'application. 43
1.4. Cloud Hybride: Inconvénients
▪ Un environnement de cloud hybride peut être l'environnement le plus
complexe à mettre en œuvre.
▪ Des considérations différentes pour chaque type de cloud à implémenter.
▪ Toutes les règles et procédures ne s'appliqueront pas à tous les environnements. Il faut
développer un ensemble de règles et de procédures pour chaque environnement.
▪ L'intégration
▪ Il peut y avoir certaines applications dans un cloud privé et d’autres dans un cloud public;
mais ces applications peuvent avoir besoin d'accéder et d'utiliser les mêmes données.
▪ Deux choix possibles:
▪ Dupliquer des copies de données, ce qui obligerait l’organisation à configurer un type de mécanisme
de réplication pour garder les données synchronisées,
▪ Déplacer les données selon les besoins. Le déplacement de données dans un environnement de cloud
hybride peut être délicat car il faut se soucier des contraintes de bande passante. 44
1.4. Cloud Hybride: Considérations relatives à la sécurité
▪ Les cloud hybrides peuvent entraîner des considérations de sécurité
particulières.
▪ Non seulement les problèmes de sécurité de chaque environnement individuel, mais
également des problèmes créés par la connexion des environnements entre eux.
▪ Données
▪ Le déplacement des données entre les environnements cloud peut être très risqué.
▪ Tous les environnements concernés doivent disposer de données sécurisées de manière satisfaisante.
▪ Les données en mouvement peuvent être particulièrement difficiles à sécuriser.
▪ Les deux côtés de la conversation doivent prendre en charge les mêmes protocoles de sécurité et ils
doivent être compatibles entre eux.
▪ Audit
▪ L'audit peut être délicat. L'accès utilisateur peut pivoter entre interne et externe.
▪ Suivre un processus du début à la fin peut conduire à l’accès aux systèmes internes et externes. Il est
important d’avoir un moyen pour faire la corrélation du journal des événements afin de pouvoir faire
correspondre ces événements internes et externes.
45
Conclusion
▪ NIST a décrit quatre modèles de déploiement cloud: public, privé,
communautaire et hybride.
▪ Les cloud publics sont ouverts au grand public.

▪ Les cloud privés sont spécifiques à une organisation particulière.

▪ Les cloud de communauté sont partagés par plusieurs organisations.

▪ Les cloud hybrides sont des environnements composés d'une combinaison de modèles
cloud.

▪ Chaque modèle a son ensemble d'avantages, d'inconvénients et d'implications

sur la sécurité.
46
2. Modèles de Service Cloud
▪ Software as a Service
▪ Platform as a Service
▪ Infrastructure as a Service
▪ Autres modèles de Service

47
Introduction
▪ Selon la définition du cloud du NIST, il existe trois principaux modèles de
service cloud:
▪ Software as a Service (SaaS),
▪ Platform as a Service (PaaS), et
▪ Infrastructure as a Service (IaaS).
▪ Puisque nous avons affaire à des prestataires de services, tout est négociable.
▪ Les services existants sont modifiés et de nouveaux services sont ajoutés pour répondre
aux besoins des clients.
▪ À mesure que le marché du cloud se développe, nous devons reconnaître l'existence de
nombreux autres modèles de services aujourd'hui.
▪ Nous couvrons quelques-uns des plus courants dans ce chapitre.
48
Introduction Utilisateurs

Systèmes clients

Connectivité réseau
Applications

Logiciels
d'infrastructure
Système
d'exploitation
Couche de
virtualisation
Serveurs
Pile de services physiques
informatiques
Mise en réseau
et stockage
Mécanique et
électrique
49
2.1. SaaS: Présentation
▪ SaaS est généralement considéré comme le modèle de service cloud d'origine.
▪ Un modèle SaaS est similaire à l'ancien modèle de fournisseur de services
d'application (ASP: Application Service Provider) avec quelques différences clés.
Ancien modèle ASP Modèle SaaS
• Les applications hébergées étaient
• Les applications SaaS sont des
des applications client / serveur
applications Web qui ne nécessitent
• Certains types d'infrastructure et de
aucun client particulier
client spéciaux étaient généralement
• Processus simplifié d’accès aux
nécessaires pour accéder aux
applications
applications
• Les clients accèdent à la même
• Les clients accédaient à différentes application; il existe simplement
instances d'une application différentes partitions ou vues de
l'application. 50
2.1. SaaS: Services Utilisateurs
▪ Cette figure décrit les
services que vous pouvez Systèmes clients

généralement attendre d'un

fournisseur SaaS Connectivité réseau
Applications

Logiciels
d'infrastructure
Système
d'exploitation

SaaS Couche de
virtualisation
Serveurs
physiques
Mise en réseau
et stockage
Mécanique et
électrique
51
2.1. SaaS: Caractéristiques
▪ Présentation de certaines caractéristiques des déploiements SaaS classiques.
▪ Selon le prestataire et le service proposé, les caractéristiques peuvent légèrement
différer, mais nous verrons les scénarios les plus courants.

▪ Caractéristiques SaaS:
▪ Personnalisation

▪ Support et maintenance

▪ Analyses

▪ Intégration

52
Personnalisation
▪ Avec les implémentations SaaS, le fournisseur de services contrôle pratiquement
tout ce qui concerne l'application. →Cela limitera toute personnalisation possible
▪ C’est possible de demander que l'interface utilisateur ou l'aspect et la convivialité de
l'application soient légèrement modifiés.
▪ Les modifications en gros ne sont généralement pas autorisées.
▪ Dans la plupart des cas, les modifications devront être faites par le fournisseur
▪ Autoriser la personnalisation peut être très coûteux pour le fournisseur de
services et, par conséquent, le client. →Une personnalisation étendue:
▪ Signifie l'hébergement d'une instance distincte d'une application pour un client
particulier.
▪ Pose un problème lors de la mise à niveau du logiciel, car la personnalisation pourra être
perdue lors de la mise à niveau. Ensuite, il devrait être recréé par le client ou le
fournisseur. Cela peut prendre beaucoup de temps; et le temps c'est de l'argent.
53
Support et Maintenance
▪ Dans un environnement SaaS, les mises à niveau logicielles sont centralisées et
effectuées par le fournisseur de services.
▪ Pas de soucie de la mise à niveau du logiciel sur plusieurs clients.
▪ Les mises à niveau centralisées permettent des mises à niveau plus fréquentes, ce qui
peut permettre une livraison accélérée des fonctionnalités.
▪ Les mises à niveau centralisées peuvent poser un problème.
▪ Lorsque le fournisseur décide qu'il est temps de procéder à la mise à niveau, le client a
peu ou pas de choix en la matière.
▪ S'il y a un temps d'arrêt associé à la mise à niveau, il faut simplement l'accepter.
▪ La mise à niveau peut nécessiter une formation supplémentaire des utilisateurs. Ce qui peut entraîner
des temps d'arrêt ou des périodes de baisse de productivité.
54
Analyses
▪ Les analyses et les statistiques d'utilisation peuvent fournir des informations
utiles sur l'utilisation des applications.
▪ Dans les implémentations SaaS, le fournisseur a la possibilité de visualiser les
activités des utilisateurs et de déterminer les tendances.
▪ Ces informations peuvent être partagées avec les clients.
▪ Étant donné que la plupart des environnements cloud sont des offres de
paiement à l'utilisation, il est important d’avoir une idée sur :
▪ Les tendances d'utilisation → Cela aide le fournisseur à comprendre quand il peut avoir
un pic d'utilisation et donc un pic de coûts.
▪ L'utilisation simultanée et l'utilisation totale → Cela pourra aider à mieux estimer les
coûts de licence.

55
Intégration
▪ Dans SaaS, les données sont stockées sur le site du fournisseur.
▪ En général, le client n'a pas d'accès direct aux données
→Problèmes de génération de rapports et de veille stratégique.
→Problèmes lors du besoin d’une correction manuelle des données ou de recharger des
données en masse.

▪ Dans certaines implémentations, Il est possible de déplacer des données dans

les deux sens entre l'instance SaaS et vos systèmes internes locaux.
▪ Il faut faire attention à la quantité de bande passante utilisée lors de ces types
d'opérations
→Des frais pour le fournisseur SaaS et des frais pour le fournisseur Internet. 56
2.1. SaaS: Responsabilités Maintenance du système client

▪ Dans les implémentations SaaS, la plupart Connectivité réseau

des responsabilités incombent au Maintenance des applications

fournisseur de services.
Plateforme de développement,
Plateforme de données
▪ L'une des raisons de popularités des
implémentations SaaS OS Patching, Antivirus
Responsabilités
▪ Les organisations peuvent libérer leurs Maintenance d’hyperviseur
du fournisseur
SaaS
ressources internes pour d'autres activités
Maintenance matérielle,
Mises à jour du firmware
▪ Cette figure donne une idée sur la
Connectivité réseau, équilibrage de la
responsabilité du fournisseur de services et charge réseau

sur ce qui est pris en charge par le client. Alimentation et refroidissement

57
2.1. SaaS: Responsabilités
▪ Le fournisseur est responsable de tout sauf des systèmes clients.
▪ Garantie que l'application est à jour.
▪ Assurance que les systèmes ont été correctement corrigés.
▪ Garantie du stockage correcte des données.
▪ Surveillance des performances des systèmes et réalisation des ajustements nécessaires.

▪ Le client est responsable du ou des systèmes client.

▪ Il doit s'assurer que les clients sont connectés à l'application SaaS.
▪ Les systèmes clients doivent avoir tous les logiciels clients nécessaires installés.
▪ Les systèmes clients doivent être patchés à un niveau approprié.

58
2.1. SaaS: Facteurs
▪ De nombreux facteurs ont contribué à l'essor des offres publiques SaaS.
▪ Une forte augmentation de la création et de la consommation d'applications Web.
▪ Les utilisateurs s'habituent à l'aspect et à la convivialité de ces types d'applications.
▪ Une amélioration de la qualité et la facilité avec lesquelles les applications web sont
développées.
▪ La maturité des anciennes plates-formes et protocoles et l'introduction de nouveaux ont créé une
grande variété d'outils qui peuvent être utilisés pour créer des applications Web robustes.
▪ Certains de ces outils sont HTML5, JavaScript, CSS, Ruby on Rails et PHP.

▪ La plupart des fournisseurs SaaS proposent leurs services sous la forme

d'applications Web.
▪ L'acceptation des services SaaS augmente avec l’augmentation de l'acceptation des
applications Web
59
2.1. SaaS: Défis
▪ Même si le SaaS est actuellement le modèle de service cloud le plus populaire,
l'adoption du SaaS pose encore de nombreux défis.
▪ Les fournisseurs SaaS ont été en mesure de résoudre certains problèmes et
d'atténuer d’autres, mais il en existe encore beaucoup.
▪ Emplacement disparate :
▪ Les applications SaaS sont généralement hébergées hors site→ Connexions entre le
client et l'application se base sur Internet public, parfois sur de longues distances.
▪ Les longues distances introduisent une latence qui peut être un facteur limitant pour
certaines applications qui nécessitent des temps de réponse en millisecondes.
▪ Certaines applications ne fonctionneront pas dans des environnements où la latence est importante
60
2.1. SaaS: Défis
▪ Architecture mutualisée
▪ Manque de personnalisation poussée
▪ Puisque l'application est partagée, il est impossible d'effectuer des personnalisations poussées
→Il est nécessaire peut-être d’utiliser une application sur site pour avoir une personnalisation poussée.
▪ Problèmes de sécurité
▪ Puisque les clients accèdent à la même instance d’une application, une faille d’application peut
permettre à un client d’accéder aux données d’un autre client.
▪ Les fournisseurs SaaS doivent être vigilants quant à la correction des applications lorsqu'elles sont
détectées. Plus un problème reste longtemps non résolu, plus il est risqué pour les clients.
▪ Sécurité des données
▪ Les employés du fournisseur de services peuvent avoir un accès direct aux systèmes qui
hébergent les données.
▪ Une façon d'atténuer ce problème consiste à protéger les données au niveau du logiciel.
▪ Cryptage des données stockées et les données en mouvement.

61
2.1. SaaS: Fournisseurs
▪ Outlook.com
▪ La messagerie Web est l'une des offres SaaS les plus populaires.
▪ Différents fournisseurs proposent depuis longtemps des e-mails basés sur le Web. Ils
proposent généralement un service gratuit et un service payant.
▪ Outlook.com est le service de messagerie de Microsoft. Il est le successeur de Hotmail et
Live Mail.
▪ Un compte de messagerie Outlook.com par défaut est gratuit.
▪ Pour avoir des fonctionnalités avancées ou une version qui n'inclut pas de publicités, il
faut mettre à niveau le compte.
▪ Google Drive
▪ Il donne un accès en ligne pour afficher et créer des documents de traitement de texte,
des feuilles de calcul, des présentations et une foule d'autres documents.
▪ Il est possible d’utiliser les types de documents intégrés ou ajouter de nouveaux types. 62
2.2. PaaS: Présentation
▪ PaaS est une offre de services par laquelle les clients reçoivent une plate-forme
à utiliser pour leurs besoins informatiques.
▪ Dans la plupart des cas, cette plate-forme est utilisée pour le développement.
▪ Selon le fournisseur, la plate-forme de développement peut être:
▪ Un système d'exploitation, ou
▪ Une plate-forme de développement complète comprenant un serveur Web et des
bibliothèques de développement.

63
2.2. PaaS: Présentation Utilisateurs
▪ Cette figure présente les
services généralement Systèmes clients

offertes par un
fournisseur PaaS. Connectivité réseau
Applications

Logiciels
d'infrastructure
Système
d'exploitation

PaaS Couche de
virtualisation
Serveurs
physiques
Mise en réseau
et stockage
Mécanique et
électrique
64
2.2. PaaS : Caractéristiques
▪ Les implémentations PaaS permettent aux organisations de créer et de
déployer des applications Web sans avoir à créer leur propre infrastructure.
▪ Les offres PaaS comprennent généralement des fonctionnalités de
développement, d'intégration et de test.
▪ Lorsqu'une organisation passe à une implémentation PaaS, elle implémente un
type d'application ou de service sur la plate-forme.
▪ Le fournisseur n'a généralement aucun contrôle sur la façon dont l'application ou le
service est développé ou sur la qualité du développement.
▪ Dans de nombreux déploiements, le fournisseur offrira des services supplémentaires,
tels que des services d'équilibrage de charge de base, pour aider dans le déploiement
des applications.
▪ Parmi les caractéristiques observées dans les environnements PaaS:
Personnalisation, Analyses, et Intégration 65
2.2. PaaS : Caractéristiques
▪ Personnalisation
▪ Avec PaaS, le client a un contrôle total sur l'application. il est libre de personnaliser
l'application comme elle souhaite.
▪ Cependant, le client ne peut pas apporter de nombreuses modifications à la plate-forme
de développement.
▪ Dans la plupart des cas, cette plateforme sera strictement contrôlée par le fournisseur.
▪ Il peut y avoir des options de configuration, mais la véritable personnalisation sera limitée
▪ Analyse
▪ Puisque le client crée les applications, il peut visualiser l'utilisation des applications et de
déterminer les tendances.
▪ Il peut voir quels composants sont les plus utilisés et lesquels ne sont pas utilisés.
▪ Le client a généralement une visibilité sur l'utilisation de la plateforme.
▪ Il peut déterminer quand de nouveaux systèmes doivent être ajoutés pour gérer la charge.
▪ Souvent, les fournisseurs donnent à leurs client la possibilité de lancer automatiquement de nouveaux
systèmes lorsque les systèmes actuels atteignent certains seuils de charge. 66
2.2. PaaS : Caractéristiques
▪ L'intégration
▪ Dans un environnement PaaS, les données sont stockées sur le site du fournisseur, mais
le client y aura un accès direct.
▪ La gestion de la veille économique et des rapports ne devrait pas être un problème du
point de vue de l'accès
▪ Le client peut rencontrer des problèmes relatives à l'utilisation de la bande passante
▪ Lors du déplacement de grandes quantités de données entre l’environnement interne du client et
l'environnement du fournisseur, il peut y avoir des problèmes de performances.

67
2.2. PaaS: Responsabilités Maintenance du système client

Connectivité réseau

Maintenance des applications

Plateforme de développement,
Plateforme de données

▪ Dans une offre PaaS, les responsabilités sont

OS Patching, Antivirus
quelque peu réparties entre le fournisseur
Responsabilités
de services et le client du fournisseur
Maintenance d’hyperviseur
PaaS

Maintenance matérielle,
Mises à jour du firmware

Connectivité réseau, équilibrage de la

charge réseau

Alimentation et refroidissement
68
2.2. PaaS: Responsabilités
▪ Le fournisseur s'occupe de tout au niveau de la plate-forme de développement
et au-dessous.
▪ Il s'assurera que le système d'exploitation est corrigé et à jour lorsqu'il est livré au client.
▪ Il effectue des mises à jour périodiques du système d'exploitation qui sont déployées au
client.
▪ Le client est responsable de tout ce qui se situe au-dessus du système
d'exploitation et de la plate-forme de développement.
▪ Il est chargé de l'installation et de la maintenance de toutes les applications
supplémentaires dont il a besoin. Cela inclut les correctifs et la surveillance des
applications.
▪ La plate-forme de base de données est fournie par le client
▪ Le client est responsable des données et a un accès direct aux données.
▪ En cas de problème avec les données, il peut mettre en œuvre toute correction de données directe
qu’il pourrait avoir besoin d'effectuer.
69
2.2. PaaS: Facteurs
▪ Plusieurs entreprises souhaitent évoluer vers un modèle de cloud public, mais
ne trouvent pas de fournisseurs SaaS publics offrant les applications dont elles
ont besoin.

▪ Un modèle PaaS leur permet de déplacer l'infrastructure et les plates-formes

hors de leurs centres de données internes tout en leur permettant de
développer les applications dont ils ont besoin.

70
2.2. PaaS: Défis
▪ Certain nombre de défis avec les environnements PaaS publics, y compris:
▪ Flexibilité
▪ Avoir des difficultés à trouver un fournisseur avec une plate-forme qui répond au besoin.
▪ La plupart des fournisseurs de PaaS limitent leurs offres à des ensembles de plates-
formes spécifiques.
▪ Absence de fournisseur offrant des besoins spéciaux ou une configuration spécifique
▪ Sécurité
▪ Le fournisseur a un contrôle administratif sur le système d'exploitation et la plate-forme
de base de données.
▪ Étant donné que le fournisseur a un accès direct aux systèmes, il a un accès direct à
toutes les applications et données.
71
2.2. PaaS: Fournisseurs
▪ Le nombre de fournisseurs PaaS sur le
marché continue de croître
▪ Exemple: Windows Azure
▪ Il a été l'un des premières offres PaaS à
arriver sur le marché.
▪ Il propose une offre gratuite et des offres
mises à niveau qui incluent des
fonctionnalités telles que des SLA accrus.
▪ Il facilite la création d'un site Web ou
d'une plateforme de développement.
▪ Il comprend une grande variété d'options
telles que les services de calcul, les
services de données, les services
d'application et le service réseau.
72
2.2. PaaS: Fournisseurs
▪ Exemple 2: Google App Engine
▪ Une solution PaaS qui permet aux utilisateurs d'héberger leurs propres applications sur
la même infrastructure ou sur une infrastructure similaire à celle de Google Docs, Google
Maps et d'autres services Google populaires.
▪ Comme Microsoft Azure, elle fournit une plate-forme pour créer et exécuter des
applications .NET. Elle permet aux utilisateurs de développer et d'héberger des
applications écrites à l'aide de Java, Python et d'un nouveau langage appelé Go.
▪ La plate-forme prend également en charge d'autres langages qui utilisent Java Virtual
Machine. (JVM), tels que les langages de programmation JRuby, JavaScript (Rhino) et
Scala.
▪ Les applications hébergées sur Google App Engine peuvent évoluer à la fois en termes de
calcul et de stockage, tout comme les autres produits Google.

73
2.3. IaaS: Présentation Utilisateurs

▪ IaaS fournit des services de

Systèmes clients
base tels que:
▪ la puissance de calcul,
Connectivité réseau
▪ le stockage,
Applications
▪ la mise en réseau, et
Logiciels
▪ les systèmes d'exploitation. d'infrastructure

▪ L’organisation peut ensuite Système

d'exploitation
créer son environnement en Couche de
plus de ces ressources. virtualisation
Serveurs
physiques
IaaS
Mise en réseau
et stockage
Mécanique et
électrique
74
2.3. IaaS: Présentation
▪ Un fournisseur IaaS peut fournir des ressources matérielles telles que des serveurs.
▪ Une organisation bénéficiant d’IaaS a un accès direct aux serveurs qui sont hébergés dans le
centre de données du fournisseur. Elle peut installer tout ce dont elle a besoin sur les serveurs.
▪ Cela peut cependant être coûteux, car le fournisseur ne serait pas en mesure de tirer parti de la
multi-location ou des économies d'échelle.
▪ Par conséquent, les clients devrait absorber tous les coûts des systèmes eux-mêmes.
▪ Un modèle plus courant consiste pour un fournisseur IaaS à fournir des machines
virtuelles
▪ Ces machines peuvent être utilisé pour installer tout ce que le client a besoin. Ils peuvent
exécuter différents système d'exploitation.
▪ Étant donné que les systèmes sont virtualisés, le fournisseur peut tirer parti de la multi-location.
▪ Ces systèmes peuvent héberger plusieurs clients sur le même matériel physique. Ils peuvent alors
augmenter considérablement leur densité.
▪ Le fournisseur peut alors répercuter les économies de coûts à ses clients.
75
2.3. IaaS: Responsabilités Maintenance du système client

▪ Dans IaaS, le client est responsable de la

Connectivité réseau
majeure partie de l'environnement.
Maintenance des applications
▪ Le fournisseur est responsable de la couche
hyperviseur (si elle est utilisée) et ci- Plateforme de développement,
dessous. Plateforme de données

▪ Cela inclut le matériel physique, le stockage et la

mise en réseau. OS Patching, Antivirus

▪ Le matériel physique est stocké dans le centre de

données du fournisseur, mais le client peut y Maintenance d’hyperviseur
avoir un accès complet.
Maintenance matérielle, Responsabilités
▪ Le client est responsable de: Mises à jour du firmware du fournisseur
▪ Maintenance du système d'exploitation et des IaaS
Connectivité réseau, équilibrage de la
applications charge réseau
▪ s'assurer que les systèmes disposent
Alimentation et refroidissement
d'un antivirus à jour. 76
2.3. IaaS: Facteurs
▪ De nombreuses organisations se tournent vers les fournisseurs IaaS pour
étendre leurs capacités.
▪ Au lieu de dépenser l'argent pour agrandir un centre de données ou construire un
nouveau, les organisations louent des systèmes fournis par un fournisseur IaaS.
▪ Les organisations recherchent également des fournisseurs IaaS pour fournir
une capacité de pointe.
▪ Certaines organisations n'ont besoin d'une capacité accrue qu'à certaines occasions.
▪ Pour cette raison, ils ne veulent pas dépenser d’argent pour des solutions permanentes
coûteuses. Un fournisseur IaaS leurs fournie de la capacité sur une base temporaire.
▪ Les clients ne paient pour l'augmentation de la capacité que lorsqu'ils en ont besoin.
77
2.3. IaaS: Défis
▪ Les organisations voient les avantages, mais s'inquiètent de la perte de contrôle
▪ Le coût total peut également être un problème.
▪ Dans de nombreux environnements IaaS, le client est facturé pour l'utilisation des
ressources, comme le processeur et la mémoire. À moins que le client ne surveillait
l'utilisation de son système, il pourrait être sous le choc lorsque la facture arrivera.
▪ Défis de sécurité
▪ Les défis de sécurité pour les implémentations IaaS sont similaires à ceux des autres
fournisseurs de services.
▪ Étant donné que le fournisseur n'a pas besoin d'accéder au système d'exploitation réel
ou aux éléments à un niveau supérieur, il n'est pas nécessaire pour eux d'avoir des
comptes administratifs sur le système.
▪ Cela peut donner au client au moins un certain niveau de confort en matière de sécurité.
78
2.3. IaaS: Fournisseurs
▪ Les fournisseurs IaaS prennent vraiment de l'ampleur sur le marché.

▪ Ce n’est pas seulement dû à la demande. Il y a aussi le fait que les plates-

formes IaaS telles que CloudStack et OpenStack ont été développées pour
faciliter l'automatisation et l'orchestration.

▪ Exemples de fournisseurs IaaS les plus connus:

▪ Amazon EC2, et

▪ Rackspace

79
2.4. Autres modèles de service
▪ Le cloud est un ensemble de services.

▪ Nouveaux services sont constamment créés pour répondre aux besoins des
utilisateurs.

▪ Ces services débouchent sur de nouveaux modèles de services en plus des trois
modèles traditionnels.

▪ Bien qu'il existe de nombreux autres modèles de service, nous présentons:

▪ Database as a Service (DbaaS), et

▪ Desktop as a Service (DaaS).

80
Database as a Service (DbaaS)
▪ DbaaS fournit une plate-forme de base de données que les organisations
peuvent utiliser pour stocker leurs données.
▪ De nombreux fournisseurs de PaaS fournissent également des services de base
de données
▪ Dans nombreux cas, les organisations n'ont pas besoin d'une plate-forme de
développement; ils ont simplement besoin d'un endroit pour stocker les données.
▪ Dans ces cas, une option DbaaS est un bon choix.
▪ Bien que les prix du stockage baissent, le coût reste assez élevé.
▪ Une implémentation DbaaS inclue la plate-forme de base de données et le stockage dont
le client besoin à un coût inférieur à ce que le client pourrait implémenter en interne.

81
Desktop as a Service (DaaS)
▪ DaaS est l'un des nouveaux modèles de service fournis.
▪ DaaS fournit aux utilisateurs un bureau virtuel qui peut être utilisé pour
effectuer des ordinateurs de bureau.
▪ Les entreprises tentent toujours de trouver le meilleur moyen de fournir ce
type de service et les fonctionnalités dont elles ont besoin pour le faire.
▪ L'une des grandes questions est de savoir si:
▪ les postes de travail mutualisés fourniront une expérience utilisateur adéquate, ou
▪ des postes de travail dédiés sont nécessaires pour offrir une expérience utilisateur
adéquate
82
Conslusion
▪ NIST a décrit trois principaux modèles de services cloud: SaaS, PaaS et IaaS.

▪ Chaque modèle de service a ses propres avantages et inconvénients.

▪ Une chose à laquelle il faut faire attention lors du choix d’un modèle de service
et les responsabilités du client ainsi que celle du fournisseur.
▪ Avec un modèle cloud, le fournisseur est responsable de certains aspects. Quoi qu'il en
soit, il faut s’assurer que ces éléments sont pris en compte.

▪ Le client doit toujours s’assurer d'avoir pris en compte la maintenance et la surveillance

de ses systèmes et applications.

83
3. Prendre la décision
▪ Choix de migrer vers le cloud ou pas
▪ Choix du modèle de service cloud
▪ Choix du modèle de déploiement cloud
▪ Choix du fournisseur de services de cloud public

84
Introduction
▪ Choisir le bon scénario de cloud et le bon fournisseur peut être essentiel au
succès de votre organisation.
▪ Une fois que vous avez choisi le fournisseur, vous pourriez être bloqué, car il pourrait
être extrêmement difficile pour vous de déplacer vos données vers un autre fournisseur.
▪ Si le service informatique choisit le mauvais fournisseur, il risque de perdre sa
crédibilité auprès de l'entreprise.
▪ L'un des avantages de cloud public est que l'entreprise peut utiliser les services
directement. Ils n'ont pas besoin de s'appuyer sur leur service informatique interne.
▪ Si le service informatique d'une organisation perd sa crédibilité, il y a de fortes chances
que l'entreprise commence à les contourner complètement

85
3.1. Choix de migrer vers le cloud ou pas
▪ La première étape consiste à déterminer le problème à résoudre.
▪ Résoudre une sorte de problème technique ou fonctionnel,
▪ Résoudre le problème de la façon dont vous pouvez offrir à vos clients un nouveau
service ou une nouvelle capacité.
▪ Déterminer si le service dont vous avez besoin est quelque chose que vous
pouvez faire vous-même.
▪ Ce n'est pas parce que vous pouvez le faire que vous devriez le faire.
▪ Certaines personnes estiment que s'il ne s'agit pas d'une offre qui est au cœur de votre
entreprise, vous devriez envisager de la transférer vers un fournisseur de services.
▪ Cela est particulièrement vrai pour les services dont le support et la maintenance sont
coûteux.

86
3.1. Choix de migrer vers le cloud ou pas
▪ Déterminer quelles seraient vos attentes pour un fournisseur.
▪ Il faut être réaliste et déterminer s'il existe un fournisseur qui pourrait répondre à vos
besoins
▪ Parfois, vos attentes peuvent être irréalistes qu'aucun fournisseur ne pourrait y répondre

▪ Un autre point clé à prendre en compte est la fréquence à laquelle vous

prévoyez utiliser les services
▪ Si vous les utilisez régulièrement, il peut être plus rentable de mettre en œuvre les
services vous-même
▪ N'oubliez pas que sur le cloud, vous paierez pour l'utilisation, donc l'utilisation régulière
des services peut être très coûteuse. 87
3.2. Choix du modèle de service cloud
▪ Après avoir compris les bases de ce que vous voulez faire, vous devez
déterminer quel modèle de service correspond le mieux à vos besoins.
▪ Ce n'est peut-être pas aussi simple que vous le pensez.
▪ Par exemple, ce n'est pas parce que vous avez besoin de services d'application que vous
choisissez un fournisseur SaaS. Vous pouvez choisir un fournisseur PaaS et créer vous-
même l'application.
▪ Examinons donc certains des éléments dont vous devez tenir compte lors du
choix de votre modèle de service:
▪ Expérience utilisateur;
▪ Sécurité; et
▪ Conformité
88
Expérience utilisateur
▪ L'expérience utilisateur peut jouer un grand rôle dans votre décision:
▪ L’objectif final est de servir les clients. Si vos clients ne sont pas satisfaits, votre
implémentation ne sera pas réussie.
▪ S'il est important de contrôler l'expérience utilisateur, un modèle SaaS public
peut ne pas être une bonne option.
▪ Dans un modèle SaaS, l’organisation a très peu de:
▪ Contrôle sur l'interface utilisateur
▪ Possibilités de personnaliser l'application pour ses utilisateurs.
▪ Avec une implémentation PaaS ou IaaS, l’organisation aura un contrôle total sur
l'application et peut personnaliser l'application.
▪ D'autres facteurs, tels que la bande passante du réseau, peuvent jouer un rôle
dans la détermination de l'expérience utilisateur.
▪ Sans bande passante appropriée, le système peut sembler lent ou ne pas répondre. 89
Sécurité
▪ Pour le cloud public, les différents modèles de service cloud offrent différents
niveaux de sécurité en fonction de qui a le contrôle sur quoi
▪ Il existe deux scénarios différents à considérer:
▪ Protéger vos données des menaces externes, ou
▪ Protéger vos données des menaces potentielles chez le fournisseur.
▪ Dans un environnement SaaS, le fournisseur a un contrôle total et un accès à
toutes les données, et vous ne pouvez pas faire grand-chose pour les protéger.
▪ Dans un environnement IaaS, le fournisseur a un accès physique aux données,
mais il existe des méthodes à mettre en place pour protéger ces données
▪ Ex: la mise en œuvre du chiffrement des données.

90
Conformité
▪ La plupart des organisations ont au moins quelques règles de conformité
auxquelles elles doivent adhérer.
▪ Les réglementations de conformité peuvent alourdir les systèmes informatiques et
l’infrastructure de l’organisation.
▪ De nombreuses personnes se tournent vers le cloud pour alléger ce fardeau.
▪ Chaque modèle de service cloud varie dans la mesure où il peut aider à
respecter les réglementations de conformité d’une organisation.
▪ Dans un modèle SaaS, le fournisseur assumera une grande partie du fardeau de
conformité.
▪ En fonction de la conformité requise, le fournisseur SaaS peut assumer toute la charge.
▪ L’organisation peut toujours être responsable d'un point de vue juridique, mais le
fournisseur assumera la charge de s'assurer que ses systèmes sont conformes.
91
Conformité
▪ Dans un modèle PaaS, la charge est partagée.
▪ Le fournisseur veillera à ce que les réglementations de conformité soient respectées par
la plate-forme et le matériel.

▪ Le client doit s'assurer que les règles de conformité sont respectées par l'application.

▪ Cela peut être un domaine un peu délicat. Une grande diligence raisonnable doit être
effectuée pour déterminer si l'ensemble de la mise en œuvre est conforme.

▪ Dans un modèle IaaS, la majeure partie du fardeau incombe au client.

▪ Le client a la plus grande confiance que les mesures de conformité appropriées ont été
prises
92
3.3. Choix du modèle de déploiement cloud
▪ Après avoir choisi le modèle de service cloud qui correspond le mieux à vos
besoins, vous devez déterminer votre modèle de déploiement cloud.
▪ Le choix est parmi public, privé, communautaire et hybride.
▪ Il faut toujours déterminer quel modèle convient le mieux à votre organisation.
▪ Examinons donc certains des éléments dont vous devez tenir compte lors du
choix de votre modèle de déploiement cloud:
▪ Expérience utilisateur;
▪ Sécurité; et
▪ Responsabilités
93
Expérience utilisateur
▪ Le cloud offre différentes expériences utilisateur en fonction du modèle de
déploiement.
▪ Pour un cloud privé, l’organisation a un contrôle total sur l'expérience
utilisateur
▪ Elle peut contrôler l'application, le réseau et les systèmes clients. Ce qui lui permet de
tout régler pour des performances et une convivialité optimales.
▪ Pour un cloud public, dans certains cas, l’organisation n'a peut-être aucun
contrôle sur l'expérience utilisateur.
▪ Dans un environnement cloud de communauté, le contrôle sur l'expérience
utilisateur dépend de l'accord que l’organisation a conclu avec les autres
membres de la communauté.

94
Sécurité
▪ La sécurité est toujours un sujet compliqué, en particulier plus compliqué
lorsque vous le traitez avec le cloud

▪ C'est principalement une question de confiance. À qui faites-vous confiance

pour votre sécurité?

▪ De nombreuses organisations préfèrent faire confiance à un tiers plutôt qu'à

elles-mêmes.

▪ La sécurité est une préoccupation si importante que vous devez suivre ce en

quoi vous avez confiance
95
Responsabilités
▪ Les responsabilités varient considérablement en fonction du modèle de cloud
que vous envisagez d'utiliser.

▪ Cela est un facteur clé dans votre décision.

▪ En fait, l’un des principaux moteurs des cloud publics est la volonté des organisations de
réduire leurs responsabilités internes.

▪ Les tableaux suivants décrivent qui est responsable de quoi dans chaque
configuration d'environnement.

96
Responsabilités SaaS par modèle de déploiement cloud
Public Privé Communauté Hybride
Mises à jour de
Fournisseur Consommateur Consommateur Varie
l'application
Mises à jour du
système Fournisseur Consommateur Consommateur Varie
d'exploitation
Antivirus Fournisseur Consommateur Consommateur Varie
Stockage Fournisseur Consommateur Consommateur Varie
Mise en réseau Fournisseur Consommateur Consommateur Varie
Serveur physique
Fournisseur Consommateur Consommateur Varie
Matériels
Application client Consommateur Consommateur Consommateur Varie
Système client Consommateur Consommateur Consommateur Varie

97
Responsabilités PaaS par modèle de déploiement cloud
Public Privé Communauté Hybride
Mises à jour de
Consommateur Consommateur Consommateur Varie
l'application
Mises à jour du
système Fournisseur Consommateur Consommateur Varie
d'exploitation
Antivirus Varie Consommateur Consommateur Varie
Stockage Fournisseur Consommateur Consommateur Varie
Mise en réseau Fournisseur Consommateur Consommateur Varie
Serveur physique
Fournisseur Consommateur Consommateur Varie
Matériels
Application client Consommateur Consommateur Consommateur Varie
Système client Consommateur Consommateur Consommateur Varie

98
Responsabilités IaaS par modèle de déploiement cloud
Public Privé Communauté Hybride
Mises à jour de
Consommateur Consommateur Consommateur Varie
l'application
Mises à jour du
système Varie Consommateur Consommateur Varie
d'exploitation
Antivirus Consommateur Consommateur Consommateur Varie
Stockage Fournisseur Consommateur Consommateur Varie
Mise en réseau Fournisseur Consommateur Consommateur Varie
Serveur physique
Fournisseur Consommateur Consommateur Varie
Matériels
Application client Consommateur Consommateur Consommateur Varie
Système client Consommateur Consommateur Consommateur Varie

99
3.4. Choix du fournisseur de services de cloud public
▪ Si vous décidez d'utiliser un fournisseur cloud public, vous devez déterminer
celui que vous utiliserez.

▪ Vous devez tenir compte de différentes choses lors de l'évaluation des

différents types de fournisseurs.

▪ Nous couvrons par la suite certains des critères les plus importants.

100
Conseils pour choisir un fournisseur SaaS
▪ Les fournisseurs SaaS proposent différentes applications → Il faut évaluer à la fois
l'application et le fournisseur de services.
▪ Exemples de questions qu’il faut poser lors du choix d’un fournisseur SaaS:
▪ Comment serez-vous facturé?
▪ Des importations / exportations de données en masse peuvent-elles être effectuées?
▪ Comment les migrations de données sont-elles gérées?
▪ À quel point serait-il difficile de passer à un nouveau fournisseur si nécessaire?
▪ Découvrez la capacité dont vous disposerez pour personnaliser l'application.
▪ Découvrez les temps d'arrêt auxquels vous pouvez vous attendre. Quand la maintenance est-elle
planifiée?
▪ Quels SLA de performance et de disponibilité existent-ils? Quelles sont les sanctions en cas de
violation de ces SLA?
▪ Quel aperçu allez-vous acquérir sur ce qui se passe avec l'application et les données? Pouvez-
vous rassembler vos propres métriques? Faites votre propre surveillance?
101
Conseils pour choisir un fournisseur PaaS
▪ Bien que les fournisseurs PaaS puissent proposer différentes plates-formes,
vous pouvez obtenir la même plate-forme auprès de différents fournisseurs
▪ Exemples de questions qu’il faut poser lors du choix d’un fournisseur PaaS:
▪ Comment serez-vous facturé?
▪ Quel système d'exploitation, quelle plate-forme de développement et de base de
données le fournisseur propose-t-il?
▪ La plateforme est-elle compatible avec les applications et/ou services que vous souhaitez
fournir?
▪ Découvrez les temps d'arrêt auxquels vous pouvez vous attendre. Quand la maintenance
est-elle planifiée?
▪ Quels SLA de performance et de disponibilité existent-ils? Quelles sont les sanctions en
cas de violation de ces SLA?
▪ Quel aperçu allez-vous acquérir sur ce qui se passe avec l'application et les données?
Pouvez-vous rassembler vos propres métriques? Faites votre propre surveillance?
102
Conseils pour choisir un fournisseur IaaS
▪ Les fournisseurs IaaS proposent les mêmes plates-formes d'infrastructure
▪ La clé est de trouver un fournisseur qui offre un service qui vous plaît le plus.
▪ Exemples de questions qu’il faut poser lors du choix d’un fournisseur IaaS:
▪ Comment serez-vous facturé?
▪ Le fournisseur fournit-il tous les composants d'infrastructure dont vous avez besoin?
Aurez-vous besoin de les compléter d'une manière ou d'une autre?
▪ Quel aperçu allez-vous acquérir sur ce qui se passe avec l'application et les données?
Pouvez-vous rassembler vos propres métriques? Faites votre propre surveillance?
▪ Découvrez les temps d'arrêt auxquels vous pouvez vous attendre. Quand la maintenance
est-elle planifiée?
▪ Quels SLA de performance et de disponibilité existent-ils? Quelles sont les sanctions en
cas de violation de ces SLA?
▪ Comment les migrations de données sont-elles gérées?
103