Zero Trust in Microsoft 365:
Warum Identität wichtiger wird als die Firewall

Warum Identität wichtiger wird als die Firewall

Zero Trust wird häufig als Netzwerkthema verstanden. Früher war die zentrale Sicherheitsfrage oft, ob ein Zugriff von innen oder außen kommt. Diese Grenze ist heute weniger eindeutig.

Benutzer arbeiten von verschiedenen Standorten, Geräte wechseln zwischen Büro, Homeoffice und unterwegs, Anwendungen liegen in Microsoft 365, Azure und anderen SaaS-Plattformen. Die klassische Firewall bleibt wichtig, ist aber nicht mehr die alleinige Sicherheitsgrenze.

In Microsoft-365-Umgebungen verschiebt sich die entscheidende Kontrolle zur Identität und zum Gerät. Geprüft wird nicht nur, von wo jemand zugreift, sondern wer zugreift, welches Gerät verwendet wird, welches Risiko besteht und welche Bedingungen erfüllt sein müssen.

Microsoft beschreibt Zero Trust Identity and Device Access als Ansatz mit Microsoft Entra ID, Conditional Access, Microsoft Intune und weiteren Sicherheitsfunktionen. Die Grundlage ist nicht ein einzelnes Produkt, sondern eine Reihe von Richtlinien für Identitäten, Geräte und Anwendungen: Zero Trust Identity and Device Access Configurations.

Was Zero Trust praktisch bedeutet

Zero Trust bedeutet nicht, jedem Zugriff grundsätzlich zu misstrauen und Arbeit unnötig zu erschweren. Es bedeutet, Zugriffe explizit zu prüfen und Bedingungen technisch durchzusetzen.

Die drei bekannten Prinzipien lauten:

• explizit überprüfen

• geringstmögliche Berechtigungen verwenden

• von einem möglichen Sicherheitsvorfall ausgehen

Für Microsoft 365 heißt das konkret: Ein Benutzer bekommt nicht automatisch Zugriff, nur weil Benutzername und Passwort stimmen. Der Zugriff kann zusätzlich von weiteren Faktoren abhängen, zum Beispiel:

• Benutzer oder Rolle

• Anwendung

• Standort

• Risiko der Anmeldung

• Gerätestatus

• Gerätekonformität

• Authentifizierungsstärke

• Session-Bedingungen

Damit wird Identität zur zentralen Steuerungsstelle für Sicherheit.

Conditional Access als zentrale Policy Engine

In Microsoft-Umgebungen ist Conditional Access der zentrale Ort, an dem Zugriffsbedingungen definiert werden.

Microsoft beschreibt Conditional Access als „Zero Trust Policy Engine“. Richtlinien kombinieren Signale wie Benutzer, Gerät und Standort und treffen daraus Entscheidungen für den Zugriff: Microsoft Entra Conditional Access.

Ein einfaches Beispiel:

Wenn ein Benutzer auf Microsoft 365 zugreifen möchte, muss er eine Mehrfaktor-Authentifizierung durchführen.

Ein erweitertes Beispiel:

Wenn ein Benutzer außerhalb eines vertrauenswürdigen Standorts auf SharePoint zugreift, muss das Gerät compliant sein und MFA erfüllen. Ist das Risiko der Anmeldung hoch, wird der Zugriff blockiert oder eine zusätzliche Prüfung verlangt.

Conditional Access arbeitet damit nach einer Wenn-dann-Logik:

• Wenn ein bestimmter Benutzer auf eine bestimmte Anwendung zugreift,

• und bestimmte Bedingungen erfüllt oder nicht erfüllt sind,

• dann wird Zugriff erlaubt, blockiert oder nur unter zusätzlichen Anforderungen gewährt.

Das macht Conditional Access zu einem Architekturthema. Es geht nicht nur darum, einzelne Richtlinien zu aktivieren. Es geht darum, ein nachvollziehbares Zugriffsmodell für den gesamten Tenant zu definieren.

Maßnahme 1: MFA als Standard

Mehrfaktor-Authentifizierung ist eine der wichtigsten Grundlagen für Zero Trust in Microsoft 365.

Passwörter allein reichen nicht aus. Sie können wiederverwendet, erraten, gestohlen oder über Phishing abgefangen werden. MFA reduziert dieses Risiko, weil für den Zugriff ein zusätzlicher Faktor erforderlich ist.

Microsoft empfiehlt in den allgemeinen Zero-Trust-Sicherheitsrichtlinien für Microsoft 365 eine Baseline-Policy für MFA und beschreibt MFA als Teil der empfohlenen Schutzebenen: Common security policies for Microsoft 365 organizations.

Wichtig ist aber die Art der Umsetzung. MFA sollte nicht nur für einzelne Benutzer manuell aktiviert werden. Sinnvoller ist eine klare Conditional-Access-Strategie:

• MFA für alle Benutzer als Grundschutz

• stärkere Anforderungen für privilegierte Rollen

• risikobasierte MFA bei auffälligen Anmeldungen

• klare Ausnahmeprozesse

• dokumentierte Break-Glass-Konten

• keine dauerhaften Sonderregeln ohne Review

MFA ist damit kein isolierter Schalter, sondern Teil des Zugriffsmodells.

Maßnahme 2: Veraltete Anmeldeverfahren blockieren

Ein besonders wichtiger Punkt ist das Blockieren veralteter Anmeldeverfahren.

Legacy Authentication umfasst ältere Protokolle und Clients, die moderne Sicherheitsmechanismen nicht ausreichend unterstützen. Dazu können ältere Office-Clients oder Protokolle wie IMAP, POP3 oder SMTP gehören.

Microsoft empfiehlt, Legacy Authentication mit Conditional Access zu blockieren. Der Grund: Solche Protokolle unterstützen keine moderne Mehrfaktor-Authentifizierung und können Conditional-Access-Kontrollen umgehen. Microsoft beschreibt den Prozess hier: Block legacy authentication with Conditional Access.

Für die Praxis ist das relevant, weil veraltete Anmeldeverfahren häufig unbemerkt aktiv bleiben. Sie werden vielleicht nur noch von alten Anwendungen, Scannern, Skripten oder Spezialpostfächern genutzt. Genau deshalb sollten sie nicht blind abgeschaltet werden.

Eine sinnvolle Vorgehensweise ist:

• Legacy-Authentication-Nutzung auswerten

• betroffene Benutzer, Geräte oder Anwendungen identifizieren

• technische Alternativen prüfen

• Richtlinie im Report-only Mode testen

• Auswirkungen bewerten

• Ausnahmen dokumentieren oder entfernen

• Richtlinie stufenweise aktivieren

Die Frage lautet nicht nur, ob Legacy Authentication erlaubt ist. Die Frage lautet, ob bekannt ist, wer sie noch nutzt und warum.

Maßnahme 3: Zugriff nur von verwalteten oder compliant Geräten

Zero Trust betrachtet nicht nur den Benutzer, sondern auch das Gerät.

Ein Benutzer mit korrekter Identität kann trotzdem ein Risiko darstellen, wenn der Zugriff von einem unbekannten, nicht verwalteten oder kompromittierten Gerät erfolgt. Deshalb ist Gerätekonformität ein wichtiger Bestandteil von Conditional Access.

Microsoft beschreibt, dass Intune Geräte-Compliance und App-Management-Daten als Signale für Conditional-Access-Entscheidungen liefern kann: Learn about Conditional Access and Intune.

In der Praxis kann eine Richtlinie zum Beispiel verlangen, dass ein Gerät compliant sein muss, bevor Zugriff auf Microsoft-365-Dienste gewährt wird. Microsoft dokumentiert dafür eigene Richtlinienbeispiele: Require device compliance with Conditional Access.

Typische Compliance-Anforderungen sind:

• Gerät ist in Intune registriert

• Betriebssystem erfüllt Mindestversionen

• Verschlüsselung ist aktiv

• Geräteschutz ist aktiviert

• Sicherheitsrichtlinien werden eingehalten

• Gerät ist nicht als kompromittiert markiert

Auch hier gilt: Die technische Richtlinie ist nur ein Teil der Lösung. Vorher muss klar sein, welche Geräte verwaltet werden, welche BYOD-Szenarien erlaubt sind und welche Anwendungen besonders geschützt werden müssen.

Warum der Rollout sorgfältig geplant werden muss

Conditional Access kann Benutzer wirksam schützen. Es kann Benutzer aber auch aussperren, wenn Regeln zu breit greifen oder Abhängigkeiten nicht berücksichtigt werden.

Microsoft weist in der Planungsdokumentation ausdrücklich darauf hin, dass Conditional Access sorgfältig geplant werden muss, weil die hohe Flexibilität unerwünschte Ergebnisse verursachen kann: Plan a Conditional Access deployment.

Eine neue Richtlinie sollte deshalb nicht sofort tenantweit aktiv geschaltet werden. In vielen Fällen ist der Report-only Mode der richtige erste Schritt. Damit lässt sich prüfen, welche Anmeldungen betroffen wären, ohne den Zugriff direkt zu blockieren.

Microsoft empfiehlt diesen Ansatz auch beim Blockieren von Legacy Authentication: Die Richtlinie wird zunächst im Report-only Mode erstellt, damit Administratoren die Auswirkungen auf bestehende Benutzer bewerten können.

Ein sauberer Rollout umfasst:

• Ziel und Scope der Richtlinie definieren

• betroffene Benutzergruppen festlegen

• Testgruppen verwenden

