Wer nach einem Sicherheitsvorfall feststellen muss, dass ein kompromittiertes Konto quer durch das Netzwerk auf kritische Systeme zugreifen konnte, hat kein reines Tool-Problem. Meist fehlen belastbare Entscheidungen darüber, welche Identität unter welchen Bedingungen auf welche Ressource zugreifen darf. Eine Zero Trust Architektur implementieren heißt deshalb nicht, den Perimeter durch ein neues Produkt zu ersetzen. Es heißt, Vertrauen als Architekturannahme abzuschaffen und jeden Zugriff nachvollziehbar zu entscheiden.
Das ist strategisch relevant, weil Unternehmens-IT heute aus Cloud-Diensten, SaaS-Anwendungen, APIs, Remote-Zugängen, OT-nahen Komponenten und mehreren Identitätswelten besteht. Das klassische Modell – intern vertrauenswürdig, extern verdächtig – beschreibt diese Realität kaum noch. Zero Trust ist eine Antwort darauf, aber keine Abkürzung zu besserer Sicherheit.
Was Zero Trust in der Praxis verlangt
Zero Trust bedeutet nicht, dass niemandem vertraut wird. Gemeint ist: Ein Netzwerkstandort, eine einmalige Anmeldung oder ein verwaltetes Endgerät reichen nicht als dauerhafter Vertrauensbeweis aus. Zugriffsentscheidungen stützen sich auf mehrere aktuelle Signale: die Identität, den Zustand des Geräts, die Sensitivität der Ressource, den angeforderten Kontext und gegebenenfalls auffälliges Verhalten.
Das NIST beschreibt Zero Trust als Sicherheitsmodell, das keine implizite Vertrauenswürdigkeit aufgrund des physischen oder Netzstandorts gewährt. Diese Definition ist hilfreich, weil sie den Fokus von Produkten auf Prinzipien lenkt. Entscheidend ist die Durchsetzung möglichst nah an der geschützten Ressource und nicht die Frage, ob ein bestimmtes Label in einer Beschaffung vorkommt.
Für die Architektur ergeben sich drei Folgen. Erstens wird Identity zum zentralen Kontrollpunkt. Zweitens müssen Richtlinien technisch durchsetzbar und überprüfbar sein. Drittens wird Telemetrie zu einem Betriebsbestandteil: Ohne verlässliche Signale über Identitäten, Geräte, Zugriffe und Workloads bleiben adaptive Entscheidungen Theorie.
Zero Trust Architektur implementieren: Mit Schutzobjekten beginnen
Der häufigste Fehlstart ist ein breit angelegtes Programm mit dem Ziel, „Zero Trust einzuführen“. Das erzeugt schnell viele Teilprojekte, aber keine messbare Risikoreduktion. Besser ist ein Schutzobjekt, dessen Kompromittierung fachlich, regulatorisch oder operativ besonders schwer wiegt. Das kann ein Administrationszugang, eine Plattform für Quellcode und CI/CD, ein Kundenportal oder ein System mit besonders schützenswerten Daten sein.
Für dieses Schutzobjekt solltest du zunächst den tatsächlichen Zugriffsgraphen erheben. Welche menschlichen und technischen Identitäten greifen zu? Welche Anwendungen, APIs, Dienstkonten und Datenflüsse sind beteiligt? Aus welchen Netzen und Geräten kommen die Zugriffe? Welche Berechtigungen werden wirklich genutzt, welche bestehen nur aus historischen Gründen?
Diese Arbeit ist mühsamer als eine Produktdemo, liefert aber die Grundlage für jede sinnvolle Policy. Gerade bei privilegierten Konten und Service Identities zeigt sich oft, dass die größte Angriffsfläche nicht ein fehlender Kontrollmechanismus, sondern über Jahre gewachsene Rechtevergabe ist.
Identität vor Netzwerksegment
Multi-Faktor-Authentisierung ist ein notwendiger Anfang, aber noch keine Zero-Trust-Architektur. Entscheidend sind phishing-resistente Verfahren für besonders kritische Zugänge, ein belastbarer Lifecycle für Joiner, Mover und Leaver sowie eine klare Trennung zwischen Standard- und Administrationsidentitäten. Privilegien sollten zeitlich begrenzt, begründet und protokolliert vergeben werden.
Bei Maschinenidentitäten gilt derselbe Anspruch, wird aber oft später behandelt. Secrets in Skripten, langlebige API-Tokens und gemeinsame Service Accounts unterlaufen jede feingranulare Zugriffspolitik. Workload Identities, kurzlebige Credentials und eine nachvollziehbare Rotation sind hier meist wirkungsvoller als zusätzliche Netzwerkregeln.
Gerät und Workload als Entscheidungssignal
Ein gültiges Nutzerkonto auf einem kompromittierten oder ungepatchten Endgerät sollte nicht dieselben Rechte erhalten wie auf einem verwalteten, konformen Gerät. Dafür müssen Endpoint Management, Endpoint Detection and Response und das Identity-System zumindest relevante Zustände austauschen können. Nicht jede Anwendung braucht dabei dieselbe Strenge. Für allgemeine Kollaboration kann ein abgestufter Zugang angemessen sein, für Produktionsadministration oder kritische Daten nicht.
Bei Workloads geht es um vergleichbare Fragen: Ist die Instanz eindeutig identifizierbar? Ist ihr Laufzeitkontext bekannt? Darf dieser Dienst tatsächlich mit jener Datenbank oder API kommunizieren? Segmentierung bleibt wichtig, aber sie sollte sich an Anwendungen und Datenflüssen orientieren, nicht nur an IP-Adressräumen. Mikrosegmentierung kann sinnvoll sein, erhöht jedoch Komplexität bei Betrieb, Fehlersuche und Change Management. Sie ist dort am stärksten, wo klare Kommunikationsmuster existieren.
Policies als Produkt der Fachlichkeit und des Betriebs
Zero Trust wird oft als Projekt der Security betrachtet. Tatsächlich berührt es Verantwortlichkeiten in Infrastruktur, Workplace, Cloud Platform, IAM, Entwicklung, Datenschutz und Fachbereichen. Eine Policy wie „Produktionsdaten nur für berechtigte Rollen auf konformen Geräten“ klingt einfach. Ihre Umsetzung verlangt aber Antworten auf Details: Was gilt als konform? Wer verantwortet Ausnahmen? Was passiert bei einem EDR-Ausfall? Wie arbeiten externe Dienstleister, Notfallteams oder Systeme ohne modernen Client?
Solche Fragen sind kein Grund, das Vorhaben zu vertagen. Sie sind der Kern der Architekturarbeit. Jede Ausnahme braucht einen Eigentümer, eine Begründung, ein Ablaufdatum und eine überprüfbare Kompensation. Sonst entsteht neben der neuen Architektur eine dauerhafte Schattenlandschaft aus Umgehungen.
Für kritische Policies empfiehlt sich ein kontrollierter Modus vor der harten Durchsetzung. Beobachte, welche legitimen Zugriffe eine Regel blockieren würde, und überprüfe die Datenqualität der verwendeten Signale. Ein falscher Gerätestatus oder eine unvollständige Gruppenmitgliedschaft kann den Betrieb stärker treffen als eine fehlende Regel. Security und Verfügbarkeit müssen deshalb gemeinsam als Qualitätskriterien gelten.
Telemetrie macht Entscheidungen prüfbar
Eine Architektur, die Zugriffe dynamisch bewertet, braucht nachvollziehbare Ereignisdaten. Dazu gehören mindestens Authentisierungen, Berechtigungsänderungen, Gerätebewertungen, administrative Aktionen, Workload-Zugriffe und Policy-Entscheidungen. Zentralisierung allein genügt nicht. Die Daten müssen zeitlich korrelierbar, ausreichend lange verfügbar und für Incident Response nutzbar sein.
Dabei entsteht ein echter Zielkonflikt. Je mehr Kontextdaten in Zugriffsentscheidungen einfließen, desto höher sind Integrationsaufwand, Kosten und Anforderungen an Datenschutz sowie Betriebsmodell. Nicht jedes Risikosignal muss in Echtzeit eine Anmeldung blockieren. Für manche Systeme reicht es, Anomalien nachgelagert zu untersuchen. Bei privilegierten Zugängen kann dagegen eine unmittelbare Schritt-up-Authentisierung oder Sperre angemessen sein.
Definiere daher vorab, woran Fortschritt erkennbar wird. Sinnvolle Kennzahlen sind etwa der Anteil phishing-resistent abgesicherter Admin-Zugänge, die Zahl dauerhaft privilegierter Konten, die Abdeckung verwalteter Geräte bei kritischen Anwendungen oder die Zeit bis zur Sperrung einer kompromittierten Identität. Solche Kennzahlen verbinden Architekturentscheidungen mit Risiko, statt bloß den Rollout einzelner Komponenten zu messen.
Architekturmodernisierung statt Big Bang
Die Reihenfolge hängt von deiner Ausgangslage ab. Unternehmen mit schwachem Identity Lifecycle profitieren meist stärker von IAM- und Privileged-Access-Verbesserungen als von einer sofortigen Netzwerkmikrosegmentierung. In Cloud-nativen Umgebungen können Workload Identities, Secret Management und CI/CD-Schutz den größeren Hebel bieten. Wer viele Legacy-Anwendungen betreibt, muss häufig zunächst mit Zugangsgateways, stärkerer Protokollierung und klar begrenzten Ausnahmen arbeiten.
Ein Big Bang ist selten sinnvoll. Zu viele Abhängigkeiten, unklare Berechtigungen und Sonderfälle werden erst sichtbar, wenn Policies wirksam werden. Plane daher in wiederholbaren Wellen: Schutzobjekt auswählen, Zugriffe verstehen, Zielpolicy festlegen, im Beobachtungsmodus validieren, kontrolliert durchsetzen und die Wirkung messen. Das schafft einen Lernzyklus, der sowohl für das Security-Team als auch für Betrieb und Fachbereiche tragfähig ist.
Auch die Governance gehört in diesen Zyklus. Zero Trust verändert, wer Zugriffsentscheidungen vorbereitet, genehmigt und verantwortet. Der CISO braucht dafür ein klares Risikobild, der CIO ein belastbares Betriebs- und Investitionsmodell, und Architekten brauchen verbindliche Muster für neue Anwendungen. Ohne diese gemeinsame Sprache wird Zero Trust zur Sammlung lokaler Sicherheitsmaßnahmen.
Der hilfreiche nächste Schritt ist deshalb nicht die Suche nach einer vollständigen Zielplattform. Nimm einen Zugang, bei dem Identität, Berechtigung und Schutzbedarf heute erkennbar auseinanderfallen. Wenn du dort eine nachvollziehbare, überprüfbare und betrieblich tragfähige Zugriffspolitik etablierst, entsteht aus einem Sicherheitsprinzip schrittweise eine belastbare Architektur.
