Zero Trust Architektur: Komponenten und Funktionsweise erklärt

Zero Trust ist kein einzelnes Produkt, das Unternehmen installieren und anschließend als erledigt betrachten können. Vielmehr handelt es sich um ein Sicherheitsmodell, dessen Prinzipien sich durch die gesamte IT-Architektur ziehen. Der zentrale Gedanke: Kein Benutzer, Gerät oder Workload erhält allein aufgrund seines Netzwerkstandorts automatisch Vertrauen. Zugriffe werden stattdessen explizit geprüft, möglichst restriktiv vergeben und anhand relevanter Sicherheitssignale bewertet.

Eine Zero Trust Architektur verbindet dafür verschiedene technische und organisatorische Komponenten. Identitätsmanagement, Multi-Faktor-Authentifizierung, Gerätesicherheit, Zugriffskontrollen, Segmentierung, PKI, Verschlüsselung und Monitoring liefern gemeinsam die Informationen und Kontrollmechanismen, die für sichere Zugriffsentscheidungen benötigt werden.

Doch wie greifen diese Komponenten ineinander? Wer entscheidet, ob ein Zugriff erlaubt wird? Und was passiert, wenn sich das Risiko während einer bestehenden Sitzung verändert?

Was ist eine Zero-Trust-Architektur?

Eine Zero-Trust-Architektur ist die technische und organisatorische Umsetzung der Zero-Trust-Prinzipien innerhalb einer IT-Infrastruktur. Sie löst sich von der Vorstellung, dass allein der Standort innerhalb eines Unternehmensnetzwerks ausreichendes Vertrauen begründet.

Klassische Sicherheitsarchitekturen waren lange stark perimeterorientiert: Das interne Netzwerk wurde gegenüber externen Netzen abgeschirmt. Wer sich innerhalb dieser Grenze befand, konnte – abhängig von der jeweiligen Architektur und den vergebenen Berechtigungen – vergleichsweise weitreichende Zugriffsmöglichkeiten erhalten.

Zero Trust verändert dieses Vertrauensmodell. Ob sich eine Person oder ein Gerät im Büro, im Homeoffice oder in einer Cloud-Umgebung befindet, reicht allein nicht aus, um einen Zugriff als vertrauenswürdig einzustufen.

Im Mittelpunkt stehen stattdessen die konkret zu schützenden Ressourcen: Anwendungen, Daten, Dienste, Workloads und andere IT-Ressourcen. Für einen Zugriff muss geprüft werden, welche Identität unter welchen Bedingungen auf welche Ressource zugreifen möchte und ob dieser Zugriff den festgelegten Sicherheitsrichtlinien entspricht.

Eine Zero Trust Architektur setzt dabei drei zentrale Prinzipien praktisch um:

• Explizit verifizieren: Zugriffe werden anhand verfügbarer Informationen und definierter Richtlinien geprüft.
• Least Privilege: Benutzer, Geräte und Dienste erhalten möglichst nur die Berechtigungen, die sie tatsächlich benötigen.
• Assume Breach: Die Architektur berücksichtigt, dass einzelne Konten, Geräte oder Systeme bereits kompromittiert sein könnten, und soll die möglichen Auswirkungen begrenzen.

Die grundlegenden Prinzipien und die schrittweise Einführung des Sicherheitsmodells erläutern wir ausführlich in unserem Beitrag zu Zero Trust Security.

Wie ist eine Zero-Trust-Architektur aufgebaut?

Damit Zero Trust nicht nur ein abstraktes Sicherheitsprinzip bleibt, muss eine Architektur Zugriffsentscheidungen treffen und technisch durchsetzen können. Das Referenzmodell des US-amerikanischen National Institute of Standards and Technology (NIST) unterscheidet dafür mehrere logische Komponenten.

Besonders wichtig sind die Policy Engine (PE), der Policy Administrator (PA) und der Policy Enforcement Point (PEP). Vereinfacht lässt sich die Architektur außerdem in eine Control Plane für Entscheidungen und eine Data Plane für die eigentliche Kommunikation unterteilen.

