Conditional Access in Entra ID einrichten: Richtlinien für den Mittelstand

Was ist Conditional Access?

Ohne Conditional Access trifft Microsoft Entra ID bei jeder Anmeldung eine einfache binäre Entscheidung: Sind Benutzername und Passwort korrekt? Wenn ja, erhält der Benutzer Zugriff. Wenn nein, wird der Zugriff verweigert. Diese binäre Logik ignoriert den gesamten Kontext der Anmeldung: Von welchem Gerät kommt der Zugriff? Aus welchem Land? Zu welcher Uhrzeit? Auf welche Anwendung? Gibt es Anzeichen für ein kompromittiertes Konto?

Conditional Access ergänzt diese binäre Entscheidung um eine kontextabhängige Ebene. Statt "Zugriff ja oder nein" lautet die Frage jetzt: "Zugriff unter welchen Bedingungen?" Die Antwort kann lauten: "Zugriff erlaubt, aber nur mit MFA", oder "Zugriff erlaubt, aber nur von einem konformen Gerät", oder "Zugriff verweigert, weil die Anmeldung aus einem ungewöhnlichen Land kommt".

Technisch funktioniert Conditional Access als Policy Engine, die zwischen der Authentifizierung (Wer bist du?) und der Autorisierung (Was darfst du?) sitzt. Das Konzept passt perfekt in eine Zero-Trust-Architektur, bei der jeder Zugriff individuell verifiziert wird. Jede Richtlinie besteht aus drei Komponenten:

Assignments (Wer und Was):

• Benutzer und Gruppen (oder alle Benutzer)
• Cloud-Apps oder Aktionen (z.B. alle Apps, nur Office 365, nur Azure Management)
• Bedingungen (Standort, Geräteplattform, Anmelderisiko, Client-App)

Access Controls (Was passiert):

• Grant: Zugriff gewähren mit Anforderungen (MFA, konformes Gerät, Domain-joined)
• Block: Zugriff komplett verweigern
• Session: Eingeschränkter Zugriff (z.B. keine Downloads, zeitlich begrenzt)

Aktivierungsstatus:

• Report-Only: Richtlinie wird ausgewertet, aber nicht durchgesetzt (nur Logging)
• On: Richtlinie wird durchgesetzt
• Off: Richtlinie ist deaktiviert

Voraussetzungen und Lizenzen

Conditional Access erfordert mindestens eine Entra ID P1-Lizenz, die in Microsoft 365 Business Premium, E3 und E5 enthalten ist. Für risikobasierte Richtlinien (Sign-in Risk, User Risk) brauchst du Entra ID P2, das in E5 enthalten ist oder als Add-on zu E3 verfügbar ist.

Bevor du die erste Richtlinie erstellst, kläre folgende Voraussetzungen:

• Lizenzierung prüfen: Jeder Benutzer, der von Conditional Access betroffen ist, braucht eine P1-Lizenz. Das gilt auch für Gastbenutzer (hier greift die Lizenzierung des einladenden Tenants).
• Break Glass Accounts anlegen: Mindestens zwei Notfallzugangs-Konten mit Global Admin-Rechten, langem Passwort, ohne MFA, die von allen Conditional Access Policies ausgenommen werden. Diese Accounts sind dein Rettungsanker, falls eine fehlerhafte Richtlinie alle regulären Admins aussperrt.
• Named Locations konfigurieren: Vertrauenswürdige Standorte (Büro-IP-Adressen) und blockierte Länder als Named Locations in Entra ID hinterlegen.
• MFA-Registrierung vorbereiten: Benutzer müssen ihre MFA-Methode registriert haben, bevor eine MFA-Richtlinie greift. Plane eine Registrierungskampagne mit ausreichend Vorlauf.

Die sechs Kernrichtlinien

Die folgenden sechs Richtlinien bilden ein solides Fundament, das die wichtigsten Angriffsvektoren adressiert, ohne den Arbeitsalltag unnötig zu behindern. Die Reihenfolge entspricht der empfohlenen Einführungsreihenfolge.

Richtlinie 1: MFA für alle Benutzer

