Zero Trust Network Access (ZTNA) ist heute ein strategischer Ansatz, seine Applikationen und Services zu schützen. Allein in diesem Blog gibt es mehrere Artikel, die das Thema behandeln (vgl. www.tec-bite.ch/?s=ztna). Ich möchte in diesem Artikel daher nicht auf die Definition oder den strategischen Aspekt eingehen, sondern viel mehr ein mögliches Konstrukt mit Zscaler Private Access (ZPA) präsentieren.

Wenn wir uns mit ZPA beschäftigen, dann wird uns schnell klar, dass wir mit ZPA den ZTNA Ansatz gut umsetzen können. Im Weiteren können wir mit ZPA auch eine Möglichkeit finden, eine effektive und solide Micro-Segmentierung anzubieten und jeden Server (in unserem Kontext «Applikation» genannt) zu separieren.

Schauen wir doch nochmals auf das Basis Design von ZPA.

Diese Applikation stellt eine sichere Verbindung (TLS verschlüsselt), ausgehend zu einer Cloud-Komponente (Zscaler Service Broker) bereit.

Auf der Server Seite haben wir einen Server am Laufen, welcher ebenfalls ausgehend eine sichere Verbindung zum Zscaler Service Broker aufbaut und durch diesen Kanal den Zugriff auf die Applikation bereitstellt. Den App Connector können wir dabei nahe den Applikationen hosten oder nach Bedarf in einer DMZ betreiben. Verfügbar ist dieser als fertige VM für diverse Cloud-Umgebungen wie Azure oder AWS, aber auch als Package für REHL oder CentOS.

Um die Sicherheit zu erhöhen, können wir eine übergelagerte Verschlüsselung zwischen dem ZCC (1) und dem App Connector (3) konfigurieren.

Typischerweise kommt ZPA als Ersatz für klassische VPNs ins Spiel und schlägt dort die Konkurrenz sehr oft durch seine Benutzerfreundlichkeit. Dies da automatisch die Lastverteilung und die Pfad-Selektion vom Client zu der jeweiligen Applikation übernommen wird. Wobei der Client niemals Teil des Netzwerkes wird und die Applikationen sich hinter einer pseudo IP verbergen und Zscaler die Rolle des Access Brokers übernimmt (Zero Trust Ansatz). Wenn man nun die Applikation unter sich separiert und den Zscaler App Connector als zentrale Access Komponente versteht, können wir so die Applikation auch sehr gut physisch trennen (erster Ansatz der Micro-Segmentierung), wobei der Service Broker (2) die Aufgabe der Zugriffskontrolle übernimmt.

Dadurch, dass der App Connector (3) nur eine ausgehende Verbindung zur Cloud benötigt, ist dieser auch von extern nicht erreichbar – womit viele Angriffsvektoren entfallen oder DDOS-Attacken erschwert werden.

Nun erkennen wir schnell, dass dieser Ansatz eine optimale Möglichkeit darstellt, Benutzern, welche in der Welt unterwegs sind (sogenannte RoadWarriors), den Zugriff auf unsere Applikationen zu ermöglichen (siehe Grafik von oben).

Doch was, wenn sich der Benutzer im lokalen Netzwerk befindet? Aus Latenzgründen oder um die Bandbreite der ISP Leitung nicht ans Limit zu bringen, macht es oft wenig Sinn, den Traffic in die Cloud zum Service Broker (2) zu schicken, damit er dort kehrt und zum App Connector (3), welcher sich im selben internen Netz (bzw. Standort) wie der Client befindet, zu schicken.

Bei den ersten ZPA Projekten, die umgesetzt wurden, haben wir anhand eines Trust-Kriteriums festgestellt, ob sich der ZCC (1) ausserhalb des eigenen Firmennetzwerks befindet (off trusted network) oder innerhalb des Firmennetzwerks (on trusted network). Anhand dieser Detektion hat sich die ZPA Logik entsprechend im Firmennetzwerk komplett ausgeschaltet und der Zugriff auf die Applikationen fand entsprechend den Routing-Topologien statt.

Dadurch wurde der ZTNA und Micro-Segmentierung Ansatz aufgeweicht und die Applikationen waren direkt erreichbar und können so potenziell eher angegriffen werden.

Um ZPA auch im Firmen-Netzwerk effektiv zu betreiben, bietet es sich an, den Zscaler Service Broker (2) lokal zu betreiben. Dies ist bei ZPA auch seit geraumer Zeit möglich. Den Broker kann man dabei so aufsetzen, dass er nur intern, aber bei Bedarf auch dediziert für die eigenen User von extern erreichbar ist. Ebenfalls seit diesem Jahr unterstützt der lokale Service Edge die Verwendung von SCIM, wodurch dieser denselben Funktionsumfang zu den Komponenten in der Cloud bietet.

Nun haben wir den Vorteil, dass wir den Ansatz des ZTNA mit ZPA im internen Netzwerk verfolgen können, ohne den Nachteil, dass der Traffic in die Cloud und zurückgesendet werden muss – wodurch wir die Latenz verringern können.

Ferner haben wir in der ZPA noch einen weiteren Kniff, auf den wir zurückgreifen können – die «Forwarding Policy». In der Forwarding Policy definieren wir, welcher Traffic unter welchen Bedingungen vom Zscaler Client Connector (1) zum Service Edge (2) gesendet wird. Angenommen wir haben für unsere Lokationen ein trusted Kriterium definiert, anhand welchem wir feststellen können, an welcher Lokation sich der Client befindet (daher: ob er sich am Standort A, B oder C befindet) – so können wir in der Forwarding Policy dieses Kriterium verwenden um z.B. den Traffic an der Lokation, an der sich der Client befindet, direkt an den jeweiligen Server zu schicken (z.B. Traffic an der Lokation A geht auch direkt an die Applikationen an der Lokation A ohne ZPA). Die Verbindungen zu den Applikationen an Standort B oder C werden jedoch weiterhin via ZPA gesendet. So haben wir quasi einen Hybrid-Ansatz, welcher erfordert, dass wir im ZPA Portal die Applikationen und Applikationssegmente auch sauber trennen bzw. definieren und das (Access- und Forwarding-) Regelwerk sauber aufarbeiten.

Bis dato fehlt mir leider die Umgebung, um diese Strategie in grösseren Netzwerken umzusetzen und zu verfolgen. In kleineren Umgebungen habe ich eine solche Strategie schon mit Erfolg umsetzen können ohne nennenswert grössere Latenzen.

ZTNA mit ZPA funktioniert sehr gut und kann als strategische Lösung eingesetzt werden, um den Traffic und den Zugriff auf Applikationen zu steuern, unabhängig der Lokation des Clients und ohne Veränderung der Arbeitsweise des Endanwenders (dieser muss sich z.B. bei ZPA keine Gedanken mehr machen, mit welchem VPN Gateway er sich an unterschiedlichen Geo-Lokationen verbinden muss).

Eine der grössten Herausforderungen ist es aus meiner Sicht, die Applikationen zu trennen. Bei traditionellen Netzwerken haben wir oft die Denkweise von Netzen und DMZen mit entsprechenden Klassifizierungen von Services und Sicherheitsniveaus. ZTNA, insbesondere der Ansatz der Mikro-Segmentierung, setzt vermehrt auf eine granulare Zugriffskontrolle mit FQDNs und weniger in Netzwerk-Adressen. Die Transformation von klassischen IP-Netzen zu ZPA (insbesondere den Applikationssegmenten) sollte also strategisch angedacht und auch sauber umgesetzt werden, um das gesamte Potenzial nutzen zu können.