Virtualisation de systèmes d'exploitation et sécurité
Date : 31 Août 2007
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
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
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,
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.
- CERT-IST/AV-2007.196 - Multiples vulnérabilités dans des produits VMware
- CERT-IST/AV-2007.155 - Vulnérabilités dans VMware ESX Server 3.0.0 et 3.0.1
- CERT-IST/AV-2007.011 - Multiples vulnérabilités dans "VMware ESX Server"
- CERT-IST/AV-2006.473 - Multiples vulnérabilités dans "VMware ESX Server"
- CERT-IST/AV-2006.461 - Vulnérabilité dans "VMware ESX Server" sur les systèmes AMD
- CERT-IST/AV-2006.300 - Multiples vulnérabilités dans le serveur "VMware ESX"
- CERT-IST/AV-2006.289 - Vulnérabilité des clés SSL dans VMware sur Linux
- CERT-IST/AV-2006.209 - Vulnérabilité dans "VMware Server"
- CERT-IST/AV-2006.207 - Vulnérabilité dans le serveur "VMware ESX"
- CERT-IST/AV-2005.483 - Vulnérabilité dans le service NAT des produits VMware
- CERT-IST/AV-2003.241 - Vulnérabilité dans la solution serveur VMware GSX Server et Workstation (pour Linux)
- CERT-IST/AV-2002.256 - Débordement de pile dans la solution serveur VMware GSX Server 2.0.0 (pour Microsoft Windows)
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é.
