Was ist Zero Trust?

Zero Trust ersetzt standortbasiertes Vertrauen durch kontinuierliche Überprüfung. Während bei einem Perimeter-Modell alles innerhalb des Netzwerks standardmäßig als vertrauenswürdig eingestuft wurde, bewertet Zero Trust jede Anfrage so, als stamme sie aus einer nicht vertrauenswürdigen Quelle – unabhängig davon, woher sie tatsächlich stammt oder welche Zugriffsrechte demselben Benutzer eine Stunde zuvor gewährt wurden.

Drei Ideen prägen das Modell in der Praxis:

• Kein implizites Vertrauen. Die Position im Netzwerk allein sagt noch nichts aus, und die Tatsache, dass sich ein Rechner innerhalb der Firewall befindet, ist kein Beweis dafür, dass eine Anfrage legitim ist.
• Kontinuierliche Überprüfung. Die Vertrauenswürdigkeit wird bei jeder Anfrage neu bewertet und nicht nur einmalig bei der Anmeldung ermittelt und für die Dauer einer Sitzung beibehalten.
• Prinzip der geringsten Berechtigungen. Der Zugriff beschränkt sich auf das, was für eine bestimmte Anfrage erforderlich ist, und geht nicht darüber hinaus.

„Zero Trust“ ist kein Produkt, das Unternehmen erwerben können. Es handelt sich um eine Strategie, die Identitäten, Geräte, Netzwerke, Anwendungen und Daten umfasst, und nicht um eine Technologie, die in einer dieser Schichten angesiedelt ist. Anbieter, die sie als Produkt präsentieren, beschreiben in der Regel nur eine einzelne Komponente der Architektur.

Der Begriff selbst stammt aus dem Jahr 1994, als Stephen Paul Marsh ihn in einer Doktorarbeit zum Thema “Computational Trust” an der University of Stirling verwendete. Im Jahr 2010 gelangte das Konzept in den Mainstream der Sicherheitsbranche, als der Forrester-Analyst John Kindervag den Artikel „No More Chewy Centers: Introducing the Zero Trust Model of Information Security“ veröffentlichte und darlegte, dass Vertrauen an sich eine Schwachstelle darstelle. Das 2009 gestartete BeyondCorp-Projekt von Google gehörte zu den ersten groß angelegten Implementierungen.

NIST SP 800-207 definiert sieben Grundsätze, die jede Zero-Trust-Architektur erfüllen muss.

1. Alle Datenquellen und Rechendienste sind Ressourcen. Datenbanken, Anwendungen, SaaS-Dienste, IoT-Geräte und Benutzerarbeitsplätze müssen alle geschützt werden, wobei es keine Ausnahmen aufgrund des Standorts oder der vermeintlichen Bedeutung gibt.
2. Die gesamte Kommunikation ist unabhängig vom Standort des Netzwerks gesichert.. Der Datenverkehr innerhalb des internen Netzwerks wird nach denselben Standards authentifiziert und verschlüsselt wie der aus dem öffentlichen Internet kommende Datenverkehr.
3. Der Zugriff wird pro Sitzung gewährt. Die Vertrauenswürdigkeit wird für die jeweilige Sitzung bewertet und wird nicht auf nachfolgende Sitzungen übertragen; der Zugriff auf eine Ressource sagt daher nichts über den Zugriff auf eine andere aus.
4. Der Zugriff wird durch dynamische Richtlinien geregelt. Bei den Entscheidungen werden die Identität des Clients, der Anwendungsstatus, der Zustand der Ressourcen sowie Verhaltens- und Umgebungsmerkmale berücksichtigt, anstatt auf der Grundlage eines statischen Regelsatzes zu entscheiden.
5. Das Unternehmen überwacht den Sicherheitsstatus aller Ressourcen. Keinem Asset wird standardmäßig vertraut, und die Integrität der Geräte wird fortlaufend überprüft, damit diese bei Zugriffsentscheidungen berücksichtigt werden kann.
6. Authentifizierung und Autorisierung erfolgen dynamisch und werden vor dem Zugriff strikt durchgesetzt.. Die Verifizierung erfolgt nicht als einmaliger Prüfschritt zu Beginn einer Sitzung, sondern als kontinuierlicher Zyklus aus Gewährung, Überprüfung, Anpassung und Neubewertung.
7. Das Unternehmen sammelt so viele Informationen wie möglich und nutzt diese, um seine Position zu verbessern.. Die von den Systemen, der Infrastruktur und den Kommunikationskanälen gesammelten Telemetriedaten fließen in die Richtlinien ein, die den Zugriff regeln.

