Conditional Access Baseline Richtlinienlücken Entra ID

Conditional Access Baseline Richtlinienluecken Entra ID sind die grundlegendste Form eines Conditional-Access-Versagens überhaupt: keine fehlkonfigurierte Richtlinie, keine zu breite Ausnahme, sondern gar keine Richtlinie, die Admin-Rollen, alle Benutzer, alle Cloud-Apps oder Gerätekonformität abdeckt. Ein Tenant kann ein Dutzend Conditional-Access-Richtlinien im Admin Center haben – Blockierung von Legacy-Authentifizierung, risikobasierte Sign-in-Regeln, app-spezifische Ausnahmen – und trotzdem bei jeder dieser vier Baselines bei null Abdeckung liegen. Entra ID Conditional Access Lücken: Welche Fehlkonfigurationen reale Exposition hinterlassen behandelt Scope Drift, Ausnahmen und Legacy-Authentifizierung innerhalb bestehender Richtlinien. Dieser Artikel behandelt die Frage, die davor kommt: Existiert überhaupt eine Baseline-Richtlinie?

Conditional Access Baseline Richtlinienluecken Entra ID: Die vier blinden Flecken

Microsofts eigene Bereitstellungsanleitung für Conditional Access macht deutlich, dass ein Tenant auf eine kleine Menge breit wirkender Baseline-Richtlinien verweisen können sollte – nicht auf einen Haufen enger Ausnahmen. Wie Microsoft es in seiner Planungsanleitung formuliert, sollten Organisationen eine Richtlinie erstellen, die auf alle Benutzer, alle Ressourcen ohne App-Ausnahmen zielt und Multi-Faktor-Authentifizierung verlangt – denn das "stellt sicher, dass Sie Conditional-Access-Richtlinien nicht bei jeder neu angebundenen Anwendung aktualisieren müssen". Ein Tenant, dem eine der vier unten beschriebenen Lücken fehlt, hat diese Baseline nicht erreicht, egal wie viele andere Richtlinien er konfiguriert hat.

Keine Richtlinie für Admin-Rollen (CA_NO_POLICY_ADMINS)

Microsofts gängige Conditional-Access-Richtlinie für Administratoren empfiehlt, für mindestens vierzehn hochprivilegierte Rollen phishing-resistente MFA zu verlangen: Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, User Administrator und weitere mit tenant-weiter Auswirkung. Ohne eine Richtlinie, die gezielt diese Directory-Rollen adressiert – statt sich auf eine generische All-Users-MFA-Richtlinie zu verlassen, die für Admin-Sign-ins ausgeschlossen oder unzureichend gescoped sein könnte –, trifft ein kompromittiertes Administrator-Credential auf überhaupt keine zusätzliche Zugriffskontrolle.

Keine Richtlinie für alle Benutzer (CA_NO_POLICY_ALL_USERS)

Eine Richtlinie, die auf bestimmte Gruppen oder Apps zielt, ist nicht dasselbe wie eine Richtlinie, die auf All users zielt. Microsofts Dokumentation zum Conditional-Access-User-Assignment weist darauf hin, dass All users in einem Conditional-Access-Assignment sowohl B2B-Gäste als auch Members einschließt – und genau das ist der Punkt: Eine partielle, Gruppe für Gruppe aufgebaute Benutzerabdeckung übersieht tendenziell genau den Kontotyp, an den niemand gedacht hat. Ein Tenant mit starker MFA für sein Marketing-Team, aber nichts für Auftragnehmer oder neu onboardete Mitarbeiter, hat diese Lücke – selbst wenn die Richtlinienliste voll aussieht.

Keine All-Cloud-Apps-Abdeckung (CA_NO_ALL_APPS_COVERAGE)

