Der Weg zum Zero-Trust-Networking (1)

Von Evren Eren, Bremen

Klassische IT-Infrastrukturen von Unternehmen umfassen in der Regel ein segmentiertes Netzwerk mit Client- und Server-Systemen – die gesamte Infrastruktur wird von der äußeren Umgebung abgeschirmt und interne Netze voneinander getrennt. Dabei gehen traditionelle Sicherheitskonzepte davon aus, dass alle Dienste, Geräte und Anwender innerhalb des eigenen Netzwerks vertrauenswürdig sind. Als potenziell gefährlich eingestuft werden Netzwerkverkehr und Zugriffe von außen.

Die Abwehr eines in das Firmennetz eingedrungenen Angreifers zeigt hier wenig Wirksamkeit, denn dieser könnte auf sensible Informationen und Daten zugreifen oder das Netzwerk in seinem Sinne manipulieren. Um dem entgegenzuwirken, ist das Einrichten von Sicherheitszonen nützlich: Nur Systeme in derselben Sicherheitszone – Unternehmensbereiche mit gleichen Anforderungen oder demselben Schutzbedarf – dürfen dann miteinander kommunizieren. In jeder Zone wird die Verbindung terminiert und mit der nächsten neu aufgebaut (z. B. DMZ, Trusted und Privileged Zone). So kann man verhindern, dass ein Angreifer bei Übernahme einer Zone das gesamte Netzwerk übernimmt. Abbildung 1 zeigt exemplarisch eine hybride Umgebung, um die Limitierungen zu veranschaulichen.

Drinnen und draußen

Im Perimeter-Modell wird davon ausgegangen, dass sich Teilnehmer eindeutig sicheren internen oder unsicheren externen Netzwerken (Internet) zuteilen lassen. Durch zunehmende Mobilität bewegen sich Mitarbeiter mit ihren Clients jedoch zwischen den verschiedenen Sicherheitsbereichen – um das Perimeter-Modell weiterhin aufrechtzuerhalten, kommen Virtual Private Networks (VPNs) zum Einsatz. In hybriden Cloud-Umgebungen können sich, zusätzlich zu den Clients, auch Dienste in unsicheren Netzwerken befinden. Nach dem Perimeter-Modell müsste der „Schutzkreis“ eigentlich auch um diese Dienste im unsicheren Netzwerk gespannt werden. Die Grenzen zwischen sicherem und unsicherem Netzwerk verschwimmen und das Perimeter-Modell verliert an Wirkung.

In diesem Zusammenhang spielen Public-Key-Infrastructures (PKIs) eine wichtige Rolle, indem sie die Grundlage für authentifizierte und verschlüsselte Kommunikation bilden. Allerdings werden unternehmensinterne PKIs über Unternehmensgrenzen hinweg als nicht-vertrauenswürdig eingestuft. Während Unternehmen die Vertrauensstellung der internen PKI selbst bestimmen können, müssen öffentliche PKIs einen langwierigen Prozess durchlaufen, damit ihre Vertrauensstellung offiziell anerkannt wird.

Einen weiteren Punkt zur Absicherung von Netzwerkbereichen bildet Network-Access-Control (NAC). Sobald sich jedoch Clients und Dienste außerhalb von kontrollierten Netzwerkbereichen befinden, verliert NAC die Schutzwirkung: Sind Clients im Internet und greifen von dort direkt auf Cloud-Dienste zu, vermag NAC den Dienst nicht mehr vor unautorisierten Zugriffen zu schützen, was die Wirksamkeit in hybriden und vollständigen Cloud-Umgebungen reduziert.

Dass zukünftig die Kommunikation aus dem internen Netzwerk in Richtung Cloud-Dienste zunehmen wird, ist auch für den Einsatz von Firewalls relevant. Einige Cloud-Anbieter raten dazu, mit Cloud-Diensten direkt, und nicht über einen Proxy, zu kommunizieren. Das kann dazu führen, dass Firewall-Regeln breiter definiert werden müssen und dadurch die Segmentierung von Netzwerken ineffizient wird.

