Bonnes Pratiques VMWare NSX (Partie 2/3)
|
note
|
Cet article est la partie 2 de notre série “Bonnes Pratiques NSX”. Pour une navigation aisée au sein de cet article, une table des matières est disponible sur le côté droit. |
5. Utilisation des Groupes NSX pour une Politique Dynamique (Point 7 - partiel)
5.1. Rôle des Groupes
Les groupes NSX sont des constructions logiques fondamentales qui permettent de regrouper des objets d’inventaire (VMs, adresses IP, segments, ports de segment, etc.) et des métadonnées (balises).1 Ils servent ensuite de source, de destination ou de cible d’application (‘Applied To’) dans les règles de pare-feu (DFW et GFW).24
5.2. Appartenance Dynamique
La puissance des groupes NSX réside dans leur capacité à déterminer leur appartenance de manière dynamique, en fonction de critères définis.28 Pour la conception hiérarchique envisagée, les critères clés sont :
- Balises (Tags) : Le critère le plus pertinent ici. Permet de sélectionner des membres basés sur la correspondance exacte d’une balise et/ou d’une portée (Tag Equals X, Scope Equals Y).33 Des opérateurs logiques (AND/OR) peuvent être utilisés pour combiner plusieurs conditions ou critères.33
- Segment NSX : Inclure des membres basés sur leur connexion à un ou plusieurs segments NSX spécifiques (qui sont eux-mêmes connectés à une passerelle T1).33
- Autres Groupes (Imbrication) : Un groupe peut inclure d’autres groupes comme membres.33 C’est le mécanisme qui permet de construire des structures de politique hiérarchiques via l’imbrication.
- Propriétés des VM : Nom de VM, nom d’OS, nom d’ordinateur, etc., peuvent également être utilisés.1
5.3. Imbrication des Groupes (Nesting)
- Capacité : NSX permet d’imbriquer des groupes les uns dans les autres.33
- Limite Recommandée (Meilleure Pratique) : Une contrainte opérationnelle majeure concerne l’imbrication des groupes. VMware recommande fortement de limiter la profondeur d’imbrication à trois niveaux maximum.2 Certains documents mentionnent une fourchette de 3 à 5 niveaux.2
- Justification de la Limite : Cette recommandation découle de plusieurs facteurs critiques :
- Complexité du Dépannage : Une imbrication profonde rend extrêmement difficile le suivi de l’appartenance effective d’un objet à un groupe et le débogage de l’application des politiques.39
- Impact sur les Performances/Scalabilité : Le calcul des appartenances dynamiques et la publication des politiques deviennent plus gourmands en ressources (CPU/mémoire sur NSX Manager et les contrôleurs) avec une imbrication profonde.39
- Fiabilité (Bogues Connus) : Des problèmes ont été identifiés dans certaines versions de NSX où les règles DFW utilisant des groupes profondément imbriqués pouvaient ne pas correspondre au trafic comme attendu, en raison de conditions de concurrence dans la réalisation de l’appartenance IP au niveau du data plane.41
- Alternative à l’Imbrication Profonde : Plutôt que de créer une structure de groupes directement calquée sur la hiérarchie des balises (par exemple, Groupe G-Zone1 contient G-Zone1-1 qui contient G-Zone1-1-1), il est souvent préférable d’utiliser des structures de groupes plus plates combinées à des critères d’appartenance dynamiques précis basés sur les balises. Par exemple :
- Un groupe G-Zone1-1-1 pourrait correspondre aux objets ayant Portée=SubZone2 ET Balise=Zone1-1-1.
- Un groupe G-Zone1-1 pourrait correspondre aux objets ayant Portée=SubZone1 ET Balise=Zone1-1.
- Un groupe G-Zone1 pourrait correspondre aux objets ayant Portée=Zone ET Balise=Zone1. Alternativement, si la stratégie de nommage par délimiteur est utilisée, un groupe pourrait utiliser des critères comme “Nom de VM commence par…” ou “Balise contient…” 28, bien que cela puisse être moins précis. Cette approche évite les risques liés à l’imbrication profonde tout en permettant une organisation logique.
La structure hiérarchique souhaitée par l’utilisateur (Zone > SubZone1 > SubZone2) implique trois niveaux. La mapper directement sur trois niveaux de groupes imbriqués est techniquement possible mais se situe à la limite de la meilleure pratique et expose aux risques mentionnés. Une conception utilisant des groupes moins imbriqués, s’appuyant fortement sur la précision du balisage (Stratégie 1 : Portée+Balise) et des critères dynamiques, est probablement plus robuste, plus facile à gérer et moins susceptible de rencontrer des problèmes de fiabilité.
5.4. Limites des Groupes
NSX impose certaines limites à la configuration des groupes 33 :
- Maximum de 5 critères d’appartenance par groupe.
- Maximum de 15 conditions avec des types de membres NSX mixtes par critère.
- Maximum de 35 conditions avec des types de membres mixtes (incluant Kubernetes) par groupe générique.
- Maximum de 5 conditions avec le même type de membre par critère.
Le tableau suivant résume les meilleures pratiques et limites clés pour les groupes NSX :
Tableau 3 : Meilleures Pratiques et Limites des Groupes NSX
| Meilleure Pratique / Limite | Recommandation / Valeur | Justification / Référence |
|---|---|---|
| Profondeur d’Imbrication | Max 3 niveaux | Dépannage 39, Performance 39, Fiabilité/Bogues 41, Recommandation VMware 2 |
| Critères par Groupe | Max 5 | Limite documentée 33 |
| Conditions par Groupe | Max 15 (NSX mixte) / 35 (global mixte) | Limite documentée 33 |
| Types de Membres | Utiliser Balises, Segments, VM, IP, Groupes (dynamiques) | Flexibilité, Automatisation 5, Précision contextuelle 1 |
| Alternative à l’Imbrication | Critères dynamiques basés sur Balises/Portées/Préfixes | Évite les problèmes d’imbrication profonde, maintenabilité 28 |
6. Implémentation des Politiques de Sécurité DFW Hiérarchiques (Point 5)
6.1. Vue d’ensemble du Pare-feu Distribué (DFW)
Le DFW est le composant clé de NSX pour la micro-segmentation.1 Il s’agit d’un pare-feu stateful L2-L7 intégré au noyau de l’hyperviseur, qui applique les politiques de sécurité directement à l’interface réseau virtuelle (vNIC) de chaque charge de travail.1 Cette approche distribuée permet une application granulaire des politiques pour le trafic Est-Ouest, indépendamment de la topologie réseau.1 Les règles sont traitées de haut en bas, et la première règle correspondante est appliquée à la connexion.17
6.2. Structure des Politiques DFW
Les règles DFW sont organisées de manière hiérarchique dans l’interface NSX :
- Catégories (Sections) : Prédéfinies (par exemple, Ethernet, Emergency, Infrastructure, Environment, Application) ou personnalisées. Elles déterminent l’ordre global de traitement des règles.24
- Politiques : Conteneurs logiques de règles au sein d’une catégorie. Permettent de regrouper les règles par application, environnement, etc.
- Règles : Définissent les conditions spécifiques de contrôle du trafic.
6.3. Composants d’une Règle DFW
Une règle DFW typique comprend les éléments suivants 24 :
- Source : Qui initie la communication (souvent un Groupe NSX).
- Destination : Qui reçoit la communication (souvent un Groupe NSX).
- Service : Quel protocole/port est utilisé (objets L4 prédéfinis/personnalisés, ou Any).
- Profils de Contexte (Context Profiles) : Pour l’inspection L7 (App-ID, FQDN/URL).1
- Appliqué à (Applied To) : À quelles charges de travail cette règle doit-elle s’appliquer (souvent un Groupe NSX). C’est un champ crucial pour l’optimisation et la portée.
- Action : Que faire du trafic correspondant (Allow, Drop, Reject).
6.4. Application de la Hiérarchie T1 et Balises dans les Règles DFW
Pour traduire la structure hiérarchique T1 + Balises en politiques DFW efficaces :
- Source / Destination : Utiliser les Groupes NSX créés dynamiquement à partir des balises hiérarchiques. Par exemple, un groupe G-Zone1-1-1 correspondant aux VM ayant Portée=SubZone2, Balise=Zone1-1-1.24
- Appliqué à (Applied To) : Ce champ est essentiel pour lier la politique DFW au contexte de la passerelle T1 et optimiser l’application des règles.45 Deux approches principales :
1. Appliquer au Groupe le plus spécifique : Appliquer la règle uniquement aux membres du groupe source ou destination le plus granulaire (par exemple, Appliqué à : G-Zone1-1-1). Simple mais peut nécessiter plus de règles si la portée doit être plus large.
2. Appliquer au Groupe de la Zone T1 (Recommandé pour la hiérarchie) : Créer un groupe (par exemple, G-Zone1) qui contient dynamiquement toutes les VM connectées aux segments de la passerelle T1 Zone 1. Utiliser ce groupe G-Zone1 dans le champ Appliqué à.
L’approche 2 est particulièrement puissante pour la hiérarchie. Elle garantit qu’une règle, même si elle concerne des sous-zones très spécifiques (définies dans Source/Destination par des groupes basés sur des balises comme G-Zone1-1-1), ne sera programmée et évaluée que sur les vNIC des VM appartenant à la Zone 1 (connectées à la T1 Zone 1). Cela renforce la limite de la zone T1 au niveau du DFW, améliore considérablement l’efficacité (moins de règles à évaluer par VM) 45, et simplifie la gestion des politiques en liant clairement les règles DFW à la structure T1.16
6.5. Exemples de Construction de Règles Hiérarchiques
En utilisant l’approche “Appliqué à la Zone T1” et des groupes basés sur les balises (Stratégie 1 : Portée+Balise) :
- Autoriser Intra-Sous-Sous-Zone (au sein de Zone 1-1-1) :
- Refuser Inter-Sous-Sous-Zone (entre Zone 1-1-1 et Zone 1-1-2) :
- Autoriser Accès Service Partagé (depuis Zone 1-1 vers Infra Partagée) :
- Source : G-Zone1-1 (Groupe basé sur Portée=SubZone1, Balise=Zone1-1)
- Destination : G-Shared-Infra (Groupe basé sur balises pour DNS, AD, NTP, etc.)
- Service : DNS, Kerberos, NTP, etc.
- Appliqué à : G-Zone1 (ou G-Zone1-1 si on veut être plus restrictif)
- Action : Allow
6.6. Profils de Contexte (Inspection L7)
Pour une sécurité allant au-delà des ports et protocoles L4, les profils de contexte peuvent être ajoutés aux règles DFW.1 Ils permettent :
- Identification d’Application (App-ID) : Reconnaître et autoriser/bloquer des applications spécifiques (par exemple, mysql, ssh, http, différentes versions de TLS/SSL) indépendamment du port utilisé.1 NSX dispose d’une bibliothèque d’App-ID prédéfinis et permet la création de profils personnalisés.46
- Filtrage FQDN/URL : Autoriser ou refuser le trafic vers des noms de domaine complets ou des URL spécifiques, même si leurs adresses IP sont dynamiques ou inconnues.1 Supporte les noms complets et les expressions régulières partielles (par exemple, *.example.com).47 Nécessite une règle DNS préalable pour permettre à NSX d’apprendre le mappage IP-FQDN via DNS Snooping.47
6.7. Règle par Défaut
Pour adopter une posture Zero Trust, il est essentiel de configurer la règle par défaut du DFW (au niveau global ou par politique) sur Drop ou Reject.16 Cela garantit que tout trafic non explicitement autorisé par une règle spécifique est bloqué.
7. Performance, Scalabilité et Gestion (Point 6)
7.1. Performance du DFW
Le DFW est conçu pour des performances élevées, fonctionnant à la vitesse de la ligne (“line rate”) car il est intégré au noyau de l’hyperviseur.1 Sa capacité de traitement évolue horizontalement : l’ajout d’hôtes ESXi au cluster augmente la capacité globale de pare-feu distribué.12
7.2. Impact des Balises, Groupes et Règles
- Grand Nombre de Balises : NSX est conçu pour gérer un grand nombre de balises.39 L’impact principal d’un très grand nombre de balises se situe au niveau de la complexité de gestion (organisation, cohérence, automatisation) plutôt que sur les performances d’exécution, sauf si les limites maximales de configuration (ConfigMax) sont atteintes.49
- Groupes Complexes/Imbriqués : C’est ici que l’impact sur les performances et la fiabilité est le plus notable. Le calcul des appartenances dynamiques, en particulier avec une imbrication profonde ou des critères complexes, augmente la charge de calcul lors de la publication des politiques sur NSX Manager et les contrôleurs.39 Plus important encore, des bogues connus liés aux groupes imbriqués peuvent entraîner une non-concordance des règles DFW, compromettant la sécurité.41 La recommandation stricte de limiter l’imbrication à 3 niveaux vise à atténuer ces risques.2
- Complexité des Règles : Un très grand nombre de règles DFW ou des règles excessivement complexes (multiples sources/destinations/services combinés) peuvent augmenter le temps de compilation des politiques et potentiellement la consommation de mémoire sur les hôtes. Cependant, le traitement séquentiel (haut-bas, premier match) est efficace à l’exécution.17 L’utilisation judicieuse du champ Appliqué à réduit considérablement l’impact d’un grand nombre de règles globales, car chaque VM n’a besoin d’évaluer que les règles qui lui sont effectivement appliquées.45
7.3. Limites de Scalabilité
Les limites précises (nombre de balises par objet, total de balises, nombre de groupes, règles par politique, nombre de politiques, etc.) dépendent de la version de NSX et doivent être vérifiées dans l’outil VMware Configuration Maximums.3 Dépasser ces limites peut entraîner des instabilités ou des échecs de configuration.
7.4. Gestion et Dépannage
- Discipline de Balisage : Une hiérarchie de balises complexe exige une rigueur absolue dans le nommage, l’application et la documentation. Sans cela, les groupes dynamiques deviendront incorrects et les politiques inefficaces.53 La gestion (création, modification, suppression) de milliers de balises nécessite des outils d’automatisation (API, scripts).
- Complexité du Dépannage : Le débogage des politiques DFW avec des groupes imbriqués est notoirement difficile.39 L’outil Traceflow est utile pour visualiser le chemin d’un paquet et la règle DFW appliquée, mais il a historiquement eu des limitations (par exemple, ne fonctionnant que pour les segments Overlay dans certaines versions 54).
- Outils Essentiels : Des outils comme VMware Aria Operations for Networks (anciennement vRealize Network Insight - vRNI) et Aria Operations for Logs (anciennement vRealize Log Insight - vRLI) sont pratiquement indispensables pour la visibilité des flux, la planification des politiques de micro-segmentation et le dépannage efficace.12
- NSX Intelligence : Conçu pour aider à découvrir les flux applicatifs et recommander des règles DFW, NSX Intelligence peut être un point de départ utile. Cependant, les recommandations initiales peuvent être trop granulaires, générant un très grand nombre de groupes et de règles spécifiques qui nécessitent une consolidation et une révision manuelles pour être gérables et alignées sur la stratégie de sécurité globale.12
- Impact Opérationnel : Il existe une tension inhérente entre la flexibilité technique offerte par NSX (balises, groupes dynamiques, imbrication) et la capacité opérationnelle à gérer la complexité résultante à grande échelle. Le respect des meilleures pratiques (comme la limite d’imbrication à 3 niveaux) n’est pas seulement une question de performance brute, mais fondamentalement une question de maintien d’une posture de sécurité gérable et fiable. Des configurations excessivement complexes deviennent difficiles à comprendre, à déboguer ou à modifier en toute sécurité par la suite, un phénomène parfois décrit comme “écrire une seule fois” (“write-once”).40 Le succès d’une segmentation hiérarchique dépend autant de la maturité opérationnelle (standards, processus, outillage) que de la conception technique.
Dans la suite de cette série, nous explorerons les différentes constructions NSX alternatives et complémentaires. Lire la suite