Microsofts Bereitstellungsanleitung für Conditional Access stellt klar fest, dass es "aus Sicherheitssicht besser ist, eine Richtlinie zu erstellen, die All resources (ehemals 'All cloud apps') einschließt" – gerade weil App-für-App-Scoping bedeutet, dass jede neu angebundene SaaS-Anwendung zunächst ungeschützt ist, bis jemand daran denkt, sie einer Richtlinie hinzuzufügen. Ein Tenant, der nur eine Conditional-Access-Richtlinie für Exchange Online und das Azure-Portal geschrieben hat, hat jede andere Ressource – einschließlich Drittanbieter-OAuth-Apps und Microsoft Graph – außerhalb jeder Conditional-Access-Auswertung gelassen, da Sign-ins zu nicht adressierten Ressourcen von nichts geregelt werden.

Keine Anforderung an Gerätekonformität (CA_NO_DEVICE_COMPLIANCE)

Microsoft dokumentiert eine Conditional-Access-Richtlinie, die verlangt, dass Geräte, die auf Ressourcen zugreifen, als konform mit den Intune-Compliance-Richtlinien der Organisation markiert oder Microsoft Entra hybrid joined sind. Ohne sie erreichen MFA-erfüllte Sign-ins von nicht verwalteten, ungepatchten oder privaten Geräten dieselben Ressourcen wie Sign-ins von einem gehärteten, compliance-geprüften Firmen-Laptop – MFA belegt, wer sich anmeldet, nicht, dass das verwendete Gerät vertrauenswürdig genug für die Session ist.

⚠️

⚠️ Warnung: Diese vier Lücken sind unabhängig voneinander. Ein Tenant kann MFA für alle Benutzer verlangen und trotzdem keine admin-spezifische Richtlinie haben, oder jede Cloud-App für MFA abdecken und gleichzeitig nirgendwo Gerätekonformität verlangen. Jede muss einzeln überprüft werden – das Bestehen einer Prüfung bedeutet nicht, dass die anderen abgedeckt sind.

Warum "Wir haben Conditional Access" nicht bedeutet, dass Baseline-Abdeckung existiert

Zwei Dinge geben Tenants routinemäßig ein falsches Vertrauen, dass diese vier Baseline-Lücken geschlossen sind, obwohl sie es nicht sind.

Security Defaults ist kein Ersatz und verschwindet in dem Moment, in dem eine benutzerdefinierte Richtlinie erstellt wird. Microsoft aktiviert Security Defaults automatisch für neue Tenants, um eine Mindest-MFA-Baseline bereitzustellen, aber Security Defaults und Conditional-Access-Richtlinien schließen sich gegenseitig aus – sie können nicht gleichzeitig aktiviert sein. Die Falle: Ein Admin, der eine einzige enge Conditional-Access-Richtlinie erstellt (zum Beispiel Legacy-Auth für eine Abteilung blockiert), deaktiviert dabei stillschweigend Security Defaults tenant-weit, obwohl diese eine Richtlinie nichts zur Abdeckung von Admin-Rollen, allen Benutzern, allen Apps oder Gerätekonformität beiträgt. Der Tenant landet mit weniger Baseline-Schutz als zuvor, während das Admin Center weiterhin "Conditional Access: konfiguriert" anzeigt. Azure Tenant Hardening: Unsichere Standardeinstellungen beheben behandelt diese und weitere Standardeinstellungs-Fallen in neuen Tenants.

Microsoft-verwaltete Richtlinien decken einen engeren Ausschnitt ab, als "Baseline" suggeriert, und starten im Report-only-Modus. Seit Ende 2023 rollt Microsoft automatisch eine Reihe Microsoft-verwalteter Conditional-Access-Richtlinien an berechtigte Tenants aus, einschließlich MFA-Anforderungen für Admins und für alle Benutzer. Das ist eine echte Verbesserung, aber zwei Einschränkungen sind für diesen Artikel relevant: Erstens zielt die admin-fokussierte verwaltete Richtlinie speziell auf Sign-ins zu Microsoft-Admin-Portalen (Azure-Portal, Microsoft 365 Admin Center, Entra Admin Center und ähnliche), nicht auf Admin-Rollen-Sign-ins zu beliebigen Fachanwendungen; zweitens erstellt Microsoft diese Richtlinien standardmäßig im Report-only-Modus, der auswertet, aber nicht erzwingt. Ein Tenant, der sich auf die verwaltete Richtlinie verlässt, ohne je zu prüfen, ob sie den Report-only-Status verlassen hat, hat praktisch dieselbe Exposition wie ohne jede Richtlinie – ein eigenständiger, aber verwandter Fehlermodus zum Report-only-Drift, der in Conditional Access Report-only-Modus, veraltete Ausnahmen behandelt wird.