Diese Richtlinie ist die Basis: Jeder Benutzer muss sich bei jeder Anmeldung an einer Cloud-App mit einem zweiten Faktor authentifizieren. Das klingt radikal, ist aber in der Praxis weniger störend als befürchtet, weil Entra ID sich konforme Geräte und vertrauenswürdige Standorte merkt und MFA nicht bei jedem Login erneut abfragt (Token Lifetime, Primary Refresh Token).

Konfiguration:

• Assignments: Alle Benutzer, alle Cloud-Apps
• Ausnahmen: Break Glass Accounts, Service Accounts (falls nötig, aber minimieren)
• Grant: Require multi-factor authentication
• Status: Zunächst Report-Only, nach 2 Wochen Evaluation auf On schalten

Warum nicht Security Defaults? Security Defaults bieten eine vereinfachte MFA-Variante, die kostenlos verfügbar ist. Sie erlauben aber keine Ausnahmen, keine Kombination mit anderen Richtlinien und keine granulare Steuerung. Sobald du eine einzige Conditional Access Policy aktivierst, werden Security Defaults automatisch deaktiviert. Starte also direkt mit Conditional Access, anstatt den Umweg über Security Defaults zu nehmen.

Richtlinie 2: Legacy Authentication blockieren

Legacy-Authentifizierungsprotokolle (POP3, IMAP, SMTP AUTH, ActiveSync mit Basic Auth) unterstützen kein MFA. Solange sie aktiv sind, kann ein Angreifer mit gestohlenen Credentials die MFA-Anforderung aus Richtlinie 1 komplett umgehen, indem er ein Legacy-Protokoll verwendet.

Konfiguration:

• Assignments: Alle Benutzer, alle Cloud-Apps
• Bedingungen: Client Apps = "Other clients" und "Exchange ActiveSync"
• Ausnahmen: Break Glass Accounts (und ggf. ein dedizierter Service Account für Multifunktionsdrucker, falls diese SMTP AUTH benötigen)
• Grant: Block access
• Status: Report-Only, dann Analyse der Logs (welche Benutzer/Apps nutzen noch Legacy Auth?), Migration der verbleibenden Anwendungen, dann On

Vor der Aktivierung prüfen: Analysiere die Sign-in Logs der letzten 30 Tage auf Legacy-Auth-Nutzung. Filter: Client App = "Other clients". Häufige Kandidaten sind ältere Scanner/Drucker mit Scan-to-Mail, alte Outlook-Versionen, Drittanbieter-CRM-Systeme und mobile E-Mail-Apps. Migriere diese Anwendungen auf Modern Authentication, bevor du die Richtlinie scharfschaltest.

Richtlinie 3: Erhöhte Anforderungen für Administratoren

Administratorenkonten sind hochwertige Ziele. Eine separate Richtlinie für Admin-Rollen stellt sicher, dass auch dann strenge Anforderungen gelten, wenn die allgemeine MFA-Richtlinie aus irgendeinem Grund eine Ausnahme zulässt.

Konfiguration:

• Assignments: Directory Roles (Global Admin, Security Admin, Exchange Admin, SharePoint Admin, User Admin, Privileged Role Admin, Cloud Application Admin, Authentication Admin, Helpdesk Admin, Billing Admin)
• Cloud-Apps: Alle Cloud-Apps
• Ausnahmen: Break Glass Accounts
• Grant: Require multi-factor authentication AND Require compliant device (bei Intune-Nutzung)
• Status: Report-Only für 1 Woche, dann On

Zusätzliche Empfehlung: Wenn du Entra ID P2 hast, aktiviere Privileged Identity Management (PIM) für alle Admin-Rollen. Statt permanenter Rollenzuweisung aktivieren Admins ihre Rolle erst bei Bedarf (Just-in-Time), geben dabei eine Begründung an und erhalten die Berechtigung nur für einen definierten Zeitraum (z.B. 4 Stunden). Das reduziert die Angriffsfläche erheblich, weil Admin-Rechte nicht rund um die Uhr aktiv sind.

Richtlinie 4: Geräte-Compliance erforderlich

Diese Richtlinie stellt sicher, dass nur Geräte auf Unternehmensdaten zugreifen können, die die definierten Sicherheitsanforderungen erfüllen. Das setzt voraus, dass du Microsoft Intune eingerichtet und Compliance-Richtlinien pro Geräteplattform definiert hast.

