Bildquelle: Pexels / https://www.pexels.com/photo/man-in-shirt-holding-access-card-over-reader-13657406/
Zero Trust scheitert selten am Tool, sondern an Altanwendungen, Service-Identitäten und Supportpfaden
Viele Unternehmen haben inzwischen eine ZTNA-Lösung, neue Richtlinien für bedingten Zugriff oder erste Mikrosegmentierungsprojekte eingeführt. Auf den Architekturfolien sieht das nach einer klaren Zero-Trust-Reise aus. Im Alltag stockt der Fortschritt trotzdem oft erstaunlich schnell. Nicht weil das Zugangstool technisch nichts könnte, sondern weil ältere Anwendungen, unklare Service-Identitäten, schwach definierte Ausnahmen und improvisierte Supportpfade den Ansatz im Betrieb aufweichen.
Grundlagen: Zero Trust ist ein Sicherheits- und Architekturansatz, bei dem dem Netzwerk selbst kein pauschales Vertrauen mehr gegeben wird. Jeder Zugriff auf Daten oder Services soll anhand von Identität, Gerätezustand, Kontext und Richtlinie geprüft werden, statt allein nach Standort oder Netzsegment zu entscheiden. Relevant ist das vor allem deshalb, weil sich seit Jahren zeigt, wie leicht Angreifer nach einem ersten Zugang seitlich durch Umgebungen wandern können, wenn interne Verbindungen zu großzügig vertraut werden.
NIST beschreibt Zero Trust genau in diesem Sinn als Sammlung von Konzepten zur möglichst präzisen, least-privilege-basierten Zugriffsentscheidung pro Anfrage. CISA ergänzt mit seinem Zero Trust Maturity Model, dass der Weg dorthin mehrere Säulen und querliegende Fähigkeiten wie Sichtbarkeit, Automatisierung und Governance braucht. Das britische NCSC formuliert es operativ noch greifbarer: Wer Vertrauen aus dem Netzwerk herausnimmt, muss stattdessen fortlaufend Vertrauen in Nutzer, Geräte und Services aufbauen. Genau an dieser Stelle beginnt die eigentliche Betriebsarbeit.
Ein neues Zugriffstool ersetzt keine unsaubere Anwendungslandschaft
Der häufigste Denkfehler besteht darin, Zero Trust wie ein Einführungsprojekt für Remote Access oder Single Sign-on zu behandeln. Dann wird eine neue Zugangsschicht vor Anwendungen gesetzt, die internen Abhängigkeiten dahinter bleiben aber unangetastet. Solange Altanwendungen nur aus festen Netzsegmenten erreichbar sind, moderne Authentisierungsverfahren nicht unterstützen oder mit groben Sammelkonten arbeiten, bleibt die Policy-Logik lückenhaft.
Das NCSC weist ausdrücklich darauf hin, dass Organisationen ihre Architektur, Daten, Services und Risiken kennen müssen, um späte Integrationsprobleme mit Legacy-Systemen zu vermeiden. Genau daran fehlt es oft. Viele Teams wissen zwar, welche kritischen Anwendungen existieren, aber nicht belastbar, welche technischen Nebenpfade daran hängen: alte Admin-Zugänge, Datenbankdirektzugriffe, interne API-Freigaben, ausgenommene Jump Hosts oder historische Dienstkonten. Wird Zero Trust darübergestülpt, entstehen schnell Sonderfälle. Offiziell gilt dann ein modernes Zugriffsmodell, praktisch existieren daneben mehrere unkontrollierte Ausweichrouten.
Für den Betrieb ist das gefährlich, weil diese Restpfade meist genau dort entstehen, wo Zeitdruck oder Fachkritikalität am größten sind. Ein Team umgeht eine Richtlinie, damit eine Altanwendung weiterläuft. Ein Lieferant bekommt eine zu breite Ausnahme, weil seine Wartung sonst stockt. Ein Administrator nutzt weiter ein altes Sammelkonto, weil die Anwendung keine feinere Trennung unterstützt. Aus Einzelfällen wird so schrittweise ein zweites, unsichtbares Berechtigungsmodell.
Service-Identitäten sind für Zero Trust genauso wichtig wie Benutzerkonten
Zero Trust wird in vielen Diskussionen noch zu stark aus Sicht menschlicher Nutzer erklärt. Im produktiven Betrieb ist das zu eng. Das NCSC betont ausdrücklich, dass Identitäten nicht nur Menschen, sondern auch Services und Geräte repräsentieren. Genau diese maschinellen Identitäten sind in modernen Umgebungen oft die eigentliche Engstelle: APIs, Hintergrundjobs, Integrationsdienste, Container-Workloads, Automationsskripte oder Sicherheitskomponenten sprechen permanent miteinander und benötigen dafür nachvollziehbare, zweckgebundene Vertrauensbeziehungen.
Wenn Service-Identitäten unscharf bleiben, verliert Zero Trust seine Präzision. Dann werden technische Verbindungen pauschal über Netzlage, gemeinsame Secrets oder breit berechtigte Servicekonten freigeschaltet, obwohl der Ansatz eigentlich pro Anfrage und pro Rolle differenzieren sollte. NISTs Grundidee von genauer, least-privilege-orientierter Zugriffssteuerung lässt sich aber nur umsetzen, wenn auch maschinelle Akteure eindeutig identifizierbar sind und nicht als graue Infrastrukturmasse behandelt werden.
Praktisch heißt das: Teams müssen wissen, welcher Dienst mit welchem anderen Dienst sprechen darf, unter welcher Identität das geschieht, welche Token- oder Zertifikatswege dahinterliegen und wie sich Missbrauch oder Drift erkennen lässt. Andernfalls entsteht ein blinder Fleck. Nach außen sieht die Zero-Trust-Strategie modern aus, intern laufen jedoch alte Vertrauenskonstruktionen für Maschinen weiter. Genau dort entstehen später Seitwärtsbewegungen, überbreite Berechtigungen und aufwendige Ursachenanalysen im Incident.
Gerätezustand und Telemetrie müssen in den Betrieb eingebettet sein
Ein zweiter Stolperstein ist der Umgang mit Gerätezustand und Kontextsignalen. In Zero-Trust-Modellen klingt es einfach: Zugriff nur von gesunden, bekannten oder ausreichend konformen Geräten. In der Praxis ist das jedoch kein Schalter, sondern ein dauerhafter Daten- und Betriebsprozess. Das NCSC nennt Gerätezustand, Nutzerverhalten und Servicegesundheit explizit als wichtige Signale für Policy-Entscheidungen. CISA wiederum macht Sichtbarkeit und Analyse nicht zufällig zu zentralen Querschnittsfähigkeiten.
Wenn diese Signale unvollständig, verspätet oder widersprüchlich sind, kippt der Ansatz schnell in Frust. Dann werden Geräte fälschlich blockiert, Ausnahmen hektisch freigegeben oder Richtlinien generell aufgeweicht, weil der Support die Fehlersuche sonst nicht bewältigt. Ein Access-Policy-Fehler ist im Service Desk selten nur ein Security-Ticket. Er kann einen Produktionszugang, einen Dienstleistereinsatz oder eine Störung im Bereitschaftsdienst direkt ausbremsen.
Deshalb reicht es nicht, Compliance- oder EDR-Daten irgendwo zu sammeln. Relevante Zustandsinformationen müssen so in den Betriebsprozess eingebunden werden, dass Teams verstehen, warum ein Zugriff verweigert wurde, welche Bedingung fehlte und welcher Weg zur sauberen Behebung führt. Ohne diese Transparenz wird Zero Trust als willkürliche Hürde erlebt. Mit ihr wird es zu einem steuerbaren Sicherheitsmechanismus.
Ausnahmen und Supportpfade entscheiden über die Glaubwürdigkeit des Modells
Besonders oft zerfällt Zero Trust an den Rändern: bei Drittanbietern, Altgeräten, Notfällen, privilegierten Tätigkeiten oder gestörten Vertrauensketten. Genau dort zeigt sich, ob eine Organisation wirklich ein Betriebsmodell aufgebaut hat oder nur eine neue Oberfläche über alte Entscheidungen gelegt wurde. CISA weist zu Recht darauf hin, dass Zero Trust oft auch einen Kulturwandel verlangt. Gemeint ist damit nicht nur Sicherheitsbewusstsein, sondern auch die Bereitschaft, Ausnahmen sichtbar zu machen, hart zu befristen und technisch nachvollziehbar zu führen.
Ein belastbarer Ansatz braucht deshalb definierte Ausnahmewege. Wer darf in welchem Szenario von einer Standardrichtlinie abweichen? Wie wird eine temporäre Freigabe dokumentiert? Welche Zusatzüberwachung gilt in dieser Zeit? Wann endet die Ausnahme automatisch? Und wie wird verhindert, dass der Support aus Bequemlichkeit immer denselben weichen Bypass wählt? Diese Fragen sind unangenehm, aber zentral. Ohne sie wird Zero Trust im Tagesgeschäft schnell zu einem Regelwerk mit ständigem Hinterausgang.
Ebenso wichtig sind klare Supportpfade. Der First Level muss unterscheiden können, ob ein Problem an Identität, Gerät, Anwendung, Netzpfad oder Policy hängt. Plattform-, Security- und Fachteams brauchen eine gemeinsame Sprache für diese Fehlerbilder. Wenn jede Zugriffsstörung sofort als unklare Sicherheitsblockade eskaliert, wird der Druck wachsen, Richtlinien breiter und unschärfer zu machen. Gute Supportpfade sind daher kein nachgelagerter Komfort, sondern eine Stabilitätsbedingung für den gesamten Zero-Trust-Ansatz.
Wie Unternehmen pragmatisch anfangen können
Ein sinnvoller Einstieg braucht kein Big-Bang-Programm. Praktisch bewährt sich zunächst ein Zuschnitt auf wenige kritische Serviceketten statt auf das gesamte Unternehmen. Für diese Ketten sollten Teams erstens die beteiligten Nutzer, Geräte, Services und Altpfade sichtbar machen. Zweitens braucht jede Verbindung eine klar benannte Identität und einen begründeten Minimalzugriff. Drittens sollten Ausnahmen nicht informell über Tickets oder Zurufe laufen, sondern als eigener, befristeter Prozess mit Owner, Zweck und Rückbaupfad geführt werden.
Im nächsten Schritt lohnt sich eine enge Verzahnung von Security-Telemetrie und Support. Richtlinien helfen nur, wenn ihr Effekt beobachtbar bleibt: Welche Zugriffe scheitern regelmäßig? Welche Gerätesignale fehlen? Welche Altanwendungen erzeugen die meisten Sonderfälle? Welche Service-Identitäten tragen zu breite Rechte? Genau diese Daten zeigen, wo die Architektur verbessert werden muss. Sie verhindern auch, dass Zero Trust nur als Identity-Projekt missverstanden wird, obwohl es in Wahrheit Architekturpflege, Betriebsdisziplin und Ausnahmesteuerung zugleich ist.
So entsteht schrittweise ein belastbarer Rahmen. Nicht jedes Legacy-Problem lässt sich sofort lösen. Aber jedes Problem, das sichtbar gemacht, sauber befristet und in ein klareres Identitäts- und Supportmodell überführt wird, stärkt die Glaubwürdigkeit der gesamten Sicherheitsarchitektur.
Fazit
Zero Trust scheitert im Unternehmen selten daran, dass ein Zugangstool fehlt. Es scheitert häufiger an Altanwendungen, unscharfen Service-Identitäten, schlechten Ausnahmewegen und Supportprozessen ohne klare Diagnose. Wer Vertrauen aus dem Netzwerk herausnehmen will, muss deshalb deutlich mehr ordnen als nur Login und Policy Engine. Erst wenn Anwendungen, Maschinenidentitäten, Gerätesignale und Ausnahmen gemeinsam als Betriebsmodell geführt werden, wird aus Zero Trust mehr als ein Architekturversprechen.