Erkennung

Erkennung von Baseline-Abdeckungslücken bedeutet, aufzulisten, was im Conditional-Access-Richtliniensatz des Tenants tatsächlich existiert – nicht, was der Tenant zu konfigurieren beabsichtigte.

Signal	Wo zu prüfen	Was es aussagt
Policy `conditions.users` Scope über alle Richtlinien	Microsoft Graph `GET /identity/conditionalAccess/policies`, oder `Get-MgIdentityConditionalAccessPolicy` (`Policy.Read.All`)	Ob irgendeine aktivierte Richtlinie `All` Users/Roles einschließt versus nur bestimmte Gruppen – die direkte Prüfung für `CA_NO_POLICY_ALL_USERS` und `CA_NO_POLICY_ADMINS`
Policy `conditions.users.includeRoles` mit Admin-Directory-Rollen-IDs befüllt	Gleiche Graph-Abfrage, gefiltert nach enabled-Status	Bestätigt, dass eine Richtlinie existiert, die gezielt privilegierte Directory-Rollen adressiert, statt nur eine generische All-Users-MFA-Regel, die für Admins ausgeschlossen sein könnte
Policy `conditions.applications.includeApplications`-Wert	Gleiche Graph-Abfrage	`All` bedeutet, dass All-resources-/All-cloud-apps-Abdeckung existiert; alles andere bedeutet, dass die Richtlinie auf bestimmte Apps gescoped ist und jede nicht gelistete App ungeschützt bleibt
Policy `grantControls` mit `compliantDevice` oder `domainJoinedDevice`	Gleiche Graph-Abfrage	Bestätigt, ob irgendeine erzwungene Richtlinie tatsächlich Gerätekonformität oder Hybrid Join verlangt, im Gegensatz zu reiner MFA
Policy-`state`-Wert (`enabled` vs. `enabledForReportingButNotEnforced`)	Gleiche Graph-Abfrage, oder der Report-only-Tab im Admin Center	Unterscheidet eine erzwungene Richtlinie von einer Microsoft-verwalteten oder benutzerdefinierten Richtlinie, die noch im Report-only-Modus steckt – eine Richtlinie im Report-only-Modus schließt die Lücke nicht
Conditional Access Gap Analyzer Workbook	Entra Admin Center → Monitoring & health → Workbooks → Bereich Conditional Access (erfordert Reports Reader und einen Log Analytics Workspace)	Speziell dafür gebaut, Benutzer, Anwendungen und benannte Standorte ohne jede angewendete Conditional-Access-Richtlinie aufzudecken, anhand echter Sign-in-Belege statt Richtlinientext
`conditionalAccessStatus`-Feld in Sign-in-Log-Einträgen	Entra Admin Center Sign-in-Logs, oder `GET /auditLogs/signIns`	`notApplied` bei einem Sign-in einer Admin-Rolle, eines Standardbenutzers oder eines nicht verwalteten Geräts ist die Laufzeit-Bestätigung, dass die entsprechende Baseline-Lücke real und nicht nur theoretisch ist

💡

