In vielen Tenants, die ich mir anschaue, geht man bei Conditional Access noch erstaunlich zögerlich vor. Meist existieren ein oder zwei Richtlinien, doch das Fundament, das aus Sicherheitssicht dringend nötig wäre, fehlt. Gerade in kleineren oder frisch migrierten Umgebungen sind oft nicht einmal die Standardmaßnahmen umgesetzt, obwohl Conditional Access längst zur Grundausstattung von Microsoft Entra ID gehört. Seit Azure AD im Juli 2023 umbenannt wurde, gibt es auch keine Ausrede mehr für veraltete Konzepte.

Für Admins ist MFA ohne Ausnahme Pflicht

Zu den wichtigsten Maßnahmen gehört nach wie vor, alle privilegierten Konten mit Multi-Faktor-Authentifizierung abzusichern. Das klingt banal. In der Praxis wird es aber erstaunlich oft vergessen oder nur halbherzig umgesetzt, etwa weil man auf „klassische“ MFA-Methoden (SMS, Telefonanruf) setzt und moderne Methoden (Authenticator-App, FIDO2, passwortlose Anmeldung) links liegen lässt. Für administrative Rollen empfehle ich eine eigene Richtlinie, die alle Benutzer mit Adminrechten zu einem zweiten Faktor verpflichtet. Damit schrumpft die Angriffsfläche erheblich, und darauf möchte ich in keinem Tenant verzichten.

Legacy Authentication gehört konsequent blockiert

Legacy Authentication spreche ich in fast jedem Tenant an. Die alten Protokolle (z. B. IMAP, POP, SMTP Basic) beherrschen keine modernen Authentifizierungsverfahren und bieten Angreifern einen bequemen Einstieg. Microsoft rät schon lange dazu, sie zu blockieren (siehe Dokumentation). Trotzdem begegnen mir immer wieder Tenants, in denen sie noch aktiv sind, weil etwa ein altes Multifunktionsgerät E-Mails verschickt oder Benutzer an ihrer gewohnten Mail-App hängen.

Tipp aus der Praxis: Bevor Sie Legacy Authentication blockieren, testen Sie die Richtlinie immer zuerst im Report-Only-Modus und werten das Monitoring (Sign-In Logs, Insights & Reporting) aus. So fallen auch unauffällige Altnutzer auf, und man kann rechtzeitig reagieren.

Auch alle übrigen Benutzer brauchen MFA

Sind die Admins abgesichert, kommt die restliche Belegschaft an die Reihe, denn jede Identität kann zum Angriffsziel werden. MFA sollte deshalb für alle Benutzer gelten, am besten mit modernen Methoden und mit einem Auge auf die Bedienbarkeit. Passwortlose Verfahren wie Windows Hello for Business oder die Authenticator-App machen den Rollout leichter. Die Benutzer sträuben sich weniger, und im Alltag stört MFA dann kaum noch.

Mit einer P2-Lizenz lohnen sich risikobasierte Richtlinien

Wer Entra ID Premium P2 lizenziert hat, sollte die risikobasierten Anmelderichtlinien unbedingt nutzen. Sie reagieren dynamisch auf verdächtige Aktivitäten. Je nach Lage erzwingen sie MFA, blockieren den Zugriff oder verlangen, dass das Passwort zurückgesetzt wird. Vor allem größere Organisationen mit Benutzern in aller Welt gewinnen dadurch spürbar an Sicherheit. Die offizielle Übersicht gibt es bei Microsoft. Gute Erfahrungen habe ich damit gemacht, risikobasierte Richtlinien zunächst im Report-Only-Modus zu beobachten und erst nach einigen Wochen produktiv zu schalten.

Im Report-Only-Modus lassen sich Richtlinien gefahrlos testen

Für mich gehört der Report-Only-Modus zu den wichtigsten Werkzeugen bei Conditional Access. Jede Richtlinie läuft darin gewissermaßen im Probebetrieb, ohne sofort zu greifen. Man sieht, welche Benutzer und Anwendungen betroffen wären, und bemerkt unerwünschte Nebenwirkungen früh. Bei kritischen Richtlinien, etwa beim Blockieren von Legacy Authentication oder bei MFA für alle, erspart man sich so böse Überraschungen. Ich lasse jede neue Richtlinie mindestens eine Woche im Report-Only-Modus laufen, bevor ich sie „scharf schalte“.

Break-Glass-Accounts sichern den Zugang im Notfall

Break-Glass-Accounts geraten in der Praxis gern in Vergessenheit. Gemeint sind Notfallkonten, die unabhängig von Conditional-Access-Richtlinien funktionieren. Man braucht sie zum Beispiel, wenn eine Richtlinie versehentlich zu streng ausfällt und sich niemand mehr anmelden kann. Diese Konten sollten:

  • ein sehr starkes, komplexes Passwort haben
  • MFA möglichst vermeiden (oder so ausgesteuert sein, dass sie immer funktionieren)
  • nur im Notfall genutzt werden
  • regelmäßig geprüft werden
  • Monitoring und Alerting aktiviert haben

Außerdem müssen sie dokumentiert sein und in regelmäßigen Abständen getestet werden. Der Aufwand ist gering, für einen sicheren Betrieb sind diese Konten aber unverzichtbar.

Das What-If-Tool zeigt vorab, welche Richtlinien greifen

Bei umfangreichen Conditional-Access-Konfigurationen weiß irgendwann niemand mehr genau, wie die einzelnen Richtlinien zusammenspielen. Dann hilft das What-If-Tool in der Entra-ID-Konsole. Man gibt beliebige Parameter vor (Benutzer, Anwendung, Standort, Gerät) und sieht sofort, welche Richtlinien greifen würden. Im Groben läuft das so ab:

flowchart TD
    Anfrage["Sign-In Anfrage"] --> User["User auswählbar"]
    User --> Anwendung["App auswählbar"]
    Anwendung --> Standort["Standort wählbar"]
    Standort --> Gerät["Gerätestatus"]
    Gerät --> CA["CA Policies simuliert"]
    CA --> Ergebnis["Policy-Ergebnis"]

Abbildung: So simuliert das What-If-Tool in Entra ID eine Anmeldung gegen die Richtlinien.

Wirken mehrere Richtlinien gleichzeitig oder sind Ausnahmen definiert, erspart das Tool viel Ärger (mir hat es schon manche Stunde Fehlersuche abgenommen).

Ein gestaffelter Einstieg lässt Raum zum Nachjustieren

Viele machen den Fehler, Conditional Access zu „überspezifizieren“ oder gleich mit einem zu komplexen Regelwerk einzusteigen. Bewährt hat sich ein gestaffeltes Vorgehen. Zuerst kommt die Baseline mit MFA für Admins, dem Blockieren der Legacy Authentication, MFA für alle und Break-Glass-Accounts. Danach ergänzt man nach und nach weitere Richtlinien und prüft jede vorher im Report-Only-Modus und mit What-If-Simulationen. Wer so vorgeht, hat schon viel erreicht, ohne den Betrieb zu gefährden. Am wichtigsten ist aber, die Richtlinien regelmäßig zu überprüfen und anzupassen und sie als festen, sich wandelnden Teil der Sicherheitsstrategie zu begreifen. Kein Tenant bleibt, wie er ist, und mit jeder neuen App, jedem neuen Benutzer und jedem neuen Standort wächst die Angriffsfläche.