valentint - Fotolia

Mit Best Practices für NSX-Firewalls die Sicherheit erhöhen

VM-Sicherheit ist wesentlich für den Data-Center-Betrieb. NSX-T von VMware bietet umfassende Sicherheitsmaßnahmen durch Firewalls. Best Practices helfen, diese wirksam einzusetzen.

Das VMware NSX-T Data Center enthält sowohl eine Distributed Firewall (DFW) als auch eine Gateway Firewall, um Netzwerkbereiche zu überwachen und zu kontrollieren. Sie können mehrere Best Practices für die NSX-Firewalls implementieren, etwa einen Trust-Nothing-Ansatz und eine rollenbasierte Zugriffskontrolle. Auf diese Weise lässt sich die Netzwerksicherheit erhöhen und der Zugriff auf virtuelle Maschinen (VM) einschränken.

Legen Sie fest, wie die Distributed Firewall und die Gateway Firewall mit dem Traffic umgehen sollen, bevor Sie das NSX-T Data Center implementieren. Die Distributed Firewall in NSX-T bietet Mikrosegmentierung. Das bedeutet, dass Sie alle Komponenten im Netzwerk, wie virtuelle Switches, am virtuellen Netzwerkadapter jeder VM im Hypervisor segmentieren können.

Die folgenden Best Practices helfen, die Sicherheit im gesamten Netzwerk zu gewährleisten:

  • Verwenden Sie den Trust-Nothing-Ansatz.
  • Überprüfen und kontrollieren Sie den Traffic mit NSX Intelligence.
  • Gruppieren Sie die VMs effizient.
  • Aktivieren Sie die rollenbasierte Zugriffskontrolle (Role-based Access Control, RBAC).

Best Practices für die Distributed Firewall von NSX-T

Der Trust-Nothing-Ansatz

Die erste Best Practice, die Sie nach der Implementierung der NSX-T-DFW anwenden sollten, ist der Trust-Nothing-Ansatz, besser bekannt als Zero-Trust-Ansatz. Üblicherweise kontrollieren Firewalls am Netzwerk-Edge nicht den Traffic zwischen VMs im Data Center. Doch die virtuelle Firewall von VMware ist dazu in der Lage. Die DFW in NSX-T lässt automatisch den gesamten Traffic zu, was dem normalen Verhalten des Netzwerks ohne Mikrosegmentierung entspricht. Abbildung 1 zeigt die Standardregel für Layer 3 – Regel-ID 2 –, die den gesamten Traffic zulässt.

Abbildung 1: Beispiel für die Standard-Layer-3-Regel von NSX-T.
Abbildung 1: Beispiel für die Standard-Layer-3-Regel von NSX-T.

Den gesamten Datenverkehr standardmäßig zu erlauben, ist jedoch keine Best Practice. VMware empfiehlt dies, da NSX-T andernfalls den gesamten Traffic für Anwendungen blockiert, sobald Sie es installiert haben. Für einen sichereren Betrieb sollten Sie die DFW konfigurieren und die standardmäßig aktivierte Allow-All-Regel deaktivieren.

Um Sicherheitsrisiken zu minimieren, prüfen Sie zunächst, welchen Traffic das System zulassen soll. Anschließend erstellen Sie die Firewall-Regeln.

Als Best Practice sollten Sie darauf achten, dass Verwaltungskomponenten wie die vCenter Server Appliance nicht von der DFW blockiert werden. Eine Möglichkeit besteht darin, diese VMs in einem Management-Cluster auszuführen, der nicht für NSX-T konfiguriert ist. Dadurch können weder Netzwerkvirtualisierung noch die DFW diese Management-VMs beeinflussen.

Bei diesem Ansatz sind die Management-VMs jedoch ungeschützt. Sie können diese VMs stattdessen in einem geschützten Cluster ausführen. Fügen Sie sie zur Ausschlussliste der DFW hinzu, damit sie nicht verfügbar werden, wenn die DFW den Traffic blockiert. Nachdem Sie die Firewall-Regeln, auch wenn es nur für den vCenter Management Server ist, fertiggestellt haben, können Sie die geschützten VMs von der Ausschlussliste entfernen.

Prüfen und kontrollieren Sie den Traffic mit dem VMware-Tool

Eine weitere Best Practice ist die Verwendung der NSX Intelligence genannten Funktion, die mit der Enterprise-Plus-Lizenz von NSX-T verfügbar ist. Um VMs zu schützen, müssen Sie bestimmen, welche Ports und Protokolle sie verwenden. NSX Intelligence prüft den gesamten Traffic und erstellt entsprechende Firewall-Regeln für diesen Datenverkehr.

Abbildung 2 zeigt eine Untergruppe von VMs und die Verbindungen zwischen ihnen in separaten Netzwerksegmenten. Die grüne Linie zwischen den VMs kennzeichnet Traffic, der bereits durch eine Firewall-Regel zugelassen wurde. Die gestrichelte rote Linie zeigt Traffic an, der noch nicht geschützt ist.

