vSAN en 2026 : architecture ESA/OSA, licences VCF et sécurité

VMware vSAN est la couche de stockage logiciel intégrée à l'hyperviseur ESX (anciennement ESXi) : elle agrège les disques locaux des hôtes d'un cluster vSphere pour former un datastore partagé, piloté par des politiques de stockage définies machine virtuelle par machine virtuelle. En 2026, trois sujets dominent les projets : le choix entre l'architecture historique OSA (Original Storage Architecture) et l'architecture tout NVMe ESA (Express Storage Architecture), la capacité incluse dans les offres VMware Cloud Foundation (VCF) et vSphere Foundation (VVF), et la sécurité d'un stockage qui partage le sort de l'hyperviseur. Un attaquant qui prend la main sur vCenter ou sur un hôte ESX accède potentiellement à toutes les données du cluster. Ce guide détaille l'architecture, les règles de licence, le chiffrement, le durcissement et la supervision, en complément de notre dossier sur la sécurité de VMware vSphere et ESXi en 2026.

Qu'est-ce que VMware vSAN ?

Le principe relève de l'infrastructure hyperconvergée (HCI) : le calcul et le stockage cohabitent dans les mêmes serveurs. Chaque hôte apporte ses disques NVMe ou SSD, et le module vSAN, chargé dans le VMkernel, répartit les données sur plusieurs hôtes pour survivre à une panne. Il n'y a ni baie externe, ni fabric Fibre Channel, ni contrôleur de stockage dédié : le réseau Ethernet relie les nœuds.

Pour une équipe d'infrastructure, l'intérêt est opérationnel. Le stockage se provisionne depuis vCenter au moment où l'on crée une machine virtuelle, sans demande à une équipe SAN. La politique attachée au disque virtuel décide du nombre de pannes tolérées, du schéma RAID et de l'emplacement des copies. L'ajout d'un hôte augmente à la fois la puissance de calcul et la capacité.

Pour une équipe de sécurité, cette intégration change la frontière de confiance. Dans une architecture à trois tiers, l'administrateur de la baie et l'administrateur vSphere sont souvent deux personnes distinctes, avec deux consoles et deux annuaires. Avec vSAN, les droits sur vCenter donnent la main sur la donnée elle-même. Le réseau de stockage devient un simple réseau VMkernel, qu'il faut cloisonner avec la même rigueur qu'un SAN physique.

vSAN et SAN traditionnel : ce qui change vraiment

Un SAN classique expose des LUN depuis une baie, formatées en VMFS par les hôtes. vSAN ne présente pas de LUN : il stocke des objets et applique une politique à chacun. La résilience ne repose plus sur les contrôleurs d'une baie, mais sur la répartition des composants entre hôtes ou domaines de panne. Le dimensionnement suit donc le nombre de serveurs, et non la taille d'un châssis.

Comment vSAN stocke les données : objets, composants et politiques

Chaque machine virtuelle placée sur un datastore vSAN est décomposée en objets : répertoire de la VM, disques virtuels VMDK, fichier d'échange, deltas de snapshots. Chaque objet est lui-même découpé en composants répartis sur plusieurs hôtes selon la politique choisie. Par défaut, chaque hôte constitue un domaine de panne ; des domaines de panne explicites permettent de raisonner par baie ou par salle.

La gestion par politiques, ou SPBM (Storage Policy Based Management), fixe les règles appliquées à chaque objet. Les paramètres les plus structurants sont les suivants :

• Failures to tolerate (FTT) : nombre de pannes d'hôtes ou de domaines de panne que l'objet doit supporter sans perte de données.
• Méthode de tolérance : miroir RAID-1 ou codage d'effacement RAID-5/6, plus économe en capacité.
• Tolérance de site : réplication entre les deux sites d'un cluster étendu.
• Réservation d'espace et limites d'IOPS : garanties de capacité et plafonds de performance par objet.

Le nombre d'hôtes conditionne les schémas disponibles. Avec l'architecture ESA, un RAID-1 tolérant une panne exige trois hôtes, le RAID-5 adaptatif fonctionne en 2+1 dès trois hôtes et bascule en 4+1 à partir de six, et le RAID-6 en 4+2 requiert six hôtes. Lorsqu'un cluster de six hôtes perd un nœud, vSAN repasse automatiquement d'un schéma 4+1 à 2+1 après vingt-quatre heures.

