Der Weg zum Zero-Trust-Networking (2)

Von Evren Eren, Bremen

Der erste Teil dieses Beitrags [1] hat Sicherheitsmaßnahmen in klassischen Infrastrukturen und ihre Limitierungen in Cloud-Computing-Umgebungen mit dem Zero-Trust-Network-(ZTN)-Modell verglichen – der vorliegende zweite Teil stellt die konkreten ZTN-Implementierungen Google BeyondCorp und Netflix LISA näher vor.

Google BeyondCorp

Nach dem Angriff „Operation Aurora“ im Jahr 2009 hatte Google erkannt, dass das Perimeter-Modell nicht zukunftsfähig ist und startete 2014 die BeyondCorp-Initiative, die das privilegierte Unternehmensnetzwerk auflösen und sich komplett in Richtung Zero-Trust-Network bewegen sollte [2]. Um dieses Vorhaben umsetzen zu können, wurden die Haupthandlungsfelder Sicherheit, Identität, Netzwerk, Zugriffssteuerung, Endgerät und Server-Software, unternehmenskritische Anwendungsdienste, Drittanbieter sowie outgesourcte Funktionen definiert [3] – damit erfolgte eine komplette Migration in Richtung Zero-Trust-Network. Google setzte dieses kontextbasierte Zugangskonzept zunächst nur intern ein, implementierte es jedoch 2019 auch in seine Dienste.

Vergleicht man den Ansatz von Google (Abb. 1) mit dem ZTN-Modell (Abb. 2 in [1]), so ist zu erkennen, dass die Struktur im Wesentlichen gleich ist. Beide haben die drei Hauptkomponenten Enforcement-Module (hier: Access-Proxy), Policy-Engine (hier: Access-Control-Engine) und Trust-Engine (hier: Pipeline) als zentralen Dreh- und Angelpunkt implementiert, legen Wert auf Geräte und Benutzerdaten sowie eine Single-Sign-on-Implementierung.

Trust-Engine

Die Trust-Engine von Google berechnet für jede Kommunikation einen Trust-Score, der sich aus den erhaltenen Informationen zu Gerät, Benutzer, Netzwerkverkehr und Lokation zusammensetzt. In Verbindung mit dem Trust-Score wurde ein stufenbasiertes Zugriffsmodell (Tiered Access-Model) eingeführt [4], das auf dem Least-Privilege-Grundsatz basiert: Geräte und Benutzer erhalten ausschließlich Minimalrechte. Alle Anwendungen, die auf Google BeyondCorp umgestellt wurden, sind in eine der Stufen eingruppiert, um damit den Schutzbedarf der Anwendung zu bestimmen – der Zugriff auf die einzelnen Stufen ist an Bedingungen geknüpft.

Ein Beispiel für die Limitierung auf Benutzer ist die Website http://codereview.corp.google.com, auf die Vollzeitmitarbeiter von einem Firmengerät aus zugreifen können – nicht jedoch Teilzeitkräfte, auch nicht von Firmengeräten. Zudem müssen beispielsweise Betriebssystemupdates für den Zugriff auf höhere Stufen zeitnah eingespielt worden sein, während Updates bei niedrigeren Stufen auch später erfolgen dürfen. Die Entscheidung über den Zugriff wird anhand eines Network-Agent, also über die Kombination von Gerät und Benutzer, getroffen [4].

Enforcement-Module

Als Enforcement-Module operiert der Access-Proxy, der unter dem Namen „Google Front Ends“ implementiert ist und dort die Authentifizierung und Autorisierung, ein Self-Service-Provisioning sowie das Logging umfasst. Der Access-Proxy hat eine Verbindung zum Google Identity-Provider (IdP) und unterstützt weitere Authentifizierungsmethoden wie OpenID Connect, OAuth und einige Google-proprietäre Protokolle [5].

Policy-Engine

Die Policy-Engine bezeichnet Google als Access-Control-Engine und Richtlinien als Access-Control-Lists (ACLs). ACLs werden durch die Access-Control-Engine verarbeitet und im Enforcement-Module angewendet. Richtlinien sind unterteilt in globale und weit gefasste ACLs, die allgemeinere Richtlinien abbilden, und in anwendungsspezifische ACLs, die feingranular auf bestimmte Anwendungen und Benutzer angewendet werden [5].

