Contexte

L’affichage de ce blog était relativement lent. Il pouvait mettre plus de 5 secondes pour s’afficher complètement ce qui n’est pas un temps d’affichage très bon. J’ai donc entrepris de trouver une solution à ce problème.

Ce site est hébergé sur une machine virtuelle Xen dont le système d’exploitation est OpenSolaris 2009.06. Elle est globalement assez lente car relativement peu de mémoire lui est alloué. De plus, la cohabitation d’Apache et de MySQL sur le même système ne favorise clairement pas les choses. Certains médisants diront que WordPress et/ou PHP sont des facteurs de lenteur. Ils auront raison mais je n’ai aucune intention d’utiliser autre chose que WordPress car c’est un réel plaisir à l’utiliser.

Un peu de théorie

Un proxy ou en Français « serveur mandataire » est un serveur qui se place entre le client et le serveur. Le client va interroger le proxy qui va à son tour interroger le serveur. Le serveur répondra au proxy qui, à son tour, répondra au client. Ceci est le fonctionnement le plus classique mais on peut placer un proxy dans nombreuses configurations et donner au proxy une intelligence supplémentaire.

Dans le cas de proxys HTTP(S) classiques, on y ajoute des mécanismes de cache afin d’économiser de la bande passante. On peut également y ajouter des fonctions de filtrage d’URL afin d’éviter la consultation de certains sites.

L’exemple d’application du proxy qui nous intéresse ici est le reverse proxy. Le client n’aura aucune connaissance de la présence d’un proxy et pensera qu’il s’agit d’un serveur HTTP comme un autre. Le proxy interrogera ensuite le serveur web et la requête sera renvoyée au client. Dans cette situation, la fonctionnalité de cache du proxy est très intéressante car elle permet d’éviter le traitement de certaines requêtes au serveur HTTP. On pourrait également utiliser le proxy couplé à plusieurs serveurs HTTP afin d’effectuer du load balancing et de la redondance.

Une autre VM

La première étape a été de trouver une machine supplémentaire afin de ne pas faire cohabiter la pile LAMP et Squid sur le même serveur. Dans l’absolu, ce n’est pas impossible mais lorsqu’on a un serveur déjà surchargé, ce n’est peut être pas la meilleure idée.

Étant donné qu’OVH vient de lancer son offre miniCloud, ce projet était une parfaite excuse pour la tester. Le prix de cette offre est vraiment très bas. Pour une VM de 256Mo de RAM, cela revient à 8,5€/mois. J’ai donc crédité 10€ sur mon compte. L’interface de gestion n’est pas la plus esthétique ni la plus rapide mais elle fait l’affaire.

En une petite dizaine de minutes, j’avais donc à ma disposition une machine virtuelle Debian Lenny 64-bits. Le réel inconvénient de l’offre d’OVH est que l’IP de la machine virtuelle change à chaque fois que vous l’arrêtez par le biais de l’interface de gestion.

L’installation de la pile LAMP est très simple et je ne la détaillerai donc pas ici. Il existe des masses incroyables de documentation à ce sujet.

Squid

L’installation de Squid est très simple. Je l’ai installé sur OpenSolaris à partir des dépôts Blastwave via pkgutil. Dans le cas de Debian, un apt-get s’occupera de tout ca pour vous.

Une fois installé, nous pouvons passer à sa configuration. La configuration du reverse proxy est la suivante :

http_port 80 accel defaultsite=www.antoinebenkemoun.fr
visible_hostname vm.antoine.fr
cache_peer 178.32.yy.xx parent 80 0 no-query originserver name=myAccel
acl all src 0.0.0.0/0.0.0.0
cache_peer_access myAccel allow all
acl our_sites dstdomain antoinebenkemoun.fr www.antoinebenkemoun.fr antoinebenkemoun.com www.antoinebenkemoun.com
http_access allow our_sites