Control Plane – wo Zugriffsentscheidungen entstehen

In der Control Plane werden die Informationen verarbeitet, die für eine Zugriffsentscheidung benötigt werden. Hier kommen Unternehmensrichtlinien und Sicherheitssignale zusammen.

Das können beispielsweise Informationen aus dem Identity & Access Management, Gerätemanagement, Monitoring oder aus Risiko- und Bedrohungsanalysen sein.

Die Control Plane entscheidet damit sinngemäß:

Darf diese Identität unter den aktuellen Bedingungen auf diese konkrete Ressource zugreifen?

Die eigentlichen Anwendungsdaten des Benutzers laufen dagegen über die Data Plane.

Policy Engine – Zugriff erlauben oder verweigern?

Die Policy Engine ist die zentrale Entscheidungsinstanz. Sie bewertet eine Zugriffsanfrage anhand der hinterlegten Unternehmensrichtlinien und der verfügbaren Sicherheitssignale.

Dabei kann beispielsweise berücksichtigt werden:

• Wer fordert den Zugriff an?
• Welche Rolle und Berechtigungen besitzt die Identität?
• Ist eine erforderliche MFA erfolgreich durchgeführt worden?
• Von welchem Gerät erfolgt der Zugriff?
• Entspricht das Gerät den Sicherheitsrichtlinien?
• Welche Ressource wird angefordert?
• Wie hoch ist deren Schutzbedarf?
• Gibt es aktuelle Hinweise auf ein erhöhtes Risiko?

Aus diesen Informationen leitet die Policy Engine eine Entscheidung ab. Ein Zugriff kann beispielsweise erlaubt oder verweigert werden. Ändert sich die Sicherheitslage, kann eine bereits bestehende Zugriffsentscheidung auch neu bewertet werden.

Policy Administrator – Entscheidungen technisch umsetzen

Der Policy Administrator setzt die Entscheidung der Policy Engine technisch um beziehungsweise steuert die dafür erforderlichen Maßnahmen.

Hat die Policy Engine einen Zugriff freigegeben, sorgt der Policy Administrator dafür, dass die entsprechenden Kommunikationswege eingerichtet werden können. Wird ein Zugriff nicht mehr erlaubt, kann er die Beendigung einer bestehenden Verbindung veranlassen.

Policy Engine und Policy Administrator bilden damit gemeinsam die logische Entscheidungs- und Steuerungsebene.

Data Plane und Policy Enforcement Point – Zugriff tatsächlich kontrollieren

In der Data Plane findet die eigentliche Kommunikation zwischen dem anfragenden Subjekt – beispielsweise einem Benutzer oder Gerät – und der geschützten Ressource statt.

Eine zentrale Rolle spielt dabei der Policy Enforcement Point (PEP). Er setzt die getroffene Zugriffsentscheidung durch und kontrolliert die Verbindung zur Ressource.

Vereinfacht lässt sich das Zusammenspiel so darstellen:

Benutzer/Gerät → Policy Enforcement Point → Anwendung/Ressource

Die Entscheidung darüber, ob dieser Weg geöffnet werden darf, entsteht dagegen in der Control Plane:

Identität + Gerät + Kontext + Risiko + Richtlinien → Policy Engine → Policy Administrator → Policy Enforcement Point

Damit sind Entscheidung und eigentliche Datenkommunikation logisch voneinander getrennt.

Welche Informationen fließen in eine Zugriffsentscheidung ein?

Eine Zero Trust Architektur sollte ihre Entscheidung nicht ausschließlich auf ein einzelnes Signal stützen. Ein korrektes Passwort sagt beispielsweise noch nichts darüber aus, ob das verwendete Gerät kompromittiert ist oder ob der angeforderte Zugriff zur Rolle des Benutzers passt.

Je mehr relevante und verlässliche Kontextinformationen zur Verfügung stehen, desto differenzierter kann ein Zugriff bewertet werden.

