Securiser un cluster de virtualisation : le regard d'un RSSI

Pour illustrer ces enjeux, nous avons interroge Marc Delaunay, RSSI d’un groupe de services multi-sites, un profil representatif que nous avons construit a partir de plusieurs temoignages du secteur. Son nom, son parcours et son organisation sont fictifs : ils servent à restituer, sous la forme de questions-reponses avec un expert, des pratiques et des retours d’expérience fréquemment observés dans les environnements de virtualisation d’entreprise.

Pourquoi l’hyperviseur attire autant les attaquants

VM Nerds : Pourquoi l’hyperviseur est-il devenu une cible aussi stratégique pour les attaquants ?

Marc Delaunay : Parce qu’il concentre la valeur opérationnelle du système d’information. Compromettre un poste utilisateur permet parfois de rebondir. Compromettre un serveur applicatif peut interrompre un service. Compromettre la couche de virtualisation peut donner un levier sur des dizaines, voire des centaines de machines virtuelles, leurs disques, leurs réseaux virtuels, leurs sauvegardes et leurs mécanismes de reprise.

L’hyperviseur n’est pas seulement un système qui exécute des VM. Il est au cœur d’un plan de contrôle : création et arrêt de machines, rattachement réseau, montage de médias virtuels, accès aux datastores, snapshots, migrations et parfois intégration avec l’annuaire d’entreprise. Une identité disposant de privilèges élevés sur la plateforme peut modifier l’infrastructure sans avoir besoin d’ouvrir une session dans chaque système invité.

Pour un opérateur de ransomware, l’intérêt est évident. Il peut chercher à arrêter des VM avant chiffrement, à supprimer des snapshots, à effacer des sauvegardes accessibles depuis la plateforme, ou à déployer une image compromise sur plusieurs charges de travail. Pour un attaquant orienté espionnage, l’intérêt est différent : il peut cloner un disque virtuel, monter un VMDK ou un disque équivalent hors ligne, et extraire des données sans laisser les mêmes traces qu’une connexion interactive sur le serveur invité.

Il faut également rappeler un point souvent sous-estimé : la virtualisation réduit le nombre de systèmes à administrer physiquement, mais augmente l’impact de chaque compte d’administration. C’est un gain d’exploitation, à condition d’accepter que le risque se concentre lui aussi.

VM Nerds : Est-ce que cela signifie que l’hyperviseur lui-même est systématiquement vulnérable ?

Marc Delaunay : Non. Le raccourci serait dangereux. Les compromissions les plus courantes ne reposent pas nécessairement sur une faille « zéro jour » dans le noyau de l’hyperviseur. Elles exploitent bien plus souvent une interface d’administration exposée, un mot de passe réutilisé, une absence de MFA, un compte de service sur-privilégié, un correctif non appliqué ou un réseau d’administration insuffisamment segmenté.

L’hyperviseur est une cible privilégiée parce que son administration est puissante, pas parce qu’il serait intrinsèquement moins sûr que les autres composants. La sécurité dépend de l’ensemble : hôte, manager centralisé, API, annuaire, bastion, réseau d’administration, stockage, sauvegarde, supervision et procédures d’exploitation. Pour aller plus loin, consultez notre guide de sécurisation d’un cluster.

Les écarts de configuration les plus fréquents en audit

VM Nerds : Quels sont les défauts que vous retrouvez le plus souvent lors d’audits de plateformes de virtualisation ?

Marc Delaunay : Les mêmes motifs reviennent avec une régularité déconcertante. Le premier est l’exposition du plan de management. On voit encore des interfaces d’administration accessibles directement depuis Internet, souvent derrière une simple redirection NAT, parfois avec un certificat expiré ou auto-signé qui masque l’absence d’une véritable gouvernance d’accès.

Une interface de management ne doit pas être considérée comme un portail applicatif public. Elle doit être accessible uniquement depuis un réseau d’administration dédié, idéalement via un bastion ou une passerelle d’accès à privilèges. Un VPN seul améliore la situation, mais il ne remplace pas la segmentation, le contrôle d’identité fort et la journalisation.

Le deuxième défaut concerne les identités. Beaucoup d’environnements utilisent encore un compte administrateur partagé pour l’administration quotidienne. Cela pose trois problèmes immédiats : aucune traçabilité individuelle fiable, impossibilité de retirer proprement un accès à un administrateur sortant, et difficulté à imposer le MFA si l’identité est générique.

