Conditional Access Policies richtig aufbauen – Reihenfolge, Fallstricke, Blueprint

Kurzfassung vorab

Conditional Access ist die Firewall deiner Identitäten – und die meisten bauen sie in der falschen Reihenfolge auf. Die unbequeme Wahrheit: Eine einzige Policy bringt dir wenig, ein durchdachtes Set aus fünf bis sieben Policies fast alles. Wer mit der MFA-für-alle-Policy startet, ohne vorher Notfall-Konten auszunehmen, sperrt sich früher oder später selbst aus. Dieser Leitfaden zeigt dir die Reihenfolge, die in der Praxis funktioniert – und die teuren Fehler, die du dir damit sparst.

Conditional Access sammelt erst alle passenden Policies ein – dann gewinnt die strengste Anforderung, und ein Block schlägt jedes Grant.

Wie Conditional Access überhaupt entscheidet

Bevor du auch nur eine Policy baust, musst du verstehen, wie die Engine tickt. Bei jeder Anmeldung sammelt Entra ID sämtliche Policies ein, deren Bedingungen auf den aktuellen Anmeldeversuch passen – also Benutzer, Cloud-App, Standort, Plattform, Gerätestatus und (mit P2) das Risiko. Diese Treffer werden nicht einzeln abgearbeitet, sondern zusammengefasst: Es gilt die jeweils strengste Anforderung aus allen passenden Grant-Policies.

Zwei Regeln solltest du dir tätowieren lassen. Erstens: Block schlägt alles. Eine einzige Block-Policy, die greift, verweigert den Zugriff – egal wie viele Grant-Policies sonst noch erfüllt sind. Zweitens: Was keine Policy trifft, läuft ungehindert durch. Es gibt kein implizites „Verbieten“ am Ende. Genau deshalb brauchst du eine Baseline, die möglichst alle Anmeldungen einfängt – sonst hast du Löcher, von denen du nichts weißt.

Die richtige Reihenfolge beim Aufbau

Der häufigste Anfängerfehler ist, gleich die schöne risikobasierte Policy zu bauen, von der alle reden – und das Fundament zu vergessen. Baue von unten nach oben. Jede Stufe wird erst sauber getestet und aktiviert, bevor die nächste kommt.

Von unten nach oben: erst Notfall-Konten und Admin-MFA, dann Breitenschutz, zuletzt Geräte- und Risikopolicies.

Warum diese Reihenfolge? Weil sie das größte Risiko zuerst abräumt und dich gleichzeitig vor dem Aussperren schützt. Notfall-Konten zuerst, weil sie dein Sicherheitsnetz für alles Folgende sind. Admin-MFA als Nächstes, weil ein übernommenes Admin-Konto der Super-GAU ist. Erst danach die Breite – und die feinen, teuren P2-Policies ganz zum Schluss, wenn du weißt, dass die Basis steht.

Das Baseline-Set, das in keinem Tenant fehlen darf

Du musst das Rad nicht neu erfinden. Es gibt ein Set von Policies, das in nahezu jeder Umgebung Sinn ergibt und zusammen den Großteil der gängigen Angriffe abfängt. Microsoft liefert die meisten davon inzwischen als vorkonfigurierte Vorlagen mit – trotzdem solltest du wissen, was sie tun.

Fünf Policies als Grundgerüst – mit Wirkung, benötigter Lizenz und dem empfohlenen Startmodus.

Niemals direkt scharf: der Report-only-Modus

Jede Policy, die mehr als eine Handvoll Konten betrifft, geht durch denselben Lebenszyklus. Der Report-only-Modus protokolliert, was die Policy tun würde – ohne tatsächlich zu blocken. Du siehst in den Sign-in Logs genau, wen es erwischt hätte, und korrigierst, bevor das Telefon klingelt.

Erst beobachten, dann auswerten, dann eng aktivieren, dann überwachen – das ist der sichere Weg jeder neuen Policy.

Break-Glass-Konten – dein Rettungsanker

Bevor du irgendetwas erzwingst, legst du zwei Notfall-Konten an. Reine Cloud-Konten (kein Sync aus dem On-Prem-AD), mit sehr langen, sicher hinterlegten Passwörtern, die von jeder MFA-erzwingenden Policy ausdrücklich ausgenommen sind. Diese Konten sind das, was dich rettet, wenn du dich mit einer Policy selbst ausgesperrt hast oder der MFA-Anbieter eine Störung hat.

Schließ die Break-Glass-Konten dann aber auch ab: dedizierte Überwachung auf jede Anmeldung, Alarm bei Nutzung, regelmäßige Passwort-Rotation. Ein ausgenommenes Konto ohne Überwachung ist keine Versicherung, sondern eine offene Tür.

