Conditional-Access-Architektur

Eine Zugriffsregel ist ein Wenn-Dann-Satz

Conditional Access ist die Stelle, an der alles zusammenläuft, was die vorigen Module aufgebaut haben: Benutzer und Gruppen, Anmeldeverfahren, Gerätezustände. Die Dokumentation beschreibt eine Regel als Wenn-Dann-Satz aus zwei Teilen — den Zuweisungen und den Zugriffssteuerungen.

Zuweisungen

Das Wenn: wer, worauf, von wo und unter welchen Bedingungen. Benutzer und Gruppen, Zielressourcen, Netzwerk, Geräteplattform, Risiko.

Zugriffssteuerungen

Das Dann: sperren oder gewähren, und im Fall des Gewährens unter welchen Auflagen.

Zugriffsregel — Eine benannte Bedingung mit Rechtsfolge, die nach der ersten Anmeldestufe ausgewertet wird. Sie entscheidet nicht, wer jemand ist, sondern was unter den erkannten Umständen erlaubt sein soll.

Wer Regeln über Microsoft Graph liest oder schreibt, findet dieselbe Zweiteilung als Felder wieder: Unter conditions stehen die Zuweisungen mit users, applications, platforms und locations, unter grantControls die Steuerungen. In users trennen includeUsers und includeGroups von excludeUsers und excludeGroups — und der Wert All bedeutet dort wörtlich alle, was der häufigste Grund für eine Regel mit zu großer Reichweite ist.

Alle zutreffenden Regeln müssen erfüllt sein

Das ist die Eigenschaft, die man zuerst verstehen muss, weil sie dem Bauchgefühl widerspricht. Auf eine Anmeldung können mehrere Regeln gleichzeitig zutreffen — und dann müssen laut Dokumentation alle erfüllt sein. Es gibt keine erste passende Regel, die gewinnt, und keine Reihenfolge, in der sie abgearbeitet würden.

Verlangt eine Regel eine mehrstufige Authentifizierung und eine zweite ein konformes Gerät, dann braucht es beides. Innerhalb einer einzelnen Regel gilt dasselbe für die Zuweisungen: Sie werden mit UND verknüpft, alle müssen zutreffen, damit die Regel überhaupt auslöst.

Nur an einer Stelle steht ein Oder: Bei der Einstellung, dass eine der ausgewählten Steuerungen genügt, erscheinen die Abfragen in der festgelegten Reihenfolge, und sobald eine erfüllt ist, wird der Zugriff gewährt.

Aus dieser Verknüpfung folgt eine Eigenschaft, die den Entwurf prägt: Regeln lassen sich verschärfen, indem man eine weitere hinzufügt, aber nicht lockern. Eine zusätzliche Regel kann nie erlauben, was eine bestehende verbietet — sie kann nur weitere Auflagen hinzufügen. Wer eine Ausnahme braucht, muss sie deshalb als Ausschluss in die bestehende Regel schreiben, nicht als neue, großzügigere Regel danebenstellen.

Zwei Phasen, und eine davon läuft auch im Testbetrieb

Die Auswertung geschieht laut Dokumentation in zwei Phasen, und der Unterschied zwischen ihnen erklärt später eine unerwartete Nebenwirkung.

Der entscheidende Satz: Phase 1 läuft für aktivierte Regeln und für Regeln im reinen Berichtsmodus. Phase 2 dagegen nur für aktivierte Regeln. Eine Regel im Testbetrieb setzt also nichts durch — sie sammelt aber sehr wohl Angaben, und dieses Sammeln ist nicht immer unsichtbar.

Reiner Berichtsmodus — Ein Zustand, in dem eine Regel bei jeder Anmeldung ausgewertet und das Ergebnis protokolliert wird, ohne dass der Zugriff davon abhängt. Der übliche Weg, die Wirkung einer Regel vor dem Scharfschalten zu messen.

Eine Regel kennt genau drei Zustände, und sie stehen im Feld state: disabled für ausgeschaltet, enabledForReportingButNotEnforced für den Berichtsmodus und enabled für scharf. Der mittlere Wert ist sperrig und sagt genau, was er tut — er wird ausgewertet und berichtet, aber nicht durchgesetzt.

Die Zustände sind kein Ersatz für einen Freigabeprozess. Eine Regel von enabledForReportingButNotEnforced auf enabled zu setzen, ist eine einzige Feldänderung mit sofortiger Wirkung auf jede erfasste Anmeldung — technisch eine Kleinigkeit, betrieblich der eigentliche Änderungsvorgang. Wer Regeln als Text verwaltet, sollte genau diese Änderung gesondert prüfen lassen.

Was Conditional Access nicht ist

Eine Formulierung aus der Dokumentation lohnt es wörtlich zu nehmen: Zugriffsregeln werden nach Abschluss der ersten Authentifizierungsstufe durchgesetzt. Sie sind ausdrücklich nicht als vorderste Verteidigungslinie gedacht.