Konfiguration:

• Assignments: Alle Benutzer
• Cloud-Apps: Office 365 (oder spezifische Apps)
• Ausnahmen: Break Glass Accounts, ggf. Gastbenutzer (die eigene Geräte nicht in Intune registrieren können)
• Grant: Require device to be marked as compliant
• Status: Report-Only für mindestens 2 Wochen (Compliance-Status aller Geräte prüfen!)

BYOD-Fallback: Nicht jedes Unternehmen kann Intune auf alle Geräte ausrollen, insbesondere bei BYOD-Szenarien. Für diese Fälle bietet sich eine alternative Richtlinie an, die statt Gerätecompliance eine App Protection Policy (MAM) erfordert. Damit werden Unternehmensdaten innerhalb der verwalteten Apps geschützt (verschlüsselt, nicht kopierbar, remote löschbar), ohne dass das persönliche Gerät vollständig verwaltet wird.

Richtlinie 5: Geo-Blocking

Wenn dein Unternehmen keine Mitarbeitenden oder Geschäftspartner in bestimmten Ländern hat, gibt es keinen Grund, Anmeldungen aus diesen Ländern zuzulassen. Geo-Blocking ist kein perfekter Schutz (Angreifer nutzen VPNs und Proxies), aber es eliminiert den Großteil der automatisierten Angriffe und reduziert das Rauschen in den Sign-in Logs erheblich.

Konfiguration:

• Named Location erstellen: "Blocked Countries" mit den Ländern, aus denen kein Zugriff erwartet wird
• Assignments: Alle Benutzer, alle Cloud-Apps
• Bedingungen: Locations = Include "Blocked Countries"
• Ausnahmen: Break Glass Accounts
• Grant: Block access
• Status: Report-Only für 2 Wochen (prüfe, ob es legitime Anmeldungen aus den blockierten Ländern gibt, z.B. Mitarbeitende auf Dienstreise)

Praktischer Ansatz: Statt eine lange Blockliste zu pflegen, ist es oft einfacher, eine Allow-List zu verwenden. Erstelle eine Named Location mit den Ländern, in denen Anmeldungen erlaubt sind (z.B. Deutschland, Österreich, Schweiz, und Länder, in die regelmäßig Dienstreisen stattfinden), und blockiere alles andere.

Dienstreisen berücksichtigen: Informiere die Mitarbeitenden, dass sie vor einer Dienstreise in ein nicht freigeschaltetes Land Bescheid geben müssen, damit du das Land temporär freischalten oder einen Ausnahme-Account vorbereiten kannst.

Richtlinie 6: Risikobasierte Anmeldung

Diese Richtlinie nutzt die Risikobewertung von Entra ID Identity Protection (erfordert P2-Lizenz) und reagiert dynamisch auf verdächtige Anmeldeversuche. Entra ID analysiert jede Anmeldung auf Anomalien: ungewöhnlicher Standort, unmögliche Reise (Impossible Travel), anonyme IP-Adresse, Password Spray-Muster, bekannte Angreifer-Infrastruktur und mehr. Jede Anmeldung erhält eine Risikostufe: None, Low, Medium oder High.

Konfiguration:

• Assignments: Alle Benutzer, alle Cloud-Apps
• Bedingungen: Sign-in Risk = Medium und High
• Ausnahmen: Break Glass Accounts
• Grant: Require multi-factor authentication (bei Medium Risk), Block access (bei High Risk, optional)
• Status: Report-Only für 2-4 Wochen, dann schrittweise aktivieren

Ergänzend: User Risk Policy:

• Bedingungen: User Risk = High
• Grant: Require password change (Benutzer muss Passwort ändern)
• Diese Richtlinie reagiert nicht auf einzelne Anmeldungen, sondern auf die kumulative Risikobewertung eines Benutzers (z.B. Credentials in einem Leak gefunden)

Praxisbeispiel: Conditional Access für ein Unternehmen mit 100 Mitarbeitenden

