Heute geht es um das Thema Zero Trust Security Model (auch Zero Trust Architecture, ZTA) oder kurz: Zero Trust, auf Deutsch “Vertraue niemandem”. Zero Trust verfolgt dabei auch strikt den Ansatz: “Vertraue niemandem, verifiziere jeden”. Zero Trust ist kein Framework oder Software, welche man installieren kann, sondern es gibt verschiedene Konzepte und Prinzipien, die bei der Umsetzung einer Zero-Trust-Architektur von Bedeutung sind. Viele dieser Konzepte sind auch nicht wirklich neu. Den Begriff Zero Trust gibt es schon seit 1994. Stephen Paul Marsh hat diesen in seiner Doktorarbeiteit über Computersicherheit zum ersten Mal genutzt. 2014 hat ein Schweizer Security Engineer, Gianclaudio Moresi, zum ersten Mal ein System gebaut, welches die Prinzipien von Zero Trust umsetzte. 2019 wurde vom National Cyber Security Centre empfohlen, dass neue cloud-nahe Services mit einer Zero-Trust-Architektur deployed werden sollen. Seit 2020 stellen grosse IT-Plattform-, sowie Cyber Security-Anbieter verständliche Beispiele für eine Zero-Trust-Architektur zur Verfügung.

Zero Trust Grundlagen

Zero Trust ist ein Cybersecurity Paradigma, welches sich zur Aufgabe macht, Ressourcen zu schützen und dabei niemals ein Vertrauensverhältnis als gegeben sieht. Unternehmen verlassen sich gerne darauf, dass eine Firewall sie gegen alle Angriffe aus dem Netz schützt. Dies trifft auch in den meisten Fällen zu aber kommt es dann doch mal zu einem Durchbruch der Firewall, so steht dem Angreifer danach oft das ganze System offen, da es innerhalb des Firmennetzwerks meist kaum weitere Sicherheitsmassnahmen gibt. Auch interne Mitarbeiter, welche nicht über die Firewall auf das firmeneigene Netzwerk zugreifen, können sich innerhalb des Netzwerks “frei bewegen”. Zero Trust setzt genau hier an und schützt jede einzelne Ressource vor unerlaubten Zugriffen. Das bedeutet, dass jeder Benutzer sich bei jeder Anfrage an eine Ressource zuerst authentifizieren und authorisieren muss. Der Terminus “Benutzer” ist dabei auch nicht ganz richtig. Dies suggeriert, dass es sich dabei ausschliesslich um Personen handelt. Vielmehr geht es jedoch um jede Entität, also beispielsweise auch ein anderer Computer oder allenfalls ein technischer Benutzer. Daher müssten wir hier eher von einem Subjekt reden.

Im folgenden Diagramm sehen wir exemplarisch, wie ein Subjekt auf eine Ressource zugreift. Die Erlaubnis wird durch einen Policy Decision Point (PDP) und dem damit verbundenen Policy Enforcement Point (PEP) gegeben. Das System muss also gewährleisten, dass das Subjekt authentifiziert und die Anfrage auch rechtens ist. Dies impliziert, dass Zero Trust für zwei grundlegende Bereiche gilt: Authentifizierung und Authorisierung.

Wir sehen im Diagramm die “Implicit Trust Zone”. Diese repräsentiert einen Bereich, in dem allen Entitäten vertraut wird und zwar bis zum Level des letzten PDP/PEP.

Versuchen wir uns das etwas anschaulicher vorzustellen: Auf einem Flughafen muss jeder Passagier durch einen Sicherheitscheck, bevor er zum Boarding darf. Dieser Sicherheitscheck wäre in unserem Diagramm der PDP/PEP. Alle Menschen, die diesen Punkt noch nicht durchlaufen haben, befinden sich also in der “Untrusted Zone”. Alle, die diesen Punkt passiert haben, befinden sich also folgerichtig in der “Implicit Trust Zone”.

Der PDP/PEP stellt also bestimmte Kontrollen zur Verfügung, sodass die Anfrage nach dem PEP ein grundlegendes Level an Sicherheit hat. Ein PDP/PEP kann dabei auch keine weiteren Rechte an einen Request ausstellen. Dafür bedarf es dann eines weitere PDP/PEP, welcher dann andere Kontrollen zur Verfügung stellt. Um dies wieder auf unser Flughafenbeispiel anzuwenden, können wir uns vorstellen, dass man durch das Passieren des ersten PDP/PEP (Sicherheitscheck) noch nicht zwingend an Bord des Flugzeugs darf. Vorher wird erst noch einmal der Boarding Pass mit dem Ausweis abgeglichen (Boarding Kontrolle).

