Was ist Zero Trust?

Zero Trust ist ein Konzept zur Entwicklung von Sicherheitsarchitekturen, das auf dem Grundsatz basiert, dass jede Interaktion einen nicht vertrauenswürdigen Ausgangsstatus aufweist. Dies steht im Gegensatz zu traditionellen Architekturen, bei denen Vertrauenswürdigkeit davon abhängt, ob eine Kommunikation innerhalb einer Firewall beginnt. Beim Zero-Trust-Konzept wird versucht, Lücken in Sicherheitsarchitekturen zu schließen, die auf impliziten Vertrauensmodellen und einmaliger Authentifizierung basieren.

Zero Trust wird zunehmend wichtiger, weil sich die globalen Bedrohungen verändert haben. Dies hat zur Folge, dass traditionelle Annahmen über die Vertrauenswürdigkeit von Aktivitäten in einem Netzwerk nun in Zweifel gezogen werden. Gut organisierte Cyberkriminelle können Insider rekrutieren, wodurch die Gefahr für Insider-Bedrohungen steigt, und nach immer neuen Möglichkeiten suchen, die äußere Hülle traditioneller Sicherheitsarchitekturen zu umgehen. Darüber hinaus sind Hacking-Tools und kommerzialisierte Ransomware-as-a-Service-Plattformen viel leichter verfügbar, wovon vor allem finanziell motivierte Kriminelle und Cyberterroristen profitieren. Bei all diesen Bedrohungen besteht die Möglichkeit, dass wertvolle Daten gestohlen, Wirtschaft und Handel gestört und der Alltag von Personen beeinträchtigt wird.

Vor diesem neuen Hintergrund wurde für die US-Regierungsbehörden eine Durchführungsverordnung zur Entwicklung in Richtung einer Zero-Trust-Architektur erlassen. Viele Unternehmen wägen derzeit die Kosten und Nutzen der Einführung dieses Ansatzes ab.

In einem bekannten Bericht von Forrester Research zu Zero Trust aus dem Jahr 2010 rief John Kindervag dazu auf, den gängigen Ansatz „Vertrauen ist gut, Kontrolle ist besser“ bei der Netzwerksicherheit in eine Strategie nach dem Prinzip „Kontrolliere alles, vertraue niemandem“ umzuwandeln. Kindervag stellte auch das vorherrschende Motto „Unser Netzwerk soll[te] wie ein M&M sein: eine harte äußere Schicht mit einem weichen, schwer zu kauenden Kern“ infrage. Jahrzehntelang waren Unternehmen nach diesem Stil konzipiert worden, mit einem vertrauenswürdigen oder internen Netzwerk (dem weichen Kern), das von der Außenwelt durch eine Umhüllung aus Firewalls und anderen Sicherheitsmaßnahmen (die äußere harte Schicht) getrennt war. Einzelpersonen und Endgeräte, die sich innerhalb dieses Perimeters befanden oder remote mit dem Netzwerk verbunden waren, wurden dabei als vertrauenswürdiger angesehen als solche außerhalb des Perimeters.

Dieser „harte Schale, weicher Kern“-Ansatz beim Sicherheitsdesign war vermutlich nie optimal, besteht aber auch heute noch. Bei darauf basierenden Architekturen ist es ein Leichtes, das interne Netzwerk zu durchlaufen, sobald man sich darin befindet, da Nutzerinnen und Nutzer, Geräte, Daten und andere Ressourcen nur minimal voneinander getrennt sind. Bei Cyberangriffen wird dieses Design genutzt, um sich zunächst Zugang zu einem oder mehreren internen Endgeräten oder anderen Assets zu verschaffen und sich anschließend lateral durch das Netzwerk zu bewegen. So können Schwachstellen ausgenutzt werden, um Datenexfiltrationen vorzunehmen und weitere Angriffe zu starten.

