Mit den Funktionen für eine identitätsbasierte Firewall (IDFW) haben NSX-Administratoren die Möglichkeit, Regeln für die verteilte Firewall (DFW) anhand der Active Directory-Benutzer zu erstellen.

Eine IDFW kann für virtuelle Desktops (VDI) oder Remotedesktopsitzungen (RDSH-Unterstützung) und physische Computer verwendet werden. Dies ermöglicht eine gleichzeitige Anmeldung mehrerer Benutzer für den bedarfsbasierten Benutzerzugriff auf Anwendungen sowie die Beibehaltung unabhängiger Benutzerumgebungen. VDI-Verwaltungssysteme steuern, welchen Benutzern Zugriff auf die virtuellen VDI-Maschinen gewährt wird. NSX steuert den Zugriff auf die Zielserver von der virtuellen Quellmaschine (VM), für die IDFW aktiviert ist. Erstellen Sie mit RDSH-Administratoren Sicherheitsgruppen mit verschiedenen Benutzern in Active Directory (AD) und gewähren oder verweigern Sie diesen Benutzern basierend auf ihrer Rolle den Zugriff auf einen Anwendungsserver. Beispielsweise können sich Personal- und Konstruktionsabteilung mit demselben RDSH-Server verbinden und von diesem Server aus auf verschiedene Anwendungen zugreifen.

Um die Firewallregeln zuzuweisen, muss IDFW wissen, bei welchem Desktop sich ein Active Directory(AD)-Benutzer anmeldet. Für die Erkennung der Anmeldung verwendet IDFW zwei Verfahren: Guest Introspection (GI) und/oder Ereignisprotokoll-Scraping. Guest Introspection wird auf ESXi-Clustern bereitgestellt, auf denen virtuelle IDFW-Maschinen ausgeführt werden. Wenn Netzwerkereignisse von einem Benutzer generiert werden, leitet ein auf der VM installierter Gast-Agent die Informationen über das Guest Introspection-Framework an die NSX Manager weiter. Die zweite Option ist der Active Directory Event Log Scraper. Ereignisprotokoll-Scraping aktiviert IDFW für physische Geräte. Konfigurieren Sie den Active Directory Event Log Scraper im NSX Manager so, dass auf eine Instanz in Ihrem Active Directory-Domänencontroller verwiesen wird. NSX Manager übernimmt dann die Ereignisse aus dem AD-Sicherheitsereignisprotokoll.

Ereignisprotokoll-Scraping kann für virtuelle Maschinen verwendet werden. Wenn jedoch sowohl der AD Event Log Scraper als auch Guest Introspection verwendet werden, hat Guest Introspection Vorrang vor dem Ereignisprotokoll-Scraping. Guest Introspection wird über VMware Tools aktiviert. Wenn Sie die vollständige VMware Tools-Installation und IDFW verwenden, hat Guest Introspection Vorrang vor dem Ereignisprotokoll-Scraping.

IDFW kann auch auf VMs verwendet werden, die über unterstützte Betriebssysteme verfügen. Siehe Von der identitätsbasierten Firewall unterstützte Konfigurationen.

IDFW verarbeitet die Benutzeridentität an der Quelle nur in Firewallregeln. Nur Datenverkehr, der von der Quelle stammt, in der die Benutzeridentität verarbeitet wird, unterliegt den IDFW-Regeln. Identitätsbasierte Gruppen können nicht als Ziel in Firewallregeln verwendet werden.

Hinweis: IDFW vertraut auf die Sicherheit und Integrität des Gastbetriebssystems. Es gibt mehrere Methoden für einen böswilligen lokalen Administrator, seine Identität zu manipulieren, um Firewallregeln zu umgehen. Benutzeridentitätsinformationen werden vom NSX Guest Introspection Agent innerhalb der Gast-VMs bereitgestellt. Sicherheitsadministratoren müssen sicherstellen, dass Thin Agent auf jeder Gast-VM installiert ist und ausgeführt wird. Angemeldete Benutzer sollten nicht über die Berechtigung zum Entfernen oder Beenden des Agents verfügen.

