Conditional Access einrichten: Zugriff nach Kontext statt Bauchgefühl

Definition

Conditional Access sind Richtlinien (Conditional Access Policies) in Microsoft Entra ID, die Zugriff auf Anwendungen nur gewähren, wenn definierte Bedingungen erfüllt sind und passende Zugriffskontrollen angewendet werden. Es ist keine einzelne MFA-Funktion und kein Ersatz für Geräteverwaltung oder allgemeine IT-Sicherheitsprozesse.

Einleitung

Passwörter werden abgefischt, Tokens werden missbraucht, und plötzlich ist ein Konto drin. Conditional Access hilft, genau diese Lücke zu schließen: Zugriffe werden nicht pauschal erlaubt, sondern nach Kontext gesteuert. Wenn du Conditional Access einrichten willst, geht es weniger um „eine Regel“, sondern um saubere Policies, Tests und einen Rollout ohne Überraschungen.

Warum Conditional Access wichtig ist

In der Microsoft Cloud entscheidet nicht mehr nur das Passwort über den Zugriff, sondern die Gesamtsituation bei der Anmeldung. Das reduziert Risiko, ohne Kolleginnen und Kollegen mit Dauer-Popups auszubremsen: Unauffällige Anmeldungen laufen normal, auffällige Anmeldungen bekommen zusätzliche Authentifizierung oder werden blockiert.

• Weniger erfolgreiche Phishing-Angriffe durch erzwungene Multi-Faktor-Authentifizierung (MFA) und risikobasierte Regeln.
• Weniger Support-Aufwände, weil Regeln nachvollziehbar sind und nicht als Einzelfall-Ausnahmen „per Zuruf“ leben.
• Bessere Steuerbarkeit für Admins und Rollen durch klare Bedingungen und dokumentierte Ausnahmen.

Kontextsignale: Standort, Gerät, Benutzer, Risiko

Conditional Access wertet Signale aus und wendet danach Controls an. Typische Signale sind Standort/IP, Device-Status, Benutzerkontext und Risiko. Entscheidend ist: Signale beschreiben die Lage, Controls die Reaktion (z. B. MFA erzwingen oder Zugriff blockiert).

Standort

Standortsignale basieren meist auf IP-Adresse oder benannten Standorten. Damit lassen sich externe Anmeldungen strenger behandeln oder Länder/Regionen per Geofencing blockieren, wenn das zum Bedrohungsbild passt.

Gerät

Gerätesignale prüfen, ob ein Device verwaltet ist (Azure AD joined, hybrid joined oder registriert) und ob es compliant ist. Geräte-Compliance kommt in der Praxis oft aus Microsoft Intune und ist die Grundlage für „Nur von verwalteten Geräten“.

Benutzer

Benutzer- und Rollenbezug hilft, Admin-Konten, privilegierte Rollen oder besonders kritische Konten anders zu behandeln als Standard-Accounts. Das verhindert, dass ein einzelnes kompromittiertes Admin-Konto direkt „alles“ kann.

Risiko

Risikobasierte Policies nutzen Signale aus Entra Identity Protection (Microsoft Entra ID P2), z. B. riskante Anmeldung oder riskantes Benutzerkonto. Das erlaubt dynamische Reaktionen: zusätzliche Faktoren oder sofortiges Blocken, wenn das Risiko hoch ist.

Voraussetzungen, Lizenzierung und typische Abhängigkeiten

Für Conditional Access wird in der Regel Microsoft Entra ID P1 benötigt; für risikobasierte Policies Microsoft Entra ID P2. Geräte-Policies sind stark davon abhängig, ob es eine klare Device-Strategie gibt (verwaltete Devices, Compliance), häufig mit Microsoft Intune. Typische Abhängigkeiten sind außerdem Legacy Authentication (Altprotokolle) und saubere Rollen-/Gruppenpflege im Tenant.

Conditional Access einrichten: pragmatische Konfigurationshinweise

Der sichere Weg startet kontrolliert. Statt viele Policies auf einmal zu bauen, wird mit wenigen, gut getesteten Richtlinien begonnen.

Schritt 1: Break-Glass sauber vorbereiten

Break-Glass bzw. Emergency Access Accounts müssen existieren, stark abgesichert sein und in Policies bewusst ausgeschlossen werden. Sonst kann eine falsche Regel den Tenant unzugänglich machen.

Schritt 2: Report-Only statt „sofort aktiv“

Neue Conditional Access Policies sollten zunächst im Report-Only-Modus laufen. So wird sichtbar, welche Anmeldungen betroffen wären, ohne produktiv zu blockieren.

Schritt 3: Start-Policies definieren

• MFA für alle Benutzer, mit klaren Ausnahmen (Break-Glass, ggf. Service Accounts).
• Legacy Authentication blockieren, weil sie moderne Authentifizierung unterläuft.
• Externer Zugriff nur von compliant Devices oder mit strengeren Grant Controls.

Schritt 4: Rollout in Wellen

Erst Pilotgruppe, dann breiter Rollout. Teste mindestens: internes Netz, externes Netz, neues Gerät, Admin-Rolle, Zugriff auf Microsoft 365-Apps wie SharePoint und Exchange Online.

Best Practices: Zero Trust, MFA und klare Richtlinien

Zero Trust heißt: nie automatisch vertrauen, immer prüfen, so wenig Rechte wie möglich. In Conditional Access wird das praktisch durch wenige, saubere Policies mit klarer Benennung (Naming Convention), dokumentierten Ausnahmen und regelmäßigem Review.

• MFA bevorzugt phishing-resistent umsetzen (z. B. FIDO2 oder Windows Hello for Business), wo möglich.
• Admin-Zugriffe getrennt behandeln (stärkere Authentifizierung, engerer Gerätezwang, kürzere Session-Logik).
• Policies regelmäßig auswerten und nachschärfen, weil Anwendungen, Standorte und Geräte sich ändern.

Typisches Anwendungsszenario (Mini-Beispiel)

Ein Vertriebler meldet sich auf Reisen in einem Hotel-WLAN an. Der Standort ist „extern“, das Gerät ist nicht compliant, und das Sign-In-Risiko steigt. Conditional Access erzwingt MFA und blockiert den Zugriff auf sensible Anwendungen, bis ein verwaltetes Device genutzt wird. Ergebnis: weniger Risiko bei gleichbleibender Arbeitsfähigkeit, weil Standardzugriffe im Normalfall weiter funktionieren.

Checkliste vor Rollout

• Lizenzen (Entra ID P1/P2) und Tenant-Voraussetzungen geprüft, Security Defaults verstanden.
• Break-Glass/Emergency Access Accounts definiert, dokumentiert und ausgeschlossen.
• Report-Only aktiv, Pilotgruppe festgelegt, Testfälle für Anmeldung und Zugriff definiert.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn Policies nicht nur „einmal eingerichtet“, sondern als laufender Betrieb verstanden werden müssen: mehrere Anwendungen, viele Standorte, gemischte Devices, Rollen, Gäste und steigende Anforderungen an Nachweis und Dokumentation. Dann entstehen sonst schnell unklare Richtlinien, zu viele Ausnahmen, oder es wird aus Angst vor Störungen zu wenig durchgesetzt.

Mit Managed Microsoft 365 Security übernehmen wir den Betrieb eures Microsoft Security-Stacks in Entra ID und halten Conditional Access Policies stabil, testbar und nachvollziehbar.