Diese unzureichende Architektur ist nicht nur anfällig für ausgefeilte Cyberangriffe. Sie wird zudem bei der Ausweitung des Netzwerks durch eine zunehmende Anzahl von Endpunkten immer mehr belastet, da Nutzerinnen und Nutzern an immer mehr Standorten auf immer mehr Assets mit immer komplexeren Services Remote-Zugriff gewährt wird. Das Problem des Vertrauens hat seit der COVID-19-Pandemie zusätzlich die Aufmerksamkeit auf sich gezogen, da die Belegschaft vieler Unternehmen vermehrt remote arbeitet und die Anzahl von Workloads in Cloud-Umgebungen immer weiter ansteigt.

Um die Schwachstellen solcher Umgebungen managen zu können, gehen Unternehmen von VPNs (Virtual Private Networks), die den sicheren Zugriff auf ein ganzes Netzwerk erlauben, auf die differenziertere Zugangslösung ZTNA (Zero Trust Network Access) über. Dabei wird der Zugriff segmentiert und Nutzerberechtigungen auf konkrete Anwendungen und Services begrenzt. Dieser Mikrosegmentierungsansatz kann Lateral Movements besser einschränken, Angriffsflächen reduzieren und die Auswirkungen von Datenpannen eindämmen. Für die Einführung eines Zero-Trust-Modells müssen Organisationen jedoch die Sicherheitsphilosophie „Kontrolliere alles, vertraue niemandem“ auf alle Bereiche ihrer Sicherheitsarchitektur anwenden.

Zero-Trust-Sicherheit basiert auf De-Perimeterisierung und Zugriff nach dem Least Privilege-Prinzip. Dadurch werden sensible Daten, Assets und Services besser vor Schwachstellen geschützt, die Netzwerkperimetern und impliziten Trust-Architekturen innewohnen.

De-Perimeterisierung: Unternehmen werden nicht mehr durch geografische Grenzen definiert. Nutzerinnen und Nutzer arbeiten von verschiedenen Standorten und Endgeräten und greifen dabei teilweise auf Ressourcen von mehreren Betriebsumgebungen zu, darunter Cloud- und SaaS-Lösungen (Software-as-a-Service), die sich oftmals nicht im Besitz oder unter der Kontrolle der IT-Abteilung des Unternehmens befinden. Mit De-Perimeterisierung lässt sich dieser Entkoppelung von Vertrauen und Standort entgegenwirken.

Least Privilege-Prinzip: Wenn eine Interaktion nicht aufgrund ihres Namens oder Standorts als vertrauenswürdig eingestuft werden kann, ist sie zunächst einmal verdächtig. Die Entscheidung, ob eine Interaktion zugelassen werden soll, wird damit zu einer geschäftlichen Entscheidung, bei der die Vorteile und Risiken der Zulassung berücksichtigt werden müssen. Das Least Privilege-Prinzip bezieht sich auf die Methode, den Zugriff auf die absolut notwendigen Ressourcen zu begrenzen, also die geringsten („least“) Privilegien für eine Aktivität zu gewähren. Jede Zugriffsanfrage auf eine Ressource muss dynamisch validiert werden – mithilfe von Identitätsmanagement und risikobasierten, kontextbezogenen Zugriffskontrollen.

Für die Implementierung einer Zero-Trust-Architektur ist es nicht erforderlich, vorhandene Netzwerke vollständig zu ersetzen oder enorme Investitionen in neue Technologien vorzunehmen. Stattdessen sollte das Framework vorhandene Sicherheitspraktiken und -tools stärken. Viele Organisationen verfügen bereits über die notwendige Basis für eine Zero-Trust-Architektur und wenden Praktiken an, die Zero Trust in ihren täglichen Abläufen unterstützen.

So sind diese kritischen, für die erfolgreiche Einführung einer Zero-Trust-Strategie erforderlichen Komponenten manchmal bereits Teil einer konventionellen Sicherheitsarchitektur:

• Identitäts- und Zugriffsmanagement

• Autorisierung

• automatisierte Richtlinienentscheidungen

• Patching von Ressourcen

• kontinuierliches Monitoring durch Protokollierung und Analyse von Transaktionen

• weitestgehende Automatisierung von wiederholbaren, fehleranfälligen Aufgaben

• Verhaltensanalysen und Threat Intelligence für einen besseren Schutz von Assets

