Wer in einem größeren Mandanten Conditional Access pflegt, kennt das Problem: Die Liste der Richtlinien wächst, und niemand weiß mehr genau, welche Ausnahme wo gilt. Microsoft bietet dafür jetzt in der Public Preview die Conditional-Access-Policy-Plans an. Damit fassen Sie verwandte Richtlinien in einem Plan zusammen und definieren Benutzer, Ressourcen und Bedingungen nur noch einmal.

Ein Policy Plan bündelt gemeinsame Einstellungen und trennt sie von den Regeln

Bisher war jede Conditional-Access-Richtlinie ein eigenständiges Objekt. Wollten Sie für dieselbe Benutzergruppe sowohl phishing-resistente MFA als auch ein konformes Gerät verlangen, mussten Sie zwei Richtlinien anlegen und in beiden dieselben Gruppen und Ausnahmen pflegen. Bei Dutzenden Richtlinien hilft dann oft nur noch ein Namenspräfix, um den Überblick zu behalten.

Ein Plan dreht diese Logik um. Auf Plan-Ebene legen Sie fest, welche Identitäten, Ressourcen, Client-App-Typen, Netzwerkstandorte oder Risikostufen gelten. Jede Regel im Plan erbt diese Angaben und ergänzt nur noch ihre eigenen Bedingungen sowie die Grant- oder Session-Controls. Ein Plan hat außerdem Name, Beschreibung, Besitzer und Tags, sodass sofort erkennbar ist, wofür er gedacht ist. Das Modell erklärt die Microsoft-Dokumentation zu Policy Plans ausführlich.

Wichtig für die Praxis: Jede Regel wird bei der Anmeldung weiterhin einzeln ausgewertet. Es gibt keine Rangfolge zwischen Regeln und klassischen Richtlinien, alle zutreffenden Vorgaben müssen erfüllt sein. Ein Plan ist also ein Verwaltungskonzept und keine neue Durchsetzungslogik.

Die Vererbung vom Plan an die Regeln lässt sich in einem Diagramm nachvollziehen

Das folgende Diagramm zeigt am Beispiel eines Plans für Mitarbeitende am Hauptstandort, wie die Einstellungen von oben nach unten weitergereicht werden. Die Ausnahmegruppe für Notfallkonten sitzt einmal im Plan und wirkt dadurch auf jede Regel.

flowchart TD
    A["Plan: Hauptstandort"] --> B["Gemeinsam: Benutzergruppe"]
    A --> C["Gemeinsam: Notfallkonten-Ausnahme"]
    B --> D["Regel 1: Phishing-resistente MFA"]
    B --> E["Regel 2: Konformes Gerät"]
    C --> D
    C --> F["Regel 3: Neue Regel später"]
    B --> F

Der Plan gibt Benutzergruppe und Ausnahme an alle Regeln weiter, jede Regel ergänzt nur ihre eigene Anforderung.

Gemeinsame Ausschlüsse sind kumulativ. Schließt eine Regel zusätzlich eine weitere Gruppe aus, gelten beide Ausschlüsse, und eine Regel kann einen vom Plan geerbten Ausschluss nicht aufheben. Das ist praktisch für Break-Glass-Konten, aber ein Risiko, wenn Sie Richtlinien mit unterschiedlichen Ausnahmen in denselben Plan packen.

Bestehende Richtlinien migrieren Sie mit einem Assistenten im Entra Admin Center

Sie müssen nicht bei null anfangen. Im Microsoft Entra Admin Center filtern Sie unter „Schutz“ > „Bedingter Zugriff“ Ihre Richtlinienliste, etwa nach einem Namenspräfix, markieren die gewünschten Einträge und starten die Migration. Der Assistent sucht nach Gemeinsamkeiten, zieht diese auf Plan-Ebene und macht aus jeder Richtlinie eine Regel. Wie das im Detail abläuft, steht in der Anleitung zum Migrieren von Richtlinien in einen Plan.

Die ursprünglichen Richtlinien bleiben dabei unverändert und werden weiter durchgesetzt. In einem Praxistest eines Community-Autors blieben die neuen Regeln zunächst ausgeschaltet. Außerdem war die Break-Glass-Gruppe nicht automatisch auf Plan-Ebene gelandet, obwohl sie in allen Ursprungsrichtlinien stand. Diese Ausnahme sollten Sie also selbst ergänzen und das Ergebnis prüfen.