Sur le plan de la sécurité, une politique est un paramètre sensible. Passer un objet en FTT=0 supprime toute redondance : une panne de disque devient une perte de données. Ce type de modification, comme la suppression massive d'objets, doit être réservé à des rôles précis et journalisé. Dans VCF 9.1, la fonction Auto-RAID ajuste automatiquement la résilience par défaut à la taille du cluster, ce qui réduit les erreurs de configuration manuelles.

vSAN OSA ou vSAN ESA : comparer les deux architectures

L'architecture originale, OSA, organise les disques de chaque hôte en groupes de disques. Chaque groupe associe un périphérique de cache à un maximum de sept périphériques de capacité, avec jusqu'à cinq groupes par hôte. Le cache absorbe les écritures et accélère les lectures, puis les données sont déstockées vers la capacité. OSA accepte des configurations hybrides ou 100 % flash, en SAS, SATA ou NVMe.

L'architecture ESA, introduite avec vSAN 8 en 2022, supprime le niveau de cache. Chaque hôte forme un pool de stockage dans lequel chaque périphérique NVMe TLC sert à la fois à la performance et à la capacité. La documentation VCF 9.1 exige au moins 128 Go de mémoire par hôte, et Broadcom impose des périphériques certifiés d'au moins 1,6 To. Les disques SAS et SATA ne sont pas pris en charge en ESA.

Broadcom présente ESA comme l'architecture recommandée pour les nouveaux déploiements depuis vSAN 8. Les profils ReadyNode ont été revus à la baisse en novembre 2025 pour abaisser le ticket d'entrée, et un réseau 10 GbE reste admis pour les plus petits profils. La déduplication globale, la nouvelle compression et les snapshots natifs à faible impact sont réservés à ESA.

Passer d'OSA à ESA

Le passage d'OSA à ESA ne se fait pas par une simple mise à jour logicielle, car le matériel et le format sur disque diffèrent. La démarche consiste à créer un nouveau cluster ESA, à y déplacer les machines virtuelles par Storage vMotion, puis à décommissionner l'ancien cluster. Depuis VCF 9.1, le mode mixte des datastores distants ESA et OSA facilite cette transition progressive.

Topologies vSAN : HCI, deux nœuds, cluster étendu et cluster de stockage

Le cluster HCI sur un seul site compte au minimum trois hôtes ESX, reliés en général sur le même réseau de niveau 2. C'est la topologie la plus courante. Pour le domaine de gestion de VCF, Broadcom exige toutefois quatre hôtes sur un site, et huit hôtes répartis à parts égales lorsque ce domaine est étendu sur deux zones de disponibilité.

Le cluster à deux nœuds vise les agences et sites distants. Deux hôtes locaux hébergent les données, et un hôte témoin, souvent une appliance virtuelle installée sur le site central, conserve uniquement les composants témoins pour arbitrer en cas de partition. Le cluster étendu applique la même logique entre deux sites dont la latence réseau ne dépasse pas cinq millisecondes, avec un témoin sur un troisième site.

Le cluster de stockage vSAN, anciennement vSAN Max, sépare les rôles : ses hôtes ne fournissent que de la capacité, montée à distance par des clusters de calcul. Basé sur ESA, il exige au moins quatre hôtes et un réseau d'au moins 10 GbE, Broadcom recommandant 25 GbE dédiés. VCF 9.0 permet de séparer le trafic des clients de celui du stockage interne, sur des interfaces VMkernel distinctes.

Licences vSAN en 2026 : capacité incluse dans VCF et VVF

Depuis le rachat de VMware par Broadcom, vSAN n'est plus vendu en licence perpétuelle. Il est inclus, en quantité limitée, dans les abonnements par cœur VMware Cloud Foundation et vSphere Foundation, avec un minimum de seize cœurs facturés par processeur, même lorsqu'un processeur en compte moins. La capacité supplémentaire s'achète sous forme d'extension « VMware vSAN » exprimée en tébioctets (TiB).

