Conditional Access: Best Practices für die Implementierung von MFA und Sicherheitsrichtlinien

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?

Abhängig von der Lizenzierung haben Sie bei der Nutzung von Microsoft 365 zwei grundlegende Möglichkeiten Ihre Identitäten zu schützen.

1. 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 (mind. Entra ID Premium P1). 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.

2. 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

Aus meiner jahrelangen Erfahrung bei der Umsetzung von Conditional Access (CA)-Projekten weiß ich: Einfach gesagt entscheidet Conditional Access, ob ein Zugriff erlaubt oder blockiert wird – unter Berücksichtigung der definierten Sicherheitsvorgaben.

Das Motto lautet: "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 alle Benutzer dazu verpflichtet, MFA zu verwenden – etwa via Microsoft Authenticator. Dabei werden oftmals die öffentlichen IP-Adressen der Unternehmensstandorte von dieser Regel ausgenommen, da diese als vertrauenswürdig deklariert werden.

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 sich vor Ort ins Netzwerk einschleichen, können Identitäten leicht kompromittieren, da nur Benutzername und Passwort benötigt werden.

Das Ergebnis: Es entsteht eine große Angriffsfläche. Angreifer, die sich ins Unternehmensnetzwerk einschleusen, können Identitäten leicht kompromittieren, da zur Anmeldung nur der Benutzername und das Passwort benötigt werden. Wenn diese Benutzer dann eines Tages extern arbeiten, benötigen sie oft Unterstützung der IT, um ihren zweiten Faktor einzurichten.

Das Problem

Derartige Conditional Access Implementierungen haben zur Folge, dass in Wirklichkeit nur ein kleiner Teil der Zugriffe durch Conditional Access geschützt ist – der Großteil bleibt verwundbar.

Meine Empfehlung

In Cloud-Umgebungen ist Identity der wichtigste Perimeter. Jeder IT-Administrator oder IT-Sicherheitsverantwortliche sollte daher sein Conditional Access Framework regelmäßig überprüfen lassen.
Nur so kann sichergestellt werden, dass:

1. 100% der Anmeldevorgänge durch Conditional Access geschützt sind / keine Anmeldungen an Conditional Access “vorbeigehen”.

2. Fehlkonfigurationen zeitnah entdeckt werden können.

3. Das Framework kontinuierlich weiterentwickelt wird.

Ein regelmäßiges, professionelles Review minimiert Risiken und maximiert die Sicherheit – und das nachhaltig.

Welche Lizenzen benötigt man für Conditional Access?

Um Conditional Access nutzen zu können, benötigen Sie mindestens folgende Lizenzen:

1. 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.

2. Microsoft Entra ID P2 (optional)

• 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.

Was passiert 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 den höchsten Sicherheitsstandard zu gewährleisten. 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.

Einführung von Conditional Access

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) ist essenziell, um Zugriffsrichtlinien passend zu gestalten.

• Welche Systeme sind besonders schützenswert?
  Die Art und Sensibilität der Daten bestimmen die erforderliche Sicherheitsstufe für Zugriffe.

Wichtiger Hinweis

Ein erfolgreiches Conditional Access Framework muss die Produktivität des Unternehmens sicherstellen, ohne den Arbeitsalltag einzuschränken. Die richtige Balance zwischen Sicherheit und Benutzerfreundlichkeit/Produktivität ist hierbei entscheidend.

Schritt 2: Lizenzierung – Die richtigen Lizenzen auswählen

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 oder Business Premium
  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
  Diese Lizenz wird empfohlen, wenn risikobasierte Richtlinien eingesetzt werden sollen. Sie ermöglicht dynamische Sicherheitsmaßnahmen basierend auf dem Benutzer- und Anmelderisiko.

Tipp

Die Vor- und Nachteile der Entra ID Security Defaults sowie 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 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 richtig zu konfigurieren, um Sicherheitsrisiken zu minimieren.

Empfehlungen:

• Synchronisieren Sie nur Standard-User und Service-Konten, die in beiden Umgebungen benötigt werden.

• 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 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 schützt sowohl Ihre lokale als auch Ihre Cloud-Infrastruktur vor Angriffen.

Schritt 5: Nutzen Sie so viele Signale wie möglich

Die Integration von möglichst vielen Signalen macht Ihre Sicherheitsstrategie effektiv. Conditional Access kann dynamisch reagieren – etwa auf verdächtige Anmeldeversuche oder nicht (mehr) konforme Geräte. Dadurch stehen mehr Daten zur Verfügung, die als Entscheidungsgrundlage für weitere Handlungen (automatisiert oder manuell) 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 definiert, die ermitteln, ob ein Unternehmensendgerät als “sicher” 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.

