Der IT-Basisschutz beinhaltet typische Computer-Hygienemaßnahmen, wie das regelmäßige Patching, Hardening durch das Ausschalten von ungenutzten Services und Netzwerkports, die fachgerechte Konfiguration, der Verschlüsselung von Daten im Transport und auf den Datenträgern. Diese Maßnahmen sind durch eine Sicherheitsrichtline festzulegen und nachvollziehbar umzusetzen (Sicherheitsaudits). Dazu gehört auch das Festlegen der notwendigen Privilegien und weiterer Maßnahmen, die den Kunden auf dem Weg zu Zero Trust begleiten. Letztendlich bedeutet Zero Trust, dass allen Diensten, Anwendern oder Geräten im Netzwerk misstraut wird. Jeglicher Verkehr von innen und außen ist zu überprüfen und vor allem die Anwender müssen sich auf sichere Art und Weise authentifizieren.

Im IT-Administrator März 2022 haben wir im Artikel "Zero Trust mit NSX-T" [1] die notwendigen fünf Schritte zu Zero Trust im Datacenter und in der Cloud dargelegt:

1. Absicherung des Datacenters mit Makro-Segmentierung (Gateway-Firewall)

2. Analyse und Dokumentation des Traffics und der Applikationen

3. Absicherung des DC-Verkehrs (East-West) mit Mikrosegmentierung

4. Anwendung zusätzlicher Sicherheitsfunktionen, etwa IDS/IPS (Intrusion Detection und Intrusion Prevention), ID (Identität), NDR (Network Detec-tion and Response), Reputation und Zeit

5. Übergeordnetes Securitymanagement (SIEM/SOAR)

In diesen fünf Schritten verbirgt sich hinter dem Kürzel "ID" der wichtige vierte Schritt, nämlich der Erkennung und Verwendung der User-Identität (Anwendername) bei der Sicherheitsüberprüfung.

Eine Frage in diesem Kontext ist, ob sich Anwender wirklich an einer identitätsbasierten Firewall identifizieren müssen, damit sie Zugriff auf Applikationen oder Dienste erhalten. Denn meist sind die Berechtigungen ohnehin in der jeweiligen Anwendung hinterlegt und erlauben nur speziellen Gruppen die Benutzung. Doch durch eine Identity Firewall (IDFW) ergibt sich die Möglichkeit, die Mikrosegmentierung nicht nur für den Datenverkehr zwischen Quell- und Zielrechner auf die IP-Adresse und den Anwendungsport zu beschränken, sondern die Berechtigung der Kommunikation anhand der Identität zu steuern. Es ist damit nicht mehr die VDI-Station "VDI01" (und damit die Quell-IP-Adresse 10.10.10.10), sondern der User "gpflueger" an der VDI01-Station, der mit dem SAP-Rechner auf Port 50001 die Anwendung nutzt.

So besteht nun ein Schutz auf Anwendungsebene (Zugriffsrechte) als auch auf der Netzwerk-Kommunikationsebene (ID-Firewall-Filterung). Für die Sicherheit stellt diese Kombination einen großen Schritt dar. Sie verhindert, dass Angreifer vom Quellrechner (Arbeitsplatzgerät oder VDI-Station) überhaupt auf den Anwendungsrechner (Destination) zugreifen können und IP-Scans möglich sind. Dies ist mit reiner Anwendungsberechtigung nicht zu verhindern. Praktisch ist auch, dass sich die Identität auf die Rollen der Anwendungen beziehungsweise auf Gruppen aus dem Active Directory anwenden lassen.

Wie spielt nun die Mikrosegmentierung per NSX mit einem Verzeichnisdienst wie dem Active Directory (AD) zusammen? Die Mikrosegmentierung mit NSX ist eine Funktion der Verkehrsfilterung, da die virtuellen Netzwerk-Karten (vnic) der VMs direkt mit dem vmkernel-Port des Hypervisors (ESX) verbunden sind. Dadurch lässt sich jedes Datenpaket von der VM und zur VM mit einer L7-Firewall (Distributed Firewall, DFW) filtern. Somit ist auch das Filtern von Verkehr von nebeneinander liegenden VMs auf demselben oder über verschiedene Hosts verteilten Hypervisoren möglich.

Mit der NSX-Mikrosegmentierung wird der Zero-Trust-Ansatz erst möglich, da nun alle notwendigen Flows für eine bestimmte Applikation in einer Allow-Regelliste erlaubt werden können und damit ein impliziertes Deny den Verkehr blockt, der nicht notwendig ist oder sogar gefährlich sein kann. Diese Filterfunktion ist im Hypervisor-Kernel eingebettet und ausreichend performant. Die Regeln von der NSX-Firewall lassen sich so über Gruppen, Anwendungsports und Services sehr leicht lesbar schreiben und werden über den Lebenszyklus hinweg (neue VMs pro Gruppe, VM-Motion, Löschen von Gruppen oder VMs) automatisch aktualisiert.

