Mitarbeiter müssen längst nicht mehr am Schreibtisch oder im Büro sitzen, um ihre Aufgaben zu erledigen. Mit den leistungsfähigen Mobilgeräten und Geschäftsanwendungen in der Cloud können sie jederzeit und überall arbeiten. Die flexiblen Arbeitsmöglichkeiten zwingen Unternehmen dazu, neue Strategien für den sicheren und performanten Zugriff auf Anwendungen und Daten von überall aus zu entwickeln.

Eine Umfrage von Atomik Research unter mehr als 400 IT-Entscheidern aus Großbritannien, Deutschland, Frankreich und Benelux ergab, dass durchschnittlich 61 Prozent der Mitarbeiter mobile Geräte nutzen, um aus der Ferne auf Daten und Anwendungen im internen Netzwerk oder der Cloud zuzugreifen. Traditionelle Sicherheitsmaßnahmen wie Remote Access VPNs greifen hier nicht mehr lückenlos. Denn im Mittelpunkt traditioneller Sicherheitskonzepte steht ein vertrauensbasierter Ansatz: Erhält ein Nutzer per Remote Access VPN Zugriff auf das Unternehmensnetz, kann er dort oft auf alle Daten und Anwendungen zugreifen – sofern das Unternehmen den Aufwand und die Komplexität der Netzwerksegmentierung scheut. Ein solch grenzenloses Vertrauen kann sich allerdings als gefährlich für das Unternehmen erweisen und das Sicherheitssystem unterlaufen.

RAS-VPN (RAS: Remote Access Service) ist bei einer Mehrheit der Unternehmen nach wie vor notwendig. Sie benötigen es für den Fernzugriff externer Nutzer auf das interne Netzwerk sowie zunehmend auch auf Anwendungen, die man in die Cloud verlagert hat: 49 Prozent der im Rahmen einer Cloud-Transformationsstudie befragten europäischen CIOs/CISOs gaben an, dass ihre Unternehmen auf Remote ­Access VPN für den Fernzugriff auf alle Geschäftsanwendungen setzen. Allerdings wurden im Zuge der Umfrage auch Bedenken hinsichtlich der Sicherheit laut. Im Zusammenhang mit der zunehmenden Cloud-Nutzung äußerten sich europaweit 80 Prozent der Befragten besorgt darüber, wie Mitarbeiter auf interne Anwendungen zugreifen. Hier liegt der wunde Punkt klassischer RAS-VPN-Konzepte: In einem ersten Schritt erstellt man zunächst die Verbindung zum Netzwerk, um sie dann durch Firewall-Regeln wieder einzuschränken. Dieser Prozess ist nicht nur komplex, sondern auch fehleranfällig. Zudem kann man ihn nur schwer einer Revision unterziehen, was das Sicherheitsrisiko vergrößert. Ist das Gerät eines Mitarbeiters kompromittiert, können unautorisierte Personen auf sensible Informationen zugreifen und Schadsoftware in das Netzwerk einschleusen.

Kein Vertrauen mehr

Als Alternative zum grenzenlosen Vertrauen beim Fernzugriff kam vor einigen Jahren „Zero Trust“ als Begriff für ein neues Sicherheitskonzept in Mode. Dieser Ansatz propagiert Einfachheit als oberste Prämisse, um Anwender standort- und netzwerkunabhängig sicher mit ihren Applikationen zu verbinden. Auf den ersten Blick erscheint der Name irreführend, ist doch Vertrauen unvermeidlich, um den richtigen Nutzer mit der gewünschten Anwendung zu verbinden. Zero Trust ist hier schlicht das übergeordnete Ziel, das man mit einem sogenannten softwaredefinierten Perimeter (SDP) erreichen kann. Gartner steuert mit seinem CARTA-Modell den Prozess bei, basierend auf einem adaptiven Zugriff. Dabei ist es entscheidend, dass Vertrauen in den Anwender oder sein Gerät nicht vorausgesetzt wird: Software stellt es erst im Kontext her und kontrolliert es dann mittels fortlaufender Risikobewertung.

Die Grundidee des SDPs: Kein Nutzer erhält Zugriff auf die gewünschte Anwendung, bevor er nicht in einem ersten Schritt für den Zugang autorisiert ist. Dies stellt das traditionelle Zugriffskonzept auf den Kopf, bei dem erst die Verbindung ins Netzwerk erfolgt und im Anschluss die Autorisierung. In einem Arbeitsalltag, der von Cloud und Mobilität geprägt ist, wird es immer wichtiger, dass Unternehmen ihren Mitarbeitern einen sicheren Pfad für den Zugriff auf ihre Anwendungen anbieten, wo auch immer sie diese Applikationen vorhalten – im HRZ oder in der Cloud. Aus Gründen der Anwenderfreundlichkeit bemerkt der Nutzer beim Fernzugriff auf seine Apps im Idealfall nicht einmal mehr, wo sich diese befinden.