Praktisch heißt das: Ein gestohlenes Kennwort wird geprüft, bevor eine Regel überhaupt zum Zug kommt. Die Regel entscheidet danach, ob das genügt. Wer glaubt, eine Zugriffsregel verhindere, dass ein Kennwort ausprobiert wird, hat die Reihenfolge falsch im Kopf — und wählt dann die falschen Gegenmaßnahmen für Angriffe, die auf die Anmeldung selbst zielen.

Sichtbar wird die Reihenfolge in den Anmeldeprotokollen: Ein Versuch mit richtigem Kennwort, der an einer Zugriffsregel scheitert, erscheint als Anmeldung mit einem eigenen Fehlerbefund zur Regel — nicht als fehlgeschlagene Kennworteingabe. Beides auseinanderzuhalten ist der erste Schritt jeder Untersuchung: Der eine Fall sagt, dass jemand das Kennwort nicht hat, der andere, dass jemand es hat und trotzdem nicht hineinkommt. Der zweite ist der interessantere.

Die Dokumentation zieht daraus selbst eine Grenze: Zugriffsregeln sind ausdrücklich nicht als Abwehr gegen Überlastungsangriffe gedacht, können deren Signale aber in ihre Entscheidungen einbeziehen. Sie sind ein Werkzeug der Autorisierung, nicht der Verfügbarkeit.

Gewähren und Sperren

Auf der Seite der Steuerungen gibt es zwei Grundentscheidungen. Sperren ist laut Dokumentation die restriktivste Entscheidung und die mächtigste — sie verlangt entsprechende Sorgfalt. Gewähren löst eine oder mehrere Auflagen aus.

• Mehrstufige Authentifizierung verlangen
• Eine bestimmte Anmeldestärke verlangen — die eingebauten Stärken aus dem vorigen Modul
• Ein als konform gekennzeichnetes Gerät verlangen
• Ein hybrid eingebundenes Gerät verlangen
• Eine genehmigte Clientanwendung oder eine Anwendungsschutzrichtlinie verlangen

Wer sperrt, sollte sich klarmachen, dass eine Sperre keine Auflage ist, die jemand erfüllen könnte. Sie beendet den Vorgang. Deshalb ist der häufigste Entwurfsfehler nicht eine zu schwache Auflage, sondern eine Sperre, deren Umfang breiter ist als beabsichtigt.

In der Schnittstelle tragen diese Steuerungen kurze, feste Namen, die man kennen sollte, weil Regeln zunehmend als Text verwaltet werden: block für die Sperre, mfa für die mehrstufige Anmeldung, compliantDevice für das konforme Gerät, domainJoinedDevice für die hybride Einbindung und passwordChange für den erzwungenen Kennwortwechsel. Daneben steht operator mit den Werten AND und OR — er entscheidet, ob alle ausgewählten Auflagen nötig sind oder eine genügt.

Ein Blick auf diese Namen beantwortet eine Frage schneller als jede Oberfläche: compliantDevice und domainJoinedDevice sehen im Portal nebeneinander aus wie zwei Abstufungen derselben Sache. Es sind zwei verschiedene Bedingungen mit verschiedenen Plattformgrenzen, wie das vorige Modul gezeigt hat — und im Text der Regel ist das sofort sichtbar.

Der Token-Effekt: warum eine Gruppenänderung nicht sofort wirkt

Hier steht ein Satz in der Dokumentation, der im Betrieb regelmäßig für Verwirrung sorgt und den kaum jemand kennt: Regeln, die auf Rollen oder Gruppen zielen, werden nur ausgewertet, wenn ein Token ausgestellt wird.

Die Folge ist ausdrücklich benannt: Wer neu in eine Rolle oder Gruppe aufgenommen wird, unterliegt der Regel erst, sobald er ein neues Token erhält. Bis dahin arbeitet die Person mit den Verhältnissen von vorher weiter — nicht wegen einer Verzögerung im Abgleich, sondern weil die Regel an dieser Stelle gar nicht neu bewertet wird.

Der reine Berichtsmodus und seine vier Ergebnisse

Vor dem Scharfschalten gehört jede Regel in den Berichtsmodus. Die Ergebnisse stehen in den Anmeldeprotokollen, in eigenen Registerkarten für Conditional Access und für den Berichtsmodus. Vier Ergebnisse sind möglich, und sie bedeuten Verschiedenes:

Report-only: Success

Alle Bedingungen und alle ohne Zutun erfüllbaren Auflagen waren erfüllt — etwa weil das Token bereits einen Nachweis der mehrstufigen Anmeldung enthielt.

Report-only: Failure

Die Bedingungen trafen zu, aber eine Auflage war nicht erfüllt — oder es war eine Sperre konfiguriert.

Report-only: User action required

Die Bedingungen trafen zu, und die Person hätte etwas tun müssen. Im Berichtsmodus wird sie dazu nicht aufgefordert.

Report-only: Not applied