Beide ACL-Arten werden von verschiedenen Personengruppen verantwortet: Jeder Anwendungsverantwortliche hat für seine Anwendung entsprechende ACLs zu erstellen und diese, im Zusammenspiel mit der Sicherheitsabteilung und den Verantwortlichen, für die Access-Control-Engine zu implementieren – das soll verhindern, dass Anwendungsverantwortliche ACLs zu offen gestalten. Um beispielsweise Zugriff auf eine Anwendung mit hoher Vertrauensstufe zu erhalten, müssen auf dem Client die Verschlüsselung aktiviert und aktuellste Sicherheitsupdates des Betriebssystems installiert sein.

Richtlinien werden bereits im Vorfeld berechnet und dem Access-Gateway zur Verfügung gestellt, damit es schnellere Autorisierungsentscheidungen treffen kann, ohne Anfragen an die Access-Control-Engine weiterleiten zu müssen [4]. Da es für Richtlinien noch keine einheitliche Beschreibungssprache gibt, hat Google seine eigene Beschreibungssprache entwickelt, um die genannten Anforderungen erfüllen zu können. Zusätzlich wurde ein lokaler Simulator entwickelt, der Auswirkungen von ACLs simuliert, ohne die Kommunikation einzuschränken. Damit kann jeder Verantwortliche prüfen, ob erstellte ACLs die gewünschte Wirkung erzielen [2,5].

Netzwerkteilnehmer

Google lässt in seinem Design den Zugriff auf Ressourcen nur durch Unternehmensgeräte zu, die in mehreren Device-Inventory-Management-Systemen erfasst sind. Zur effizienten Verwendung dieser Systeme wurde eine Meta-Inventory-Datenbank erstellt, die aus den verschiedenen Systemen gespeist wird. Informationen über Geräte werden über einen Device-Agent oder ein Configuration-Management-System erhoben. Diese Daten werden durch zusätzliche Informationen aus anderen Systemen angereichert [2,4] – etwa Schwachstellenscanner, ARP-Tabellen, Logs von Netzwerkkomponenten und Zertifizierungsstellen (CAs).

Die Authentifizierung wird über ein Gerätezertifikat realisiert, das bei der Inbetriebnahme des Geräts ausgestellt wird. Ein Gerät erhält nur dann ein Zertifikat, wenn es dem Device-Inventory-Management-System bekannt und dort verbucht ist – so können nur bekannte Geräte über ein Zertifikat verfügen. Das Zertifikat wird auf dem Gerät in einem qualifizierten Zertifikatsspeicher abgelegt, bei Windows-Computern beispielsweise im Trusted-Platform-Module (TPM).

Für Authentifizierung und Autorisierung verwendet Google ein zentrales Benutzer- und Berechtigungsverwaltungssystem, das mit dem Personalverwaltungssystem des Unternehmens verbunden ist. Über diese Verbindung erhält es detaillierte Informationen darüber, welcher Benutzer in welcher Stellenkategorie und auf welcher Stelle arbeitet. Darauf basierend erhält dieser Berechtigungen, wobei Sonderberechtigungen direkt über das System zusätzlich vergeben werden können [3]. Somit nutzt Google grundsätzlich eine zentrale Benutzerverwaltung mit zentraler Berechtigungsverwaltung – ermöglicht jedoch bei der Berechtigungsverwaltung auch lokale Ansätze.

Die Autorisierung am Access-Proxy basiert auf einer groben Freigabe der Berechtigung – in der Anwendung selbst werden anschließend dezidierte Berechtigungen auf einzelne Funktionen in der Anwendung vergeben. Arbeitet beispielsweise ein Benutzer in der deutschen Personalabteilung, beschränkt das Access-Proxy den Zugriff im Personalverwaltungssystem auf deutsche Mitarbeiter. Auf Basis verfügbarer Informationen kommt also eine Kombination aus lokaler und zentraler Benutzer- und Berechtigungsverwaltung zum Tragen. Über die Art der initialen Identifikation neuer Mitarbeiter sind keine weiterführenden Informationen vorhanden – laut [6] ist jedoch ein schnelles Onboarding von Mitarbeitern möglich.

