Post Zero Trust und Cyberresilienz: Sicherheit beginnt mit Identität

Post Zero Trust und Cyberresilienz: Sicherheit beginnt mit der Identität.

Warum moderne Sicherheitsarchitekturen vor dem Rechner des Nutzers beginnen müssen – und erst mit der Wiederherstellungsfähigkeit enden.

Zusammenfassung (TL; DR):

• Moderne Sicherheitsarchitekturen müssen über Zero Trust hinausgehen und beim Menschen beginnen. Dies gelingt, indem man die Identität vor der Rechnernutzung durch physische Token und geschützte Laufzeitumgebungen sichert.
• Dieser “Post Zero Trust”-Ansatz priorisiert die Identitätssicherung vor der Tunnelverbindung, um Zugriffe nur auf autorisierte Anwendungen zu ermöglichen und die Cyberresilienz zu erhöhen.

Ausgangslage

Klassische Unternehmensnetze mit klarer Grenze zwischen vertrauenswürdigem Innen und unsicherem Außen gibt es faktisch nicht mehr. Cloud-Dienste, Homeoffice, externe Dienstleister und hybride Infrastrukturen sind Normalzustand. Zero Trust war die notwendige Antwort: Vertrauen entsteht nicht mehr durch die Position im Netz, sondern wird laufend über Identität, Gerät, Kontext und Richtlinien neu bestätigt.

Damit ist diese Entwicklung jedoch noch nicht abgeschlossen. Bevor man entscheidet, auf welche Ressource jemand zugreifen darf, muss geklärt sein: Wer sitzt tatsächlich vor dem Rechner? Solange die Identität nicht zweifelsfrei feststeht, soll keine geschützte Anwendung oder Zugriffsmöglichkeit entstehen können. Sicherheit beginnt damit nicht am Gateway oder vor dem Tunnel, sondern schon vor dem Rechner des Nutzers – bei der Identität selbst.

Die Sicherheitskette beginnt beim Menschen

Viele Sicherheitskonzepte setzen beim Endgerät an. Doch selbst ein abgesichertes Gerät beantwortet nicht die Frage, ob tatsächlich die berechtigte Person davorsitzt. Daraus ergibt sich eine klare Reihenfolge: zuerst die Identität, dann die Sicherheitsumgebung, dann die Policy, dann die Anwendung und erst danach die Kommunikation.

In der technischen Umsetzung beginnt dieser Prozess mit einem persönlichen Mikroprozessor-Token mit einem AES-verschlüsselten, geschützten Bereich, der eindeutig einem Besitzer zugeordnet ist. Solange der zugeordnete Benutzer nicht erfolgreich identifiziert wurde, bleibt der Token deaktiviert und steht dem Client-Betriebssystem nicht zur Verfügung. Gerät er in fremde Hände, kann die geschützte Sicherheitsumgebung ohne erfolgreiche Identifikation nicht genutzt werden. Erst nach erfolgreicher Identifikation wird der Token aktiviert. Die eigentliche Sicherheitsentscheidung fällt damit weder am Client noch im Rechenzentrum, sondern beim Menschen selbst.

Vom Token zur geschützten Laufzeitumgebung

Nach erfolgreicher Identifikation wird aus dem geschützten Tokenbereich der Kommunikationsclient gestartet – nicht in einer gewöhnlichen lokalen Umgebung, sondern in einem eigens geschützten, verschlüsselten Bereich des Arbeitsspeichers.

Dort werden Sitzungs-, Policy-, kryptografische, Kommunikations- und temporär benötigte Routinginformationen verarbeitet, ohne dauerhaft lokal gespeichert zu werden. Erst in diesem geschützten Kontext beginnen Policy-Prüfungen, Sicherheitszustandsprüfungen des Endgeräts (Posture Checks) und Kommunikationsprüfungen.

Sicherheit vor dem Tunnel

Auch nach erfolgreicher Identifikation entsteht nicht automatisch eine Verbindung. Zunächst sollte man prüfen, ob die gewünschte Kommunikation überhaupt zulässig ist – welche Identität, welches Gerät, welche Anwendung, welches Ziel und welche parallelen Kommunikationswege während der Sitzung erlaubt sind. Erst bei positiver Prüfung entsteht der Kommunikationsweg. Der Tunnel ist damit nicht Ausgangspunkt, sondern Ergebnis einer vorher getroffenen Sicherheitsentscheidung.

Zero Trust war ein Meilenstein, aber kein Endpunkt

