Der Sicherheitsexperte und Gartner-Analyst John Watts bezeichnet "Zero Trust" als eine gute Kurzformel für die Beschreibung eines Paradigmas, bei dem implizites Vertrauen aus der gesamten Computerinfrastruktur entfernt wird. Dabei ersetzen explizit berechnete, in Echtzeit anpassbare Vertrauensstufen für einen gerade noch ausreichenden Zugang zu Unternehmensressourcen das implizierte Vertrauen.

Um Zero Trust im Datacenter zu erreichen, ist jeglicher Verkehr zu prüfen. Dies inkludiert Datenströme von Anwendern außerhalb des RZ (Nord-Süd-Verkehr) als auch den internen Verkehr zwischen den Anwendungen (Ost-West-Verkehr). Zusätzlich muss nach Möglichkeit die Authentisierung von Anwendungen und Geräten erfolgen.

Diese Maßnahmen sind nicht in einem Schritt durchsetzbar, sondern erfolgen idealerweise in einem fünfstufigen Prozess, der die Maßnahmen in planbare und kontrollierbare Arbeitsschritte aufteilt:

1. Absicherung des RZ mit Macrosegmentierung (Nord-Süd).

2. Analyse und Dokumentation des Traffics und der Applikationen.

3. Absicherung der Datenströme (Ost-West) mit Microsegmentierung.

4. Anwendung zusätzlicher Sicherheitsfunktionen: IDS/IPS (Intrusion Detection/ Intrusion Prevention System), NDR (Network Detection and Response), Identity- und zeitbasierende Maßnahmen und URL- und Reputations-Filter.

5. Übergeordnetes Securitymanagement (SIEM/SOAR).

Der erste Schritt auf dem Weg zu Zero Trust ist definitiv die Perimeter-Firewall. Über Jahre hinweg oft die einzige Verteidigung gegen Bedrohungen aus dem Internet, nimmt die Perimeter-Firewall immer noch einen wichtigen Platz ein. Best Practise ist es, eine Hardwarefirewall von einem zweiten Hersteller für den Verkehr vom Internet zu nutzen und zusätzlich den Verkehr ins Datacenter (Nord-Süd) mit der NSX-T-Gateway-Firewall vorzufiltern.

Diese Gateway-Firewall wird im NSX-Manager als Funktion der Edge-Services (VM oder Bare-Metal) auf dem T0- oder T1-Gateway installiert und arbeitet im Rahmen der genutzten Services im "Ac- tive Active"- oder "Active Standby"-Modus. Wichtig ist, dass die Gateway-Firewall unabhängig von der DFW (Distributed Firewall) arbeitet. Die Regeln erstellen Sie per NSX-T-GUI (Bild 1) oder über die REST-API. Wie bei der DFW können Sie für die Regelerstellung Gruppen, Tagging und andere logische Objekte verwenden. Ebenso stehen wie bei der DFW vordefinierte Dienste und Gruppen zur Verfügung, um das Filtern von L4-Diensten bis hin zu L7-Services (entspricht Application Level Gateway; ALG) zu ermöglichen.

Nach der Installation der Hardware-Perimeter-Firewall und des NSX-T-Gateways ist der erste Schritt erledigt und Sie wenden sich nun den Anwendungen und Verkehrsströmen im Rechenzentrum zu.

Ohne eine CMDB wie beispielsweise ServiceNow kennen die meisten IT-Verantwortlichen weder die Anwendungen im Datacenter noch die dazugehörigen Datenströme. Das Zero-Trust-Prinzip erfordert aber, dass alle notwendigen Flows erlaubt und der Rest des Verkehrs gefiltert wird. Im virtualisierten Datacenter mit NSX-T gibt es zwei Möglichkeiten, die richtigen Verkehrsströme zu ermitteln. Natürlich lässt sich das Ganze auch per Recherche oder Traffic-Analysator erledigen. Die Grundlage für die DFW-Firewall-Regeln ist: das Gute zu schützen und das Schlechte zu filtern.