Was die Lokation anbetrifft, löst sich Google bewusst von Vertrauensentscheidungen anhand der physischen Position. Zugriffe auf alle umgestellten Dienste sind von überall möglich, somit kann jeder Teilnehmer im Internet grundsätzlich mit dem Access-Proxy kommunizieren. Die Lokation wird nur noch als ein weiteres Kriterium betrachtet, das die Trust-Engine verarbeitet, um Autorisierungsentscheidungen zu treffen [2].

Beim Netzwerkverkehr war Googles initiales Ziel, alle Arbeitsprozesse ausschließlich auf webbasierte Kommunikation umzustellen [5] – durch den bereits vorhandenen starken Fokus der Google-Dienste auf HTTP/HTTPS wurde das Ziel in den meisten Fällen erreicht. Das Access-Proxy nimmt als Single-Point-of-Contact die webbasierten Anfragen entgegen und leitet sie an die Zielsysteme weiter. Die Kommunikation zwischen Client und Access-Proxy sowie zwischen Access-Proxy und Anwendung ist in den meisten Fällen über Mutual TLS abgesichert. Google entwickelte zusätzlich das eigene Protokoll „Low Overhead Authentication System (LOAS)“, das den Authentifizierungsprozess beschleunigen sollte [5].

Bei einigen Arbeitsprozessen stieß Google allerdings auf Hindernisse, die eine ausschließliche Nutzung webbasierter Protokolle verhinderte – dazu gehören Protokolle, die eine Ende-zu-Ende-Verschlüsselung voraussetzen (z. B. SSH), proprietäre Systeme, die keine Client-Authentifizierung unterstützen, sowie nicht-webfähige Protokolle (z. B. UDP oder RDP). Für diese Fälle wurden Softwarekomponenten entwickelt, um die fehlenden Funktionen zu kompensieren. Hierzu war eine teilweise Verlagerung der Authentifizierung und Autorisierung auf den Client notwendig, da eine Deep-Inspection von Netzwerkpaketen durch das Access-Proxy nicht möglich ist [3,5].

Migrationsprozess

Eine der ersten Herausforderungen für Google lag darin, alle im Unternehmen vorhandenen Workflows und Kommunikationsbeziehungen zu identifizieren und diese Abteilungen und Zielgruppen zuzuordnen – mit dem Ziel einer schrittweisen und zielgruppenorientierten Migration [2]. Gleichzeitig war es wichtig, alle Mitarbeiter über die anstehenden Änderungen regelmäßig und zielgruppengerecht zu informieren. Hierzu startete Google eine weitreichende Informationskampagne, die über Projektfortschritte und anstehende Änderungen informierte. Zusätzlich bekamen Supportmitarbeiter Schulungen für die neue Lösung [3,4].

Google entschied sich für den Aufbau eines neuen Netzwerks und gegen den Umbau der vorhandenen Infrastruktur, da so ein Fallback einfacher möglich war und man keine Änderungen an funktionierenden Infrastrukturen machen musste. Anwendungen wurden auf das neue Konzept umgebaut und Benutzer in das unprivilegierte Netzwerk verlagert. Nach einiger Zeit wurden Benutzern die Rechte auf die Fallback-Ebene entzogen und der noch genutzte Virtual-Private-Network-(VPN)-Client entfernt. Den Unterbau für dieses Vorgehen legte Google mit einer flächendeckenden Einführung einer Network-Access-Control-(NAC)-Lösung, wodurch Geräte zwischen dem alten privilegierten und dem neuen unprivilegierten Netzwerk verschoben werden konnten. Bei Sonderfällen wurde teilweise neue Software entwickelt oder – wie bei „Captive Portals“ und bei lokalen Netzwerkgeräten – im geschützten Netzwerk eine Lösung für die Benutzer zur Verfügung gestellt, sodass sie ihre Probleme im Self-Service lösen konnten [3].