In hybriden Umgebungen stehen weniger Systeme in der klassischen Infrastruktur und mehr in der Cloud, was die Last auf Proxies als Zugangspunkt zum Internet erhöht. Reverse-Proxies verlieren an Bedeutung, da sich mehr Dienste in der Cloud befinden und weniger Zugriffe auf das interne Netzwerk notwendig sind – auch deshalb raten einige Cloud-Anbieter von deren Einsatz ab. Folgt man diesem Rat, muss man jedoch Sicherheitsmaßnahmen verlagern!

Ein letzter Aspekt ist die Benutzer- und Berechtigungsverwaltung: Eine lokale Administration ist in hybriden Umgebungen risikoreicher als in klassischen Infrastrukturen – und ohne weitere Sicherheitsmaßnahmen nicht zu empfehlen. Eine zentrale Benutzerverwaltung eignet sich hingegen ideal für Cloud-Dienste, da sich bei der Deaktivierung von zentralen Benutzer-Accounts auch Zugänge für Cloud-Dienste automatisch sperren lassen.

Zero-Trust-Network

In den letzten Jahren haben sich „Zero Trust“ und Zero-Trust-Network zu weit verbreiteten Begriffen entwickelt. Der Vorgänger des Zero-Trust-Network-Model – das Zero-Trust-Model – wurde 2010 von Forrester vorgestellt und zum Zero-Trust-Network-Model ausgebaut [1,2]. 2018 stellte Forrester mit „Zero Trust eXtended“ (ZTX) ein weiterentwickeltes Framework vor, anhand dessen IT-Verantwortliche ihre Sicherheitsarchitekturen gemäß Zero Trust aufbauen können. Basierend auf diesem Begriff entstand das sogenannte „Zero Trust eXtended Ecosystem Framework“ [3], das Schwerpunkte des Ecosystems definiert: Daten, Netzwerk, Menschen, Arbeitsabläufe, Geräte, Sichtbarkeit und Analyse sowie Automatisierung und Orchestrierung, wonach sich Produkte einordnen lassen. Forrester legt dabei Wert auf die Kompatibilität und Kommunikation zwischen den Softwareherstellern.

Gartner griff Teile des Zero-Trust-Network-Model auf und verfeinerte es. Um auch Client-Zugriffe auf Ressourcen ohne die Nutzung von VPN zu ermöglichen, veröffentlichte Gartner einen „Market Guide for Zero Trust Network Access“ (ZTNA) [4]. Zusätzlich wurde 2017 das Framework „Continuous Adaptive Risk and Trust Assessment“ (CARTA) entwickelt.

Sowohl bei CARTA als auch bei ZTN geht es um das Gewähren risikobasierter Zugriffe auf Ressourcen [5]. Benutzer, Geräte und Apps sind nicht nur bei jeder Anmeldung zu prüfen, sondern ihr Vertrauensstatus ist während einer Sitzung fortlaufend zu hinterfragen. Beim Feststellen von Veränderungen mit Risikopotenzial kann der bereits gewährte Zugang limitiert oder gänzlich verwehrt werden.

Das ZTN-Modell basiert nach Gilman im Kern auf folgenden fünf Annahmen [6]:

• Netzwerke sind stets feindlich.
• In Netzwerken existieren zu jedem Zeitpunkt Bedrohungen von intern und extern.
• Die Position eines Netzwerks ist kein ausreichendes Vertrauenskriterium.
• Benutzer, Geräte und Kommunikationsflüsse müssen authentifiziert und autorisiert werden.
• Richtlinien müssen möglichst viele Datenquellen berücksichtigen und dynamisch sein.

Demnach geht man davon aus, dass es keine vertrauenswürdigen Netzwerke gibt, also müssen bisherige (abgesicherte) interne Netzwerke nunmehr ebenfalls als unsicher betrachtet werden. Es handelt sich um einen konsequent datenzentrischen Ansatz, der auf Monitoring beruht – das bedingt neue Sicherheitskonzepte und Sicherheitsmaßnahmen direkt an den zu schützenden Systemen! Zusätzlich ist ein Grundvertrauen zu bekannten Geräten und Benutzern wichtig, und zwar unabhängig von ihrer Position (Lokation) im Netzwerk. Da aber bei jeder neuen Verbindungsanfrage Benutzern oder Geräten nicht automatisch vertraut werden soll, setzt jede Verbindung Authentifizierung und Autorisierung voraus.

