Conditional Access Best Practices: Sicherer Zugriff mit Entra ID

Definition

Conditional Access ist eine Richtlinien-Engine in Microsoft Entra ID, die Zugriffe auf Microsoft 365 und Cloud-Apps anhand von Sign-in-Signalen (z. B. Nutzer, Gerät, Standort, Risiko) erlaubt, einschränkt oder blockiert. Conditional Access ist keine Netzwerksicherheitslösung und ersetzt weder Endpoint-Schutz noch Security Monitoring.

Einleitung

Passwörter werden abgephisht, Tokens werden gestohlen, und ein gültiger Login wirkt für viele Systeme „normal“. Conditional Access Best Practices sorgen dafür, dass ein Login erst dann zählt, wenn Kontext und Schutz passen: starke Authentication, passende Devices und klare Regeln für Admins. Das senkt das Risiko von Account-Takeover und reduziert den Support-Aufwand, der sonst nach Sicherheitsvorfällen entsteht.

Rolle von Conditional Access im Microsoft 365 Ökosystem

Conditional Access sitzt zwischen Identität und Anwendung: Ein Benutzer möchte sich anmelden (sign-in), Entra ID bewertet die Bedingungen und erzwingt Controls wie MFA, compliant device oder Session controls. So schützt es Identitäten und Accounts auch dann, wenn Zugangsdaten kompromittiert sind, und macht „Secure Access“ messbar über Policies, Logs und Reports.

Lizenzen und Voraussetzungen (was du wirklich brauchst)

Conditional Access erfordert Microsoft Entra ID P1 oder P2. Ohne diese Lizenzen bleiben nur Security Defaults als grober Basisschutz, aber keine fein steuerbaren access policies. Für typische Best Practices sind diese Bausteine relevant:

• Entra ID P1: Conditional Access policies, Basis-Controls (z. B. MFA erzwingen).
• Entra ID P2: Entra Identity Protection für Sign-in risk und User risk (risikobasierte Regeln).
• Intune: Gerätebewertung für compliant devices und optional App Protection Policy (MAM) für unmanaged devices.

Wichtig für Kompatibilität: Legacy authentication (z. B. IMAP, POP3, SMTP, EWS) kann moderne Conditional Access-Controls umgehen oder führt beim Blocken zu ungeplanten Ausfällen. Das muss vorab inventarisiert werden.

Schritt-für-Schritt: Policies pragmatisch einführen

Ein sicherer Weg ist ein kleiner Policy-Satz, sauber getestet, dann schrittweise erweitert. Vorgehen:

• Vorbereitung: Break-glass accounts anlegen, schützen und von allen Policies ausschließen; Admin-Rollen inventarisieren; kritische Apps identifizieren.
• Simulation: Policies zuerst im Report-only mode bauen und im What-If tool testen (User, App, Location, Device).
• Rollout: Nach 3–7 Tagen Log-Review aktivieren, schrittweise ausrollen (z. B. erst IT, dann Pilotgruppe, dann alle).

So vermeidest du den Klassiker: ein „All users + All apps“-Schalter ohne Ausnahmen, der Administrators aussperrt und sofort Support-Tickets erzeugt.

Wichtige Policy-Typen (und was sie bringen)

1) MFA und phishing resistant Authentication

Require Multi-Factor Authentication ist die schnellste Risikoreduktion gegen Phishing. Wo möglich, erhöhe die Qualität der Authentication: Passwordless authentication, Microsoft Authenticator oder FIDO2 (phishing resistant). Nutzen: deutlich weniger erfolgreiche Kontoübernahmen und weniger Wiederherstellungsaufwand für Accounts.

2) Compliant device und Schutz vor unmanaged devices

Für sensible Anwendungen (z. B. Finance, HR, Admin-Portale) ist „Require device to be marked as compliant“ oft effektiver als nur MFA. In Kombination mit Intune senkst du Datenabfluss, weil ein Zugriff von nicht verwalteten Geräten blockiert oder auf Web-only reduziert wird. Für mobile Android iOS Szenarien kann MAM (App protection policy) eine Alternative sein, wenn Geräte nicht vollständig gemanagt werden sollen.

3) Risikobasierte Regeln (Entra Identity Protection)

Mit Entra ID P2 lassen sich Sign-in risk und User risk in Conditional Access einbinden, z. B. MFA erzwingen oder blocken bei hohem Risiko (Impossible travel, anomale Token-Nutzung). Nutzen: Du reagierst automatisch auf echte Angriffsindikatoren, statt alles gleich streng zu behandeln.

Best Practices und typische Fallstricke

In der Praxis scheitert Conditional Access selten an Technik, sondern an Betriebsdetails. Drei Best Practices:

• Saubere Ausnahmen: Break-glass accounts nie vergessen, Admins getrennt behandeln, Notfälle und Service-Accounts prüfen.
• Legacy authentication konsequent ausräumen: erst erkennen, dann block legacy, sonst gibt es „plötzliche“ Ausfälle.
• Scope klein halten: wenige Policies, klare Namen, eindeutige Assignments; sonst wird Tuning unmöglich.

Typische Fallstricke sind überlappende Richtlinien, unklare Zuständigkeiten und fehlende Dokumentation, warum eine Regel existiert.

Monitoring, Logging und Auditing: so bleibt es wirksam

Conditional Access ist nur dann „effective“, wenn du es kontrollierst. Mindeststandard:

• Sign-in logs regelmäßig prüfen: Welche Policies wurden angewendet, welche Controls haben gegriffen, wo wird geblockt?
• Report-only mode als dauerhafte Testspur nutzen, bevor Änderungen live gehen.
• Audit- und Change-Disziplin: jede Policy-Änderung begründen, Impact prüfen, Rollback planen.

Wenn du Logs zentralisieren willst, ist eine Anbindung an ein SIEM wie Microsoft Sentinel sinnvoll, weil du damit Korrelation, Alerting und Auditing effizienter betreibst und Betriebskosten durch schnellere Analyse sinken.

Mini-Praxisbeispiel: der schnelle Quick-Win ohne Chaos

Ein Unternehmen hatte MFA nur für Admins, aber viele user accounts wurden per phishing kompromittiert. Der erste Schritt war eine MFA-Policy für alle Benutzer im Report-only mode, parallel ein Report zu Legacy authentication und eine Pilotgruppe für compliant device bei sensiblen Apps. Nach einer Woche Log-Review wurde MFA aktiviert, während Legacy-Protokolle kontrolliert abgebaut wurden. Ergebnis: weniger verdächtige sign-ins und deutlich weniger Account-Recovery-Tickets im Betrieb.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn viele Apps, Hybrid-Identitäten, mehrere Standorte/Locations oder komplexe Ausnahmen im Spiel sind, weil falsche Policies sofort Business-Prozesse blocken können. Auch wenn du keine Zeit für Reviews von Logs, Tuning und saubere Dokumentation hast, wird Conditional Access schnell zum „einmal eingerichtet, nie gepflegt“-Risiko.