Zero Trust scheitert selten daran, dass niemand das Prinzip versteht. Die Schwierigkeiten beginnen dort, wo ein abstraktes Ziel in konkrete Anwendungen, Nutzergruppen, Geräte, Richtlinien und Betriebsrollen übersetzt werden muss.
Wer zu früh mit einer Produktkonfiguration startet, bildet häufig die alte Netzwerklogik in einer neuen Plattform nach. Wer zu lange an einem vollständigen Zielbild arbeitet, erzeugt ein Architekturprogramm ohne sichtbare Wirkung. Der wirksame Weg liegt dazwischen: eine belastbare Discovery, ein begrenztes Zielbild, ein repräsentativer Pilot und eine Betriebsübergabe, die von Anfang an mitgeplant wird.
NIST beschreibt Zero Trust als Fokus auf Ressourcen statt auf implizites Vertrauen durch Netzwerkstandort oder Besitz. Für ein Unternehmen bedeutet das: Nicht „im internen Netz“ entscheidet über Zugriff, sondern Identität, Gerät, Anwendung, Kontext und Policy.
Phase 1: Die Discovery beginnt bei Geschäftswegen
Eine gute Discovery ist keine vollständige Inventur jedes Ports. Sie identifiziert zuerst die Geschäftswege, deren Schutz oder Vereinfachung den größten Nutzen bringt.
Für jeden Weg werden mindestens erfasst:
- Nutzer- oder Dienstidentität,
- verwendetes Gerät und Verwaltungsstatus,
- Zielanwendung und fachlicher Owner,
- heutiger Zugriffsweg,
- bestehende Authentisierung,
- Daten- und Schutzbedarf,
- Abhängigkeiten wie DNS, Zertifikate oder feste IP-Adressen,
- bekannte Ausnahmen und Betriebsprobleme.
Besonders wertvoll sind repräsentative Fälle: Standard-SaaS, private Webanwendung, Legacy-Client, externer Dienstleister, administrativer Zugriff und ein Standort mit agentenlosen Geräten.
Phase 2: Das Zielbild beschreibt Entscheidungen
Ein Architekturdiagramm allein reicht nicht. Das Zielbild muss erklären, welche Entscheidung an welcher Stelle getroffen wird.
Für Zscaler-Umgebungen betrifft das beispielsweise:
- Welche Verkehre laufen über ZIA?
- Welche privaten Anwendungen werden über ZPA bereitgestellt?
- Welche Gerätezustände beeinflussen den Zugriff?
- Wo wird SSL/TLS inspiziert und wo gibt es begründete Ausnahmen?
- Welche Identitätsquelle liefert Gruppen und Attribute?
- Welche Standorte oder Workloads benötigen Connectoren?
- Welche Protokolle oder Legacy-Systeme brauchen einen Übergangspfad?
Jede Entscheidung erhält einen Owner, eine Begründung und einen Testfall. Dadurch wird das Zielbild prüfbar.
Phase 3: Policies nach Risiko statt nach Historie
Alte Regeln sind häufig nach Netzwerksegmenten, Standorten oder gewachsenen Gruppen organisiert. Eine Zero-Trust-Policy sollte näher an Anwendung und Zweck rücken.
Ein praktikables Policy-Modell beginnt mit wenigen klaren Klassen:
- Standardzugriff für verwaltete Nutzer und Geräte,
- erhöhte Anforderungen für sensible Anwendungen,
- begrenzte Wege für externe Partner,
- separate administrative Zugriffe,
- Remediation für nicht konforme Geräte,
- explizite Behandlung von agentenlosen Systemen.
Komplexität entsteht nicht durch zu wenig Regeln, sondern durch zu viele unklare Ausnahmen. Deshalb sollten Policy-Owner und Review-Datum schon beim Design feststehen.
Phase 4: Der Pilot muss echte Reibung enthalten
Ein Pilot nur mit IT-Nutzern und modernen Webanwendungen beweist wenig. Er sollte typische Problemstellen enthalten, ohne das Unternehmen unnötig zu gefährden.
Eine gute Pilotgruppe deckt unterschiedliche Geräte, Standorte und Anwendungen ab. Sie testet positive und negative Fälle: erlaubter Zugriff, fehlender Gerätezustand, abgelaufenes Zertifikat, nicht erreichbarer Connector, falsche Identitätsgruppe und begründete Ausnahme.
Messpunkte sind:
- erfolgreiche und fehlgeschlagene Zugriffe,
- zusätzliche Latenz und Nutzererfahrung,
- Zeit bis zur Diagnose,
- Zahl und Ursache notwendiger Ausnahmen,
- Qualität von Logs und Supportinformationen,
- Aufwand für Rollback und Wiederholung.
Phase 5: Migration in Wellen
Zero Trust ist selten ein Big Bang. NIST weist ausdrücklich darauf hin, dass klassische Perimeter- und Zero-Trust-Komponenten während einer Übergangszeit parallel bestehen können.
Sinnvolle Wellen orientieren sich an Risiko und Wiederholbarkeit:
- Standard-SaaS und klar verwaltete Nutzer,
- ausgewählte private Anwendungen,
- externe und privilegierte Zugriffe,
- Standorte und agentenlose Geräte,
- Legacy- und Sonderprotokolle.
Jede Welle hat Eingangskriterien, Testfälle, Rückfallweg und Abschlussnachweis. Dadurch wird Migration zu einem kontrollierten Prozess statt zu einer Reihe spontaner Umschaltungen.
Phase 6: Betrieb ist kein Abschlusskapitel
Schon während des Piloten muss klar sein, wer später Tickets qualifiziert, Policies ändert, Ausnahmen genehmigt und Herstellerfälle eskaliert.
Die Betriebsübergabe enthält:
- Rollen- und Berechtigungskonzept,
- Runbooks für häufige Störungen,
- Change- und Freigabeprozess,
- Monitoring und Reporting,
- Liste kritischer Abhängigkeiten,
- offene Risiken und technische Schulden,
- regelmäßigen Review von Ausnahmen und Policies.
Wenn diese Dinge erst nach dem Rollout entstehen, bleibt das Projektteam dauerhaft der eigentliche Betrieb.
Drei Ergebnisse, die eine gute Roadmap liefern muss
Eine belastbare Zero-Trust-Roadmap produziert nicht nur eine Reihenfolge von Produkten. Sie liefert:
Ein priorisiertes Anwendungs- und Datenflussbild. Das Unternehmen weiß, welche Wege zuerst verändert werden und warum.
Eine testbare Zielarchitektur. Policies, Identitäten, Geräte, Connectoren und Ausnahmen sind konkreten Entscheidungen zugeordnet.
Ein Betriebsmodell. Helpdesk, Security, Plattformteam und Partner kennen Aufgaben, Freigaben und Eskalationen.
So bleibt Zero Trust nicht auf Folien. Es wird zu einer Architektur, die Nutzer verstehen, Teams betreiben und Verantwortliche weiterentwickeln können.