
Zero Trust ist in aller Munde. Durch die zunehmende Dezentralisierung und Nutzung von Cloud-Diensten, den exponentiellen Anstieg von IoT-Geräten sowie den anhaltenden Trend hin zum Homeoffice, wird es immer schwieriger, Netze und Dienste sicher zu betreiben. Wer im „Cloud first“-Umfeld agiert, muss auch Sicherheitslösungen über die Cloud bereitstellen, um das Ökosystem aus Kunden, Geschäftspartnern, Mitarbeitenden, Anwendungen und Daten sicher zusammenzuhalten.
Klassische Ansätze wie Perimeterschutz und die Anbindung von „externen Teilnehmenden“ via VPN greifen nicht weit genug. Dies liegt zum einen daran, dass Datenverbindungen durch wenige zentrale Punkte geschleust werden müssen und eine Unterscheidung zwischen „gut“ und „böse“ anhand der Einordnung „drinnen“ oder „draußen“ nicht mehr funktioniert. Zum anderen gehen immer häufiger Angriffe von korrekt authentifizierten Usern aus, nach dem Zugangsdaten durch z.B. „Phishing“ erbeutet oder Geräte kompromittiert wurden. Hier greift das Konzept des Zero Trust.
Rückblickend ist vieles nicht mehr vorstellbar. Der Digitalisierungsschub, der durch die zwangsweise Umstellung der Arbeitswelt erfolgte, ist überall sichtbar. Aus der Not heraus haben viele Unternehmen ihre Bedenken beiseite geschoben und auf Cloud-Dienste zurückgegriffen. Zumeist wurde Microsoft 365 bereitgestellt.
Doch die Kurzfristigkeit, mit der agiert wurde, zeigt auch ihre Schattenseiten. Ohne die üblichen Projekt- und Changemanagement-Prozesse wurden Tools eingeführt, die einen erheblichen Einfluss auf den Betriebsablauf haben. Grundlegende Fragestellungen wie z. B. Datenschutzkonformität wurden dabei zurückgestellt.
Diese Herangehensweise war richtig und hat es der deutschen Wirtschaft ermöglicht, verhältnismäßig gut durch die Krise zu kommen. Nichtsdestotrotz ist nun, zwei Jahren später, die Zeit gekommen, die ordentliche Einführung der New-Work-Tools zu prüfen und gegebenenfalls offen gelassene Punkte und Schwachstellen zu schließen.
Hier gibt es zwei ineinandergreifende Handlungsstränge: Zum einen die organisatorischen Veränderungen, z. B. die Implementierung neuer Prozesse, bei denen weiterer Nachholbedarf besteht, zum anderen die technologischen Aspekte.
Dringenden Handlungsbedarf gibt es bei vielen Unternehmens beispielsweise im Bereich IT-Security. Durch die Verlagerung der Mitarbeitenden ins Homeoffice verändert sich der Perimeter: Wo bislang Firewalls die Grenze zwischen dem als sicher wahrgenommenen internen Netz und dem Internet gezogen haben, existiert heute keine klare Grenze mehr. Der Schutzbedarf hat sich damit verlagert: weg von den Systemen, hin zu den Identitäten. Dies wird z. B. in einer erhöhten Exposition für Phishing-Attacken deutlich.
Um die Basis für den langfristig erfolgreichen, risikolosen Betrieb des Modern Workplace sicherzustellen, sollte zunächst eine neutrale Bewertung des Status quo durchgeführt werden.
Beispielhafte Fragen, die im Rahmen einer Risikobewertung gestellt werden müssen:
Nach dieser Analysephase folgt die Konzeptionsphase, in der einerseits das kurzfristige Vorgehen hinsichtlich identifizierter Risiken und andererseits das mittelfristige Management der neu eingeführten Lösungen definiert werden. Dies ist nötig, da sich Cloud-Lösungen in einem steten Wandel befinden, so dass sich gegebenenfalls bereits in den vergangenen zwei Jahren Änderungen ergeben haben, die im pandemiebedingten Arbeitsmodus keine Berücksichtigung fanden. So war es vor einiger Zeit noch notwendig, zur Nutzung von Single Sign-on (SSO) eine ADFS-Farm zu betreiben. Durch die laufenden Verbesserungen von Azure AD Connect ist ADFS heute nicht mehr notwendig, und wird auch nicht mehr empfohlen – um nur ein Beispiel zu nennen.
Die Sicherheit von Komponenten darf nicht mehr ausschließlich durch vorgelagerte Firewalls oder ähnliches sichergestellt werden. Vielmehr ist jede Applikation für sich genommen für die eigene Sicherheit voll verantwortlich. Dies bedeutet, dass jede Applikation grundsätzlich Kommunikationspartnern sowie Clients misstraut und deren Integrität und Zugriffsberechtigung selbst verifizieren muss.

Dies bedeutet nicht nur, dass beispielsweise jede Applikation einen zugreifenden Client erneut mithilfe eines Authentifizierungsproviders verifizieren muss, sondern auch dass Datenverbindungen zwischen Applikationen ebenso einer Verifikation des tatsächlich dahinterstehenden Users bedürfen. Dies bedeutet somit auch die Abkehr von praxisüblichen technischen Benutzerkonten, z.B. für die Kopplung von IT-Anwendungen untereinander oder nicht persönliche Schulungs- und Administrationskonten.
Außerdem bedeutet Zero Trust, dass Unternehmen auch im Nachhinein nachverfolgen können möchten, welche Tätigkeiten durch einen User erfolgt sind, da ich jeder Aktion grundsätzlich misstraue. Entsprechend verlangt ein Zero-Trust Ansatz ein granulares Logging.
Die Vorteile einer solchen Architektur im Überblick:
Durch die neue Architektur ergeben sich einige Punkte, die bei einer Zero-Trust-Architektur besonders berücksichtigt werden müssen.
Zero Trust ermöglicht es, Applikationen nativ auf einem Endgerät nutzen zu können. Eine Absicherung auf Basis der Netzwerkinfrastruktur kann entfallen.
Perimeterschutz ist nicht per se obsolet. Einige Applikationen können hohe Schutzbedarfe aufweisen, sodass diese nicht rein durch einen Zero-Trust-Ansatz abgesichert werden können oder sollten. Beispiele sind insbesondere in der Bearbeitung von vertraulich eingestuften Dokumenten in der öffentlichen Verwaltung zu finden.
In diesem Fall sollte jedoch zusätzlich zu den bestehenden Schutzmechanismen ein Zero-Trust-Ansatz unternehmensintern eingeführt werden, da durch eine reine Netzabsicherung der Kreis der Angreifer zwar minimiert wird, nur durch Zero Trust jedoch eine Nachverfolgbarkeit gegeben wird.