Hyperviseur Type 1 ou Type 2 : lequel choisir

Hyperviseur Type 1 ou Type 2 : lequel choisir

Le choix entre hyperviseur Type 1 et Type 2 détermine la taille du socle de confiance, la qualité de l’isolation et la charge d’exploitation. Le label seul ne suffit pas : un Type 1 mal administré peut exposer davantage qu’un Type 2 correctement cloisonné, mais ce n’est pas une excuse pour transformer un poste de travail en mini-cloud.

Explication de la marmotte

Un hyperviseur ressemble à un gestionnaire d’immeuble qui attribue des appartements séparés sur un même terrain. Le choix du gestionnaire décide combien de personnes possèdent les passe-partout, combien de portes doivent rester ouvertes et jusqu’où un incident dans un appartement peut se propager.

→ Lire l’explication complète de la marmotte

Type 1 et Type 2 : le compromis qui compte

Un hyperviseur est un logiciel qui exécute plusieurs machines virtuelles (VM) sur un même matériel physique. Il arbitre le processeur, la mémoire, les disques, les interfaces réseau et les périphériques. La séparation n’est jamais magique : elle dépend du processeur, du micrologiciel, du noyau hôte, des pilotes et du code d’émulation.

Un hyperviseur Type 1 démarre directement sur le matériel, avant les systèmes invités. VMware ESXi, Xen et Microsoft Hyper-V entrent généralement dans cette catégorie. Un hyperviseur Type 2 s’exécute comme une application au-dessus d’un système d’exploitation généraliste : VMware Workstation, VirtualBox ou Parallels Desktop en sont les exemples classiques.

Le compromis central est brutal : le Type 1 réduit la quantité de code entre une VM et le matériel, mais impose une plateforme dédiée, une administration séparée et une discipline opérationnelle. Le Type 2 accélère les usages locaux, les démonstrations et les laboratoires, mais confie la sécurité des VM au noyau, aux pilotes, aux agents et aux applications du poste hôte. Le navigateur, le client de messagerie et le pilote audio deviennent alors des voisins indirects des charges virtualisées. Voilà une colocation qui n’a jamais rassuré un modèle de menace sérieux.

La recommandation est nette : pour une charge de production, une zone d’administration, un traitement de données sensibles ou une frontière de sécurité entre équipes, retenir un Type 1 sur matériel dédié. Réserver le Type 2 aux postes de développement, aux laboratoires isolés et aux tests reproductibles, sans y placer de secrets de production persistants. Le coût d’un Type 1 est l’exploitation ; le coût d’un Type 2 est l’extension du périmètre de compromission. Le premier se budgète, le second se découvre souvent après incident.

La classification reste imparfaite. Hyper-V utilise une partition parent privilégiée qui fournit des pilotes et des services de gestion. Xen repose souvent sur un domaine de contrôle nommé Dom0. KVM (Kernel-based Virtual Machine) s’appuie sur le noyau Linux et sur un processus d’émulation tel que QEMU. Le vrai critère n’est donc pas le slogan commercial, mais la taille et les privilèges de la base de confiance : hyperviseur, noyau privilégié, pilotes, services de gestion, firmware et chaîne de démarrage.

Pour cadrer cette frontière avec le reste de l’architecture, consulter les fondations de l’isolation et les principes d’architecture cyber. Une VM n’est pas une frontière réglementaire par décret. C’est une frontière technique, conditionnelle, qui réclame des preuves.

Architecture matérielle et base de confiance

Les processeurs modernes fournissent une virtualisation matérielle : Intel VT-x ou AMD-V pour l’exécution, puis une seconde traduction d’adresses mémoire, Intel Extended Page Tables ou AMD Nested Page Tables. Ces mécanismes empêchent normalement une VM de lire la mémoire attribuée à une autre VM ou à l’hyperviseur.

