Kein Zugriff ohne Sichtbarkeit : ZTNA und RBAC Hand in Hand – wie man Anwendungen im Unternehmen so verbergen kann, dass nur autorisierte Benutzer sie sehen

Das Streben nach „Zero Trust“ ist bereits seit mehr als zehn Jahren zu beobachten – da aber Benutzer inzwischen von jedem Ort aus arbeiten und Anwendungen weg vom Rechenzentrum nach außerhalb des Netzwerkperimeters verlagert wurden, mussten Netzwerk- und Sicherheitsgruppen ihren Schwerpunkt verschieben: Es geht nicht mehr um die Absicherung eines Netzwerks, sondern um den Schutz von Anwendern, Geräten und allen Vermögenswerten des Unternehmens.

Traditionell erfolgt der Zugriff eines Benutzers auf Anwendungen über den Netzwerkzugang und wird von den Netzwerk- und Sicherheitsabteilungen verwaltet – diese Teams entscheiden sowohl über Sicherheitsregeln als auch über die Durchlässigkeit der Firewall für Zugriffe von Anwendern. Das Konzept Zero-Trust-Network-Access (ZTNA) drängt diese Vorgehensweise in den Hintergrund und macht die Zugriffsberechtigungen nicht mehr am Netzwerk fest, sondern am Benutzer, seinem Eingabegerät, seiner Rolle im Unternehmen und seinen Gruppenzugehörigkeiten.

Diese Komplexität lässt sich nicht im Verzeichnisdienst festhalten. Es muss vielmehr eine Policy für jeden Benutzer beziehungsweise jede Benutzergruppe geschrieben werden, die ZTNA sowie dem Vorgehen einer Role-Based Access-Control (RBAC) entspricht. Das aber geht über den Aufgabenbereich der Netzwerker hinaus!

Der Wandel von einer Netzwerk-orientierten hin zu einer Zero-Trust-Architektur bewirkt eine Änderung der Zuständigkeiten: Denn plötzlich sind die Administratoren des Active Directories (AD) oder des „Identity-Providers“ (IDP) dafür verantwortlich, dass der Zugriff auf eine Anwendung ermöglicht oder abgewiesen wird. Typischerweise verbergen sich dahinter das Identity-Team, das sich mit der Authentifizierung auseinandersetzt, sowie die Endpoint-Verwaltung, welche die Berechtigung eines Endgeräts festlegt, und auch die Personalabteilung.

Offensichtlich hat ein Marketing-Mitarbeiter im Unternehmen eine andere Rolle inne und benötigt zum Teil andere Anwendungen als ein Vertriebsmitarbeiter oder Entwickler. Wenn ein Benutzer die Rolle „Marketing“ zugewiesen bekommt, dann sollte er auch Mitglied der Gruppen werden, die sich den Aufgaben dieses Bereichs widmen – also Marketing, Werbung, PR, Social Media, Produkt-Management, Messeplanung und so weiter. Innerhalb solcher Gruppen arbeiten Benutzer weitgehend mit den gleichen Anwendungen. Deswegen verfolgt die Entwicklung von ZTNA und RBAC den Gedanken, Gruppen als Quelle der Zugriffsberechtigung zu Anwendungen zu nutzen.

Wer schreibt die Policies?

Ein entsprechendes Berechtigungskonzept muss die zuständige interne Instanz ersinnen. Das ist in vielen Fällen die Personalabteilung (HR) – denn sie erstellt den Arbeitsvertrag, aus dem sich die Rolle eines Mitarbeiters meist bereits ergibt. Die Ausgestaltung der (technischen) Rolle, also die exakte Zuordnung zu Gruppen, wird HR dann in Zusammenarbeit mit fachlichen Experten festlegen müssen. Die exakten Anforderungen werden dabei nicht von der IT definiert, sondern innerhalb der zuständigen Abteilung unter Berücksichtigung von beispielsweise Least-Privilege-Prinzipien festgelegt. Dort legt man etwa fest, zu welchen Gruppen jemand mit der Rolle „Marketing“ gehört und auf welche gruppenbezogenen Anwendungen er/sie Zugriff erhält. Der letztliche Zugriff auf Systeme hängt damit nicht an der Rolle, sondern an den Gruppen.

Große Unternehmen haben zum Teil 40.000 Anwendungen oder mehr. Bis hier ein System von Rollen, Gruppen und gruppenbezogenen Anwendungen aufgebaut ist, wird Zeit vergehen! Die Herausforderung ist dabei der vollständige Blick über alle Anwendungen und ein Verständnis dafür, wer alles auf welche Anwendungen Zugriff haben muss. Es steht eine Umwälzung von einem offenen Netzwerk, auf das jeder Mitarbeiter zugreifen kann, hin zu einem granularen Zugriffskonzept auf Applikationsebene an.