Hierbei helfen zwei Tools von VMware: Als integriertes NSX-T-Tool bietet sich "NSX Intelligence" an, um den Verkehr im Datacenter zu untersuchen. NSX Intelligence ist eine virtuelle Appliance, die Sie im NSX-T-Manager installieren und auch bedienen. Die Software eignet sich, wenn die Anwendungen bereits bekannt sind und Sie die VMs in Gruppen eingeteilt haben. Im NSX-T-Manager-Bereich "Plan & Troubleshoot" stehen zwei Funktionen zur Verfügung, die die Zusammenfassung von Anwendungen vorsehen ("Discover" und "Take Action") und das Erstellen eines Firewall-Regelwerks für die gewählte Anwendung oder Gruppe vorschlagen. Diesen Vorschlag kontrollieren Sie dann im Bereich "Recommendations", bearbeiten ihn gegebenenfalls und übertragen ihn in das Regelwerk der DFW.

vRealize Network Insight (vRNI) ist das zweite Tool, das die Netzwerkkommunikation umfassend betrachtet. vRNI sammelt nicht nur die Informationen vom Datacenter (ESXi und NSX), sondern kümmert sich auch um das nicht virtualisierte Netzwerkequipment (Switches, Router, Server, SD-WAN et cetera) und sammelt Daten per NetFlow, SNMP und CLI-Auswertung. vRNI bietet neben der FBAD (Flow Based Applications Detection) auch eine Security-Planung. Dies ist besonders dann sinnvoll, wenn Sie keine Details zu den Applikationen haben. vRNI errechnet aus den Messdaten die Wahrscheinlichkeit, dass VMs zu einer Anwendung gehören, und bietet diese dann als Vorschlag an. Die nun erkannten Applikationen nutzen Sie mit der Funktion "Security Planning", um eine Vorschlagsliste für die notwendige Allow-Liste der Firewall-Regeln für die DFW zu bekommen. Leider gibt es derzeit noch keinen automatischen Import dieser empfohlenen Firewall-Regeln in die DFW und Sie müssen mit einem Skript arbeiten.

Microsegmentierung ist eine Funktion der Verkehrsfilterung, da die virtuellen Netzwerkkarten (vnic) der VMs direkt mit dem VMkernel-Port des Hypervisors (ESX) verbunden sind. Dadurch lässt sich jedes Datenpaket von und zu der VM mit einer L7-Firewall (DFW) filtern. Somit ist auch das Filtern von Verkehr von nebeneinanderliegenden VMs auf demselben oder über verschiedene Hosts verteilten Hypervisoren machbar. Mit der NSX-Microsegmentierung wird der Zero-Trust-Ansatz erst möglich, da sich nun alle notwendigen Flows für eine bestimmte Applikation in einer Allow-Regelliste erlauben lassen und damit ein impliziertes Verbot den Verkehr blockt, der nicht notwendig ist oder sogar gefährlich sein kann. Diese Filterfunktion ist im Hypervisor-Kernel eingebettet und ausreichend performant.

Zero Trust bedeutet, dass als Best Practice Regeln für Applikationen vorliegen, die nur den notwendigen Verkehr erlauben. Hierzu sollten Sie sich vom alten Verfahren der fünf Tupels (Source/Destination -IP-Adresse, Source/Destination-Port und Protokoll) lösen. Gruppen, die auf einer manuellen oder einer automatischen Zuordnung per Tags basieren, und benannte Services (Protokoll) verbessern die Lese- und Wartbarkeit der Policies und Regeln.

Für zusätzliche Sicherheit können Sie bei NSX-T nun auch Context-Profile (L7-Service-Inspektion) einschalten. Um die Optimierung der Performance und Skalierung zu erhöhen, sollten Sie Regeln nur dort anwenden, wo auch der zu filternde Verkehr einer VM entsteht (Anwendung auf Gruppen).