Weit verbreitet ist auch eine kürzere, dreiteilige Formulierung: explizit überprüfen, eine Sicherheitsverletzung annehmen, das Prinzip der geringsten Berechtigungen durchsetzen. Diese Formulierung stammt ursprünglich von Microsoft und eignet sich recht gut als Zusammenfassung, entspricht jedoch nicht den tatsächlichen Vorgaben von SP 800-207. Daher sollten Organisationen, die ihre Systeme nach NIST-Standards aufbauen, sich an die oben genannten sieben Grundsätze halten.

Jede Zugriffsanfrage wird abgefangen und in Echtzeit entschieden, wobei eine Abfolge befolgt wird, die unabhängig davon, wer den zugrunde liegenden Stack entwickelt hat, immer gleich bleibt:

1. Eine Person beantragt Zugang auf eine Ressource, wobei es sich bei diesem Subjekt um eine Person, ein Dienstkonto, eine Arbeitslast oder einen KI-Agenten handeln kann.
2. Signale werden erfasst, darunter Identität, Gerätestatus, Standort, Zeitpunkt, bisheriges Verhalten und Bedrohungsinformationen.
3. Eine Policy-Engine wertet die Anfrage aus entgegen den Unternehmensrichtlinien und unter Berücksichtigung einer berechneten Risikobewertung.
4. Eine Entscheidung wird erlassen und vollstreckt, den Zugriff zu gewähren, ihn zu verweigern oder ihn durch einen zusätzlichen Authentifizierungsfaktor zu verstärken.
5. Die Sitzung wird überwacht, sodass sich ändernde Risikobedingungen eine Neubewertung auslösen und der Zugriff noch während der laufenden Sitzung widerrufen werden kann.

Dieser letzte Schritt ist es, der Zero Trust von den vorangegangenen Modellen unterscheidet, da bei der Perimetersicherheit an der Grenze eine einzige Entscheidung getroffen wird und man dann mit den Konsequenzen leben muss, während bei Zero Trust die Bewertung so lange fortgesetzt wird, wie die Sitzung andauert.

Am deutlichsten lässt sich der Unterschied so verstehen: Ein VPN erweitert die Netzwerkgrenze, während Zero Trust diese Grenze gänzlich aufhebt.

Wenn sich ein Benutzer über ein herkömmliches VPN verbindet, wird er in das Unternehmensnetzwerk eingebunden und erhält auf der Grundlage einer einzigen, bei der Verbindung durchgeführten Überprüfung umfassenden Zugriff auf Netzwerkebene. Alles, was von dieser Netzwerkposition aus erreichbar ist, ist für diesen Benutzer zugänglich – ebenso wie für jeden, dem es gelingt, seine Anmeldedaten zu stehlen.

Zero Trust gewährt Zugriff auf einzelne Ressourcen und nicht auf Netzwerke, sodass sich die Berechtigung zum Zugriff auf eine Anwendung nicht auf andere Ressourcen erstreckt. Jede Anfrage wird unter Berücksichtigung der aktuellen Risikosituation neu bewertet.

Die im August 2020 veröffentlichte NIST-Sonderveröffentlichung 800-207 ist die Referenzarchitektur, auf der die meisten Organisationen ihre Systeme aufbauen. Sie zieht eine klare Trennlinie zwischen den Komponenten, die Zugriffsentscheidungen treffen und durchsetzen, und den Datenquellen, auf denen diese Entscheidungen basieren.

Drei zentrale logische Komponenten

Policy Engine (PE). Trifft die Zugriffsentscheidung, indem die Unternehmensrichtlinie anhand der unten beschriebenen Eingaben bewertet, ein Vertrauensalgorithmus angewendet und anschließend der Zugriff gewährt, verweigert oder widerrufen wird.

Vertragsverwalter (PA). Diese Entscheidung wird umgesetzt, indem der Kommunikationsweg geöffnet oder geschlossen wird und die Berechtigungsnachweise oder das Token ausgegeben werden, mit denen der Benutzer auf die Ressource zugreifen kann. Zusammen bilden PE und PA das, was das NIST als „Policy Decision Point“ (Entscheidungspunkt für Richtlinien) bezeichnet.

Policy Enforcement Point (PEP). Stellt die Verbindung zwischen dem Subjekt und der Ressource her, überwacht sie und beendet sie, wobei es im Anforderungspfad eingebunden ist und die vom Richtlinienentscheidungspunkt festgelegten Maßnahmen anwendet.