Le point le plus souvent mal compris concerne l'assiette de calcul. Broadcom compte la capacité brute des disques apportés au cluster, et non la capacité utile affichée dans le client vSphere. La vue de capacité du client affiche l'espace disponible du datastore, qui ne correspond pas à la capacité physique à licencier. L'éditeur fournit donc un module PowerCLI pour établir le décompte exact des cœurs et des TiB.

# Décompte des cœurs et des TiB vSAN (module PowerCLI fourni dans la KB 313548)
Connect-VIServer -Server vcenter.exemple.local
Import-Module .\FoundationCoreAndTiBUsage.psm1
Get-FoundationCoreAndTiBUsage -DeploymentType VCF
Get-FoundationCoreAndTiBUsage -ClusterName "CL-VSAN-01" -DeploymentType VVF -CSV

Avec VCF 9.0, la gestion des licences a été simplifiée : un environnement VCF n'utilise plus que deux licences, l'une en cœurs pour la plateforme, l'autre en TiB pour vSAN. Elles s'attribuent à l'instance vCenter depuis VCF Operations, et tous les clusters de ce vCenter sont alors couverts. Sans licence, vSAN fonctionne en mode évaluation pendant quatre-vingt-dix jours.

Ce que la licence change pour la sécurité

Le décompte de licence est aussi un exercice d'inventaire : il recense les hôtes, les processeurs et les disques réellement en service. Un écart entre l'inventaire de sécurité et le rapport PowerCLI signale souvent un hôte oublié, donc non patché. À l'inverse, des arbitrages de coût ont conduit certaines organisations à comparer d'autres plateformes, comme le montre notre comparatif sécurité entre Proxmox, VMware et Hyper-V.

Nouveautés de vSAN dans VCF 9.0 et VCF 9.1

VCF 9.0, disponible depuis juin 2025, a surtout renforcé la protection des données. La réplication de vSAN vers vSAN, orchestrée par VMware Live Recovery, autorise un objectif de point de reprise descendant jusqu'à une minute. Cette version a aussi introduit en disponibilité limitée la déduplication globale, la séparation du trafic des clients et la prise en charge de 500 partages par cluster dans vSAN File Services.

VCF 9.1, annoncé en mai 2026, généralise les gains d'efficacité. Selon le blog technique VMware du 7 mai 2026, la déduplication globale devient disponible pour les clusters HCI de 3 à 64 hôtes et pour les clusters de stockage, y compris avec le chiffrement au repos. Elle n'est en revanche pas prise en charge sur les clusters étendus et à deux nœuds.

Les autres évolutions de la branche 9.1 à suivre sont les suivantes :

• Compression ZSTD toujours active, qui remplace progressivement LZ4 au fil des réécritures de données.
• Auto-RAID, qui ajuste la résilience par défaut à la taille du cluster.
• Stockage objet compatible S3 intégré, en préversion technique dans la version 9.1.1 du 3 septembre 2026.
• ReadyNodes QLC réservés aux environnements de cyber-récupération.
• Correctifs à chaud d'ESX sur les hôtes équipés d'un TPM, et récupération après rançongiciel vers des salles blanches isolées sur site.

Un détail mérite l'attention des équipes de sécurité : pour dédupliquer des données chiffrées, le traitement en arrière-plan déchiffre temporairement les blocs en mémoire. La protection au repos reste intacte, mais la mémoire des hôtes contient des données en clair, comme pour toute machine virtuelle en fonctionnement. Le durcissement de l'hyperviseur reste donc la première ligne de défense.

Modèle de menace : pourquoi un cluster vSAN attire les rançongiciels

L'hyperconvergence concentre la valeur : un seul plan de contrôle administre le calcul, le réseau virtuel et le stockage. Pour un groupe criminel, compromettre vCenter ou un hôte ESX revient à atteindre toutes les machines virtuelles et leurs disques en une opération. C'est la raison pour laquelle les opérateurs de rançongiciels développent des chiffreurs dédiés aux hyperviseurs.

L'avis conjoint #StopRansomware AA24-109A de la CISA, mis à jour le 13 novembre 2025, rappelle qu'Akira a déployé dès avril 2023 une variante Linux visant ESXi. Les auteurs y décrivent aussi le contournement de la protection d'un contrôleur de domaine : arrêt de la VM, copie de ses fichiers VMDK et rattachement à une nouvelle VM pour extraire la base NTDS.dit.