Tout d’abord, on indique à Squid d’écouter les requêtes sur le port 80 et que le site que l’on va proxy-er est « www.antoinebenkemoun.fr ». Ensuite, on lui indique l’IP du serveur web où est réellement hébergé le site. Il est ensuite nécessaire de définir un certain nombre d’ACL qui sont ici assez génériques et tout à fait simples. Dans l’exemple, nous avons autorisé le reverse proxy pour 4 sites et nous avons autorisé toutes les IP à visionner le site.

Il est également possible d’utiliser d’autres options afin de mieux régler votre reverse proxy. L’ajout d’un « access log » va vous permettre de voir les pages qui sont consultés mais surtout si le contenu est envoyé par Squid ou par votre serveur LAMP. Il est également possible de régler la quantité de mémoire vive utilisé pour le cache de pages web. L’espace mémoire utilisé pour le cache sera donc alloué en plus de l’espace mémoire du programme principal.

cache_mem 20 MB
cache_access_log /opt/csw/var/logs/access.log

Le chemin pour l’access log est adapté à mon OpenSolaris mais à vous de l’adapter à votre distribution. Si vous êtes sur Linux, vous voudrez surement placer les logs quelque part dans /var/log/.

Au final, nous avons installé notre serveur Squid et l’avons configuré en mode reverse-proxy. Dans le billant suivant, nous verrons les modifications qu’il faut apporter à notre serveur Apache afin d’utiliser réellement la fonctionnalité de cache du reverse proxy.

Dans les billets précédents, l’objectif avait été de proposer quelques ajustements vis à vis de la conférence sur la sécurité de la virtualisation lors de la Nuit de Hack. Ces articles s’étaient donc voulus plutôt rassurants cependant il est nécessaire de mitiger ce portrait. Les risques liés à la sécurité de la virtualisation existent bien. Affirmer le contraire serait au mieux une vulgaire erreur.

Nous allons aujourd’hui nous intéresser aux vulnérabilités qui ont déjà été trouvées dans des produits de virtualisation et leurs implications.

Xen

Nous allons premièrement nous intéresser au produit Xen open source. Le produit Citrix est un produit hybride s’inspirant largement du produit open source mais disposant de nombreuses modifications qui dépassent le périmètre de ce dernier. La conception de Xen se veut sécurisée par le biais, notamment, de l’utilisation des différents anneaux de protection système. Son histoire n’est cependant pas exempte de vulnérabilités.

La plus grosse vulnérabilité de Xen date de Septembre 2007. Il s’agissait d’une faille qui permettait à un domU d’exécuter des commandes dans le dom0 lors de l’utilisation de l’outil pygrub. L’outil pygrub permet à un domU de disposer d’un bootloader similaire à celui que l’on peut trouver sur une machine physique classique. Cette faille est extrêmement problématique dans la mesure où le dom0 est un domaine exceptionnellement sensible qui dispose de très nombreuses interactions directes avec le matériel et l’hyperviseur. Vous pourrez trouver plus d’informations sur cette faille sur l’OSVDB.

D’autres vulnérabilités ont été trouvées dans Xen permettant à un domU de sortir de son isolation. La plupart de ces failles nécessitent des conditions très particulières afin d’être exploitables ou ne permettent au mieux qu’un DoS local. La liste des failles est disponible sur l’OSVDB.

VMWare

Nous allons ensuite nous intéresser au produit VMWare. La liste des vulnérabilités pour ce produit est nettement plus longue avec un net pic en 2008. Le plus grand nombre de vulnérabilités s’explique surement en partie par la grande étendue des produits VMWare qui incluent aussi bien l’hyperviseur que tous les outils de gestion associés (Virtual Center, Service Console, …).

Parmi toutes ces vulnérabilités, on en recense 4 qui permettent une violation de l’isolation des machines virtuelles. Ces élévations de privilèges se font à travers les VMWare Tools quant il s’agit de machines virtuelles ou à travers les produits connexes à l’hyperviseurs.

Conclusion

