Conditional Access: Sicherheit für Microsoft 365

Wie viele Policies sind notwendig, um einen Microsoft 365 Tenant vernünftig abzusichern? Zwei? Drei? Zwölf? Dreißig? Die Wahrheit liegt für die meisten Tenants dazwischen. Es gibt einige Dinge zu beachten und kein passendes CA-Regelwerk von der Stange. Wir zeigen die wichtigsten Tipps und Infos mit den verfügbaren CA-Regelwerken zum Stand 03/2025.

Conditional Access ist der Microsoft 365 Dienst, der die Konfiguration der Zugriffsregeln für Identitäten und Geräte ermöglicht. Ermöglicht ist hier auch das erste Schlüsselwort: Microsoft bietet Konfigurationsmöglichkeiten - um eine tatsächlich sichere Konfiguration, muss sich der Kunde selbst kümmern.

Wer sein eigenes Regelwerk mal veranschaulicht sehen möchte, dem sei der CA-Documenter von Merill Fernando empfohlen: https://idpowertoys.merill.net/ca

Ziele des CA-Regelwerks

Das Ziel eines soliden und sicheren CA-Regelwerks liegt im Schutz des Tenants vor unbefugten Zugriffen. Dafür müssen typische Angriffe auf die Microsoft 365 Dienste rund um Entra ID abgewehrt werden. Aktuelle Angriffe in diesem Bereich umfassen beispielsweise die folgenden Aktivitäten:

  • Passwort-Spray-Angriffe
  • MFA-Bypass-Angriffe
  • Pass-the-Token-Angriffe
  • Cookie-Diebstahl
  • Phishing und Device Code Phishing

Der Fokus der Verteidigung liegt auf externen Angreifern, wobei im Buzzword-Bingo „Zero-Trust“ auch gewisse Angriffe von internen Quellen über CA eingedämmt werden können.

Eins noch vorweg: Wer seine Managed Identities bzw. Workload Identities über Conditional Access absichern möchte, der muss tiefer in die Tasche greifen.

Die notwendigen Lizenzen (z. B. Workload Identities Premium) sind nicht in den üblichen Standardlizenzen und nicht in den Entra ID P2 enthalten. Hierfür gelten besondere Regeln - sowohl für die CA-Regeln selbst, als auch für die Lizenzen.

Diese sind in den 40 Regeln unten daher nicht berücksichtigt.

Workload Identities und Conditional Access

Die perfekte CA-Policy - Orientierungshilfen

Die perfekte One-Click-CA-Policy für jeden Tenant: Ein Traum. Na gut, dann wären wir als Dienstleister wohl Arbeitslos, aber was tut man nicht alles für eine bessere Welt? Das Problem: Es gibt sie nicht.

Wir haben in den letzten Jahren viele Ideen, Quellen und Referenzen zusammen gesammelt. Die Folgenden sind enorm hilfreich und eine gute Grundlage.

Benchmarks vom Center for Internet Security

Die CIS-Benchmarks existieren für viele verschiedene Systeme und Produkte und umfassen ausführliche Maßnahmen zur Härtung. Für Microsoft 365 und Microsoft Azure gibt es zwei Benchmarks, die auch CA-Regelwerke enthalten. Die Empfehlungen sind super, die PDF-Dokumente kostenfrei und durch die  non-Profit-Organisation dahinter, sind die Empfehlungen auch relativ neutral.

Microsoft Secure Score

Der Secure Score ist das Microsoft built-in Werkzeug zur Analyse der Sicherheit des Tenants und enthält Empfehlungen zur Anpassung der Konfiguration - auch für Conditional Access. Naturgemäß enthalten die Empfehlungen des Scores die Sichtweise von Microsoft und bevorzugen das Zusammenspiel der kostenpflichtigen Produkte. Es gibt aber auch einige gute Empfehlungen, die mit Standard-Lizenzen (Entra P1, Business Premium oder E3) umsetzbar sind. Ein Blick in den Score kostet ja nichts (ob das Microsoft auf eine Idee bringt …).

DC-Toolbox CA-POC

Die DCToolbox von Daniel Chronlund ist ein eher praxisnahes Hilfsmittel. Mit wenigen Zeilen PowerShell wird ein Proof-of-Concept CA-Regelwerk im Tenant erstellt. Es enthält viele gute Ideen und bietet eine greif- und diskutierbare Grundlage zur Erweiterung und individuellen Anpassung.

Microsoft MVPs und weitere Quellen

Es gibt verschiedene Empfehlungen jenseits von den offiziellen Quellen. Hier sind Microsoft MVPs sicherlich eine gute Anlaufstelle. Joey Verlinden hat einen recht aktuellen Blog-Post dazu. Auch die AzureAD-Attack-and-Defense-Sammlung hat zu den einzelnen Angriffen Empfehlungen zur Abwehr mit Conditional Access und zur Erkennung mit KQL, Defender und co.

Maester CA-Checks