Ce dernier scénario illustre une limite essentielle : le chiffrement au repos ne protège pas contre un attaquant qui détient des droits d'administration sur vCenter ou ESX. Pour un hôte autorisé, les données sont déchiffrées de manière transparente. Le chiffrement répond au vol de disques ou à la mise au rebut, pas à l'usurpation d'un compte privilégié.

Les vulnérabilités de l'hyperviseur complètent le tableau. Le CERT-FR a signalé dans son avis CERTFR-2025-AVI-0177 du 5 mars 2025 que VMware jugeait activement exploitées trois failles touchant ESXi 7.0, ESXi 8.0 et VMware Cloud Foundation. Notre analyse des hyperviseurs ESXi ciblés par les APT détaille ces campagnes.

Scénarios à intégrer à l'analyse de risque

• Vol d'identifiants d'administration vCenter ou d'un annuaire Active Directory auquel les hôtes ESX sont joints.
• Exploitation d'une faille ESX ou vCenter non corrigée, ou évasion depuis une machine virtuelle compromise.
• Modification malveillante des politiques de stockage, suppression d'objets ou mise hors service d'hôtes pour provoquer une perte de données.
• Sabotage du gestionnaire de clés : sans clé de chiffrement de clés, les hôtes ne peuvent plus déchiffrer leurs disques après redémarrage.
• Écoute du réseau vSAN lorsqu'il n'est ni isolé ni chiffré, et vol physique de disques non chiffrés.

Chiffrement vSAN : données au repos et en transit

Le chiffrement au repos, ou D@RE (Data-at-Rest Encryption), protège tout le contenu du datastore. Selon la documentation Broadcom, vCenter obtient d'un gestionnaire de clés une clé de chiffrement de clés (KEK) AES-256 et ne conserve que son identifiant. Chaque disque reçoit sa propre clé de chiffrement de données (DEK), et l'hôte chiffre en AES-256 XTS. Les DEK sont stockées chiffrées par la KEK, qui n'est jamais écrite sur disque.

Deux sources de clés sont possibles. Un serveur de gestion de clés externe, ou KMS, dialogue en KMIP avec vCenter et les hôtes. Le Native Key Provider, disponible depuis vSAN 7.0 Update 2, se passe de KMS externe : vCenter génère la KEK et la pousse vers les hôtes. Broadcom recommande alors de sauvegarder ce fournisseur et de stocker la sauvegarde, avec son mot de passe, hors du cluster chiffré.

Après un redémarrage, un hôte doit récupérer la KEK pour relire ses disques. La persistance des clés dans un module TPM 2.0 permet de redémarrer même si le serveur de clés est momentanément injoignable. Cette option améliore la disponibilité, mais elle suppose des TPM 2.0 correctement configurés sur chaque hôte, idéalement associés au démarrage sécurisé UEFI.

Le chiffrement en transit, ou DIT (Data-in-Transit Encryption), chiffre en AES-256 le trafic de données et de métadonnées entre hôtes, y compris vers le témoin et pour vSAN File Services. Il impose la confidentialité persistante, ne requiert aucun gestionnaire de clés et authentifie chaque hôte lorsqu'il rejoint le cluster. Il s'active indépendamment du chiffrement au repos, au niveau du cluster.

Côté conformité, Broadcom indique que le module cryptographique du VMkernel, utilisé par vSphere et vSAN pour tous leurs services de chiffrement, a obtenu une validation FIPS 140-3 en septembre 2024. Lors d'un changement de fournisseur de clés, vSAN réalise un renouvellement superficiel des clés, sans réécrire les données ; un renouvellement profond, plus long, réécrit l'ensemble avec de nouvelles DEK.

Cloisonner et chiffrer le réseau de stockage vSAN

Le trafic vSAN doit circuler sur des interfaces VMkernel dédiées, dans un VLAN réservé et non routé, jamais partagé avec la gestion ou les machines virtuelles. Lorsque vSAN est activé, les règles nécessaires sont ajoutées automatiquement au pare-feu d'ESX, notamment CMMDS en UDP 12321 pour l'appartenance au cluster et RDT en TCP 2233 pour les entrées-sorties. Aucune ouverture manuelle n'est requise.