Les produits de virtualisation ne sont clairement pas exempts de vulnérabilités quoi que l’on puisse dire. L’impact d’une vulnérabilité sur une plateforme de virtualisation sera largement plus important par rapport à une architecture classique. Il est cependant nécessaire de nuancer ces propos. De nombreuses mesures sont prises afin d’éviter que ces vulnérabilités puissent avoir un impact quelconque sur le reste de la plateforme. De plus jusqu’à présent, l’impact des failles de sécurité est relativement minime et leur fréquence plutôt faible. Il convient donc de rester vigilant aux évolutions des plateformes de virtualisation en matière de sécurité.

Pour en savoir plus, je vous conseille la présentation de Julien Raeis et Nicolas Collignon à ce sujet. Les deux tableaux récapitulatifs présents dans cet article sont extraits de cette présentation.

La sécurisation du stockage

La virtualisation n’ajoute pas de risque particulier à partir du moment où l’on suppose que l’attaquant dispose d’un accès physique aux données. Ce type d’exploit est donc uniquement inhérent au stockage sur disque.

Les réseaux de stockage en Fibrechannel n’ajoutent également pas de risque particulier. Seul les hyperviseurs ont accès aux supports de stockage distribués par le réseau de stockage. De plus, il est possible de gérer finement les accès aux différents supports de disque par les biais des techniques de « zoning ». Le zoning est une technique équivalente aux « Private VLAN » de Cisco dans le cas des réseaux Ethernet.

Contrairement à ce qui a été présenté Samedi dernier, la connexion des équipements Fibrechannel au réseau Ethernet n’ouvre pas de faille supplémentaire. Il n’est pas possible d’utiliser cette interface pour accéder aux données transitant sur le réseau de stockage. L’interface Ethernet permet uniquement d’accéder aux informations de configuration du commutateur.

Supposons qu’il soit possible d’accéder aux données transitant sur le réseau Fibrechannel par le biais de cette interface Ethernet. Toute tentative de spoofing d’adresse MAC serait parfaitement inutile car les réseaux Fibrechannel n’utilisent pas d’adresses MAC mais des WWN qui n’ont rien à voir. Les protocoles de communication sont différents et ne sont pas compatibles.

Cette problématique est cependant intéressante dans le cas des réseaux iSCSI qui n’ont même pas été mentionnés. Il n’est absolument pas souhaitable que les LAN iSCSI soient routables vers d’autres réseaux. Il est même recommandé d’avoir des équipements uniquement dédiés aux fonctionnalités iSCSI dans la mesure du possible.

Récapitulons…

Les potentielles interfaces d’attaque vers les hyperviseurs sont très peu nombreuses. Dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, ces interfaces sont même inexistantes. Dans le cas des interfaces de paravirtualisation, leur utilisation est standardisée par le biais d’API mais la découverte de failles reste envisageable bien qu’aucune n’ait été trouvée à ce jour.

Les mécanismes de DoS sont régulés voire supprimés par les mécanismes classiques d’ordonnancement présents dans toutes les solutions de virtualisation.

Quels sont les risques ?

Les risques réels de sécurité inhérents aux plateformes de virtualisation se situent, d’une part, au niveau des interface de gestion. Les interfaces de gestion ne sont pas propres à la virtualisation mais leur utilisation dans ce cas particulier est généralisé.

L’accès aux interfaces de gestion doivent être sécurisés par les mécanismes réseau traditionnels ainsi que par le biais de méthodes d’authentification. Dans le cas d’une compromission de ces interfaces, les données et l’accès aux machines virtuelles reste indemne. Les interfaces ne disposent généralement pas d’accès particulier aux données, elles disposent uniquement d’une vue globale permettant la configuration des supports de stockage. En ce qui concerne l’accès aux VM, il reste protégé par les protections classiques telles que le couple login et mot de passe. Le passage dans des modes plus privilégiés attireraient inévitablement l’attention car cela nécessiterait des redémarrages non planifiés.

Conclusion