Umsetzung – schneller Überblick per PowerShell

Klicken im Portal ist gut zum Lernen, aber für Audits und Wiederholbarkeit willst du die Policies abfragen können. Über das Microsoft Graph PowerShell SDK bekommst du alle Conditional-Access-Policies samt Status auf einen Blick:

Das State-Feld verrät dir sofort, welche Policy aktiv ist (enabled), welche nur beobachtet (enabledForReportingButNotEnforced) und welche aus ist (disabled). Eine Policy im Report-only-Modus, die du längst hättest scharf schalten sollen, fällt hier sofort auf.

Beispiel aus der Praxis

Die Trendforge Digital GmbH, ein cloud-first Tech-Startup mit 60 Leuten, kommt mit einem klassischen Problem: „Wir haben MFA aktiviert, aber irgendwie greift das nicht überall, und letzte Woche hat sich trotzdem jemand über ein altes Postfach-Protokoll eingeloggt.“

Beim Blick in den Tenant zeigt sich das typische Bild: eine einzige, gut gemeinte „MFA für alle“-Policy, direkt scharf geschaltet, ohne Block für Legacy-Authentifizierung. Die alten IMAP- und POP-Protokolle können aber gar keine moderne MFA – sie umgehen die Policy schlicht. Dazu kein einziges Break-Glass-Konto, dafür ein Admin, der sich beim letzten Test fast selbst ausgesperrt hätte.

Der Umbau folgt exakt der Reihenfolge von oben: erst zwei Break-Glass-Konten und Admin-MFA, dann eine separate Block-Policy gegen Legacy-Auth (zwei Wochen Report-only, weil noch ein altes Scan-to-Mail-Gerät dranhängt), danach die generalisierte MFA-Policy sauber neu aufgesetzt. Ergebnis: Das Legacy-Schlupfloch ist zu, die Anmeldungen sind nachvollziehbar, und der nächste Auditor findet eine dokumentierte Baseline statt Bastelei.

Verwandte Artikel

Häufige Fragen (FAQ)

Brauche ich für Conditional Access eine kostenpflichtige Lizenz?

Ja. Conditional Access setzt mindestens Entra ID P1 pro abgesichertem Benutzer voraus. Mit der Free-Lizenz bekommst du nur die Security Defaults – ein pauschaler MFA-Zwang ohne Feinsteuerung. Risikobasierte Policies aus Identity Protection brauchen sogar P2.

In welcher Reihenfolge sollte ich Conditional-Access-Policies aufbauen?

Von unten nach oben: erst Break-Glass-Konten ausnehmen, dann MFA für Admins, dann MFA für alle Benutzer, anschließend Geräte- und Plattformregeln inklusive Legacy-Auth-Block, und ganz zum Schluss die risikobasierten Feinpolicies. So räumst du das größte Risiko zuerst ab, ohne dich auszusperren.

Was passiert, wenn mehrere Policies gleichzeitig auf eine Anmeldung passen?

Entra ID wertet alle passenden Policies gemeinsam aus. Bei Grant-Policies gilt die strengste Anforderung. Eine Block-Policy hat aber immer Vorrang: Greift auch nur eine Block-Regel, ist der Zugriff verweigert – egal wie viele Grant-Bedingungen erfüllt wären.

Wofür ist der Report-only-Modus gut?

Report-only protokolliert in den Sign-in Logs, was eine Policy tun würde, ohne tatsächlich zu blocken. So siehst du vor der Aktivierung genau, wen es treffen würde, und korrigierst Fehlkonfigurationen, bevor jemand ausgesperrt wird. Jede breit wirkende Policy sollte ein bis zwei Wochen dort laufen.

Was sind Break-Glass-Konten und warum brauche ich sie?

Break-Glass-Konten sind zwei reine Cloud-Notfall-Admins mit langen, sicher verwahrten Passwörtern, die von jeder MFA-erzwingenden Policy ausgenommen sind. Sie sind dein Rettungsanker, wenn du dich mit einer Policy selbst aussperrst oder der MFA-Dienst ausfällt. Sie gehören überwacht und regelmäßig rotiert.

Reicht es nicht, einfach MFA für alle zu erzwingen?

Nein. Eine einzelne MFA-Policy lässt typischerweise Legacy-Authentifizierung offen, die moderne MFA gar nicht unterstützt – ein beliebtes Schlupfloch. Erst die Kombination aus Admin-MFA, Breiten-MFA, Legacy-Auth-Block und Geräteregeln ergibt einen wirksamen Schutz. Eine Policy allein ist Stückwerk.

Wie geht es weiter?