Zero Trust: Ein neuer Maßstab für den IT-Grundschutz?
Perspektivisch wird sich der IT-Grundschutz schrittweise auf die Zero-Trust-Architektur (ZTA) als Prinzip der Informationssicherheit ausrichten [6]. Unsere Autoren diskutieren die Fragen, warum man Zero Trust benötigt, was das ZTA-Kernprinzip ist und wie sich der IT-Grundschutz künftig in dieser Richtung weiterentwickeln könnte.
Von Volker Tanger und Andreas Barke, Berlin
In der modernen IT-Sicherheitsarchitektur ersetzt die Zero-Trust-Architektur (ZTA, [1,2,3,4,5]) zunehmend das nicht mehr tragfähige, konventionelle Perimeter-Sicherheitsmodell. Dabei wird das implizite Vertrauen in einem (geschlossenen) Netzwerk durch ein rigoroses und kontinuierliches Überprüfungs- und Authentifizierungsregime ersetzt („never trust, always verify“). Der Begriff der De-Perimetrisierung wurde bereits 2004 vom Jericho Forum (vgl. [7]) propagiert und markiert einen Paradigmenwechsel in der Cybersicherheit: weg vom traditionellen Modell, das auf Vertrauen in die Netzwerkinfrastruktur als Hauptsicherheitsanker setzt – hin zu einem Modell, das den direkten, kontinuierlich überprüften Zugang zwischen Nutzern* und den von ihnen benötigten Daten und Anwendungen in den Fokus rückt.
Anstelle des Bilds eines „sicheren Netzwerks“ als Schutzschild, geht die ZTA konzeptionell davon aus, dass Netzwerke und Geräte potenziell kompromittiert sind. Daher wird bei jedem Zugriff eine strenge Authentifizierung und Autorisierung verlangt. Eine implizite Vertrauensstellung aufgrund von Netzwerkzugehörigkeit, Kennung oder Lokalität des anfragenden Clients ist dabei als nicht mehr ausreichend anzusehen. Nicht die Position im Netzwerk und IP-Adressen, sondern eine kontinuierliche Validierung der Zugriffsanfragen durch die Anwendung ist entscheidend.
Die Implementierung des Zero-Trust-Prinzips im IT-Grundschutz erfordert sowohl technische als auch organisatorische Anpassungen. Wichtig ist eine Unterscheidung zwischen Nutzern und verwendeten Systemen, also Clients, Daten, Servern und Anwendungen [5].
Zero Trust vs. Trusted Third Party
Grundsätzlich widerspricht die Einbindung einer dritten, zwischen oder neben Nutzer und Anwendung stehenden Instanz – sei es funktional oder organisatorisch – dem Kernprinzip der ZTA, da dieser per Grundannahme nicht vertraut werden dürfte. Als Dritter könnten beispielsweise ein externer Trust-Broker (Entscheidungsinstanz über festgelegte Zugriffsrichtlinien) oder Identity-Provider (zentraler Dienst zur Speicherung und Verwaltung von Nutzer- und Anwenderinformationen) fungieren. Das Vertrauen in solche externen Dienste birgt jedoch generell das Risiko, dass ein kompromittierter Anbieter die gesamte jeweilige Sicherheitsarchitektur gefährdet.
Ein bekanntes Beispiel dafür war die Exfiltration umfangreicher Kundendaten des US-amerikanischen Identity-Providers Okta in mehreren erfolgreichen Angriffen in den Jahren 2022 und 2023 [8]. Im Zuge des Hafnium-Angriffs haben Angreifer bereits ab 2021 Schwachstellen in Microsoft-Exchange-Servern ausgenutzt und weltweit Tausende von Firmen und Einrichtungen kompromittiert: Bestehende Vertrauensstellungen von Servern dienten dabei dazu, weitere Systeme anzugreifen [9].
Weitere prominente Beispiele für die Risiken, die durch die Einbindung externer Akteure entstehen können, sind der SolarWinds-Angriff von 2019, bei dem Angreifer über ein kompromittiertes Software-Update auf Systeme zahlreicher Unternehmen und Behörden weltweit zugreifen konnten, da die Software von SolarWinds als vertrauenswürdig galt. Ein Angriff auf die Colonial Pipeline in den USA zeigte 2021 die Verwundbarkeit kritischer Infrastrukturen, als Ransomware über eine kompromittierte externe Komponente eingeschleust wurde und zu erheblichen Störungen in der Kraftstoffversorgung führte. Und im gleichen Jahr verdeutlichte die Log4Shell-Lücke, wie eine Schwachstelle in einer weitverbreiteten Open-Source-Java-Bibliothek ermöglichte, in unzählige Systeme einzudringen. Die Log4Shell-Lücke und der SolarWinds-Angriff gelten auch als Paradebeispiele für Risiken, die von der Lieferkette ausgehen. Die beobachtete Zunahme solcher Angriffe (Supply-Chain-Attacks) und das potenzielle Schadensausmaß weisen im vorliegenden Kontext eine besonders hervorzuhebende Bedrohung auf (vgl. die Lageberichte des BSI 2023/2024, www.bsi.bund.de/Lageberichte/)
So unterschiedlich die geschilderten Vorfälle sind, so zeigen sie doch allesamt, dass auch vermeintlich vertrauenswürdige Systeme Bedrohungen darstellen können. Eine vorhandene ZTA hätte ein Eindringen von Angreifern in den genannten Fällen zwar nicht unmöglich gemacht – allerdings wäre der Nutzen der jeweiligen Sicherheitslücken in erheblichem Maße eingeschränkt gewesen. Eine ZTA hätte durch restriktivere Zugriffsrichtlinien und kontinuierliche Überprüfung die Ausbreitung und dauerhafte Einnistung von Angreifern wahrscheinlich erschwert [10].
Zero-Trust-Kernprinzipien
Eine ZTA liegt dann vor, wenn alle involvierten Instanzen gewissermaßen „auf einer Linie“ agieren und direkte 1:1-Verbindungen zwischen Nutzern und Systemen bestehen. Der Zugriff auf eine Anwendung (User-to-Application-Connection) und Daten (User-to-Data-Connection) erfolgt ausschließlich nach Authentifizierung und Autorisierung auf Anwendungsebene. Hierbei meldet sich der jeweilige Client direkt am Anwendungsserver (z. B. für Datenbankmanagementsysteme, Kommunikationssoftware, Entwicklungswerkzeuge und Plattformen etc.) innerhalb eines Informationsverbunds an – ohne die Notwendigkeit einer Authentifizierung über externe Dienste. In dieser Konstellation – Client, Server und Authentifizierungsdienst – besteht also kein technisches Vertrauen in Zwischeninstanzen; es findet keine Netzwerk-Anmeldung statt (Userto-Network-Connection), sondern Nutzer authentifizieren sich direkt an der Anwendung [11].
Anders gesagt, sind Mehrfachrelationen in diesem Modell ausgeschlossen. Ein Beispiel hierfür wäre der Einsatz von Middleware oder Proxy-Servern, die gegenüber der Anwendung als (alleiniger) Vertrauensanker arbeiten und somit potenzielle Schwachstellen darstellen.
Die Dienste von Trust-Brokern und Identity-Providern werden oft auch als Policy-Decision-Point (PDP) bezeichnet. Identity-Provider überprüfen die Identität und Berechtigungen eines Nutzers und treffen Authentifizierungsentscheidungen – Trust-Broker bewerten die Vertrauenswürdigkeit einer Anfrage basierend auf festgelegten Richtlinien und treffen eine Zugriffsentscheidung.
PDP bestehen aus einer Policy-Engine und einem Policy-Administrator: Die Policy-Engine (PE) entscheidet über den Umfang des Zugriffs – vollständig, eingeschränkt oder verweigert – basierend auf Informationen über Nutzende, Geräte, Richtlinien und gegebenenfalls Drittquellen. Sie verwendet dazu einen sogenannten Trust-Algorithmus, der alle Signale bewertet und einen Score zuweist. Beispielsweise würde der Zugriff durch einen bekannten und authentifizierten Nutzer über einen dem PDP bekannten Client unter Berücksichtigung weiterer Faktoren (z. B. kein ungewöhnliches Verhalten, keine Risikoindikatoren) einen relativ hohen Trust-Score erhalten und der Zugriff gewährt. Der Policy-Administrator (PA) kommuniziert schließlich mit dem Policy-Enforcement-Point (PEP), der die Richtlinien umsetzt und automatisiert Anmelde-Token bereitstellen kann.
Abbildung 1 veranschaulicht dieses Kernprinzip: Der PEP ist als integraler Bestandteil in die jeweilige Anwendung eingebettet (blaue Fläche) und interagiert mit dem PDP, wobei in keiner Verbindung eine implizite Vertrauensannahme vorliegt. Gestrichelte Verbindungen repräsentieren vollständig nichtvertrauenswürdige Verbindungen (untrusted), die streng kontrolliert und kontinuierlich verifiziert werden müssen. Diese sind als unsicher eingestuft und erfordern eine kontinuierliche Authentifizierung und Autorisierung, bevor der Zugriff auf Ressourcen oder Daten gewährt wird. Durchgezogene Verbindungen innerhalb der Anwendung haben aufgrund des Aufbaus einen höheren Trust-Score; diese sind jedoch weiterhin auf regelmäßige Überprüfungen angewiesen.
Hard- und Softwarekomponenten fungieren hier nicht als Vertrauensanker – ein höherer Trust-Score wird durch kontinuierliche Authentifizierung, Autorisierung und Verifizierung auf der Ebene von Nutzern und Daten erreicht. Ein Datenflussdiagramm kann zur Abbildung der Kommunikation zwischen Komponenten herangezogen werden, da es hilft, potenzielle Schwachstellen zu identifizieren und Angriffspunkte innerhalb der Trusted-Computing-Base (TCB) zu minimieren. In klassischen Sicherheitsmodellen umfasst die TCB, alle Komponenten, denen man für die Sicherheit eines Systems vertrauen muss. Die ZTA ist prinzipiell unabhängig von der TCB – die TCB kann in einem Informationsverbund in Abstimmung auf das Konzept der ZTA jedoch fortbestehen [12].
Heute werden zwar viele Produkte unter dem Label „Zero Trust“ vermarktet, erfüllen die hierfür erforderlichen strikten Anforderungende facto jedoch nicht.
Beispiele und Gegen-Beispiele
Ein Beispiel für ZTA-konforme Authentifizierung ist das Secure-Shell-(SSH)-Protokoll, das eine direkte, exklusive Verbindung zwischen Client und Anwendung (Shell) sowie dem darin eingebetteten Server herstellt. Ein weiteres Beispiel ist die Authentifizierung an einem Webmailer, bei der die Anfrage direkt an einen Message-Access-Protocol-(IMAP)-Server gesendet wird, der gegebenenfalls intern auf einen Lightweight-Directory-Access-Protocol-(LDAP)-Server zugreift. Jede dieser Interaktionen bleibt eine 1:1-Beziehung, ohne die Notwendigkeit einer zusätzlichen Authentifizierungsinstanz als „Passierschein“ für die Zugangskontrolle – technische Voraussetzung hierfür ist ein sicherer Schlüssel- und Berechtigungsmanagementprozess.
Dienste wie Kerberos oder Java-Web-Token (JWT) führen hingegen zu einer „Dreiecksbeziehung“ (Mehrfachrelation), da sowohl Nutzer als auch Server auf eine korrekte Informationsübertragung über eine dritte Instanz angewiesen sind. Bei strikter ZTA-Anwendung würde der Server die Anmeldedaten direkt und ohne Umwege bei einem internen Verzeichnisdienst (z. B. per LDAP) abfragen, wodurch die Abhängigkeit von externen Instanzen entfällt. In dieser Konstellation bleiben die Sitzungs- und Gültigkeitsdaten unter der Kontrolle des Servers, was die Abhängigkeit von externen Instanzen minimiert.
Technische Komponenten zur ZTA-Umsetzung
Die erwähnten PEPs setzen die Entscheidungen der PDPs technisch um und können an verschiedenen Stellen im Netzwerk positioniert sein, etwa durch dynamische Firewall-Regeln. In Software-Defined Networks (SDN) lassen sich Netzwerksegmente entsprechend der Zugriffsentscheidung dynamisch rekonfigurieren. Da man in einer solchen Umsetzung wieder zwischengeschalteten Systemen und meist zeitbasierten Multi-Use-Tokens vertrauen muss, widerspricht dies dem Kernprinzip einer ZTA jedoch, da Zwischeninstanzen und zeitbasierte Multi-Use-Tokens das Vertrauen in externe Komponenten voraussetzen.
Ein möglicher Ansatz, der dem Kernprinzip der ZTA nahekommt, könnte ein als PEP genutzter Reverse-Proxy für eine Anwendung sein, bei dem nur der Anmeldevorgang erreichbar ist – weitere Anwendungsbestandteile könnten in einer „demilitarisierten Zone“ (DMZ) isoliert sein. Die Kombination von Reverse-Proxy und DMZ führt dann dazu, dass die Anwendung als monolithisches System auftritt. Das heißt: Es gibt nur einen definierten, kontrollierten Zugangspunkt – das restliche IT-System hat keinen direkten Zugriff auf die Anwendung, sondern nur über den Reverse-Proxy.
Sobald ein PEP den Netzwerkverkehr unabhängig von der eigentlichen Anwendung regelt und somit zwischen Nutzer und Client oder System als separate Einheit agiert, liegt keine ZTA mehr vor. Dies verdeutlichen die Abbildungen 2 und 3 anhand der Beispiele einer Anmeldung des Nutzers am System/ Client sowie am PDP, wobei der PEP ein externer Dienst ist und außerhalb der Anwendung liegt.
Zusammenfassend schließen sich die Nutzung eines externen PEP und ein ZTA-konformer Aufbau aus folgenden Gründen aus:
Position im Datenfluss: Der PEP setzt die Zugriffsentscheidungen direkt am Punkt des Zugriffs um – er kontrolliert den tatsächlichen Datenfluss zwischen Nutzenden und der Ressource. Ein externer PEP würde den Zugriff auf die Ressourcen über eine dritte Instanz leiten, wodurch die Kontrolle und Sicherheit des Datenflusses kompromittiert werden könnten.
Angriffsfläche und Abhängigkeit: Ein externer PEP ist eine potenzielle Schwachstelle, da er den direkten Zugang zu den Ressourcen kontrolliert. Ein kompromittierter PEP könnte direkt unautorisierten Zugriff auf Ressourcen gewähren oder Sicherheitsrichtlinien unterlaufen. Zudem bedeutet ein externer PEP eine Abhängigkeit vom jeweiligen Anbieter, was die Flexibilität und die Fähigkeit zur autonomen Kontrolle innerhalb des Unternehmens einschränkt.
Kontrolle und Integrität: Während der PDP lediglich Entscheidungen trifft, ist der PEP für deren technische Umsetzung zuständig. Ein externer PEP würde die direkte Integrität der Datenzugriffsrichtlinien gefährden, da er möglicherweise nicht vollständig unter der Kontrolle der internen IT-Sicherheitsrichtlinien steht.
Fallstricke bei der ZTA-Umsetzung
Die technische Umsetzung einer 1:1-Verbindung im Sinne der ZTA hat erhebliche Konsequenzen für die Auswahl der eingesetzten Anbieter und Technik. Ein Risiko in der Umsetzung einer ZTA ist ein Vendor-Lock-in, also die Abhängigkeit von einem oder wenigen Herstellern: Da es keinen einheitlichen Standard für Zero-Trust-Implementierungen gibt, sind Unternehmen in ihrer Absicherung oft auf spezifische Lösungen einzelner Hersteller angewiesen. Dies kann – gerade bei kritischen Systemen – zu einer Abhängigkeit führen, die eine zukünftige Migration oder den Wechsel des Anbieters erschwert, der aus Sicherheits- oder Kostengründen eigentlich geboten wäre. Eine Exit-Strategie ist daher unabdingbar, um die langfristige Flexibilität und Sicherheit der IT-Infrastruktur zu gewährleisten.
Auf den Einsatz von Single-Signon-(SSO)-Lösungen sollte man möglichst verzichten: Denn sowohl SSO- als auch JSON-Web-Token (JWT) haben eine feste Gültigkeitsdauer, die von Minuten bis Wochen reichen kann – unabhängig davon, ob sich ein Nutzer bereits abgemeldet hat. Ein entwendetes Token ließe sich daher während seiner gesamten Gültigkeitsdauer für einen unberechtigten Zugriff missbrauchen. Ein großes Risiko besteht vor allem darin, dass ein Angreifer Zugriff auf ein sogenanntes „Golden Ticket“ erlangt (z. B. ein kompromittiertes Master-Token oder Zertifikat), mit dem er sich wiederholt anmelden könnte.
Die Nutzung getrennter Login-Daten für jeden Dienst stellt eine relativ einfache Möglichkeit dar, um hinsichtlich der Anmeldedaten eine Unabhängigkeit der Systeme voneinander zu gewährleisten. Außerdem können Single-Use-Token (SUT) als sicherere Alternative zu SSO-Token eingesetzt werden: SUT ermöglichen nur eine spezifische Operation und minimieren dadurch das Risiko, das bei einem gestohlenen, allerdings gemäß Zeitstempel noch gültigen Universal-Token, entstehen könnte.
Der Einsatz von einmalig gültigen Token oder Challenge-Response-Authentifizierungen – beispielsweise Cross-Site-Request-Forgery-(XSRF)-Token oder das PhotoTAN-Verfahren in Verbindung mit einer Bankkarte – dienen dazu sicherzustellen, dass ausschließlich autorisierte Aktionen durchgeführt werden können. Im Sinne des Zero- Trust-Prinzips wird hierbei bewusst auf Token von Zertifizierungsstellen (Certificate-Authorities, CAs) oder Authentisierungsdienstleistern verzichtet: Diese fungieren nämlich nicht nur als Drittparteien, denen sowohl Nutzer als auch Server bei der Authentifizierung vertrauen müssten. Sie weisen darüber hinaus auch keine Qualifizierung zur Bewertung oder Validierung der aufzurufenden Funktion auf (z. B. bei einer Onlineüberweisung).
Zero Trust schließt den Einfluss externer Instanzen bei wesentlichen Entscheidungen gezielt aus. Zwar können Zertifikate – etwa beim Einsatz des Transport-Layer-Security-(TLS)-Protokolls – als zusätzliche Absicherung gegen das Mitlesen der Kommunikation genutzt werden, das grundsätzliche ZT-Prinzip fordert jedoch die Minimierung oder den Ausschluss des Vertrauens in Dritte bei der eigentlichen Authentifizierung.
Neben SUT bieten sich weitere Anti-Replay-Mechanismen an (z. B. Zeitstempel, einmalige Zufallswerte, Session-IDs oder Challenge-Response-Authentifizierung). Um die Risiken weiter zu reduzieren, kann man überdies Verfahren zur Multi-Faktor-Authentifizierung (MFA) oder direkt ausgetauschte Public Keys einsetzen.
Zugleich sollte die Implementierung einer ZTA den Bedienkomfort und die Anwenderfreundlichkeit berücksichtigen, was einen Zielkonflikt zur Folge haben kann und die Umsetzung vor zusätzliche Herausforderungen stellt. Eine ZTA-Implementierung setzt sich aus technischen und organisatorischen Maßnahmen zusammen: Wenngleich eine ZTA technisch voraussetzungsvoll ist, kann in der Regel doch davon ausgegangen werden, dass organisatorische Maßnahmen bezüglich ihrer zu erwartenden Wirkung deutlich überwiegen [13].
ZTA im IT-Grundschutz
Die im Folgenden aufgeführten Maßnahmen, die eine ZTA unterstützen und flankieren, sind bereits durch bestimmte Anforderungen in den Bausteinen des IT-Grundschutzes verankert. Die Umsetzung dieser Maßnahmen ist jedoch stets an deren Kompatibilität mit dem Kernprinzip der ZTA gebunden.
Durchsetzung von Sicherheitsrichtlinien
Die Durchsetzung von Sicherheitsrichtlinien in der ZTA ist durch statische und dynamische Vorgaben geregelt, sodass jeder Zugriff kontrolliert wird. Klar definierte und durchgesetzte Sicherheitsrichtlinien innerhalb eines Informationsverbunds sind eine Grundvoraussetzung, um die Integrität und Vertraulichkeit der Daten dauerhaft zu gewährleisten. Die Umsetzung erfolgt in der ZTA durch die technische Konfiguration der Komponenten sowie die strenge Einhaltung definierter Zugriffsvorgaben [14].
Dies wird besonders durch die direkte Beziehung zwischen Daten und Nutzern erleichtert, da dazwischengeschaltete Systeme kontrolliert und abgesichert sind. Dafür müssen sowohl Client als auch (Anwendungs)-Server stabil und sicher genug sein, um sich auch in einer „feindlichen“ Umgebung sicher betreiben zu lassen.
Minimalprinzip der Rechtevergabe
Dem Prinzip der minimalen Rechtevergabe (Least-Privilege-Principle) folgend, sind Berechtigungen auf das absolut notwendige Minimum zu beschränken. Dies ist entscheidend, um Risiken zu minimieren, die von sogenannten Insider-Bedrohungen und unbefugtem Zugriff ausgehen.
Identitäts- und Zugriffsmanagement
Das Identitäts- und Zugriffsmanagement (Identity-and Access-Management, IAM) umfasst die strenge Authentifizierung und Autorisierung jedes Zugriffs auf Ressourcen. Hierdurch wird sichergestellt, dass nur berechtigte Nutzer Zugriff erhalten.
Ein Beispiel für eine strenge Authentifizierung ist die Aktions-Authentisierung, wie sie bei Banküberweisungen mittels FlickerCode
oder PhotoTAN-Generator und Bankkarte zum Einsatz kommt. Hier überprüft man nicht nur die Identität des Nutzers, sondern autorisiert allem voran die konkret angeforderte Aktion, wodurch ein höheres Maß an Sicherheit erreicht wird. Auch hierbei lassen sich durch ein kontinuierliches Threat-Modeling potenzielle Schwachstellen im IAM-System identifizieren und beheben.
Segmentierung
Obwohl Netzwerksegmentierung und der Einsatz von Virtual Private Networks (VPNs) traditionell zur Verbesserung der Sicherheit beitragen, spielen diese in einer ZTA nur eine untergeordnete Rolle. In der ZTA agiert das Netzwerk lediglich als Transportmedium – die Sicherheit wird durch direkte Authentifizierung und Autorisierung zwischen Nutzern und Daten gewährleistet. Daher sind Segmentierung und VPNs in der ZTA konzeptionell und im engeren Sinne betrachtet nur insoweit relevant, dass sie das Kernprinzip der ZTA nicht beeinträchtigen dürfen.
Bei VPNs könnte eine Beeinträchtigung der ZTA daher rühren, dass sie auf einem konventionellen Perimeter-Sicherheitsmodell beruhen: VPNs schaffen eine geschützte Verbindung in ein internes Netzwerk und behandeln Benutzer als „vertrauenswürdig“. In einer ZTA wird jedoch jedes Netzwerk – auch das interne – als potenziell unsicher betrachtet. Das VPN kann daher ein Einfallstor für Angreifer darstellen, sofern ein VPN-Zugang kompromittiert ist. Stattdessen sind Ansätze wie Software-Defined Perimeters (SDP) oder Identity-Aware Proxies (IAP) einzusetzen, die einen kontrollierten, kontextbasierten und dynamischen Zugang zu Ressourcen ermöglichen und das Kernprinzip der ZTA unterstützen.
Überwachung und Protokollierung
Maßnahmen zur Überwachung und Protokollierung (Monitoring und Logging) sicherheitsrelevanter Ereignisse sind unerlässlich, um ungewöhnliche Aktivitäten zu erkennen und darauf zu reagieren.
Trotz der weitverbreiteten Implementierung von Security-Information-and-Event-Management-(SIEM)- Systemen in Informationssicherheits-Managementsystemen (ISMS) zeigt die Praxis oft, dass Einrichtungen und Organisationen die erfassten Daten nicht ausreichend priorisieren und verarbeiten (können). Dies kann dazu führen, dass tatsächlich erfolgte Angriffe nicht oder nur verspätet im Nachgang bemerkt werden (vgl. [15]).
Durch konsequente Analyse der Protokolldaten lassen sich solche Vorfälle möglicherweise verhindern oder zumindest frühzeitig erkennen. So kann eine simple Alarmierung bei Brute-Force-Angriffen oder Anmeldungen zu ungewöhnlichen Zeiten effektiv zur Angriffserkennung beitragen. Letztlich kann ein SIEM hier den Nachweis der Wirksamkeit durch einen Abgleich der Lage (ceteris paribus) vor und nach Implementierung einer ZTA erbringen und zur Weiterentwicklung beitragen.
Fortentwicklung des IT-Grundschutzes
Eine solide umgesetzte Basis- und Standardabsicherung nach IT-Grundschutz bildet einen sicheren Ausgangspunkt, um eine ZTA in ein bestehendes ISMS zu implementieren. Es ist derzeit allerdings nicht offiziell bekannt, wie der IT-Grundschutz strukturell weiterentwickelt wird – beispielsweise hinsichtlich der Methodik, der Ausgestaltung der Absicherungsstufen, Bausteine und Anforderungen. Mit dem hier erörterten Kernprinzip der ZTA sind jedoch folgende Aspekte unbedingt und zentral zu berücksichtigen (vgl. [16]):
- stärkere systematische und regelmäßige Überprüfung von externen Diensten
- sichere Einbindung von Authentifizierungsdiensten
- Einführung von Maßnahmen zur sicheren Authentifizierung ohne Drittanbieter (z. B. mittels Self-hosted-Identity-Management-Lösungen)
- Forcieren einer lokalen und sicheren Verwaltung der Identitäts- und Berechtigungsnachweise
- nach Möglichkeit Ausschluss der Nutzung eines externen PEP
- regelmäßige Verifizierung von Authentifizierungsnachweisen auf Servern ohne dazwischen geschaltete Intermediäre
Fazit und Ausblick
Zero Trust bildet die Grundlage für einen Paradigmenwechsel, ein „Change-Programm“. Eine ZTA lässt sich nicht durch bestimmte Produkte oder ein zeitlich abgeschlossenes Projekt umsetzen: Die Einführung einer ZTA ist ein umfassender und mehrstufiger Prozess, der sorgfältige Planung und fortlaufende Anpassungen erfordert. Eine ZTA kann nur effektiv sein, wenn sie als eine langfristige Strategie begriffen wird und auf gelebten organisatorischen Sicherheitsmaßnahmen aufsetzt – und nicht als technischer Ersatz dafür dient.
Vor und während einer Implementierung gilt stets zu prüfen, ob der jeweilige Informationsverbund dies personell sowie technisch-organisatorisch stemmen und nachhaltig aufrechterhalten kann. Die ausgereifteste ZTA ist wertlos, sofern grundständige Maßnahmen zur Absicherung fehlen – beispielsweise das regelmäßige und zeitnahe Einspielen von Sicherheitspatches für Server.
Darüber hinaus ist zu berücksichtigen, dass es keinen einheitlichen Standard für die Implementierung einer ZTA gibt. Für jeden Informationsverbund muss daher eine individuell angepasste Lösung entwickelt werden, die den spezifischen Anforderungen entspricht. Dies kann zu einer verstärkten Abhängigkeit von bestimmten Herstellern und Technologien führen – gerade bei Verwendung von SSO.
Wenngleich eine ZTA darauf abzielt, das Vertrauen in Systeme und Netzwerke zu minimieren, ist ein Verzicht auf externe Drittanbieter in vielen Informationsverbünden aus betriebswirtschaftlichen und praktikablen Gründen nicht oder nur schwer umsetzbar. Der Einsatz bestimmter Hard- und Softwarekomponenten, Zertifizierungsstellen (CAs), Internet-Registraren oder Cloud-Diensten erfordert ein gewisses Maß an Vertrauen. In einer solchen Umgebung wäre es folglich zutreffend, den Begriff „Minimal Trust“ zu nutzen, statt des strapazierten Schlagworts „Zero Trust“ [10].
Hier setzt wiederum „Development, Security, and Operations“ (DevSecOps) als komplementäre Strategie an: Sicherheit wird demzufolge von Anfang an in den Entwicklungsprozess integriert. DevSecOps umfasst die Definition von Sicherheitsstandards, die Nutzung von automatisierten Sicherheitsüberprüfungen, den Umgang mit Open-Source-Komponenten und die Förderung einer Sicherheitskultur im gesamten Entwicklungsteam, um kontinuierlich sichere Software und Updates über den gesamten „Lebenszyklus“ zu gewährleisten (Security by Design).
Die Zukunftsfähigkeit und Sicherheit der IT-Architektur eines Informationsverbunds hängt letztlich maßgeblich davon ab, wie flexibel und modular sie ist, um künftige Herausforderungen und neue Bedrohungen abwehren zu können. Zero Trust wirft die passenden Fragen auf und bietet überzeugende Antworten.
Andreas Barke ist Consultant bei der HiSolutions AG mit Schwerpunkt im Aufbau und der Verbesserung von ISMS auf der Basis von IT-Grundschutz. Volker Tanger arbeitet als Expert IT Forensik bei der HiSolutions AG.
Literatur
[1] Evren Eren, Der Weg zum Zero-Trust-Networking (1), <kes> 2020#6, S. 52, www.kes-informationssicherheit.de/print/titelthema-netzwerksicherheit-zero-trustsase-caa-casb/der-weg-zum-zero-trust-networking-1/(<kes>+)
[2] Stefan Strobel, Vertrauen ist gut, kein Vertrauen ist besser?!, Entwicklung und Implementierungen von „Zero Trust“, <kes> 2022#1, S. 14, www.kes-informationssicherheit.de/print/titelthema-massnahmen-gegenransomware/vertrauen-ist-gut-kein-vertrauen-ist-besser/
(<kes>+)
[3] Kai Martius, Zero Trust: Allheilmittel oder fauler Zauber?, <kes>2022#5, S. 48, www.kes-informationssicherheit.de/print/titelthema-zeitgemaesse-netzwerksicherheit/zero-trust-allheilmittel-oder-fauler-zauber/ (<kes>+)
[4] Ulrich Kohn, Vom Perimeter-Schutz zu Zero-Trust-Architekturen, Zero Trust im Hochsicherheitsbereich erfordert vertrauenswürdige Weitverkehrsnetze, <kes> online, Oktober 2023, www.kes-informationssicherheit.de/artikel/vom-perimeter-schutz-zu-zero-trust-architekturen/ (<kes>+)
[5] Nathan Howe, Sieben Schritte zur Umsetzung von Zero Trust, <kes> online, Februar 2024, https://www.kes-informationssicherheit.de/artikel/sieben-schritte-zur-umsetzung-von-zero-trust/(<kes>+)
[6] Stefan Krempl, Zero Trust: Bund will bei IT-Sicherheit niemandem mehr vertrauen, heise online, Juni 2022, https://heise.de/-7156348
[7] Jericho Forum, Jericho Forum Commandments, Version 1.2, Mai 2007, https://collaboration.opengroup.org/jericho/commandments_v1.2.pdf
[8] Alex Scroxton, Customers speak out over Okta’s response to latest breach, Computer Weekly, Oktober 2023, www.computerweekly.com/news/366556618/Customers-speak-out-over-Oktas-response-to-latest-breach
[9] U. S. Cybersecurity and Infrastructure Security Agency (CISA), Mitigate Microsoft Exchange Server Vulnerabilities, Cybersecurity Advisory, März 2021, https://us-cert.cisa.gov/ncas/alerts/aa21-062a
[10] Haya Shulman, Was bringt Zero Trust?, Tagesspiegel Background, Februar 2022, https://background.tagesspiegel.de/it-und-cybersicherheit/briefing/was-bringt-zero-trust
[11] Scott Rose, Oliver Borchert, Stu Mitchell, Sean Connelly, Zero Trust Architecture, U. S. National Institute of Standards and Technology (NIST) Special Publication 800-207, August 2020, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
[12] Felix von Leitner (Fefe), Zero Trust, Vortrag bei der Deutschen Rentenversicherung, Sommer 2022, https://ptrace.fefe.de/Zero%20Trust/
[13] Thomas Milde, Macht Zero Trust wirklich sicher? … und wenn ja, um welchen Preis?, Datenschutz und Datensicherheit (DuD) Vol. 47, S. 641, September 2023, https://link.springer.com/article/10.1007/s11623-023-1836-3 (kostenpflichtig)
[14] Bundesamt für Sicherheit in der Informationstechnik (BSI), Übersicht konsolidierte Dokumentationsaufwände (DA) im IT-Grundschutz – Stand Kompendium 2023, Juni 2024, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Drafts/Community_
Draft/Uebersicht_DA-IT-Grundschutz_Kompendium_2023.html
[15] Volker Tanger, Andreas Barke, Jens Ohlig, Logs, SIEM, EDR und Co.: Erkennung von Cyberangriffen, iX-Notfallguide 2024, S. 22, Juni 2024, https://shop.heise.de/ix-special-2024/pdf (kostenpflichtig)
[16] Bundesamt für Sicherheit in der Informationstechnik (BSI), Positionspapier Zero Trust 2023, Juni 2023, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeLeitlinien/Zero-Trust/Zero-Trust_04072023.pdf