Tatsächlich wird Zero Trust bereits heute in unterschiedlichem Umfang und in verschiedenen Umgebungen praktiziert. Für Kernmandanten ist dabei hauptsächlich die Anwendung von bestehenden Sicherheitspraktiken sowie Unternehmens- und Prozesskontrollen erforderlich. Bundesorganisationen wie das US-Verteidigungsministerium, das US-Ministerium für Innere Sicherheit und die United States Intelligence Community, für die Sicherheit eine zentrale kulturelle Säule ist, haben bei der Implementierung eines Zero-Trust- Trust-Sicherheitsmodells bereits bedeutende Fortschritte gemacht.

Um den geschäftlichen Anforderung gerecht zu werden und die Bemühungen im Bereich digitaler Transformation zu beschleunigen, verlassen sich viele Unternehmen bei der Softwareentwicklung auf Open Source-Komponenten und Drittanbieter-Tools. Allerdings können Angreifer die Software-Lieferkette infiltrieren und dadurch die Sicherheit von quelloffenen Komponenten und Abhängigkeiten im frühen Entwicklungs-Lifecycle gefährden, was zu Cyberangriffen und verzögerten Veröffentlichungen von Anwendungen führen kann. Ein Zero-Trust-Ansatz ist für den Schutz der Software-Lieferkette äußerst wichtig und stellt sicher, dass Probleme früh erkannt werden, wodurch sie sich kostengünstiger beheben lassen.

Organisationen können das Risiko von Angriffen auf die Lieferkette minimieren, indem sie sicheren Open Source-Code verwenden, Sicherheit in Container Images integrieren, die CI/CD-Pipeline stärken und Anwendungen zur Runtime überwachen.

Im Vergleich zu formalisierten kontrollierten Zugriffsmodellen wie Bell-LaPadula wird Zero Trust als Sicherheitsmodell oft abstrakt beschrieben. Es gibt unterschiedliche Komponenten, die von unterschiedlichen Gruppen oder Standardisierungsorganisationen unterstützt werden. Eine typische Reihe von Komponenten könnte so aussehen:

• Eine einzige starke Identitätsquelle für Nutzerinnen und Nutzer sowie nicht menschliche Entitäten (Non-Person Entities, NPEs)

• Nutzer- und Geräteauthentifizierung

• Zusätzliche Kontextinformationen wie Richtlinien-Compliance und Gerätezustand

• Autorisierungsrichtlinien für den Zugriff auf Anwendungen oder Ressourcen

• Richtlinien für die Zugriffskontrolle innerhalb von Apps

Diese Komponenten konzentrieren sich hauptsächlich auf die Implementierung von identitätsbasierten Zugriffsrichtlinien, die standardmäßig alles ablehnen und nur Ausnahmen zulassen.

Für die Einhaltung von Zero-Trust-Prinzipien muss eine Vertrauensgrenze so eng wie möglich gehalten werden. Per Definition wird den Subjekten innerhalb dieser Grenze vertraut, sodass Zugriffskontrollen möglicherweise wegfallen, umgangen oder anderweitig beschränkt werden. Da die Autorisierung nur für bestimmte geschäftliche Funktionen erfolgt, muss eine Grenze, die den Zugriff auf andere Funktionen ermöglicht, verkleinert werden.

Nicht alle Sicherheitsgrenzen in einer Systemarchitektur müssen den Kriterien einer richtigen Zero-Trust-Grenze entsprechen. Diese gewöhnlichen Grenzen – etwa das Filtern unerwünschter IP-Adressen, das Gewähren von Zugriff auf ein Netzwerk für bestimmte Protokolle oder das Einschränken der Social Media-Nutzung – können sich mit den Zero-Trust- Trust-Grenzen überschneiden und dennoch eine wichtige Rolle in der Sicherheitsstrategie spielen. Der entscheidende Unterschied bei der Einführung von Zero Trust ist jedoch, dass gewöhnliche Grenzen bei der Berechnung des Vertrauens nicht berücksichtigt werden, wie es vielleicht bei traditionellen Netzwerkarchitekturen der Fall war. Nur solche Grenzen, die den Zero-Trust-Prinzipien entsprechen, sollten bei der Berechnung des Vertrauens eine Rolle spielen.