Zwei Paar Schuhe

Demnach sind für unterschiedliche Funktionen im Unternehmen Rollen zu definieren: Die Zuordnung zu den Gruppen hängt an den Rollen und die Nutzung von gruppenbezogenen Anwendungen wird über RBAC gesteuert. ZTNA erfordert, dass ein Nutzer „seine“ Anwendungen tatsächlich sieht und auf sie zugreifen kann. Oder anders gesagt: Ein Benutzer wird erst dann mit der benötigten Anwendung verbunden, wenn er die passende Berechtigung für den Zugriff hat, was über die Authentifizierung sowie die Autorisierung geregelt wird. Authentifizierung und Autorisierung sind also zwei Paar Schuhe, müssen aber Hand in Hand gehen. Denn ZTNA erlaubt oder verbietet nicht den Zugriff auf Informationen innerhalb einer Anwendung oder eines Hosts – es ermöglicht vielmehr, dass ein Benutzer sich überhaupt erst am Host oder einer Anwendung anmelden kann (Login). Welche Informationen für den Anwender nach erfolgreicher Anmeldung dann zur Verfügung stehen, wird über das Berechtigungskonzept innerhalb der Anwendung bestimmt. Da ZTNA und RBAC aber auf die gleiche Informationsbasis im IDP zugreifen, lässt sich der Umfang des finalen Zugriffs zukünftig mehrheitlich über die Rolle(n) und Gruppenzugehörigkeit(en) der Anwender steuern.

Wichtige Schritte für ZTNA und RBAC

• • Entkoppeln des Anwendungszugriffs vom Netzwerkzugriff
  • Anwendungen mit Gruppenzugehörigkeiten verknüpfen
  • Verbergen von Anwendungen, sodass diese nur authentifizierte und autorisierte Benutzer sehen können
  • Definieren, welche Endgeräteeigenschaften für den Zugriff auf Anwendungen nötig sind
  • Umsetzen des „Least-Privilege“-Konzepts bei der Beschränkung des Zugriffs auf benötigte Anwendungen
  • Interne Ausrichtung der administrativen und personellen Strukturen auf die Anforderungen von ZeroTrust-Network-Access (ZTNA) und Role-Based AccessControl (RBAC)

„Next-Generation“-Netzwerksegmentierung

Bei einem auf „Zero Trust“ basierenden Modell wird die traditionelle Netzwerksegmentierung durch eine Mikro-Segmentierung auf Ebene der einzelnen Anwendungen ersetzt. Sowohl Anwender-zu-Anwendung- als auch Server-zu-Server-Kommunikation kann dabei segmentiert werden, um als zusätzlicher Schutzmechanismus laterale Bewegungen im Netzwerk zu unterbinden.

Bislang hat man beispielsweise eine Server-Segmentierung mittels unterschiedlicher Netzwerke erreicht: Host A im Netzwerk A durfte beispielsweise zu Host B im Netzwerk B mittels Layer-3-Verbindung über eine Netzwerkgrenze hinweg zugreifen, während die Kommunikation von Host A zu Host C im Netzwerk B mittels einer Layer-3-Policy verhindert wurde.

Bei Zugriffen von Anwendern auf Anwendungen (sowohl im klassischen Remote-Access-VPN wie auch bei internen Verbindungen) bekommt ein Anwender typischerweise vollen Zugriff auf die Netzwerke, in denen sich die Anwendungsserver befinden. Ein granulares Regelwerk, das einem Benutzer nur die für ihn benötigten Zugriffsrechte einräumt, lässt sich mit klassischen Werkzeugen auf Layer 3 häufig nicht vollständig umsetzen.

Grundsätzlich ist eine Segmentierung auf Netzwerkebene bei einer überschaubaren Anzahl von beteiligten Systemen noch administrierbar, skaliert aber nicht für große Umgebungen. Hier wird dann häufig aus der Not heraus viel mehr Kommunikation erlaubt, als eigentlich benötigt.

ZTNA minimiert Risiken

Angriffe erfolgen typischerweise gegen Systeme, die aus dem öffentlichen Netzwerk heraus erreichbar sind. Hat ein Angreifer ein lohnenswertes Ziel identifiziert und kann er eine Verbindung dorthin aufbauen, wird er möglicherweise versuchen, sich mit widerrechtlich erlangten Zugangsdaten oder mittels Brute-Force-Angriff an einem solchen System anzumelden.