Zero Trust Grundsätze

Eine Zero-Trust-Architektur wird unter Einhaltung der folgenden Zero-Trust-Grundsätze entworfen und bereitgestellt:

• Alle Services und Datenquellen werden als Ressourcen betrachtet.

• Sämtlicher Zugriff auf Ressourcen ist gesichert, und zwar unabhängig von Netzwerk Standorten.

  • Das bedeutet, dass ein internes Netzwerk kein Vertrauensverhältnis impliziert. Anfragen aus dem internen Netzwerk müssen daher die gleichen Sicherheitsvoraussetzungen erfüllen, wie eine Anfrage aus dem externen Netzwerk.

• Zugang zu individuellen Ressourcen ist auf Session-Basis erlaubt.

  • Wenn der Zugang zu einer Ressource gewährt wird, so soll in der gleichen Session der Zugang auch bei der nächsten Anfrage erlaubt sein. Dies gilt allerdings nicht für weitere Ressourcen.

• Der Zugriff auf Ressourcen wird durch dynamische Richtlinien bestimmt.

  • Beim Zugriff auf eine Ressource ist nicht unbedingt nur der Benutzername oder die gegebene Rolle von Bedeutung. Eine Richtlinie ist ein Set von Zugangsregeln, die eine Organisation einem Subjekt zuordnet. Die “Client-Identity” kann einen Benutzeraccount und jedes Attribut enthalten, welches von der Firma zugewiesen wird. Dabei kann auch die Art des Gerätes, installierte Softwareversionen usw. eine Rolle spielen.

• Das Unternehmen überwacht und misst die Integrität und den Sicherheitsstatus aller eigenen und zugehörigen Assets.

  • Keinem Asset darf durch Vererbung vertraut werden. Das bedeutet, dass das Unternehmen den Sicherheitsstatus des Assets bewertet, wenn es eine Ressourcenanforderung auswertet. Assets, welche nicht selbst von der Firma verwaltet werden, können dabei anders behandelt werden, als firmeneigene Assets.

• Jede Authentifizierung und Autorisierung ist dynamisch und wird strikt durchgesetzt, bevor der Zugriff auf eine Ressource erlaubt wird.

  • Dazu gehört beispielsweise der Einsatz einer Multi-Faktor-Authentifizierung, welche in bestimmten Zeitabständen immer wieder angefordert wird.

• Logging und Überwachung jeglicher Kommunikation im Netzwerk.

  • Ein Unternehmen sollte Daten über den Sicherheitsstatus der Assets, dem Netzwerkverkehr und der Zugriffsanfragen sammeln, diese Daten verarbeiten und alle gewonnenen Erkenntnisse nutzen, um die Erstellung und Durchsetzung von Richtlinien zu verbessern. Diese Daten können auch verwendet werden, um den Kontext für Zugriffsanfragen von Subjekten bereitzustellen.

Zero Trust Plattform Anforderungen

Um diese Grundsätze einzuhalten, bedarf es gewissen Plattform-Anforderungen. Diese wollen wir uns im folgenden Abschnitt anschauen. Ziel dabei ist es, die plattformrelevanten Aspekte der gerade beleuchteten Grundsätze hervorzuheben.

• Die Kommunikation auf Datenebene muss verschlüsselt werden. Eine Ausnahme darf es nur absichtlich geben (z. B. DNS).

• Das System muss in der Lage sein, Zugriffskontrollen für alle Arten von Ressourcen durchzusetzen. Zugriffskontrollmechanismen müssen durch identitätszentrierte und kontextbezogene Richtlinien gesteuert werden.

• Der Schutz von Datenressourcen sollte in der Lage sein, Identitäts- und Kontextrichtlinien zu verwenden, um den Zugriff zu kontrollieren.

• System- und Richtlinienmodell müssen die Sicherung aller Benutzer an allen Standorten unterstützen. Richtlinienmodell und Kontrollen müssen für Remote- und lokale Benutzer konsistent sein.

• Geräte müssen auf ihren Sicherheitszustand und ihre Konfiguration überprüft werden können, bevor ihnen der Zugriff gewährt wird, und danach regelmäßig.

• Es muss möglich sein, unternehmensfremde von unternehmensverwalteten Geräten zu unterscheiden und die Zugriffsebene entsprechend zu steuern.

• Der Zugriff auf jede Netzwerkressource muss ausdrücklich per Richtlinie gewährt werden. Kein Benutzer oder Gerät sollte von Natur aus breiten Netzwerkzugriff haben.

