Conditional Access verstehen, Teil 2: Anatomie einer Richtlinie

In Teil 1 haben wir geklärt, was Conditional Access ist und welche Lizenz ihr braucht. Jetzt öffnen wir die Motorhaube: Woraus besteht eine Richtlinie, was bedeuten die vielen Schalter – und was passiert, wenn mehrere Richtlinien gleichzeitig zutreffen?

Das Minimum einer Richtlinie

Damit eine Richtlinie überhaupt etwas bewirkt, braucht sie mindestens vier Dinge:

1. Einen Namen, an dem ihr später erkennt, was sie tut.
2. Benutzer (oder Workload-Identitäten), für die sie gilt.
3. Zielressourcen, also die Apps oder Aktionen, die sie schützt.
4. Ein Steuerelement: gewähren mit Bedingungen oder blockieren.

Alles andere – Netzwerk, Geräteplattform, Client-Apps, Risiko – ist optional und schränkt ein, wann die Richtlinie greift.

Zuweisungen: Wer und was?

Benutzer, Gruppen und Rollen

Hier legt ihr fest, für wen die Richtlinie gilt. Ihr könnt einschließen und ausschließen – und ein Ausschluss gewinnt immer gegen einen Einschluss. Zur Auswahl stehen alle Benutzer, bestimmte Gruppen, Verzeichnisrollen wie „Globaler Administrator“ sowie Gäste und externe Benutzer. Mit einer Workload-ID-Lizenz könnt ihr außerdem Dienstprinzipale ansprechen.

Ein Detail, das viele überrascht: Richtlinien, die auf Gruppen oder Rollen zielen, werden bei der Ausstellung eines Tokens ausgewertet. Wer gerade frisch in eine Gruppe aufgenommen wurde, ist erst nach dem nächsten Token betroffen. Bei Admin-Rollen, die per Privileged Identity Management aktiviert werden, solltet ihr die MFA deshalb direkt bei der Aktivierung verlangen.

Zielressourcen

Früher hieß dieser Bereich „Cloud-Apps“, heute Zielressourcen. Darunter fallen:

• Ressourcen (ehemals Cloud-Apps): Microsoft-Dienste wie Exchange Online, SharePoint oder die Windows Azure Service Management API, aber auch eure eigenen Enterprise-Apps. Die Option „Alle Ressourcen“ schützt jede Tokenanfrage – auch Dienste, die ihr einzeln gar nicht auswählen könnt.
• Benutzeraktionen: „Sicherheitsinformationen registrieren“ und „Geräte registrieren oder beitreten“. Damit schützt ihr etwa die MFA-Registrierung selbst.
• Authentifizierungskontext: ein Etikett, mit dem ihr besonders sensible Bereiche innerhalb einer App schützt – mehr dazu in Teil 5.
• Global Secure Access: Datenverkehrsprofile, wenn ihr Microsofts SSE-Lösung nutzt.

Netzwerk

Was früher „Standorte“ hieß, heißt jetzt Netzwerk. Ihr könnt benannte Standorte anlegen – IP-Bereiche eurer Büros oder ganze Länder – und sie als vertrauenswürdig markieren. Der Standort ergibt sich aus der öffentlichen IP-Adresse oder, wenn ihr das so einstellt, aus dem GPS der Authenticator-App. Auch wenn ihr Standorte nicht in Richtlinien nutzt, lohnt sich das Anlegen: Entra ID Protection bewertet Anmeldungen aus bekannten Netzen als weniger riskant.

Bedingungen: Wann genau?

Bedingungen verfeinern, unter welchen Umständen die Richtlinie greift. Nicht konfigurierte Bedingungen gelten als erfüllt.

Bedingung	Wofür ihr sie nutzt
Benutzerrisiko	Konto wahrscheinlich kompromittiert, z. B. durch geleakte Zugangsdaten (P2)
Anmelderisiko	diese eine Anmeldung ist verdächtig, z. B. anonyme IP-Adresse (P2)
Geräteplattformen	Android, iOS, Windows, macOS, Linux
Client-Apps	Browser, moderne Clients, Exchange ActiveSync, „Andere Clients“ (veraltete Protokolle)
Filter für Geräte	Geräte anhand von Eigenschaften wie Hersteller, Modell oder Erweiterungsattribut
Authentifizierungsflüsse	Device Code Flow und Authentifizierungsübertragung

Zwei Dinge solltet ihr wissen: Die Geräteplattform wird aus dem User-Agent abgeleitet und lässt sich fälschen – blockiert deshalb nie „nur Windows erlauben“, ohne zusätzlich ein konformes Gerät zu verlangen. Und die alte Bedingung Gerätestatus ist abgekündigt; nutzt stattdessen den Filter für Geräte, etwa mit device.isCompliant oder device.trustType.

Steuerelemente: Was passiert dann?

Gewähren oder blockieren

Zugriff blockieren ist das schärfste Werkzeug. Es gewinnt immer und sollte entsprechend vorsichtig eingesetzt werden. Zugriff gewähren lässt sich an Bedingungen knüpfen:

• Multifaktor-Authentifizierung verlangen
• Authentifizierungsstärke verlangen – etwa nur phishing-resistente Methoden (Teil 4)
• Gerät muss als konform markiert sein (Intune)
• In Microsoft Entra hybrid eingebundenes Gerät
• App-Schutzrichtlinie verlangen (Intune MAM auf iOS und Android)
• Kennwortänderung bzw. Risikobehebung verlangen (bei Benutzerrisiko)
• Nutzungsbedingungen, sofern ihr welche angelegt habt

Wählt ihr mehrere Steuerelemente, entscheidet ihr, ob alle oder nur eines davon erfüllt sein muss. „MFA oder konformes Gerät“ ist zum Beispiel eine beliebte Kombination: Auf dem Firmenlaptop gibt es keine zusätzliche Abfrage, auf dem fremden Rechner muss MFA her.

Sitzung

Sitzungssteuerelemente greifen nach dem Gewähren und bestimmen, wie die Sitzung aussieht:

• Anmeldehäufigkeit: wie oft sich jemand neu anmelden muss – bis hin zu „jedes Mal“.
• Beständige Browsersitzung: ob „Angemeldet bleiben“ erlaubt ist.
• Von der App erzwungene Einschränkungen: z. B. nur Webzugriff ohne Download in SharePoint und Exchange.
• App-Steuerung für bedingten Zugriff: leitet Sitzungen über Defender for Cloud Apps.
• Fortlaufende Zugriffsevaluierung anpassen und Tokenschutz (Teil 5).
• Resilienzstandards deaktivieren: legt fest, was bei einem Entra-Ausfall passiert – lasst sie eingeschaltet, außer ihr wisst genau, warum nicht.

So wertet Entra ID mehrere Richtlinien aus

Jetzt kommt der Teil, der die meisten Missverständnisse auflöst. Es gibt bei Conditional Access keine Reihenfolge und keine Priorität zwischen Richtlinien. Stattdessen gilt:

1. Phase 1 – Informationen sammeln. Entra ID ermittelt Benutzer, App, Netzwerk, Gerät und Risiko. Das passiert für aktive Richtlinien und für Richtlinien im Modus „Nur Bericht“.
2. Phase 2 – Durchsetzen. Alle Richtlinien, deren Zuweisungen und Bedingungen vollständig zutreffen, werden zusammengerechnet. Innerhalb einer Richtlinie sind alle Bedingungen mit UND verknüpft.
3. Blockieren gewinnt. Trifft auch nur eine Richtlinie mit „Zugriff blockieren“ zu, ist hier Schluss.
4. Alle Anforderungen müssen erfüllt sein. Verlangt Richtlinie A MFA und Richtlinie B ein konformes Gerät, braucht der Benutzer beides.
5. Feste Reihenfolge der Abfragen. Fehlende Anforderungen werden in dieser Reihenfolge abgefragt: MFA, konformes Gerät, hybrid eingebundenes Gerät, genehmigte App, App-Schutzrichtlinie, Kennwortänderung, Nutzungsbedingungen.
6. Danach die Sitzung. Erst wenn alles erfüllt ist, greifen die Sitzungssteuerelemente.

Und der vielleicht wichtigste Satz: Trifft keine Richtlinie zu, gibt es Zugriff. Conditional Access ist kein „Alles verboten, außer …“, sondern ein „Alles erlaubt, außer eine Richtlinie sagt etwas anderes“. Deshalb ist die Basis-Richtlinie „MFA für alle Benutzer und alle Ressourcen“ so wichtig – sie schließt die Lücken, die einzelne App-Richtlinien offen lassen.

Ein Beispiel zum Mitdenken

Nehmen wir einen Tenant mit drei aktiven Richtlinien:

Richtlinie	Zuweisung	Steuerelement
A	Alle Benutzer, alle Ressourcen	MFA
B	Alle Benutzer, Office 365, Plattform iOS und Android	App-Schutzrichtlinie
C	Alle Benutzer, alle Ressourcen, Client-Apps „Andere Clients“	Blockieren

Anna öffnet Outlook auf ihrem iPhone. A und B treffen zu: Sie macht MFA und braucht die Outlook-App mit Intune-App-Schutz. Ihr Kollege versucht, mit einem alten Mailprogramm per IMAP abzurufen: C trifft zu – blockiert, egal was A sagt. Und Anna am Firmenlaptop im Browser? Nur A trifft zu, also MFA.

Wie es weitergeht

Jetzt kennt ihr die Bausteine. In Teil 3 geht es darum, wie ihr Richtlinien einführt, ohne euch auszusperren: mit Notfallkonten, dem Modus „Nur Bericht“, dem What-If-Tool und einem Namensschema, bei dem ihr auch in einem Jahr noch wisst, was „CA017“ eigentlich tut.

Offizielle Microsoft-Quellen

• Eine Conditional-Access-Richtlinie erstellen (Aufbau und Auswertung)
• Zielressourcen
• Netzwerkzuweisung
• Bedingungen
• Filter für Geräte
• Gewähren
• Sitzung
• Resilienzstandards
• Durchsetzung bei „Alle Ressourcen“ mit Ausnahmen