Identität und Berechtigungen

Zunächst muss feststehen, wer beziehungsweise was den Zugriff anfordert. Dabei kann es sich nicht nur um einen Menschen handeln. Auch Anwendungen, Dienste, APIs und andere Workloads benötigen Identitäten und Berechtigungen.

Relevante Informationen können sein:

• Benutzer- oder Maschinenidentität
• Rolle im Unternehmen
• zugewiesene Berechtigungen
• Authentifizierungsstatus
• MFA-Status

Eine erfolgreiche Authentifizierung beantwortet dabei zunächst die Frage nach der Identität. Ob diese Identität auch auf die gewünschte Ressource zugreifen darf, ist eine separate Autorisierungsentscheidung.

Gerät und Sicherheitszustand

Auch ein legitimer Benutzer kann ein Risiko darstellen, wenn der Zugriff von einem kompromittierten oder unzureichend geschützten Gerät erfolgt.

Eine Zero Trust Architektur kann deshalb Informationen über den Gerätezustand berücksichtigen:

• Ist das Gerät bekannt?
• Wird es zentral verwaltet?
• Ist das Betriebssystem aktuell?
• Sind erforderliche Sicherheitspatches installiert?
• Sind vorgeschriebene Sicherheitsmaßnahmen aktiv?
• Entspricht das Gerät den Compliance-Vorgaben des Unternehmens?

Damit wird nicht nur geprüft, wer zugreift, sondern auch, womit der Zugriff erfolgt.

Standort und Netzwerk

Auch Standort- und Netzwerkinformationen können weiterhin relevant sein. Zero Trust bedeutet nicht, dass der Standort ignoriert werden muss. Er verliert lediglich seine Funktion als alleinige Vertrauensgrundlage.

Ein Zugriff aus dem Unternehmensbüro kann deshalb anders bewertet werden als eine Anmeldung aus einem Land, aus dem sich derselbe Benutzer normalerweise nicht anmeldet.

Der Standort ist damit ein Kontextsignal unter mehreren, aber kein automatischer Vertrauensnachweis.

Verhalten und aktuelles Risiko

Zusätzlich können Informationen aus Monitoring, Threat Intelligence oder Verhaltensanalysen berücksichtigt werden.

Interessant sind beispielsweise Fragen wie:

• Weicht das aktuelle Verhalten deutlich vom üblichen Muster ab?
• Gibt es Hinweise auf kompromittierte Zugangsdaten?
• Werden ungewöhnlich große Datenmengen heruntergeladen?
• Greift die Identität plötzlich auf untypische Ressourcen zu?
• Gibt es aktuelle Sicherheitswarnungen für das verwendete Gerät?

Solche Informationen ermöglichen risikobasierte Zugriffsentscheidungen.

Ressource und Schutzbedarf

Nicht zuletzt ist entscheidend, worauf zugegriffen werden soll.

Der Zugriff auf eine allgemein verfügbare interne Anwendung muss nicht zwangsläufig denselben Anforderungen unterliegen wie der Zugriff auf eine Datenbank mit sensiblen Kundeninformationen oder eine administrative Oberfläche.

Daten und Anwendungen müssen deshalb nach ihrem Schutzbedarf bewertet werden. Je kritischer eine Ressource ist, desto strenger können die Anforderungen an Identität, Gerät, Authentifizierung und Kontext ausfallen.

Wie arbeiten IAM, MFA, PKI, Gerätemanagement und Monitoring zusammen?

Eine Zero Trust Architektur entsteht nicht dadurch, dass Unternehmen möglichst viele Sicherheitsprodukte einsetzen. Entscheidend ist vielmehr, dass die einzelnen Komponenten verlässliche Informationen liefern und aufeinander abgestimmt sind.

IAM – Identitäten und Berechtigungen bereitstellen