La redondance réseau relève aussi de la sécurité, au sens de la disponibilité : deux cartes physiques en association, des commutateurs distincts et une MTU cohérente de bout en bout. Pour les clusters à deux nœuds et étendus, la séparation du trafic témoin évite d'exposer le réseau de données au site distant. Le chiffrement en transit protège enfin les échanges lorsque le cloisonnement ne suffit pas.

Le chiffrement au repos ajoute un flux à maîtriser : les hôtes dialoguent directement avec le serveur de clés. vSAN gère pour cela une règle de pare-feu dédiée, vsanEncryption, qui n'autorise que l'adresse du KMS contacté, le temps de l'échange. Sur le réseau physique, limitez l'accès au KMS aux interfaces de gestion des hôtes et de vCenter, et alertez sur toute autre source.

Durcir l'administration de vCenter et des hôtes ESX

L'administration constitue le véritable point de bascule d'un cluster hyperconvergé. Protégez vCenter comme un contrôleur de domaine : authentification multifacteur via une fédération d'identité, comptes d'administration nominatifs distincts des comptes bureautiques, rôles au moindre privilège et séparation des privilèges cryptographiques. Sur les hôtes, appliquez le mode verrouillage, désactivez SSH hors maintenance et n'autorisez que des binaires signés. Notre guide de durcissement de VMware ESXi détaille ces réglages.

Broadcom publie un guide de configuration de sécurité et de durcissement pour VCF dans son dépôt officiel vcf-security-and-compliance-guidelines sur GitHub. Il contient des contrôles d'audit propres au chiffrement vSAN, pour ESA comme pour OSA, et des ressources consacrées à la défense contre les rançongiciels. C'est la base de référence à confronter à votre configuration réelle.

# Audit en lecture seule d'un hôte membre d'un cluster vSAN
esxcli vsan cluster get                  # appartenance et état du cluster
esxcli vsan network list                 # interfaces VMkernel portant vSAN
esxcli vsan network security get         # état du chiffrement en transit
esxcli vsan encryption info get          # chiffrement au repos et fournisseur de clés
esxcli system settings encryption get    # mode de protection de la configuration (TPM)
esxcli network firewall ruleset list | grep -i -E "cmmds|rdt|vsan"
esxcli vsan debug object health summary get   # santé des objets

Ordre de priorité recommandé

1. Appliquer les correctifs de sécurité d'ESX et de vCenter publiés dans les avis VMSA.
2. Isoler l'administration : réseau de gestion dédié, poste d'administration durci, MFA.
3. Cloisonner le réseau vSAN et activer le chiffrement en transit.
4. Activer le chiffrement au repos avec un gestionnaire de clés résilient et indépendant.
5. Centraliser les journaux et alerter sur les changements sensibles.

Résilience et cyber-récupération des données vSAN

La tolérance aux pannes d'une politique de stockage n'est pas une sauvegarde. Un FTT=2 protège contre la perte de deux hôtes, pas contre un administrateur malveillant qui supprime une VM, ni contre un chiffreur qui réécrit des fichiers VMDK. De même, un snapshot stocké sur le même datastore disparaît avec lui si le cluster est compromis ou détruit.

Avec ESA, vSAN Data Protection crée des snapshots locaux à faible impact et, depuis VCF 9.0, peut répliquer vers un autre cluster vSAN, avec une orchestration de reprise par VMware Live Recovery. VCF 9.1 ajoute la récupération après rançongiciel vers des salles blanches isolées sur site, ainsi que des ReadyNodes QLC destinés à ces environnements. Ces fonctions réduisent les délais de reprise, sans remplacer une copie indépendante.

La règle à retenir tient en une phrase : conservez une sauvegarde hors du cluster, isolée de l'annuaire de production, avec une copie immuable ou hors ligne et des restaurations testées régulièrement. Les recommandations de la CISA pour Akira vont dans le même sens : sauvegardes hors ligne et tests réguliers de la restauration. Le serveur de sauvegarde, souvent ciblé en premier, mérite le même durcissement que vCenter.

Retour terrain : Cas typique rencontré en mission — le plan de reprise vSAN suppose souvent que le serveur de clés externe sera disponible, alors qu'il tourne lui-même en VM sur le cluster chiffré. Après un arrêt complet, les hôtes ne peuvent plus déverrouiller les disques. Autre écart fréquent : la sauvegarde est documentée, mais seule la restauration d'un fichier isolé a été testée. Je recommande un KMS hors du cluster et une restauration complète éprouvée.