Traditionnellement, on considère qu’une technologie est sécurisée jusqu’à preuve du contraire. Il n’est pas utile de céder au sensationnalisme en décriant des potentielles failles qui n’ont pas été découvertes et qui n’ont jamais été exploitées (dans le cas de Xen).

Si nous suivons cette supposition traditionnelle, nous pouvons affirmer que la virtualisation est une technologie sécurisée. Comme toute technologie informatique, il est nécessaire d’être vigilant lors de son implémentation en suivant quelques règles de bon sens.

Pour revenir au sujet de la présentation effectué lors de la nuit du hack, j’ai été largement déçu par cette présentation aux conclusions au mieux hâtives et des nombreuses autres imprécisions que je n’ai pas évoqué ici.

Une présentation a particulièrement attiré mon attention mais pas pour de bonnes raisons. En fin de soirée avait lieu une conférence intitulé « Virtualisation et sécurité ». J’attendais donc avec impatience cette conférence. Autant dire que cela a été une grande déception. Le sujet était traité d’un point de vue beaucoup trop global mais, surtout, les informations soutenues étaient plus que discutables.

Je vais donc profiter de cette espace pour tenter d’éclaircir certains points par rapport à la sécurité de la virtualisation.

Classification

Avant de plonger dans l’étude à proprement dit de la sécurité dans la virtualisation, il est intéressant de se replonger dans la classification des solutions. Lors de la présentation, il avait été différencié les types de virtualisation suivants : « full virtualisation », « paravirtualisation » et « hyperviseurs ».

Un hyperviseur n’est pas un type de virtualisation mais une application qui peut effectuer de la virtualisation. Il est possible de les classifier selon deux catégories bien que cette division ne me plaise pas particulièrement.

La sécurisation de l’hyperviseur : DoS & DDoS

Lors de la présentation, le DoS (Denial of Service) et le DDoS (Distributed Denial of Service) ont été désignés comme des solutions simples et efficaces de neutraliser une plateforme de virtualisation.

Dans le cas de Xen, il est pratiquement impossible de communiquer avec l’hyperviseur. Il ne faut bien sur par confondre hyperviseur et domaine 0 (ou console de gestion dans le cas de VMWare). L’attaque DoS est donc difficile à imaginer dès le départ. L’interface de communication avec l’hyperviseur dont nous disposons est l’API des hypercalls, remplaçants des appels systèmes classiques dans le cas de la paravirtualisation.

L’utilisation des ces hypercalls est limitée par les algorithmes d’ordonnancement système ce qui empêche une utilisation abusive. Il s’agit du même mécanisme que celui utilisé pour le partage des ressources physiques. Le DoS semble donc impossible par ce biais.

Les outils d’administration sont également un potentiel point d’entrée supplémentaire. Ces outils ne sont accessibles qu’à partir du domaine 0 qui peut difficilement être considéré en tant que VM comme les autres. Un attaque DoS sur le domaine 0 rendrait les mêmes résultats qu’une attaque DoS sur les autres machines virtuelles étant donné les mécanismes d’ordonnancement.

La communication avec l’hyperviseur n’étant possible que par ces interfaces, il parait impossible d’y effectuer une attaque DoS capable d’atteindre toutes les machines virtuelles de la plateforme.

La sécurisation de l’hyperviseur : cloisonnement

Le cloisonnement des machines virtuelles est bien sûr une caractéristique élémentaire d’une plateforme de virtualisation. Contrairement à ce qui a été dit, l’hyperviseur n’a pas « la main » sur les machines virtuelles. Il a simplement la possibilité de les éteindre, de les démarrer ou de les mettre en pause. Ni plus, ni moins.

Le cloisonnement est géré par la restriction des accès mémoire. Les hyperviseurs ont été spécifiquement prévus afin d’éviter un débordement des accès vers la mémoire. Le seul vecteur d’exploitation de ce type de faille est les hypercalls dans le cas de Xen. A ce jour aucune faille connu permet d’accéder à des zones mémoires non autorisées.