Le troisième point est la confusion entre administration des VM et administration de l’infrastructure. Un administrateur système qui doit redémarrer une VM ou ouvrir sa console n’a pas forcément besoin de créer des port groups, d’attacher des disques à des VM sensibles, de modifier le réseau de management ou d’accéder aux paramètres des hôtes. Les rôles prédéfinis sont rarement utilisés avec suffisamment de granularité, alors que les RBAC permettent généralement de séparer exploitation, sauvegarde, réseau, stockage et sécurité.

VM Nerds : Quels autres écarts techniques méritent une attention particulière ?

Marc Delaunay : J’en citerais plusieurs :

• Des hôtes et appliances de management qui ne suivent pas un cycle de correctifs documenté.
• Des services historiques ou inutiles laissés actifs, par exemple des accès shell, SSH ou des interfaces de gestion hors bande ouverts en permanence.
• L’absence de séparation entre les flux utilisateurs, les flux de VM, la migration à chaud, le stockage, la sauvegarde et le management.
• Des VLAN de management accessibles depuis des postes bureautiques ou des serveurs applicatifs.
• Des journaux locaux non exportés vers une plateforme centralisée, donc vulnérables à l’effacement lors d’une compromission.
• Des snapshots conservés trop longtemps, qui deviennent à la fois un risque de performance et un réservoir de données potentiellement sensibles.
• Des sauvegardes pilotées par un compte disposant de privilèges trop larges sur la plateforme.
• Des images modèles et ISO non gouvernées, parfois accessibles en écriture à trop d’opérateurs.
• Des exceptions pare-feu accumulées au fil des incidents sans revue périodique.

Un audit utile ne se limite pas à vérifier une liste de paramètres. Il cherche aussi à comprendre les chemins d’attaque plausibles. Par exemple : un compte compromis sur le réseau bureautique peut-il atteindre le manager de virtualisation ? Un opérateur de sauvegarde peut-il supprimer les points de restauration ? Un administrateur de VM peut-il attacher le disque d’un contrôleur de domaine à une machine qu’il contrôle ?

Priorités de durcissement pour une PME

VM Nerds : Une PME n’a pas toujours une équipe dédiée à la sécurité. Par quoi commencer avec des ressources limitées ?

Marc Delaunay : Il faut accepter une logique de priorisation. Le but n’est pas de tout faire en même temps, mais de réduire rapidement les scénarios les plus destructeurs. Pour une PME, je recommande un plan en cinq chantiers, dans cet ordre.

Premièrement, fermer l’exposition inutile. Vérifiez immédiatement que les consoles d’administration, API, interfaces web des hôtes et interfaces de gestion hors bande ne sont pas publiées sur Internet. Si un accès distant est nécessaire, imposez un VPN ou, mieux, un bastion avec MFA. Limitez les adresses sources et supprimez les redirections temporaires devenues permanentes.

Deuxièmement, sécuriser les identités privilégiées. Chaque administrateur doit disposer d’un compte nominatif. Les comptes partagés doivent être supprimés ou, lorsqu’ils sont techniquement indispensables, placés sous contrôle strict avec coffre-fort de mots de passe et traçabilité. Le MFA doit être activé pour les comptes d’administration, en particulier sur le manager centralisé, le VPN, le bastion, la sauvegarde et l’annuaire.

Troisièmement, appliquer les correctifs critiques. Cela suppose un inventaire clair : version de chaque hôte, version du manager, firmware lorsque pertinent, compatibilités matérielles et fenêtres de maintenance. Les PME repoussent souvent les mises à jour par crainte d’une indisponibilité. C’est compréhensible, mais l’absence de procédure de maintenance transforme une opération maîtrisable en dette technique permanente.

Quatrièmement, isoler le management. Même sans architecture complexe, il est possible de créer un VLAN d’administration dédié, de filtrer les accès avec un pare-feu inter-VLAN et d’autoriser seulement les flux nécessaires depuis le bastion, les outils de sauvegarde, la supervision et quelques postes d’administration identifiés.

Cinquièmement, protéger et tester les sauvegardes. La sauvegarde n’est pas un simple sujet de capacité. Elle est une frontière de sécurité. Il faut viser au minimum une copie séparée de la production, des identifiants distincts de ceux de l’administration de virtualisation, une rétention adaptée et des tests de restauration réguliers. Pour aller plus loin, consultez le durcissement pratique d’un hôte ESXi.

