Securiser un cluster de virtualisation : guide complet

Un cluster de virtualisation concentre des actifs qui, auparavant, étaient dispersés sur des dizaines de serveurs physiques : systèmes d’exploitation, données métier, identités techniques, sauvegardes, réseaux virtuels et outils d’administration. Cette densité change profondément le modèle de risque. La compromission d’un poste d’administration, d’un compte vCenter trop privilégié ou d’un hôte ESXi exposé peut donner à un attaquant une capacité de destruction transversale : arrêt simultané de VM, exfiltration de disques virtuels, suppression de snapshots, désactivation de sauvegardes et chiffrement massif des datastores.

Les campagnes de ransomware visant ESXi observées depuis 2023 et 2024 ont rappelé un fait parfois sous-estimé : l’hyperviseur n’est pas un simple socle technique. C’est une cible prioritaire. Les attaquants recherchent les interfaces de management, les accès VPN, les identifiants d’administration réutilisés, les vulnérabilités non corrigées et les configurations héritées. Une fois un hôte compromis, ils peuvent exécuter des outils de chiffrement adaptés aux fichiers VMFS, arrêter les machines virtuelles et rendre indisponibles des services entiers en quelques minutes.

La sécurisation ne repose donc pas sur une option isolée. Elle combine durcissement du plan de management, segmentation réseau, contrôle strict des identités, chiffrement, journalisation centralisée, supervision comportementale, sauvegardes réellement isolées et procédures de réponse à incident testées. Ce guide propose une démarche applicable à un environnement VMware vSphere, tout en restant utile pour les principes communs aux autres plateformes de virtualisation. L’objectif est de réduire la surface d’attaque, de limiter le rayon d’impact d’une compromission et de préserver une capacité de reconstruction vérifiable.

Cartographier les surfaces d’attaque du cluster

Avant de modifier une configuration, il faut disposer d’une cartographie opérationnelle du cluster. Elle doit identifier les composants, les flux et les dépendances nécessaires à l’administration comme à la reprise d’activité.

Le périmètre minimal comprend généralement :

• Les hôtes ESXi et leurs interfaces VMkernel.
• vCenter Server et ses services associés.
• Les postes d’administration, bastions et serveurs de rebond.
• Active Directory ou l’annuaire d’entreprise.
• Les services de gestion des certificats, KMS et éventuellement HSM.
• Les réseaux de management, vMotion, stockage, sauvegarde et production.
• Les datastores VMFS, NFS, vSAN ou baies externes.
• Les serveurs de sauvegarde, dépôts, proxies et consoles d’orchestration.
• Les collecteurs de journaux, SIEM, EDR et outils de supervision.
• Les accès distants : VPN, ZTNA, accès prestataires et interfaces hors bande.

Cette cartographie ne doit pas rester documentaire. Elle alimente les règles de pare-feu, les matrices d’habilitation, les contrôles de conformité et les scénarios de réponse à incident.

Identifier les chemins d’administration réels

Dans de nombreux environnements, les hôtes ESXi restent accessibles directement depuis plusieurs VLAN, parfois depuis des réseaux utilisateurs ou des segments serveurs trop larges. Cette situation contredit l’objectif d’un plan de management isolé.

Inventoriez les accès à ces interfaces :

• HTTPS vers vCenter et, si nécessaire, vers les hôtes ESXi.
• SSH et ESXi Shell.
• API vSphere utilisées par les outils de sauvegarde et d’automatisation.
• DNS, NTP, LDAP(S), Active Directory et PKI.
• Syslog sortant vers les collecteurs.
• Accès de gestion matérielle : iDRAC, iLO, XClarity ou équivalent.

Chaque flux doit avoir une source, une destination, un protocole, un port, un propriétaire et une justification. Tout flux sans propriétaire identifié est un candidat à la suppression.

Durcir le plan de management et réduire les accès directs

Le plan de management doit être traité comme une zone d’administration à haute sensibilité. Il ne doit pas être accessible depuis les réseaux de bureautique, les réseaux de VM de production, les VLAN invités ou un VPN ouvert à l’ensemble des collaborateurs.

L’accès doit passer par un bastion administré, journalisé et protégé par une authentification forte. Idéalement, les administrateurs utilisent des comptes dédiés, différents de leurs comptes bureautiques, depuis un poste d’administration durci ou un environnement d’accès privilégié. Pour aller plus loin, consultez le durcissement d’un hôte ESXi exposé. Les recommandations équivalentes côté Microsoft sont documentées dans le guide officiel de planification de la sécurité Hyper-V.

