Quelle sécurité pour les architectures virtualisées ?

S'ils ne constituent pas de nouvelles menaces pour la sécurité, les serveurs virtuels imposent une configuration rigoureuse du réseau et une réflexion préliminaire sur le type d'hyperviseur à adopter.

Les techniques de virtualisation sont désormais largement utilisées par les entreprises, jusque dans leurs processus de production, y compris critiques. Mais, si cette tendance est indéniablement une preuve de la fiabilité des systèmes, elle ne présume pas de leur sécurité. C'est la question qui se pose aujourd'hui. ' Des clients nous consultent parfois sur la sécurité de leurs infrastructures virtualisées, mais nous n'avons encore jamais eu besoin de délivrer des prestations de sécurité spécifiques de la virtualisation ', fait remarquer Éric Fichot, expert sécurité pour le cabinet Intrinsec et ingénieur certifié VMware.Pas de prestations spécifiques, et pour cause : les systèmes virtualisés sont avant tout des systèmes traditionnels qu'il convient de sécuriser comme tels. ' Avant d'aborder les spécificités de la virtualisation, il convient de respecter toutes les règles de l'art de la sécurité traditionnelle ', explique Sylvain Siou, directeur technique de l'éditeur VMware. Toutes, plus une : la console d'administration de l'ensemble des machines virtuelles (celle de l'hyperviseur chez VMware ou le Virtual Machine Manager intégré à Windows chez Microsoft) doit être particulièrement protégée, notamment en la plaçant sur un réseau interne dédié.Ce n'est qu'ensuite que se posera la seule vraie question propre à la virtualisation : celle de l'étanchéité à la fois entre les machines virtualisées et entre celles-ci et les systèmes hôtes physiques qui les hébergent. Sans étanchéité, pas de sécurité. ' Et là, ce n'est pas forcément rassurant car, quels que soient le nombre et la diversité des serveurs virtuels, toute la sécurité repose sur la solution de virtualisation de base ', rappelle Éric Fichot.Le modèle de virtualisation adopté par la solution de base du système conditionnera la structure du projet : la virtualisation est-elle prise en charge par une application comme une autre, fonctionnant sur un système d'exploitation traditionnel, ou bien est-elle gérée directement par l'OS ? Et, suivant le cas, les produits diffèrent, même chez un même éditeur. ' Il est évident qu'avec des solutions telles que Workstation ou VMware Server, l'isolation n'est pas parfaite au niveau du réseau, car toutes les machines partagent la même pile TCP/IP : celle de l'hôte physique ', reconnaît Sylvain Siou. Ce n'est qu'avec la gamme ESX que l'isolation est totale : ' ESX permet de créer des commutateurs virtuels et de les faire sortir sur des ports distincts de ceux des commutateurs réels. Le trafic est donc réellement isolé. Il n'y a au cun moyen que deux machines virtuelles communiquent si elles n'ont pas des adresses IP cohérentes et ne sont pas sur le même réseau ', poursuit-il.

Systèmes d'exploitation standards ?

Du côté de Microsoft, les versions actuelles de Virtual Server fonctionnent sur un système d'exploitation Windows standard. La solution ne fait pas que des adeptes. ' Certes, chez VMware, le logiciel fonctionne aussi avec un système d'exploitation connu, puisque c'est un Linux. Mais il a été spécifiquement retravaillé, simplifié, il est doté d'un système de fichiers spécifique et il intervient comme un service du noyau. Je déconseille fortement l'approche que propose Microsoft avec Virtual Server, qui consiste à faire de la virtualisation sur un système d'exploitation existant standard ', explique Éric Fichot. Un avis que Microsoft semble avoir, en partie, entendu : ' Nous prévoyons d'intégrer la virtualisation à Longhorn Server. L'hyperviseur sera alors un composant du système d'exploitation [intégré au noyau et non plus simplement un applicatif, Ndlr] ', justifie Alain Le Hégarat, responsable marketing Windows Server chez l'éditeur. Mais que faire du réseau ? C'est l'autre question cruciale qui se pose au moment de l'élaboration du cahier des charges.

Virtualiser le réseau : les avis sont partagés