Superviser vSAN et détecter les actions suspectes

La supervision d'un cluster vSAN repose sur trois sources : les événements et tâches de vCenter, les journaux syslog des hôtes ESX et le service de santé vSAN, également consolidé dans VCF Operations. Transférez ces flux vers votre SIEM avec une horloge synchronisée, et conservez-les hors du périmètre administré par vCenter pour qu'un attaquant ne puisse pas les effacer.

Les règles de détection les plus utiles ciblent les changements rares et à fort impact :

• Désactivation du chiffrement au repos ou en transit, changement du fournisseur de clés par défaut, renouvellement de clés non planifié.
• Passage d'une politique à FTT=0, suppression massive d'objets ou de VM, retrait d'hôtes du cluster ou partition réseau inattendue.
• Activation de SSH, sortie du mode verrouillage, abaissement du niveau d'acceptation des VIB.
• Attribution d'un rôle administrateur, création d'un compte local, ou apparition d'un groupe « ESX Admins » dans Active Directory.
• Arrêt simultané de nombreuses VM, souvent précurseur d'un chiffrement au niveau de l'hyperviseur.

Le service de santé fournit aussi des signaux de sécurité indirects : incohérence de configuration du chiffrement entre hôtes, perte de connexion au serveur de clés, objets dont la conformité à la politique se dégrade. Un hôte dont l'état de chiffrement en transit diffère du réglage du cluster peut provoquer une partition ; ce contrôle doit faire partie des vérifications après chaque intervention.

Retour terrain : Cas typique rencontré en mission — les règles les plus utiles corrèlent l'activation de SSH, la sortie du mode verrouillage et une modification de politique de stockage par un même compte, dans un court intervalle. Isolées, ces alertes produisent des faux positifs pendant les maintenances ; je les rapproche donc du calendrier des changements. En exercice, la suppression de snapshots et l'arrêt groupé de VM restent les événements vCenter les plus révélateurs.

Fin de support de vSAN 8 : planifier 2027 dès maintenant

Broadcom a fixé la fin du support général de vSAN 8, d'ESXi 8 et de vCenter 8 au 11 octobre 2027, dans l'article KB 459135, mis à jour le 27 octobre 2026. Au-delà de cette date, plus aucun correctif ne sera publié dans le cadre du support général, alors même que les hyperviseurs restent une cible prioritaire des rançongiciels.

Trois trajectoires se dessinent. La première consiste à passer à VCF 9 ou VVF 9, ce qui impose une instance VCF Operations pour gérer les licences et, souvent, un renouvellement matériel compatible ESA. La deuxième consiste à réduire le périmètre VMware aux charges qui le justifient. La troisième consiste à migrer, en s'appuyant par exemple sur notre guide de migration d'ESXi 8 vers Proxmox VE 9.

Quelle que soit l'option retenue, le calendrier se construit à rebours : inventaire précis des versions et du matériel, vérification de la compatibilité avec le guide Broadcom, budget de licences calculé sur la capacité brute, tests de restauration avant bascule, puis migration par vagues. Une migration de stockage hyperconvergé implique aussi de revoir les politiques de protection, de chiffrement et de supervision dans la plateforme cible.

À lire aussi : VMware Workstation pour les labs ; l'alternative Proxmox et son automatisation.

Questions fréquentes

Conclusion

vSAN simplifie le stockage en le fondant dans l'hyperviseur, mais il transfère aussi la responsabilité de la donnée vers l'équipe qui administre vCenter. En 2026, les décisions structurantes sont connues : ESA pour les nouveaux clusters, licences calculées sur la capacité brute, chiffrement au repos et en transit avec un gestionnaire de clés résilient, réseau cloisonné, sauvegardes indépendantes et supervision des actions sensibles.

L'échéance du 11 octobre 2027 pour vSAN 8 laisse peu de marge pour une migration sereine. Pour replacer ces choix dans une stratégie globale, consultez notre dossier sur la sécurité de VMware vSphere et ESXi et notre guide de migration sécurisée de VMware vers Proxmox VE.