Die Bedingungen trafen nicht zu — die Person ist ausgenommen, oder die Regel gilt nur für bestimmte Standorte.

Zu unterscheiden ist außerdem das schlichte Success einer aktivierten Regel: Es bedeutet, dass diese Regel den Zugriff zugelassen hätte. Die Dokumentation setzt ausdrücklich hinzu, dass die Anmeldung trotzdem durch eine andere Regel gesperrt sein kann — die Bestätigung gilt immer nur je Regel, nie für die Anmeldung als Ganzes.

Der Berichtsmodus ist nicht nebenwirkungsfrei

Weil Phase 1 auch für Regeln im Berichtsmodus läuft, kann eine vermeintlich folgenlose Testregel Spuren hinterlassen. Die Dokumentation warnt ausdrücklich vor einem Fall.

Regeln im Berichtsmodus, die ein konformes Gerät verlangen, können Anwenderinnen auf macOS, iOS und Android dazu auffordern, während der Auswertung ein Gerätezertifikat auszuwählen — obwohl die Konformität gar nicht durchgesetzt wird. Diese Aufforderungen können sich wiederholen, bis das Gerät konform ist.

Die empfohlene Gegenmaßnahme steht dabei: Diese Geräteplattformen von Regeln im Berichtsmodus ausnehmen, die eine Konformitätsprüfung vornehmen. Wer das nicht tut, erzeugt genau das, was der Berichtsmodus vermeiden sollte — eine spürbare Änderung für Anwender, noch bevor irgendetwas gilt.

Ausschlüsse: die Regel, die dich selbst aussperrt

Die klassische Katastrophe in diesem Bereich ist eine Regel, die alle Benutzer erfasst, eine Bedingung verlangt, die niemand mehr erfüllen kann, und damit auch jeden aussperrt, der sie zurücknehmen könnte.

Deshalb gehören die Notfallzugangskonten aus dem ersten Modul in die Ausschlussliste jeder Regel, die sperren oder eine Auflage erzwingen kann. Das ist der Preis, der dort schon benannt wurde: Diese Konten sind bewusst von den Schutzmaßnahmen ausgenommen, damit die Schutzmaßnahmen sie im Ernstfall nicht blockieren.

• Notfallzugangskonten ausschließen — ohne Ausnahme, in jeder sperrenden Regel.
• Ausschlüsse so eng wie möglich fassen: eine Gruppe für den Notfallzugang, nicht eine Sammelgruppe für alles Unbequeme.
• Ausschlüsse regelmäßig durchsehen — ein Ausschluss ist eine dauerhafte Lücke, die sich niemand merkt.
• Beim Prüfen der Regel bedenken, dass eine Aufnahme in die Ausnahmegruppe erst mit einem neuen Token wirkt.

Was passiert, wenn die Lizenz ausläuft

Zugriffsregeln setzen Microsoft Entra ID P1 voraus; Kunden mit Microsoft 365 Business Premium können sie ebenfalls nutzen. Risikobasierte Regeln brauchen zusätzlich P2, weil sie auf den Identitätsschutz zugreifen.

Interessant ist der dokumentierte Fall des Ablaufs: Laufen die nötigen Lizenzen aus, werden vorhandene Regeln nicht automatisch deaktiviert oder gelöscht. Die Dokumentation nennt das einen geordneten Zustand, der einen Ausstieg ohne plötzliche Änderung der Sicherheitslage erlaubt — man kann die verbliebenen Regeln ansehen und löschen, aber nicht mehr ändern.

Bemerkenswert ist die Entwurfsentscheidung dahinter. Der bequeme Weg wäre gewesen, abgelaufene Regeln stillzulegen — dann wäre niemand ausgesperrt. Genau das wäre aber eine stille Absenkung des Schutzniveaus zu einem Zeitpunkt, an dem niemand hinsieht. Die gewählte Variante hält den Schutz aufrecht und nimmt dafür in Kauf, dass die Verwaltung eingeschränkt ist. Das ist dieselbe Abwägung wie beim Notfallzugang, nur andersherum: Hier gewinnt die Wirksamkeit, dort die Erreichbarkeit.

Durchgerechnet: eine Regel einführen

Der Preis dieses Vorgehens ist die Dauer: Zwischen Anlegen und Wirken liegen Tage. In dieser Zeit schützt die Regel nichts — der Berichtsmodus setzt nichts durch. Wer auf eine akute Bedrohung reagiert, muss diesen Weg abkürzen und trägt dann bewusst das Risiko, jemanden auszusperren. Das ist eine vertretbare Entscheidung, solange sie eine Entscheidung ist und keine Unachtsamkeit.

Die Reihenfolge, die alles zusammenhält

Conditional Access ist mächtig, weil es alle Signale des Tenants an einer Stelle zusammenführt. Aus demselben Grund ist es der Ort, an dem ein Denkfehler die größte Reichweite hat: Eine einzelne falsche Zuweisung wirkt auf jede Anmeldung, die sie erfasst, sofort und gleichzeitig.