vDefend Distributed Firewall : le zero trust au niveau du workload

Tes consoles acceptent enfin l’identité d’entreprise : vc-par-01.corp.example, nsx-par-01.corp.example et ops-par-01.corp.example renvoient toutes vers idb-par-01.corp.example, et la révocation d’un départ se fait en un seul endroit. Tu ouvres alors NSX pour écrire ta première règle de pare-feu par groupe d’utilisateurs, avec le sentiment raisonnable que cette identité te suit partout. C’est cette déduction que l’article démonte.

La série a commencé par le périmètre réel du SSO de VCF 9.1, puis par le fournisseur d’identité et son protocole. Elle se termine sur un résultat négatif : les vrais noms du pare-feu VCF 9.x, un parcours de segmentation en quatre phases aligné sur les catégories de règles du produit, et la frontière entre le plan d’administration — fédéré — et le plan d’enforcement, qui lit toujours Active Directory. Aucun lab n’a été exécuté : c’est un guide de conception adossé à des pages Broadcom rechargées le 15 août 2026, chaque affirmation rattachée à sa page.

TL;DR

• La décision — bâtir la politique sur des tags et des groupes dynamiques plutôt que sur des adresses IP, et dérouler les quatre phases dans l’ordre même des catégories de règles du produit.
• L’arbitrage qui coûte — l’Identity Firewall ne connaît qu’une source d’identité, Active Directory. Un annuaire AD synchronisé reste une dépendance de la politique réseau, même quand toutes les consoles sont fédérées ailleurs.
• L’action de lundi matin — vérifier l’action de la règle par défaut du Distributed Firewall, qui est en Allow après préparation des hôtes, puis lancer une collecte de flux avant d’écrire la moindre autorisation.

Les vrais noms, et celui qui n’existe pas

« Firewall-as-a-Service », et son abréviation à quatre lettres, n’est un nom de produit Broadcom sur aucune page VCF 9.x chargée — ni sur la page d’aperçu, ni sur les pages 9.0 et 9.1 du Distributed Firewall, ni sur celle du Gateway Firewall, ni dans le chapitre sécurité de la documentation réseau VCF 9.0. C’est une catégorie de marché héritée du vocabulaire SASE. L’employer dans un document d’architecture invente une brique et rend la suite invérifiable.

Le produit s’appelle VMware vDefend Firewall : sa page d’aperçu le décrit comme un pare-feu logiciel de niveau 2 à 7 pour charges virtualisées en cloud privé. Deux formes d’usage, une fonction, un modèle de délégation.

Nom de catalogue	Où il s’exécute	Direction	Niveau annoncé (et page qui le porte)	Source d’identité
vDefend Distributed Firewall (DFW)	noyau de chaque hôte ESX, moteur VSIP ; instancié sur chaque vNIC	est-ouest	Layer 2-7 — page vDefend Distributed Firewall	aucune par défaut ; AD via IDFW
vDefend Gateway Firewall (GFW)	NSX Edge, VM ou serveur physique	nord-sud	layer 3-7 sur sa page ; layer 2-7 sur la page d’aperçu	aucune par défaut ; AD via IDFW
Identity Firewall (IDFW)	fonction du DFW et du GFW	à la source uniquement	n/a	Active Directory, exclusivement
Secure VPC / VPC Security Profile	à l’échelle d’un NSX Project	nord-sud pour les VPC du Project	n/a	n/a

L’écart de niveau annoncé sur le Gateway Firewall est réel et je ne le lisse pas : deux pages chargées le même jour le décrivent différemment. Je cite chaque valeur avec sa page et laisse l’arbitrage ouvert — à vérifier sur ta plateforme.

La mécanique qui porte toute la micro-segmentation tient en une phrase : un pare-feu est instancié sur chaque carte réseau virtuelle, ce qui applique les règles au plus près de la source. Le moteur s’appelle VSIP et vit dans le noyau de chaque hôte ESX — le passage du VDS au pod en donne le décor.

Deux plans qui ne se rejoignent pas

Le plan d’administration est bien fédéré : la page Integration with VCF Identity Broker for Single-Sign-On Access, dans l’arbre VCF 9.1, décrit OIDC comme une couche d’identité posée sur OAuth 2.0. Détail vérifiable, son URL porte encore le segment workspace-one-access-broker — le nom du produit a changé plus vite que l’arborescence.

