Hyper-V : sécuriser le démarrage des machines virtuelles

Le démarrage d’une machine virtuelle ne se résume pas à cliquer sur « Démarrer ». Dans Hyper-V, il s’inscrit dans une chaîne de confiance qui commence par le matériel, se poursuit avec le micrologiciel et la configuration de la VM, et doit rester cohérente avec les mécanismes d’isolation, de chiffrement et de continuité de service. L’actualité de 2026 rappelle que cette chaîne est attaquée aux deux extrémités : le démarrage sécurisé d’un côté, l’hyperviseur de l’autre.

Vérifier l’hôte et la configuration avant le lancement

Hyper-V est un hyperviseur de type 1 intégré à Windows Server et à Windows : il s’exécute directement sur le matériel et isole les charges de travail. Cette position rend la vérification de l’hôte essentielle avant tout démarrage — la plateforme doit appartenir aux versions prises en charge et le processeur doit exposer les fonctions nécessaires au scénario retenu.

Pour la virtualisation imbriquée, Microsoft distingue deux familles de processeurs. Avec un processeur Intel prenant en charge VT-x et EPT, l’hôte Hyper-V doit utiliser Windows Server 2016 ou une version ultérieure, ou Windows 10 ou une version ultérieure, et la configuration de la VM doit être en version 8.0 ou supérieure. Avec un processeur AMD EPYC ou Ryzen, l’hôte doit utiliser Windows Server 2022 ou une version ultérieure, ou Windows 11 ou une version ultérieure, tandis que la version de configuration minimale est 9.3. Ces contrôles précèdent le démarrage : ils ne se rattrapent pas après.

Contrôler l’activation de la virtualisation imbriquée

La virtualisation imbriquée n’est pas implicite. La VM doit d’abord être créée avec un système et une version de configuration compatibles, puis être arrêtée : Microsoft demande d’exécuter, sur l’hôte physique Hyper-V, la commande PowerShell « Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true », qui expose les extensions de virtualisation au processeur virtuel. Ce n’est qu’ensuite que la VM peut être démarrée, puis le rôle Hyper-V installé à l’intérieur, comme sur un serveur physique.

Le contrôle doit aussi porter sur la réversibilité : pour retirer cette capacité, la VM doit être arrêtée et la même propriété passée à « $false ». Cette symétrie fournit un point de vérification simple dans les procédures : une VM destinée à héberger un hyperviseur doit être explicitement identifiée, et l’exposition des extensions ne doit pas devenir un réglage permanent et invisible. Dans un scénario Azure, le type de sécurité « Standard » doit en outre être sélectionné pour activer la virtualisation imbriquée.

Sécuriser le firmware et l’identité de la machine

Le démarrage sécurisé prend sa place dans une stratégie plus large. Hyper-V propose des machines virtuelles blindées, qui associent chiffrement BitLocker, vérification Secure Boot et attestation TPM 2.0, le Host Guardian Service vérifiant que seuls les hôtes autorisés peuvent les exécuter. Les VM de génération 2 apportent de leur côté un firmware UEFI, Secure Boot et un TPM virtuel 2.0.

Encore faut-il que la racine de confiance soit à jour. Les certificats Secure Boot émis par Microsoft en 2011 ont commencé à expirer en juin 2026, le dernier arrivant à échéance en octobre 2026 : un système qui n’a pas reçu les autorités de certification 2023 continue de démarrer, mais cesse de recevoir les mises à jour du gestionnaire de démarrage, les listes de révocation et les correctifs contre les bootkits. Le 14 juillet 2026, la recherche ESET a par ailleurs révélé onze applications UEFI signées par Microsoft permettant de contourner Secure Boot sur toute machine faisant confiance au certificat Microsoft UEFI CA 2011 : du code non signé pouvait s’exécuter dès l’amorçage et installer un bootkit persistant, Secure Boot pourtant activé. Ces applications ont été révoquées, mais une révocation ne protège que les systèmes qui ont reçu la mise à jour.

Ne pas oublier l’hyperviseur lui-même

L’isolation ne s’arrête pas au firmware. VLAN, commutateurs virtuels privés et réseau défini par logiciel créent des segments destinés à empêcher les mouvements latéraux entre charges de travail. Dans la virtualisation imbriquée, la connectivité se décide avant le démarrage opérationnel : soit l’activation de l’usurpation d’adresse MAC sur le commutateur virtuel de premier niveau, soit un réseau NAT lorsque cette usurpation est impossible, notamment en cloud public.

Cette segmentation ne remplace pas les correctifs de l’hôte. Le 9 juin 2026, Microsoft a corrigé plus de 200 vulnérabilités, dont 33 critiques et trois failles déjà exploitées ; la plus grave, CVE-2026-47291 (score 9.8), touche HTTP.sys. Surtout, trois exécutions de code à distance corrigées le même jour concernaient Hyper-V et permettaient une évasion de machine virtuelle. Le mécanisme n’est pas propre à Microsoft : le bulletin du CERT-FR du 13 juillet 2026 décrit Januscape (CVE-2026-53359), qui permet de sortir d’une VM invitée pour prendre le contrôle de l’hôte KVM.

Inscrire les contrôles dans l’exploitation

Une stratégie de virtualisation fiable transforme ces vérifications en étapes répétables. Avant lancement, l’équipe confirme l’hôte, le processeur, la version de configuration, l’état arrêté requis pour les modifications, la présence des certificats 2023 et, si nécessaire, le type de sécurité Azure. Après lancement, elle vérifie que le rôle Hyper-V fonctionne dans la VM hôte et que le réseau choisi correspond à l’objectif d’isolement. Hyper-V Manager et PowerShell permettent de porter ces contrôles dans les procédures plutôt que dans les habitudes.

Cette discipline relie sécurité et disponibilité : Hyper-V fournit l’isolation, Secure Boot et le TPM 2.0, tandis que le clustering de basculement, la migration à chaud et Hyper-V Replica répondent à la continuité d’activité. L’objectif n’est pas d’ajouter une étape isolée, mais de rendre vérifiable chaque condition qui autorise une VM à entrer en production.