Conditional Access: Der Schlüssel zur sicheren Microsoft 365 Umgebung
Was ist Conditional Access?
Conditional Access oder der "bedingte Zugriff" ist DAS zentrale Sicherheitsfeature von Microsoft 365 und die effektivste Methode, den Zugriff auf Ihre Unternehmensressourcen abzusichern.
Anbei der offizielle Microsoft Link zum Thema: https://learn.microsoft.com/de-de/entra/identity/conditional-access/overview
Conditional Access ist die zentrale Zugangskontrolle für Ihre Microsoft 365 Umgebung. Stellen Sie sich Conditional Access wie ein intelligentes Zugangssystem vor: Ein Benutzer darf nur dann auf eine Ressource zugreifen, wenn vorher definierte Bedingungen erfüllt sind. Diese Bedingungen können auf Signalen basieren, die Informationen wie Benutzerstandort, Gerätezustand oder Risikobewertungen des Benutzers oder des anmeldenden Geräts enthalten. So lässt sich der Zugriff granular steuern und genau an die Bedürfnisse Ihres Unternehmens anpassen.
Zu diesen Signalen gehören:
Identitäten
Anwendungen
Geräte
Standorte
Risikobewertungen
Am Ende hat Conditional Access eine einfache Aufgabe: Den Zugriff erlauben oder blockieren – basierend auf definierten Voraussetzungen. Das Ziel ist es, alle Identitäten mit Conditional Access zu schützen.
Warum ist Conditional Access so wichtig?
Ein sehr großer Teil erfolgreicher Cyberangriffe ist auf Identitätsdiebstahl zurückzuführen. Dabei gelangt ein Angreifer an Anmeldeinformationen eines Benutzers (meist Benutzername + Passwort, immer häufiger jedoch auch an dessen Anmeldeartefakte - Tokens) und übernimmt damit die Identität des betroffenen Accounts (Initial Access): Er verschafft sich einen Überblick, liest dessen E-Mails und Dokumente (Discovery) und lädt diese möglicherweise herunter. Das Ziel: Möglichst mehrere Accounts und Systeme kompromittieren (Lateral Movement, Persistence) und an höhere Rechte, möglichst an Domain-Admin Rechte des Active Directory oder an Global Admin Rechte oder vergleichbare Graph-Permissions (Privilege Escalation) zu gelangen. Hat ein Angreifer derartige Rechte erlangt, ist der Worst-Case eingetreten. Der Angreifer hat in aller Regel Zugriff auf einen Großteil aller Systeme und Daten. Zumindest muss in solchen Fällen immer davon ausgegangen werden. Die Vorgehensweise ist längst bekannt: Opfer werden doppelt erpresst. Durch Veröffentlichung ihrer Daten und/oder durch die Verschlüsselung ihrer Daten und das nicht Herausgeben der Entschlüsselungs-Schlüssel. Der Angreifer hat meist natürlich monetäre Anreize und versucht eine Lösegeldsumme (Ransom) zu erpressen - daher auch Ransomware.
Abhängig von der Lizenzierung haben Sie bei der Nutzung von Microsoft 365 zwei grundlegende Möglichkeiten Ihre Identitäten zu schützen.
Sicherheitsstandards bzw. Security Defaults
Dieses Feature aktiviert grundlegende Sicherheitsfunktionen für den gesamten Tenant. Es ist besonders praktisch, wenn man nicht die Lizenzvoraussetzungen für Conditional Access erfüllt (also keine Entra ID Premium P1-Lizenzen hat). Der Nachteil besteht darin, dass die Multi-Faktor-Authentifizierung (MFA) für alle Konten lediglich aktiviert oder deaktiviert werden kann. Für Servicekonten ist dies beispielsweise nicht immer umsetzbar. Man geht also einen Kompromiss ein: weniger Flexibilität und Sicherheit, dafür etwas geringere Lizenzkosten – jedoch mit einem erhöhten Unternehmensrisiko aufgrund der höheren Wahrscheinlichkeit eines Cyberangriffs und mit weniger Flexibilität bzw. Komfort.Conditional Access bzw. bedingter Zugriff
Im Vergleich zu den Sicherheitsstandards bietet Conditional Access umfangreiche Möglichkeiten, den Zugriff auf den eigenen Microsoft 365-Tenant zu steuern. Dadurch können Identitäten und Ressourcen effektiv geschützt werden. Wie bereits erwähnt, wird der Zugriff basierend auf bestimmten Voraussetzungen entweder genehmigt oder blockiert. Dieses Feature ermöglicht maximale Flexibilität und Sicherheit bei überschaubaren Lizenzkosten, da es bereits in Lizenzpaketen wie Business Premium enthalten ist.
Conditional Access: Ein mächtiges Werkzeug, oft falsch angewandt
Einfach gesagt entscheidet Conditional Access, ob ein Zugriff, unter Berücksichtigung der definierten Sicherheitsvorgaben, erlaubt oder blockiert wird. Oder: Conditional Access steuert die Bedingungen, unter denen Microsoft Entra ID ein Zugriffstoken ausstellt.
Zum Thema Conditional Access sage ich immer: "Easy to learn, hard to master."
Ein gut implementiertes Conditional Access Framework schützt sämtliche Identitäten und reduziert die Angriffsfläche erheblich. Trotzdem stoße ich immer wieder auf Unternehmen, die fälschlicherweise annehmen, bereits ein solides Conditional Access Regelwerk zu haben, obwohl dies oft nicht zutrifft.
Ein typisches Beispiel
Ein häufiges Problem bei Conditional Access ist eine lückenhafte Konfiguration der Sicherheitsrichtlinien. Etliche Unternehmen verwenden eine einzige Policy, die bei allen Benutzern MFA erzwingt. Dabei werden oftmals die öffentlichen IP-Adressen der Unternehmensstandorte von dieser Regel ausgenommen, da diese als vertrauenswürdig deklariert werden. Gleichzeitig fehlt dabei die nötige Richtlinie zur Absicherung ebendieses Vorgangs zur Registrierung neuer MFA Methoden (“Security Info Registration”).
Das bedeutet:
Mitarbeiter, die ausschließlich im Büro arbeiten, werden nie aufgefordert, MFA einzurichten oder zu nutzen.
Angreifer, die an die Zugangsdaten gelangen, können selbst den zweiten Faktor unbemerkt registrieren.
Angreifer, die ein Gerät im Netzwerk vor Ort kompromittiert haben, können nun weitere Identitäten leicht angreifen, da nur Benutzername und Passwort benötigt werden.
Das Ergebnis: Es entsteht eine große Angriffsfläche. Angreifer, die von Geräten des Unternehmensnetzwerks agieren können, können Identitäten leicht kompromittieren. Wenn diese Benutzer dann eines Tages extern arbeiten, benötigen sie oft Unterstützung der IT, da sie nicht den nötigen zweiten Faktor eingerichtet haben.
Das Problem
Derartige Conditional Access Implementierungen haben zur Folge, dass etliche Anmeldungen an Conditional Access “vorbeigehen”. Wir sprechen hier typischerweise von “Gaps” oder von einem sogenannten “Conditional Access Bypass”. Genau das wollen wir verhindern!
Meine Empfehlung
Wie wir wissen, ist Identity heute der wichtigste Security-Perimeter. Jeder IT-Administrator oder IT-Sicherheitsverantwortliche sollte daher sein Conditional Access Framework regelmäßig überprüfen lassen.
Nur so kann sichergestellt werden, dass:
100% der Anmeldevorgänge durch Conditional Access geschützt sind / keine Anmeldungen an Conditional Access “vorbeigehen”.
Fehlkonfigurationen zeitnah entdeckt werden können.
Das Framework kontinuierlich auf neue Bedrohungslagen angepasst wird.
Ein regelmäßiges, professionelles Review minimiert Risiken und verbessert die Sicherheit nachhaltig.
Welche Lizenzen benötigt man für Conditional Access?
Um Conditional Access nutzen zu können, benötigen Sie mindestens folgende Lizenzen:
Mind. Microsoft Entra ID P1
Ermöglicht die Nutzung grundlegender Conditional Access Policies.
Enthalten bereits ab Microsoft 365 Business Premium (ebenso in Microsoft 365 E3, Microsoft 365 E5, und weiteren) wodurch es eine kosteneffiziente Lösung auch für kleine und mittelständische Unternehmen darstellt.
besser Microsoft Entra ID P2
Ideal für Unternehmen, die zusätzlich risikobasierte Richtlinien (“Risk based Conditional Access”) implementieren möchten.
Diese erweiterten Policies ermöglichen eine dynamische und flexible Absicherung von Zugriffen basierend auf dem individuellen Risikostatus eines Benutzers und dessen Anmeldeverhalten.
Microsoft Entra Workload ID Premium
Da Workload Identitäten (Service-Principals, App-Registrations) standardmäßig NICHT von Conditional Access abgedeckt werden und damit nichts anderes als eine Single-Faktor-Authentifizierung durchführen, sollten diese Anmeldevorgänge ebenso durch Conditional Access abgedeckt werden. Leider ist diese Funktionalität weder von Entra ID P1, noch von Entra ID P2 abgedeckt. Microsoft verlangt hierfür eine separate Lizenz pro Workload Identität.
Was mache ich ohne Entra ID P1/P2 Lizenzen?
Ohne diese Lizenzen bleiben Ihnen nur die Security Defaults, die lediglich einen statischen, grundlegenden Schutz bieten. Für viele Unternehmen sind diese jedoch nicht ausreichend:
Einschränkung: Einzelne Konten können nicht von den Sicherheitsrichtlinien ausgenommen werden bzw. es können keine abgemilderten Richtlinien für einzelne Konten angewendet werden. Security Defaults können nur aktiviert oder deaktiviert werden.
Risiko: Weitere Angriffsflächen bleiben bestehen, wie beispielsweise die fehlende Möglichkeit, Endgeräte beim Anmeldevorgang mit einzubeziehen und somit die Anmeldung nur von Unternehmensendgeräten aus zu erlauben.
Empfehlung
Wir empfehlen die Nutzung von Microsoft Entra ID P2, um Conditional Access durch Verwendung der Anmelde- und Benutzer-Risikosignale anzureichen.
Mindestens sollte jedoch auf die Microsoft 365 Business Premium Lizenz zum Einsatz kommen, da diese bereits Entra ID P1 sowie Microsoft Intune P1 enthält und somit bereits eine sehr starke Grundlage für ein solides Conditional Access Framework bietet, das auch die Nutzung von gerätebasierten Signalen (Device-Compliance) ermöglicht und damit die Phishing-Resistenz erhöht.
Einführung von Conditional Access
Wie gehe ich am besten bei der Einführung von Conditional Access vor?
Schritt 1: Analyse – Die Arbeitsweise des Unternehmens verstehen
Bevor Sie Conditional Access einführen, ist es entscheidend, die Arbeitsweise des Unternehmens zu verstehen. Folgende Fragen sollten geklärt werden:
Werden ausschließlich Unternehmensgeräte verwendet?
Die Nutzung privater Geräte erfordert andere Richtlinien als reine Unternehmensumgebungen.Werden Dateien häufig mit externen Partnern geteilt?
Eine häufige Zusammenarbeit mit Externen stellt besondere Anforderungen an die Sicherheit und den Zugriff.Gibt es externe Mitarbeiter oder Administratoren im Tenant?
Externe Nutzer und Admins benötigen spezielle Richtlinien, um Risiken zu minimieren, ohne die Zusammenarbeit zu behindern.Von welchen Standorten aus wird gearbeitet?
Die Berücksichtigung der Standorte (z. B. Büro, Homeoffice, Ausland) Länder ist essenziell, um Zugriffsrichtlinien passend zu gestalten.Welche Applikationen sind besonders schützenswert?
Die Art und Sensibilität der Daten bestimmen die erforderliche Sicherheitsstufe für Zugriffe.
Wichtiger Hinweis
Ein gutes Conditional Access Framework muss die Produktivität des Unternehmens sicherstellen, ohne den Arbeitsalltag einzuschränken. Die richtige Balance zwischen Sicherheit und Produktivität ist hierbei entscheidend.
Schritt 2: Auswahl der richtigen Lizenzen
Die Wahl der passenden Lizenzen ist ein zentraler Bestandteil der Einführung eines soliden Conditional Access Frameworks. Dabei sollten Sie folgende Punkte beachten:
Microsoft Entra ID P1 (als Teil von Microsoft 365 Business Premium oder Microsoft 365 E3)
Diese Lizenz ist notwendig für alle Benutzer, einschließlich Servicekonten (mit Ausnahme von Shared Mailboxen). Sie bietet die Grundlage für die Nutzung von Conditional Access.Microsoft Entra ID P2 (alternativ - empfohlen)
Diese Lizenz wird empfohlen, wenn risikobasierte Richtlinien eingesetzt werden sollen. Sie ermöglicht dynamische, automatisierte Reaktionen basierend auf dem Benutzer- und Anmelderisiko.
Abwägung Entra ID P1/P2
Die Vor- und Nachteile von Entra ID P1 und P2 sollten gegenübergestellt werden. Letztendlich muss der Kunde entscheiden, welches Risiko für ihn akzeptabel ist.
Schritt 3: Notfallzugriff absichern
Emergency Access Accounts sind essenziell, um im Notfall Zugriff auf Ihren Microsoft 365-Tenant zu behalten. Diese Konten sind von allen “Standard” Conditional Access Policies ausgenommen, besitzen jedoch eine eigene Richtlinie, die eine phishing-resistente MFA (z. B. FIDO2-Key) voraussetzt.
Warum sind diese Accounts so wichtig? Ohne sie könnten Sie bei einer fehlerhaften Konfiguration von Conditional Access oder einem Sicherheitsvorfall möglicherweise den Zugang zu Ihrem Tenant verlieren.
Für weitere Details und eine umfassende Anleitung lesen Sie den Blogbeitrag zum Thema Emergency Access Accounts: Microsoft 365 Emergency Access
Schritt 4: Hybride Umgebungen – Cloud und On-Premises sauber trennen
In hybriden Umgebungen ist es entscheidend, die Synchronisation zwischen lokalem Active Directory und Entra ID auf das nötige Minimum zu reduzieren, um Sicherheitsrisiken zu minimieren.
Empfehlungen:
Synchronisieren Sie nur Standard-User und Service-Konten, die in beiden Umgebungen benötigt werden.
Synchronisieren Sie niemals administrative Konten des Active Directory (Domain-Admins, Schema-Admins, etc.)
Trennen Sie Admin-Konten und andere privilegierte Identitäten strikt zwischen On-Premises und Cloud. Dies verringert das Risiko von Lateral Movement, also die Kompromittierung von Entra ID, wenn das Active Directory bereits befallen ist, oder umgekehrt.
Warum ist das wichtig?
Ein Beispiel: Wenn Angreifer über das lokale Active Directory Zugriff auf ein synchronisiertes Konto mit Domain-Admin Rechten erhalten, welches in Entra ID gleichzeitig Globale Administrator Rechte besitzt, sind zeitgleich beide Umgebungen (On-Premises und die Microsoft Cloud) “gefallen” sprich der Worst-case ist eingetreten. Derartig unüberlegte Synchronisationen eröffnen massive Angriffsflächen und erhöhen das Risiko eines einschlägigen Angriffs erheblich.
Tipp:
Konfigurieren Sie Entra ID Connect bzw. Entra Cloud Sync so, dass nur ausgewählte Organisationseinheiten des Active Directory synchronisiert werden. Voraussetzung ist natürlich, dass das lokale Active Directory und dessen OU-Struktur “aufgeräumt” sind. Eine klare Trennung und präzise Steuerung der Synchronisation verringert die Angriffsfläche erheblich.
Schritt 5: Nutzen Sie so viele Signale wie möglich
Die Integration von möglichst vielen Signalen macht Conditional Access effektiv. Conditional Access kann dynamisch reagieren, etwa auf verdächtige Anmeldeversuche oder nicht (mehr) konforme Geräte (so können Geräte, auf denen aktive Security-Incidents bestehen automatisch am weiteren Zugriff gehindert werden). Dadurch stehen mehr Daten zur Verfügung, die als Entscheidungsgrundlage für weitere Handlungen dienen.
Beispiele für die Nutzung von Signalen:
Beispiel 1: Microsoft Intune Compliance Policies und Defender Defender for Endpoint
Innerhalb von Microsoft Intune können Compliance-Policies angewendet werden, die ermitteln, ob ein Unternehmensendgerät als “sicher”, genauer “konform” eingestuft wird. Ein wichtiger Parameter ist dabei das Risiko-Level des Endgeräts, das durch Microsoft Defender for Endpoint ermittelt wird.Beispiel 2: Defender XDR und Entra Identity Protection
Diese Dienste liefern Risikosignale an Conditional Access. Wenn ein Benutzer in einen Sicherheitsvorfall verwickelt ist, wird sein Risiko-Score erhöht. Basierend darauf können Benutzer mit hohem Risiko entweder blockiert oder nur unter strengeren Sicherheitsvorgaben zugelassen werden.
Schritt 6: Authentifizierungsmethoden – Sicherheit im Wandel
Die Anforderungen an sichere Authentifizierungsmethoden haben sich über die Jahre drastisch verändert. Während früher die Nutzung starker Passwörter gepredigt wurde, sind diese heute längst nicht mehr ausreichend.
Von sicheren Passwörtern zu Multi-Faktor-Authentifizierung (MFA)
Passwörter allein bieten keinen ausreichenden Schutz, da sie leicht gestohlen oder erraten werden können.
Die Einführung von MFA war ein entscheidender Schritt, um die Sicherheit zu erhöhen. Neben dem Passwort wird ein zweiter Faktor wie ein Authenticator-Code benötigt.
Neue Bedrohungen: Token-Diebstahl
Doch auch klassisches MFA ist nicht unfehlbar. Angreifer nutzen mittlerweile Methoden wie Token Phishing durch echt aussehende Phishing-Websites, um Benutzer auszutricksen und Tokens abzugreifen. Diese digitalen "Besucherausweise", die nach einer erfolgreichen Anmeldung erstellt werden, erlauben Angreifern Zugriff auf betreffende Benutzerkonten – ohne Passwort oder erneute MFA-Bestätigung.
Die Lösung: Phishing-resistente Authentifizierungsmethoden
Phishing-resistente Anmeldemethoden wie FIDO2 oder biometrische Logins via Windows Hello For Business sind der Goldstandard moderner Authentifizierung. Sie bieten nicht nur höchste Sicherheit, sondern erleichtern auch den Anmeldeprozess für Benutzer, da diese Methoden intuitiv und benutzerfreundlich sind.
Empfehlung
Nutzen Sie FIDO2-Keys oder Passkeys über Android und iOS, um maximale Sicherheit zu gewährleisten. Dies gilt insbesondere für Konten mit privilegierten Rollen / Admins, da diese den größten Schaden anrichten können.
Wird über Conditional Access die Anmeldung von einem Unternehmensgerät (compliant Device oder Hybrid Joined Device) erfordert, gilt diese Anmeldung auch als phishing-resistent. Diese beiden Faktoren können von einem Angreifer nur extrem schwer erfüllt werden.
Schritt 7: Sind Standorte wirklich vertrauenswürdig?
Spoiler: Nein. Ein häufiges Szenario in Conditional Access ist, dass MFA nur außerhalb von als vertrauenswürdig definierten Standorten, gefordert wird. Dies mag praktisch erscheinen, birgt jedoch erhebliche Risiken:
Die Risiken vertrauenswürdiger Standorte:
Kein zweiter Faktor für lokale Nutzer: Mitarbeiter, die ausschließlich an diesen Standorten arbeiten, werden nicht zur Einrichtung eines zweiten Faktors aufgefordert.
Angreifer vor Ort: Sollten Angreifer bereits Geräte vor Ort kompromittiert haben, können sie diese zur Anmeldung verwenden und umgehen damit auch die Anforderung des zweiten Faktors.
Empfehlung
Generell:
MFA immer erzwingen, unabhängig vom Standort. Standorte sind in modernen Zero-Trust-Strategien keine sicheren Perimeter.
Wo MFA nicht möglich ist, da beispielsweise Legacy-Systeme Benutzer nur mit Single-Faktor authentifizieren können, sollten durch eigene Conditional Access Policies (eigene Persona-Gruppe) die Zugriffe auf nötige Geräte, ggf. IPs beschränkt werden um die Angriffsfläche zu verringern.
Bei Admins: Token-Laufzeit durch Verwendung der “Sign-In Frequency” verkürzen. Admins sollten sich generell nur von Intune-verwalteten, konformen Geräten (“compliant Devices”) anmelden dürfen. Besser: Admins dürfen sich nur noch von PAW’s (“Privileged Access Workstations”) einloggen.
Für externe Benutzer/Contractor:
Setzen Sie auf phishing-resistente Anmeldemethoden wie FIDO2.
Für Gast-Konten
MFA via Authenticator erzwingen.
Schritt 8: Personas
Ein effektives Conditional Access Framework basiert auf der Kategorisierung aller Benutzer in Persona-Gruppen. Das sind Gruppen, in der die Benutzer identische Zugriffsanforderungen haben, also Microsoft 365 ähnlich nutzen und ähnliche Voraussetzungen haben. Jede Persona-Gruppe erhält damit einen eigenen “Block” an Conditional Access Richtlinien.
Beispiele für Persona-Gruppen mit speziellen Sicherheitsanforderungen:
Administratoren:
Zugriff nur mit FIDO2-Keys und von Intune-verwalteten, konformen Geräten.
Sign-In-Frequency: Periodic Authentication - Every time.
Device Code Flow: geblockt.
Legacy-Authentifizierung: geblockt.
Sign-In-Risiko: Low, Medium, High: geblockt.
Benutzer-Risiko: Low, Medium, High: geblockt.
Gäste:
MFA via Microsoft Authenticator erzwungen
Sign-In-Frequency: 8h
Die spezifischen Anforderungen für jede Gruppe ergeben sich aus einer Analyse der Arbeitsweise des Unternehmens, wie in Schritt 1 beschrieben.
Wichtige Grundregel:
Alle Identitäten müssen einer Persona-Gruppe zugeordnet werden.
Benutzer ohne Zuweisung werden blockiert, bis ein Administrator sie in eine entsprechende Gruppe einordnet.
Dies gewährleistet, dass Zugriffsregeln immer explizit und nicht implizit erteilt werden.
Beispiele für Persona-Gruppen:
Die folgenden Persona-Gruppen sind in Enterprise-Umgebungen häufig vorzufinden und können als Vorlage dienen:
Global Protection: CA001–CA099
Admins: CA100–CA199
Internal User : CA200–CA299
External User: CA300–CA399
Guest User : CA400–CA499
Guest Admins: CA500–CA599
Microsoft 365 Service Accounts: CA600–CA699
Azure Service Accounts: CA700–CA799
Corporate Service Accounts: CA800–CA899
Workload Identities: CA900–CA999
Fazit
Die klare Gruppierung aller Benutzer in Persona-Gruppen schafft Struktur und erhöht die Sicherheit bei gleichzeitiger Flexibilität. Ein derartiges Framework soll außerdem die Lesbarkeit der Richtlinien sicherstellen und Troubleshooting vereinfachen.
Schritt 9: Conditional Access “geräuschlos” einführen
Die Einführung von Conditional Access sollte so geräuschlos wie nur möglich erfolgen, da bei jeder unerwünschten Blockierung eines Anmeldevorgangs die Produktivität beeinträchtigt wird. Damit dies gelingt, muss die Einführung gut geplant und vorbereitet werden.
Wie bleibt die Einführung reibungslos?
Um die potenziellen Auswirkungen der Einführung des neuen Conditional Access Frameworks zu “simulieren”, sollten die Conditional Access Richtlinien zunächst im “Report-Only” Modus betrieben werden. Die Dauer der Reporting-Phase hängt nicht zuletzt von der Größe des Unternehmens und dessen Reifegrad ab und dauert meist selten 2-4 Wochen lang, kann jedoch auch deutlich länger andauern. Während der Reporting-Phase müssen die Sign-In Logs und die potentiellen Auswirkungen der Conditional Access ausgewertet werden.
Nutzen Benutzer noch SMS als zweiten Faktor, obwohl der Microsoft Authenticator erzwungen werden soll? Dies würde in dieser Phase auffallen.
Würden Externe Mitarbeiter/Contractor nicht mehr einloggen können, da im neuen Policy-Set FIDO2 für die Anmeldung von nicht-verwalteten Geräten gefordert wird?
Wie werden die Policies ausgewertet?
Für die Analyse setzen wir auf einen Log Analytics Workspace, der in einer eigenen Azure Subscription erstellt wird. Dieser Workspace dient als Datenbank, um die Sign-In-Logs (möglichst längerfristig) zu speichern und auszuwerten.
Vorteile:
Längerfristige Aufbewahrungsmöglichkeit: Die Sign-In-Logs (Informationen darüber, wie und wann sich Benutzer anmelden) werden standardmäßig nur 30 Tage aufbewahrt. Werden die Sign-In-Logs in einen Log Analytics Workspace überführt, können Aufbewahrungszeiträume individuell festgelegt werden. Dies ist für forensische Zwecke (Post-Incident) äußerst wichtig.
Auswertung: Mit KQL-Abfragen (Kusto Query Language) können detaillierte Analysen durchgeführt werden.
Visualisierung: Ein benutzerdefiniertes Workbook stellt die Ergebnisse übersichtlich grafisch dar. Dadurch können die Auswirkungen der Report-Only-Policies transparent nachvollzogen werden.
Interactive vs. Non-Interactive Sign-Ins
Interactive Sign-Ins: Authentifizierungen, bei denen der Benutzer sich aktiv anmeldet, z. B. bei einer Anmeldung via Browser an office.com.
Non-Interactive Sign-Ins: Automatisierte Sign-Ins, die im Hintergrund ablaufen, z. B. Erneuerung von Tokens.
In Log Analytics gibt es ein Standard Workbook zur Auswertung der SignIn Logs. Hierbei ist jedoch zu beachten:
Das Standard-Workbook stellt nur Interactive Sign-Ins dar.
Non-Interactive Sign-Ins, die oft für Service-Konten oder automatisierte Prozesse relevant sind, fehlen in dieser Darstellung.
Es ist jedoch ebenso wichtig die Auswirkungen der neuen Richtlinien auf die Non-Interactive Sign-Ins zu ermitteln, da diese ebenfalls durch Conditional Access geschützt werden.
Combined Insights Workbook von Christopher Brumm
Danke an Christopher Brumm, der ein Workbook veröffentlicht hat, das sowohl Interactive als auch Non-Interactive Sign-Ins berücksichtigt. Dieses Workbook erleichtert die Einführung von Conditional Access erheblich, da es eine vollständige Auswertung der Report-Only Policies ermöglicht.
Link: crmhh/CAWorkbooks
Schritt 10: Das Conditional Access Regelwerk
Im Folgenden finden Sie eine Übersicht über ein beispielhaftes Conditional Access Policy-Set für “Global” als für alle Personas und speziell für Admins, um das Framework zu veranschaulichen:
Globale Richtlinien
Diese Richtlinien schützen alle Personas und definieren grundlegende Sicherheitsstandards.
CA001-Global-BaseProtection-AllApps-AnyPlatform-BlockNonPersonas
Funktion: Blockiert alle Benutzer, die keiner Persona-Gruppe zugeordnet sind, um unautorisierte Zugriffe zu verhindern.CA002-Global-BaseProtection-AllApps-AnyPlatform-ProtectedAction-CA-PhisResMFA
Funktion: Erlaubt Änderungen am Conditional Access Framework nur, wenn sich der Administrator mit einer phishing-resistenten MFA-Methode (z. B. FIDO2) authentifiziert.CA010-EmergencyAccounts-IdentityProtection-AllApps-AnyPlatform-PhishResMFA
Funktion: Stellt sicher, dass Emergency Access Accounts ausschließlich mit phishing-resistenten MFA-Methoden genutzt werden können.
Admin Richtlinien
Administratoren haben die höchsten Sicherheitsanforderungen, da sie wegen ihrer hohen Berechtigungen den größten Schaden anrichten können.
CA100-Admins-BaseProtection-AllApps-AnyPlatform-CompliantandMFA
Funktion: Erlaubt Administratoren Zugriff nur mit compliant devices und MFA.CA101-Admins-BaseProtection-AllApps-AnyPlatform-PhishResMFA
Funktion: Setzt den Einsatz von phishing-resistenten MFA-Methoden wie FIDO2 voraus.CA102-Admins-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration
Funktion: Definiert die Sicherheitsanforderungen, unter welchen Änderungen an den Sicherheitsmethoden durchgeführt werden dürfen.CA103-Admins-IdentityProtection-AllApps-AnyPlatform-MFAforMediumRiskUser
Funktion: Erfordert MFA für Admins mit mittlerem Risiko oder höher, basierend auf Identity Protection Signalen.CA104-Admins-IdentityProtection-AllApps-AnyPlatform-MFAforMediumRiskySignIns
Funktion: Eine erneute MFA-Abfrage ist erforderlich bei Anmeldungen ab einem mittleren Anmelde-Risiko.CA105-Admins-IdentityProtection-AllApps-AnyPlatform-BlockLegacyAuth
Funktion: Blockiert unsichere Authentifizierungsmethoden wie Basic Authentication.CA106-Admins-AttackSurfaceReduction-AllApps-AnyPlatform-NoPersBrowserSession
Funktion: Verhindert persistente Sitzungen in Browsern, um das Risiko von gestohlenen Sitzungstokens zu minimieren.CA107-Admins-AttackSurfaceReduction-AllApps-AnyPlatform-BlockUnknownPlatforms
Funktion: Blockiert den Zugriff von unbekannten oder nicht unterstützten Plattformen.CA108-Admins-AttackSurfaceReduction-AllApps-AnyPlatform-DenyDeviceCodeFlow
Funktion: Verhindert Anmeldungen über unsichere Devicecode-Flows.
Schritt 11. Low-Hanging Fruits
Zur schnellen Verringerung des Risikos identitätsbasierte Angriffe sollten folgende Maßnahmen umgesetzt werden:
Authentication Strength für alle User und Gäste erzwingen (z.B. Microsoft Authenticator erfordern)
Phishing Resistente MFA-Methode für alle Admins erzwingen
Nutzungsradius für Service-Konten einschränken: Service-Konten via Conditional Access einschränken, z.B. den Login auf bestimmte IP’s beschränken.
Security Info Registration absichern (z.B. durch Anforderung eines compliant Device oder durch MFA - erstmalige Registrierung kann via Temporary-Access-Pass erfolgen)
Legacy-Protokolle blockieren: Blockieren Sie unsichere legacy Protokolle wie SMTP-Auth, da diese oft von Angreifern ausgenutzt werden. Die Angriffsversuche sind im Entra ID-Portal einsehbar.
Device Code Flow blockieren: Device Code Flow gilt als unsichere Anmeldemethode und sollte auf Grund des hohen Risikos nach Möglichkeit blockiert werden.
Token-Lifetime verkürzen: Reduzieren Sie die Gültigkeitsdauer von Tokens, damit Admins zyklisch erneut authentifizieren müssen und damit privilegierte Tokens nicht dauerhaft auf Geräten verweilen, von wo diese abgegriffen und missbraucht werden können.
Risk-based Policies: Reagieren Sie dynamisch auf Sicherheitsbedrohungen, z. B. bei verdächtigen Ortswechseln eines Benutzers.
Diese Maßnahmen bieten eine solide Grundlage, um mit Conditional Access die Sicherheit schnell zu erhöhen – und die Sicherheitslücken zu schließen, die Angreifer am häufigsten ausnutzen.
Fazit: Conditional Access: Mächtig, aber nur mit klarem Konzept effektiv
Conditional Access ist ein äußerst mächtiges Tool, das Unternehmen vor modernen Bedrohungen schützen kann. Doch in der Praxis finden wir häufig lückenhafte Regelwerke vor. Sicherheitsverantwortliche sollten sich bewusst sein, dass ein umfassendes Conditional Access Framework sorgfältig geplant, implementiert und regelmäßig überprüft werden muss, um das Risiko identitätsbasierte Angriffe stark zu reduzieren.