Le plan d’enforcement ne consomme pas ce jeton. La page Identity Firewall, rechargée en 9.0 et en 9.1, ne cite qu’une source d’identité : l’appartenance à un groupe Active Directory. Aucune des deux ne nomme Entra ID, Okta, OIDC ni le moindre fournisseur non-AD.

Précision qui compte : ce n’est pas une incompatibilité constatée, c’est un trou documentaire assumé. Aucune page chargée ne relie l’identité OIDC émise par le VCF Identity Broker à un objet de règle DFW ou GFW. Rien n’interdit en théorie qu’un mécanisme existe sans être publié ; en pratique, « vos groupes Entra ID deviennent des objets de règle DFW » est à ce jour non sourcé, et je ne l’écrirai pas. Seul un relevé sur une instance 9.1 réelle pourra lever ce point.

Les six limites publiées de l’Identity Firewall, à poser avant tout design — aucune ne dépend du fournisseur choisi aux articles 1 et 2.

Limite publiée	Conséquence de design
source d’identité = Active Directory, exclusivement	l’annuaire AD reste nécessaire même quand les consoles sont fédérées ailleurs
identité traitée à la source uniquement	aucune règle « vers » un groupe d’utilisateurs
groupe d’identité interdit en destination	une matrice de flux qui les met en destination est inapplicable
détection par Guest Introspection ou Event Log Scraping	dépendance à VMware Tools ou aux journaux des contrôleurs de domaine
OU des utilisateurs et OU des groupes synchronisées	un oubli d’unité d’organisation produit une règle silencieusement inerte
changement d’appartenance effectif à la reconnexion	prévoir la déconnexion forcée dans la procédure de révocation

La dernière ligne mérite relecture par qui a lancé son chantier d’identité pour révoquer un départ en moins de 24 heures. Côté consoles, la révocation est immédiate au niveau de l’IdP ; côté réseau, un changement d’appartenance AD ne prend pas effet pour une session déjà ouverte. Deux plans, deux latences.

Désigner une charge sans écrire une adresse IP

Un groupe NSX se construit sur des critères statiques ou dynamiques : nom de VM, tags, segment, port de segment, adresses IP, autres attributs. Le type Generic accepte critères, membres manuels, adresses IP ou MAC et groupes Active Directory. Le type IP Addresses Only accepte IP, Geo IP et Malicious IP — mais ces groupes ne sont pas acceptés dans le champ Applied To d’une règle DFW. La limite se découvre tard et coûte une réécriture.

La bibliothèque VMware Validated Solutions pour VCF 9.0.x tranche. La décision SEC-WLD-CFG-007 recommande les tags pour porter les métadonnées des VM et objets NSX : regroupement par attributs, et découplage de l’appartenance à une politique et de la topologie réseau. La décision SEC-WLD-CFG-001 qualifie à l’inverse les groupes fondés sur des IP de non résilients aux changements d’architecture. L’adresse IP dit où une charge se trouve ; le tag dit ce qu’elle est.

La grammaire est publiée : le scope joue le rôle d’une clé, le nom de tag celui d’une valeur. Les critères dynamiques couvrent VM Name, VM Tag, VM OS Name et VM Computer Name. Un nom de tag accepte 256 caractères, un scope 128, et un tag sans machine associée est supprimé automatiquement après cinq jours. Le choix du critère se règle ensuite en trois questions.

1. Attribut stable et gouverné — tag posé par le pipeline, nom normalisé ? Critère dynamique VM Tag ou VM Name.
2. Attribut venu de la plateforme Kubernetes ? Tag de port ou de segment, avec la grammaire propre au mode réseau, détaillée plus bas.
3. Objet hors périmètre NSX — partenaire, service externe ? Groupe IP Addresses Only, en sachant qu’il sera refusé dans Applied To.

Si aucune réponse ne vient, le trou est dans la CMDB, pas dans le pare-feu.

Le parcours en quatre phases

Le vocabulaire zero trust n’est pas une importation marketing : la page TechDocs du Distributed Firewall publie elle-même un modèle présenté comme une Security Journey, approche par étapes permettant d’adopter progressivement une posture zero trust, et nomme quatre étapes en 9.0 comme en 9.1. Les libellés diffèrent légèrement sur la page de design VCF — Security Segmentation Assessment, Infrastructure Services Protection, Environment Segmentation, Application Segmentation : j’emploie le jeu de la page produit et je signale l’autre. La colonne « catégorie », en revanche, est un rapprochement de ma part, publié tel quel sur aucune page chargée.

