Entra ID bedingter Zugriff Luecken

Entra ID bedingter Zugriff Luecken: So laesst sich am direktesten der Unterschied zwischen Policies beschreiben, die im Admin Center breit aussehen, und Kontrollen, die die users, guests, apps, protocols und workload identities, die in der Produktion wirklich zaehlen, tatsaechlich auswerten. Ein Tenant kann nach sauberer Conditional-Access-Abdeckung aussehen und dennoch reale Angriffsfaechen ueber Ausnahmen, legacy protocols, guest-Pfade oder service principals offenlassen, die nie im richtigen Scope waren.

Dieser Artikel behandelt Conditional Access als Beweisproblem, nicht als Screenshot-Problem. Ziel ist zu zeigen, was als reale Luecke gilt, welche Microsoft-Signale das belegen, wie sich die Luecke ohne operativen Lockout schliessen laesst und wie sich der sicherere Zustand nach der Aenderung belastbar validieren laesst. Fuer die breitere Tenant-Pruefung beginnen Sie mit Microsoft Entra ID-Sicherheit auditieren: praktischer Leitfaden.

Entra ID bedingter Zugriff Luecken: Was zaehlt als echte Luecke?

Eine Conditional-Access-Luecke ist jede Abweichung zwischen der Policy, die Sie durchsetzen wollen, und den Sign-ins, die Microsoft Entra tatsaechlich auswertet. Microsoft beschreibt Conditional Access als Policy-Engine, die Signale zusammenfuehrt, Assignments und Conditions anwendet und dann Zugriff gewaehrt, blockiert oder weiter einschraenkt. Der Mechanismus ist stark, aber nicht selbsterklaerend. Eine Policy reduziert Risiko nur dann, wenn sie die richtigen Identitaeten und Resources adressiert, den relevanten Protocol Path auswertet und Belege in Sign-in Logs und Audit Logs hinterlaesst.

In der Praxis entsteht eine Luecke meist in einem der folgenden Faelle:

fuer einen sensiblen Scope fehlt die Policy vollstaendig
eine Policy existiert, schliesst aber die users oder roles aus, die am wichtigsten sind
eine Policy schuetzt users, aber nicht workload identities
eine Policy zielt auf die falschen resources oder client paths
eine Policy verwendet einen zu schwachen Grant fuer die geschuetzte Resource
eine Policy verbleibt in report-only und erreicht nie Enforcement

Microsoft weist ausserdem darauf hin, dass Conditional Access nach dem ersten Authentifizierungsfaktor ausgewertet wird. Deshalb darf Conditional Access nicht als magische Kontrolle "vor der Authentifizierung" beschrieben werden. Es ist eine Entscheidungsschicht rund um einen Sign-in, und die Qualitaet dieser Entscheidung haengt von Scope, Telemetry und Policy-Design ab.

Warum Conditional Access Trotzdem Reale Exposition Offenlassen Kann

Viele Teams denken ueber Conditional Access in einem binaeren Modell nach: aktiviert oder nicht aktiviert. Reale Exposition ist unordentlicher. Microsoft Entra bewertet alle Policies, die fuer einen Sign-in gelten, und der Benutzer muss alle anwendbaren Anforderungen erfuellen, bevor Zugriff gewaehrt wird. Das eigentliche Problem ist, dass viele Sign-ins, die eigentlich haetten geregelt werden sollen, in der Praxis nie "applicable" werden.

Das erste Beispiel ist Scope Drift. Sicherheitsteams glauben haeufig, eine breite Policy decke alles ab, weil sie auf All users zielt. Microsoft dokumentiert, dass All users auch B2B guests einschliesst. Das ist hilfreich, bedeutet aber nicht, dass jeder Identitaetspfad abgedeckt ist. Workload identities sind eine eigene Assignment-Klasse, und user-scoped Policies steuern service principals nicht automatisch. Wenn ein Tenant von app registrations, Automatisierung oder Backend-Integrationen abhaengt, muss das mit derselben Strenge ueberprueft werden wie menschliche Benutzer.

