Zero Trust ohne Buzzwords

Warum das klassische Perimeter-Modell nicht mehr reicht

Mitarbeitende arbeiten mobil, Anwendungen liegen in der Cloud und externe Partner greifen auf Daten zu. Die Grenze zwischen innen und außen existiert faktisch nicht mehr. Angreifer nutzen genau das: Ein kompromittiertes Konto reicht oft, um sich unbemerkt weiter zu bewegen.

Historisch beruhte Informationssicherheit darauf, Werte zu sammeln und mit einem kontrollierten Perimeter zu umgeben. Nutzer galten als vertrauenswürdig, weil sie sich innerhalb dieses Perimeters befanden. Genau diese Annahme kehrt Zero Trust um: Vertrauen entsteht nicht aus dem Standort, sondern aus einer Prüfung, die für jeden Zugriff erneut stattfindet.

Was Zero Trust anders macht

Fünf Merkmale unterscheiden den Ansatz von klassischen Sicherheitsmodellen. Sie klingen unspektakulär, verändern aber die Reihenfolge, in der man Sicherheit plant.

• Von innen nach außen denken: Ausgangspunkt sind der Wert der Daten und die notwendigen Zugriffsrechte – nicht die Netzgrenze.
• Prüfen, bevor vertraut wird – bei jedem Zugriff, nicht einmalig bei der Anmeldung am Morgen.
• Geringere Abhängigkeit von einem physischen Perimeter, weil Schutz an Identität, Gerät und Anwendung wandert.
• Zugriffsentscheidungen sind risikobasiert statt binär: Derselbe Nutzer kann in unterschiedlichen Situationen unterschiedlich viel dürfen.
• Vertrauensentscheidungen fußen auf Identität – der Identität von Menschen, Geräten, Diensten und Workloads.

Die drei Grundsätze im Alltag

Zero Trust ist kein Produkt, sondern ein Betriebsprinzip. Im Microsoft-Umfeld lässt es sich mit vorhandenen Werkzeugen schrittweise umsetzen.

• Explizit prüfen: Mehrfaktor-Authentifizierung und Conditional Access bewerten jede Anmeldung im Kontext.
• Minimale Rechte: Administrative Rollen werden mit Privileged Identity Management nur zeitlich begrenzt aktiviert.
• Von einer Kompromittierung ausgehen: Protokollierung, Erkennung und Segmentierung begrenzen den möglichen Schaden.

Leitprinzipien, die über Erfolg und Scheitern entscheiden

Die Cloud Security Alliance hat aus vielen Umsetzungen eine Reihe von Leitprinzipien abgeleitet. Sie sind bewusst technikfrei formuliert – und erklären erfahrungsgemäß besser als jede Produktliste, warum Initiativen gelingen oder versanden.

• Mit dem Ziel beginnen: Erst das Geschäftsziel, dann die Technik. Ohne klares Schutzziel wird jede Maßnahme beliebig.
• Nicht überkomplizieren: Zero Trust beruht auf altbekannten Prinzipien – geringste Rechte, Funktionstrennung, Segmentierung.
• Produkte sind nicht die Priorität: Werkzeuge unterstützen eine Strategie, sie ersetzen sie nicht.
• Zugriff ist eine bewusste Entscheidung: Jede Berechtigung wird absichtlich erteilt, dokumentiert und wieder entzogen.
• Von innen nach außen: Schutzwürdige Daten und Prozesse definieren die Architektur, nicht das Netzdiagramm.
• Sicherheitsvorfälle passieren: Ziel ist es, den Schadensradius klein zu halten und schnell wieder handlungsfähig zu sein.
• Risikobereitschaft kennen: Ohne Einigkeit darüber, welches Restrisiko akzeptabel ist, gibt es keine tragfähigen Regeln.
• Haltung von oben: Ohne sichtbare Unterstützung der Leitungsebene bleibt Zero Trust ein IT-Thema.
• Kultur aufbauen: Sicherheit muss im Alltag praktikabel sein, sonst wird sie umgangen.
• Klein starten, schnelle Erfolge suchen: Sichtbare Fortschritte finanzieren die nächsten Schritte.
• Kontinuierlich überwachen: Was nicht beobachtet wird, lässt sich weder bewerten noch verbessern.

Neun Annahmen, die man loslassen muss

Zero Trust wird greifbarer, wenn man benennt, wem man bislang stillschweigend vertraut hat. Die folgenden Punkte sind keine Panikmache, sondern Prüffragen für die eigene Architektur.

