Vier Vorbedingungen verhindern die häufigsten Fehler.
1. Ziel und Geltungsbereich
Formulieren Sie pro Richtlinie einen Satz: „Diese Regel schützt Zielgruppe beim Zugriff auf Ressourcen gegen Risiko durch Kontrolle.“ Wenn dieser Satz nicht klar ist, wird die Regel später kaum wartbar sein.
2. Notfallzugriff testen
Halten Sie mindestens zwei getrennte, cloudbasierte Notfallzugriffskonten bereit. Sie sind von blockierenden Richtlinien ausgenommen, werden überwacht und regelmäßig getestet. Ein Ausschluss ist kein Freifahrtschein.
3. Pilotgruppe benennen
Wählen Sie repräsentative, informierte Benutzer aus unterschiedlichen Szenarien: Büro, mobil, extern, verwaltetes und nicht verwaltetes Gerät. Ein einzelner IT-Account ist kein ausreichend breiter Test.
4. Rückweg festlegen
Dokumentieren Sie, wer eine fehlerhafte Richtlinie deaktivieren darf, wie der Entscheidungsweg aussieht und wo die letzten funktionierenden Einstellungen nachvollziehbar sind.
Diese Fragen sollten Sie für jede Richtlinie beantworten.
Die Liste ersetzt keine fachliche Risikoentscheidung. Sie verhindert jedoch, dass wichtige Wirkungen oder Ausnahmen nur implizit bleiben.
Zielgruppen
Sind eingeschlossene Benutzer, Gruppen und Workload Identities korrekt? Sind Ausschlüsse begründet, zeitlich begrenzt und dokumentiert?
Zielressourcen
Ist klar, ob die Regel alle Ressourcen, Microsoft 365 oder eine einzelne Anwendung schützt? Deckt sie das beabsichtigte Zugriffsszenario wirklich ab?
Bedingungen
Sind Gerät, Standort, Clienttyp, Plattform, Risiko oder Netzwerkbedingungen bewusst gewählt? Jede zusätzliche Bedingung reduziert die Reichweite der Regel.
Grant Controls
Passt die Anforderung – MFA, Authentication Strength, konformes Gerät oder Block – zum Risiko? Werden bei kombinierten Controls „alle“ oder „eine“ Kontrollen verlangt?
Session Controls
Sind Anmeldehäufigkeit, Browser-Sitzung oder App-Restriktionen begründet? Prüfen Sie besonders die Auswirkung auf mobile und gemeinsam genutzte Geräte.
Lizenz und Signale
Prüfen Sie vor dem Design, ob benötigte Features und Risikosignale im Tenant verfügbar sind. Fehlende Lizenzinformationen sind eine Prüflücke, kein positives Ergebnis.
Von Report-only zu „On“ in fünf nachvollziehbaren Schritten.
1. Regel benennen und dokumentieren
Nutzen Sie ein Schema wie „CA01 – Admins – Alle Ressourcen – Phishing-resistant MFA“. Ergänzen Sie Zweck, Eigentümer und Link zur Freigabe.
2. Report-only einschalten
Report-only bewertet die Richtlinie bei Anmeldungen, erzwingt sie aber nicht. Prüfen Sie die Ergebnisse in den Anmeldeprotokollen und den Richtlinienauswirkungen.
3. Negative Fälle suchen
Untersuchen Sie nicht nur „Success“. Suchen Sie nach Benutzern, Geräten und Anwendungen, die bei Aktivierung blockiert oder zu zusätzlicher Aktion aufgefordert würden.
4. Pilot freigeben
Aktivieren Sie die Regel für die Pilotgruppe. Dokumentieren Sie echte Anmeldetests, Ausnahmen und Korrekturen vor der breiten Einführung.
5. Breiter Rollout und Wiederholung
Erst nach dokumentierter Wirkung wird die Zielgruppe erweitert. Prüfen Sie Richtlinien, Ausschlüsse und Notfallzugriff bei jeder wesentlichen Änderung erneut.
Abschlussnachweis
Eine Regel gilt als umgesetzt, wenn Zielgruppen und Ausschlüsse geprüft, Report-only-Ergebnisse bewertet, Pilotfälle getestet und der Go-live von der verantwortlichen Stelle freigegeben wurden.
Wichtig: Ausschlüsse sind ein eigenes Risiko.
Notfallzugriffskonten müssen bei blockierenden Richtlinien funktionsfähig bleiben. Andere dauerhafte Ausschlüsse sollten selten sein und eine nachvollziehbare Kompensationsmaßnahme haben. Microsoft empfiehlt, neue Regeln zuerst im Report-only-Modus auszuwerten und vor dem breiten Rollout mit einer Pilotgruppe zu testen.