Das zweite Beispiel ist der Unterschied zwischen einem breiten Grant und einem starken Grant. Require multifactor authentication und Require authentication strength sind nicht dieselbe Kontrolle. Wenn das Geschaeft fuer Administratorrollen oder sensible Anwendungen phishing-resistente Authentifizierung erwartet, kann eine allgemeine MFA-Anforderung schwacher sein als die eigentliche Absicht. Deshalb gehoeren Azure Identitaetssicherheit: Warum MFA Allein Nicht Ausreicht, MFA Fatigue: Erkennung und Praevention fuer Microsoft Entra ID und eine Conditional-Access-Review oft zusammen.

Das letzte wiederkehrende Problem ist Validation Drift. Policies sammeln Ausnahmen, report-only-Entwuerfe, ueberlappende Templates und Notfallausnahmen an. Das Portal zeigt weiterhin viele Policies an, aber genau die Sign-ins, die wirklich zaehlen, koennen weiter ohne Challenge durchkommen oder ueber schwaechere Pfade ausgewertet werden als beabsichtigt.

Scope-Luecken: Users, Guests, Roles, Resources und Workload Identities

Users, directory roles und exclusions

Der erste Review-Schritt besteht darin, genau zu kartieren, wen die Policies wirklich treffen. Conditional Access kann alle users, ausgewaehlte users und groups, directory roles, guests und external users sowie workload identities ein- oder ausschliessen. Ein Tenant mit starker user-Abdeckung kann dennoch privilegierte Rollen oder privilegierte exclusions schlecht steuern. Das gilt besonders dann, wenn privilegierter Zugriff ohnehin schon zu breit ist, wie in Azure Privilegierter Zugriff: Zu Viele Globale Admins.

Emergency access accounts sind das klarste Beispiel fuer eine beabsichtigte exclusion. Microsoft empfiehlt, sie aus Conditional-Access-Policies auszuschliessen, um Tenant-Lockout zu verhindern. Diese Empfehlung rechtfertigt aber keine bequemen Dauerausnahmen. Jede exclusion braucht einen engen Grund, einen owner und aktive Ueberwachung. Wenn derselbe Break-Glass-Account fuer normale Administration verwendet wird, ist die Luecke operativ und nicht theoretisch.

Guests und external users

Guest- und externer Zugriff verdient eine eigene Review und nicht die Annahme, All users habe das bereits geloest. Microsoft Entra erlaubt es, gezielt bestimmte guest- und external-user-Typen anzusprechen, und externes Verhalten haengt ausserdem von cross-tenant trust settings ab. Wenn Sie etwa authentication strengths fuer external users einsetzen, dokumentiert Microsoft, dass der resource tenant auch MFA-Trust aus dem home tenant bewertet. Guest-Abdeckung ist deshalb nicht nur eine Frage, ob eine Policy existiert. Sie ist eine Frage von Scope und Trust. Deshalb gehoert Azure Gastkonten: Die Vergessene Angriffsflaeche in Ihrem Tenant oft in dieselbe Review.

Resources, apps und user actions

Eine weitere Scope-Luecke entsteht, wenn das falsche Set an resources geschuetzt wird. Policies koennen allen resources oder ausgewaehlten resources zugewiesen werden. Wenn ein Tenant Microsoft-Admin-Portale schuetzt, aber nicht die Business- oder SaaS-Anwendungen, die Benutzer tatsaechlich zuerst erreichen, bleibt die Kontrollgeschichte unvollstaendig. Dasselbe Problem entsteht, wenn ein Team sich mit einem Cloud-App-Screenshot zufriedengibt, anstatt den echten resource path zu ueberpruefen, den ein Angreifer nach dem Diebstahl von Credentials oder Sessions wiederverwenden wuerde. Angriffe, die gueltige Sessions oder OAuth-Pfade ausnutzen, verketten sich oft mit solchen Luecken; deshalb ist Device Code Phishing: Wie OAuth Device Flow Entra-ID-Konten kompromittiert hier relevant.

Workload identities

Service principals und workload identities sind der haeufigste blinde Fleck in ansonsten reifen Tenants. Microsoft dokumentiert, dass Aufrufe von service principals nicht durch Conditional-Access-Policies blockiert werden, die nur auf users zielen, und dass Conditional Access fuer workload identities verwendet werden muss, wenn diese Identitaeten per Policy gesteuert werden sollen. In der Praxis bedeutet das: Ein Tenant kann starke user-MFA-Abdeckung zeigen und dennoch Automatisierungs- und Anwendungsidentitaeten ausserhalb des Conditional-Access-Modells belassen.