Datenquellen, die in die Policy-Engine einfließen

Die folgenden Komponenten liefern die Signale, die von der Policy-Engine ausgewertet werden, ohne selbst Entscheidungen zu treffen:

• Identitätsmanagementsystem. Konten, Identitätsdatensätze, Rollen, Attribute und Berechtigungen.
• Richtlinien zum Datenzugriff. Die Regeln, die festlegen, wer unter welchen Bedingungen auf welche Ressourcen zugreifen darf.
• Kontinuierliche Diagnose und Schadensbegrenzung. Bestandsaufnahme der Ressourcen und Gerätestatus.
• Bedrohungsinformationen. Interne und externe Indikatoren für neu entdeckte Angriffe und Sicherheitslücken.
• Aktivitätsprotokolle und SIEM. Aggregierte Telemetriedaten, die dazu dienen, die Richtlinien im Laufe der Zeit zu optimieren.
• Compliance-Systeme in der Industrie. Regulatorische Anforderungen, zu deren Einhaltung das Unternehmen verpflichtet ist.
• PKI. Ausstellung und Validierung von Zertifikaten für Subjekte und Ressourcen.

Teams verwischen diese Grenze bei der Implementierung häufig und behandeln ein Identitätssystem oder einen Bedrohungs-Feed so, als würden diese die Zugriffsentscheidungen treffen, obwohl diese Systeme im NIST-Modell lediglich Eingaben an die Policy-Engine liefern, die tatsächlich die Entscheidungen trifft. Diese Unterscheidung ist besonders wichtig, wenn es darum geht, zu beurteilen, welche Teile der Architektur ein Anbieter tatsächlich abdeckt.

Als Konzept ist Zero Trust eigentlich ganz einfach: Man darf niemandem vertrauen und keine Aktion genehmigen, bevor man die Person überprüft und die Anfrage autorisiert hat. Bei der Umsetzung kommen die meisten Unternehmen ins Stocken, da Zero Trust gleichzeitig die Bereiche Identität, Netzwerk, Endgeräte, Anwendungen und Daten betrifft und nur wenige Sicherheitsteams über das Budget oder das politische Kapital verfügen, um alle fünf Bereiche auf einmal anzugehen. Das wirft die praktische Frage auf, wo man anfangen soll – und die Antwort lautet fast immer: bei der Identität.

Jede Zero-Trust-Entscheidung läuft letztlich auf eine einzige Frage hinaus: Ist diese Person tatsächlich die, für die sie sich ausgibt, und sollte sie derzeit über diesen Zugriff verfügen? Segmentierung und Verschlüsselung können diese Frage nicht beantworten, und der Gerätestatus grenzt sie zwar ein, klärt sie aber nicht – sodass die Identitätsprüfung als einzige Kontrollmaßnahme übrig bleibt, die sie lösen kann. Wenn die Identitätsprüfung unzureichend ist, setzen alle nachgelagerten Kontrollmaßnahmen treu eine Entscheidung durch, die auf einer unüberprüften Prämisse beruht.

Die Identität trägt an drei Stellen die Last:

• Authentifizierung. Überprüfung des Themas durch Phishing-resistente Methoden anstatt gemeinsam genutzter Geheimnisse, die gestohlen, wiederholt oder durch Social Engineering ausgenutzt werden können.
• Genehmigung. Die Feststellung, was eine verifizierte Person erreichen darf, basierend auf geregelte Rollen anstatt auf Zugangsrechte zurückzugreifen, die sich im Laufe der Jahre durch wechselnde Rollen angesammelt haben.
• Kontinuierliche Bewertung. Beide sollten neu bewertet werden, sobald sich die Risikosignale ändern, und der Zugriff sollte entzogen werden, wenn die Signale dies rechtfertigen.

Darin verbirgt sich eine unangenehme Konsequenz: Man kann keinen Standard der geringsten Berechtigungen durchsetzen, den man nie definiert hat, und man kann keinen Standard der geringsten Berechtigungen definieren, ohne zu wissen, wer heute Zugriff auf was hat. Die meisten Organisationen können diese Frage nicht mit Sicherheit beantworten, weshalb Identitätsmanagement sollte bereits zu Beginn eines Zero-Trust-Programms erfolgen und nicht erst in einer späteren Phase.

Identitäts- und Zugriffsmanagement stellt die Komponenten bereit, auf denen eine Zero-Trust-Architektur basiert.

Zwei Anforderungen werden tendenziell stärker unterschätzt als alle anderen.