Die Theorie klingt gut, aber wie sieht die Einführung in der Praxis aus? Nehmen wir ein fiktives Beispiel: Die Müller & Partner GmbH, ein Ingenieurbüro mit 100 Mitarbeitenden, 5 IT-Admins, Microsoft 365 Business Premium und der Anforderung, ein ISMS nach ISO 27001 aufzubauen.

Woche 1-2: Vorbereitung

Die IT-Abteilung legt zwei Break Glass Accounts an, speichert die Passwörter im versiegelten Umschlag im Tresor und konfiguriert Alert Policies, die bei jeder Anmeldung mit diesen Accounts eine Benachrichtigung senden. Named Locations werden für die Büro-IP-Adressen und die erlaubten Länder (DACH + häufige Reiseländer) konfiguriert.

Parallel startet die MFA-Registrierungskampagne. Alle Mitarbeitenden erhalten eine Anleitung zur Installation der Microsoft Authenticator App und einen Termin zur Registrierung. Die IT unterstützt bei Problemen. Ziel: 100 Prozent MFA-Registrierung innerhalb von zwei Wochen.

Woche 3-4: Report-Only Phase

Alle sechs Richtlinien werden im Report-Only-Modus erstellt. Die IT-Abteilung analysiert die Logs täglich und beantwortet folgende Fragen:

• Wie viele Anmeldungen würden von der Legacy-Auth-Blockade betroffen? (Ergebnis: 12 Anmeldungen pro Tag von drei alten Scannern)
• Gibt es Anmeldungen aus blockierten Ländern? (Ergebnis: 2 Mitarbeitende waren in den USA auf einer Messe, das Land wird zur Allow-List hinzugefügt)
• Welche Geräte sind nicht Intune-konform? (Ergebnis: 15 private Smartphones, für die MAM statt MDM konfiguriert wird)

Woche 5: Schrittweise Aktivierung

• Montag: Richtlinie 2 (Legacy Auth Block) wird scharf geschaltet, nachdem die Scanner auf Modern Authentication umgestellt wurden
• Mittwoch: Richtlinie 1 (MFA für alle) und Richtlinie 3 (Admin-MFA) werden aktiviert
• Freitag: Richtlinie 5 (Geo-Blocking) wird aktiviert

Woche 6: Verbleibende Richtlinien

• Richtlinie 4 (Geräte-Compliance) wird aktiviert, mit einer Grace Period von 7 Tagen für noch nicht konforme Geräte
• Richtlinie 6 (Risikobasiert) bleibt noch eine weitere Woche in Report-Only und wird dann aktiviert

Ergebnis nach 6 Wochen

Die Müller & Partner GmbH hat ein strukturiertes Conditional Access Framework, das die wichtigsten Angriffsvektoren adressiert. Im ISMS werden die sechs Richtlinien als TOMs dokumentiert und den Controls A.5.15, A.8.2 und A.8.5 zugeordnet. Der Secure Score hat sich durch die Maßnahmen um 25 Punkte verbessert.

Der Report-Only-Modus im Detail

Der Report-Only-Modus ist das wichtigste Werkzeug für die sichere Einführung von Conditional Access. Eine Richtlinie im Report-Only-Modus wird bei jeder Anmeldung ausgewertet, aber das Ergebnis wird nur protokolliert, nicht durchgesetzt. Du siehst in den Sign-in Logs genau, welche Anmeldungen betroffen wären, ohne dass tatsächlich jemand blockiert oder zu MFA aufgefordert wird.

So nutzt du Report-Only effektiv:

1. Erstelle die Richtlinie im Report-Only-Modus
2. Warte mindestens 2 Wochen (besser 4 Wochen, um auch seltene Anmeldeszenarien abzudecken)
3. Analysiere die Sign-in Logs: Filter nach "Report-only: Failure" (wären blockiert worden) und "Report-only: Not applied" (Ausnahmen)
4. Identifiziere und behebe Probleme (z.B. Legacy-Auth-Nutzung, fehlende MFA-Registrierung, nicht konforme Geräte)
5. Schalte die Richtlinie auf "On", wenn keine unerwarteten Blockaden mehr auftreten