Nachdem nun ausschließlich der "gute" Verkehr vom Hypervisor transportiert wird, sollten Sie diesen zusätzlich untersuchen und qualifizieren. Dazu bieten sich die zusätzlichen Sicherheitsfunktionen von NSX an:

- Das Intrusion Detection System inspiziert den Netzwerkverkehr (wie die DFW) im Hypervisor zur VM und prüft auf bekannte Cyberangriffe anhand der Signaturen. Das Intrusion Prevention System (IPS) unterstützt das IDS mit Funktionen, die die Lieferung von Paketen verhindern (Drop) oder den Angriff versuchen zu stoppen (Reset).

- Network Detection and Reponse ist ein System zur Erkennung von Angriffen oder Bedrohungen und zur forensischen Analyse, wenn ein Angriff schon passiert ist. NDR vereint verschiedene Sicherheitstools wie verhaltensbasierende Verkehrsanalyse, IDS/IPS und Sandbox für weitere Analysen.

- Mit der Identity-Firewall kreieren Sie nutzerbasierende Regeln für die DFW und müssen nicht nur auf Applikationsebene filtern. Hierzu gibt es Schnittstellen für AD und LDAP. Die Kombination mit zeitbasierenden Regeln ist ebenfalls möglich.

- URL-Filterung: Für den Verkehr ins und aus dem Datacenter ist eine reputationsbasierende und themenspezifische Filterung (FQDN/URL) von Verkehr an der Gateway-Firewall möglich.

Der Vorteil ist, dass das Filtern der DFW im Hypervisor – vergleichbar mit IDS/IPS – erfolgt. Die Leistungsauswirkung ist überschau- und optimierbar. So wie bei den Firewallregeln und der Zuordnung zu Gruppen von VMs lässt sich IDS/IPS über die Metadaten (Anwendungsinformationen) an die jeweiligen Applikationen binden und damit die Menge der zu prüfenden Signaturen begrenzen. Dies optimiert die Performance und reduziert False-Positives.

Bei der Erstinstallation von IDS sollte der IPS-Teil auf "Monitor" stehen und keine Pakete verwerfen oder Verbindungen blockieren. Diese Konfiguration passen Sie gegebenenfalls auf Basis der Log-Nachrichten an. Dies erledigen Sie unter "Security" und "Distributed IDS/IPS". Der Vorgang beinhaltet auch das Erstellen der Basiseinstellung. Hier definieren Sie auch, wann und wie die Signaturen aktualisiert werden (direkt, Proxy oder per File) und auf welchen Clustern das IPS/IDS laufen soll. Profile für die verschieden Signaturen können Sie erstellen und dann als Regeln für verschiedene Kommunikationsbeziehungen anwenden (Detect Only oder Detect & Prevent). Das Monitoring dazu findet auch im NSX-Manager statt.

Für den NDR-Teil (original Lastline) benötigen Sie etwas mehr Vorbereitung und Expertise, obgleich die Basisinstallation mit Network-Sensor, Data Node, Engine und Manager sehr schnell erledigt ist. Hierbei müssen Sie aber auf die Hardwareanforderungen achten: Zum Beispiel braucht der 10-GBit-Netzwerk-Sensor 128 GByte RAM und zwei Intel-Xeon-Silver-4114-Prozessoren. Die anderen Komponenten begnügen sich mit 64 GByte RAM und einem Prozessor.

NDR bietet für den Ost-West-Verkehr im Datacenter und in Multicloud-Umgebungen eine Analyse und verschiedene Reaktionsfunktionen an. Die Analyse umfasst den VMware NSX Advanced Threat Analyzer, IDS/IPS, eine Sandbox für die tiefere Analyse und vor allem eine verhaltensbasierende Analyse auf Basis von KI. Die Erkennungsfunktionen können automatisierte Gegenaktionen, wie Flow-Manipulation, erweiterte Forensik, Integration in Security-Anwendungen (SIEM, SOAR, Firewalls und Endpunktsicherheit) und das aktive Aufspüren von Netzwerkbedrohungen, starten. VMware plant, diese aktuell noch eigenstehende Lösung in die kommende NSX-Version zu integrieren.

