Zero Trust Network Access – eine Alternative zu klassischem VPN Remote Access

Burgmauern und Wassergräben

Benutzer konsumieren heute eine bunte Mischung von IT-Services, von Enterprise Apps über Web-Applikationen bis hin zu SaaS-Diensten. Dies geschieht sowohl über firmeneigene als auch private Endgeräte und praktisch zu jeder Zeit von beliebigen Orten aus. Dieses Nutzungsmuster hat die Annahme überholt, dass Firmengeräte in erster Linie innerhalb des klassischen Perimeters für interne Anwendungen eingesetzt werden. Ebenso vermischen BYOD (Bring Your Own Device) und die geschäftliche Nutzung privater Endgeräte die Grenzen zwischen Firmen-IT und externen Diensten.

Klassische IT-Security stützt sich stark auf Perimeterschutz und grobmaschige Netzwerksegmentierung. Zugriff auf Ressourcen wird üblicherweise auf Grund von «schwarz-weissen» Kriterien wie Netzwerk-Adresse oder Identitäten gewährt. Die Regelwerke vertrauen darauf, dass sich ein Benutzer und sein Endgerät zu Recht im Inneren eines Perimeters oder Netzwerksegments aufhalten.

Fernzugriffe von ausserhalb des Perimeters folgen in der klassischen IT-Security denselben Leitlinien. Ein Remote-Benutzer wird mit VPN RAS, Terminalserver oder ähnlichen Lösungen auf die Innenseite des Perimeters geleitet und geniesst von dort aus ein Vertrauensniveau ähnlich oder gleich einem internen Benutzer.

Security Inversion

Wir beobachten eine Umkehrung der etablierten «Innen-Aussen»-Denkmuster. Die Mehrheit der Endgeräte einer Organisation ist beweglich und befindet sich oft ausserhalb des Perimeters. Sie greifen gemeinsam mit organisationsfremden Endgeräten auf eine Kombination von internen und externen Webapplikationen, SaaS-Services und Legacy-Anwendungen zu. Firmengeräte befinden sich mehrheitlich ausserhalb des Perimeters, nutzen jedoch nach wie vor auch interne Anwendungen. BYOD trägt das Seine zur Vermischung von Privatem und Geschäftlichem bei. Externe Dienstleister und Freelancer sind häufig für die Erfüllung ihrer Aufgabe nur auf einen Teil der Unternehmensressourcen angewiesen. Die Durchsetzung dieser Rechtevergabe ist aufwändig, beinhaltet Policies über verschiedene Silo-Lösungen hinweg und wird oft vernachlässigt: VPN-Gateways, Firewalls, Jump Hosts, BYOD-Infrastrukturen und vieles mehr wollen stets gepflegt sein und sollen dennoch alle Businessprozesse zulassen.

Vertrauensfrage

Dieser traditionelle Perimeteransatz birgt mehrere Nachteile. Einem Akteur wird primär aufgrund seiner Netzwerkzugehörigkeit Zugriff gewährt, anstatt aufgrund seines effektiven Bedarfs nach dem Least Privilege Prinzip. Dies bietet beispielsweise Raum für exzessive Zugriffsrechte oder Lateral Movement eines Angreifers. Für Benutzer ausserhalb des Perimeters – im Home-Office oder auf Reisen – ist üblicherweise ein manueller Aufbau der VPN-Verbindung erforderlich. Dabei führt die VPN-Verbindung allen Datenverkehr über den Perimeter. Beim Zugriff von extern führt der Datenverkehr sogar zweimal über den Perimeter. Im Zeitalter von Cloud-Diensten ist der Zugriff von aussen eher die Regel als die Ausnahme. Für das Funktionieren dieser Verkehrsführung in allen Lagen muss die Security-Infrastruktur auf das Bewältigen der Spitzenlast dimensioniert sein, sowohl hinsichtlich des Durchsatzes als auch der Lizenzen.

Warum ZTNA?

Zero Trust Network Access (ZTNA, auch als «Private Access» oder «Secure Corporate Access» bekannt) stellt für eine Vielzahl von Anwendungsfällen eine attraktive Alternative dar. Wichtige Treiber hinter ZTNA sind:

• Gewähren von Zugriffsrechten über eine einheitliche Policy gemäss dem Least Privilege Prinzip statt auf Grund von «schwarz-weissen» Legacy-Kriterien.
• Stützen der Vertrauenswürdigkeit eines Akteurs auf hilfreiche Attribute, wie Typ und Zustand des Endgeräts, Ort, Zeit, etc.
• Durchgängige Integration von Multifaktor-Authentisierung (MFA).
• Benutzer sollen VPN-Tunnels nicht mehr manuell aufbauen müssen.
• Einheitliche Sichtbarkeit über alle erfolgreichen und abgelehnten Zugriffe.
• Verkleinern der Angriffsfläche für Applikationen und Data Center.

Remote Access ohne eingehende Verbindungen – ein Widerspruch?

Wie löst ZTNA dabei die Herausforderungen klassischer Lösungen? 

• ZTNA wird üblicherweise als Cloudbasierter Dienst bereitgestellt. 
• Benutzer und Applikationen werden über gemeinsame Policies verwaltet, jedoch über individuelle, gesicherte Verbindungen mit dem Cloud-Backend verbunden. 
• Zentral ist dabei, dass auch der applikationsseitige Endpunkt eine ausgehende Verbindung ins Cloud-Backend aufbaut und damit keine eingehenden Firewall-Regeln oder extern geroutete IP-Adressen benötigt.
• Im Zug eines Benutzerzugriffs prüft die ZTNA-Policy alle erforderlichen Kriterien wie Identität, Endgerät, Ort, Zeit und weitere. 

Erst die Kombination aller erforderlichen Faktoren erlaubt dem Benutzer den Zugriff. Und nur bei Freigabe werden Client und Applikation im Cloud-Backend miteinander verknüpft. Für den legitimierten Benutzer verläuft dieser Prozess transparent, unabhängig von seinem Standort und von seiner Verbindungstechnologie.

Ein Gericht mit mehreren Geschmacksrichtungen

ZTNA existiert in unterschiedlichen Ausprägungen. Auf Client-Seite existieren sowohl Agentenbasierte wie auch Agentenlose Lösungen. Agenten bieten mehr Kontext und Einflussnahme auf das Endgerät als Agentenlose Lösungen.

Auf Applikationsseite kommen entweder klassische, tunnelfähige Endgeräte wie Router, L3-Switches oder Firewalls zum Einsatz, oder dedizierte Software-Appliances, welche in unmittelbarer Nähe der Zielapplikationen laufen und keinerlei Anpassung der klassischen Netzwerkinfrastruktur erfordern. In beiden Fällen erlaubt die ZTNA-Policy lediglich die Nutzung der erforderlichen Protokolle und IP-Adressen bzw. Hostnamen, um Lateral Movement im Keim zu ersticken. Der ausgehende Verbindungsaufbau kann auf öffentlich erreichbare IP-Adressen und Hostnamen verzichten und verkleinert so drastisch die Angriffsfläche für Data Center («Blackening») und Applikationsserver.

Endpoint-initiated oder Service-initiated

Im Cloud-Backend schliesslich wird zwischen «Endpoint-initiated» und «Service-initiated» ZTNA unterschieden. Ein zentrales Unterscheidungsmerkmal ist, ob die Benutzeridentität auf dem Endgerät oder im Cloud-Backend bestimmt wird. Ein weiterer Unterschied besteht darin, ob Applikationsprotokolle transparent durchgereicht auf einem virtuellen, webbasierten Gateway aufgebrochen werden, ähnlich einem Terminalserver. Ersteres stellt eine schlankere Lösung mit universeller Protokollunterstützung dar. Letzteres ist eher ein Gateway mit zahlreichen Eingriffs- und Überwachungsmöglichkeiten sowie der Option, auf einen Client-Agenten zu verzichten.

Welche Variante passt zu mir?