Une unité de gestion de mémoire d’entrée-sortie, appelée IOMMU (Input-Output Memory Management Unit), complète ce dispositif pour les accès directs des périphériques à la mémoire. Sans IOMMU active et correctement configurée, une carte réseau, un contrôleur de stockage ou un périphérique passé directement à une VM peut effectuer des accès mémoire hors de son périmètre. Le passage direct de périphérique n’est pas une optimisation gratuite, malgré ce que promettent certaines slides pleines de nuages.

Le démarrage doit être mesuré et protégé. Secure Boot vérifie les composants chargés au démarrage ; un TPM (Trusted Platform Module) peut enregistrer des mesures cryptographiques de cet état. Ces protections limitent le chargement de composants non autorisés, mais ne corrigent ni un hyperviseur vulnérable ni un compte d’administration compromis. Elles sont une condition d’intégrité initiale, pas un exorcisme matériel.

Un Type 1 réduit normalement le noyau généraliste exposé aux VM, mais la partition de gestion peut annuler une grande partie de ce bénéfice. Une partition parent qui héberge pilotes, agents de sauvegarde, outils d’inventaire, antivirus et accès Internet devient un système généraliste très privilégié. Il faut la traiter comme un bastion : fonctions limitées, logiciels minimaux, accès administratifs dédiés et aucune navigation Web. Vingt ans d’infrastructure enseignent que l’outil d’administration installé « juste pour dépanner » finit par avoir plus de privilèges que l’application qu’il dépanne.

Les prérequis de plateforme sont les suivants :

• processeur compatible virtualisation matérielle et IOMMU ;
• micrologiciel serveur maintenu, avec mises à jour traçables ;
• démarrage vérifié, stockage des mesures de démarrage si l’exigence l’impose ;
• interfaces réseau distinctes pour administration, migration et trafic des VM ;
• stockage capable de préserver les barrières d’accès entre hôtes ;
• synchronisation de temps fiable, car certificats, journaux et tickets d’administration détestent l’horlogerie créative ;
• source de paquets et d’images contrôlée pour l’hyperviseur, les pilotes et les outils invités.

Surface d’attaque : Type 1, Type 2 et plan de gestion

L’évasion de VM consiste à exploiter une faiblesse afin de sortir du système invité et d’atteindre l’hyperviseur ou l’hôte. Le sujet est traité spécifiquement dans les pages consacrées aux failles, mais l’architecture décide ici de la probabilité et du rayon d’explosion.

Les sorties de virtualisation sont une première surface : la VM demande à l’hyperviseur de traiter certaines instructions, interruptions ou accès matériels. Les hyperappels, c’est-à-dire les appels explicites de la VM vers l’hyperviseur, ajoutent une interface privilégiée. Chaque périphérique émulé ajoute du code : contrôleur disque, carte graphique, contrôleur USB, carte réseau, lecteur virtuel. Le périphérique absent ne contient pas de vulnérabilité exploitable. Désactiver les périphériques inutiles est donc une réduction de surface, pas une manie ascétique.

Le Type 2 ajoute le noyau hôte, ses pilotes, son environnement graphique, les services locaux et les logiciels utilisateurs. Un attaquant qui obtient des privilèges administrateur sur l’hôte peut souvent lire les fichiers de disques virtuels, modifier leur configuration, intercepter leur trafic ou injecter du code dans le processus de virtualisation. Le chiffrement d’une VM éteinte protège peu face à un hôte qui possède les clés ou peut capturer sa mémoire lors de l’exécution.

Le Type 1 concentre une autre surface : l’interface de gestion, les interfaces de programmation, les consoles distantes, les services de migration à chaud, les dépôts d’images et les contrôleurs centralisés. Le compte qui peut créer une VM peut souvent attacher un disque existant, monter une image modifiée ou extraire une mémoire à des fins de diagnostic. L’administration de virtualisation est donc une administration de données et de secrets.

Les contre-mesures prioritaires sont concrètes :