Phase	Nom sur la page produit	Catégorie de règles	Ce qu’on publie
1	Stage 1: Security Assessment	aucune	rien — on collecte et on lit
2	Stage 2: Infrastructure Services Protection	Infrastructure	DNS, NTP, LDAP, sauvegarde, supervision
3	Stage 3: Environment-level Protection	Environment	cloisonnement production / hors-production
4	Stage 4: Application-level Isolation	Application	ring-fencing puis micro-segmentation par tier

La phase 1 produit un score. La page VMware Validated Solutions décrit un barème de 95 points maximum calculé sur 30 jours de données de trafic, dans lequel une règle par défaut positionnée sur Drop ou Reject compte. Le guide de déploiement publie ses seuils de génération : au moins une heure de trafic et plus de 1 000 flux uniques pour produire un rapport, une semaine de collecte recommandée en production.

Fermer sans casser la production

Les catégories sont ordonnées de gauche à droite : Ethernet, Emergency, Infrastructure, Environment, Application. À l’intérieur, l’évaluation va de haut en bas et la première correspondance gagne : dès qu’une règle correspond, elle s’applique et l’évaluation s’arrête.

Vient le fait le plus rassurant pour qui craint de couper la production : après la préparation des hôtes, la règle par défaut est positionnée sur Allow. Le point de départ produit est permissif ; la fermeture est une décision explicite et datée, pas un effet de bord. La journalisation est désactivée par défaut et les journaux de paquets vivent dans /var/log/dfwpktlogs.log sur l’hôte ESX — à activer sélectivement sur les règles à observer, puis à désactiver après collecte.

La séquence de bascule est publiée par la page de design VMware Validated Solutions, et son ordre est explicite : pendant la migration des applications dans le workload domain, la règle L3 par défaut reste en ANY/ANY/ANY/ALLOW ; une fois la migration terminée, elle passe en refus selon un modèle de moindre privilège. On publie les autorisations d’abord, on ferme le défaut ensuite.

Le placement compte autant que le contenu : la politique large de blocage entre zones se place vers le bas de table, les exceptions en haut, créées là et documentées pour la conformité. Les décisions à reprendre en dossier d’architecture sont SEC-WLD-CFG-012 (exceptions inter-zones), 013 (blocage inter-zones), 014 (ring-fencing applicatif), 015 (micro-segmentation par application) et 020 (service L7 couplé à son context profile).

Trois réflexes pour finir. Les actions sont Allow, Drop — rejet silencieux — et Reject, qui renvoie un message d’inaccessibilité. Le champ Applied To définit la portée d’une politique, et la bonne pratique publiée est de la restreindre plutôt que de viser l’ensemble du DFW. Les modifications se travaillent en brouillon, sauvegardé comme configuration de travail, avant Publish.

Déléguer, et descendre jusqu’aux conteneurs

Les NSX VPC créent des réseaux privés autonomes dans un NSX Project. Le VPC Security Profile gère les politiques Gateway Firewall de tous les VPC d’un Project ; un VPC group définit les membres compute auxquels appliquer des politiques. Ce modèle prolonge celui du self-service Kubernetes de VCF 9.1.

Niveau	Qui écrit	Portée	Précédence
Espace par défaut	équipe plateforme — rôles NSX de portée système	tout le système NSX	la plus haute
NSX Project	Project Admin, ou rôles de sécurité de portée projet	VM des segments du Project	intermédiaire
NSX VPC	VPC Admin — propriétaire applicatif	membres compute du VPC	la plus basse

À la réalisation d’un Project, cinq règles DFW par défaut sont créées, identifiants 1003 à 1007 : ICMP IPv6, DHCPv4, DHCPv6, communication entre VM du Project, puis rejet du reste. La règle Gateway Firewall par défaut est stateful et laisse tout passer.

Le lien avec la licence est un piège de mise en service : sans licence vDefend Firewall, les règles par défaut existent dans le Project mais restent inactives ; avec la seule licence VCF, seules des règles Gateway Firewall stateless sont configurables. L’attribution par édition commerciale reste un trou — la page de synthèse nomme les éditions vendues et retirées de la vente sans dire quelle fonction relève de laquelle. C’est le champ REPLACE_WITH_VDEFEND_LICENSE de mon état de fin, et il reste vide.