De plus dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, les machines virtuelles ne disposent même pas d’interface spécifique avec l’hyperviseur ce qui rend pratiquement impraticable de ce type de vulnérabilité.

Les risques d’erreur de cloisonnement ne sont pas inexistants bien entendu cependant il ne faut pas perdre de vue qu’il s’agit de l’objectif même de la conception de l’hyperviseur et que les machines virtuelles disposent de très peu ou aucune interface de communication avec l’hyperviseur afin de l’induire en erreur.

Dans le prochain (et dernier épisode), nous étudierons les autres points abordés lors de la présentation et les risques réels associés à la virtualisation. Loin de moi l’idée de prêcher la sécurisation totale de la virtualisation, je pense cependant qu’il est très facile et réducteur d’agiter des menaces sans fondement pratique.

Notion de duplication

La notion de duplication de données est relativement simple. Prenons un jeu de données, la duplication de ces données donne un second jeu identique de données mais sur un autre espace de stockage. Il est possible de faire de la duplication dans le cas de la copie de disques ou de DVD par exemple. Il est également intéressant de faire de la duplication de données dans le cas de la virtualisation. Lorsque des machines virtuelles sont « provisionnées » ou bien, plus simplement, créées, une technique envisageable est la duplication d’une machine virtuelle « template ».

Dans le cas de la virtualisation, de nombreuses données sont présentes en plusieurs exemplaires. Sur une plateforme de virtualisation, il va être exécuté un certain nombre de systèmes d’exploitation. Un serveur de virtualisation standard aujourd’hui est capable d’exécuter 20 à 30 machines virtuelles. Supposons que ces machines virtuelles disposent de 2-3 systèmes d’exploitation différents, cela implique que 7 à 15 copies du même système d’exploitation vont être stockées.

Définition de la duplication

La déduplication va nous permettre de solutionner en grande partie ce problème. Cette technique a pour objectif de supprimer les doublons/triplons/etc du support de stockage afin de stocker qu’une seule copie des données. Il est possible d’implémenter cette technique à plusieurs endroits et à plusieurs niveaux. Prenons tout d’abord l’exemple de la mémoire vive et ensuite, l’exemple des disques.

Déduplication de la mémoire vive

La mémoire vive est un support de stockage d’information particulièrement couteux. Nous avons donc tout intérêt à en optimiser son utilisation. L’exemple que nous avons proposé plus haut pour illustrer la duplication des données est tout à fait valable pour les informations stockées en mémoire vive.

Le système d’exploitation va calculer une empreinte (« hash » pour les anglophones) pour une certaine unité de stockage pour la totalité de la mémoire vive. Lorsque le système rencontrera deux unités présentant la même empreinte, il en supprimera une copie et fera un lien vers l’unique copie. L’unité de stockage utilisée est, souvent, la page mémoire. Une empreinte est donc calculée pour chaque page mémoire et la déduplication se fait à ce niveau.

A ma connaissance, seuls les systèmes de virtualisation utilisent cette technique pour la mémoire vive. C’est, plus particulièrement, le cas de VMWare et de Xen 4.0.

Déduplication de disques

L’exemple de la mémoire vive est transposable aux supports de disque divers. La déduplication au niveau des disques va permettre les mêmes avantages que la mémoire vive et utilisera le même fonctionnement. La différence se situe principalement au niveau de l’unité de stockage qui sera choisie pour le calcul de l’empreinte. Le bloc sera, le plus souvent, utilisé pour les disques.

Une application réelle pour la déduplication se situe d’une part dans les systèmes de virtualisation mais aussi dans les systèmes de sauvegarde dans lesquels on peut retrouver de (très) nombreuses copies d’une même copie. Les équipements qui effectuent la déduplication sont les SAN mais aussi les systèmes de fichiers (« filesystem » pour les anglophones).

Vous allez me dire « Mais mon Linux il sait pas faire ca ! » et, oui, vous avez raison. Si vous voulez effectuer de la déduplication au niveau d’un système de fichiers, il va falloir utiliser ZFS sous OpenSolaris. J’en parlerais dans un prochain billet. Il serait prévu d’inclure ce type de fonctionnalité dans Btrfs.