• Kein Vertrauen in ein Netz – auch nicht in das eigene Firmennetz.
• Kein Vertrauen in den Transportweg über das Internet; Verschlüsselung und Authentifizierung gehören in die Anwendung.
• Kein Vertrauen in Rechtsräume: Wo Daten liegen und verarbeitet werden, ist eine bewusste Entscheidung.
• Kein Vertrauen in fremde Hardware und fremden Code, inklusive Bibliotheken und Lieferkette.
• Kein Vertrauen in die Entwicklungs- und Deployment-Kette ohne Prüfung und Nachvollziehbarkeit.
• Kein blindes Vertrauen in Administratoren – eigene wie die des Dienstleisters. Deshalb Vier-Augen-Prinzip und zeitlich begrenzte Rechte.
• Kein Vertrauen in den Standort eines Servers oder dessen physische Absicherung allein.
• Kein Vertrauen in das Endgerät ohne belegten Zustand: Verwaltung, Patchstand, Verschlüsselung, Bedrohungsschutz.
• Kein Vertrauen in ein Identitätssystem ohne Prüfung, wie Konten entstehen, verifiziert und wieder entzogen werden.

Architektur: die Bausteine einer Zugriffsentscheidung

Technisch läuft jede Zero-Trust-Entscheidung auf dasselbe Muster hinaus: Eine Stelle entscheidet, eine andere setzt durch. In modernen Architekturen – etwa beim Software-Defined Perimeter – wird der Zugang zu einer Anwendung erst nach erfolgreicher Prüfung aufgebaut; vorher ist die Anwendung für den Anfragenden praktisch unsichtbar.

Das erklärt, warum ein VPN kein Zero Trust ist: Es verbindet ein Gerät mit einem Netz, statt einen geprüften Nutzer mit einer einzelnen Anwendung.

• Entscheidungspunkt: bewertet Identität, Gerätezustand, Ort, Uhrzeit, Verhalten und Risiko gegen die Richtlinie.
• Durchsetzungspunkt: lässt die Verbindung zu, fordert eine weitere Prüfung oder blockiert.
• Signalquellen: Identitätsschutz, Geräteverwaltung, Bedrohungserkennung, Datenklassifizierung.
• Segmentierung: pro Anwendung statt pro Netz, damit ein Vorfall nicht das ganze Netz erreicht.
• Protokollierung: jede Entscheidung nachvollziehbar, damit Betrieb und Audit dieselbe Sicht haben.

Von der Theorie in die Microsoft-Praxis

In einer Microsoft-365- und Azure-Umgebung existieren die meisten Bausteine bereits. Der Aufwand liegt seltener in der Lizenz als in Konfiguration, Bereinigung und Betrieb.

• Identität: Entra ID mit phishingresistenter Mehrfaktor-Authentifizierung, Conditional Access, Identity Protection.
• Privilegierte Zugriffe: Privileged Identity Management mit Genehmigung, Befristung und Protokoll.
• Geräte: Intune-Compliance als Bedingung für den Zugriff, nicht nur als Inventar.
• Daten: Purview für Klassifizierung, Sensitivity Labels und Data Loss Prevention.
• Erkennung und Reaktion: Defender XDR und Sentinel mit definierten Alarmen und Zuständigkeiten.
• Anwendungen: Zugriff pro Anwendung veröffentlichen statt Netzzugang per VPN gewähren.

Womit sinnvoll starten?

Der größte Hebel liegt fast immer bei den Identitäten. Eine saubere Bestandsaufnahme von Konten, Rollen und Ausnahmen, gefolgt von Conditional Access im Report-only-Modus, schafft schnell Transparenz – ohne den Betrieb zu unterbrechen. Danach folgen Geräte-Compliance mit Intune und der Schutz sensibler Daten.

Ein realistischer Fahrplan über zwölf Monate

Der folgende Ablauf hat sich im Mittelstand bewährt. Entscheidend ist nicht die Geschwindigkeit, sondern dass jeder Schritt im Betrieb ankommt, bevor der nächste beginnt.