VM Nerds : Pouvez-vous résumer ce socle sous une forme opérationnelle ?

Marc Delaunay : Oui. Une PME peut démarrer avec cette liste de contrôle, à adapter à son hyperviseur et à ses contraintes :

[ ] Aucune interface de management exposée directement à Internet
[ ] Accès d'administration via VPN ou bastion avec MFA
[ ] Comptes administrateurs individuels, sans identifiant partagé quotidien
[ ] Rôles RBAC revus selon le principe du moindre privilège
[ ] VLAN ou réseau dédié au management des hôtes et du manager
[ ] Filtrage inter-VLAN documenté et limité aux flux nécessaires
[ ] Correctifs critiques appliqués selon une fenêtre de maintenance définie
[ ] Journaux exportés vers une plateforme centralisée ou un collecteur distant
[ ] Sauvegardes séparées, protégées par des identifiants distincts
[ ] Test de restauration réalisé et documenté au moins périodiquement
[ ] Services d'administration non nécessaires désactivés
[ ] Revue trimestrielle des comptes, rôles et règles réseau

Cette liste ne remplace pas une analyse de risque, mais elle évite les erreurs les plus coûteuses. Le meilleur durcissement pour une petite équipe est souvent celui qu’elle peut réellement exploiter, contrôler et maintenir dans le temps.

Retour d’expérience : l’interface de management exposée

VM Nerds : Vous évoquez souvent le risque d’une interface de management publiée. Pouvez-vous décrire un incident représentatif ?

Marc Delaunay : Dans le cas que nous avons reconstruit à partir de plusieurs situations comparables, l’entreprise utilisait une plateforme de virtualisation avec un manager centralisé. Pour faciliter l’intervention d’un prestataire, l’interface web d’administration avait été exposée via une règle NAT. L’intention initiale était temporaire, pendant une migration. La règle est restée en place plus d’un an.

L’accès était protégé par un mot de passe robuste, mais pas par MFA. Pire, le compte utilisé était partagé entre plusieurs intervenants internes et externes. L’organisation ne pouvait donc pas attribuer de manière fiable une action à une personne. Un attaquant a obtenu les identifiants dans le cadre d’une compromission plus large, probablement via réutilisation d’identifiants ou hameçonnage ciblé. Le point essentiel est qu’il n’a pas eu besoin d’exploiter une vulnérabilité complexe : l’interface était accessible et l’identité était suffisante.

Une fois connecté, il a créé une VM utilitaire, lui a attribué un accès réseau interne et a utilisé les capacités de la plateforme pour explorer l’environnement. Des snapshots ont été supprimés sur plusieurs VM critiques. L’attaquant a également tenté de désactiver des tâches de sauvegarde. L’incident a été détecté parce qu’un administrateur a constaté une création de VM non planifiée et une activité inhabituelle en dehors des heures ouvrées.

VM Nerds : Quels ont été les principaux enseignements ?

Marc Delaunay : Le premier enseignement est qu’une interface exposée transforme une faiblesse d’identité en incident d’infrastructure. Le deuxième est que la sécurité ne peut pas reposer sur un seul mot de passe, même complexe. Le MFA aurait considérablement réduit la probabilité de succès de cette attaque.

Le troisième enseignement concerne les journaux. Les traces de connexion existaient, mais elles n’étaient pas corrélées en temps réel avec le reste du SI. Elles n’ont donc pas déclenché d’alerte immédiate. Après l’incident, l’entreprise a mis en place l’export des journaux du manager, des hôtes, du VPN, de l’annuaire et de la solution de sauvegarde vers une collecte centralisée. L’objectif n’était pas de tout surveiller manuellement, mais de définir quelques alertes à forte valeur : connexion d’administration depuis une localisation ou un créneau inhabituel, ajout d’un rôle privilégié, création d’une VM, modification réseau, suppression massive de snapshots, échec répété d’authentification et désactivation de tâches de sauvegarde.

Enfin, le traitement de l’incident a montré l’importance de procédures simples. Les équipes doivent savoir qui peut isoler un hôte, suspendre un compte, bloquer une règle pare-feu, vérifier l’intégrité des sauvegardes et décider d’un arrêt de service. Sans cela, les premières heures sont perdues à chercher les responsabilités au lieu de contenir l’attaque.