Au final, j’espère avoir fait un tour d’horizon assez complet de cette technique relativement récente mais que je trouve particulièrement intéressante.

Petit historique

Vous savez peut être que Xen a été quelque peu obscurcit par l’introduction de KVM dans le noyau Linux. Cette inclusion de KVM a conduit des distributions telles que Red Hat et Ubuntu à supprimer Xen de leurs distributions ou de ne laisser qu’un support pour le moins minimal. A l’époque de ces faits, Xen n’était compatible qu’avec un ou deux noyaux Linux patchés par l’équipe de Xen. Cette époque est révolue car Xen a évolué vers les noyaux dits « Paravirt Ops » ce qui signifie que la compatibilité d’un noyau Linux avec Xen ne tient plus qu’à un module de ce même noyau.

La version Xen 4.0 est particulièrement intéressante car il s’agit de la première version qui fonctionne par défaut avec les noyaux Paravirt Ops. L’installation de versions antérieures vous assurera la douleur de devoir éventuellement passer vers une version supérieure à la 4.0 lorsque vous voudrez mettre à jour vos noyaux Linux.

Installation

Nous pouvons désormais passer aux choses sérieuses. Nous allons effectuer une installation à partir des sources car il n’existe pas encore de paquets. Et puis de toute façon, une petite compilation ne vous fait pas peur !

Nous allons tout d’abord récupérer l’archive sur le site de Xen et on la dézippe :

wget http://bits.xensource.com/oss-xen/release/4.0.0/xen-4.0.0.tar.gz

tar zxvf xen-4.0.0.tar.gz

Nous allons ensuite installer tous les pré-requis et ils sont nombreux.

apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-fonts-recommended pciutils-dev mercurial build-essential make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev iasl libbz2-dev e2fslibs-dev git-core uuid-dev gcc-multilib

Passons désormais à la compilation. Si vous avez une machine dotée de plusieurs cœurs / processeurs, n’hésitez surtout pas à utiliser l’option -jX où X est le nombre de cœurs que vous avez. Cette option permet de répartir la compilation sur tous les cœurs et ainsi de la finir plus rapidement. J’avais un BiQuad Core, donc ce sera 8 pour cet exemple.

make -j8 xen

make -j8 tools

make -j8 stubdom

Ensuite, on installe tout ca.

make -j8 install-xen

make -j8 install-tools

make -j8 stubdom

Grâce à toutes ces commandes, nous avons installé Xen ainsi que tous les outils associés. Il nous manque plus que le noyau Linux pour les domaines. A partir de là, vous pouvez soit créer votre propre noyau soit utiliser un noyau proposé par Xen. J’ai choisi de faire cela car c’était plus simple, plus rapide et plus pratique.

On va donc exécuter la commande qui va nous permettre de récupérer et de compiler le noyau qui va bien pour notre installation de Xen.

make -j8 world

Pour installer le noyau que vous avons compilé, il ne manque qu’à exécuter la commande suivante. On crée au passage l’initrd qui va bien.

make install

mkinitramfs -o /boot/initrd-2.6.31.13.img 2.6.31.13

Vous devez ensuite modifier Grub afin qu’il s’adapte à Xen. La configuration suivante fonctionne sur l’hyperviseur que j’ai eu l’occasion d’installer. Il faut adapter le root en fonction de votre serveur. Ici, il s’agissait d’un contrôleur RAID HP.

title           Xen 4.0.0 / Debian GNU/Linux, kernel 2.6.31.13
root            (hd0,1)
kernel          /boot/xen-4.0.0.gz
module          /boot/vmlinuz-2.6.31.13 root=/dev/cciss/c0d0p2 ro console=tty0
module          /boot/initrd-2.6.31.13.img