Die Wahl eines ZTNA-Services richtet sich nach den Anwendungsfällen. Agentenbasierte Lösungen stellen die bevorzugte Wahl für organisationseigene Mitarbeiter und Endgeräte dar. Agentenlose Lösungen eignen sich besser für Endgeräte ausserhalb der Kontrolle einer Organisation oder für solche, die invasive Agenten nicht unterstützen – beispielsweise iOS.
Steht für den applikationsseitigen Tunnelendpunkt ein existierendes Netzwerkprodukt, wie SD-WAN CPE, Router, Firewall oder dergleichen, zur Verfügung, ist keine weitere ZTNA-Komponente mehr notwendig. Ohne bestehendes Produkt, welches einen IPsec- oder GRE-Tunnel ins Cloud-Backend aufbauen kann, bietet sich eine Lösung via Softwarekomponente (VM, Container) an, welche eine ausgehende Verbindung aufbaut und möglichst nahe an der zu erschliessenden Applikation platziert ist.
Eine Lösung mit virtuellem Terminalserver empfiehlt sich, wenn ein Protokollbruch sowie eine lückenlose Aufzeichnung der Benutzeraktivitäten erforderlich sind, oder aber wenn kein Client-Agent eingesetzt werden kann. Andernfalls stellt eine Agentenbasierte Lösung eine schlanke, protokoll-agnostische Lösung dar, insbesondere für Legacy-Protokolle.

Kein Allheilmittel

ZTNA sollte nicht als genereller Ersatz für Web Application Firewalls (WAF) gesehen werden. Die Technologie eignet sich für definierte Benutzergruppen als VPN- bzw. RAS-Ersatz. Öffentliche Webapplikationen können über klassische oder Cloudbasierte WAFs geschützt werden oder es wird ein virtueller Terminalserver eingesetzt. Die Produktwahl wird mitunter auch von den Lizenzbestimmungen der ZTNA- bzw. WAF-Lösung sowie vom dahinter agierenden Identity- und Access-Management (IAM) gesteuert.

Worauf kommt es an?

Unabhängig vom Anwendungsfall sollte jede evaluierte Lösung einige Best Practices erfüllen. Die wichtigsten sind:

• Verfügbarkeit: Der ZTNA-Anbieter muss seine Verfügbarkeit in einem SLA garantieren und darf keine Single Points of Failure einsetzen. Eintritts- und Austrittspunkte seiner Infrastruktur (Points of Presence, PoP) müssen redundant vorhanden und sollten möglichst identisch aufgebaut sein. Rein virtuelle PoPs beeinträchtigen die Leistungsfähigkeit und damit die Benutzererfahrung.
• Performance: Die anbieterseitige Vernetzung der PoPs muss performant ausgelegt sein, was der Anbieter mit Latenzdaten belegen kann. Die Strecke über das öffentliche Internet auf dem Weg vom und zum anbietereigenen Backend sollte möglichst kurz sein.
• Identitätsmanagement: Die Integration in Identity Provider muss alle Ansprüche des Anwendungsfalls erfüllen, von Legacy Active Directory bis hin zu SaaS-Diensten.
• Sicherheit: Multifaktor-Authentisierung (MFA) ist Pflicht, entweder als integraler Lösungsbestandteil oder als API-Integration.
• Investitionsschutz: Verfügt der Anbieter über eine vielseitige SASE-Plattform (Secure Access Service Edge), die künftige Use Cases ohne Anbieterwechsel oder Infrastruktur-Lifecycling ermöglicht?

Zusammen. Sicher.

Welches sind die erfolgversprechenden Schritte in Richtung ZTNA? Ein Lifecycling der bestehenden VPN-Gateways ist ein Anlass, um bestehende Lösungen auf Performance, Skalierbarkeit und Lebenswegkosten zu hinterfragen. Visualisieren Sie Ihre VPN- bzw. RAS-Anwendungsfälle und die daran beteiligten Benutzergruppen sowie Services. Bilden Sie diese auf Ihre bestehende Remote Access Infrastruktur ab und identifizieren Sie Engpässe und Kostentreiber.

Benötigen Sie zu jeder Zeit die Spitzenkapazität einer On-Premise-Lösung? Sind Sie in der Lage, diese Kapazität über die Lebensdauer der Investition verlässlich und gleichzeitig kostenoptimiert zu dimensionieren? Stellen Sie die CAPEX und OPEX Kosten beider Varianten gegenüber – wir unterstützen Sie dabei!

Kontaktieren Sie uns via marketing[at]ispin.ch oder +41 44 838 3111.