Das bedeutet nicht, dass jede workload identity dieselbe Policy erhalten muss. Es bedeutet, dass der Tenant belegen muss, welche workload identities existieren, welche bewusst ausgenommen sind und welche noch immer von schwaecheren Mustern abhaengen, die wo immer moeglich durch managed identities ersetzt werden sollten.

Kontrollluecken: MFA, Authentication Strengths, Legacy Authentication und Risk Policies

MFA-Abdeckung ist nicht dasselbe wie starkes Authentifizierungsdesign

Ein Tenant kann viele Policies besitzen, die MFA verlangen, und trotzdem hochkritischen Zugriff ueber schwaechere Methoden als beabsichtigt offenlassen. Microsoft dokumentiert authentication strengths als Conditional-Access-Kontrolle, die begrenzt, welche Methodenkombinationen fuer den Zugriff auf eine Resource verwendet werden duerfen. Diese Unterscheidung zaehlt immer dann, wenn das Policy-Ziel staerker ist als "irgendein MFA reicht". Fuer Administratorrollen oder sensible Anwendungen muss der Unterschied zwischen einem breiten MFA-Grant und einer phishing-resistenten oder passwordlosen Anforderung explizit sein.

Legacy authentication bleibt eine reale Luecke, wenn sie noch erreichbar ist

Legacy authentication muss praezise behandelt werden, weil sie oft zu unscharf beschrieben wird. Microsoft erklaert, dass Legacy-Protokolle kein MFA unterstuetzen und keine Geraetezustandsinformationen uebermitteln. Microsoft empfiehlt ausserdem, Authentifizierungsanfragen ueber solche Protokolle zu blockieren, und weist darauf hin, dass diese Pfade in Password-Spraying- und Credential-Stuffing-Kampagnen weiterhin stark genutzt werden.

Die belastbare Formulierung ist daher: Legacy authentication ist eine Luecke, wenn diese Protokolle fuer Identitaeten oder resources erreichbar bleiben, die der Tenant fuer modern durch Conditional Access geschuetzt haelt. Manche Tenants schliessen diese Luecke mit einer dedizierten Block-Policy. Andere verlassen sich auf breitere Grants fuer alle client apps. Gute Review bedeutet nicht, ein Template auswendig zu lernen. Gute Review bedeutet, mit Sign-in-Belegen nachzuweisen, dass legacy clients blockiert oder verschwunden sind. Wenn der Tenant ohnehin schwache erste Faktoren untersucht, sollte dieses Thema mit Password Spraying: Erkennung und Praevention fuer Active Directory und Entra ID verknuepft werden.

Risk Policies sind nicht automatisch Teil einer guten Conditional-Access-Reife

Ein Tenant ohne Sign-in-Risk- oder User-Risk-Policies ist nicht automatisch fehlkonfiguriert, weil diese Policies von Microsoft Entra ID Protection und vom passenden Lizenzniveau abhaengen. Wenn die Sicherheitsgeschichte aber risikoadaptive Zugriffskontrolle behauptet, muss der Tenant belegen, dass diese Kontrollen existieren und greifen. Microsoft dokumentiert Sign-in-Risk-Policies separat und macht die P2-Abhaengigkeit klar. Wenn der Tenant diese Faehigkeit nicht lizenziert oder nicht nutzt, muss das offen benannt werden, statt eine nicht vorhandene Kontrolle zu suggerieren. Siehe dazu auch Azure Identity Protection: Reaktion auf Kompromittierte Konten.

Erkennung

Die Erkennung von Luecken im bedingten Zugriff von Entra ID ist eine Korrelationsaufgabe und kein Ein-Feld-Alert.

Microsoft-Entra-Sign-in-Logs sind die primaere Beweisquelle. Fuer interaktive und nicht interaktive Sign-ins sollten mindestens diese Dimensionen geprueft werden:

Signal	Warum es wichtig ist
`conditionalAccessStatus`	Zeigt, ob Conditional Access erfolgreich war, fehlgeschlagen ist oder nicht angewendet wurde. `notApplied` ist nicht automatisch ein Fehler, wird aber zur Luecke, wenn der Sign-in eigentlich im Scope haette sein muessen.
`appliedConditionalAccessPolicies`	Zeigt, welche Policies den Sign-in wirklich ausgewertet haben. Das ist nuetzlicher, als nur anzunehmen, welche Policy haette greifen sollen.
`clientAppUsed`	Identifiziert legacy paths wie IMAP, POP, SMTP, Exchange ActiveSync und andere clients, die in der Regel blockiert oder verschwunden sein sollten.
`riskLevelDuringSignIn` und verwandte Risikofelder	Wichtig, wenn der Tenant behauptet, risikobasiertes Enforcement umzusetzen, und dies nachweisen muss.
resource- und app-Kontext	Hilft zu erkennen, ob der Sign-in den Resource-Satz erreicht hat, den die Policy schuetzen sollte.
interaktive vs. nicht interaktive Sign-ins	Noetig, weil legacy- und service-getriebene Pfade oft uebersehen werden, wenn Teams nur interaktive Sign-ins betrachten.

Die entscheidende Nuance ist: Ein erfolgreicher Sign-in mit conditionalAccessStatus = notApplied reicht fuer sich allein nicht. Die eigentliche Frage ist, ob dieser Sign-in gemaess dem eigenen Tenant-Design haette geregelt werden muessen.

Audit Logs auf Policy Drift pruefen

Audit Logs sind die zweite Beweisquelle. Nutzen Sie sie fuer Policy-Erstellung, Updates, Enablement-Aenderungen, Uebergaenge nach report-only, Exclusion-Aenderungen und Loeschungen. Wenn ein Tenant den Scope von Conditional Access staendig veraendert, ohne nachvollziehbare Belege fuer das Warum zu hinterlassen, dann ist die eigentliche Luecke genauso sehr Governance Drift wie Policy-Design.

Den Policy-Zustand pruefen, nicht nur den Policy-Text

report-only und das What If-Tool sind nuetzlich, aber sie beantworten unterschiedliche Fragen. report-only hilft, Auswirkungen ohne Enforcement einzuschaetzen. Das What If-Tool hilft zu simulieren, welche Policies auf einen user- oder service-principal-Sign-in angewendet wuerden. Keines von beiden ersetzt Produktionsbelege. Eine reife Review nutzt beides und bestaetigt das Ergebnis anschliessend in echten Sign-in-Daten.

Remediation

Remediation sollte zuerst die Scope- und Kontrollluecken mit der groessten Auswirkung schliessen.

Eine breite Baseline fuer users und resources etablieren. Der Tenant sollte zeigen koennen, welche Basis-Policies den normalen Benutzerzugriff auf die wirklich wichtigen resources schuetzen und nicht nur ein Admin-Portal oder eine Lieblingsanwendung.
Exclusions pruefen, bevor neue Policies hinzukommen. Wenn exclusions bereits Administratoren, guests oder hochwertige Gruppen verstecken, koennen neue Policies Fortschritt nur vortaeuschen, waehrend die reale Exposition bestehen bleibt.
Legacy-authentication-Pfade blockieren oder entfernen. Wenn Conditional Access zur Verfuegung steht, sollten Policy-Scope und Validierung genutzt werden, um legacy authentication zu blockieren. Wenn es noch Dienst- oder Anwendungsabhaengigkeiten gibt, muessen diese explizit dokumentiert und als Ausnahmen mit Rueckbauplan behandelt werden, nicht als dauerhafte Designannahme.
User-Coverage von Workload-Identity-Coverage trennen. Wenn der Tenant auf service principals, Automatisierung oder Anwendungsidentitaeten angewiesen ist, braucht es einen eigenen Review-Pfad fuer workload identities. User-scoped Policies haben diese Arbeit nicht automatisch erledigt.
Authentication strengths nutzen, wenn das Zugriffsziel staerker als generisches MFA ist. Sensible Anwendungen, externer Zugriff und privilegierte Rollen brauchen oft mehr als einen breiten MFA-Grant.
Risk Policies nur einfuehren, wenn der Tenant sie auch wirklich betreiben kann. Wenn P2-gestuetzte Risikobewertung Teil der Sicherheitsgeschichte ist, muss die Evidenz das zeigen. Wenn sie weder lizenziert noch ausgerollt ist, sollte der Artikel das als bewusste Begrenzung behandeln, nicht als versteckte Reife.