Zusammenfassend lässt sich feststellen, dass sich Google bei den Hauptkomponenten von BeyondCorp stark am ZTN-Modell orientiert hat: Trust-Engine, Enforcement-Module und Policy-Engine sind modellgetreu umgesetzt. Im Enforcement-Module wurden noch weitere Funktionen eingeführt, beispielsweise ein Self-Service-Provisioning. Für die Policy-Engine wurden eine eigene Richtliniensprache und eine Anwendung zum Testen der Richtlinien entwickelt. Auch bei den Netzwerkteilnehmern orientiert sich das Unternehmen am ZTN-Modell: Für die Authentifizierung kommen Zertifikate zum Einsatz und Autorisierungsentscheidungen erfolgen anhand eines Network-Agent – Netzwerkverkehr wird per Mutual TLS abgesichert. Damit hat Google das ZTN-Modell als Gesamtkonzept umgesetzt und an einigen Stellen darüber hinaus erweitert. Durch die Umstellung auf das ZTN-Modell ist es Google gelungen, alle Dienste in die Cloud zu migrieren.

Netflix LISA

Die ZTN-Implementierung von Netflix heißt LISA (Location Independent Security Approach – vgl. Abb. 2), wurde 2018 veröffentlicht und folgt folgenden Prinzipien:

• Das Büro-Netzwerk ist nicht vertrauenswürdig.
• Isoliere alle Geräte.
• Vertraue nur authentifizierten Benutzern und integren Geräten.

Bei der Umstellung auf das ZTN-Modell wollte Netflix spezielle Use-Cases abbilden: Zunächst sollten Mitarbeiter, unabhängig von ihrer Lokation, auf dieselbe Art und Weise arbeiten können. Der Zugriff auf Unternehmensressourcen sollte im Sinne einer hohen Mobilität stets über denselben Weg erfolgen. Darüber hinaus sollten Tests in der Cloud erfolgen und der Zugriff auf die Entwicklungsumgebung von verschiedenen Gerätetypen aus möglich sein [7].

Enforcement-Module

Als Enforcement-Module wirkt ein VPN-Zugriffspunkt in der Cloud – als zentraler und sicherer Kommunikationspunkt für alle Geräte. An diesen ist ein Identitätsprovider angebunden, der die Authentifizierung durchführt und – je nach Risikofaktor – einen zweiten Faktor verlangen kann [7,8].

Policy-Engine

Die Policy-Engine erhält den Risikofaktor der Authentifizierung von der Trust-Engine mitgeteilt. Anhand des konfigurierten Risikolevels der Anwendung kann die Policy-Engine die Authentifizierung bestätigen oder über das Enforcement-Module einen weiteren Faktor verlangen [8].

Netzwerkteilnehmer

Benutzer dürfen ihre Geräte selbst verwalten. Hierfür entwickelte Netflix die Software Stethoscope, die ein umfangreiches Inventarmanagement von Geräten und eine Zuordnung zu Benutzern ermöglicht. Die entsprechenden Informationen werden mit der Unternehmensrichtlinie verglichen und Benutzern ausführliche Informationen zu Integrität (Health) von Geräten geliefert, anhand derer Geräte sicherer konfiguriert werden können, um den Risikofaktor zu senken [7].

Die sogenannte User-Focused Security unterteilt die Benutzerverwaltung in zwei Benutzer- und Berechtigungsverwaltungssysteme: Mitarbeiter und Dienstleister wurden dazu zentral über das Google Identity-Management in die Cloud migriert – alle anderen Benutzer werden in einem zweiten Benutzer- und Berechtigungsverwaltungssystem im internen Netzwerk administriert. Das Personalverwaltungssystem besitzt eine Schnittstelle zum zentralen Verwaltungssystem der Cloud, sodass bekannt ist, in welcher Abteilung und Lokation ein Benutzer aktiv ist. Beim Zugriff auf Anwendungen wird über die Lokation geprüft, wie hoch die Wahrscheinlichkeit ist, dass der Benutzer diese Anwendung für seine Aufgaben benötigt. Zusätzlich wertet man die Anmeldehistorie anhand von Logs aus, um unberechtigte Zugriffe zu identifizieren. Die Aggregation der Logs und die Analyse des Benutzerverhaltens erfolgt über die Software Trainman [7,8].

Das interne Netzwerk besitzt keine besondere Vertrauensstellung – alle Zugriffe terminieren zunächst am VPN-Gateway in der Cloud und werden anschließend weiterverteilt.