Das Active Directory ist derweil eine der zentralen Komponenten zur Verwaltung von Windows-basierten Netzwerken. Informationen zu Geräten, Ressourcen und Einstellungen lagern in einer hierarchischen Datenbank. Das AD ist in drei Teile aufgegliedert: Schema, Konfiguration und Domain:

- Ein Schema ist eine Schablone für alle Active-Directory-Einträge. Es definiert sowohl Objekttypen, ihre Klassen und Attribute als auch ihre Attributsyntax.

- Die Konfiguration beschreibt die Active-Directory-Gesamtstruktur und deren Bäume.

- Die Domain enthält schließlich alle Informationen, die sie selbst und die in ihr erstellten Objekte beschreiben.

Das AD kann dazu genutzt werden, nutzerbasierte Identity-Firewall-Regeln zu erstellen. Sie können eine oder mehrere Windows-Domänen bei einem NSX Manager registrieren. Dieser ruft Gruppen- und Benutzerinformationen sowie die Beziehungen zwischen diesen von jeder registrierten Domäne ab. Der NSX Manager erkennt auch die AD-Anmeldeinformationen. Sobald das Active Directory entsprechend synchronisiert ist, lassen sich Sicherheitsgruppen auf der Grundlage der Benutzeridentität sowie identitätsbasierte Firewallregeln erstellen.

Benutzerbasierte, verteilte Firewallregeln werden durch die Mitgliedschaft in einer AD-Gruppe bestimmt. IDFW überwacht, wo AD-Benutzer angemeldet sind, und ordnet die Anmeldung einer IP-Adresse zu, die die DFW zur Anwendung von Firewallregeln verwendet. Für die Identity Firewall ist hierfür entweder ein "Guest-Introspection"-Datenaustausch oder ein "Active Directory Event Log Scraping" erforderlich. Sie können beides in Ihrer Umgebung verwenden oder wahlweise nur eines der beiden Verfahren. Wenn Sie sowohl den AD-Protokollscraper als auch Guest Introspection nutzen, hat Guest Introspection Vorrang. Beachten Sie, dass sich die beiden Verfahren gegenseitig ausschließen: Wenn eines von beiden nicht mehr funktioniert, kann das andere nicht mehr als Backup dienen.

Änderungen der AD-Gruppenmitgliedschaft werden für angemeldete Benutzer, die RDSH-Identity-Firewall-Regeln verwenden, nicht sofort wirksam. Zunächst müssen sich die Benutzer abmelden und wieder anmelden. Wir empfehlen AD-Administratoren, eine Abmeldung zu erzwingen, wenn sich die Gruppenmitgliedschaft geändert hat, um diese Einschränkung seitens des Active Directory zu umschiffen. Zusätzlich ist es ein Best Practice, die Zeitsynchronisation von den Stationen und VMs mit dem AD zu konfigurieren.

IDFW lässt sich für virtuelle Desktopinfrastrukturen (VDI), Remote-Desktop-Sitzungen (RDSH-Unterstützung) und physische Maschinen einsetzen und ermög- licht die gleichzeitige Anmeldung mehrerer Benutzer, den Zugriff auf Benutzeranwendungen je nach Bedarf und die Aufrechterhaltung unabhängiger Benutzerumgebungen. VDI-Verwaltungssysteme steuern, welche Benutzer Zugriff auf die virtuellen VDI-Maschinen erhalten. NSX regelt den Zugriff auf die Zielserver von der virtuellen Quellmaschine aus, die IDFW aktiviert hat. Mit RDSH erstellen Sie Sicherheitsgruppen mit verschiedenen Benutzern im AD und erlauben oder verweigern diesen Benutzern den Zugriff auf einen Anwendungsserver, je nach ihrer Rolle.

So können sich beispielsweise die Entwickler und das Marketing mit demselben RDSH-Server verbinden und von diesem Server aus auf verschiedene, getrennte Anwendungen zugreifen. Dazu verbinden Sie den NSX Manager mit dem AD für die Guest Introspektion. Mit Admin-Rechten ausgestattet, klicken Sie im Hauptmenu "System" im Bereich "Identity Firewall AD" den "Add Active Directory"-Knopf an und machen die nötigen Angaben (Bild 1). Nun wird nach dem Namen des AD gefragt (FQDN; zum Beispiel vdi.pflueger. com), dem Netbios-Namen (etwa VDI) und dem Base Distinguished Name (beispielsweise dc=vdi,dc=pflueger,dc=com). Der Base Name wird vom LDAP-Server dazu verwendet, den Startpunkt der User-Suche im Directory zu finden. Das Delta-Interval ist bei geänderten Objekten gefragt, um den NSX Manager teilweise oder komplett zu synchronisieren.