Validierung Nach Policy-Aenderungen

Hier scheitert Conditional-Access-Arbeit am haeufigsten.

Verwenden Sie zuerst What If, um die erwartete Policy-Anwendung fuer reprasentative users, Administratorrollen, guests und service principals zu pruefen. Nutzen Sie zweitens report-only, wo es sinnvoll ist, um den Blast Radius vor dem Enforcement zu verstehen. Bestaetigen Sie drittens das echte Ergebnis in den Sign-in-Logs, nachdem die Policy aktiviert wurde.

Diese Validierung sollte konkrete Fragen beantworten:

treffen die vorgesehenen Policies die vorgesehenen users?
bleiben ausgeschlossene Konten bewusst ausgeschlossen und ueberwacht?
folgen guest-Sign-ins dem erwarteten Policy-Pfad?
liegen workload identities weiterhin ausserhalb user-scoped Controls?
schlagen Versuche ueber legacy clients jetzt fehl oder verschwinden sie?
wenn authentication strengths eingefuehrt wurden, zeigen die betroffenen Sign-ins in der Praxis die erwartete Staerke?

Ein Tenant, der diese Fragen nicht mit Sign-in- und Audit-Belegen beantworten kann, hat seine Remediation nicht abgeschlossen.

Belege, die Zwischen Reviews Aufbewahrt Werden Sollten

Conditional Access driftet leise, deshalb ist das Evidence Pack wichtig.

Aufbewahren	Warum es wichtig ist
Policy-Exporte oder Screenshots mit Assignments, Exclusions und Grant Controls	Belegt, was der Tenant zu diesem Zeitpunkt durchsetzen wollte.
Sign-in-Log-Beispiele fuer reprasentative in-scope- und ausgeschlossene Identitaeten	Belegt, was Microsoft Entra wirklich ausgewertet hat.
Audit-Log-Eintraege fuer Policy-Aenderungen	Hellt auf, wer Scope, Modus, Exclusions oder Grant-Logik geaendert hat.
Ausnahme-Register fuer emergency accounts, guests oder legacy-Abhaengigkeiten	Trennt absichtliche Ausnahmen von versehentlichen Luecken.
Inventar der workload identities	Belegt, dass nicht-menschliche Identitaeten separat geprueft und nicht einfach als mitabgedeckt angenommen wurden.

Dieses Paket erlaubt es der naechsten Review, Drift zu messen statt wieder bei verstreuten Screenshots zu beginnen. Wenn der Tenant ausserdem einen groesseren Compliance-Rahmen braucht, ist NIS2 Anforderungen an die Identitaetssicherheit: Was AD- und Entra-Teams nachweisen muessen der richtige Begleitartikel und kein Ersatz fuer diese technische Review.

Wie EtcSec Hilft, Luecken im Bedingten Zugriff zu Messen

EtcSec sollte hier eng und sachlich positioniert werden: nicht als magischer Sign-in-Detektor, sondern als Mittel, gaengige strukturelle Conditional-Access-Luecken ueber die Zeit neu zu messen.

Fuer diesen Artikel sind die relevanten Findings diejenigen, die bereits echten Policy-Design-Problemen entsprechen:

CA_NO_MFA_REQUIREMENT
CA_NO_LEGACY_AUTH_BLOCK
CA_NO_RISK_BASED_SIGNIN
LEGACY_AUTH_ALLOWED

Dieses Mapping ist nuetzlich, weil es wiederkehrende Reviews unterstuetzt. Ein Tenant kann nach Policy-Aenderungen erneut auditieren und pruefen, ob dieselben strukturellen Luecken weiterhin bestehen, statt Conditional Access als einmalige Einrichtung zu behandeln.

Entra ID bedingter Zugriff Luecken: welche Fehlkonfigurationen reale Angriffsflaechen lassen

Entra ID bedingter Zugriff Luecken: Was zaehlt als echte Luecke?

Warum Conditional Access Trotzdem Reale Exposition Offenlassen Kann