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-T Data Center 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.

Note : IDFW s'appuie sur la sécurité et l'intégrité du système d'exploitation invité. Il existe plusieurs méthodes pour qu'un administrateur local malveillant usurpe son identité afin de contourner les règles de pare-feu. Les informations d'identité d'utilisateur sont fournies par l'agent léger NSX Guest Introspection dans les machines virtuelles invitées. Les administrateurs de sécurité doivent s'assurer que l'agent léger est installé et en cours d'exécution sur chaque machine virtuelle invitée. Les utilisateurs connectés ne doivent pas disposer du privilège pour supprimer ou arrêter l'agent.

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

Il peut y avoir deux types de groupes de stratégies IDFW :
  • 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 règles de sécurité basées sur des groupes d'identité homogènes appliquent la règle à toutes les machines virtuelles NSX sur lesquelles l'utilisateur AD appartenant à l'un des membres du groupe AD se connecte. Avec des groupes d'identité hétérogènes, la justification est la possibilité de créer des sources plus spécifiques et plus précises pour les stratégies de sécurité IDFW plutôt que des sources largement applicables. Une règle de sécurité dans laquelle un groupe d'identité hétérogène est utilisé dans la source ne sera appliquée qu'aux machines virtuelles qui font partie du groupe de stratégies (de manière statique, via un critère dynamique ou via une attribution d'adresse IP ou de plage d'adresses IP) lorsqu'un utilisateur AD appartenant au(x) groupe(s) AD membre(s) se connecte. La règle est une intersection (opération AND) des machines virtuelles qui sont membres du groupe avec les machines virtuelles sur lesquelles les utilisateurs AD cibles se connectent.

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].

Exemple 1 : membres de machines virtuelles statiques avec des groupes AD en tant que membres.
  • 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.
Exemple 2 : critères basés sur le nom dynamique pour les machines virtuelles avec des groupes AD en tant que membres.
  • 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.