Restreindre SSH et ESXi Shell

SSH est utile pour le diagnostic, mais il est régulièrement détourné après compromission. Le principe recommandé est simple : SSH et ESXi Shell doivent être désactivés par défaut, activés temporairement pour une intervention précise, puis désactivés immédiatement après.

Sur un hôte ESXi, vérifiez l’état des services :

esxcli system maintenanceMode get
esxcli system settings advanced list -o /UserVars/SuppressShellWarning

La gestion effective des services peut être réalisée via l’interface vSphere, PowerCLI ou les profils de configuration selon votre modèle d’exploitation. Limitez également les adresses autorisées à accéder à l’hôte via les règles de pare-feu ESXi.

Exemple de vérification des règles pare-feu :

esxcli network firewall ruleset list
esxcli network firewall ruleset allowedip list -r sshServer

Si SSH doit être maintenu pour une contrainte d’exploitation, appliquez les mesures suivantes :

• Autoriser uniquement les IP des bastions d’administration.
• Désactiver l’authentification par mot de passe lorsque l’environnement le permet.
• Utiliser des clés dédiées, protégées et révoquées lors des départs ou changements de rôle.
• Limiter les comptes pouvant ouvrir une session.
• Centraliser les journaux SSH et corréler les connexions avec les demandes de changement.
• Configurer une alerte sur toute activation du service SSH ou ESXi Shell.

Ne considérez jamais la désactivation de l’avertissement Shell comme une mesure de sécurité. L’objectif est au contraire de conserver une visibilité sur les opérations interactives inhabituelles.

Activer le MFA sur vCenter

vCenter est le point de contrôle central du cluster. Sa compromission peut donner accès à la console, aux API, aux tâches planifiées, aux permissions et aux opérations sur les VM. Le MFA doit donc être imposé aux administrateurs et aux opérateurs disposant d’un accès interactif.

La mise en œuvre dépend de l’architecture d’identité retenue : fédération avec un fournisseur d’identité compatible, intégration avec l’annuaire d’entreprise, authentification adaptative ou accès via un bastion avec MFA obligatoire. Dans tous les cas, évitez que le compte administrateur local historique serve aux opérations quotidiennes.

Conservez un nombre minimal de comptes d’urgence, protégés par des mots de passe longs, uniques, stockés dans un coffre-fort et soumis à une procédure de consultation tracée. Ces comptes doivent être testés périodiquement, sans être utilisés comme comptes d’exploitation.

Maintenir les certificats et la confiance PKI

Les certificats expirés produisent souvent des contournements dangereux : acceptation manuelle d’alertes, désactivation de la vérification TLS ou réutilisation de certificats auto-signés non maîtrisés. Le renouvellement doit être industrialisé et surveillé.

Établissez un inventaire incluant :

• Certificats Machine SSL de vCenter.
• Certificats de service vCenter.
• Certificats des hôtes ESXi.
• Certificats des interfaces de sauvegarde et de supervision.
• Chaînes d’autorité de certification internes.
• Dates d’expiration et propriétaires techniques.

Définissez des alertes à 90, 60 et 30 jours avant expiration. Lorsque l’organisation possède une PKI interne, privilégiez des certificats émis par cette autorité, avec des noms DNS corrects et une chaîne de confiance déployée sur les composants concernés.

Segmenter les réseaux de virtualisation

La segmentation réduit la capacité d’un attaquant à pivoter depuis une VM compromise vers le plan de management. Elle protège aussi les flux de migration, de stockage et de sauvegarde contre l’écoute ou l’injection sur des segments insuffisamment isolés.

Un cluster ne doit pas reposer sur un unique réseau plat, même si les VLAN sont distincts sur le papier. Les règles de filtrage inter-VLAN, les listes de contrôle d’accès sur les commutateurs et les pare-feu distribués doivent matérialiser cette séparation.

Isoler management, vMotion et stockage

Le VLAN de management ne doit pas transporter les flux utilisateurs ou les flux applicatifs ordinaires. Les accès à vCenter, ESXi et aux contrôleurs matériels sont limités aux bastions, au SIEM, aux services d’infrastructure strictement nécessaires et aux outils de sauvegarde explicitement autorisés.