Les logiciels actuels permettent de créer des commutateurs virtuels et de faire ainsi tourner une architecture complète, de la DMZ au LAN, serveurs compris, sur une seule machine physique. Techniquement intéressante, cette architecture n'a pourtant pas encore séduit les équipes de sécurité. ' Psychologiquement, les RSSI ont souvent du mal à accepter l'idée de virtualiser la DMZ et le LAN sur la même machine ', confirme Sylvain Siou. Et de fait, du côté des consultants en sécurité, on abonde en ce sens. ' Il faut séparer la DMZ du LAN en les mettant sur des serveurs physiques différents. Même si ce n'est qu'une précaution, c'est à mon avis essentiel ', recommande Éric Fichot. Le reste du réseau, ensuite, peut parfaitement être virtualisé avec un peu d'astuce. ' L'idéal est de créer les commutateurs virtuels nécessaires, puis de sortir sur des réseaux séparés, via des interfaces physiques distinctes, plutôt que tout mettre sur un seul tuyau et de marquer les flux ', explique Édouard Jeanson, responsable de l'offre sécurité pour Sogeti.Une fois ces étapes franchies, l'architecture virtualisée ne comporte pas plus de risques que la même architecture fonctionnant sur des équipements physiques distincts. Voire même moins : un commutateur ou un serveur virtuels ne tombent jamais en panne !

Si vous êtes pressé

La protection des serveurs virtuels repose en grande partie sur les bonnes pratiques issues de la protection des serveurs traditionnels, avec un accent particulier à placer sur l'isolation de la console d'administration. En revanche, tous les modèles de virtualisation ne se valent pas sous l'aspect de la sécurité. ESX Server, la solution haut de gamme de VMware, qui ne recourt pas à un OS sous-jacent et dispose de fonctions avancées de virtualisation réseau, se distingue une nouvelle fois. Enfin, une stricte isolation physique des serveurs virtuels de la DMZ et de ceux du LAN s'impose.

Les trois règles de sécurité à suivre

Séparer la DMZ du LAN sur des serveurs physiques distincts.
Protéger la console de l'hyperviseur sur un réseau physique séparé.
Rester vigilant. Les logiciels sont récents, et personne n'y a encore vraiment cherché les vulnérabilités. Si Cisco peut commettre des erreurs dans le code de ses commutateurs, VMware aussi.

Penser à la sauvegarde : Philippe Letreulle (Orbytes) : ' la sauvegarde de machines virtualisées est spécifique '

' Une machine virtuelle, ça se sauvegarde ! On peut, évidemment, réaliser des snapshots réguliers à l'aide des fonctions intégrées aux logiciels. Mais cela ne sauvegarde que les machines elles-mêmes [sans tenir compte des besoins des applicatifs qui tournent sur la machine virtuelle, Ndlr]. À l'inverse, des outils tiers, tel NetVault de BackBone, traitent désormais aussi bien les machines virtualisées que la console de l'hyperviseur. D'autres, tel esxRanger de Vizioncore, permettent la sauvegarde à chaud des machines virtuelles en production, leur restauration sélective, etc. On ne sauvegarde pas des machines virtualisées comme des systèmes traditionnels. Il y a des fichiers spécifiques à protéger si l'on veut reconstruire les machines. Et surtout, on place le tout sur un SAN, afin de stocker les images sur le réseau et d'y accéder aisément. '

Attention à l'exploitation : Cédric Cartau (CHU) : ' le vrai risque vient de l'industrialisation '

Au CHU de Rouen, la virtualisation est à tous les étages et les problèmes de sécurité, pas forcément là où on les attend. ' Le problème de la sécurité au quotidien, ce n'est pas l'isolation des machines virtuelles, c'est leur exploitation. Nous courons le risque de laisser des systèmes de côté parce que nous n'aurons plus les moyens physiques de les entretenir ', considère Cédric Cartau. Car des systèmes avec la virtualisation, il y en beaucoup ! ' Depuis le début de l'année, nous avons déployé 55 nouveaux serveurs virtuels. Nous n'avons jamais eu autant de machines. Désormais, nous nous retrouvons avec un problème de gestion du cycle de vie de ces serveurs. Aujourd'hui, nous gérons, mais lorsquil faudra renouveler, appliquer un Service Pack ou sauvegarder correctement plusieurs centaines de machines, nous aurons un problème ', explique Cédric Cartau.