Das Identity & Access Management (IAM) bildet eine wichtige Grundlage für identitätsbasierte Zugriffsentscheidungen. Es verwaltet Benutzer und weitere Identitäten sowie Rollen und Berechtigungen.

Das IAM liefert damit Antworten auf Fragen wie:

• Wer ist die anfragende Identität?
• Welche Rolle besitzt sie?
• Welche Berechtigungen sind ihr zugeordnet?
• Ist das Konto noch aktiv?
• Wurden Berechtigungen kürzlich geändert?

 

Gerade für das Least-Privilege-Prinzip ist eine saubere Verwaltung der Berechtigungen unverzichtbar.

MFA – Identitätsprüfung verstärken

Die Multi-Faktor-Authentifizierung (MFA) ergänzt beispielsweise ein Passwort um mindestens einen weiteren Authentifizierungsfaktor.

Dadurch reicht ein gestohlenes Passwort allein nicht zwangsläufig für eine erfolgreiche Authentifizierung aus. Je nach Risiko und Richtlinie kann eine zusätzliche Authentifizierung auch gezielt für besonders sensible Zugriffe verlangt werden.

MFA stärkt damit die Identitätsprüfung, ersetzt jedoch nicht die anschließende Entscheidung darüber, auf welche Ressourcen eine erfolgreich authentifizierte Identität zugreifen darf.

PKI und digitale Zertifikate – Geräte und Maschinenidentitäten authentifizieren

Zero Trust betrifft nicht nur menschliche Benutzer. In modernen IT-Infrastrukturen kommunizieren zahlreiche Geräte, Anwendungen, APIs, Container, Server und Cloud-Workloads miteinander.

Eine Public-Key-Infrastruktur (PKI) und digitale Zertifikate können dabei eine wichtige Rolle spielen. Zertifikate ermöglichen es, Identitäten kryptografisch nachzuweisen und verschlüsselte Verbindungen aufzubauen.

Besonders relevant ist dies bei Maschinenidentitäten und bei der gegenseitigen Authentifizierung über Mutual TLS (mTLS). Dabei authentifizieren sich beide Kommunikationspartner mithilfe digitaler Zertifikate.

Wichtig ist jedoch die Abgrenzung zwischen Authentifizierung und Autorisierung: Ein gültiges Zertifikat kann die Identität eines Geräts oder Dienstes beziehungsweise den Besitz des zugehörigen privaten Schlüssels nachweisen. Es entscheidet aber nicht automatisch darüber, auf welche Unternehmensressourcen diese Identität zugreifen darf. Diese Entscheidung bleibt Aufgabe der jeweiligen Zugriffsrichtlinien.

Gerätemanagement – Sicherheitsstatus verfügbar machen

Endpoint- und Device-Management-Systeme liefern Informationen darüber, ob ein Gerät die Sicherheitsanforderungen des Unternehmens erfüllt.

Dazu gehören beispielsweise:

• Patchstand
• Betriebssystemversion
• Gerätestatus
• Verschlüsselung
• vorhandene Sicherheitssoftware
• Einhaltung definierter Compliance-Regeln

Diese Informationen können unmittelbar in Zugriffsentscheidungen einfließen. Ein Gerät, das die Anforderungen nicht mehr erfüllt, kann beispielsweise nur eingeschränkten Zugriff erhalten oder vollständig abgewiesen werden.

Monitoring und SIEM – Veränderungen und Risiken erkennen

Eine Zero Trust Architektur benötigt Transparenz darüber, was innerhalb der IT-Umgebung geschieht. Monitoring-Systeme erfassen dafür sicherheitsrelevante Ereignisse. Ein Security Information and Event Management (SIEM) kann Informationen aus verschiedenen Quellen zentral sammeln und korrelieren.

Dadurch lassen sich beispielsweise ungewöhnliche Anmeldeversuche, auffällige Datenzugriffe oder Veränderungen im Verhalten einer Identität erkennen.

Diese Informationen dienen nicht nur der nachträglichen Analyse eines Sicherheitsvorfalls. Sie können auch neue Signale für weitere Zugriffsentscheidungen liefern.