Die Authentifizierung muss gegen Phishing geschützt sein. MFA auf Basis von Einmal-Passwörtern Die Zustellung per SMS oder E-Mail legt die Messlatte höher, ohne jedoch die Sicherheitslücke zu schließen, da Man-in-the-Middle-Angriffe und Kampagnen zur MFA-Müdigkeit Push- und OTP-Verfahren regelmäßig außer Kraft setzen. FIDO2 und gerätegebundene Passkeys Die Anmeldedaten sowohl an das Gerät als auch an die Herkunftsquelle zu binden – das ist der Mechanismus, der den Angriff tatsächlich stoppt, anstatt ihn nur zu verlangsamen. RSA vertritt dieses Argument bereits seit langem, noch bevor es zum Konsens wurde, und zwar als Vorstandsmitglied der FIDO Alliance und als Co-Vorsitzender der Arbeitsgruppe „Enterprise“.

Access muss auch dann weiter funktionieren, wenn die Cloud ausfällt. Eine Architektur, bei der jede Zugriffsentscheidung über eine Cloud-Policy-Engine geleitet wird, führt konstruktionsbedingt zu einem Single Point of Failure, und wenn dieser Dienst nicht mehr erreichbar ist, kann niemand mehr arbeiten. Für Unternehmen, die On-Premises-, Hybrid-, Air-Gapped- oder Constant-Availability-Umgebungen betreiben, in denen ein Ausfall nicht nur Unannehmlichkeiten, sondern operative Konsequenzen nach sich zieht, ist das ein schlechter Kompromiss. Zero Trust sollte die Anzahl der Faktoren reduzieren, die ein Unternehmen offline bringen können, anstatt sie zu bündeln. Deshalb sind Offline- und On-Premises-Durchsetzungswege entscheidend dafür, dass das Modell in diesen Umgebungen überlebensfähig bleibt.

Sobald sich ein Unternehmen für Zero Trust entscheidet, beginnt die eigentliche Arbeit. Es handelt sich um ein mehrjähriges Programm, und die Unternehmen, die damit Erfolge erzielen, gehen die Aufgaben in der Regel schrittweise an, anstatt alles gleichzeitig in Angriff zu nehmen.

1. Bestandsdaten, Ressourcen und aktueller Zugriff. Das Prinzip der geringsten Berechtigungen lässt sich nicht anhand einer unbekannten Ausgangsbasis durchsetzen. Ermitteln Sie daher zunächst, wer und was derzeit auf welche Ressourcen zugreifen kann – einschließlich Dienstkonten, Auftragnehmer und Maschinenidentitäten.

2. Zuerst die Authentifizierung verstärken. Der Einsatz einer phishing-resistenten MFA auf den wichtigsten Zugriffspfaden sorgt für die größte Risikominderung pro Aufwandseinheit und ist eine Voraussetzung für die meisten der nachfolgenden Maßnahmen.

3. Zugriffsrichtlinien definieren und durchsetzen. Setzen Sie Rollen und geschäftliche Anforderungen in klare Richtlinien um, heben Sie dann pauschale Zugriffsrechte auf und ersetzen Sie diese durch Berechtigungen, deren Geltungsbereich klar definiert und überprüfbar ist.

4. Entscheidungen über den Zugriff mit Kontext untermauern. Durch die Einführung einer risikobasierten Authentifizierung werden Anfragen mit geringem Risiko problemlos durchgelassen, während ungewöhnliche Anfragen überprüft oder blockiert werden. Auf diese Weise verhindern Sie auch, dass Nutzer Wege finden, das Programm zu umgehen.

5. Segmentressourcen. Indem man einschränkt, worauf eine kompromittierte Sitzung Zugriff hat, begrenzt man den Schadensumfang für den Fall, dass – nicht „falls“, sondern „wenn“ – eine Sicherheitsmaßnahme versagt.

6. Überwachen, prüfen und widerrufen. Die Überprüfung der Zugriffsrechte muss nach einem festen Zeitplan erfolgen, da sich Zugriffsrechte, die ohne Überprüfung angesammelt werden, letztendlich zu einer Ausuferung der Zugriffsrechte entwickeln, die das Programm eigentlich verhindern sollte.

Hier kommt es mehr auf die Reihenfolge als auf das Tempo an, da eine Segmentierung, die ohne zugrunde liegende kontrollierte Identität angewendet wird, zwar gut unterteilte Netzwerke erzeugt, die jedoch weiterhin überprivilegierte Konten schützen.