Identitätsbasierte Firewallregeln werden von der Mitgliedschaft in einer Active Directory (AD)-Gruppe bestimmt. Die Organisationseinheit mit einem AD-Benutzer und die Organisationseinheit mit der AD-Gruppe, in der sich der Benutzer befindet, müssen beide zu „Zu synchronisierende Organisationseinheiten“ hinzugefügt werden, damit IDFW-Regeln funktionieren. Informationen zu unterstützten IDFW-Konfigurationen und Protokollen finden Sie unter Von der identitätsbasierten Firewall unterstützte Konfigurationen.

IDFW-Regeln werden auf globalen Managern in einer Verbundumgebung nicht unterstützt. IDFW kann weiterhin lokal auf Verbund-Sites verwendet werden, indem IDFW-Regeln auf lokalen Managern erstellt werden.

IDFW-Richtliniengruppen und DFW-Regel-Übereinstimmungslogik

Es kann zwei Arten von IDFW-Richtliniengruppen geben:
  • Homogene Gruppen mit nur AD-Gruppen als Mitglieder der Richtliniengruppe.
  • Heterogene Gruppen, in denen neben AD-Gruppen auch andere Mitglieder vorhanden sein können, z. B. virtuelle Maschinen und IP-Adressen.
Sicherheitsregeln, die auf homogenen Identitätsgruppen basieren, wenden die Regel auf alle NSX-gestützten virtuellen Maschinen an, bei denen sich ein AD-Benutzer anmeldet, der einem AD-Gruppenmitglied angehört. Bei heterogenen Identitätsgruppen dient dies dazu, spezifischere und präzisere Quellen für IDFW-Sicherheitsrichtlinien erstellen zu können anstatt allgemein anwendbarer Quellen. Eine Sicherheitsregel, bei der eine heterogene Identitätsgruppe in der Quelle verwendet wird, wird nur auf die VMs angewendet, die Teil der Richtliniengruppe sind (entweder statisch oder über ein dynamisches Kriterium oder über die IP-Adress-/Bereichszuweisung), wenn sich ein AD-Benutzer anmeldet, der den AD-Gruppenmitgliedern angehört. Die Regel ist eine Schnittmenge (UND-Vorgang) von VMs, die Mitglieder der Gruppe mit jenen VMs sind, auf denen sich die Ziel-AD-Benutzer anmelden.

Die effektiven Mitglieder einer heterogenen Identitätsrichtliniengruppe können mithilfe der folgenden Logik ermittelt werden: [Vereinigungssatz aller Nicht-AD-Mitglieder] UND, d. h. Schnittmenge mit, [Satz der VMs, bei denen sich AD-Benutzer anmelden, die den AD-Gruppenmitgliedern angehören].

Beispiel 1: Statische VM-Mitglieder zusammen mit AD-Gruppen als Mitgliedern.
  • Absicht: Wenn einige VMs statisch mit AD-Gruppen gekoppelt werden, sollte die Richtlinie auf die statischen VM-Mitglieder angewendet werden, wenn sich ein AD-Benutzer, der den AD-Gruppen angehört, bei ihnen anmeldet.
  • Nicht anwendbare Quellbeispiele: VMs, bei denen sich ein AD-Benutzer anmeldet, der einer der Ad-Gruppen angehört, die aber KEINE statischen Mitglieder der Richtliniengruppe sind. VMs, die statische Mitglieder der Richtliniengruppe sind, bei denen der protokollierte Benutzer jedoch zu AD-Gruppen gehört, die NICHT Mitglieder der Richtliniengruppe sind.
Beispiel 2: Dynamische namensbasierte Kriterien für VMs zusammen mit AD-Gruppen als Mitglieder.
  • Absicht: Anwenden einer Sicherheitsrichtlinie NUR für VMs, deren Name mit den Kriterien übereinstimmt, wenn sich ein bestimmter AD-Benutzer bei ihnen anmeldet.
  • Nicht anwendbare Quellbeispiele: VMs, bei denen sich der AD-Benutzer anmeldet, die jedoch nicht mit den Namenskriterien übereinstimmen. VMs, bei denen die Namenskriterien übereinstimmen, der angemeldete Benutzer jedoch keiner der Mitglieder-AD-Gruppen angehört.