04.02.2021 / Kategorie: Cloud Security
Wurde Ihre Remote Access Lösung im vergangenen Jahr auf die Probe gestellt? Machen Sie sich Gedanken über deren künftige Form? Zero Trust Network Access ist ein Ansatz, um einige Nachteile klassischer VPN Remote Access Lösungen zu überwinden. Die Ereignisse des Jahres 2020 haben bekannte Muster auf den Kopf gestellt, als Home-Office über Nacht zur Norm und die Firmenbüros leer wurden. Zahlreiche Organisationen wurden zum Umdenken gezwungen und stellten sich auf die neue Normalität ein.
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.
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.
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.
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:
Wie löst ZTNA dabei die Herausforderungen klassischer Lösungen?
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.
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.
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.
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.
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.
Unabhängig vom Anwendungsfall sollte jede evaluierte Lösung einige Best Practices erfüllen. Die wichtigsten sind:
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.
Haben Sie Fragen zu unseren News, Events oder Blogartikeln? Nehmen Sie mit mir Kontakt auf.
Reiner Höfinger
Marketing & Communications