Vom Sicherheitssignal zur Zugriffsentscheidung: ein Praxisbeispiel

Wie die verschiedenen Komponenten zusammenspielen, lässt sich an einem Beispiel verdeutlichen.

Eine Mitarbeiterin aus der Finanzabteilung möchte aus dem Homeoffice auf eine sensible Finanzanwendung zugreifen.

1. Identität feststellen

Das IAM bestätigt die Benutzeridentität und liefert Informationen über ihre Rolle und Berechtigungen.

2. Authentifizierung absichern

Die Richtlinie verlangt für die Finanzanwendung eine Multi-Faktor-Authentifizierung. Die Mitarbeiterin bestätigt den zusätzlichen Faktor erfolgreich.

3. Gerät überprüfen

Das Gerätemanagement erkennt das verwendete Notebook als verwaltetes Unternehmensgerät. Patchstand und Sicherheitsstatus entsprechen den festgelegten Anforderungen.

4. Geräteidentität prüfen

Ein auf dem Gerät vorhandenes Zertifikat kann zusätzlich zur Authentifizierung des verwalteten Geräts eingesetzt werden.

5. Kontext bewerten

Die Policy Engine erhält die relevanten Informationen. Die Identität ist berechtigt, das Gerät erfüllt die Anforderungen und es liegen keine auffälligen Risikosignale vor.

6. Zugriffsentscheidung treffen

Die Policy Engine erlaubt den Zugriff entsprechend der Unternehmensrichtlinie. Der Policy Administrator veranlasst die technische Umsetzung der Entscheidung.

7. Zugriff durchsetzen

Der Policy Enforcement Point ermöglicht die freigegebene Kommunikation mit der Finanzanwendung. Andere Anwendungen oder Netzwerkbereiche werden dadurch nicht automatisch zugänglich.

8. Zugriff überwachen

Monitoring und Sicherheitsanalysen beobachten relevante Ereignisse. Entstehen neue Risikosignale, können diese in eine erneute Bewertung einfließen.

Das Beispiel verdeutlicht den eigentlichen Architekturgedanken: Nicht ein einzelnes Sicherheitssystem entscheidet über Vertrauen. Mehrere Komponenten liefern Informationen, aus denen anhand definierter Policies eine konkrete Zugriffsentscheidung entsteht.

Warum Zugriffe kontinuierlich neu bewertet werden

Ein Benutzer kann zu Beginn einer Sitzung alle Sicherheitsanforderungen erfüllen. Die Situation muss jedoch nicht während der gesamten Sitzung unverändert bleiben.

Denkbar ist beispielsweise:

• Das Gerät wird nachträglich als kompromittiert erkannt.
• Der Standort verändert sich auf ungewöhnliche Weise.
• Das Benutzerverhalten weicht deutlich vom Normalfall ab.
• Es werden ungewöhnlich große Datenmengen abgerufen.
• Berechtigungen werden durch einen Administrator geändert.
• Neue Bedrohungsinformationen erhöhen die Risikoeinstufung.

Eine moderne Zero Trust Architektur kann solche Veränderungen berücksichtigen und eine erneute Bewertung auslösen.

Abhängig von Risiko und Richtlinie kann die Reaktion unterschiedlich ausfallen:

• Zugriff unverändert fortsetzen
• zusätzliche Authentifizierung verlangen
• Zugriffsrechte einschränken
• Zugriff auf eine Ressource verweigern
• bestehende Sitzung beenden

 

Kontinuierliche Überprüfung bedeutet dabei nicht zwangsläufig eine permanente vollständige Neuauthentifizierung. Entscheidend ist vielmehr, dass eine einmal getroffene Zugriffsentscheidung nicht automatisch für unbegrenzte Zeit als unveränderlich betrachtet wird.

Neue sicherheitsrelevante Signale können zu einer Anpassung führen.

Warum Zero Trust kein einzelnes Produkt ist