Tipp:

Je mehr Features Sie aktiv nutzen, desto mehr Signale stehen Ihnen zur Verfügung. Insbesondere durch die Nutzung von Microsoft Intune und Defender for Endpoint können die Conditional Access Richtlinien mit wertvollen Signalen angereichert werden, die zu sichereren Zugriffen führen.

Schritt 6: Authentifizierungsmethoden – Sicherheit im Wandel

Die Anforderungen an sichere Authentifizierungsmethoden haben sich über die Jahre drastisch verändert. Während früher starke Passwörter ausreichten, sind diese heute längst nicht mehr ausreichend.

Von sicheren Passwörtern zu Multi-Faktor-Authentifizierung (MFA)

• Passwörter allein bieten keinen ausreichenden Schutz mehr, 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 eine SMS oder ein Authenticator-Code benötigt.

Neue Bedrohungen: Token-Diebstahl

Doch auch 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 Systeme – ohne das Passwort oder den zweiten Faktor erneut eingeben zu müssen.

Die Lösung: Phishing-resistente Authentifizierungsmethoden

Phishing-resistente Anmeldemethoden wie FIDO2 oder biometrische Logins 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.

• Wird über Conditional Access die Anmeldung von einem Unternehmensgerät (compliant Device oder Hybrid Joined Device) erfordert, gilt diese Anmeldung auch als phishing-resistent.

• Falls dies nicht möglich ist, setzen Sie mindestens auf den Microsoft Authenticator mit aktiviertem Passwordless Login.

Schritt 7: Sind Standorte wirklich vertrauenswürdig?

Ein häufiges Szenario in Conditional Access ist, dass MFA nur außerhalb von als vertrauenswürdig definierten Standorten, wie Firmenbüros, 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, müssen keinen zweiten Faktor einrichten.

• 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.

• Einschränkungen für mobile Nutzer: Wenn Mitarbeiter plötzlich außerhalb des Firmenstandorts arbeiten, benötigen sie oft Unterstützung der IT, um MFA einzurichten.

Empfehlung

• Für interne Benutzer und Administratoren:

  • MFA immer erzwingen, unabhängig vom Standort.

  • Kombinieren Sie dies mit der Nutzung von compliant devices, um ein höheres Sicherheitsniveau zu erreichen.

• Für Gäste und externe Benutzer:

  • Setzen Sie auf phishing-resistente MFA-Methoden, auch wenn diese Benutzer keine compliant devices nutzen.

Schritt 8: Personas

Ein effektives Conditional Access Framework basiert auf der Kategorisierung aller Benutzer in Persona-Gruppen. Das sind Gruppen, in der die Benutzer ähnliche Zugriffe haben, also Microsoft 365 ähnlich nutzen und ähnliche Voraussetzungen haben. Jede Gruppe erhält passgenaue Sicherheitsrichtlinien, die sowohl Schutz als auch Produktivität sicherstellen.

Beispiele für Persona-Gruppen und Sicherheitsanforderungen:

• Administratoren:

  • Zugriff nur mit FIDO2-Keys und compliant devices.

  • Strikte Sicherheitsrichtlinien, da sie besonders attraktive Angriffsziele sind.

• Gäste:

  • Oft kein Firmengerät oder FIDO-Key verfügbar.

  • Absicherung durch alternative Sicherheitsmaßnahmen wie phishing-sichere MFA-Methoden.

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 der Zugriff auf Microsoft 365 klar geregelt und sicher bleibt.

Welche Personas gibt es?

Die folgende Struktur wurde für Enterprise-Umgebungen entwickelt und deckt alle gängigen Identitäten ab:

• Global Protection: CA001–CA099

• Admins Protection: CA100–CA199

• Internals User Protection: CA200–CA299

• Externals User Protection: CA300–CA399

• Guests User Protection: CA400–CA499

• Guest Admins Protection: 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 Kategorisierung aller Benutzer in Persona-Gruppen schafft Struktur und erhöht die Sicherheit. Maßgeschneiderte Richtlinien für jede Gruppe sorgen dafür, dass alle Identitäten geschützt sind und die Produktivität gewährleistet ist. Ein derartiges Framework soll außerdem die Lesbarkeit der Richtlinien sicherstellen und Troubleshooting vereinfachen.

Schritt 9: Conditional Access geräuschlos einführen