Vous pouvez ensuite rebooter sur votre nouvelle installation de Xen 4.0 avec votre noyau Paravirt Ops. Si vous souhaitez modifier des options à la compilation du noyau, il faut se placer dans le bon répertoire et activer les bons paramètres dans le menu.

cd build-linux-2.6-pvops_x86_64

make menuconfig

Il faut activer le support TUN/TAP si vous souhaitez exécuter des domaines HVM ainsi que le support du 802.1Q si vous souhaitez placer vos domaines sur différents VLAN. Ces deux options ne sont pas activées par défaut.

Au final, j’espère que ce tutoriel vous sera utile et que j’ai été clair. Le passage vers les noyaux en Paravirt Ops est une évolution majeure dans l’histoire de Xen et permettra une adoption nettement plus large.

Lorsqu’une architecture est conçue initialement, les concepteurs disposent d’un certain nombre d’éléments motivant un choix technologique par dessus un autre. Dans le cas du cloud computing, ces éléments ne sont pas fixés depuis une durée particulièrement longue et ne sont clairement pas fixés à des échéances au delà du moyen terme. La relative nouveauté du cloud computing devrait démotiver bon nombre de concepteurs d’architecture.

Dans le cas où le choix serait fait de se baser sur une architecture intégrée au sein d’un cloud quelconque, il est nécessaire de se poser très sérieusement la question de l’interopérabilité. Lorsqu’une entité va placer son architecture,  elle confiera d’une part ses données mais aussi le travail humain lié à la conception d’une plateforme. Ce travail humain a un coût relativement important en fonction de l’architecture en question. De sérieux problèmes sont à envisager dans l’éventualité d’une faillite de la société hébergeant le cloud ou même une catastrophe quelconque mettant à mal le cloud. La non-transparence des clouds actuels rend exceptionnellement compliqué l’évaluation de ces risques.

La problématique de l’interopérabilité se pose ainsi. Dans le cas où une entité utilisatrice utilisatrice d’infrastructure cloud souhaite changer d’hébergeur pour une raison X ou Y, en a-t’elle la possibilité ? Il y a bien sur plusieurs niveaux de réponse à cette question. Nous pouvons envisager une situation dans laquelle il lui est juste possible de récupérer les données applicatives ce qui impliquerait de devoir reconstruire la quasi totalité de l’infrastructure applicative. Nous pouvons également envisager une situation où il est possible de récupérer une version « packagée » des machines virtuelles ou, à l’opposé, une situation où rien n’est prévu pour être compatible avec d’autres plateformes.

De plus, ce n’est pas parcqu’il est possible de récupérer une machine virtuelle qu’il sera possible de l’exécuter sur une autre plateforme sans devoir se plonger dans les méandres du système d’exploitation pour peu que celà soit même possible.

Au final, l’interopérabilité est un enjeu majeur de toute plateforme informatique et suscite de nombreux débats habituellement. Les problématiques d’interopérabilité dans le cloud computing ne semblent pas encore avoir passioné grand monde ce qui est dommage car elle est bien réelle et existante. Le logiciel libre a clairement un rôle à jouer dans le cadre de cette standardisation avec les acteurs majeurs de l’industrie associée.

Les dangers liés au cloud computing sont la conséquence directe de la dématérialisation des infrastructures physiques.

Tout d’abord, la première problématique est la localisation des données. L’abstraction des infrastructures physiques rend la localisation de données spécifiques significativement plus compliquée. Cette incertitude induit une sécurité pas forcément amoindrie mais certainement considérablement complexifiée.

Cette première problématique est évidente dans le cas des clouds publics ou privés-publics. Le client des infrastructures de cloud computing accorde une confiance totale aux prestataires en lui livrant toutes ses données. Bien que la plupart des argumentaires commerciaux mettent en avant une sécurité des données et, le plus souvent, un chiffrement, il est impossible de vérifier cela. Le client devient spectateur de la sécurisation de ces données.