Ein Zero-Trust-Network ist in die beiden Ebenen Data-Plane und Control-Plane unterteilt (vgl. Abb. 2):
Erstere bearbeitet Client-Anfragen und leitet sie an die Control-Plane weiter, die Daten aus einem Inventar von Benutzern und von Geräten sowie aggregierte Informationen nutzt, um Authentifizierungs- und Autorisierungsentscheidungen zu treffen. Die Prüfung dieser Informationen übernimmt dabei die Trust-Engine; Entscheidungen werden aus der Control-Plane an die Data-Plane zurückgegeben, wo anschließend die eigentliche Kommunikation zwischen Client und Service stattfindet.
Kernkomponenten der Data-Plane sind Enforcement-Module, Client und Server – bei der Control-Plane Policy-Engine, User- und Device Inventar sowie Trust-Engine.

Kernkomponenten

Trust-Engine

In einer Umgebung, in der jeder Teilnehmer potenziell Angreifer sein kann, ist das Vertrauensverhältnis wesentlich. Über Vertrauen wird anhand von Kriterien entschieden, mit denen sich eine böswillige Absicht erkennen lässt, sodass entsprechende Gegenmaßnahmen ergriffen werden können. Hierbei werden fünf Indikatoren für die Vertrauensbildung unterschieden: Geräte, Benutzer, Anwendungen, Netzwerkverkehr und Lokation [6]. Über diese benötigt die Trust-Engine Informationen.

Für Geräte sind das beispielsweise Informationen aus der Configuration-Management-Database (CMDB), in der alle clientspezifischen Informationen erfasst sind. Sie werden nach definierten Richtlinien ausgewertet, um daraus einen Trust-Score zu errechnen. Je nach eingestelltem Schwellenwert steuert das System dann Zugriffe auf angefragte Ressourcen: Wird ein Zugriff verwehrt, ist das Einleiten weiterer Freigabeprozesse, etwa einer Zwei-Faktor-Authentifizierung (2FA), vonnöten – der Trust-Score kann also durch zusätzliche Faktoren erhöht werden.

Der entscheidende Vorteil bei der Verwendung eines Trust-Scores liegt darin, dass man Entscheidungen entsprechend des Verhaltens und des Status von Benutzer und Gerät treffen kann. Beispielsweise kann ein Mitarbeiter in der Personalabteilung von seinem Arbeitsplatzrechner ohne weitere Prüfung auf das Personalverwaltungssystem zugreifen dürfen. Versucht er jedoch einen Zugriff von einem Arbeitsplatzrechner in der Finanzabteilung des Unternehmens, kann der Trust-Score durch den Ortswechsel zu niedrig sein. Somit sind Zugriffe zwar grundsätzlich möglich, jedoch nicht in jeder Situation. Dieses Beispiel impliziert, dass weder das Gerät noch der Benutzer allein für eine Entscheidung über den Trust-Score ausreichen.

Enforcement-Module

Als eigenständige Software-Komponente, die als zentrale Anlaufstelle für eingehende Client-Anfragen agiert und Server von direkten Anfragen abschirmt, leitet das Enforcement-Module Anfragen an die Policy-Engine weiter und verarbeitet die Antworten – nach erfolgreicher Authentifizierung wird die Kommunikation an den angefragten Server übergeben. Das Enforcement-Module agiert hier als Reverse-Proxy.
Bei jedem Verbindungsaufbau prüft es, ob der Client noch über den notwendigen Trust-Score verfügt, um weiterkommunizieren zu dürfen – falls nicht, wird die Kommunikation unterbrochen und der Client muss sich erneut authentifizieren.

Policy-Engine