Der softwaredefinierten Ansatz entkoppelt den Anwender vom Netzwerk. Das einzige, was zählt, ist das Etablieren der Zugriffsberechtigung auf der Applikationsebene. Dem Anwender erleichtert dieser Ansatz den Zugriff: Er muss sich keine Gedanken mehr machen, welchen Weg er zu seiner Anwendung einschlagen muss. Denn SDP ermöglicht 1:n-Standortverbindungen und rückt damit von der 1:1-Verbindung des traditionellen VPN-Konzepts ab. Der Anwender kann also gleichzeitig mit unterschiedlichen Arbeitsumgebungen im internen Netzwerk und in der Cloud verbunden sein. So muss der Nutzer nicht mehr darüber nachdenken, auf welche Umgebung er zugreifen muss: Er verbindet sich nicht mehr mit einem Netzwerk, sondern erhält auf direktem Weg Zugang zu seiner Anwendung. Für etwaige Schadsoftware auf seinem Arbeitsgerät bleibt das restliche Netzwerk unsichtbar – und entzieht sich damit einem Angriff.

Funktionsweise des SDPs

Im Mittelpunkt eines SDP-Ansatzes steht, dass keine Verbindung zu einem Netzwerk oder Standort hergestellt wird. Die Identität des Benutzers steuert und kontrolliert den Anwendungszugriff: Hat der Benutzer keine Zugriffsberechtigung, kann er nicht einmal sehen, welche Anwendungen vorhanden sind. Dieser Ansatz erfordert das Regeln der Zugriffserlaubnis sowie eine Policy Engine. Die Erlaubnis für den Zugriff auf eine Anwendung kann im Zero-Trust-Modell durch unterschiedliche Vorgehensweisen geregelt sein. Gartners „Zero Trust Network Access“-Kategorisierung unterscheidet zwischen dem User-initiierten Pfad und dem Service-initiierten Ansatz. Im ersten Fall erzeugt der Nutzer eine Anfrage für die Zugriffsberechtigung auf eine Anwendung über seinen Web-Browser. Wird der Anwender für den Zugriff autorisiert, erfolgt die Verbindung zur Applikation über das existierende Netzwerk und einen Internet-Link. Bei der zweiten Vorgehensweise stellt ein zwischengeschalteter Service (Broker) die Verbindung zur Anwendung her. Dies erfordert eine Software zur Weiterleitung des Traffics, die granulare Kontrollfunktion zwischen Anwender und Applikation bietet. Dieser Ansatz stellt die Verbindung nicht über das öffentliche Internet her, sondern über eine private Infrastruktur, somit also besser isoliert.

Bei beiden Modellen erfolgt der Zugriff erst nach der Autorisierung des Anwenders. Auf Basis von SAML 2.0 (Secure Application Markup Language) kommt zur Autorisierung die vorhandene IDP-Datenbank des Identity Providers des Unternehmens zum Einsatz. Hier ist die Policy Engine angesiedelt, die nach der Autorisierung die Zugriffsrechte eines Anwenders umsetzt und entscheidet, zu welcher Anwendung eine Verbindung erlaubt ist. Dazu muss die Zugriffsanfrage des Anwenders mit einer vorhandenen Regel übereinstimmen. Die Policy Engine funktioniert wahlweise auf Basis einer einzelnen IP-Adresse oder eines FQDN (Fully Qualified Domain Name); auch kann sie sich breiter konfiguriert sein und einen Netzwerknamen oder gar Wild Cards umfassen.

Auch in der Policy Engine kann man zwei Ansätze unterscheiden. Vorherrschend ist das SDP-Modell, bei dem das SDP-Gateway nach Autorisierung des Nutzers eine Nachricht an den Anwender schickt, mit welchem Gateway er sich für seine gewünschte Anwendung verbinden muss. Diesen Vorgang kann man sich wie einen Redirect (Umleitung) zum Standort der Anwendung vorstellen, der den Nutzer über das Internet zu einer IP-Adresse routet. Dieses Modell etabliert eine eingehende Verbindung über das Internet. Dabei können alle gängigen UDP- und TCP/IP-Ports zum Einsatz kommen, um den Datenverkehr per Web-Browser weiterzuleiten.

Im Unterschied dazu geht der Verbindungsaufbau beim zweiten Ansatz nicht vom Nutzer, sondern von der Anwendung aus: Die Applikation baut die Sitzung auf, sobald der Anwender sie nutzt. Sogenannte Enforcement Nodes verknüpfen als Vermittlungsinstanz die beiden ausgehenden Anfragen – vom Anwender und der Applikation – und ermöglichen so den autorisierten Zugriff. Dies findet unabhängig von einer Internet-Verbindung statt. Da die Applikation nicht dem Internet ausgesetzt ist, erhöht dieser Ansatz die Sicherheit: Was nicht sichtbar ist, entzieht sich Angriffen. Auf diese Weise wird aufwendige Netzwerksegmentierung überflüssig, denn es erfolgt eine Mikrosegmentierung auf Anwendungsebene mit Ende-zu-Ende-TLS-Verschlüsselung, was die laterale Ausbreitung eines Angriffs im Netzwerk automatisch unterbindet.

Unternehmen können dabei den Zugriff auf ihre internen Anwendungen über die zentrale Administrationsoberfläche der Cloud selbst steuern und somit bestimmen, welche Benutzer auf welche Anwendungen zugreifen dürfen. Der Administrator kann die Zugriffsrichtlinien über ein Dashboard in Echtzeit konfigurieren.

Nathan Howe ist Principal Architect bei Zscaler, www.zscaler.com.