Nous pouvons faire une exception à cette problématique dans le cas de clouds privés-publics. Ce cloisonnement reste tout à fait relatif. Ce cloisonnement peut être, dans le cas d’infrastructures « bas de gamme » seulement un mécanisme réseau tel que les VLAN. Ce mécanisme peut difficilement être considéré en tant que mécanisme de cloisonnement de données efficace.

Dans le cas d’infrastructures « haut de gamme », nous pouvons imaginer une architecture de type « cloud computing » exclusive à chaque client. Cette alternative se place dans le haut de gamme par le coût que cela engendre. Ce type d’offre permettrait, au passage, une plus grande flexibilité dans l’architecture à tous les niveaux.

Au final, la sécurité des données est une réelle problématique du cloud computing. Nous nous intéresserons plus tard aux problématiques d’interopérabilité des plateformes.

Nous distinguerons trois types de nuages. Le premier type, également le premier à être apparu sous la dénomination « cloud », est le nuage public. Le second type est le nuage privé. Le dernier type est un mélange des deux, c’est à dire, un nuage privé-public.

Le nuage public

La dénomination de « cloud computing » est arrivée en même temps que les grands nuages publics. Ces grands systèmes informatiques ont été rendus viables grâce à une forte automatisation et une grande efficacité des couches de virtualisation.

Dans ce type de nuage, chaque client se voit attribuer plus ou moins aléatoirement une machine virtuelle dans laquelle il pourra faire ce qu’il souhaite. Ces machines virtuelles sont soumises aux contraintes définies par l’hébergeur en fonction de ses conditions générales de vente. Chaque machine virtuelle est sensée être l’égale d’une autre et le client n’a que très peu d’amplitude pour la construction d’une véritable architecture.

Les nuages publics existant aujourd’hui ont essentiellement vocation à être des plateformes d’hébergement grand public à la manière d’OVH sur le marché des serveurs dédiés. Pour que cette comparaison soit valable, il est nécessaire d’exclure la diversification des offres d’OVH avec notamment la possibilité d’obtenir un firewall Cisco ASA. Il est peu probable qu’il soit possible d’insérer un Cisco ASA dans un grand nuage public.

La présence de l’open source dans les nuages public est très forte, surtout à travers de Xen. Amazon, Gandi, 1&1 et Rackspace sont tous basés sur Xen. Le marché des grand nuages public a peu de chance de voir une réelle présence de VMWare à cause de sa tarification. Je vous laisse imaginer le prix d’un cloud public VMWare…

Le nuage privé

Les nuages privés sont clairement orientés vers les entreprises. Il parait particulièrement improbable de voir une quelconque entreprise confier la totalité de ses données et de l’infrastructure informatique à une nébuleuse telle qu’Amazon.

Il me semble que la notion de nuage privé est quasiment équivalente à la notion de plateforme de virtualisation interne à une société. Dans ce type de nuage, la notion de « cloud computing » semble floue et la distinction avec une plateforme de virtualisation semble mince voire inexistante.

L’open source a un rôle à jouer sur ce type de nuages mais l’état actuel des choses ne le facilite pas. L’automatisation d’une plateforme Xen ou KVM nécessite un travail de développement conséquent même si des outils tels que le Xen Cloud Platform vont dans le bon sens. VMWare est désormais très présent sur le marché avec ses produits d’administration et d’automatisation VSphere et Virtual Center.

Le nuage privé-public

Le nuage privé-public est un nuage privé inséré dans une plateforme public. Ce type d’offre est encore relativement rare car le concept est plutôt récent.

Cette notion semble relativement équivalente à la notion de nuage privé placé dans le cadre d’une offre d’infogérance. Bien que les offres placées sous la dénomination « nuage privé-public » sont rares, les plateformes de virtualisation infogérées sont monnaie courante aujourd’hui.

Au final, je pense avoir fait le tour des différentes configurations de « cloud computing » que l’on peut retrouver aujourd’hui. Je pense également que toutes ces offres ne sont pas réellement révolutionnaires contrairement à ce que bon nombre de commerciaux souhaiteraient nous faire croire.