Les fonctionnalités de pare-feu d'identité (IDFW) permettent à un administrateur NSX de créer des règles de pare-feu distribué (DFW) basées sur l'utilisateur Active Directory.
IDFW peut être utilisé pour des postes de travail virtuels (VDI), des sessions de poste de travail distant (prise en charge de RDSH) et des machines physiques, l'activation de connexions simultanées par plusieurs utilisateurs, l'accès aux applications d'utilisateur en fonction de conditions requises et la possibilité de maintenir des environnements utilisateur indépendants. Les systèmes de gestion VDI contrôlent les utilisateurs autorisés à accéder aux machines virtuelles VDI. NSX contrôle l'accès aux serveurs de destination à partir de la machine virtuelle (VM) source sur laquelle l'IDFW est activé. Avec RDSH, les administrateurs créent des groupes de sécurité avec différents utilisateurs dans Active Directory (AD) et autorisent ou refusent l'accès à ces utilisateurs à un serveur d'applications selon leur rôle. Par exemple, les ressources humaines et l'ingénierie peuvent se connecter au même serveur RDSH et ont accès à différentes applications à partir de ce serveur.
IDFW doit savoir à quel poste de travail un utilisateur Active Directory (AD) se connecte pour appliquer des règles de pare-feu. IDFW utilise deux méthodes pour la détection de la connexion : Guest Introspection (GI) et/ou analyse de journaux d'événements. Guest Introspection est déployé sur des clusters ESXi sur lesquels des machines virtuelles IDFW s'exécutent. Lorsque des événements réseau sont générés par un utilisateur, un agent invité installé sur la VM transfère les informations via l'infrastructure de Guest Introspection à NSX Manager. La seconde option est l'analyseur de journaux d'événements Active Directory. Le prélèvement de journaux des événements active IDFW pour les dispositifs physiques. Configurez l'analyseur de journaux d'événements Active Directory dans NSX Manager pour qu'il pointe sur une instance de votre contrôleur de domaine Active Directory. NSX Manager extrait ensuite les événements du journal d'événements de sécurité AD.
L'analyse de journaux d'événements peut être utilisée pour les machines virtuelles. Toutefois, lorsque l'analyseur de journaux AD et Guest Introspection sont utilisés, Guest Introspection est prioritaire sur l'analyse de journaux d'événements. Guest Introspection est activé via VMware Tools. Si vous utilisez l'installation complète de VMware Tools et IDFW, Guest Introspection sera alors prioritaire sur l'analyse de journaux d'événements.
L'IDFW peut également être utilisé sur les machines virtuelles dont les systèmes d'exploitation sont pris en charge. Reportez-vous à la section Configurations prises en charge par le pare-feu d'identité.
IDFW traite l'identité de l'utilisateur sur la source uniquement dans les règles de pare-feu. Seul le trafic provenant de la source dans laquelle l'identité de l'utilisateur est traitée sera soumis aux règles IDFW. Les groupes basés sur l'identité ne peuvent pas être utilisés comme destination dans les règles de pare-feu distribué et de pare-feu de passerelle.
Les règles de pare-feu basées sur l'identité sont déterminées par appartenance dans une appartenance de groupe Active Directory (AD). L'unité d'organisation avec un utilisateur AD et l'unité d'organisation avec le groupe AD dans lequel se trouve l'utilisateur doivent être ajoutées dans les unités d'organisation à synchroniser pour que les règles IDFW fonctionnent. Pour les configurations et les protocoles d'IDFW pris en charge, reportez-vous à la section Configurations prises en charge par le pare-feu d'identité.
Les règles IDFW ne sont pas prises en charge sur les gestionnaires globaux dans un environnement de fédération. IDFW peut toujours être utilisé localement dans les sites fédérés en créant des règles IDFW sur les gestionnaires locaux.
Groupes de stratégies IDFW et logique de correspondance de règle DFW
- Groupes homogènes avec uniquement des groupes AD en tant que membres du groupe de stratégies.
- Groupes hétérogènes où il peut y avoir d'autres membres en plus des groupes AD, tels que des machines virtuelles et des adresses IP.
Les membres effectifs d'un groupe de stratégies d'identité hétérogènes peuvent être trouvés à l'aide de la logique suivante :[Ensemble d'union de tous les membres non-AD] AND c'est-à-dire intersection avec [Ensemble de VM où les utilisateurs AD appartenant au(x) groupe(s) AD membre(s) se connectent].
- Intention : lors du couplage statique de quelques machines virtuelles avec des groupes AD, l'intention est d'appliquer la stratégie aux membres de machine virtuelle statique lorsqu'un utilisateur AD appartenant aux groupes AD s'y connecte.
- Exemples source non applicables : machines virtuelles dans lesquelles un utilisateur AD appartenant à l'un des groupes AD membres se connecte, mais qui ne sont pas des membres statiques du groupe de stratégies. Machines virtuelles qui sont des membres statiques du groupe de stratégies, mais l'utilisateur connecté appartient à des groupes AD qui ne sont pas des membres du groupe de stratégies.
- Intention : appliquez une stratégie de sécurité UNIQUEMENT aux machines virtuelles dont le nom correspond aux critères lorsqu'un utilisateur AD spécifique s'y connecte.
- Exemples de sources non applicables : machines virtuelles sur lesquelles l'utilisateur AD se connecte, mais qui ne correspondent pas aux critères de nom. Machines virtuelles sur lesquelles les critères de nom correspondent, mais l'utilisateur connecté n'appartient pas à l'un des groupes AD membres.