Sécurité réseaux et virtualisation des systèmes PDF

UNIVERSITE HASSAN II ECOLE NATIONALE SUPERIEURE DES ARTS ET METIERS - CASABLANCA - Polycopié du module Sécurité des réseaux et Virtualisation des systèmes * * * Élément II...

UNIVERSITE HASSAN II ECOLE NATIONALE SUPERIEURE DES ARTS ET METIERS - CASABLANCA - Polycopié du module Sécurité des réseaux et Virtualisation des systèmes * * * Élément II : Virtualisation Filière : Cybersécurité et Cloud Computing (1ère année) Professeur : Mouaad Mohy-eddine Année universitaire : 2024 / 2025 Table des matières I. LA VIRTUALISATION................................................................... 3 1. INTRODUCTION................................................................................ 3 a. Principe de fonctionnement..................................................... 3 b. Virtualisation en pratique........................................................ 3 c. Les avantages........................................................................... 7 2. ARCHITECTURE DE LA VIRTUALISATION................................................. 7 a. Architecture native (Hyperviseur de type 1)............................. 7 d. Architecture invitée (Hyperviseur de type 2)............................ 7 3. METHODES DE VIRTUALISATION.......................................................... 8 a. Virtualisation complète............................................................ 8 b. Virtualisation partielle.............................................................. 8 4. FONCTIONNEMENT DES HYPERVISEURS................................................ 9 a. Le stockage............................................................................... 9 b. Le réseau.................................................................................. 9 5. PROBLEMES LIEES A LA VIRTUALISATION............................................. 12 a. VM Sprawl (Etalement des VMs)............................................ 12 b. VMs zoombie.......................................................................... 12 c. VM Orpheline......................................................................... 12 d. Solution................................................................................... 12 II. VIRTUALISATION DES CONTENEURS ET DOCKER...................... 13 1. INTRODUCTION.............................................................................. 13 2. DEFINITIONS IMPORTANTES............................................................. 13 a. Image...................................................................................... 13 b. Alpine Linux............................................................................ 13 c. DockerFile............................................................................... 13 d. Conteneur............................................................................... 14 e. Compose................................................................................. 14 f. Volume................................................................................... 14 g. Swarm Mode.......................................................................... 14 3. CONTENEURS VS MACHINES VIRTUELLES............................................ 14 4. AVANTAGES DE LA CONTENEURISATION.............................................. 15 III. REFERENCES............................................................................. 16 2 I. LA VIRTUALISATION 1. Introduction a. Principe de fonctionnement Le principe de base de la virtualisation est de séparer le système d’exploitation des ressources physiques. Des logiciels appelés hyperviseurs, sont spécialisés dans cette tâche (isoler les ressources physiques des environnements virtuels). Si on installe un SE sur une machine physique, ce SE est lié au hardware, même si on déplace le disque dur vers un autre serveur, ceci pourrait ne pas fonctionner. La virtualisation offre une couche entre le SE et le hardware, qui est l’hyperviseur, le SE devient une instance installée. Pourquoi c’est important ? Parce que si vous installez un autre serveur, vous avez l’option de déplacer le SE vers ce serveur. C’est le gain le plus important de la virtualisation. Le deuxième gain est qu’on peut installer plusieurs différents SE sur le même serveur. Donc au lieu d’avoir plusieurs serveurs pas chers, on peut avoir un seul serveur mais qu’il soit bon. Ces hyperviseurs peuvent fonctionner de deux manières : Reposer sur un système d'exploitation (ordinateur portable, par exemple) ou Etre directement installés sur un système physique (tel qu'un serveur).. Les hyperviseurs répartissent vos ressources physiques pour permettre aux environnements virtuels de les utiliser, ces environnements sont également appelés machines virtuelles ou hôtes. Ces ressources sont partitionnées à partir de l'environnement physique et distribuées aux différents environnements virtuels. Les utilisateurs interagissent avec ces environnements et y exécutent des calculs. La machine virtuelle opère comme un fichier de données unique. Comme n'importe quel fichier numérique, vous pouvez la transférer d'un ordinateur à un autre, l'ouvrir sur l'un ou l'autre et l'utiliser de la même manière. Lorsque l'environnement virtuel est exécuté et qu'un utilisateur ou un programme émet une instruction nécessitant des ressources supplémentaires à partir de l'environnement physique, l'hyperviseur transmet cette requête au système physique et met en cache les modifications. Le processus est presque aussi rapide que sur un système natif. b. Virtualisation en pratique En pratique, les ressources nécessitant le plus la virtualisation sont : les serveurs, les machines, les applications et les réseaux (un peu moins). Virtualisation des applications L’objectif de ce type de virtualisation est de pouvoir utiliser une application dans un système d'exploitation sans que cette application ne soit installée dedans. Les applications sont installées une seule fois dans le serveur, transformées en services virtuels administrés de façon centralisée, et envoyées autant de fois que nécessaires vers les machines, sans nécessiter d'installation sur ces dernières. 3 Pour ce faire, l’application doit être installée sur un serveur (de distribution d’application), puis un logiciel dit « App Receiver » doit être utilisé par la machine hôte pour recevoir et utiliser l’application localement. Pour cela, différents logiciels doivent être utilisés pour assurer la virtualisation des applications : Citrix XenApp, Microsoft AppV, VMware ThinApp, etc. La plupart du temps, ces logiciels envoient l’application sous la forme de pixels qui transitent entre le serveur et le client, et ce, en utilisant le protocole Remote Display Protocol. L’utilisateur peut donc utiliser l’application comme si elle était installé en locale sur sa machine, et chaque action qu’il effectue est transmise au serveur qui la traite et rafraichit l’interface de l’application. Les avantages de la virtualisation des applications sont : Les administrateurs du parc informatique installent les applications une seule fois. Les mises à jour sont appliquées à une seule application et ne sont donc pas compliquées. La gestion des droits utilisateur est centralisée. Isoler l’application distante des applications locales, ce qui permet d’éviter les incompatibilités. Les applications ne sont pas accessibles uniquement par un périphérique ou par un seul système d’exploitation. Les inconvénients de la virtualisation des applications sont : Les applications très chargées en composants graphiques peuvent ne pas fonctionner correctement comme application virtuelle. L’accès aux périphériques de la machine hôte n’est pas toujours garantie du moment que l’application s’exécute sur le serveur. La virtualisation des applications peut se faire via différentes techniques : Le mode virtual Locally installed Applications : Ce mode installe les applications en local, mais les isole du système d’exploitation de telle sorte à laisser le dossier c:\windows\system32 (exemple) propre et à mettre les fichiers nécessaires dans des dossiers nommés c:\app1\windows\system32 et c:\app2\windows\system32. Ainsi chaque application est isolé dans un environnement séparé. Le mode streaming : au niveau du serveur, l’application est installée et une fois l’application installée, son profil est enregistré dans ce qu’on appelle profil, ce profil sera envoyé entièrement à la machine hôte, collé dans un cache local et exécuté comme 4  si l’application est installée localement. Tout ce qui est nécessaire au fonctionnement de l’application est transféré à la demande depuis le serveur vers la machine hôte, une fois l’application fermée, les fichiers sont supprimés. On peut changer ce comportement si on souhaite garder les fichiers en local et d’éviter de les « streamer » à chaque nouvelle utilisation. Le mode en pixel : l’application ne s’exécute pas localement et ne consomme pas les ressources locales de la machine hôte, le serveur délivrent les pixels de l’application via un canal vers la machine hôte, et c’est ainsi que l’utilisation est effectuée. Virtualisation des postes de travail De la même manière que la virtualisation des applications permet l’utilisation des applications sans les avoir installées auparavant sur les machines hôtes, la virtualisation des postes de travail permet d’utiliser tout un poste de travail (Système d’exploitation et application nécessaires). Les machines clientes sont utilisées comme une fenêtre d’accès distant à un poste de travail hébergé dans un serveur de virtualisation. Le poste de travail est transmis à la demande à l’utilisateur soit en mode pixel ou en streaming selon le paramétrage du serveur et la configuration matérielle et logicielle de la machine cliente. Virtualisation de serveurs Les serveurs sont des ordinateurs conçus pour traiter un volume élevé de tâches spécifiques afin de permettre aux autres ordinateurs d'effectuer diverses autres tâches. La virtualisation d'un serveur permet d'optimiser l'exécution de ces fonctions spécifiques et implique son partitionnement, de sorte que les composants puissent être utilisés pour exécuter différentes fonctions. 5 Virtualisation des machines (ou de systèmes d’exploitation) La virtualisation des systèmes d'exploitation intervient au niveau du noyau, qui correspond au gestionnaire de tâches central de ces derniers. Cette approche permet notamment d'exécuter des environnements Linux et Windows côte à côte. Les entreprises peuvent également transférer les systèmes d'exploitation virtuels vers des ordinateurs, ce qui présente les avantages suivants : Réduction des coûts de matériel, étant donné que les ordinateurs ne nécessitent pas un nombre élevé de fonctionnalités prêtes à l'emploi Renforcement de la sécurité grâce à la possibilité de surveiller et d'isoler les instances virtuelles Réduction du temps consacré aux services informatiques, tels que les mises à jour de logiciel. Virtualisation des (fonctions) réseaux La virtualisation des fonctions réseau sépare les fonctions clés d'un réseau (telles que les services d'annuaire, le partage de fichiers et la configuration des adresses IP) afin de les répartir entre les différents environnements. Lorsque les fonctions logicielles sont indépendantes des machines physiques sur lesquelles elles étaient hébergées, il est possible de regrouper des fonctions spécifiques dans un nouveau réseau et de les assigner à un environnement. La virtualisation des réseaux réduit le nombre de composants physiques nécessaires à la création de plusieurs réseaux indépendants, tels que les commutateurs, les routeurs, les serveurs, les câbles et les hubs. Elle est particulièrement répandue dans le secteur des télécommunications. 6  c. Les avantages Gestion du load balancing Migration de tout un système d’exploitation comme étant un seul fichier Allocation statique de la mémoire Allocation dynamique de la mémoire 2. Architecture de la virtualisation Il existe deux architectures de virtualisation : a. Architecture native (Hyperviseur de type 1) L’hyperviseur de type 1 est un système qui s’installe directement sur la couche matérielle du serveur. Ces systèmes sont faits pour être très légers, de manière à se « concentrer » sur la gestion des systèmes d’exploitation invités c'est-à-dire ceux utilisés par les machines virtuelles qu’ils contiennent. Ceci permet de libérer le plus de ressources possible pour les machines virtuelles. Les hyperviseurs de type 1 les plus connus sont : Xen server, Oracle VM, Microsoft Hyper-V, VMware ESXi, Proxmox. d. Architecture invitée (Hyperviseur de type 2) 7 Un hyperviseur de type 2 est un logiciel qui s’installe et s’exécute sur un système d’exploitation déjà en place. De ce fait, plus de ressources sont utilisées étant donné qu’on fait tourner l’hyperviseur et le système d’exploitation qui le supporte, il y a donc moins de ressources disponible pour les machines virtuelles. L’intérêt qu’on peut trouver c’est le fait de pouvoir exécuter plusieurs hyperviseurs simultanément vu qu’ils ne sont pas liés à la couche matérielle. Les hyperviseurs de type 2 les plus connus sont : VMware Player, VMware Workstation, VirtualPC et VirtualBox. 3. Methodes de virtualisation Il existe deux méthodes de virtualisation : a. Virtualisation complète Les hyperviseurs de type 2 utilisent cette méthode. Cette méthode permet d’exécuter tout OS (invité) sans modifier l’OS de l’hôte. Les hyperviseurs se comportent comme des émulateurs du matériel. Des logiciels simulent donc les pilotes (drivers) des différents périphériques (cartes réseau, disque SATA, processeur…). Les systèmes invités, les VM, ne dialoguent jamais directement avec le matériel réel mais avec l’émulateur. On peut même dire que les VMs ne savent pas qu’elles sont virtualisées. Il est important de préciser que tous les OS ne sont pas vraiment utilisables avec cette technique. Mais les Linux ou BSD ainsi que Windows fonctionnent en virtualisation. Les produits de virtualisation complète sont les plus connus du grand public : VMware Player VirtualBox (Oracle) VirtualPC (Microsoft) QEMU b. Virtualisation partielle Utilisée par les hyperviseurs de type 1. L’OS invité a parfaitement conscience qu’il est virtualisé. La différence avec la virtualisation complète permet alors d’optimiser le système pour la virtualisation. Ceci implique de pouvoir modifier le noyau, ce qui ne pose pas véritablement de problème avec les systèmes Linux ou BSD du fait de l’orientation open source, mais qui n’est pas envisageable avec les OS de type Windows. Les hyperviseurs de type 1 les plus connus sont : KVM XEN, XenServer VMware ESX Hyper-V (Microsoft) 8 La virtualisation partielle permet des performances accrues. Si la modification du noyau pour la virtualisation est possible, alors l’accès au matériel est quasi identique par rapport au système natif. À ce jour, c’est la solution Xen qui est la plus performante sur le sujet, mais les acteurs comme VMware et Microsoft ne sont pas en reste. 4. Fonctionnement des hyperviseurs a. Le stockage Le stockage des VMs sur le disque de l’hôte peut se faire de différents modes : Stockage par fichiers C’est la méthode la plus courante et aussi la plus simple à configurer. Le disque dur de la VM est contenu dans un simple fichier disque. La taille de ce fichier définit la dimension du disque dur de la VM. Il est possible d’utiliser deux types de fichiers : Fichier plein ou complet ; Fichier à trou (sparse file) ou encore alloué dynamiquement. Stockage Managé Cette fonctionnalité est bien connue des administrateurs Linux. LVM permet la modification d’un système de fichiers de manière dynamique, à chaud et sans perte. Appliqué au stockage des VM, il permet l’agrandissement du disque dur de manière souple. Stockage partagé Lors de la mise en place d’une plate-forme de production de virtualisation, c’est la solution la plus intéressante. Dans ce type de configuration, les disques des VM sont accessibles par tous les hôtes de virtualisation. Grâce à ce principe, la migration à chaud des VM d’un hôte vers un autre est très facile. Mettre en place un stockage partagé peut être simple. Le protocole NFS (Network File System) utilisé sous Unix depuis sa création est une solution. b. Le réseau Il s’agit d’un autre point important à considérer lors de la création d’une VM. Il existe plusieurs possibilités : NAT Routage Bridge ou pont Réseau privé Le choix dépend de ce que l’on souhaite faire avec les VM. NAT Le principe du NAT (Network Address Translation) est de faire correspondre le plus souvent des adresses internes non routables (192.168…) vers une ou des adresses routables. Son mode de fonctionnement est quasiment identique à celui du routage, sauf que les IPs des VMs ne sont 9 pas accessibles de l’extérieur. Le NAT est très utilisé pour partager une connexion Internet pour laquelle il n’existe qu’une adresse IP publique. Le NAT permet de faire un réseau isolé pouvant communiquer avec l’extérieur (principe de passerelle). Le mode NAT est ce qui est par défaut configuré sue la plupart des hyperviseurs. C’est aussi le plus simple à gérer au niveau réseau car la configuration de l’hôte est nulle. Routeur Le principal atout du mode routeur pour les VM est que celles-ci, bien qu’étant dans un réseau différent de l’hôte, restent accessibles de l’extérieur. Le schéma est quasi identique au mode NAT sauf au niveau de la configuration. 10 Le bridge Un bridge (ou pont) est un équipement matériel qui permet d’interconnecter deux réseaux physiques. Le pont travaille au niveau 2 du modèle OSI (un routeur travaille au niveau 3). Le transfert des paquets est effectué suivant l’adresse Ethernet (adresse MAC) et non avec l’adresse IP. Un pont peut être vu comme une sorte de hub ou de switch virtuel. La conséquence directe de la configuration en bridge est que les IP des VM et de l’hôte sont dans le même sous- réseau. 11 Le mode bridge est très souvent utilisé afin que les VM soient vues par les clients comme des serveurs physiques. Réseau privé Ce mode permet de complètement isoler de l’hôte un réseau de VM. Il n’y a donc plus aucune communication entre les VM et le réseau local. Ce mode de fonctionnement est très intéressant pour simuler un réseau local entre plusieurs VM. Il se rapproche du schéma du NAT sauf que les VM ne peuvent pas communiquer avec l’extérieur. 5. Problèmes liées à la virtualisation a. VM Sprawl (Etalement des VMs) La technologie de virtualisation est simple, peu coûteuse et efficace. Mais parce que c'est si facile, cela peut devenir un peu incontrôlable. Dans le monde des serveurs physiques, il existe des contraintes intégrées pour lutter contre l'étalement (budget pour acheter un nouveau serveur, délai de livraison, place dans le Datacenter, alimentation, refroidissement, connexion). En fin de compte, nos centres de données ne disposent que d’une capacité limitée en termes d’espace, d’alimentation, de refroidissement et d’accès réseau. Dans le monde virtuel, besoin d'un nouveau serveur ? Il suffit de cloner l’un de vos serveurs existants sans se soucier des problèmes d’infrastructure. b. VMs zoombie Le VM Sprawl peut conduire à la création de différentes VMs, de test, de recette, etc. Sans une procédure de gestion des VMs, ces machines peuvent être oubliées dans les serveurs physique et deviennent des VMs zoombies. Une VM zoombie est une VM qui consomme des ressources, mais personne ne sait vraiment pourquoi. On ne peut pas la supprimer car on ne sait pas pourquoi elle a été créée, surtout si celui qui l’a créée n’est plus là. c. VM Orpheline En réalité, une VM orpheline est une VM dont les fichiers existent encore, même la machine virtuelle à laquelle ils étaient attachés a été supprimée. C’est un espace perdu sans doute, mais il peut être un peu difficile à repérer. d. Solution Des outils de gestion des VMs existent. Toutes les principales applications de gestion de la virtualisation aident à identifier et à gérer l’étalement des machines virtuelles. Choisissez-en un qui soit facile à utiliser, optimise vos ressources et fournit une vue globale des éléments de calcul, de stockage, de réseau et d’applications de votre centre de données virtuel. Quelques uns de ces outils sont : RV Tools from Robware.net (free) PowerShell from Microsoft (free) Citrix Essentials from Citrix (paid/free) vControl from Vizioncore (paid) 12 II. VIRTUALISATION DES CONTENEURS ET DOCKER 1. Introduction Docker permet la mise en œuvre de conteneurs s’exécutant en isolation, via une API (interface utilisateur). Construit sur des capacités du noyau Linux (surtout les cgroups et espaces de nommage), un conteneur Docker, contrairement machines virtuelles traditionnelles, ne requiert aucun système d’exploitation séparé et n’en fournit aucun. Il s’appuie plutôt sur les fonctionnalités du noyau et utilise l’isolation de ressources (comme le processeur, la mémoire, les entrées et sorties et les connexions réseau) ainsi que des espaces de noms séparés pour isoler le système d’exploitation tel que vu par l’application. Docker accède aux capacités de virtualisation du noyau Linux, soit directement à travers la bibliothèque runc (disponible depuis Docker 0.9), soit indirectement via libcrt, LXC (Linux Containers) ou systemd-nspawn. Le systemd-nspawn est comme la commande chroot sur Linux mais en plus puissante. Il peut être utilisé pour rentrer une commande ou un OS dans un espace léger tel un conteneur. Il peut complètement virtualiser la hiérarchie des fichiers systèmes, comme l’arborescence des processus.) Utiliser Docker pour créer et gérer des conteneurs peut simplifier la mise en œuvre de systèmes distribués en permettant à de multiples applications, tâches de fond et autres processus de s’exécuter de façon autonome sur une seule machine physique ou à travers de multiples machines isolées. Ceci permet de déployer des nœuds en tant que ressources sur besoin, fournissant ainsi une plateforme de déploiement de style PaaS. 2. Définitions importantes a. Image Une image Docker représente le système de fichiers sans les processus. Cette image contient ce que vous avez décidé d’installer (tel qu’une base de donnée (MySQL), Java, PHP, un script, etc…) mais en étant inactif. Elles sont créées à partir de fichiers de configuration « Dockerfiles ». Dockerfiles décrie exactement ce qui doit être installé sur le système, le conteneur est l’exécution d’une image. b. Alpine Linux Alpine Linux est une très simple distribution Linux et d’une faible taille (5MB seulement, un conteneur de 8MB est requis pour l’installation et 130MB de stockage sur votre disque). Cette distribution est fréquemment utilisée par les utilisateurs de Docker. c. DockerFile C’est votre fichier source qui donne une image une fois qu’il est compilé. Il peut être inclus dans un autre Dockerfile et être à la base de plusieurs images différentes. Vous avez le choix d’utiliser des images officielles ou des images modifiées présentes sur le Docker Hub (https://hub.docker.com/ ) ou, si vous le souhaitez, de personnaliser vos propres images en écrivant un Dockerfile. 13  d. Conteneur Comme dit précédemment, un conteneur Docker n’a besoin d’aucun système d’exploitation séparé. Il se sert de fonctionnalités du noyau du système d’exploitation. Ainsi il utilise l’isolation de ressources. (CPU, mémoire, I/O, connexions réseau etc…). e. Compose C’est un outil qui permet de définir et exécuter des applications multi-conteneurs. Les conteneurs sont idéaux pour des applications pour de simple micro services. C’est pour cela qu’il est idéal de faire une interconnexion entre plusieurs conteneurs. L’exemple le plus parlant et celui d’un serveur web contenant les service php, mysql et nginx dans des containers différents. f. Volume C’est le mécanisme le plus adapté pour la persistance des données qui sont générés et utilisées par les conteneurs de Docker. Les volumes de Docker ont différents avantages tels qu’une simplicité de sauvegarde ou de migration ou encore leurs gestions facilités grâce aux outils et commandes Docker. g. Swarm Mode Le mode Swarm indique à Docker que vous exécuterez de nombreux containeurs Docker et que vous souhaitez coordonner les opérations entre eux. Le mode Essaim combine la possibilité de définir non seulement l’architecture de l’application, comme Composer, mais aussi de définir et de maintenir des niveaux de haute disponibilité, la mise à l’échelle, l’équilibrage de charge, etc. Avec toutes ces fonctionnalités, le mode Swarm est plus souvent utilisé dans les environnements de production que Compose. 3. Conteneurs VS machines virtuelles Après avoir découvert ce qu’est DOCKER, on peut se demander quelle est la différence entre les conteneurs et les machines virtuelles, car à première vue, cela se ressemble fortement. Les machines virtuelles et les conteneurs diffèrent de plusieurs façons. La principale différence est liée à l’architecture logiciel de ceux-ci. La machine virtuelle, elle est composée d’un OS host sur lequel est exécuter un hyperviseur comme Hyper-V sous Windows ou KVM sous Linux. L’hyperviseur lui va virtualiser le « Guest OS » ou le système d’exploitation invité tout en virtualisant également la matériel et périphérique présent sur une station de travail classique comme par exemple la RAM, le CPU… Le container lui fonctionne toujours sur un OS host mais utilise le moteur Docker (Docker Engine) pour interagir et utilisé les fonctionnalités du noyau linux, les librairie et bibliothèque sont partager et donc utilisé par les différents containers hébergeant les applications. Les containers sont donc plus polyvalents et performants que des VMs. Les containers Docker peuvent démarrer en quelques secondes et s’arrêter aussi rapidement. 14 4. Avantages de la conteneurisation Les conteneurs sont particulièrement utiles pour développer, déployer et tester des applications distribués modernes et micro-services pouvant fonctionner dans des environnements d'exécution isolés sur les mêmes machines hôtes. Avec la conteneurisation, les développeurs n'ont pas besoin d'écrire du code dans différentes VMs. Les conflits des bibliothèques ou des composants ne se produisent pas lors de l'exécution et le conteneur d'applications peut être déplacé efficacement entre les instances de cloud ou de centre de données. La différence architecturale offre les propositions de valeur clés suivantes pour le personnel informatique et les entreprises : L’intégration continue, le déploiement et les tests : dans les organisations dirigées par DevOps, les organisations peuvent utiliser des conteneurs pour faciliter les processus du pipeline CI/CD. Les conteneurs fonctionnent comme un environnement d’infrastructure cohérent, de sorte que les développeurs n’ont pas besoin de tâches de configuration complexes pour chaque sprint, les charges de travail migrant entre les ressources physiques. Portabilité de la charge de travail : les charges de travail informatiques peuvent basculer entre différentes instances d'infrastructure et environnements virtuels sans modification importante de la configuration ni modification du code de l'application. Qualité et conformité logicielles : une collaboration transparente entre les développeurs et le personnel chargé des tests pour la fourniture des blocs d'exploitation de l'application entraîne une meilleure qualité logicielle, des cycles de développement plus rapides et une conformité améliorée. Optimisation des coûts : les conteneurs optimisent l'utilisation des ressources dans leurs propres environnements virtualisés isolés. Cela permet aux organisations de planifier avec précision la capacité et la consommation de l'infrastructure. Infrastructure agnostique: les conteneurs rendent les composants de l'application agnostiques, permettant aux entreprises de déplacer des charges de travail entre serveurs neutres vers des environnements virtualisés vers une infrastructure cloud en réponse aux besoins changeants de l'entreprise. 15 III. RÉFÉRENCES http://www.virtu-desk.fr/medias/files/syntecle-livre-blanc-du-cloud-computing.pdf https://www.it-connect.fr/les-types-dhyperviseurs/ https://searchnetworking.techtarget.com/feature/Top-five-virtualization-problems- VM-Sprawl https://searchservervirtualization.techtarget.com/tip/Top-10-virtualization- management-tools https://www.bmc.com/blogs/containers-vs-virtual-machines/ 16