• Zugriffskontrollen müssen in der Lage sein, zwischen verschiedenen Diensten auf die selbe Netzwerkressource zu unterscheiden. Der Zugriff auf HTTPS muss beispielsweise getrennt vom Zugriff auf SSH gewährt werden können.

• Der Zugriff auf bestimmte Datenelemente, die in Anwendungen oder Containern mit unterschiedlichen Klassifizierungen enthalten sind, muss auf der Grundlage der Geschäftsrichtlinie durchgesetzt werden.

• Die Metadaten zum gesamten Netzwerkverkehr müssen mit dem Identitätskontext angereichert und protokolliert werden. Ausserdem muss der Netzwerkverkehr auf Sicherheits- und Datenverlust- relevante Aspekte überprüft werden können.

• Es darf bei der Anwendung von Richtlinien keinen Unterschied von lokalen zu Cloud-Ressourcen geben

• Logs müssen in Analytics Tools aufgenommen werden, um eine schnelle Durchsetzung von Richtlinien zu ermöglichen. Dadurch wird sichtbar, welche Ressourcen von welchen Subjekten gebraucht werden, und es lassen sich so durch entsprechende Automatisierungstools Rechte vergeben.

Komponenten einer Zero Trust Architektur

Zero Trust besteht im Kern aus 3 Komponenten, Policy Engine (PE), Policy Administrator (PA) und Policy Enforcement Point (PEP). Im obigen Diagramm sehen wir, dass der Policy Decision Point (PDP) aus den beiden Komponenten Policy Engine und Policy Administrator besteht.

Schauen wir uns kurz die Zuständigkeit der Komponenten an. Weiter oben habe ich bereits erwähnt, dass PDP und PEP dafür sorgen, dass ein Subjekt eine Erlaubnis zu einer bestimmten Ressource erhält. Wie die einzelnen Komponenten sich diese Arbeit aufteilen, wollen wir uns nun anschauen.

Policy Engine

Die Policy Engine-Komponente ist verantwortlich für die endgültige Entscheidung, ob der Zugriff auf eine Ressource gewährt wird. Dabei werden Unternehmensrichtlinien sowie weitere externe Quellen (z. B. CDM-Systeme, engl. “Continuous diagnostics and mitigation system”) als Eingabe für einen Vertrauensalgorithmus genutzt. Der Zugriff auf eine Ressource kann dadurch gewährt, verweigert oder widerrufen werden. Die PE ist mit der Policy-Administrator-Komponente gekoppelt. Dabei trifft und protokolliert die PE die Entscheidung (also genehmigt oder abgelehnt) und der Richtlinienadministrator führt die Entscheidung aus.

Policy Administrator

Die Policy Administrator-Komponente ist für das Herstellen und/oder Schließen des Kommunikationspfads zwischen einem Subjekt und einer Ressource verantwortlich. Der PA ist eng mit der PE verbunden und verlässt sich auf deren Entscheidung, eine Sitzung letztendlich zuzulassen oder abzulehnen. Wenn die Session autorisiert und die Anforderung authentifiziert ist, konfiguriert der PA den PEP, um den Start der Session zu ermöglichen. Wenn die Session verweigert wird (oder eine vorherige Genehmigung widerrufen wird), signalisiert der PA dem PEP, die Verbindung zu beenden. Es gibt Implementierungen die die PE und den PA als einen einzigen Dienst behandeln; hier werden sie in die zwei logischen Komponenten aufgeteilt.

Policy Enforcement Point

Die Policy Enforcement Point-Komponente ist für das Aktivieren, Überwachen und schließlich das Beenden von Verbindungen zwischen einem Subjekt und einer Unternehmensressource verantwortlich. Der PEP kommuniziert mit dem PA, um Anforderungen weiterzuleiten und/oder Richtlinienaktualisierungen vom PA zu empfangen. Sobald der PEP passiert wurde, befindet sich dahinter die Vertrauenszone (Implicit Trust Zone), in der die Unternehmensressource gehostet wird.

Schlusswort

Wir haben heute die Grundlagen von Zero Trust kennengelernt und gelernt, warum man Zero Trust überhaupt einsetzt und welche Komponenten eine Rolle spielen. Im nächsten TechUp will ich dieses interessante Thema weiter anschauen. Wir wollen uns dort die verschiedenen Enterprise-Architektur-Komponenten anschauen und betrachten, wie diese im Zero Trust Umfeld eingesetzt oder entsprechend angepasst werden müssen. Stay tuned!