NSX compte quinze rôles intégrés. Les rôles Network Admin, Network Operator, Security Admin et Security Operator définis dans un Project n’ont de permissions que dans ce Project, pas sur l’ensemble du système ; le Project Admin a un accès complet aux configurations du Project. Les notes de version vDefend 9.0 ajoutent la délégation aux propriétaires applicatifs via le rôle VPC Admin. Pour Nordwind Logistics, cela dessine prj-webshop, vpc-webshop-prod, les groupes grp-webshop-web|app|db et une délégation à grp-app-webshop-owners — hypothèse de design de ma part, pas une prescription Broadcom. L’application webshop est celle de la migration blue-green en VM Apps et All Apps.

Le DFW couvre nommément les conteneurs et le bare metal, et une bibliothèque de design existe pour vSphere Supervisor et VKS, ciblant VCF 9.0 et vDefend 9.0. Le mécanisme repose sur deux adaptateurs du plugin CNI Antrea : le Management Plane Adapter remonte l’inventaire Kubernetes au NSX Manager, le Central Control Plane Adapter reçoit règles et groupes DFW, les traduit en politiques Antrea et crée les CRD correspondantes. La politique NSX descend donc jusqu’au conteneur par traduction, pas par instanciation sur un vNIC.

Un détail fait échouer les politiques copiées d’un environnement à l’autre : l’isolement d’un vSphere Namespace passe par un tag dont la grammaire dépend du mode réseau — tag de port nsx-op/vm_namespace en VCF Networking avec VPC, tag de segment kubernetes.io/metadata.name en NSX classique. La page d’isolement au niveau du pod décrit par ailleurs des Antrea ClusterNetworkPolicy sur critères Pod Tag, sans réénoncer la traduction depuis le DFW : les deux pages ne se contredisent pas mais ne se raccordent pas explicitement, donc je n’affirme pas qu’une règle DFW produit toujours une politique Antrea équivalente de bout en bout. À valider sur ta plateforme. Ce qui se passe à l’intérieur des clusters relève d’une autre série.

Pièges & points de vigilance

Symptôme	Cause à vérifier	Décision
une règle par identité ne s’applique jamais	groupe d’identité placé en destination	réécrire avec l’identité en source
un utilisateur retiré d’un groupe AD garde son accès réseau	l’appartenance ne change qu’à la reconnexion	forcer la déconnexion
l’identité n’est jamais résolue sur une VM	ni Guest Introspection ni Event Log Scraping actif, ou OU non synchronisée	vérifier l’OU des utilisateurs et celle des groupes
dérive horaire entre VM et annuaire	service de temps Windows inactif	rétablir avant toute conclusion
les règles par défaut du Project ne font rien	licence vDefend Firewall absente	vérifier l’entitlement
un groupe refusé dans Applied To	groupe IP Addresses Only	reconstruire en groupe Generic
une politique s’applique ici et pas là	grammaire de tag différente entre VPC et NSX classique	comparer nsx-op/vm_namespace et kubernetes.io/metadata.name
aucun trafic visible avant fermeture	journalisation désactivée par défaut	activer sélectivement, collecter, désactiver

Deux réflexes de retour arrière. Remettre la règle par défaut en Allow n’est pas un contournement : c’est l’état documenté après préparation des hôtes. Revenir au brouillon avant Publish dépublie une politique sans trace en production. Supprimer un tag « pour nettoyer » casse en revanche l’appartenance des groupes dynamiques qui s’y référaient — et c’est inutile, un tag orphelin disparaissant seul après cinq jours. Fenêtres de maintenance et upgrade NSX relèvent d’un autre chantier ; la sécurité et la résilience de VCF 9.1 en donnent le cadre.

Conclusion

La série se termine sur une frontière, pas sur une promesse bouclée. L’identité fédérée pilote l’accès aux consoles ; elle ne pilote pas l’appartenance d’un flux à une règle de pare-feu. Tant que l’Identity Firewall lit Active Directory, l’annuaire AD reste une dépendance de la politique réseau, même sur une plateforme dont toutes les consoles sont fédérées ailleurs. Ce n’est pas un défaut supposé du produit : c’est un trou documentaire déclaré, que seul un relevé sur une instance 9.1 pourra lever.

Ce que je n’ai pas et ne fabrique pas : version NSX, édition de licence vDefend, fenêtre de collecte, score de segmentation et date de bascule restent des REPLACE_WITH_* dans mes notes.