Die ganze Welt spricht von ZTNA (Zero Trust Network Access) oder besser: «never trust, always verify». Das Konzept der Technologie soll einen sicheren, auf Applikationsebene steuerbaren Zugriff auf Anwendungen eines Unternehmens oder einer Organisation ermöglichen. Es werden also, anders als bei einem VPN, keine Tunnel zwischen Client und Unternehmensnetzwerk aufgebaut, sondern dedizierte Verbindungen zu Applikationen hergestellt. Stellen Sie sich vor, Ihre User könnten das CRM oder die Zeiterfassung von überall öffnen, ohne zuerst einen VPN Tunnel zum gesamten Netzwerk zu öffnen oder die Applikation ins Internet zu hängen.

Wie Fortinet diesen Ansatz verfolgt, werde ich in diesem Blog Artikel erläutern.


Never trust, always verify

Der Titel macht klar, wir vertrauen niemandem, ob ausserhalb oder innerhalb des Netzwerks, sondern verifizieren. Der Zugriff auf Anwendungen wird erst gewährt, nachdem das Gerät verifiziert, die Identität des Benutzers authentifiziert, der Benutzer autorisiert und dann kontextbasierte Status-Prüfungen mit Zero-Trust-Tags durchgeführt worden sind.


FortiClient EMS und FortiGate

Der FortiClient EMS (Endpoint Management Server) dient als ZTNA Certificate Auhtority (CA) und erstellt sowie signiert ein Zertifikat für jeden Client. Dieses Zertifikat, sowie auch das CA Zertifikat wird dann mit der FortiGate synchronisiert. Voraussetzung für den EMS Server ist natürlich die Erreichbarkeit von aussen, sodass die Telemetrie-Verbindung zum Client jederzeit bestehen bleibt. Den EMS Server gibt es sowohl on-Prem als auch als Cloud-Instanz.

Zero Trust Network Access mit Fortinet

Die sogenannten ZTNA Tagging Rules, welche benötigt werden, um die Clients anhand von Informationen zu taggen, werden ebenfalls mit der FortiGate synchronisiert. Solche Tags können ein Ruleset von verschiedenen Prüfungen enthalten wie zB. Operating System, Domain, Registry Key, AV Signaturen etc. um nur einige Beispiele zu nennen.

Auf der FortiGate werden nun ZTNA Rules erstellt, um so den Zugriff anhand von Tags zu steuern. In diesen Regeln können festgelegt werden, mit welchen Tags auf welche Applikation zugegriffen werden kann oder eben nicht. Natürlich kann auch die Source eingeschränkt werden auf zB. Geo Objekte.


HTTPS Access Proxy vs. TCP forwarding Proxy

Die FortiGate, welche als Trust Broker und Reverse Proxy fungiert, unterscheidet zwischen zwei Access Methoden. HTTPS Access Proxy fungiert als Reverse Proxy für den dahinter stehenden HTTP Server. Wenn ein Client auf eine Webseite im internen Netzwerk verbinden möchte, wird die Zieladresse auf die definierte VIP der FortiGate aufgelöst. Die FortiGate (hier als Proxy) wird anhand der ZTNA Rules entscheiden, ob der Zugriff gewährleistet wird oder nicht.

Der TCP Forwarding Access Proxy funktioniert hier etwas anders. Anstatt dass der Traffic zu einem Webserver proxiert wird, wird der Traffic zwischen Client und Access Proxy über HTTPS getunnelt und weitergeleitet zum entsprechenden Server. Der FortiClient auf dem Endpoint zeigt hierbei bei dieser Verbindung auf den Proxy und ebenfalls auf das entsprechende Zielsystem. Entsprechend den ZTNA Rules wird der Traffic anhand von ZTNA Tags und Zertifikat des Clients entweder erlaubt oder nicht. Wird er erlaubt, wird der TCP Traffic weitergeleitet und eine End-to-End Verbindung wird initiiert.

Zero Trust Network Access mit Fortinet
Figure 1, Quelle: https://docs.fortinet.com/document/fortigate/7.2.0/administration-guide/101256/ztna-tcp-forwarding-access-proxy-example, abgerufen am 31.08.22.

Fully-Qualified Domain Name (FQDN)

FQDN ist hier natürlich ebenfalls ein Thema, um beispielsweise interne Adressen von den Usern zu verbergen oder, der Einfachheit halber, damit die User, ob intern oder extern, immer denselben Namen verwenden können. Auch hierfür gibt es von Fortinet eine Lösung dies abzubilden. Hierbei wird der FQDN auf der FortiGate eingerichtet. Der FortiClient auf dem Endgerät wird dann einen Eintrag im Hosts File erstellen, wobei es den Namen server.firma.int auf eine falsche IP zeigen lässt. Der FortiClient schickt dann alles an diese IP an den Proxy mit der Destination als FQDN. Im GET-Request ist der Hostname dann ersichtlich und der Zugriff kann vom Proxy weiterverarbeitet werden.


Vorteile gegenüber klassischem VPN

ZTNA bietet einige Vorteile zu klassischem VPN. Basierend auf Identität, Gerätestatus und Kontext wird ausschliesslich auf die entsprechende Applikation erlaubt und das unabhängig von der Lokation des entsprechenden Users/Client. Es wird also pro Session authentifiziert und geprüft und nicht nur einmal wie das bei VPN der Fall ist. Sollte sich der Status eines Gerätes ändern, werden automatisch auch die ZTNA Tags auf dem Device ändern und die Zugriffe auf die entsprechende Ressource blockiert werden.


Fazit

Für mich ist und bleibt ZTNA ein spannendes Thema, welches ich gerne weiterverfolge. Wer bereits FortiClients mit dem FortiClient EMS Managed hat, sollte bereits in der Lage sein, das Feature zu nutzen, denn das Feature ist in der kleinsten Lizenz (ZTNA) bereits vorhanden. Somit kann eine stufenweise Ablösung von wichtigen Applikationen weg vom normalem VPN angegangen werden. Wichtig ist hier wohl der Aufbau der Tags, wie man dies gestalten möchte, und welche Device Prüfungen durchgeführt werden sollten.