Die Integration von Identität in die DFW von NSX bringt erweiterte Sicherheit. Sie erlaubt Ihnen, sich von der applikationsbasierten Regel zu lösen und den Nutzer in die Betrachtung einzubeziehen. Somit sind Sie nun in der Lage, eine Regel zu erstellen, die es dem VDI-User "Gerd" erlaubt, eine Anwendung zu nutzen und es dem VDI-User "Jörg" zu verbieten. Diese Regeln lassen sich auch noch mit Zeitinformationen erweitern. Hierzu legen Sie im NSX-Manager im Bereich "System" als Anbindung das AD oder einen LDAP-Server an. Beim Erstellen von Firewall-Regeln geben Sie als "Source" eine Gruppe an, deren Mitglieder aus den AD-Gruppen stammen. Damit wird die Identität Teil des Regelwerks und löst damit die klassische IP-Adresse ab.

Der letzte aktive Schritt der Reise zu Zero Trust ist die intelligente Filterung auf Basis statischer Konfiguration und der Reputation von Domain Namen und URLs. Bei der statischen Konfiguration erstellen Sie als Erstes eine Regel für das Protokoll wie zum Beispiel DNS und definieren dann die zu adressierende Domain als weitere Regel. Dazu hinterlegen Sie im "Service-Context" den FQDN. Für das reputationsbasierte Filtern von URLs wählen Sie im Bereich "Security" die Option "URL Analysis" . Nach dem Aktivieren der URL-Filterung wählen Sie die Attribute aus und konfigurieren als Kontext "Profile". Dazu stehen Ihnen 80 URL-Kategorien zur Verfügung. Wichtig ist es, dass die Regeln zur Filterung von FQDN und URL nur auf den Gateway-Firewalls funktionieren. Die Reputationsdatenbank wird regelmäßig angepasst und stammt von der Firma Webroot.

Unser letzter Schritt umfasst die notwendigen Managementsysteme. Hier bieten sich SIEM (Security Information and Event Management) und SOAR (Security Orchestration Automation and Response) an. SIEM sammelt ausgewählte Protokoll-, Ergebnis- und Logdaten aus verschiedenen Zero-Trust-Quellen wie Perimeter-, Gateway- und Distributed-Firewall sowie IDS/IPS und NDR und korreliert diese Infos mit Daten von Netzwerken, Servern und Anwendungen. Die Daten wandern zur Analyse ins SIEM-System, das auf dieser Basis die Bedrohungen darstellt.

SOAR ist ein neuer Ansatz in der Analyse der Gefährdung. Wie beim SIEM-System sammelt SOAR zusätzliche Daten auch aus externen Quellen, wie etwa Threat Intelligence Feeds von Anbietern von Sicherheitssoftware. Diese meist cloudbasierten Daten spiegeln das Sicherheitswissen der angeschlossenen Systeme und Kunden wider und erlauben es somit, automatisiert auf Sicherheitsvorfälle zu reagieren. SOAR-Systeme versprechen eine höhere Effizienz des Zero-Trust-Gesamtsystems. Beispiele für SIEM/SOAR-Produkte sind Datadog, SolarWinds oder Splunk.

Mit NSX-T ist die Reise zu Zero Trust in den geschilderten fünf Schritten mit den integrierten Sicherheitsfunktionen relativ einfach möglich. Durch die Filterfunktion im Hypervisor hat VMware hier ein Alleinstellungsmerkmal, das IT-Verantwortlichen vor allem bei der Mikrosegmentierung und IDS/IPS entgegenkommt. Mit den drei ersten Schritten – Makrosegmentierung, Traffic- und App-Analyse und Mikrosegmentierung – erreichen Sie bereits einen sehr wirkungsvollen Grundschutz. Die weiteren Schritte mit Zusatzfunktionen und Management sind optional und können auch nachgerüstet werden.