Unternehmen erreichen niemals das „Zero Trust“-Prinzip. Sie müssen ihre Sicherheitslage kontinuierlich bewerten und jede Zugriffsentscheidung überprüfen.

Benutzerprobleme. Eine zu strenge Überprüfung führt zu Umgehungsstrategien, Schatten-IT und einem Anstieg des Helpdesk-Aufkommens, obwohl Barrierefreiheit und Sicherheit eigentlich nicht gegeneinander abgewogen werden müssen. Bei der risikobasierten Authentifizierung wird die Anforderung an den Nutzer an das Risiko angepasst, das eine einzelne Anfrage darstellt, anstatt für alle Nutzer einheitliche Hürden zu errichten.

Altsysteme. Anwendungen, die vor der Einführung moderner Authentifizierungsstandards entstanden sind, können oft nur mit Hilfe eines Gateways, eines Proxys oder durch einen vollständigen Austausch integriert werden, was dies in den meisten Programmen zum größten Hindernis macht – und zu dem, das bei der Planung am häufigsten unterschätzt wird.

Verfügbarkeitsabhängigkeit. Die Konzentration von Zugriffsentscheidungen auf einen einzigen Cloud-Dienst schafft eine neue kritische Abhängigkeit, und sollte die Policy-Engine nicht mehr erreichbar sein, haben alle keinen Zugriff mehr auf irgendetwas. Es lohnt sich, jeden Anbieter direkt zu fragen, was mit der Authentifizierung geschieht, wenn sein Dienst ausfällt.

Organisatorischer Geltungsbereich. Da Zero Trust Identitäts-, Netzwerk-, Endpunkt-, Anwendungs- und Datenteams umfasst, bleiben Programme, die vollständig von einer einzigen Funktion aus betrieben werden, häufig an der Grenze dieser Funktion stecken.

Vermischung von Anbietern. Da kein einzelnes Produkt “Zero Trust” bietet, sollten Anbieter am besten danach bewertet werden, welche Architekturkomponenten sie tatsächlich bereitstellen, und der Begriff „Zero-Trust-Plattform“ sollte eher als zu überprüfende Behauptung denn als Kaufkategorie betrachtet werden.

Ausuferung von Identitätsdaten. Identität ist kein statisches, sondern ein zunehmend wachsendes Datenproblem, und Berechtigungen häufen sich schneller an, als die meisten Teams sie manuell überprüfen können – und genau an diesem Punkt sind Automatisierung und Analytik keine Option mehr, sondern eine Notwendigkeit.

„Zero Trust“ hat sich in zahlreichen regulierten Bereichen von einer bewährten Vorgehensweise zu einer zwingenden Anforderung entwickelt.

• Durchführungsverordnung 14028 weist an Zivile Bundesbehörden der USA in Richtung einer Zero-Trust-Architektur.
• CISA-Reifegradmodell für Zero Trust bietet den Rahmen, anhand dessen Bundesbehörden ihren Reifegrad bewerten, und gliedert sich in fünf Säulen: Identität, Geräte, Netzwerke, Anwendungen und Workloads sowie Daten.
• Zero-Trust-Strategie des Verteidigungsministeriums legt Zero-Trust-Maßnahmen für Verteidigungskomponenten fest.
• CMMC 2.0 legt in der gesamten Verteidigungsindustrie Anforderungen an die Zugangskontrolle und die Multi-Faktor-Authentifizierung fest.
• DORA und NIS2 Anforderungen hinsichtlich Zugangskontrolle, Ausfallsicherheit und Betriebskontinuität an Finanzdienstleistungen in der EU sowie kritische Infrastrukturen, die den Zero-Trust-Prinzipien entsprechen, unabhängig davon, ob der Begriff im Text vorkommt oder nicht.

In jedem dieser Bereiche spielt die Identität eine zentrale Rolle oder bildet eine Kontrollgruppe, und genau hier fragen Auditoren in der Regel als Erstes nach Belegen – und genau hier sind Organisationen am seltensten bereit, diese vorzulegen.

Auch die Anforderungen an die Ausfallsicherheit und rein cloudbasierte Architekturen stehen in einem Spannungsverhältnis zueinander, das es lohnt, frühzeitig zu durchdenken. Die im Rahmen von DORA gestellten Erwartungen an die Betriebskontinuität sowie die Vorgaben zur ständigen Verfügbarkeit im Verteidigungsbereich und bei kritischen Infrastrukturen lassen sich nur schwer mit einem Zugriffsmodell erfüllen, das nicht mehr funktioniert, sobald der Dienst eines Anbieters nicht mehr erreichbar ist.