• isoler le réseau de gestion, sans exposition directe aux réseaux utilisateurs ;
• imposer une authentification multifacteur pour les administrateurs ;
• séparer les rôles d’exploitation, de sécurité et de sauvegarde ;
• désactiver presse-papiers partagé, glisser-déposer, dossiers partagés, USB redirigé et périphériques inutilisés sur les VM sensibles ;
• chiffrer et authentifier les migrations avec TLS (Transport Layer Security), en validant les certificats des hôtes ;
• appliquer les correctifs d’hyperviseur, de micrologiciel et de pilotes selon une fenêtre définie ;
• journaliser les changements de configuration, les attachements de disques, les exports et les accès à la console.

L’isolation réseau reste distincte de l’isolation de calcul. Une VM correctement séparée en mémoire peut exfiltrer ses données sur un réseau plat. Les contrôles réseau doivent donc segmenter les flux d’administration, de stockage, de migration et de production. Mélanger ces réseaux sur un même segment pour économiser deux ports physiques reste une économie qui prend parfois la forme d’un rapport d’incident.

Exemple : vérifier les prérequis KVM sur Linux

Sur un hôte Linux destiné à KVM, la présence des extensions processeur et de l’IOMMU doit être vérifiée avant de créer des VM. La commande suivante est reproductible sur une distribution disposant des outils système standards :

# Vérifier que le processeur expose une extension de virtualisation matérielle.
# vmx correspond aux processeurs Intel, svm aux processeurs AMD.
grep -Ewc '(vmx|svm)' /proc/cpuinfo

# Vérifier que le noyau a détecté une IOMMU active.
# Un résultat vide impose de vérifier le micrologiciel et la ligne de démarrage.
dmesg | grep -Ei 'iommu|dmar|amd-vi'

# Vérifier les groupes d'isolation pour le passage direct de périphériques.
# Un périphérique assigné à une VM doit partager son groupe uniquement
# avec des composants explicitement acceptés dans le même périmètre.
find /sys/kernel/iommu_groups/ -type l | sort -V

Un résultat positif sur la première commande ne prouve pas que KVM est exploitable de façon sûre. L’IOMMU peut être désactivée dans le micrologiciel, ignorée par le noyau ou contournée par un groupe de périphériques mal compris. Le passage direct d’une carte graphique ou réseau doit être refusé tant que le groupe d’isolation n’a pas été examiné. Lancer des VM avant cette vérification revient à signer un plan de cloisonnement après avoir percé les murs.

Exploitation : identités, sauvegarde, rotation et reprise

Les comptes d’administration doivent être nominatifs, fédérés si possible et séparés des comptes bureautiques. La fédération d’identité n’est acceptable que si la perte du fournisseur d’identité ne bloque pas toute reprise : un accès d’urgence local, stocké et audité, reste nécessaire. Son usage doit déclencher une alerte immédiate. Un compte d’urgence sans surveillance devient rapidement un compte permanent avec un nom plus romantique.

Les certificats utilisés par les consoles, les interfaces de programmation et les migrations doivent être inventoriés avec leur autorité de certification, leur date d’expiration et leur procédure de renouvellement. Révoquer un certificat ne ferme pas forcément les sessions déjà établies : les sessions longues doivent être limitées, réauthentifiées ou explicitement coupées.

Les sauvegardes doivent couvrir trois objets distincts : les disques des VM, leur configuration et la configuration de l’hyperviseur ou du contrôleur. Restaurer un disque sans sa définition réseau, ses règles de démarrage et ses identifiants de périphériques produit une VM qui existe, ce qui est différent d’une VM récupérable. Les sauvegardes chiffrées exigent une gestion séparée des clés de chiffrement : perdre la clé rend la restauration aussi décorative qu’un extincteur peint sur un mur.

Les instantanés ne remplacent pas une sauvegarde. Ils peuvent figer des données incohérentes, prolonger des chaînes de disques fragiles et conserver des secrets en mémoire. Leur durée de vie doit être courte, leur création journalisée et leur suppression contrôlée. Les tests de restauration doivent vérifier le démarrage, les dépendances réseau, l’intégrité applicative et la rotation des secrets restaurés.

