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
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:
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.
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.
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.
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 …).
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.
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.
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.
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
Conditional Access kann verschiedene Input-Vektoren verarbeiten, die für die Entscheidung ob/wie ein Zugriff gestattet wird, herangezogen werden können, u.a.:
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:
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:
Für das CA-Regelwerk selbst gibt das gleiche. Wir bauen Regeln mit definierten Namen:
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.
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.