Typische Lücken in Conditional Access Regelwerken

Conditional Access ist ein zentrales Sicherheitsfeature in Microsoft Entra (ehemals Azure AD), das den Zugriff auf Unternehmensressourcen dynamisch steuert – basierend auf Benutzeridentität, Standort, Gerätestatus und weiteren Bedingungen. Es ermöglicht Administratoren, granulare Richtlinien zu definieren, um Risiken zu minimieren und gleichzeitig die Benutzerfreundlichkeit zu erhalten. Richtig konfiguriert, kann Conditional Access helfen, unbefugten Zugriff zu verhindern – erfordert jedoch ein gutes Verständnis der Auswirkungen auf Benutzererfahrung und Geschäftsprozesse.

Szenario 1 – MFA ist für alle Benutzer aktiviert!

Häufig treffe ich auf Conditional Access Policies die wie folgt konfiguriert sind, um die MFA für alle Benutzer zu aktivieren.

In der Realität schaut der Aktivierungsstand und die passende CA Policy dann eher wie folgt aus:

D.h. die Registrierung zur MFA erfolgt nicht, wenn der Benutzer sich von einem „vertrauenswürdigen Standort“ (typischerweise die PIPs der Unternehmensstandorte) anmeldet. Das heißt aber auch, wenn ein etwaiger Angreifer erfolgreich Benutzername und Kennwort erbeutet hat, und dann eine Anmeldung von außerhalb des Unternehmens vornimmt, die MFA Registrierung erfolgreich abschließen könnte..

Behelfen können wir uns mit einer weiteren Conditional Access Policy, welche die MFA Registrierung forciert, und die Registrierung wiederum bpsw. nur von bestimmten Standorten / Compliant Device etc. zu lässt.

Wir könnten nun bspw. die vertrauenswürdigen Standorte von dieser Richtlinie ausschließen, um eine MFA Registrierung von außerhalb zu blockieren. 

Alternativ können wir auch, wie in diesem Beispiel, den Gerätefilter benutzen und somit Registrierungen blockieren die von nonCompliant Geräten erfolgen.

Um nun noch die MFA Registrierung in der gewünschte Authentifizierungsstärke zu forcieren, legen wir eine weitere CA Policy an.

Szenario 2 – „Vergessene“ Geräteplattformen

Ein anderes wiederkehrendes Bild ist, dass Conditional Access Policys im Kontext der Geräteplattformen häufig auf Include gesetzt werden.

D.h. es gibt eine für Windows, eine für MacOS, eine für Android/iOS usw., aber was passiert wenn die Geräteplattform in der Anmeldung nicht mitgegeben wird, oder eine neue Plattform hinzukommt für die dann keine Regel existert? 

Ich empfehle daher eine „Catch-All“ Policy zu implementieren. In der Regel nutze ich dafür die Richtlinie für Windows Geräte (Compliant und/oder Hybrid Joined). Statt nun aber dort in den Plattformen ein Include für Windows zu konfigurieren, wähle ich Jedes Gerät, und schließe explizit die Plattformen aus für welche ich separate Richtlinien nutze. (Typischer iOS / Android / MacOS)

Szenario 3 – StepUp auf Windows Enterprise schlägt fehl

Nach wie vor muss hierfür eine Ausnahme in den CA-Regeln vorgenommen werden, ansonsten bleibts beim Pro.

Ausgeschlossen werden muss die „Universal Store Service-APIs und Webanwendung“ -  AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f - mehr Infos dazu gibt es hier.

Weitere Quellen & Infos zum Thema:

Hilfreiche um Schwachstellen / Lücken im eigenen Regelwerk zu erkennen, sind aus meiner Sicht einerseits die What-If Funktion im Conditional Access. Dazu definitiv noch das Conditional Access Insights Workbook, und zukünftig sicherlich auch der „Entra-Agent zur Optimierung des bedingten Zugriffs“.

 

Moderne IT- und Cloud-Szenarien stellen neue Anforderungen an Sicherheit, Governance und Betrieb. Die Beratungsangebote zum Thema Microsoft Security der Telekom unterstützten Sie dabei, Ihre Umgebung strukturiert zu analysieren und gezielt weiterzuentwickeln – von der ersten Einordnung bis zur konkreten Umsetzung.

Starten Sie mit einem unverbindlichen Orientierungsgespräch oder einem Microsoft 365 Security Assessment und erhalten Sie klare Handlungsempfehlungen für mehr Sicherheit.