Tipp: Nutze die Conditional Access Insights and Reporting Workbook in Azure Monitor, um eine grafische Übersicht über die Auswirkungen deiner Report-Only-Richtlinien zu bekommen. Das Workbook zeigt dir auf einen Blick, wie viele Benutzer betroffen wären und welche Richtlinie die meisten Blockaden verursachen würde.

Notfallzugang: Break Glass Accounts

Break Glass Accounts sind Notfallzugangs-Konten, die du verwendest, wenn alle anderen Zugänge zum Tenant gesperrt sind. Das kann passieren, wenn eine fehlerhafte Conditional Access Policy alle Admins aussperrt, wenn der MFA-Dienst ausfällt oder wenn ein Angreifer die Admin-Accounts kompromittiert hat.

Best Practices für Break Glass Accounts:

• Mindestens zwei Accounts anlegen (Redundanz)
• Cloud-only Accounts (keine Synchronisation mit on-premises AD)
• Global Admin-Rolle permanent zugewiesen
• Extrem langes Passwort (mindestens 24 Zeichen, zufällig generiert)
• Keine MFA (damit der Account auch bei MFA-Ausfall funktioniert)
• Von allen Conditional Access Policies ausgenommen
• Passwörter im versiegelten Umschlag im physischen Tresor aufbewahren
• Alert Policy: Benachrichtigung bei jeder Anmeldung mit einem Break Glass Account
• Vierteljährlich testen: Anmeldung mit dem Break Glass Account, Passwort zurücksetzen, neuen Umschlag erstellen
• Im ISMS dokumentieren: Wer hat Zugang zum Tresor? Wer wird benachrichtigt? Wie ist der Prozess?

Die Idee, einen Account ohne MFA in einem ansonsten MFA-geschützten Tenant zu haben, fühlt sich falsch an. Das ist verständlich. Aber die Alternative, nämlich bei einem Ausfall keinen Zugang zum Tenant zu haben, ist deutlich gefährlicher. Der Break Glass Account ist durch seine Länge des Passworts, die Alerting-Überwachung und den physischen Schutz ausreichend gesichert. Microsoft empfiehlt dieses Vorgehen ausdrücklich in der offiziellen Dokumentation.

Conditional Access und BYOD

Bring Your Own Device ist in mittelständischen Unternehmen weit verbreitet, stellt aber eine besondere Herausforderung für Conditional Access dar. Private Geräte können nicht in Intune enrollt werden (oder die Mitarbeitenden wollen das nicht), sie erfüllen keine Compliance-Richtlinien, und du hast keine Kontrolle über den Sicherheitszustand des Geräts.

Die Lösung ist ein abgestuftes Modell:

Unternehmensgeräte (Intune-verwaltet):

• Voller Zugriff auf alle Cloud-Apps
• Gerätecompliance als Zugriffsbedingung
• Offline-Zugriff auf Dateien erlaubt

Private Geräte mit MAM (App Protection):

• Zugriff auf Office-Apps (Outlook, Teams, OneDrive) mit App Protection Policy
• Unternehmensdaten innerhalb der Apps verschlüsselt und vom privaten Bereich getrennt
• Copy/Paste zwischen verwalteten und nicht verwalteten Apps einschränkbar
• Remote-Löschung der Unternehmensdaten möglich, ohne persönliche Daten zu berühren

Unbekannte Geräte (z.B. Hotel-PC):

• Zugriff nur über Browser (kein App-Zugriff)
• Session-basierte Einschränkungen: Kein Download, kein Drucken, automatisches Sign-out nach Inaktivität
• Conditional Access App Control (erfordert Defender for Cloud Apps)

Häufige Fehler bei Conditional Access

Zu viele Richtlinien erstellen: Jede Richtlinie erhöht die Komplexität und die Wahrscheinlichkeit von Konflikten. Halte die Anzahl der Richtlinien so gering wie möglich. Sechs bis zehn Richtlinien reichen für die meisten mittelständischen Unternehmen.

Überlappende Richtlinien nicht verstehen: Conditional Access wertet alle zutreffenden Richtlinien aus. Wenn eine Richtlinie MFA verlangt und eine andere den Zugriff blockiert, gewinnt die restriktivste. Das kann zu unerwarteten Blockaden führen, wenn du die Interaktion zwischen Richtlinien nicht durchdacht hast.

