Risikobasierte Zugriffsrichtlinien (Risk Based Policies) - sind sie wirklich aktiv oder schlummern sie nur als Konfigurationsidee im Portal? In diesem Artikel zeige ich Dir, worauf es bei der Überprüfung bestehender Regeln ankommt und wie Du neue Richtlinien granular aufsetzt. So geben wir Deinem Tenant eine wichtige Security-Auffrischung!
Aber bevor wir tiefer einsteigen, werfen wir nochmal einen kurzen Blick auf die Grundlagen:
In der Microsoft-Umgebung sind Microsoft Entra ID Protection und Microsoft Conditional Access zwei wichtige Systeme, die zusammen für starke Sicherheitskonfigurationen sorgen. Damit wir ihre Funktionen wirklich effektiv nutzen können, ist es wichtig zu wissen: Welches System übernimmt welche Aufgabe?
Hier ein kompakter Überblick:
Wie genau arbeiten ID Protection und Conditional Access zusammen?
Sobald sich ein Benutzer anmeldet, stellt sich die Frage: Ist das wirklich die Person, die sie vorgibt zu sein? Und selbst wenn ja – passt der Zugriff in diesem Moment überhaupt zur Situation? Genau hier greifen Microsoft Entra ID Protection und Conditional Access ineinander.
Die beiden Dienste arbeiten nicht nebeneinander, sondern miteinander: Während ID Protection Risiken erkennt und analysiert, sorgt Conditional Access dafür, dass automatisch die passende Reaktion erfolgt – vom zusätzlichen MFA bis hin zur sofortigen Sperre. Das bildet die Grundlage einer risikobasierte Zugriffsrichtlinien.
Die folgende Übersicht zeigt, wie dieses Zusammenspiel konkret aussieht – und warum es sich lohnt, beide Funktionen gemeinsam zu nutzen.
ID Protection | Conditional Access | Effekt der Zusammenarbeit |
|---|---|---|
Erkennt riskante Anmeldungen | Setzt Richtlinien bei riskanten Anmeldungen durch | Automatische Blockierung oder MFA bei Bedrohungen |
Bewertet das Benutzerrisiko | Reagiert mit Richtlinien z.B. auf mittleres/hohes Risiko | Adaptive Zugriffsregeln |
Lernt und analysiert Verhaltensweisen | Entscheidet über Zugriff basierend auf Ergebnissen | Dynamische, kontextbezogene Entscheidungen |
Erstellt Warnungen und Berichte | Ermöglicht automatische Aktionen | Frühzeitige Reaktion und Begrenzung von Vorfällen |
ID Protection und Conditional Access sind also ein perfektes Frühwarnsystem, das potenzielle Risiken bei Anmeldeversuchen identifiziert und das Verhalten von Benutzern analysiert. Bedrohungen werden so automatisch geblockt und gib uns Zeit zum Reagieren.
Standardfehler beim Konfigurieren risikobasierter Zugriffsrichtlinien
Wenn Deine Organisation über eine Microsoft Entra Premium P2-Lizenz verfügt, hast Du wahrscheinlich bereits risikobasierte Zugriffsrichtlinien konfiguriert. Es gibt da jedoch einen bestimmten Fehler, der sich immer wieder gerne einschleicht: zu detaillierte Richtlinien! Besonders in Conditional Access entstehen so schnell Sicherheitslücken, die von Hackern direkt ausgenutzt werden können.
Dieser Fehler ist perfekt, um Dir zu erklären, wie Du falsch konfigurierte oder sogar fehlende risikobasierte Zugriffsrichtlinien optimal aufsetzt. Nehmen wir dazu ein Beispiel: eine Multi-Faktor-Authentifizierung für Microsoft 365 Office-Benutzer für das macOS-Betriebssystem.
Werfen wir einen Blick auf den folgenden Screenshot. Was kannst Du erkennen?
Wir sehen, dass die Bedingung für die Geräteplattform nicht erfüllt wurde. Woran liegt das? Die MFA greift immer nur dann, wenn alle Bedingungen erfüllt sind. In diesem Szenario wäre der Tenant für Zugriffe von Windows-Geräten ohne MFA nicht geschützt, selbst wenn andere Bedingungen erfüllt sind.
Wie können wir das nun ausbügeln?
Risikobasierte Zugriffsrichtlinien mit ID Protection konfigurieren
Mit dem integrierten Identitätsschutz ID Protection können wir die folgenden Bedrohungen erkennen und – bei Bedarf – automatisch entschärfen:
- Anmelderisiko: Wie hoch ist die Wahrscheinlichkeit einer unautorisierten Anmeldungsanfrage?
- Benutzerrisiko: Wie hoch ist die Wahrscheinlichkeit, dass ein Konto gehackt wurde?
Conditional Access ermöglicht es uns dann, eine automatische Reaktion zu erzwingen, sobald solche Risikobedingungen erfüllt sind. Typischerweise wird ein erkanntes Anmelderisiko durch die Anforderung einer Multi-Faktor-Authentifizierung (MFA) behoben. Ein Benutzerrisiko hingegen wird meist durch die Aufforderung zu einer sicheren Passwortzurücksetzung entschärft.
Wir haben also für zwei unterschiedliche Risikoereignisse auch zwei unterschiedliche präventive Maßnahmen. Da ist es verlockend, sowohl Anmelde- als auch Benutzerrisiken in einer einzigen Conditional Access-Richtlinie zu definieren.
Ich betone nochmal, dass risikobasierte Zugriffsrichtlinien in Conditional Access nur dann in Kraft treten, wenn ALLE definierten Bedingungen erfüllt sind. Das ist ein kritischer Punkt.
Als Beispiel: Du hast eine Richtlinie erstellt, die MFA erzwingt, wenn ein Anmelderisiko ODER ein Benutzerrisiko erkannt wird. Wenn diese "ODER"-Verknüpfung intern durch eine "UND"-Logik der Conditional Access Engine interpretiert wird (was bei mehreren Bedingungen der Fall ist), dann entsteht ein Problem:
Wenn beispielsweise ein Benutzer für eine riskante Anmeldung markiert wird (z.B. durch Zugriff über einen TOR-Browser), aber sein Benutzerkonto selbst nicht als gehackt gilt (also kein Benutzerrisiko vorliegt), dann würde die kombinierten risikobasierten Zugriffsrichtlinien möglicherweise nicht greifen. Da nicht beide Bedingungen (Anmelderisiko UND Benutzerrisiko) gleichzeitig erfüllt sind, bleibt die gewünschte Sicherheitsmaßnahme aus.
Ich verdeutliche nochmal anhand einer simulierten riskanten Anmeldung über einen TOR-Browser, warum das Zusammenfassen dieser beiden Risikotypen in einer einzigen risikobasierte Zugriffsrichtlinie eine schlechte Idee sein kann:
Und das ist ein kritischer Punkt: Auch wenn das Anmelderisiko als "Mittel" eingestuft wird, greift die Richtlinie nicht, solange das Benutzerrisiko nicht ebenfalls den konfigurierten Schwellenwert erreicht. Die Regel tritt erst in Kraft, wenn beide Bedingungen erfüllt sind.
Die Kombination von Anmelderisiko und Benutzerrisiko in einer einzigen risikobasierten Zugriffsrichtlinie führt dazu, dass der Zugriff nur dann blockiert wird, wenn beide Risikotypen für die jeweilige Anmeldung zutreffen.
Obwohl das Benutzerrisiko nach einem solchen Vorfall wahrscheinlich ebenfalls ansteigen wird, werden risikobasierte Zugriffsrichtlinien erst bei der nächsten interaktiven Anmeldung neu bewertet. Die Richtlinie funktioniert also nur in dem speziellen Moment korrekt, wenn sowohl das Benutzerrisiko als auch das Anmelderisiko den definierten Schwellenwert erreichen.
Was Microsoft empfiehlt
Gemäß den Microsoft-Empfehlungen ist es definitiv ratsam, zwei separate risikobasierte Zugriffsrichtlinien für das Anmelderisiko und das Benutzerrisiko zu erstellen - und da stimme ich zu!
Auch wenn beide Richtlinien letztendlich den Zugriff blockieren sollen, bietet die Trennung entscheidende Vorteile:
Durch diese klare Trennung stellst Du sicher, dass jede Risikokategorie ihre spezifische, effektive Gegenmaßnahme erhält und Du nicht in die Falle der "UND"-Verknüpfung tappst, die schnell Sicherheitslücken erzeugt.
Separate Minderungsstrategien
Risikotyp | Empfohlene Reaktion | Beispiel für Richtlinienmaßnahme |
|---|---|---|
Anmelderisiko | Verdächtige Sitzungen stoppen oder stärkere Authentifizierung verlangen | Anmeldung blockieren oder MFA verlangen |
Benutzerrisiko | Die kompromittierte Identität beheben | Passwort-Zurücksetzung verlangen oder Zugriff blockieren |
Unsichere risikobasierte Zugriffsrichtlinien finden
Sicher graust es Dir jetzt davor, jede einzelne Konfiguration durchzugehen, um Sicherheitslücken zu finden. Das kann ganz schön Zeit kosten - aber es gibt ein Tool, das Dir da das Leben einfacher macht: Maester-Test.
Dieser spezielle Test überprüft, ob das Anmelderisiko und das Benutzerrisiko in einer einzigen Richtlinie konfiguriert wurden.
Und so könnte es aussehen, wenn das Tool eine unsichere Konfiguration findet:
Zusammenfassung: So optimierst Du Deine Sicherheit
Auch wenn eine Konfiguration auf den ersten Blick logisch wirkt, kann sie dennoch einige Schwachstellen haben. Um das zu vermeiden und Deinen Tenant sicher zu halten, solltest Du alle möglichen Risiken mit je einer bestimmten risikobasierten Zugriffsrichtlinie abdecken.
Hier sind alle Vorteile von separaten Richtlinien aufgelistet:
Also - nochmal zu Erinnerung: Damit risikobasierte Zugriffsrichtlinien individuell wirksam wird, müssen ALLE ihre Bedingungen erfüllt sein! Definiere deswegen immer separate Richtlinien für das Anmelderisiko und das Benutzerrisiko.
Wichtig ist auch, dass Du Deine Konfigurationen regelmäßig überprüfst. So stellst Du sicher, dass Deine Sicherheitskonfigurationen stets aktuell und wirksam sind.
Bereit, Deinen Microsoft 365 auf das nächste Level zu bringen?
Wenn Du Expertenberatung oder praktische Hilfe bei der Implementierung dieser Strategien benötigst, kontaktiere uns bitte über das Kontaktformular unten. Ein sicherer Tenant ist entscheidend für den Schutz sensibler Daten. Gemeinsam werden wir eine sichere, effiziente Umgebung gestalten, die Deine sich entwickelnden Geschäftsanforderungen unterstützt.
Schau Dir doch auch die anderen Tutorials und Tipps an, die ich bereits auf meinem Blog geteilt habe. Dort findest Du auch andere Beiträge zu Microsoft Security-Relevanen Themen, u.a. zum Microsoft Defender for Cloud Apps, Microsoft Intune, der Enterprise & Mobility-Suite, dem Microsoft 365 Defender oder der Microsoft Information Protection.
Ich bin stehts bemüht, die aktuellsten Themen und Fragestellungen meiner Kunden zu beantworten, um Dich bei der Arbeit mit der Microsoft Cloud Security und anderen Microsoft 365 Produkten zu unterstützen.
Wenn Du Fragen hast, melde Dich sehr gerne bei mir!