💡 Tipp: Richtlinienprüfung vor Sign-in-Prüfung. Ein Gap-Analyzer-Workbook oder eine Sign-in-Log-Abfrage zeigt nur Belege für Identitäten und Apps, die sich im Beobachtungsfenster tatsächlich angemeldet haben. Die vorherige Auflistung des Richtliniensatzes über Graph sagt Ihnen definitiv, ob die vier Baseline-Richtlinien existieren – unabhängig davon, ob an diesem Tag zufällig jemand die Lücke ausgelöst hat.

Remediation

Zuerst eine dedizierte Admin-Rollen-MFA-Richtlinie ausrollen. Adressieren Sie die dokumentierte Menge hochprivilegierter Rollen (Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator und die übrigen Admin-Rollen aus Microsofts Common-Policy-Liste), verlangen Sie MFA oder eine stärkere Authentication Strength, und schließen Sie nur Break-Glass-Konten aus – lesen Sie Entra ID Break Glass Notfallzugangskonten, bevor Sie diese Ausnahme anlegen.
Eine Baseline-All-Users-Richtlinie mit Scope All users und All resources ausrollen. Vermeiden Sie App-für-App- oder Gruppe-für-Gruppe-Scoping für die Baseline-Ebene; ergänzen Sie stattdessen engere, stärkere Richtlinien für spezifische hochwertige Apps, statt zu versuchen, jede App aufzulisten, die die Baseline benötigt.
Eine Anforderung an Gerätekonformität oder Hybrid Join ergänzen – mindestens für dieselben Admin-Rollen und die oben abgedeckte Menge sensibler Ressourcen, mit Intune-Compliance-Richtlinien als Durchsetzungsquelle.
Prüfen, ob Microsoft-verwaltete Richtlinien existieren und ob sie noch im Report-only-Modus sind. Falls ja, überführen Sie sie nach einem validierten Prüfzeitraum entweder in den erzwungenen Modus, oder ersetzen Sie sie durch tenant-eigene Richtlinien, die den in diesem Artikel beschriebenen breiteren Scope abdecken statt nur Microsoft-Admin-Portale.
Wenn Security Defaults durch eine frühere enge Richtlinie stillschweigend deaktiviert wurde, aktivieren Sie es nicht einfach wieder – ersetzen Sie es durch die oben genannten expliziten Baseline-Richtlinien; Security Defaults und benutzerdefinierter Conditional Access schließen sich weiterhin gegenseitig aus, und eine Reaktivierung würde genau die engere Richtlinie entfernen, die die Frage überhaupt erst aufgeworfen hat.
Mit dem What-If-Tool und dem Gap-Analyzer-Workbook validieren – für ein repräsentatives Admin-Konto, einen repräsentativen Standardbenutzer und ein repräsentatives nicht verwaltetes Gerät –, bevor die Lücke als geschlossen gilt; Richtlinienkonfiguration und bestätigte Durchsetzung sind nicht derselbe Beleg.

Wie EtcSec Dies Erkennt

EtcSecs Azure/Entra-Checks bilden die vier Lücken in diesem Artikel direkt ab: CA_NO_POLICY_ADMINS und CA_NO_POLICY_ALL_USERS markieren das Fehlen einer aktivierten Richtlinie für Admin-Rollen bzw. alle Benutzer, CA_NO_ALL_APPS_COVERAGE markiert das Fehlen einer auf alle Cloud-Apps/Ressourcen gescopten Richtlinie, und CA_NO_DEVICE_COMPLIANCE markiert das Fehlen jeder Grant-Control für Gerätekonformität. AZ_SECURITY_DEFAULTS_NO_CA erfasst die oben beschriebene spezifische Falle: deaktivierte Security Defaults ohne kompensierende Conditional-Access-Baseline.

ℹ️

ℹ️ Hinweis: EtcSec prüft diese Schwachstelle automatisch bei jedem AD/Azure-Audit. Führen Sie ein kostenloses Audit durch, um Ihre Umgebung zu überprüfen.

Conditional Access Baseline Richtlinienluecken Entra ID: Keine Richtlinie für Admins, alle Benutzer oder alle Apps