Ausnahmen nicht dokumentieren: Jede Ausnahme in einer Conditional Access Policy sollte dokumentiert und begründet sein. "Weil der Geschäftsführer es so wollte" ist keine akzeptable Begründung. Im ISMS gehört zu jeder Ausnahme eine Risikobewertung und eine geplante Maßnahme zur Beseitigung der Ausnahme.

Report-Only-Phase überspringen: Die Versuchung ist groß, eine vermeintlich harmlose Richtlinie sofort zu aktivieren. In der Praxis gibt es fast immer Überraschungen: vergessene Service Accounts, unbekannte Legacy-Apps, Mitarbeitende im Ausland. Die Report-Only-Phase kostet zwei Wochen, spart aber Stunden am Helpdesk.

Named Locations nicht pflegen: Wenn sich die Büro-IP-Adresse ändert oder ein neuer Standort eröffnet wird, müssen die Named Locations aktualisiert werden. Ohne aktuelle Named Locations greifen standortbasierte Richtlinien nicht korrekt.

Conditional Access im ISMS dokumentieren

Conditional Access Policies sind technisch-organisatorische Maßnahmen (TOMs), die im ISMS dokumentiert werden sollten. In ISMS Lite lassen sich die Richtlinien als TOMs erfassen und den passenden ISO 27001-Controls zuordnen, inklusive Überprüfungsdatum und Verantwortlichem. Die Dokumentation umfasst:

Pro Richtlinie:

• Name und Beschreibung der Richtlinie
• Zuordnung zu ISO 27001-Controls
• Betroffene Benutzer und Ausnahmen (mit Begründung)
• Konfiguration (Bedingungen und Access Controls)
• Aktivierungsdatum und verantwortliche Person
• Letzte Überprüfung und nächste geplante Überprüfung

Übergreifend:

• Break Glass Account-Prozess (Aufbewahrung, Test, Alerting)
• Prozess für neue Richtlinien (Report-Only, Evaluation, Aktivierung)
• Prozess für Ausnahmen (Beantragung, Genehmigung, Befristung, Überprüfung)
• Named Locations und deren Pflegeprozess

Die Zuordnung zu ISO 27001-Controls ist eindeutig:

• A.5.15 (Zugriffskontrolle): Conditional Access als Ganzes
• A.8.2 (Privilegierte Zugriffsrechte): Admin-spezifische Richtlinien, PIM
• A.8.5 (Sichere Authentifizierung): MFA-Richtlinien
• A.8.1 (User Endpoint Devices): Geräte-Compliance-Richtlinien
• A.5.18 (Zugriffsrechte): Ausnahmen-Management

Monitoring und kontinuierliche Verbesserung

Conditional Access ist kein Set-and-Forget. Die Richtlinien müssen regelmäßig überprüft und angepasst werden:

Monatlich:

• Sign-in Logs auf blockierte Anmeldungen prüfen (sind es Angriffe oder False Positives?)
• Risikoerkennungen in Identity Protection prüfen (bei P2-Lizenz)
• Neue Benutzer und Gruppen auf korrekte Zuordnung prüfen

Quartalsweise:

• Alle Richtlinien auf Aktualität prüfen (neue Apps, neue Standorte, geänderte Anforderungen?)
• Ausnahmen überprüfen (sind sie noch nötig? Können sie entfernt werden?)
• Named Locations auf Aktualität prüfen
• Break Glass Accounts testen

Jährlich:

• Gesamtes Conditional Access Framework gegen aktuelle Microsoft-Empfehlungen und Best Practices abgleichen
• Ergebnisse in das Management Review einfließen lassen
• Ggf. neue Richtlinien basierend auf veränderten Bedrohungen oder Geschäftsanforderungen hinzufügen

Weiterführende Artikel

• Microsoft 365 absichern: Die 15 wichtigsten Sicherheitseinstellungen
• Intune für Einsteiger: Gerätemanagement ohne Enterprise-Komplexität
• Zero Trust im Mittelstand: Prinzipien und pragmatische Umsetzung
• MFA einführen: Widerstände überwinden und Akzeptanz schaffen
• Microsoft Secure Score: Was er misst und wie du ihn verbesserst