Executive summary : Un principe de base pour la protection des machines virtuelles est de considérer qu’elles sont au moins aussi sensibles que des machines physiques. Bref, elles doivent être patchées comme les autres. Par contre, cette comparaison ne prétend pas limiter les besoins de sécurité des machines virtuelles, car elles ont également des besoins spécifiques (sécurisation des fichiers de disque virtuel, des machines avec l’hyperviseur, etc.) et des caractéristiques rendant plus difficile leur sécurisation (application des patchs sur une machine virtuelle éteinte, ce qui constituera une partie importante de la session, avec la présentation de l’outil Microsoft dédié à ce cas de figure).
On retrouve à cette session un des intervenants de la précédente, mais vu le public et le calme dans la préparation comme dans la salle, je sens que ça va être beaucoup plus sage. Ca m’évitera d’ailleurs de me ramasser un cadenas dans la tronche. Oui, sur la session précédente, les intervenants lançaient des (petits) cadenas dans le public. J’ai réussi à sauver mon netbook, c’est déjà çà…
Session présentée par Pascal Saulière (http://blogs.technet.com/pascals pour les diapos), Architecte pour Microsoft France.
Contexte
On se place dans un contexte de virtualisation serveur, et non pas du client ou des applications. Bref, surtout sur Hyper-V.
La flexibilité des machines virtuelles fait qu’on tendance à créer des machines virtuelles à chaque nouveau besoin métier. Du coup, on utilise des images qui ne sont pas nécessairement patchées comme source. Il y a aussi plus de fichiers .vhd à maîtriser, alors qu’ils peuvent en plus être un peu n’importe où sur des SAN. D’où un besoin plus fort de gestion et de supervision.
Microsoft a publié un guide de sécurité Hyper-V, disponible sur http://go.microsoft.com/fwlink/?LinkId=140067. Il parle de durcissement d’Hyper-V, de délégation, et de méthodes de patch des machines virtuelles.
Durcissement
Avant tout, il faut protéger la partition parente, donc réduire la surface d’attaque sur l’endroit où on fait tourner Hyper-V. Typiquement, il ne faut jamais avoir d’autre rôle pour un serveur Hyper-V, et surtout pas contrôleur de domaine. L’idéal est d’ailleurs de le faire fonctionner en mode core, c’est-à-dire sans la GUI, et l’administrer par la console Hyper-V à distance. Ceci permet de limiter la surface d’attaque, et également de gagner en termes de ressources, ainsi qu’en nombre de patchs à mettre à jour.
Carte réseau dédiée pour la partition parente et le management d’Hyper-V. Et donc bien sûr une deuxième ou plus pour les machines virtuelles elles-mêmes, mais à part. On peut en profiter pour isoler les accès extérieurs.
Bien utiliser les stratégies de groupe adaptées (voir dans le guide).
Délégation d’administration
Consiste à dire qu’il y a une différence entre un administrateur Hyper-V et un administrateur de machines virtuelles. Authorization Manager permet de définir les autorisations de manière bien découpée.
SCVMM (System Center Virtual Machin Manager) est un outil avancé pour gérer les machines virtuelles, et ajoute un niveau d’abstraction pour la délégation, les templates de machines virtuelles, etc.
Protection des machines virtuelles
Principe de base : ce sont des machines comme les autres. Donc durcissement de l’OS : firewall, GPO, etc.
Par contre, en plus, ça vaut le coup de traiter en plus les VHD comme des fichiers sensibles. Chiffrement bitlocker par exemple, et en tout cas audit et gestion des contrôle d’accès.
Pour tout ce est de la maintenance, il faut bien sûr gérer la mise à jour. Et c’est là que se pose le véritable problème : si on a beaucoup de machines virtuelles, ça veut dire beaucoup de machines à patcher.
Autres bonnes pratiques
Ne pas considérer comme sûre l’isolation de deux VM : elle ne pourra jamais être aussi bonne que l’isolation physique. Du coup, il ne faut pas mettre sur une même machine physique des machines virtuelles qui auraient un niveau de sécurité différent. Typiquement, une VM “face à internet” doit être mise à part des autres.
Attention aux composants d’intégration (VM Additions, etc.) : la synchronisation d’horloge est importante pour l’authentification, les audits, etc. Microsoft a fourni du code Open Source pour inclusion de ces addins dans Linux. Ils sont déjà intégrés dans SuSE.
Le gros problème : la mise à jour des VM
On passe plus de temps sur cette partie car c’est là où il y a le plus de boulot. En théorie, on doit faire un test du patch en copiant un snaphsot de la machine de production, en testant, puis en appliquant la mise à jour sur la production et de mettre à jour l’image de sauvegarde à la fin. Ces enchaînements d’actions pourraient d’ailleurs s’automatiser avec PowerShell.
Le souci est surtout pour les machines virtuelles qui sont éteintes. Du coup, elles ne passent pas automatiquement sur la diffusion de mise à jour par WSUS. Comment garantir que le jour où on va les rallumer, tout se passera bien ? Typiquement, les VM pour des tests applicatifs, ou les VM clientes qui sont stockées dans la bibliothèque de SCVMM risquent de manquer le patch tuesday, donc ne respectent potentiellement plus les règles de conformité AD, ou peuvent se faire infecter.
La solution : offline virtual machine servicing tool (http://www.microsoft.com/vmservicing) qui est un guide avec des outils et des scripts permettant, en s’appuyant sur Hyper-V, SCVMM, SCCM et WSUS pour patcher des machines en les allumant, appliquant le patch, éteignant et les stockant de retour dans la bibliothèque. Le processus a lieu sur des serveurs Hyper-V dédiés à la maintenance, qui sont appelés des Maintenance Hosts.
La démarche de l’outil :
- Identifier les machines offline à patcher.
- Trouver un maintenance host avec suffisamment de capacité pour prendre en charge les machines à patcher, en faisant en plusieurs jobs si nécessaire.
- Patcher avec SCCM ou WSUS.
- Rapport temps-réel sur le statut des jobs.
Les contraintes sont que :
- Toutes les VM doivent être pilotées par SCVMM.
- L’environnement de patch doit être opérationnel avec une machine dans le domaine, avec le client WSUS Ou SCCM sur toutes les VM.
- Il faut identifier des machines dédiées (ou en tout cas, dédiées sur un temps partiel et sur un VLAN séparé) comme Maintenance Host.
Demo
OVMST 2.1 est présenté sur un Windows Server 2008 R2.
Un peu décevant à partir de ce point de la session, car la démo se fait sur une seule machine, avec beaucoup d’hypothèses simplificatrices. C’est un peu dommage de passer beaucoup de temps sur ce point, au lieu de plus parler des problématiques de sécurité sur machines virtuelles. Du coup, le libellé de la session est un peu trompeur, car on a parlé pendant 20 minutes de la sécurité, et pendant tout le reste de l’outil pour le patch des machines offline. C’est intéressant, mais c’est loin de représenter les deux tiers du sujet…
L’intervenant reconnaissant que, pour le reste de la session, il ne restait qu’à attendre que le processus démontré finisse, quelques mains se lèvent pour poser des questions. On apprend du coup qu’on ne peut pas utiliser ce processus pour patcher des templates.
Note : Hyper-V Server est la version gratuite d’Hyper-V.