Das Grundprinzip „Never trust, always verify“ (u. a. beschrieben in NIST SP 800-207) bleibt richtig. Post Zero Trust widerspricht diesem Prinzip nicht, sondern stellt zusätzliche Fragen: Was muss für einen Benutzer überhaupt sichtbar oder erreichbar sein? Muss für eine Aufgabe überhaupt eine allgemeine Netzwerkbeziehung entstehen?

Die drei Stufen im Vergleich

• VPN verbindet – eine verschlüsselte Verbindung entsteht, wodurch grundsätzlich eine Netzwerkbeziehung besteht. Deren erreichbare Systeme sind anschließend zu regeln.
• Zero Trust (ZTNA) kontrolliert – Identität, Gerät, Kontext und Richtlinien bestimmen granularer, welche Ressource zu nutzen ist. Ein technischer Pfad zwischen Client und Ziel kann jedoch weiterhin bestehen.
• Post Zero Trust isoliert – der Benutzer erhält keinen allgemeinen Netzwerkzugang mehr, sondern ausschließlich die konkret autorisierte Anwendung. Die dahinterliegende Infrastruktur bleibt möglichst unsichtbar, nicht adressierbar und nicht direkt erreichbar. Der Nutzer arbeitet nicht im Netzwerk, sondern mit der freigegebenen Anwendung.

Statt einen bestehenden Kommunikationsweg mit immer mehr Schutzschichten (Firewalls, Endpoint Protection, PAM, SIEM etc.) abzusichern, fragt Post Zero Trust zuerst, ob dieser Weg überhaupt nötig ist. Was nicht gebraucht wird, soll erst gar nicht Teil der Architektur sein – Angriffsfläche wird durch Design vermieden statt nachträglich abgesichert.

Das Endgerät als Teil des Sicherheitsmodells

Der Arbeitsplatzrechner ist einer der kritischsten Punkte einer Zugriffsarchitektur, da er sich in Nutzerhand befindet und oft außerhalb der kontrollierten Rechenzentrumsumgebung liegt. Während sicherheitskritischer Sitzungen sollte man deshalb je nach Policy auch parallele Kommunikationsmöglichkeiten auf dem Client einschränken – etwa Browser oder Remote-Control-Tools. Ziel ist nicht permanente Überwachung, sondern eine kontrollierte Umgebung für die Dauer einer definierten Sitzung.

Zero Footprint als Sicherheitsprinzip

Eine sichere Architektur soll auf dem Endgerät möglichst keine dauerhaft verwertbaren Spuren hinterlassen. Sitzungs-, Routing- und kryptografische Informationen werden nur für die Dauer der Kommunikation verarbeitet statt dauerhaft gespeichert. Nach Sitzungsende verliert dieser Kontext seine Funktion – Zero Footprint ist damit kein Komfortmerkmal, sondern ein eigenständiges Sicherheitsprinzip.

Kryptografie allein ist noch keine Architektur

Zu den eingesetzten kryptografischen und identitätsbasierten Verfahren können private PKI, Multi-Faktor-Authentifizierung, OTP, SSO, digitale Zertifikate, AES-Verschlüsselung oder Perfect Forward Secrecy gehören. Für sich genommen bilden diese Technologien jedoch noch kein Post-Zero-Trust-Modell. Entscheidend ist das Zusammenspiel aus Identität, geschützter Ausführungsumgebung, Policy, Kryptografie, Client-Kontrolle, Anwendungsisolation, Zero Footprint und der Vermeidung unnötiger Netzwerkbeziehungen. Post Zero Trust ist damit kein einzelnes Feature, sondern ein Architekturmodell.

Von der Zugriffssicherheit zur Cyberresilienz

Selbst die beste Zugriffskontrolle beantwortet nicht, was bei Ausfall der Infrastruktur oder in einem Katastrophenfall geschieht. Cyberresilienz bedeutet mehr als Angriffsprävention: Eine resiliente IT muss wesentliche Funktionen auch unter Störungen aufrechterhalten oder innerhalb definierter Zeit wiederherstellen. Vier zentrale Fragen: Wie lässt sich unberechtigter Zugriff verhindern? Wie bleiben Anwendungen bei technischen Ausfällen verfügbar? Wie lassen sich Daten vor Manipulation und Verlust schützen? Wie lässt sich der Betrieb nach einem Katastrophenfall zuverlässig und schnell wiederherstellen?

Der „Tresor im Tresor“

Eine cyberresiliente Infrastruktur besteht aus mehreren ineinandergreifenden Schutzebenen:

• Äußerer Tresor – Identität und Zugriff: verhindert, dass überhaupt unkontrollierte Kommunikationsbeziehungen entstehen; Post Zero Trust sorgt dafür, dass man Nutzer, Admins oder Dienstleister nicht pauschal in interne Netze einbindet.
• Mittlerer Tresor – resiliente Betriebsplattform: Compute, Storage und Netzwerkdienste müssen so gebaut sein, dass der Ausfall einzelner Hardwarekomponenten oder Nodes nicht automatisch den Dienst ausfallen lässt. Redundanz allein reicht nicht – Resilienz muss Teil der Betriebsplattform sein, nicht nur eines Notfallplans.
• Innerer Tresor – Daten und Wiederherstellung: Backup, Restore, Auslagerung, Medienbruch, Live-Synchronisation und Disaster Recovery bilden eine eigene, gleichrangige Schutzebene. Zugriffsschutz, Betriebsfähigkeit und Wiederherstellung sind keine drei getrennten Projekte, sondern Ebenen derselben Cyberresilienzstrategie.

Backup ist eine Technologie, Recovery ist eine Fähigkeit

Entscheidend ist nicht „Haben wir ein Backup?“, sondern „Wie schnell und zuverlässig können wir den Betrieb wiederherstellen?“. Zwischen geschriebenem Backup und erfolgreich wiederhergestellter Umgebung liegt ein erheblicher Unterschied. Eine belastbare Strategie umfasst u. a. getrennte Fehlerdomänen, Medienbruch, Auslagerung, Integritätsprüfungen, regelmäßige Restore-Tests, Live-Synchronisation und geografisch getrennte Betriebsmodelle.

Resilienz muss getestet werden

Hochverfügbarkeit darf nicht nur auf dem Architekturdiagramm existieren. Eine belastbare Plattform muss zeigen, was beim Ausfall einzelner Komponenten tatsächlich passiert – etwa bei Hardwaredefekt, Node-Abschaltung, Netzwerk- oder Storage-Verlust oder komplettem Standortausfall. Erst reale Tests zeigen, ob aus theoretischer Hochverfügbarkeit eine tatsächlich resiliente Plattform geworden ist – besonders relevant für kritische Infrastrukturen.

Weniger Angriffsfläche statt immer mehr Schutzschichten

Über Jahre wurde auf neue Bedrohungen meist mit zusätzlichen Sicherheitskomponenten reagiert, wodurch komplexe Stacks mit vielen Abhängigkeiten entstanden sind. Komplexität selbst ist dabei das Risiko. Die zentrale Frage sollte deshalb nicht mehr „Welche zusätzliche Komponente brauchen wir?“ lauten, sondern „Welche Angriffsfläche können wir durch bessere Architektur von vornherein vermeiden?“. Genau hier setzt Post Zero Trust an.

Praktische Umsetzung bei sayTEC

sayTEC verbindet das Konzept über drei Bausteine: Mit sayTRUST VPSC werden die Post-Zero-Trust-Prinzipien umgesetzt – die Kette beginnt mit Identität und Mikroprozessor-Token, gefolgt von geschütztem Laufzeitkontext, Policy- und Posture-Prüfungen und schließlich der autorisierten Kommunikation, ohne dass ein allgemeiner Netzwerkzugang entsteht. Mit sayFUSE HCI wird die Zugriffsebene um eine resiliente Betriebsplattform ergänzt, die auch bei Ausfall einzelner Komponenten weiterläuft. sayFUSE Backup ergänzt dies um Backup-, Recovery- und Disaster-Recovery-Szenarien. Ziel ist, Identität, Zugriff, Betrieb, Daten und Wiederherstellung von Beginn an als Teile derselben Sicherheitsarchitektur zu betrachten.

Fazit

Während das klassische Modell fragte „Wie schützen wir unser Netzwerk?“ und Zero Trust „Wer darf unter welchen Bedingungen zugreifen?“, ergänzt Post Zero Trust: „Warum muss für diesen Zugriff überhaupt eine Netzwerkbeziehung entstehen?“ – und geht noch weiter zurück zur Frage, wer vor dem Rechner sitzt und ob für diese Person eine sicherheitsrelevante Umgebung zu aktivieren ist. Cyberresilienz ergänzt schließlich, wie die Organisation trotz technischer Ausfälle handlungsfähig bleibt und wie sich der Betrieb nach einem Katastrophenfall zuverlässig wiederherstellen lässt.

Die höchste Sicherheitsstufe entsteht nicht durch immer mehr Technologie, sondern dadurch, dass bereits die Identität darüber entscheidet, ob eine Sicherheitsumgebung aktiviert werden darf, unnötige Kommunikationswege architektonisch gar nicht erst entstehen und die verbleibende Infrastruktur so resilient aufgebaut ist, dass der Ausfall einzelner Komponenten nicht automatisch die Betriebsfähigkeit gefährdet.

Häufige Fragen (FAQ)

Häufige Fragen (FAQ)