Die Policy-Engine wiederum nimmt Anfragen des Enforcement-Module entgegen und prüft diese gegen aktive Richtlinien. Wird die Kommunikation durch eine Richtlinie erlaubt, sendet sie die Freigabe (optional mit Parametern) an das Enforcement-Module zurück und die Kommunikation wird freigegeben. Da keine einheitliche Richtliniensprache für die Policy-Engine existiert, bleibt es Herstellern überlassen, wie Richtlinien definiert werden.
Allgemeine Anforderungen an eine Richtlinie sind:

• Alle liefernden Systeme (Trust-Engine, User- und Device-Inventory) sollen zur Entscheidungsfindung beitragen – sowohl bei allgemeinen als auch bei spezifischen Richtlinien.
• Richtlinien sollen sowohl statische (z. B. Gruppenmitgliedschaften) als auch risikobasierte Regeln umfassen, um auf aktuelle Bedrohungen reagieren zu können.
• Die Erstellung von Richtlinien soll aufgeteilt werden, um die Systemadministration zu entlasten, die den allgemeinen Rahmen für die grundlegende Kommunikation vorgibt – Anwendungsverantwortliche sollten für ihre Anwendungen feinere Richtlinien definieren.
• Ein Versionierungssystem sollte Änderungen von Richtlinien protokollieren, sodass diese nachvollziehbar sind. Dabei sollte die Qualitätssicherung durch die Administration sowie weitere Personen durchgeführt werden, um zu vermeiden, dass die Richtlinie zu weit gefasst ist und dadurch Anwendungen für potenzielle Angriffe exponiert werden.

Vertrauens-Indikatoren

Netzwerkteilnehmer

Im ZTN-Modell dienen Informationen zu Netzwerkteilnehmern (Gerät und Benutzer) als Indikatoren zur Vertrauensbildung. Zu den verschiedenen Gruppen gibt es unterschiedliche Vorkehrungen: Das Vertrauen in ein Gerät bedingt dessen Kenntnis im System, was eine Inventarisierung erfordert. Diese erfolgt üblicherweise in einem Inventarmanagement oder einer Configuration-Management-Database (CMDB). In der CMDB können zum einen Identifikationsmerkmale wie Seriennummern und eingebaute Hardwarekomponenten des Geräts erfasst werden. Außerdem kann sie die aktuelle Gerätekonfiguration und die verwendete Software mit Versionierung umfassen. Aktuelle Inventarinformationen lassen sich mit dokumentierten abgleichen und erkannte Differenzen können den Trust-Score entsprechend justieren. Dies erfordert eine Inventarisierung, die stets aktuell gehalten werden muss!

Eine flankierende Maßnahme zur Vertrauensbildung ist das Ausstatten von Geräten mit einem eigenen Betriebssystemabbild und einem Zertifikat zur Identifikation und Authentifizierung. Zertifikate müssen von einer vertrauenswürdigen Stelle im Unternehmen ausgestellt und geheime Schlüssel (Private Keys) an einer geschützten Stelle auf den Geräten abgelegt werden, idealerweise in einem Trusted-Platform-Module (TPM).

Durch Protokolle (Logs) lässt sich eine Analyse von Geräten durchführen und auf Unregelmäßigkeiten prüfen. Die vergangene Zeit seit der letzten Neuinstallation, Zugriffszeit, Zugriffsort oder generelle Kommunikationsmuster sind elementare Informationen. So lassen sich Anomalien erkennen und unbekanntes Verhalten beim Zugriff auswerten, um vordefinierte Maßnahmen auszulösen (z. B. Verwehren des Zugriffs oder Fordern eines Vertrauensbeweises). Das Grundvertrauen in ein Gerät sinkt dabei fortlaufend mit Beginn der letzten Installation, da die Wahrscheinlichkeit der Verwundbarkeit zunimmt.

Nachdem ein Gerät auf seine Vertrauenswürdigkeit geprüft ist, ist auch die Überprüfung des Benutzers erforderlich. Dies beginnt bereits beim Auswahlprozess: Definierte Onboarding-Prozesse für Mitarbeiter müssen sicherstellen, dass eingestellte Mitarbeiter nicht unter falscher Identität agieren. Bei der Übergabe von Zugangsdaten sollte eine Identitätsprüfung erfolgen, was die sichere Zuordnung von Personen zu Zugangsdaten ermöglicht. Wie auch bei Geräten kann, unter Berücksichtigung der jeweils geltenden gesetzlichen Bestimmungen, eine Analyse des Benutzerverhaltens auf Basis von Logs durchgeführt werden – verdächtige Verhaltensmuster senken den Trust-Score.