Le trafic vMotion mérite une attention particulière. Même lorsqu’il est isolé sur un VLAN dédié, il faut considérer qu’un réseau accessible à trop d’équipements reste exposé. Activez le chiffrement vMotion lorsque les contraintes de performance et de compatibilité ont été validées. Cette fonction réduit le risque de divulgation de mémoire lors d’une migration.

Le réseau de stockage doit être encore plus strict. Les hôtes ESXi et les équipements de stockage sont les seuls équipements légitimes sur ce segment, sauf besoins documentés de supervision. Évitez d’y raccorder des postes d’administration, des VM généralistes ou des services d’annuaire.

Appliquer le filtrage au plus près des charges

Les VLAN ne remplacent pas les contrôles de sécurité. Pour les charges sensibles, utilisez un pare-feu distribué, des ACL ou une segmentation basée sur les groupes de sécurité afin de limiter les communications Est-Ouest entre VM.

Les règles doivent notamment empêcher une VM applicative compromise de joindre :

• Les interfaces de management des hyperviseurs.
• Les ports d’administration de vCenter.
• Les services d’administration des sauvegardes.
• Les contrôleurs de domaine, sauf nécessité explicite.
• Les interfaces de gestion des baies de stockage.
• Les autres zones applicatives sans flux métier identifié.

Gérer les comptes, rôles et privilèges

Le compte administrator@vsphere.local, les membres d’un groupe d’administration global et les comptes de service de sauvegarde sont des cibles prioritaires. Une politique de moindre privilège doit distinguer les tâches d’exploitation, de sécurité, de sauvegarde, de réseau et d’audit.

Évitez les droits attribués directement à des utilisateurs. Utilisez des groupes d’annuaire dédiés, avec une nomenclature claire, un propriétaire et une revue périodique. Les permissions doivent être accordées au niveau le plus bas possible dans l’arborescence vCenter, sauf justification explicite. Pour aller plus loin, consultez le regard d’un RSSI sur la sécurité des clusters.

Séparer les comptes humains et les comptes de service

Un compte de service ne doit jamais être partagé avec un administrateur humain. Il doit être dédié à une intégration précise, documenté, limité fonctionnellement et surveillé. Les secrets associés doivent être stockés dans un coffre-fort, renouvelés selon une périodicité définie et remplacés lors d’un changement de fournisseur, d’outil ou d’équipe.

Pour les comptes humains, imposez :

• Une identité nominative.
• Un compte d’administration distinct du compte bureautique.
• Le MFA pour les accès interactifs.
• Une élévation temporaire de privilèges lorsque c’est possible.
• Une revue trimestrielle des appartenances aux groupes à privilèges.
• Une désactivation rapide à la sortie d’un collaborateur ou prestataire.

Les permissions vCenter doivent être auditées après tout projet de migration, de fusion d’infrastructure ou d’intégration d’outil. Ces périodes introduisent fréquemment des droits temporaires qui deviennent permanents par oubli.

Cette discipline s’applique aussi lorsque des plateformes tierces s’appuient sur le cluster : un système de gestion d’actifs comme IBM Maximo, déployé sur un cluster OpenShift lui-même virtualisé, ajoute une couche de comptes de service et de rôles qui doit suivre les mêmes principes de moindre privilège. Ce guide sur le durcissement d’un cluster OpenShift hébergeant Maximo détaille les contrôles à appliquer au niveau applicatif, en complément du durcissement de l’hyperviseur sous-jacent.

Chiffrer les VM au repos et en mouvement

Le chiffrement protège contre certains scénarios de vol de données, d’accès non autorisé aux fichiers de VM et d’interception de flux de migration. Il ne remplace pas le contrôle d’accès : un administrateur disposant des permissions adéquates peut toujours réaliser des opérations légitimes mais destructrices. Il complète les autres couches de défense.

Chiffrement des VM et intégration KMS

Le chiffrement des VM implique généralement un serveur de gestion des clés compatible KMIP, idéalement redondé et séparé du cluster protégé. Le KMS devient un composant critique : sans clés disponibles, certaines opérations de démarrage, de migration ou de restauration peuvent échouer.

Avant un déploiement large, validez :

• La haute disponibilité du KMS.
• La sauvegarde des clés et de la configuration KMS.
• La séparation des rôles entre administration KMS et administration vSphere.
• Les procédures de restauration après perte d’un vCenter ou d’un site.
• L’impact sur les opérations de sauvegarde, réplication et reprise après sinistre.
• Les capacités de l’outil de sauvegarde à traiter les VM chiffrées.