Die einzelnen Komponenten zeigen bereits, warum Unternehmen Zero Trust nicht einfach kaufen können.

IAM verwaltet Identitäten. MFA stärkt die Authentifizierung. PKI und digitale Zertifikate können Geräte und Maschinenidentitäten authentifizieren und verschlüsselte Kommunikation ermöglichen. Endpoint Security bewertet Geräte. Segmentierung begrenzt Kommunikationswege. Monitoring und SIEM liefern Risiko- und Verhaltensinformationen.

Zusätzlich kann Zero Trust Network Access (ZTNA) Zugriffe gezielt auf freigegebene Anwendungen und Ressourcen beschränken. Wie ZTNA funktioniert und worin sich der Ansatz von klassischen VPN-Zugängen unterscheidet, erklären wir ausführlich im verlinkten Beitrag.

Keine dieser Technologien bildet für sich allein eine vollständige Zero Trust Architektur.

Entscheidend ist das Zusammenspiel aus:

• IAM
• MFA
• PKI und Zertifikatsmanagement
• Endpoint Security und Gerätemanagement
• Netzwerk- und Mikrosegmentierung
• ZTNA
• Monitoring und SIEM
• Risiko- und Bedrohungsinformationen
• Zugriffsrichtlinien
• Governance und klaren Verantwortlichkeiten

Welche Komponenten benötigt werden und wie sie miteinander verbunden werden, hängt von der vorhandenen Infrastruktur, den Geschäftsprozessen und dem Schutzbedarf eines Unternehmens ab.

Zentrale Sicherheitsbereiche einer Zero-Trust-Architektur

Für die Planung einer Zero Trust Architektur ist es hilfreich, die verschiedenen Sicherheitsfunktionen in zentrale Bereiche zu gliedern. Dabei existiert allerdings kein universelles Modell mit einer verbindlichen Anzahl von Säulen. Verschiedene Zero-Trust-Frameworks verwenden unterschiedliche Gliederungen.

Für die praktische Betrachtung lassen sich insbesondere folgende Sicherheitsbereiche unterscheiden.

Identitäten und Zugriffsmanagement

Identitäten bilden einen zentralen Ausgangspunkt für Zugriffsentscheidungen. Das betrifft Benutzer ebenso wie administrative Konten, Geräte, Dienste und andere Maschinenidentitäten.

Unternehmen benötigen deshalb transparente Prozesse für:

• Identitätsverwaltung
• Authentifizierung
• Rollen und Berechtigungen
• privilegierte Zugriffe
• Vergabe und Entzug von Rechten
• regelmäßige Überprüfung bestehender Berechtigungen

Eine Zero Trust Strategie kann nur funktionieren, wenn klar ist, welche Identitäten existieren und welche Zugriffe sie tatsächlich benötigen.

Geräte und Endpunkte

Geräte müssen nicht nur identifiziert, sondern auch hinsichtlich ihres Sicherheitszustands bewertet werden.

Ein verwaltetes und vollständig gepatchtes Unternehmensgerät kann beispielsweise anders behandelt werden als ein unbekanntes privates Endgerät. Endpoint Security und Device Management liefern die dafür notwendigen Informationen.

Wird ein Gerät als kompromittiert erkannt, können seine Zugriffsrechte eingeschränkt oder vollständig entzogen werden.

Netzwerk und Segmentierung

Auch in einer ressourcenorientierten Zero Trust Architektur verliert das Netzwerk nicht seine Bedeutung. Es übernimmt jedoch nicht mehr allein die Rolle einer großen Vertrauensgrenze.

Segmentierung und Mikrosegmentierung können Netzwerke und Kommunikationsbeziehungen in kleinere Bereiche unterteilen. Ziel ist es, nur die tatsächlich erforderlichen Verbindungen zuzulassen.

Wird ein System kompromittiert, soll ein Angreifer dadurch nicht automatisch weitere Systeme erreichen können. Segmentierung kann laterale Bewegungen erschweren und die möglichen Auswirkungen einer Kompromittierung begrenzen.