• Phase 1 – Klarheit: Schutzwürdige Daten und kritische Prozesse benennen, Konten, Rollen und Ausnahmen inventarisieren.
• Phase 2 – Fundament: Mehrfaktor-Authentifizierung flächendeckend, Notfallkonten definieren, Conditional Access im Report-only-Modus beobachten.
• Phase 3 – Durchsetzen: Richtlinien pilotieren, dann stufenweise aktivieren; Administratorrechte auf befristete Aktivierung umstellen.
• Phase 4 – Geräte: Compliance-Anforderungen definieren und als Zugriffsbedingung verankern.
• Phase 5 – Daten: Klassifizierung einführen, Oversharing bereinigen, DLP dort einsetzen, wo es wirklich trägt.
• Phase 6 – Betrieb: Erkennung, Alarmierung und Wiederherstellung üben; Ausnahmen mit Ablaufdatum versehen und regelmäßig prüfen.

Den Nutzen gegenüber der Geschäftsführung begründen

Zero Trust scheitert selten an der Technik, häufig an der Finanzierung. Wer nur über Angriffe spricht, bekommt ein Sicherheitsbudget; wer über Geschäftsfähigkeit spricht, bekommt eine Strategie. Diese Argumente lassen sich in fast jeder Organisation belegen.

• Geringere Folgekosten von Vorfällen, weil der Schadensradius begrenzt ist.
• Höhere Betriebsstabilität und schnellere Wiederherstellung nach Störungen.
• Mehr Handlungsfähigkeit: Zukäufe, Standorte und Partner lassen sich schneller anbinden.
• Einfachere Nachweise gegenüber Kunden, Prüfern und Behörden – etwa im Rahmen von NIS2 oder ISO 27001.
• Sicherer Einsatz neuer Technologien, inklusive KI-Werkzeugen wie Microsoft 365 Copilot.
• Bessere Nutzung vorhandener Investitionen statt zusätzlicher Speziallösungen.
• Weniger Reibung für Mitarbeitende, wenn Anmeldungen risikobasiert statt pauschal streng sind.

Woran man Fortschritt erkennt

Ohne Messgrößen bleibt Zero Trust Gefühlssache. Diese Kennzahlen sind mit vorhandenen Mitteln erhebbar und taugen für ein Reporting an die Leitungsebene.

• Anteil der Anmeldungen mit phishingresistenter Mehrfaktor-Authentifizierung.
• Anzahl dauerhaft privilegierter Konten – Ziel ist eine sinkende Kurve.
• Anteil der Zugriffe von verwalteten und konformen Geräten.
• Anzahl offener Ausnahmen und deren Alter.
• Zeit von der Auffälligkeit bis zur Reaktion.
• Anteil klassifizierter Dokumente in den schutzbedürftigen Bereichen.

Typische Fehler

Häufig werden Richtlinien ohne Pilotphase aktiviert, Notfallkonten vergessen oder Ausnahmen nie wieder überprüft. Zero Trust gelingt, wenn Regeln dokumentiert, getestet und regelmäßig nachgeschärft werden.

• Ein Produkt kaufen und es Zero Trust nennen, ohne Richtlinien und Zuständigkeiten zu klären.
• Alles gleichzeitig angehen, statt mit den wertvollsten Daten und den größten Risiken zu beginnen.
• Nur Mitarbeitende betrachten und Dienstkonten, Automatisierungen und Dienstleisterzugänge vergessen.
• Ausnahmen ohne Ablaufdatum und ohne Eigentümer einrichten.
• Protokolle sammeln, die niemand auswertet, und daraus Sicherheit ableiten.
• Mitarbeitende nicht einbeziehen – unpraktikable Regeln werden zuverlässig umgangen.

Fazit

Zero Trust ist unspektakulärer, als der Begriff vermuten lässt: bekannte Sicherheitsprinzipien, konsequent auf eine Welt ohne Netzgrenze angewendet. Der Weg dorthin ist keine Großinvestition, sondern eine Folge kleiner, überprüfbarer Entscheidungen – beginnend bei den Identitäten, getragen von der Leitungsebene und messbar im Betrieb.

Quellen und weiterführende Literatur

Die strategischen Leitprinzipien und Argumentationslinien dieses Beitrags orientieren sich an den herstellerneutralen Veröffentlichungen der Cloud Security Alliance. Sie sind frei verfügbar und als Einstieg empfehlenswert.

• Cloud Security Alliance: Zero Trust as a Security Philosophy (2023)
• Cloud Security Alliance: Zero Trust Guiding Principles (2023)
• Cloud Security Alliance: Communicating the Business Value of Zero Trust (2023)
• Cloud Security Alliance: CCZT – Certificate of Competence in Zero Trust, Studienunterlagen zu Architektur und Software-Defined Perimeter (2025)
• NIST SP 800-207: Zero Trust Architecture