Mit Maester gibt es seit 2024 das wohl beste Audit-Werkzeug für Microsoft 365. Hierbei handelt es sich um ein Open-Source-Community-Tool von diversen M365-Spezialisten, die ein Test-Framework erschaffen haben, mit dem sich einerseits die bekannten Benchmarks und Empfehlungen von CIS, CISA und co. am eigenen Tenant überprüfen lassen, andererseits bieten viele weitere Tests der Community einen enormen Fundus an Sicherheitsempfehlungen. Das ist nicht nur auf CA beschränkt und eine absolute Empfehlung für die Härtung und Absicherung von Microsofts Cloud-Umgebung. Was das CA-Regelwerk angeht, so lassen sich hier in den Testfällen nochmals einige  sehr spannende Ideen sammeln.

Das individuelle Regelwerk

Wir verzichten hier auf die Erklärung aller Grundlagen zu Conditional Access. Da bieten der AZ-500 und die Microsoft-Doku genügend Material.

Bildquelle: https://learn.microsoft.com/de-de/entra/identity/conditional-access/overview

https://learn.microsoft.com/de-de/entra/identity/conditional-access/overview

Conditional Access kann verschiedene Input-Vektoren verarbeiten, die für die Entscheidung ob/wie ein Zugriff gestattet wird, herangezogen werden können, u.a.:

  • Identitäten
  • Benutzerkonten (intern / extern)
  •  Rollen
  • Geräte
  • Registrierung, Join
  • Compliance
  • Anmeldespezifika
  • Modern Authentication
  • Device Code Flow
  • Lokationen
  • IP-Adresse
  • Geolocation
  • Trusted Location
  • Apps
  • Verwendete App für den Login

Da wird schnell klar: Wer seine Geräte nicht in Intune verwaltet, für den fallen einige Optionen im Regelwerk weg. Wer Gäste im Tenant hat, der darf / kann / muss diese mit zusätzlichen, individuellen Regelwerken beglücken. Wer Entra ID P2 Lizenzen hat und PIM nutzt, der wird um die Definition von Authentication Contexts zum Erzwingen bestimmter Sicherheitsmerkmale beim Aktivieren von PIM nicht herum kommen.

Ein Conditional Access Regelwerk ist individuell. Pro Kunde. Selbst wir, die mit viel Erfahrung und vielen gebauten Regelwerken kommen, müssen den Tenant, die Verwendungsweise und alle kundenspezifischen Besonderheiten jedes Mal neu kennenlernen. Hier ist die zentrale Sammlung der SignIn-Logs essentiell. Ob diese in Log Analytics landen oder einem anderen Log-System ist dabei irrelevant. Wichtig ist nur, dass wir alle SignIn-Logs benötigen:

  • Interaktive Anmeldungen
  • Nicht-interaktive Anmeldungen
  • Service Principal Anmeldungen

Egal, was wir auf dem Reißbrett für ein Regelwerk erfinden: In der Praxis werden wir Ausnahmen benötigen. Der eine Dokumentenscanner, der SMTP benötigt. Der Entra Sync Account on-Prem, der kein MFA kann, obwohl der Sync-Account ein normaler Benutzeraccount ist. Das Breakglass-Konto, die externen ohne Unternehmensgeräte, der Backup Service Principal usw. usw. usw. - Schlimm ist das nicht. Wir kümmern uns ja drum.

Um am Ende den Überblick zu bewahren, empfehlen wir ein einheitliches Namensschema - Ja … langweilig, aber glaubt mir: Ihr werdet es sonst bereuen.

Das Namensschema gilt für Gruppen und Regeln. Idealerweise orientiert es sich nahe an dem, was wir machen. Also eine (role-enabled) Security Gruppe für die CA-Ausnahmen heißt beispielsweise dann so:

  • CA-Exception_Breakglass
  • CA-Exception_DeviceCompliance
  • CA-Exception_MFA

Für das CA-Regelwerk selbst gibt das gleiche. Wir bauen Regeln mit definierten Namen:

  • CA_AdminRoles_AllResources_noCond_PhishingResistantMFA
  • CA_AllUsers_AllResources_AuthenticationFlowDeviceCode_Block
  • CA_AllUsers_UA-Register-Join_Except-TrustedLocation_Block
  • CA_GuestUsers_AllResources_noCond_SessionSigninFrequency12h

Die Zielgruppe, der Wirkungsbereich, die Bedingungen und die umgesetzte Regel sollten sich im Namen wiederfinden. Mit diesem Schema kann man die Regeln noch lesen, obgleich nicht alle Infos im Namen stehen: So hat jede Regel natürlich Ausnahmegruppen zugewiesen. Mehrere Aktivitäten in einer Regel machen das Schema und die Regelwerke komplizierter. Mit diesem Ansatz haben wir gute Erfahrungen gemacht.

Alle Grundlagen haben wir in einer Tabelle zusammengefasst, die hier zum Download steht.

Conditional Access Regelwerk für Microsoft 365

Bei aller Mühe und allem Engagement, immer daran denken: Conditional Access ist DAS zentrale Sicherheitselement in der Microsoft Cloud.

Vielleicht kein Ort für Experimente oder "unser IT-Dienstleister wird das schon machen", sondern spezialisierte Dienstleistungen.

Am Autobahnkreuz 2A

74248 Ellhofen

® 2025 bi-sec

Nach oben scrollen