Virtualisation de systèmes d'exploitation et sécurité

Date : 31 Août 2007

Les logiciels de virtualisation de systèmes d'exploitation proposent des fonctionnalités permettant d'optimiser au maximum l'utilisation des ressources informatiques, notamment au niveau des serveurs de grande capacité (HP, IBM, Sun, …). Cette tendance offrant des possibilités d'économie à grande échelle est de plus en plus présente dans les grandes entreprises.

L'intérêt de ce type de technologie est de faire ainsi cohabiter sur une même plate-forme matérielle plusieurs systèmes d'exploitation et environnements logiciels.

Ce type d'architecture peut être utilisé sur des serveurs de production, notamment au niveau des solutions de sauvegarde ou de partage de fichiers, ou de pré-production à des fins de test de compatibilité (test de migration d'une application sur un nouvel OS par exemple, test de mise à jour logicielle…).

Une autre utilisation, mais cette fois-ci au niveau des postes de travail des administrateurs système ou réseau, est d'offrir en parallèle, un environnement bureautique (outils Internet, traitement de texte, …) avec des privilèges utilisateur standard et des environnements d'administration cloisonnés sur une même et unique machine.

Quoi qu'il en soit, les avantages de la virtualisation sont de plus en plus admis dans les entreprises. Mais qu'en est-il de la sécurité de ce type de technologie ?

Nous vous proposons au travers de cet article d'évaluer de manière succincte la sécurité de la virtualisation aux travers de trois principaux axes de réflexion :

  • La sécurité physique
  • Le cloisonnement des privilèges
  • La robustesse des logiciels de virtualisation