Abbildung 2: Beispiel für VM-Netzwerke mit NSX Intelligence.
Abbildung 2: Beispiel für VM-Netzwerke mit NSX Intelligence.

NSX Intelligence bietet Traffic-Empfehlungen, die einen Überblick über den gesamten erkannten Datenverkehr geben, für den Sie Firewall-Regeln erstellen können. Bestimmen Sie als Administrator, welche Firewall-Regeln NSX-T erstellen soll, um Traffic zuzulassen, und entfernen Sie diese Regeln aus den Empfehlungen für unerwünschten Traffic.

Es ist nicht notwendig, diese Regeln zu verwerfen oder abzulehnen, denn sobald Sie die Regeln zum Zulassen von Datenverkehr angelegt haben, sollten Sie NSX-T anweisen, alle anderen Daten standardmäßig zu blockieren.

Gruppieren Sie VMs effizient

NSX Intelligence empfiehlt auch Gruppen, die VMs zusammenfassen können, die miteinander kommunizieren. NSX-T verwendet diese Gruppen für die Felder Sources und Destinations der DFW. Sie sind ebenfalls für das Feld Applied To wichtig.

Das Applied-To-Feld sorgt für eine effiziente Verarbeitung der Firewall-Regeln. Standardmäßig bezieht sich dieses Feld auf die gesamte DFW. Wenn Sie das Feld Applied To für eine Regel aktivieren, wendet die DFW diese Regel auf alle VMs im Bestand an. Die DFW wendet die Regel auch auf VMs an, die keine Quelle oder kein Ziel für die Regel selbst sind. Wenn Sie beispielsweise 1.000 Firewall-Regeln erstellen und für jede Regel das Applied-To-Feld aktivieren, muss die DFW 1.000 Regeln für jede VM verarbeiten – auch wenn die Regeln nur zwei VMs betreffen.

Sie können eine Gruppe mit diesen beiden VMs erstellen und dann das Feld Applied To nur für diese Gruppe aktivieren. Dadurch wird sichergestellt, dass die DFW die Firewall-Regeln nur auf die beiden VMs in der Gruppe anwendet und nicht auf den gesamten VM-Bestand. Sie können diese Gruppe auch für die Felder Sources und Destinations nutzen. Abbildung 3 zeigt einige Regeln, bei denen die DFW eine Gruppe für Anwendungsserver im Feld Applied To verwendet.

Abbildung 3: Beispiel für kategoriespezifische Regeln der NSX-DFW.
Abbildung 3: Beispiel für kategoriespezifische Regeln der NSX-DFW.

Sie können Gruppen mit verschiedenen Kriterien erstellen, etwa VM-Namen und -Tags. Wenn ein VM-Name zum Beispiel das Schlüsselwort Web enthält, wird die VM Mitglied der Gruppe Webserver. Tags kennzeichnen VMs und teilen sie ebenfalls in Gruppen ein. Sie können Tags in Kombination mit Automatisierungssoftware, wie vRealize Automation, verwenden, um neue VMs zu klassifizieren, die über diese Software bereitgestellt werden. Die VMs gehören dann automatisch zu den richtigen Gruppen und erhalten die entsprechenden Firewall-Regeln.

RBAC

Die letzte Best Practice für NSX-Firewalls sieht die Konfiguration von RBAC vor. NSX-T lässt sich in Microsofts Active Directory (AD) oder VMwares Workspace One Access – früher bekannt als Identity Manager – integrieren, um mit Gruppen und Benutzern von AD und Workspace One zu arbeiten. NSX-T kann diese Gruppen und Benutzer auch verwenden, um Rollen für AD oder Workspace One zuzuweisen.

Im Gegensatz zu anderen VMware-Produkten ist NSX-T nicht in der Lage, spezifische Rollen mit Berechtigungen zu erstellen. Verwenden Sie die integrierten Rollen, um RBAC zu nutzen. Für die DFW handelt es sich hierbei um die Rollen Security Operator und Security Admin. Abbildung 4 zeigt die Rollen Security Operator und Security Admin, die NSX-T Gruppen oder Benutzern zuweisen kann, die aus dem Active Directory stammen.

Abbildung 4: Beispiel für NSX-T-Benutzerrollen.
Abbildung 4: Beispiel für NSX-T-Benutzerrollen.

Die NSX-T-Dokumentation enthält eine genaue Übersicht, auf welche Funktionen diese Rollen mit welcher Berechtigung zugreifen dürfen, wie Full Access, Execute, Read und None. Der Security Admin – in NSX-T Data Center 3.0 Security Engineer genannt – hat vollen Konfigurationszugriff auf die sicherheitsrelevanten Funktionen. Der Security Operator hingegen hat nur Lesezugriff auf NSX-T, darf aber die Troubleshooting Tools verwenden, um die Software zu analysieren.

Erfahren Sie mehr über Netzwerksicherheit

ComputerWeekly.de
Close