Die Konfiguration und Funktionalität des LDAP-Servers bietet einen zentralen Ort für die Authentifizierung. Wenn Sie eine Verbindung zu einem LDAP-Server konfigurieren, werden die Benutzerdatensätze auf dem externen LDAP-Server gespeichert (LDAP Server beispielsweise "dc1.vdi.pflueger.com" oder 10.10.10.15). Sie können zwischen LDAP (ungesichert) oder LDAPS (gesichert) wählen. Wenn Sie sich für LDAPS entscheiden, müssen Sie einen SHA-256-Thumbprint eingeben. Nun geben Sie die Portnummer des LDAP-Servers ein. Bei lokalen Domänencontrollern kommen der Standard-LDAP-Port 389 und der LDAPS-Port 636 für die AD-Synchronisierung zum Einsatz und sollten nicht geändert werden.

Für das optionale Event Log Scrapping müssen Sie schließlich noch den Host als Host-IP-Adresse oder FQDN angeben (plus Zugangsdaten). Mit "Check Status" können Sie übrigens den Synchronisations-Status überprüfen. Den manuellen Sync ("Sync Delta" und "Sync All") initiieren Sie mit dem "Drei-Punkte-Menü".

Die folgenden Konfigurationen werden für IDFW auf VMs unterstützt. IDFW supportet die folgenden Protokolle:

- Einzelbenutzer (VDI oder Nicht-RDSH-Server): TCP, UDP

- Multiuser (RDSH): TCP, UDP

Als Active-Directory-Domain-Controller können Sie Windows Server 2012, 2012 R2, 2016 und 2019 verwenden. Auf der VM-Seite sind der VM-Hypervisor ESXi und die VMware-Tools supported. Die Konfigurationsmöglichkeiten zu den einzelnen Gastbetriebssystemen finden Sie in der Tabelle unten.

Damit sowohl für die "Gateway Firewall" als auch die "Distributed Firewall" die Funktion der identitätsbasierten Regel überhaupt funktioniert, schalten Sie unter "Security / Distributed Firewall / Actions / General Settings" bei "General Firewall Settings" die IDFW ein und wählen bei "Identity Firewall Settings" die Standalone-Hosts und die Cluster.

Bevor Sie ID-Firewall-Regeln erzeugen, legen Sie nun die Gruppen für die Filterung an. Denn bei der NSX-DFW kommen bevorzugt Source- und Destinations-Gruppen im Firewallregelwerk zum Einsatz. Es sollten keine Kombinationen von Source- und Destinations-IP-Adressen plus Destinations-Port und Protokoll mehr verwendet werden. Gruppen helfen, dynamisch auf Veränderung zu reagieren (automatische Auswertung der Gruppenkriterien) und somit das Erstellen des Regelwerks zu vereinfachen.

Unter "Inventory" und "Groups" wählen Sie "Add Group" und vergeben für die neue Gruppe einen "Group Name". Unter "Set" (Compute Member) selektieren Sie nun aus der generischen Auswahl den Menüpunkt "AD Group". Die zugehörige Liste zeigt jetzt alle Objekte aus dem verbundenen Active Directory und Sie wählen eine oder mehrere AD-Gruppen zur Erstellung der NSX-Security-Gruppe aus. In unserem Beispiel erzeugen wir die NSX-Gruppe "Gerd-Test-AD" aus der AD Gruppe "CN=gerd_ad_test,CN=Users, C=vdi,DC=sclabs,DC=net".

Die Konfiguration der identitätsbasierten Firewall ermöglicht es auch, zusätzlich zur Gruppenfilterung eine Quell-IP-Adresse hinzuzufügen. Der Benutzer muss also nicht nur Mitglied der angegebenen Gruppe sein, sondern auch die konfigurierte IP-Adresse verwenden, was die Filterung extrem granular macht.

Beispielhaft erstellen wir nun im Bereich "Security" und "Distributed Firewall" eine neue Firewall-Policy (Gerd_IDWF_Test) und verwenden darin eine Regel, die es der neu erstellten Identitätsgruppe (Gerd-Test-AD) verbietet, Pings (ICMP ALL) zu versenden (Bild 3). Als Regelaktion wählen wir daher "Drop" und machen die neue Policy durch "Publish" gültig. In unserem Versuch zeigte sich, dass die Drop-Aktion das Senden vom Ping-Requests verhinderte. Sobald die Action wieder auf "Allow" stand, wurden auch die Echos zum Ping wieder empfangen. Eine zusätzliche Funktionsanzeige der gesamten Konfiguration finden Sie dann unter "Security / Security Overview / Configuration" im unteren linken Anzeigebereich. Hier sehen Sie die aktiven User und Sessions aufgeführt.

Die NSX-IDFW ermöglicht eine Mikrosegmentierung im Datacenter, wobei die Identität als Merkmal dient. NSX bietet somit ein Tool, um den Nord/Süd-Verkehr (Gateway-Firewall) wie auch den Ost/West-Verkehr (Distributed Firewall) zu sichern.