Le chiffrement doit être appliqué selon une classification des données. Commencez par les VM hébergeant des données réglementées, des secrets applicatifs, des services d’identité ou des composants d’administration.

Utiliser vTPM pour les charges compatibles

Le vTPM permet à une VM d’exposer un module de plateforme sécurisée virtuel au système invité. Il est utile pour des fonctions telles que BitLocker, Secure Boot, Windows Hello for Business ou les mécanismes d’attestation applicative.

L’ajout d’un vTPM nécessite généralement que la VM soit chiffrée. Cela a des conséquences d’exploitation : migration, clonage, restauration et gestion des clés doivent être testés. Ne déployez pas vTPM comme une case à cocher uniforme ; intégrez-le à une stratégie de configuration des systèmes invités.

Chiffrer vMotion

Le chiffrement vMotion protège les données de mémoire transférées pendant une migration. Les modes disponibles permettent généralement de choisir entre un chiffrement obligatoire ou opportuniste selon la compatibilité des hôtes et les exigences de sécurité.

Le bon choix dépend de votre tolérance au risque :

• Mode obligatoire pour les VM sensibles et les environnements réglementés.
• Mode opportuniste lorsqu’une transition progressive est nécessaire.
• Validation préalable de l’impact CPU, de la latence et de la compatibilité matérielle.

Les migrations inter-sites, les migrations longues distances et les environnements avec forte densité mémoire doivent faire l’objet de tests de charge avant généralisation.

Surveiller les hyperviseurs et détecter les comportements anormaux

Un hyperviseur peut être compromis sans générer les mêmes signaux qu’un serveur Windows ou Linux classique. Les agents EDR ne sont pas toujours disponibles ou souhaitables sur ESXi. La détection repose donc fortement sur la centralisation des journaux, l’analyse des événements vCenter, la télémétrie réseau et la surveillance de l’intégrité de configuration.

Configurez l’envoi distant des journaux ESXi vers une plateforme centralisée, protégée contre l’altération. Les journaux locaux ne suffisent pas : un attaquant disposant de privilèges élevés peut tenter de les effacer ou de les rendre indisponibles.

Exemple de configuration Syslog distant sur ESXi :

esxcli system syslog config set --loghost='udp://syslog.exemple.local:514'
esxcli system syslog reload
esxcli system syslog config get

Préférez des transports chiffrés lorsque votre collecteur et votre version d’ESXi le permettent. Vérifiez aussi que les équipements réseau, vCenter, le KMS, les bastions et les serveurs de sauvegarde envoient leurs journaux au même écosystème de supervision.

Cas de détection à prioriser

Les règles SIEM et les alertes doivent couvrir au minimum :

• Activation de SSH ou ESXi Shell.
• Connexions SSH depuis une adresse non autorisée.
• Création ou modification de comptes locaux.
• Ajout de permissions globales ou élévation de privilèges.
• Désactivation de l’audit, du Syslog ou des alertes.
• Passage d’un hôte en mode maintenance hors fenêtre planifiée.
• Arrêt simultané d’un nombre inhabituel de VM.
• Création, suppression ou consolidation massive de snapshots.
• Modification des paramètres de chiffrement ou de KMS.
• Déploiement de VIB non autorisés ou activation du mode acceptant des paquets non signés.
• Activité anormale sur les datastores : renommage, suppression ou écriture massive de fichiers de VM.

La supervision doit inclure la santé de la journalisation elle-même. Une baisse brutale du volume de logs, la perte de connectivité avec un collecteur ou l’arrêt d’un agent de collecte est un événement de sécurité, pas un simple incident de supervision.

Préparer la réponse à un ransomware ciblant ESXi

Les ransomwares visant ESXi cherchent généralement à arrêter les VM puis à chiffrer ou renommer les fichiers de disques virtuels et de configuration présents sur les datastores. L’attaque peut suivre la compromission d’un accès distant, d’un compte d’administration, d’une vulnérabilité non corrigée ou d’un outil tiers connecté à vCenter.

La réponse doit être préparée avant l’incident. Une procédure qui n’a jamais été testée risque d’échouer au moment où l’équipe doit arbitrer entre disponibilité, préservation des preuves et reconstruction.

Actions immédiates de confinement