Zero Trust erfordert, dass die Trennung zwischen verschiedenen Subjekten stets aufrechterhalten bleibt. Das heißt, dass zwischen zwei beliebigen Subjekten immer eine Vertrauensgrenze besteht, wodurch jede Interaktion Multi-Faktor-Authentifizierung (MFA) und direkte Autorisierung erfordert. Es besteht kein implizites Vertrauen zwischen zwei Subjekten nur aufgrund der Tatsache, dass sie sich im selben Netzwerk befinden (ein sehr häufiger Fall), am selben physischen Ort verfügbar sind oder Teil desselben Geschäftszweigs oder integrierten Systems sind.

Ein Zero-Trust-Sicherheitsmodell beruht auf dem Durchsetzen dieser Vertrauensgrenzen. Dies erfolgt üblicherweise, indem bei allen potenziellen Interaktionen mit allen Ressourcen ein Durchsetzungspunkt zwischengeschaltet wird. So, wie sich diese Interaktionen mit der Zeit ändern, ändern sich auch die Identitäten, Ressourcenzustände und andere Aspekte des Systems. Diese kontinuierliche Veränderung erfordert daher eine fortlaufende Bewertung und Überwachung der Identitäten und Ressourcen ebenso wie eine adaptive Durchsetzung von Authentifizierung und Autorisierung.

Es gibt noch immer viele Bereiche, in denen diese Grundlagen aufgrund ihrer Einschränkungen nicht implementiert werden können. Zu den gängigen Herausforderungen gehören die Weiterverwendung von Legacy-Technologien, unreife Geschäftsprozesse oder die geringe Priorität der Sicherheit als wesentlicher geschäftlicher Funktion.

Zero Trust erfordert oft eine völlig neue Denkweise sowohl auf der Führungsebene als auch bei Sicherheitsteams. Führungskräfte müssen das Risiko bewerten, dass sich durch den weiteren Einsatz bestehender, veralteter Sicherheitsarchitekturen ergibt. IT- und OT-Fachkräfte (Operational Technology) müssen erkennen, wo sie bestehende Investitionen nutzen können, um die Kosten für die Implementierung von Zero Trust zu senken, und wo neue Investitionen priorisiert werden sollten. Es lässt sich jedoch nicht leugnen, dass einige Protokolle und Geräte nie Zero Trust sein werden. In diesen Fällen muss entschieden werden, ob sie ersetzt oder beibehalten werden. Wenn bestimmte Systeme einen Zero-Trust-Ansatz nicht vollständig unterstützen können, müssen OT-Fachkräfte sich fragen, welche Kontrollen zur Risikominderung bestehen und ob alternative Sicherheitskontrollen angewendet werden können, um das Risiko noch weiter zu reduzieren.

Die Umstellung auf eine standardmäßige Ablehnung oder zwingende Überprüfung von Zugriffsanfragen – die Grundprämisse von Zero Trust – erfordert die Bereitschaft der Teams, Zero Trust nicht nur zu implementieren, sondern auch über die Zeit zu warten. Gleichzeitig müssen sie dafür sorgen, dass kein Bereich des Unternehmens versucht, die Zero-Trust-Sicherheitsarchitektur mithilfe von Schatten-IT-Lösungen zu umgehen.

Red Hat kann Sie bei den ersten Schritten der Zero-Trust-Einführung unterstützen. Dabei muss die Implementierung von Zero Trust zunächst von den Unternehmen verstanden und vollkommen unterstützt werden. Eine grundsätzliche Sensibilisierung für Cybersicherheit ist eine wichtige Voraussetzung für die weitere Unterstützung der Stakeholder: die Natur aktueller Bedrohungsumgebungen zu verstehen und zu erkennen, warum vorhandene Sicherheitspraktiken zwar wichtig, ohne die Befolgung von Zero-Trust-Prinzipien jedoch unzureichend sind. Red Hat bietet Trainings- und Weiterbildungsoptionen mit benutzerdefinierten Lernerlebnissen, die im Rahmen von Red Hat Open Innovation Labs oder anderen speziellen Red Hat Services Lösungen vermittelt werden.