Der Angreifer kam nicht durch eine Firewall. Er kam über ein VPN-Zertifikat eines externen Dienstleisters, das seit acht Monaten nicht mehr gebraucht, aber auch nie deaktiviert worden war. Einmal im internen Netz, bewegte er sich sechzehn Tage lang unbemerkt zwischen vierzig Systemen – weil jedes System, das er von innen ansprach, ihm vertraute. Die Firewall hatte ihren Job gemacht. Sie hatte nur den falschen Umkreis geschützt.
Das ist die Grundschwäche des klassischen Perimeter-Modells: Es unterscheidet zwischen “außen” (gefährlich) und “innen” (vertrauenswürdig). Sobald jemand – Angreifer oder kompromittiertes Konto – diese eine Grenze überwindet, gibt es innerhalb des Netzwerks kaum noch Widerstand.
Warum das Perimeter-Modell nicht mehr trägt
Firewall, VPN, DMZ – das Castle-and-Moat-Modell stammt aus einer Zeit, in der Mitarbeiter im Büro saßen, Anwendungen im eigenen Rechenzentrum liefen und es einen klar definierbaren Netzwerkrand gab. Diese Voraussetzung ist heute selten erfüllt. Mitarbeiter arbeiten remote, Anwendungen laufen verteilt über mehrere Cloud-Anbieter, Partner und Freelancer brauchen punktuellen Zugriff, und Geräte wechseln zwischen Heimnetz, Mobilfunk und Firmen-WLAN. Der Perimeter ist nicht kleiner geworden – er ist verschwunden.
Das Risiko bleibt trotzdem bestehen: Ein einziges kompromittiertes Zugangsdatum – Phishing, Credential Stuffing, ein gestohlenes Gerät – reicht aus, um sich innerhalb eines flach vertrauenden Netzwerks lateral zu bewegen, ohne weitere Hürden zu überwinden.
Das Kernprinzip: Never trust, always verify
Zero Trust kehrt die Grundannahme um. Kein Nutzer, kein Gerät, kein Dienst wird allein deshalb als vertrauenswürdig behandelt, weil er sich “im Netzwerk” befindet. Jede Anfrage wird individuell geprüft – unabhängig davon, ob sie aus dem Firmen-LAN oder aus einem Café-WLAN kommt.
Das NIST-Rahmenwerk SP 800-207 fasst das in drei Leitsätzen zusammen: Jede Zugriffsanfrage wird explizit authentifiziert und autorisiert. Zugriff wird nach dem Prinzip der minimalen Rechte (Least Privilege) gewährt, zeitlich und funktional begrenzt. Und man geht grundsätzlich davon aus, dass ein Einbruch bereits stattgefunden hat oder stattfinden wird (Assume Breach) – die Architektur wird so gebaut, dass ein einzelner kompromittierter Punkt keinen ungehinderten Zugriff auf alles andere ermöglicht.
Die drei Säulen einer Zero-Trust-Architektur
Identity als neuer Perimeter. Starke, kontextbezogene Authentifizierung – Multi-Faktor, idealerweise phishing-resistent über FIDO2/Passkeys – und Conditional-Access-Policies, die Standort, Gerätezustand und Anfrageverhalten in die Zugriffsentscheidung einbeziehen.
Device Trust. Nicht nur wer zugreift, sondern wovon aus. Ein Gerät ohne aktuelle Patches, ohne Festplattenverschlüsselung oder mit deaktiviertem Endpoint-Schutz sollte unabhängig von korrekten Zugangsdaten eingeschränkten oder keinen Zugriff auf sensible Systeme bekommen.
Mikrosegmentierung. Statt eines flachen internen Netzwerks werden Systeme in kleine, granular kontrollierte Segmente aufgeteilt. Ein kompromittierter Webserver kann dann nicht ungehindert mit der Datenbank eines völlig anderen Systems sprechen, nur weil beide im selben VLAN liegen.
Warum “wir haben jetzt Zero Trust gekauft” nicht funktioniert
Viele Anbieter verkaufen einzelne Bausteine – ein ZTNA-Gateway als VPN-Ersatz, ein IAM-Tool mit Conditional Access, eine Mikrosegmentierungs-Appliance – unter dem Label “Zero Trust”. Technisch korrekt, aber unvollständig: Ein ZTNA-Gateway, das vor einem intern weiterhin flach vertrauenden Netzwerk hängt, verschiebt das Problem nur an den Rand, löst es aber nicht.
Zero Trust ist ein Architekturprinzip, das Identity, Device-Health, Netzwerksegmentierung, Policy-Enforcement und Monitoring als zusammenhängendes System behandelt. Ein einzelnes Produkt kann einen Teil davon liefern. Keines liefert das Ganze – weil das Ganze eine Entscheidung darüber ist, wie eine Organisation Vertrauen grundsätzlich vergibt, nicht, welches Tool sie kauft.
Ein realistischer Einstieg
Der Big-Bang-Ansatz – “wir bauen jetzt eine vollständige Zero-Trust-Architektur” – scheitert fast immer an der Komplexität bestehender Systeme. Der Weg, der in der Praxis funktioniert, beginnt bei Identity: konsequente Multi-Faktor-Authentifizierung für alle Konten, Conditional-Access-Regeln für die kritischsten Anwendungen, und ein sauberes Offboarding-Verfahren, das Zugänge wie das eingangs beschriebene VPN-Zertifikat zuverlässig deaktiviert.
Erst danach folgt Segmentierung – beginnend bei den Systemen mit dem höchsten Schutzbedarf, nicht als flächendeckendes Rollout. Zero Trust ist kein Projekt mit einem Enddatum. Es ist eine schrittweise Reduktion von implizitem Vertrauen, die nie ganz abgeschlossen ist – aber ab dem ersten Schritt messbar wirkt.