Conditional Access für gewachsene Tenants

Conditional Access wächst in den meisten Tenants, die wir übernehmen, Policy für Policy. Jede einzelne Regel hat zum Zeitpunkt ihrer Entstehung meist Sinn ergeben. Zwei Jahre und vier Admins später kann niemand mehr sagen, warum eine bestimmte Ausnahme existiert, ob sie noch gebraucht wird, oder was kaputtgeht, wenn man sie entfernt. Aus unserer Erfahrung zeigt sich dieses Muster fast immer gleich: Dutzende Policies ohne einheitliche Benennung, ohne klaren Owner, und Ausnahmen, die niemand mehr erklären kann.

Das ist kein Conditional-Access-Problem. Es ist ein Governance-Problem, das Conditional Access nur sichtbar macht. Wir haben das mittlerweile oft genug gemacht, dass wir es zu einem Framework formalisiert haben, und wir haben es als Open Source veröffentlicht: das CDT Conditional Access Framework auf GitHub, aktuell im Release 26H2.

Erst verstehen, dann anfassen

Bevor auch nur eine Policy geändert wird, muss dokumentiert werden, was tatsächlich vorhanden ist: bestehende Policies, Ausnahmen, Break-Glass-Konten, Authentifizierungsmethoden und die betroffenen Anwendungen je Policy. In unserer Erfahrung ist die Konfiguration selten der schwierige Teil. Schwierig ist es, zu rekonstruieren, warum eine Ausnahme überhaupt entstanden ist, denn dieser Kontext steckt meist im Kopf einer Person, nicht im Tenant.

Drei Stufen statt einer flachen Regelliste

Ohne Framework passiert meist Folgendes: Jede neue Anforderung wird zu einer eigenen Einzelpolicy, zugeschnitten auf die eine Identität, die sie in der jeweiligen Woche brauchte. Nach einem halben Jahr liegt ein Haufen Regeln mit überlappendem Scope vor, ohne nachvollziehbare Reihenfolge. Die Struktur, die wir mittlerweile einsetzen, trennt das in drei Stufen:

Global Foundation
        ↓
Persona Protection
        ↓
Advanced Protection

Global Foundation ist der minimale, tenant-weite Schutz, der vor allem Persona-Spezifischen greift: Bootstrap-MFA, Blockierung veralteter Authentifizierung, Blockierung von Device Code Flow, Blockierung nicht unterstützter Plattformen, Blockierung nicht vertrauenswürdiger Standorte, Schutz der Verwaltungsportale und der Registrierung von Sicherheitsinformationen.

MFA an sich ist kein Unterscheidungsmerkmal mehr. Fast jeder Tenant, den wir übernehmen, hat es irgendwo bereits aktiviert. Was eine reife Umgebung tatsächlich von einer fragilen unterscheidet, ist, ob diese Anforderung konsequent und dort, wo es zählt, phishing-resistent ist, oder nur vorhanden.

Persona Protection existiert nur dort, wo sich Identitäten tatsächlich unterschiedlich verhalten. Admins brauchen eine stärkere, phishing-resistente Authentifizierung, nicht denselben MFA-Prompt wie ein normaler interner Nutzer. Ein Gastkonto braucht ein anderes Sitzungsmodell als ein Mitarbeitender. Global nutzen, wenn die Anforderung für alle gleich ist. Eine Persona nur dann, wenn die Anforderung sich tatsächlich unterscheidet. Dieselbe Kontrolle über fünf Personas zu duplizieren, weil es gründlich wirkt, erzeugt in den meisten Fällen Wartungsaufwand ohne echten Sicherheitsgewinn. Die Ausnahme ist ein regulierter Kunde, dessen Auditor eine Kontrolle explizit einer benannten Persona zugeordnet sehen will, was häufiger vorkommt, als man denkt. Außerhalb davon raten wir eher ab.

Advanced Protection umfasst Kontrollen mit hoher Wirkung, die erst nach ausreichender operativer Reife sicher aktiviert werden sollten: Hard-Delete-Schutz, Authentication Context, strikte Standortdurchsetzung, erhöhte Insider-Risk-Kontrollen. Diese kommen zuletzt, wenn Foundation und Persona stabil und validiert sind.

Eine Namenskonvention, die einen Personalwechsel übersteht

Jede Policy folgt demselben Muster:

<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>

Zum Beispiel:

CA100-Admins-IdentityProtection-AnyApps-AnyPlatform-MFA-PhishingResistant