• Report-only Mode nutzen

• Sign-in Logs auswerten

• Auswirkungen auf Geräte und Anwendungen prüfen

• Kommunikation an Benutzer vorbereiten

• Ausnahmen dokumentieren

• Richtlinie schrittweise aktivieren

• regelmäßige Reviews durchführen

Conditional Access ist kein Bereich für spontane Änderungen. Jede Richtlinie kann produktive Arbeit beeinflussen.

Notfallzugänge bewusst ausnehmen

Ein wichtiger Punkt sind Emergency-Access-Accounts, auch Break-Glass-Konten genannt.

Diese Konten dienen dazu, im Notfall weiterhin administrativen Zugriff auf den Tenant zu ermöglichen. Microsoft empfiehlt, Emergency-Access-Accounts von Conditional-Access-Richtlinien auszunehmen, die Anmeldungen blockieren oder einschränken. Andernfalls können genau diese Konten im Notfall unbrauchbar werden: Manage emergency access accounts in Microsoft Entra ID.

Das bedeutet nicht, dass solche Konten ungeschützt bleiben sollten. Im Gegenteil. Sie müssen besonders streng abgesichert, überwacht und regelmäßig getestet werden.

Wichtige Anforderungen sind:

• mindestens zwei Notfallkonten

• cloudbasierte Konten ohne Abhängigkeit von lokaler Föderation

• starke, phishingresistente Authentifizierung

• sichere Verwahrung der Zugangsmittel

• Monitoring jeder Anmeldung

• regelmäßige Funktionstests

• klare Dokumentation, wer diese Konten nutzen darf

Break-Glass-Konten sind kein Komfortweg für Administratoren. Sie sind ein kontrollierter Notfallmechanismus.

Typische Fehler bei Conditional Access

In gewachsenen Microsoft-365-Tenants entstehen häufig ähnliche Probleme:

• MFA ist nur für einzelne Benutzer aktiv

• Legacy Authentication ist noch erlaubt

• Ausnahmen sind nicht dokumentiert

• globale Administratoren sind zu breit geschützt oder zu wenig geschützt

• Richtlinien überschneiden sich

• Testmodus wurde übersprungen

• Break-Glass-Konten fehlen

• Geräte-Compliance ist nicht sauber definiert

• BYOD-Szenarien sind nicht geklärt

• alte Anwendungen werden nicht berücksichtigt

Viele dieser Probleme entstehen nicht durch fehlende Technik. Sie entstehen durch fehlende Architektur.

Conditional Access ist nur dann wirksam, wenn die Richtlinien ein klares Zielbild abbilden.

Prüffragen für den eigenen Tenant

Eine erste Bewertung kann mit diesen Fragen beginnen:

• Welche Conditional-Access-Richtlinien sind aktuell aktiv?

• Gibt es Richtlinien im Report-only Mode?

• Ist MFA für alle Benutzer geregelt?

• Welche Rollen haben stärkere Anforderungen?

• Sind Legacy-Authentication-Anmeldungen noch erlaubt?

• Welche Anwendungen oder Geräte nutzen noch alte Protokolle?

• Gibt es Conditional-Access-Ausnahmen?

• Sind diese Ausnahmen dokumentiert und zeitlich begrenzt?

• Werden nur compliant oder verwaltete Geräte für kritische Anwendungen zugelassen?

• Gibt es funktionierende Emergency-Access-Accounts?

• Werden Sign-in Logs regelmäßig geprüft?

• Ist das Zugriffsmodell dokumentiert?

Wenn diese Fragen nicht eindeutig beantwortet werden können, ist Conditional Access wahrscheinlich eher historisch gewachsen als bewusst entworfen.

Fazit

Zero Trust ist kein Produkt, das gekauft und aktiviert wird. Es ist ein Sicherheitsmodell, das in konkrete Entscheidungen übersetzt werden muss.

In Microsoft-365-Umgebungen beginnt diese Umsetzung häufig bei Identität und Geräten. Conditional Access ist dabei die zentrale Stelle, an der Zugriffsbedingungen definiert und technisch durchgesetzt werden.

Drei Maßnahmen sind in der Praxis besonders wirksam: MFA als Standard, das Blockieren veralteter Anmeldeverfahren und der Zugriff nur von verwalteten oder compliant Geräten.

Der wichtigste Punkt bleibt aber die Planung. Zu breite Richtlinien können Benutzer aussperren. Fehlende Ausnahmen können Notfallzugänge verhindern. Ungetestete Regeln können produktive Prozesse unterbrechen.

Zero Trust funktioniert dann gut, wenn Sicherheit und Arbeitsfähigkeit gemeinsam betrachtet werden. Nicht als Einzelmaßnahme, sondern als nachvollziehbares Zugriffsmodell für den gesamten Microsoft-365-Tenant.