En cas de suspicion crédible, appliquez un processus de décision rapide avec l’équipe sécurité, l’exploitation, la direction de crise et les responsables métier. Les premières actions visent à interrompre la propagation tout en préservant les éléments utiles à l’investigation. Pour aller plus loin, consultez la segmentation réseau d’un cluster.

1. Isoler les hôtes ou le cluster suspect du réseau de management, sans couper aveuglément les réseaux nécessaires aux preuves.
2. Bloquer les sessions VPN, bastions et comptes suspects associés à l’incident.
3. Révoquer ou désactiver les jetons, sessions et comptes à privilèges compromis.
4. Préserver les journaux vCenter, ESXi, pare-feu, VPN, Active Directory et sauvegarde.
5. Identifier les datastores, VM et hôtes touchés.
6. Vérifier si les dépôts de sauvegarde, consoles de backup et comptes de service sont affectés.
7. Éviter tout redémarrage non nécessaire avant collecte des éléments d’investigation.

Ne lancez pas immédiatement une restauration sur le cluster compromis. Une restauration rapide dans un environnement où l’identité, vCenter ou les sauvegardes restent compromis peut réintroduire l’attaquant ou provoquer une seconde destruction. Pour aller plus loin, consultez la sauvegarde comme dernier rempart.

Reconstruire depuis une base de confiance

La reprise doit s’appuyer sur une zone propre : matériel validé, hyperviseurs réinstallés à partir d’images maîtrisées, correctifs appliqués, certificats renouvelés, accès d’administration recréés et journalisation active avant remise en production.

L’ordre de reprise est important :

1. Restaurer les services d’identité et les composants de sécurité nécessaires.
2. Réinstaller ou reconstruire vCenter dans une zone contrôlée.
3. Reconfigurer les hôtes ESXi selon une configuration de référence validée.
4. Rétablir le KMS et vérifier l’accès aux clés.
5. Restaurer les services de sauvegarde et valider l’intégrité des dépôts.
6. Restaurer les VM par priorité métier, dans des réseaux de quarantaine si nécessaire.
7. Contrôler les systèmes restaurés avant exposition aux réseaux de production.

Les sauvegardes doivent suivre une stratégie incluant une copie isolée ou immuable, avec des identifiants séparés de ceux du domaine d’administration courant. Testez régulièrement la restauration complète d’une VM, mais aussi la reconstruction de vCenter, d’un hôte et d’un datastore.

Mettre en place des audits de conformité continus

Un audit annuel est utile, mais insuffisant si les environnements changent chaque semaine. Les contrôles de configuration doivent être répétés après les mises à jour, les extensions de cluster, les migrations, les projets de sauvegarde et les changements d’identité.

Créez une baseline de sécurité couvrant notamment :

• Versions ESXi et vCenter supportées et corrigées.
• Configuration de SSH, ESXi Shell et pare-feu hôte.
• Paramètres de journalisation distante.
• Serveurs NTP et synchronisation horaire.
• Certificats valides et conformes à la PKI.
• Configuration des rôles et permissions.
• État du MFA sur les accès d’administration.
• Réseaux VMkernel et séparation des flux.
• Paramètres de chiffrement, KMS et vMotion.
• Configuration de Secure Boot, TPM matériel et attestation lorsque disponible.
• Liste des VIB installés et conformité de l’image hôte.
• Résultats de restauration de sauvegardes.

Mesurer, corriger, puis prouver

Un programme de conformité utile ne se limite pas à produire un rapport. Il doit associer chaque écart à un propriétaire, une échéance, une criticité et une preuve de correction. Les exceptions doivent être formalisées, validées par le risque et limitées dans le temps.

Les indicateurs suivants sont particulièrement pertinents pour une gouvernance RSSI :

• Pourcentage d’hôtes conformes à l’image de référence.
• Nombre de comptes disposant de droits d’administration globale.
• Taux de couverture MFA des accès privilégiés.
• Nombre de services SSH actifs hors fenêtre de maintenance.
• Délai moyen d’application des correctifs critiques.
• Taux de succès des tests de restauration.
• Couverture de journalisation des hôtes et de vCenter.
• Nombre d’écarts de segmentation réseau ouverts.

La sécurité d’un cluster se construit dans la durée. Le durcissement initial est indispensable, mais la valeur réelle vient de la discipline opérationnelle : suppression des accès non nécessaires, revues d’habilitation, contrôle des changements, tests de reprise et capacité à détecter rapidement une activité anormale.