Lokation

In klassischen Infrastrukturen wird einem Gerät innerhalb des eigenen Netzwerks vertraut – ZTN jedoch unterscheiden grundsätzlich nicht zwischen sicheren und unsicheren Netzwerken. Vor diesem Hintergrund ist die physische Position von Geräten oder Benutzern bedeutend und lässt sich als Indikator für den Trust-Score heranziehen.
Zusammen mit den Log-Auswertungen lassen sich Angriffe oder Anomalien feststellen. Zum Beispiel kann sich ein Benutzer nicht zeitgleich oder kurz nacheinander aus zwei unterschiedlichen Lokationen anmelden, die räumlich weit voneinander entfernt liegen. Die Lokation wird somit unabhängig vom internen Unternehmensnetzwerk mit einbezogen.

Netzwerkverkehr

Das ZTN-Modell sieht vor, dass jeder Kommunikationsfluss authentifiziert werden muss. Obwohl das Modell eine Verschlüsselung der Datenübertragung nicht zwingend vorsieht, ist der Einsatz gängiger Verschlüsselungsverfahren zweckmäßig, da diese im Allgemeinen auch hochwertige Authentifizierungsverfahren umfassen – gleichzeitig sorgt die Verschlüsselung für die Vertraulichkeit von Datenflüssen. In diesem Kontext sind Internet-Protocol-Security (IPSec) und Transport-Layer-Security (TLS) von großer Bedeutung.

Zusammenfassung

Im Vergleich zum Perimeter-Modell bedingt das ZTN-Modell eine grundlegende Änderung der Denkweise: Der Fokus liegt auf den Netzwerkteilnehmern und nicht mehr auf ihrer Umgebung. Die Infrastruktur mit den Elementen Trust-Engine, Enforcement-Module und Policy-Engine ermöglicht Zugriffe auf Dienste unabhängig von ihrer Position. Somit können klassische Infrastrukturen sowie hybride und vollständige Cloud-Umgebungen gleichermaßen bedient werden. Die Innovation dieses Modells besteht im Zusammenspiel dieser Indikatoren, um einen dynamischen Trust-Score zu errechnen und einen risikobasierten Zugriff zu ermöglichen.

Umsetzungsaspekte

Da Geräten, Diensten und Anwendern grundsätzlich misstraut wird, stellt das ZTN-Modell einen Paradigmenwechsel dar und hat entsprechende Auswirkungen auf die IT-Sicherheitsarchitektur – schließlich sind in der gesamten IT-Infrastruktur Sicherheitssysteme vorzusehen. Die Umsetzung ist mit einem erheblichen Aufwand verbunden, da alle Bereiche der IT vom Sicherheitskonzept betroffen sind. Sämtliche Dienste, Anwender und Geräte sind zu erfassen und Systeme zur Authentifizierung sowie Prüfung des internen und externen Datenverkehrs bereitzustellen, was eine Netzwerksegmentierung erfordert – zwischen den Segmenten kontrollieren Firewalls und Intrusion-Detection/Prevention-Systems (IDS/IPS) den Datenverkehr.

Je nach Infrastruktur und individuellen Bedürfnissen kann die Umsetzung unterschiedlich ausfallen. Als Orientierung kann der 5-Stufen-Plan von Palo Alto Networks dienen [7]: Wesentliche Punkte sind dabei die Identifikation kritischer Daten, Anwendungen sowie Assets beziehungsweise Diensten. Bei den Daten spielt die Art und Weise, wie man im Netzwerk auf sie zugreift, eine bedeutende Rolle: Transaktionen sollten kontrolliert werden. Für eine kontrollierte Kommunikation zwischen Ressourcen lassen sich Datenverkehr und Anwendungskommunikation durch Whitelists regeln – flankiert durch Monitoring.