Eine ZTNA-Lösung verhindert jedoch, dass ein Angreifer sein Ziel überhaupt erreichen kann, da dieses nur für authentifizierte und autorisierte Anwender sichtbar ist. Zusätzlich wird ZTNA nicht nur zwischen erlaubten und unerlaubten Anwendern unterscheiden, sondern auch das eingesetzte Endgerät in die Entscheidung einbeziehen. Dabei können einfache Kriterien, wie das Vorhandensein einer aktiven Anti-Virus-Lösung, herangezogen werden. Bei Remote-Zugriffen von Anwendern über das Internet kommen außerdem meist komplexere Abhängigkeiten zum Tragen. Beispielsweise könnte ein Endgerät für den benötigten Zugriff auf eine HR-Anwendung mindestens ein firmenverwaltetes System sein müssen, das mit einem Zertifikat des Unternehmens versehen ist, ein AV-Scanner aktiv in Benutzung hat – und gegebenenfalls noch weitere Abhängigkeiten erfüllt. Bei weniger kritischen Anwendungen kann es hingegen auch zulässig sein, dass Anwender sogar mit privaten Laptops auf eine Firmenanwendung zugreifen dürfen (Bring your own Device – BYOD).

So oder so: Erst wenn alle geforderten Bedingungen geklärt sind und der Anwender sowohl erfolgreich authentifiziert ist (gegebenenfalls mittels Multi-Faktor-Authentifizierung – MFA) als auch die benötigte Berechtigung anhand der Rolle oder Gruppe im Verzeichnisdienst bekommen hat (Autorisierung), wird die gewünschte Anwendung für ihn erreichbar sein. Schlägt auch nur ein Kriterium fehl, bekommt der Anwender noch nicht einmal eine Verbindung zur Anwendung erstellt.

In jedem Fall wird für den Zugriff auf eine Anwendung genau ein Tunnel geöffnet, der sich nicht für weitere Anwendungen nutzen lässt: Will man vom gleichen Endgerät aus auf eine zweite Anwendung zugreifen, so wird die entsprechende Überprüfung des Anwenders und Endgeräts vorgenommen und dann gegebenenfalls ein zweiter Tunnel für die zweite Anwendung geöffnet. Vom Endgerät geht also jeweils ein Tunnel pro Anwendung in Richtung Firmennetzwerk, wodurch die Mikro-Segmentierung auf Anwendungsebene entsteht.

Große Veränderungen

Organisatorisch und administrativ bewirkt dieses neue Konzept gravierende Veränderungen der Strukturen innerhalb eines Unternehmens. Beispielsweise wird ein Administrator, der für die Firewall beziehungsweise die Schnittstelle zwischen Netzwerk und Sicherheit verantwortlich ist, Teile seiner derzeitigen Verantwortung an andere Fachbereiche übertragen müssen. Da sich das Berechtigungskonzept von der Netzwerkebene entfernt, werden übliche Tätigkeiten, wie das Administrieren von Routern und Switches, zwar nicht entfallen, die Anforderungen und Verantwortung in diesem Bereich jedoch sinken. Die Berechtigung, auf eine Anwendung zuzugreifen, ist nicht mehr von der Zugehörigkeit zu einem Netzwerk abhängig, daher endet auch die Verantwortung des Netzwerkadministrators künftig früher. Das schafft auf der anderen Seite Freiräume für Tätigkeiten, die im täglichen Geschäft häufig zu kurz kommen.

Die Aufgabe geht nun mehr und mehr auf die Menschen über, die für die ZTNA-Lösung verantwortlich sind: Sie beziehen die Informationen, welche Benutzergruppen auf welche Anwendungen zugreifen müssen, von den Identity-und-Access-Management-(IAM)-Administratoren, die wiederum eng mit der Personalabteilung zusammenarbeiten. Die benötigte Zugriffsmatrix ist gemeinsam mit der Fachabteilung, in welcher der Anwender tätig ist, zu erarbeiten.

Ein Zero-Trust-Konzept ist kein binärer Prozess, der sich von heute auf morgen etablieren lässt (siehe auch [1,2]. Dazu fehlt es am Anfang noch an der Transparenz aller Anwendungen im Unternehmensnetzwerk sowie der Datenströme – und meist fehlen auch die benötigten Zugriffsrechte der Mitarbeiter. Mithilfe einer ZTNA-Lösung werden die Vorgänge jedoch einfacher und nach der Umsetzung profitiert das gesamte Unternehmen von der erhöhten Sicherheit sowie klareren Struktur innerhalb des Netzwerks.

Wolfgang Hustädt ist Solution Architect bei der Zscaler GmbH.

Literatur

[1] Evren Eren, Der Weg zum Zero-Trust-Networking (1), 2020#6, S. 52
[2] Evren Eren, Der Weg zum Zero-Trust-Networking (2), 2021#1, S. 50
[3] Jan Pieter Giele, RBAC – ein Monster?, 2014#1, S. 18