Anwendungen, APIs und Workloads

Nicht nur Benutzer benötigen Schutz und überprüfbare Identitäten. Moderne Anwendungen bestehen zunehmend aus miteinander kommunizierenden Diensten, APIs, virtuellen Maschinen, Containern und Cloud-Workloads.

Auch diese Kommunikation sollte authentifiziert und autorisiert werden.

Gerade in dynamischen Cloud-Umgebungen gewinnen deshalb Maschinenidentitäten, kurzlebige Credentials, Zertifikate und automatisierte Richtlinien an Bedeutung.

Daten und Verschlüsselung

Letztlich dient eine Zero Trust Architektur dem Schutz von Unternehmensressourcen und insbesondere sensiblen Daten.

Dafür müssen Unternehmen zunächst wissen, welche Daten vorhanden sind und welchen Schutzbedarf sie besitzen. Klassifizierung und Kennzeichnung schaffen dafür eine wichtige Grundlage.

Abhängig vom Schutzbedarf kommen unter anderem folgende Maßnahmen infrage:

• Verschlüsselung gespeicherter Daten
• Verschlüsselung während der Übertragung
• granulare Zugriffsrechte
• Data Loss Prevention
• Protokollierung von Zugriffen
• Verwaltung kryptografischer Schlüssel und Zertifikate

Zero Trust bedeutet damit nicht nur zu entscheiden, wer auf Daten zugreifen darf, sondern auch zu kontrollieren, wie diese Daten gespeichert, übertragen und verwendet werden.

Überwachung, Analytik und Automatisierung

Die genannten Sicherheitsbereiche benötigen eine gemeinsame Sicht auf Ereignisse und Risiken. Monitoring und Analytik liefern dafür die notwendige Transparenz.

Protokolle aus IAM, Endpoints, Anwendungen, Netzwerkkomponenten und anderen Sicherheitssystemen können zusammengeführt und ausgewertet werden. So lassen sich Veränderungen erkennen, die eine neue Zugriffsentscheidung erforderlich machen.

Mit zunehmendem Reifegrad können Unternehmen Teile dieser Reaktion automatisieren – beispielsweise indem ein als kompromittiert erkanntes Gerät unmittelbar isoliert oder für eine riskante Anmeldung zusätzliche Authentifizierung verlangt wird.

Zero Trust entwickelt sich dadurch von statischen Zugriffsregeln hin zu einem Sicherheitsmodell, das auf aktuelle Informationen reagieren kann.

So entwickeln Unternehmen eine Zero Trust Strategie

Eine vollständige Zero Trust Architektur entsteht selten in einem einzigen Projekt. Besonders in historisch gewachsenen IT-Landschaften empfiehlt sich eine schrittweise Einführung.

1. Kritische Ressourcen und Schutzbedarf bestimmen

Unternehmen sollten zunächst identifizieren, welche Daten, Anwendungen, Systeme und Geschäftsprozesse besonders kritisch sind. Nicht jede Ressource benötigt dieselben Kontrollen.

2. Identitäten erfassen

Im nächsten Schritt muss Transparenz über Benutzer, Geräte, Dienste, Anwendungen und Maschinenidentitäten geschaffen werden.

Dabei sollte nicht nur geklärt werden, welche Identitäten existieren, sondern auch, welche davon privilegierte oder besonders sensible Zugriffe besitzen.

3. Daten- und Zugriffsflüsse analysieren

Unternehmen müssen verstehen, wie Benutzer, Geräte, Anwendungen und Workloads miteinander kommunizieren.

Welche Anwendung benötigt Zugriff auf welche Daten? Welche Systeme kommunizieren untereinander? Welche externen Dienstleister greifen auf interne Ressourcen zu?

Erst diese Transparenz ermöglicht sinnvolle Least-Privilege-Regeln.

4. Least-Privilege-Policies definieren