Die Persona bestimmt den Nummernbereich: CA000 bis CA099 ist Global, CA100 bis CA199 sind Admins, CA200 bis CA299 sind Internals, CA300 bis CA399 sind Externals, CA400 bis CA499 sind GuestUsers, und es geht weiter über Agents, ServiceAccounts, WorkloadIdentities bis zu ServiceProviders. Innerhalb einer Persona folgen die letzten beiden Ziffern einer Capability-Reihenfolge: x00 für Authentifizierung, x01 für Gerät, x02 für Netzwerk, x03 für Mobile, x04 für Session, x05 für Browser, x06 für Daten, x50 für Advanced Protection.

Das klingt nach viel Aufwand, bis man der dritte Administrator ist, der den Tenant übernimmt. Dann sagt eine Policy namens CA204-Internals-AttackSurfaceReduction-AllApps-AllPlatforms-Block-UntrustedLocations genau, was sie tut und warum sie existiert, ohne sie zu öffnen. Der Name ersetzt das Erfahrungswissen, das sonst mit demjenigen geht, der die Policy ursprünglich angelegt hat.

Report-only ist ein Arbeitsmodus, keine Verzögerung

Report-only ersetzt keine Entscheidung, es liefert die Daten, um eine sichere Entscheidung zu treffen. Wir werten Sign-in-Logs nach Benutzergruppen, Anwendungen, Geräteplattformen und Fehlerbildern aus, bevor irgendetwas in den erzwungenen Modus wechselt. Eine Kleinigkeit, die immer wieder überrascht: Die Standard-Aufbewahrung der Sign-in-Logs beträgt 30 Tage, was für einen sauber validierten Foundation-Rollout zu kurz ist. Vor Beginn der Report-only-Phase in einen Log-Analytics-Workspace einspeisen lassen, nicht erst, wenn jemand nach drei Monaten Historie fragt, die dann fehlt. Die Rollout-Reihenfolge, die wir bei Kunden konsequent einsetzen:

1. Mindestens zwei Emergency-Access-Konten definieren und jede Deployment-Ausnahme dokumentieren.
2. Global Foundation im Report-only-Modus ausrollen.
3. Gegen echte Sign-in-Daten validieren: betroffene Nutzer, Anwendungen, Authentifizierungsflüsse, Plattformen.
4. Bootstrap Global MFA als tenant-weite Untergrenze aktivieren.
5. Persona-spezifische MFA- und Schutz-Policies ausrollen und validieren.
6. Persona-Policies in kontrollierten Stufen aktivieren, nicht auf einmal.
7. Global MFA erst deaktivieren, wenn eine gleichwertige Persona-MFA-Abdeckung bestätigt ist, nicht früher.
8. Advanced Protection entsprechend der tatsächlichen operativen Reife des Kunden einführen.
9. Regelmäßig überprüfen, und jede Ausnahme dokumentieren, wenn sie entsteht, nicht Monate später.

Die eigentliche Herausforderung in diesem Prozess ist fast nie technischer Natur. Es ist die Disziplin, Policies lange genug im Report-only-Modus zu lassen, um den Daten zu vertrauen, und Global MFA erst zu deaktivieren, wenn die Persona-Abdeckung sie wirklich ersetzt.

Was jede Policy braucht, unabhängig vom Framework

• Einen klaren Zweck und einen definierten Identitäts-Scope.
• Einen dokumentierten Anwendungs- und Plattform-Scope. SpecificApps darf in der Produktion nie ein undefinierter Platzhalter bleiben.
• Eine bekannte Lizenzanforderung. Der Großteil des Frameworks läuft auf Entra ID P1. User-Risk- und Sign-in-Risk-Bedingungen brauchen konkret P2, und das lohnt sich zu prüfen, bevor eine Policy um ein Signal herum designt wird, das der Tenant gar nicht lizenziert auswerten kann.
• Einen Owner und ein Review-Datum.
• Dokumentierte Ausnahmen, mit dem Grund, warum sie existieren.
• Einen getesteten Rollback-Weg.

Benennung, Scope und Ausschlüsse müssen für einen Administrator verständlich sein, der nicht im Raum war, als die Policy entstanden ist, denn irgendwann ist das jeder.

Im Betrieb verankern, nicht als einmaliges Projekt

Die Migration selbst ist selten der schwierige Teil. Schwierig ist es, das Modell korrekt zu halten, während sich Anwendungen, Identitäten und Geräte darunter laufend verändern. Policies brauchen einen Owner und einen wiederkehrenden Review, sonst driftet das Sicherheitsmodell unbemerkt, bis ein Incident die Frage erzwingt.

Das Ziel war nie die maximale Anzahl an Policies. Es ist ein kleines, verständliches System, das Risiken reduziert und für denjenigen betreibbar bleibt, der um 2 Uhr nachts Bereitschaft hat, nicht nur für die Person, die es ursprünglich gebaut hat.