Auch bei der Anmeldung am VPN-Gateway wird die Lokation als weiteres Kriterium für die Bestimmung des Risikofaktors herangezogen: Kommt eine Anfrage von einer bekannten Lokation, verringert das den Risikofaktor – eine risikobehaftete Lokation blockiert den Zugriff. Netflix unterbindet überdies die direkte Kommunikation zwischen Geräten im Unternehmensnetzwerk – auf Unternehmensressourcen kann man nur per VPN-Einwahl zugreifen. Systeme, bei denen VPN-Verbindungen nicht möglich sind, werden über definierte Ausnahmen verwaltet und dazu entweder über ein gesondertes Netzwerk eingebunden oder über ein vorgeschaltetes, VPN-fähiges Zwischengerät [7].

Migrationsprozess

Ein wichtiger Erfolgsfaktor bei der Migration war auch hier die Kommunikation im Unternehmen. Netflix organisierte regelmäßig Informationsveranstaltungen für alle betroffenen Mitarbeiter. Use-Cases und das Auffinden von Systemabhängigkeiten waren eine Herausforderung, die mithilfe von Mitarbeiterbefragungen und Analysen bewältigt wurde. Vor der Umstellung auf das Produktivnetz baute Netflix ein Testnetzwerk auf, um alle Use-Cases und Funktionen zu überprüfen [7].

Die definierten Prinzipien, nach denen LISA aufgebaut ist, orientieren sich am ZTN-Modell, wurden jedoch an unternehmensspezifische Bedürfnisse angepasst: Mit den Hauptkomponenten hält sich Netflix an die Vorschläge des ZTN-Modells, genauso sieht es bei den Netzwerkteilnehmern, der Lokation und dem Netzwerkverkehr aus. Mit Stethoscope legt Netflix jedoch Wert auf ein Gerätemanagement durch den Benutzer, was im ZTN-Modell nicht explizit enthalten ist.

Vergleich von Google und Netflix

Wird das ZTN-Modell mit der von Google durchgeführten Umsetzung verglichen, ist klar zu erkennen, dass sich das Unternehmen daran orientiert. Netflix setzt es eher punktuell um, um definierte Use-Cases zu lösen. Im direkten Vergleich zwischen den beiden Implementierungen legt Google strengere Kontrollen des Endpunkts an: Zur Absicherung von Verbindungen wird ein Proxy verwendet – Netflix nutzt hingegen ein VPN. Anders als Google hatte Netflix die Vorgabe, möglichst alle Aufgaben mit vorhandener beziehungsweise mit Standardsoftware zu erreichen und somit den Entwicklungsaufwand in Grenzen zu halten.

Anhand beider Implementierungen ist zu erkennen, dass das ZTN-Modell funktioniert und dass man Herausforderungen des Perimeter-Ansatzes in hybriden und vollständigen Cloud-Umgebungen damit begegnen kann.

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

Literatur

[1] Evren Eren, Der Weg zum Zero-Trust-Networking (1), <kes> 2020#6, S. 52
[2] Rory Ward, Betsy Beyer, BeyondCorp, A New Approach to Enterprise Security, ;login: 39/6, Dezember 2014, www.usenix.org/publications/login/dec14/ward
[3] Jeff Peck, Betsy Beyer, Colin Beske, Max Saltonstal, Migrating to BeyondCorp, Maintaining Productivity While Improving Security, ;login: 42/2, 2017, www.usenix.org/publications/login/summer2017/peck
[4] Barckay Osborn, Justin McWilliams, Betsy Beyer, Max Saltonstall, BeyondCorp, Design to Deployment at Google, ;login: 41/1, 2016, www.usenix.org/publications/login/spring2016/osborn
[5] Luca Cittadini, Batz Spear, Betsy Beyer, Max Saltonstall, Beyond Corp Part III: The Access Proxy, ;login: 41/4, 2016, www.usenix.org/publications/login/winter2016/cittadini
[6] Victor Escobedo, Betsy Beyer, Max Saltonstall, Filip Zyzniewski, BeyondCorp 5: The User Experience, ;login: 42/3, 2017, www.usenix.org/publications/login/fall2017/escobedo
[7] BryanZimmer, LISA: A Practical Zero Trust Architecture, Vortragsvideo von der Usenix Enigma, Januar 2018, www.usenix.org/conference/enigma2018/presentation/zimmer
[8] Tejas Dharamshi, Building Identity for an Open Perimeter, Vortragsvideo von der Usenix Enigma, Januar 2019, www.usenix.org/conference/enigma2019/presentation/dharamshi