Für die Preview gelten derzeit zwei Einschränkungen. „Alle Benutzer“ lässt sich nicht als gemeinsame Zuweisung auf Plan-Ebene wählen, und „Alle Ressourcen“ muss in der Regel selbst gesetzt werden. Außerdem dokumentiert Microsoft eine Einschränkung bei Standortbedingungen: Dafür erhalten Benutzer in der Preview Zugriffstoken mit einer Stunde Laufzeit, ohne sofortige IP-Prüfung. Sicherheitskritische Standortregeln lasse ich deshalb vorerst in klassischen Richtlinien.

Der Umstieg gelingt am sichersten in fünf Schritten mit Report-only-Modus

Ich empfehle, einen Plan nie direkt scharfzuschalten. Die folgenden Schritte führen Sie im Entra Admin Center unter „Schutz“ > „Bedingter Zugriff“ > „Policy plans“ durch. Ein typisches Beispiel für eine solche Regel ist die Sperre von Admin-Portalen für ungeprüfte Geräte, die ich im Beitrag zur Conditional-Access-Richtlinie für Admin-Portale beschrieben habe. Sie benötigen dafür mindestens die Rolle „Administrator für bedingten Zugriff“ und eine Entra-ID-P1-Lizenz.

  1. Wählen Sie verwandte Richtlinien mit gleichem Sicherheitsziel aus und starten Sie die Migration oder legen Sie einen neuen Plan an.
  2. Prüfen Sie die gemeinsamen Einstellungen auf Plan-Ebene gegen jede Ursprungsrichtlinie, besonders Gruppen, Ressourcen und Gerätefilter.
  3. Ergänzen Sie die Break-Glass-Gruppe als gemeinsamen Ausschluss, falls der Assistent sie nicht übernommen hat.
  4. Stellen Sie die neuen Regeln auf „Nur Bericht“ und vergleichen Sie die Ergebnisse in den Anmeldeprotokollen mit den bisherigen Richtlinien.
  5. Aktivieren Sie die Regeln erst nach dieser Prüfung und deaktivieren Sie danach die alten Richtlinien, ohne sie sofort zu löschen.

Den Vergleich im vierten Schritt unterstützt der Bericht zum Report-only-Modus. Er zeigt, welche Anmeldungen eine Regel blockiert oder zusätzlich gefordert hätte.

Tipp: Legen Sie auf Plan-Ebene nur Einstellungen ab, die für jede heutige und künftige Regel gelten sollen. Alles, was später abweichen könnte, gehört in die einzelne Regel.

Auch Agenten-Identitäten lassen sich in einem eigenen Plan absichern

Microsoft liefert Vorlagen mit, aus denen Sie einen Plan nicht von Grund auf bauen müssen. Das Beispiel aus der Ankündigung auf der Microsoft Tech Community ist ein Plan für Agentenrisiko: Als gemeinsame Bedingung gilt ein hohes Agentenrisiko, darunter blockiert eine Regel Agenten-Benutzer und eine weitere autonome Agenten mit eigenen Berechtigungen. Ohne Plan wären dafür getrennte Richtlinien mit weitgehend identischen Bedingungen nötig.

Gerade bei Umgebungen, die bereits per Skript oder Pipeline verwaltet werden, bremse ich etwas. Die Graph-Endpunkte für Policy Plans liegen derzeit nur in der Beta-Version vor und sind für Produktivlösungen nicht freigegeben. Prüfen Sie daher zuerst, ob Ihr Export-, Backup- und Drift-Werkzeug die neuen Objekte kennt.

Für große Richtliniensätze lohnt sich der Plan, für kleine Mandanten meist noch nicht

Der größte Gewinn zeigt sich nicht bei der Einrichtung, sondern bei späteren Änderungen: Eine gemeinsame Bedingung ändern Sie einmal statt dreimal. Umgekehrt wirkt ein Fehler dort auch auf alle Regeln gleichzeitig. Bei zwei oder drei einfachen Richtlinien, die sich selten ändern, lohnt der Umstieg kaum.

Mein Vorgehen ist deshalb selektiv. Neue, klar abgegrenzte Szenarien lege ich als Plan an, bestehende Baselines migriere ich erst, wenn Export und Wiederherstellung der neuen Objekte sauber funktionieren.