Détection, journalisation et réponse à incident

VM Nerds : Quelles activités doivent alerter en priorité sur une plateforme de virtualisation ?

Marc Delaunay : Il faut surveiller les actions qui modifient le plan de contrôle. Une authentification réussie est importante, mais elle devient vraiment intéressante lorsqu’elle est associée à un contexte : origine réseau inhabituelle, compte dormant, heure anormale ou utilisation d’un compte qui ne devrait pas se connecter de façon interactive.

Les événements prioritaires comprennent notamment :

• Création, suppression, clonage ou déplacement de VM.
• Ajout d’un disque existant à une autre VM.
• Création ou modification de comptes, groupes et rôles.
• Élévation de privilèges ou attribution d’un rôle administrateur.
• Modification des réseaux virtuels, des port groups ou des règles de pare-feu.
• Activation de SSH, shell ou autre service d’administration.
• Désactivation de la journalisation, de la supervision ou des tâches de sauvegarde.
• Suppression anormale de snapshots ou de points de restauration.
• Changement de configuration sur un hôte ou sur le manager centralisé.
• Connexions administratives provenant d’adresses IP non attendues.

La détection efficace repose sur une ligne de base. Créer une VM peut être normal dans une équipe de développement et anormal dans un environnement de production très contrôlé. Le contexte métier est donc indispensable. Pour aller plus loin, consultez la sauvegarde comme dernier rempart.

VM Nerds : Quel conseil donneriez-vous pour la réponse à incident ?

Marc Delaunay : Évitez le réflexe de redémarrer ou d’éteindre immédiatement l’hyperviseur. Cela peut interrompre des services critiques, détruire des éléments de preuve et compliquer la restauration. Il faut d’abord qualifier l’incident et contenir ce qui doit l’être. Pour aller plus loin, consultez le licensing VMware sous Broadcom.

Une séquence pragmatique peut ressembler à ceci :

1. Identifier les comptes, hôtes et interfaces potentiellement compromis.
2. Bloquer les accès externes non indispensables et révoquer les sessions actives.
3. Réinitialiser ou désactiver les identités suspectes, en préservant la traçabilité.
4. Isoler les hôtes ou VM concernés si cela est nécessaire et maîtrisé.
5. Exporter les journaux et capturer l'état de configuration avant modification majeure.
6. Vérifier les changements sur les rôles, réseaux, tâches, snapshots et sauvegardes.
7. Contrôler l'intégrité et la disponibilité des sauvegardes hors du périmètre compromis.
8. Restaurer selon un plan validé, puis rechercher les mécanismes de persistance.
9. Documenter les décisions, horaires, actions et impacts.

L’étape souvent négligée est la recherche de persistance. Après une compromission du manager de virtualisation, il faut vérifier les comptes créés, les rôles modifiés, les tâches planifiées, les VM ajoutées, les médias ISO, les scripts d’automatisation et les intégrations API. Restaurer les VM sans assainir le plan de management revient à reconstruire sur une fondation potentiellement compromise.

Sortir d’une sécurité purement documentaire

VM Nerds : Quel message souhaitez-vous laisser aux administrateurs de virtualisation ?

Marc Delaunay : La virtualisation ne doit pas être traitée comme une simple couche technique invisible. C’est une infrastructure de sécurité à part entière. Les équipes qui l’exploitent ont un rôle direct dans la résilience de l’entreprise, au même titre que les équipes réseau, identité ou sauvegarde.

Le bon objectif n’est pas de produire une configuration théorique parfaite. Il faut construire une plateforme où les accès sont limités, les changements attribuables, les correctifs planifiés, les sauvegardes réellement restaurables et les signaux faibles détectables. Une architecture sobre, segmentée et documentée résistera mieux qu’un environnement riche en fonctionnalités mais administré avec des comptes partagés et des exceptions oubliées.

Pour une PME, la progression la plus rentable reste très concrète : supprimer l’exposition publique, imposer le MFA, séparer le réseau de management, réduire les privilèges, centraliser les journaux et tester la restauration. Ces mesures ne rendent pas l’infrastructure invulnérable, mais elles augmentent fortement le coût et la complexité d’une attaque, tout en améliorant les chances de reprise.