La supervision doit corréler les événements d’administration, les échecs d’authentification, les changements de réseau virtuel, les exports de VM, les migrations et les alertes matérielles. Sur un Type 1 comme sur un Type 2, l’absence de traces transforme une compromission en débat philosophique. Or un hyperviseur compromis ne fournit plus une source de vérité fiable sur lui-même : les journaux doivent sortir vers une plateforme indépendante.

🐝 Ce qui arrive si on s’en passe

Sans choix maîtrisé de l’hyperviseur et de son administration, le socle de confiance grossit et l’isolation entre machines virtuelles se dégrade. Un hyperviseur mal cloisonné élargit le nombre de détenteurs de passe-partout et multiplie les portes laissées ouvertes : une compromission dans une machine invitée peut alors viser la couche de virtualisation et, de là, atteindre les autres invités censés être séparés. Sur un Type 2 posé sur un système d’exploitation généraliste, chaque faille de l’hôte devient aussi une faille du socle, et transformer un poste de travail en mini-cloud multiplie cette surface. La conséquence est qu’un incident cesse d’être confiné à un appartement pour se propager à tout l’immeuble, et que la traçabilité des accès administratifs se dilue à mesure que les privilèges de gestion se dispersent.

🦫 Explication de la marmotte 🍫

Un hyperviseur permet de faire fonctionner plusieurs ordinateurs logiciels sur un même serveur physique. Chaque ordinateur logiciel reçoit une partie du processeur, de la mémoire, du stockage et du réseau. Le processeur aide à empêcher un ordinateur logiciel de lire directement la mémoire d’un autre. Un composant matériel supplémentaire contrôle aussi les accès des cartes réseau et des disques à cette mémoire.

Dans le premier modèle, le programme de virtualisation démarre directement sur le serveur. Dans le second, il fonctionne au-dessus d’un système d’exploitation de bureau ou de serveur. Le second modèle ajoute donc beaucoup de logiciels ayant une influence sur les ordinateurs logiciels : noyau du système, pilotes, interface graphique et programmes installés. Si ce système est compromis, les ordinateurs logiciels le sont potentiellement aussi.

Le premier modèle réduit cette exposition, mais il garde des éléments très puissants : outils d’administration, pilotes, interfaces réseau et services de sauvegarde. Une erreur dans ces éléments peut donner accès à toutes les machines hébergées. Il faut donc limiter les fonctions activées, séparer les réseaux d’administration, contrôler fortement les comptes capables de créer ou modifier une machine, et installer les correctifs.

Une sauvegarde doit inclure les données, la configuration et les clés nécessaires au chiffrement. Si une restauration échoue, une machine peut redémarrer sans retrouver son réseau, ses accès ou ses données lisibles.

À lire aussi

• Évasion de VM et isolation matérielle des hyperviseursComprendre l’évasion de machine virtuelle, les failles d’hyperviseur et les limites de SEV-SNP et TDX face à un hôte compromis.
• Isolation multi-locataire face à un locataire hostileQuelle frontière poser à chaque couche d'une plateforme mutualisée quand l'un des locataires est hostile, du noyau partagé à l'hôte dédié, et ce que chaque palier laisse passer.
• Virtualisation réseau, NFV et data planes ouvertsComprendre la virtualisation réseau comme abstraction d’équipements, de fonctions et de chemins : isolation, overlays, NFV, data planes accélérés et plateformes open source.
• Isolation des conteneurs Docker : namespaces, cgroups et évasionsCe qu'isole réellement un conteneur Docker sous Linux (espaces de noms, cgroups, capacités, seccomp, AppArmor ou SELinux), les évasions documentées et les configurations qui annulent cette isolation.

Pages voisines

La citent

• Isolation des conteneurs Docker : namespaces, cgroups et évasions
• Isolation multi-locataire face à un locataire hostile
• Rowhammer, Spectre et Meltdown, mécanismes et contre-mesures
• Docker ou Podman en auto-hébergement : root, rootless, isolation
• Installer WSL 2 sous Windows 10 et 11, configuration et sécurité

Hyperviseur Type 1 ou Type 2 : lequel choisir

Elle cite

• Attestation distante TPM et démarrage mesuré
• OIDC, SAML et OAuth 2.1 en fédération