Nota : La problématique sécurité se rapproche de celle abordée dans le cas de toute mutualisation de ressources (par exemple un serveur de sauvegarde et son robot hébergeant les sauvegardes de plusieurs systèmes d'information).

1 – La sécurité physique

Le regroupement géographique de différents serveurs dans un seul serveur physique fait apparaître des problèmes de sécurité et d'accès physique supplémentaires.

Par exemple, une mauvaise manipulation (volontaire ou non) sur le serveur unique, hébergeant des environnements multiples, n'aura pas le même impact en termes de sécurité physique que sur des serveurs dédiés par environnement et situés dans zones géographiques distinctes.

L'accès physique à ce type d'équipement devra alors faire l'objet d'une attention particulière.

De même, la tolérance aux pannes des composants physiques du serveur hôte (disques durs, carte mère, processeurs, …) devra garantir une haute disponibilité si ce dernier héberge des environnements critiques. Une panne matérielle verra son impact multiplier d'autant de fois qu'elle impacte d'environnements distincts sur le serveur hôte.

2 – Le cloisonnement des privilèges

La mutualisation des ressources afin d'héberger plusieurs environnements applicatifs peut engendrer une complexité accrue de la gestion du cloisonnement des privilèges utilisateur, exploitants et administrateurs.

Prenons le cas où un serveur hôte abrite un environnement virtuel dédié aux applications financières cohabitant avec un environnement dédié aux applications des ressources humaines. Les utilisateurs de l'une des deux applications n'auront pas le même besoin d'en connaître (confidentialité), modifier (intégrité) ou disposer (disponibilité) que ceux de la seconde. Cette contrainte peut être gérée de manière "classique" en faisant abstraction de la virtualisation au niveau de chaque environnement virtuel. Par contre la gestion du cloisonnement des privilèges administrateurs de la plate-forme peut se révéler plus ardue.

En effet, l'administrateur du système hôte ne devrait pas être en mesure de posséder des privilèges d'administration sur les environnements virtuels. De même qu'un administrateur d'un environnement virtuel ne devrait posséder des privilèges élevés que dans le cadre de l'environnement qui lui est alloué.

Cette complexité supplémentaire se doit d'être prise en compte lors de la réflexion préalable (étude de sécurité) en vue d'utiliser de ce type d'architecture.
 
3 – La robustesse des logiciels de virtualisation

Actuellement, les technologies de virtualisation reposent sur des éléments logiciels distribués par de grands éditeurs du marché VMWare, Microsoft, Symantec, Citrix, Sun, …

Ces lignes de codes ne sont malheureusement pas à l'abri de bogues entraînant des problèmes de sécurité critique pour l'ensemble de la plate-forme. Les chercheurs de vulnérabilité l'ont bien compris puisqu'on voit apparaître régulièrement des vulnérabilités impactant ce type de logiciel.

Ce mois-ci, par exemple, Microsoft a émis un bulletin de sécurité (MS07-049 - CERT-IST/AV-2007.376) sur ses produits de virtualisation "Microsoft Virtual PC" et "Microsoft Virtual Server".

Cette vulnérabilité permet à un administrateur d'un environnement virtuel d'acquérir les droits d'administration sur tous les autres environnements hébergés, ainsi que sur le système d'exploitation hôte de la plate-forme elle-même. Au final, cette vulnérabilité permet de prendre le contrôle total de toute la plate-forme vulnérable.

Cette vulnérabilité est donc critique pour ce type d'architecture sensible car elle rend obsolète le cloisonnement des privilèges des administrateurs.

Les produits VMWare sont également régulièrement touchés par des failles de sécurité.

Dans le même ordre d'idée de la faille précédente, la vulnérabilité CVE-2007-1744 décrite dans l'avis CERT-IST/AV-2007.196 permet à un utilisateur ayant un compte sur un des environnements simulés par VMware de lire ou de créer des fichiers arbitraires sur le système de fichiers du système d'exploitation hébergeant la solution WMware. Dans ce cas, le cloisonnement des privilèges des utilisateurs n'est plus assuré.

Ce mois-ci également un long débat a eu lieu sur des listes de diffusion concernant un problème d'isolation des privilèges dans les versions "Workstation" et "Player" de VMware.

Ce problème provient de la présence d'une API ("VMware VIX API") qui permet à un administrateur du système hôte de faire exécuter des commandes/scripts arbitraires sur les systèmes invités ("guest") avec les privilèges de l'utilisateur déjà connecté (ou qui se connectera par la suite) au système virtuel visé.

La solution proposée par VMware est de modifier un paramètre dans la configuration du logiciel (configuration accessible par l'administrateur du système hôte…..!!!!)

Note de sécurité VMware : http://www.securityfocus.com/archive/1/478156/30/0/threaded

Une faille de type "déni de service" est également en cours d'investigation (FA-2007.0198 : "Vulnérabilité dans VMWare 6.0") et concerne les pilotes ("driver") utilisés par VMware.

Les autres vulnérabilités dans les produits VMware sont données par la suite.

Face à toutes ces vulnérabilités, il est dès lors fortement recommandé de suivre les vulnérabilités impactant ce type de logiciel et d'appliquer les correctifs proposés le cas échéant. Mais cette action ne va pas sans une validation préalable du correctif afin de s'assurer de la stabilité de la plate-forme ainsi corrigée.

De la même manière, les systèmes d'exploitation et applications s'exécutant dans les environnements virtuels doivent faire l'objet d'une attention particulière en termes de correctifs de sécurité (comme pour les plates-formes plus classiques).

En conclusion, bien que la virtualisation fasse son entrée dans les entreprises, son attrait technologique ne doit pas faire oublier l'apparition de nouvelles contraintes introduites par la mutualisation des ressources, en particulier en terme de disponibilité. La virtualisation introduit ainsi des risques supplémentaires de sécurité.

Ces contraintes doivent être prises en compte dès l'intégration de cette technologie dans les projets dits sensibles afin d'identifier au plus tôt les nouvelles menaces qui pèsent sur ces systèmes et d'ajuster les mesures de protection : protection physique, cloisonnement des privilèges et gestion des correctifs de sécurité.

Précedent Précedent Suivant Suivant Imprimer Imprimer