Auf Basis der tatsächlichen Anforderungen lassen sich Zugriffsrichtlinien entwickeln.

Dabei sollte der Grundsatz gelten: So viel Zugriff wie für die jeweilige Aufgabe notwendig – aber nicht mehr.

5. Kontrollpunkte etablieren

An geeigneten Stellen müssen Zugriffsentscheidungen technisch durchgesetzt werden. Je nach Architektur können dazu beispielsweise ZTNA-Komponenten, Identity-Systeme, Netzwerkkomponenten, API-Gateways oder andere Policy Enforcement Points gehören.

6. Monitoring und Rückkopplung aufbauen

Zugriffsentscheidungen benötigen aktuelle Sicherheitssignale. Deshalb müssen relevante Ereignisse protokolliert, zentral ausgewertet und bei Bedarf in weitere Entscheidungen zurückgeführt werden.

7. Mit klar abgegrenzten Bereichen beginnen

Eine Zero Trust Strategie muss nicht sofort das gesamte Unternehmen erfassen.

Ein sinnvoller Startpunkt kann beispielsweise eine besonders kritische Anwendung, eine ausgewählte Benutzergruppe oder ein konkreter Remote-Access-Anwendungsfall sein.

So lassen sich Policies testen und technische sowie organisatorische Erfahrungen sammeln.

8. Architektur kontinuierlich weiterentwickeln

Zero Trust ist kein Projekt mit einem endgültigen Abschlussdatum. IT-Infrastrukturen, Benutzer, Anwendungen und Bedrohungen verändern sich.

Unternehmen müssen deshalb regelmäßig überprüfen:

• Sind die Zugriffsrichtlinien noch angemessen?
• Existieren unnötige Berechtigungen?
• Werden neue Geräte und Workloads vollständig erfasst?
• Liefern die Sicherheitssysteme ausreichende Informationen?
• Können weitere Entscheidungen automatisiert werden?
• Gibt es neue kritische Ressourcen oder Geschäftsprozesse?

Eine langfristige Zero Trust Strategie verbindet deshalb technische Weiterentwicklung mit kontinuierlicher Governance.

Zero Trust entsteht durch das Zusammenspiel vieler Komponenten

Eine Zero Trust Architektur ersetzt pauschales Vertrauen durch ressourcenbezogene, richtlinien- und kontextabhängige Zugriffsentscheidungen. Nicht der Netzwerkstandort allein entscheidet darüber, ob ein Zugriff erlaubt wird. Stattdessen werden Identität, Gerät, Ressource, Kontext und aktuelle Risikosignale berücksichtigt.

Im NIST-Referenzmodell bilden Policy Engine, Policy Administrator und Policy Enforcement Point das technische Herzstück dieser Entscheidungs- und Durchsetzungslogik. Damit diese Komponenten fundierte Entscheidungen treffen können, benötigen sie jedoch Informationen aus verschiedenen Sicherheitssystemen.

IAM und MFA unterstützen die Identitätsprüfung. PKI und digitale Zertifikate können Geräte und Maschinenidentitäten authentifizieren und verschlüsselte Kommunikation absichern. Endpoint-Systeme liefern Informationen über den Gerätezustand. Monitoring und SIEM machen Veränderungen und Risiken sichtbar. Segmentierung und ZTNA helfen wiederum dabei, erlaubte Kommunikationswege auf die tatsächlich benötigten Ressourcen zu begrenzen.

Eine einmal erteilte Zugriffsberechtigung muss dabei nicht dauerhaft gelten. Ändert sich der Sicherheitskontext, kann der Zugriff neu bewertet, eingeschränkt oder beendet werden.

Zero Trust ist deshalb keine einzelne Technologie und kein einzelnes Produkt. Eine belastbare Zero Trust Strategie entsteht erst, wenn Identitäten, Geräte, Anwendungen, Daten, Richtlinien und Sicherheitssignale zu einer gemeinsamen Architektur verbunden werden – und diese Architektur kontinuierlich weiterentwickelt wird.