Das Ziel bei der Einführung eines Conditional Access Frameworks ist, dass der Prozess möglichst reibungslos abläuft. Der Kunde sollte im Arbeitsalltag kaum etwas von der Umstellung merken, während im Hintergrund alle Identitäten und Zugriffe abgesichert werden.

Wie bleibt die Einführung reibungslos?

Um sicherzustellen, dass alle Aspekte berücksichtigt werden, ist es wichtig, Policies im Report-Only-Modus zu testen. Dabei sollten regelmäßig Auswertungen durchgeführt werden, um Auswirkungen genau zu verstehen und Anpassungen frühzeitig vorzunehmen.

• Simulation: Innerhalb von 2-4 Wochen analysieren wir, welche Auswirkungen die Policies auf die Nutzer haben könnten.

• Optimierung: Die Policies können schrittweise an die Arbeitsweise des Unternehmens angepasst werden, ohne Störungen im täglichen Betrieb zu verursachen.

Wie werden die Policies ausgewertet?

Für eine effektive 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 zu speichern und auszuwerten.

• Datenbasis: Die Sign-In-Logs (Informationen darüber, wie und wann sich Benutzer anmelden) werden in diese Datenbank übertragen.

• 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 an einem Dienst oder Portal.

• Non-Interactive Sign-Ins: Automatisierte Authentifizierungen, die im Hintergrund ablaufen, z. B. wenn Anwendungen Tokens für den Zugriff auf Dienste erneuern.

In Log Analytics gibt es bereits 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.

Die fehlenden Non-Interactive Sign-Ins können bei der Einführung von Conditional Access Probleme verursachen, da nicht alle Auswirkungen sichtbar sind.

Dank an Christopher Brumm

An dieser Stelle möchte ich Christopher Brumm danken, 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 Analyse 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 Framework, das auf die Arbeitsweise eines fiktiven Kunden, dessen Lizenzierung sowie die Möglichkeiten der Microsoft Cloud abgestimmt ist. Jede Persona-Gruppe erhält spezifische Sicherheitsrichtlinien, die sowohl Schutz als auch Produktivität berücksichtigen.

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.
  Beispiel: Ein neu angelegter Benutzer ohne Zuweisung zu einer Persona-Gruppe wird standardmäßig blockiert, bis ein Administrator ihn einer Gruppe zuordnet.

• CA002-Global-BaseProtection-AllApps-AnyPlatform-ProtectedAction-CA-PWlessMFA
  Funktion: Erlaubt Änderungen am Conditional Access Framework nur, wenn sich der Administrator mit einer phishing-resistenten MFA-Methode (z. B. FIDO2) authentifiziert.
  Beispiel: Änderungen an den CA-Policies können nur von einem Administrator mit höchsten Sicherheitsstandards vorgenommen werden.

• CA010-EmergencyAccounts-IdentityProtection-AllApps-AnyPlatform-PhishingResistentMFA
  Funktion: Stellt sicher, dass Emergency Access Accounts ausschließlich mit phishing-resistenten MFA-Methoden genutzt werden können.
  Beispiel: Diese Policy schützt Notfallkonten vor Phishing-Angriffen, die gezielt auf MFA-Schwächen abzielen.

Admin Richtlinien

Administratoren haben die höchsten Sicherheitsanforderungen, da sie Zugriff auf kritische Systeme und Daten haben.

• CA100-Admins-BaseProtection-AllApps-AnyPlatform-CompliantandMFA
  Funktion: Erlaubt Administratoren Zugriff nur mit compliant devices und durchgeführter MFA.
  Beispiel: Ein Administrator kann sich nur anmelden, wenn das Gerät den Compliance-Richtlinien entspricht und MFA erfolgreich abgeschlossen wurde.

• CA101-Admins-BaseProtection-AllApps-AnyPlatform-PhishingResistentMFA
  Funktion: Setzt den Einsatz von phishing-resistenten MFA-Methoden wie FIDO2 voraus.
  Beispiel: Ein Administrator kann sich nur anmelden, wenn ein FIDO2-Key zur Authentifizierung verwendet wird.

• CA102-Admins-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration
  Funktion: Definiert die Sicherheitsanforderungen, unter welchen Änderungen an den Sicherheitsmethoden durchgeführt werden dürfen.
  Beispiel: Ein neuer Administrator benötigt ein compliant Device und MFA (oder einen Temporary-Access-Pass), um seinen Passkey zu registrieren.

• CA103-Admins-IdentityProtection-AllApps-AnyPlatform-MFAforMediumRiskUser
  Funktion: Erfordert MFA für Benutzer mit mittlerem Risiko oder höher, basierend auf Identity Protection Signalen.
  Beispiel: Ein Administrator dessen Konto Risiken aufweist, da es in Incidents verwickelt ist, wird mit Risiko: Hoch deklariert und muss erneut die MFA durchführen.