Überwachung und Protokollierung des gesamten Datenverkehrs im Netzwerk sind eine zentrale Komponente von „Zero Trust“. Auch besteht die Möglichkeit, das Konzept als cloudbasierte Lösung zu implementieren. Solche Zero-Trust-Sicherheitsmodelle ermöglichen nur authentifizierten Anwendern die Nutzung definierter Applikationen – ein zentrales Managementsystem überwacht dazu den gesamten Traffic und steuert den Zugriff auf Ressourcen. Auch sollten Applikationen vom Internet isoliert werden, beispielsweise durch ein Identity-Aware-Proxy (IAP, siehe etwa https://cloud.google.com/iap/docs). Sinnvoll ist der zusätzliche Schutz von Applikationen durch eine Web-Application-Firewall (WAF).

Black Clouds

Viele Unternehmen planen die Umsetzung von „Zero Trust“ mithilfe sogenannter Software-Defined-Perimeter-Technology (SDP – auch bekannt als Zero-Trust-Network-Access, ZTNA), die auf dem „Black Cloud“-Konzept basiert, einer Entwicklung der IT-Sicherheitsbehörde des US-Verteidigungsministeriums (Defense Information Systems Agency – DISA) sowie der Cloud Security Alliance (CSA). Netzwerkzugänge und Verbindungen operieren darin nach dem Need-to-know-Prinzip: Die Infrastruktur ist „schwarz“, sie ist ohne DNS-Informationen oder IP-Adressen nicht sichtbar, sodass viele konventionelle Angriffe (z. B. DoS, SQL-Injection, MitM usw.) nicht greifen.

Für Zugriffe auf Anwendungen oder Ressourcen werden Benutzer für genau diese authentifiziert und gelangen auch nur direkt dorthin – Benutzern ist nicht bekannt, wo sie sich im Netzwerk befinden. Gemäß CSA werden dazu die logischen Einheiten „Geräte-Authentifizierung“, „identitätsbasierter Zugang“ und „dynamische Konnektivität“ kombiniert. Bekannte Ansätze, wie Next-Generation-Firewalls, NAC oder IEEE 802.1X und Extensible Authentication-Protocol (EAP), können zum Einsatz kommen, da sie verschiedene Funktionen für eine Authentifizierung anhand individueller Attribute ermöglichen.

Markteinblick

Es gibt zahlreiche Anbieter mit unterschiedlichem Portfolio an SDP-artigen Lösungen – Tabelle 1 liefert eine Übersicht ausgesuchter, repräsentativer Anbieter und ihrer Lösungen (siehe auch [10]). Dabei ist zu beobachten, dass Produkte und Dienste entweder als „as-a-Service“- (Cloud-Dienst) oder Stand-alone-Lösung angeboten werden. Die erste Variante bindet weniger Ressourcen für Einrichtung und Wartung, erfordert jedoch die Provisionierung vor Ort und das Routing des Datenverkehrs durch die Cloud des Anbieters – bei Stand-alone-Varianten obliegen Einrichtung und Wartung dem Kunden selbst. In den folgenden Abschnitten werden einige dieser Anbieter/Produkte etwas genauer betrachtet.

Zscaler

Zscaler (www.zscaler.de) bietet zwei kombinierbare Lösungen an: Zscaler Internet Access und Zscaler Private Access. Beide benötigen eine Software-Komponente auf Geräten, welche die Netzwerkkommunikation entgegennimmt und an einen Dienst in der Cloud weiterleitet. In der Cloud wird zwischen Anfragen ins Internet und ins interne Netzwerk unterschieden: Für die erste Art stellt Zscaler in der Cloud ein Forward-Proxy bereit, das ZScaler Internet Access. Zugriffe lassen sich auf Benutzerbasis steuern.

Für die Kommunikation ins interne Netzwerk dient Zscaler Private Access als VPN-Verbindung. Im internen Netzwerk operiert ein „Cloud Connector“, der an interne Anwendungen ankoppelt und Verbindungen in die Cloud aufbaut, sodass man keine eingehenden Anfragen aus dem Internet in das interne Netzwerk zulassen muss. Ein „Cloud Broker“ erlaubt dabei den Zugriff von Geräten auf interne Anwendungen (vgl. www.zscaler.com/resources/data-sheets/zscaler-private-access.pdf).

Seit der Übernahme von Edgewise Networks (www.edgewise.net) fokussieren Produkte wie Zero Trust Microsegmentation die Absicherung der Server-zu-Server-Kommunikation: Mit einer Software-Komponente dokumentiert diese Lösung jegliche Kommunikationsbeziehungen zwischen Servern. Auf Basis dieser Informationen erstellt eine Machine-Learning-Engine in der Cloud Vorschläge für mögliche Segmentierungen. Diese können in eine Segmentierungsrichtlinie umgewandelt und für die betroffenen Server angewendet werden – gleichartige Anwendungen werden dabei automatisch in dasselbe Segment geschoben und erhalten konsistente Richtlinien. Die Lösung berücksichtigt dynamische Umgebungen, zum Beispiel Autoscaling-Funktionen. Dadurch, dass Richtlinien anwendungsgebunden sind, lassen sich Anwendungen intern, hybrid oder in Cloud-Umgebungen betreiben [3,4].

Akamai, ScaleFT und Cyxtera

Akamai (www.akamai.com), ScaleFT (www.scaleft.com) und Cyxtera (www.cyxtera.com) bieten zu Zscaler vergleichbare Lösungen an. Je nach Hersteller fallen sie umfangreicher aus und fokussieren bestimmte Aspekte des ZTN-Modells. Die Grundfunktion ist jedoch gleich: gesicherter Zugriff auf interne und Cloud-Ressourcen ohne VPN.

Microsoft

In Office 365 und Azure Cloud bietet Microsoft eine umfangreiche ZTN-Lösung mit verschiedenen Komponenten an. In deren Kern steckt Conditional Access, eine Kombination aus Trust-Engine und Enforcement-Module [8]. Conditional Access ermöglicht den risikobasierten Zugriff auf interne und Cloud-Dienste, ebenfalls ohne die Notwendigkeit eines VPN. Durch die Integration weiterer Microsoft-Dienste lassen sich Informationen aus verschiedenen Systemen für Authentifizierungs- und Autorisierungsentscheidungen heranziehen – beispielsweise aktuelle Geräteinformationen über das Device-Management Intune oder Benutzerinformationen vom Azure AD. Windows Defender ATP (Advanced Threat Protection) ist als Client-Komponente auf jedem neuen Windows-System installiert und lässt sich durch entsprechende Lizenzen aktivieren – mit seiner Hilfe lassen sich weitere Geräte- und Verhaltensinformationen sammeln [8,9].

Google

Das Enforcement-Module Googles Identity Aware Proxy (IAP – https://cloud.google.com/iap?hl=de) operiert als Reverse-Proxy in der Cloud und kann mit dem Google Identity Management und dem Google Device Management verbunden werden. Das IAP kann Dienste aus der Google Cloud Platform und aus dem internen Netzwerk über das Internet bereitstellen.

Fazit

Das ZTN-Modell basiert auf dem Grundsatz, keinem Gerät, Benutzer oder Dienst innerhalb oder außerhalb des eigenen Netzwerks zu vertrauen – mit dem wesentlichen Ziel, das Risiko für Firmennetze und -anwendungen zu minimieren. Dazu erfordert es umfangreiche Maßnahmen zur Authentifizierung sämtlicher Anwender und Dienste sowie zur Prüfung des Netzwerkverkehrs. Als wichtige Alternative zum Perimeter-Modell klassischer Infrastrukturen konzentriert sich das Modell auf die Verlagerung von Sicherheitsmaßnahmen weg von der Infrastruktur und hin zu Endpunkten und Benutzern.

Der ZTN-Markt entwickelt sich schnell – Analysten sehen ZTN als zukunftsfähiges Modell an. Mittlerweile hat im ZTN-Segment bereits eine Marktkonsolidierung stattgefunden: Beispielsweise wurde ScaleFT von Okta übernommen, Duo Security hat den Namen in Duo Beyond geändert und wurde von Cisco einverleibt [4]. All das sind Indikatoren dafür, dass Hersteller von Sicherheitslösungen diesen Trend erkennen und ihre Produkte auf das ZTN-Modell ausrichten.

Speziell wird Zero-Trust-Network-Access (ZTNA) weitere Marktanteile gewinnen und letztlich das klassische VPN ablösen, da es eines der größten Probleme in Verbindung mit hybriden Infrastrukturen löst und direkten sicheren Zugriff sowohl auf Cloud-Applikationen als auch auf interne Anwendungen ermöglicht.

Durch die zukünftige Zunahme von Cloud-Diensten (bes. von SaaS) wird der Fokus in der IT verstärkt auf Dienste und Anwendungen umschwenken. Klassische Infrastrukturen werden an Bedeutung verlieren und womöglich nur noch als Trägermedium fungieren. Der Fokus von Sicherheitsmaßnahmen wird auf Anwendungen, Benutzern und Geräten liegen. Aus diesem Grund sind auch Marktforschungsinstitute davon überzeugt, dass das ZTN-Modell der richtige Weg ist, um diesen Herausforderungen zu begegnen.

Prof. Dr. Evren Eren lehrt an der City University of Applied Sciences Bremen und forscht zu Mobile sowie IT-Security, Virtualisierung und Clouds.

Der zweite Teil dieses Beitrags stellt in <kes> 2021#1 die konkreten ZTN-Implementierungen Google BeyondCorp und Netflix LISA näher vor.

Literatur

[1] John Kindervag, Build Security Into Your Network’s DNA: The Zero-Trust-Network Architecture, Forrester Research, November 2010, online verfügbar via www.virtualstarmedia.com/downloads/Forrester_zero_trust_DNA.pdf
[2] Martha Bennett, Zero Trust Security: A CIO’s Guide To Defending Their Business From Cyberattacks, Increase
Business Agility By Adopting Zero Trust, Forrester Research, Juni 2017, online verfügbar via www.akamai.com/us/en/multimedia/documents/report/zero-trust-security-cio-guideto-defending-their-business-fromcyberattacks.pdf
[3] Chase Cunningham, The Zero Trust eXtended (ZTX) Ecosystem, Extending Zero Trust Security Across Your Digital Business, Forrester Research, Januar 2018, online verfügbar via www.cisco.com/c/dam/m/en_sg/solutions/security/pdfs/forresterztx.pdf
[4] Steve Riley, Neil MacDonald, Lawrence Orans, Market Guide for Zero-Trust-Network Access, April 2020, www.gartner.com/en/documents/3912802/market-guide-forzero-trust-network-access (oder über Partner gegen Registrierung)
[5] Neil MacDonald, Zero Trust Is an Initial Step on the Roadmap to CARTA, Dezember 2018, www.gartner.com/en/documents/3895267/zero-trust-is-an-initial-step-on-theroadmap-to-carta
[6] Evan Gilman, Doug Barth, ZeroTrust-Networks: Building Secure Systems in Untrusted Networks, O’Reilly, Juni 2017, ISBN 978-1-4919-6219-0
[7] Palo Alto Networks, Simplify Zero Trust Implementation Using a Five Step Methodology, Whitepaper, Mai 2019, www.paloaltonetworks.com/resources/whitepapers/simplifyzero-trust-implementation-with-afive-step-methodology
[8] Sumesh Kumar, Ashwin Baliga, Himanshu Soni, Jairo Cadena, Building Zero-Trust-Networks with Microsoft 365, Blogbeitrag, Juni 2018, https://cloudblogs.microsoft.com/microsoftsecure/2018/06/14/building-zero-trust-networks-withmicrosoft-365/
[9] Alex Weinert, Zero Trust part 1: Identity and access management, Blogbeitrag, Dezember 2018, www.microsoft.com/security/blog/2018/12/17/zero-trust-part-1-identity-and-access-management/
[10] Qi An Xin Group, Zero Trust Architecture and Solutions, Gartner, April 2020, www.gartner.com/teamsiteanalytics/servePDF?g=/imagesrv/media-products/pdf/Qi-An-Xin/QiAn-Xin-1-1OKONUN2.pdf