• CA104-Admins-IdentityProtection-AllApps-AnyPlatform-MFAforMediumRiskySignIns
  Funktion: MFA ist erforderlich bei Anmeldungen ab einem mittleren Anmelde-Risiko.
  Beispiel: Ein Administrator, der sich von einer neuen IP-Adresse aus anmeldet, wird zur MFA-Authentifizierung gezwungen.

• CA105-Admins-IdentityProtection-AllApps-AnyPlatform-BlockLegacyAuth
  Funktion: Blockiert unsichere Authentifizierungsmethoden wie Basic Authentication.
  Beispiel: Ein Administrator wird daran gehindert, unsichere legacy-Methoden wie SMTP-Auth. oder POP3 zu verwenden.

• CA106-Admins-AttackSurfaceReduction-AllApps-AnyPlatform-NoPersBrowserSession-ExcCompl
  Funktion: Verhindert persistente Sitzungen in Browsern, um das Risiko von gestohlenen Sitzungstokens zu minimieren.
  Beispiel: Administratoren müssen sich nach jeder Sitzung erneut authentifizieren.

• CA107-Admins-AttackSurfaceReduction-AllApps-AnyPlatform-BlockUnknownPlatforms
  Funktion: Blockiert den Zugriff von unbekannten oder nicht unterstützten Plattformen.
  Beispiel: Ein Administrator kann sich nicht über ein Gerät mit einem nicht unterstützten Betriebssystem anmelden.

• CA108-Admins-AttackSurfaceReduction-AllApps-AnyPlatform-DenyDeviceCodeFlow
  Funktion: Verhindert Anmeldungen über unsichere Devicecode-Flows.
  Beispiel: Ein Administrator kann sich nicht über Devicecode-Flows wie IoT-Anmeldungen authentifizieren.

Internals (Mitarbeiter) Richtlinien

Die Sicherheitsrichtlinien für interne Mitarbeiter kombinieren MFA und Compliance-Anforderungen für Desktop- und mobile Geräte.

• CA200-Internals-BaseProtection-AllApps-DesktopOS-CompliantandMFA
  Funktion: Desktop-Zugriff nur mit compliant devices und aktiviertem MFA.
  Beispiel: Mitarbeiter können auf ihrem Laptop nur zugreifen, wenn das Gerät compliant ist und MFA durchgeführt wurde.

• CA201-Internals-BaseProtection-AllApps-SmartphoneOS-MFA
  Funktion: Aktiviert MFA für den Zugriff von Smartphones.
  Beispiel: Mitarbeiter, die sich mit ihrem Smartphone anmelden, müssen MFA verwenden.

Hinweis

Weitere Policies nicht im Detail aufgeführt, folgen jedoch den gleichen Prinzipien: spezifischer Schutz für verschiedene Zugriffsarten und Szenarien.

Schritt 11. Low-Hanging Fruits

Für den schnellen Einstieg und eine Verbesserung Ihrer Sicherheitslage sollten Sie die folgenden Maßnahmen umsetzen:

• MFA für alle User erzwingen: Schützen Sie alle Konten mit einem zweiten Faktor.

• Nutzungsradius für Service-Konten einschränken: Service-Konten via Conditional Access einschränken, z.B. den Login auf bestimmte IP’s beschränken.

• Legacy-Protokolle einschränken: Blockieren Sie unsichere legacy Protokolle wie SMTP-Auth, da diese oft von Angreifern ausgenutzt werden. Die Angriffsversuche sind im Entra ID-Portal einsehbar.

• Token-Lifetime beschränken: Reduzieren Sie die Gültigkeitsdauer von Tokens, damit Benutzer nach erfolgreicher MFA-Authentifizierung zyklisch erneut authentifizieren müssen.

• Risk-based Policies: Reagieren Sie dynamisch auf Sicherheitsbedrohungen, z. B. bei verdächtigen Ortswechseln eines Benutzers.

• Zugriff auf OneDrive und SharePoint einschränken: Setzen Sie klare Regeln für nicht-compliant devices, wie das Verhindern von Downloads oder Kopiervorgängen.

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 maximale Sicherheit zu gewährleisten.

Wie dargestellt, kann die Einführung von Conditional Access mit geringstmöglichen Beeinträchtigungen auf die Benutzer erfolgen – vorausgesetzt, sie wird mit sorgfältiger Planung und den richtigen Methoden umgesetzt.