Der einfache Einstieg in das Thema «Conditional Access Policies»

Viele Unternehmen setzen heutzutage auf Microsoft-365-Dienste. Mit der zunehmenden Beliebtheit dieser Dienste steigt auch die Attraktivität als potenzielles Angriffsziel für Hacker. Erfahrungsgemäss gibt es noch immer Unternehmen, die es versäumt haben, ihren Microsoft-Cloud-Mandanten abzusichern. Daher sollten Unternehmen Schutzmassnahmen gegen Cyberattacken treffen – Conditional Access Policies (CAP) sind eine solche Massnahme. In diesem Artikel erhalten Sie einen Überblick, wie Conditional Access Policies (CAP) funktionieren.

Um sich als Unternehmen vor Cyberangriffen zu schützen, eignet sich in Microsoft Entra ID die Funktion Conditional Access. Sie ermöglicht es, den Zugriff auf Cloud-Daten einzuschränken, eine Multi-Faktor-Authentifizierung zu erzwingen oder sogar den Zugriff zu verweigern, wenn bestimmte Bedingungen nicht erfüllt sind.

Fehlkonfigurationen bei der Erstimplementierung oder im täglichen Betrieb der Conditional Access Policies können sich jedoch auch negativ auf die Verfügbarkeit von Cloud-Diensten für die Nutzer auswirken. Darüber hinaus können Lücken in der Abdeckung der Richtlinien entstehen, welche es einem Angreifer ermöglichen könnten, die Conditional Access Policies zu umgehen. Deswegen empfiehlt es sich, ein Verständnis dafür zu entwickeln, wie Conditional Access Policies funktionieren.

Wie funktionieren Conditional Access Policies?

Conditional Access Policies sind ein Feature von Microsoft Entra ID (bis vor kurzem auch als Azure Active Directory (AD) bekannt). Um sie nutzen zu können, benötigen die Benutzer mindestens eine Microsoft-Entra-ID-P1-Lizenz.

Diese Richtlinien treten in Kraft, wenn sich der Browser oder eine Anwendung eines Benutzers bei einem Cloud-Dienst anmeldet. Microsoft Entra ID fungiert dabei als sogenannter IDP (Identity Provider) und interpretiert bestimmte Signale, die während des Anmeldevorgangs vom Browser oder der Authenticator App übertragen werden. Anhand dieser Signale kann Microsoft Entra ID erkennen, wer sich von wo aus mit welchem Gerät bei welcher Anwendung anmelden möchte, und entscheiden, welche Anmeldekriterien und Richtlinien angewendet werden sollen.

Mit Conditional Access Policies kann nicht nur festgelegt werden, dass Benutzer Multi-Faktor-Authentifizierung (MFA) verwenden oder nur unternehmensverwaltete Geräte nutzen müssen, sondern auch komplexere Szenarien können abgedeckt werden. Zum Beispiel kann der Missbrauch kompromittierter Konten erschwert werden, indem alle Anmeldungen aus unerwünschten Ländern blockiert werden. Der genaue Vorgang ist hier dokumentiert; die nachfolgenden Abschnitte fassen das Wichtigste zusammen.

Welche Signale werden bei der Anwendung von Conditional Access Policies ausgewertet?

Microsoft kann unter anderem folgende Signale von der Anmeldung entgegennehmen und verwenden, um zu entscheiden, welche Policy angewendet werden soll:

• Benutzernamen oder Gruppenmitgliedschaft können evaluiert werden, um bestimmte Policies nur bestimmten Anwendern zuzuweisen, zum Beispiel eine strengere MFA-Methode bei Mitarbeitenden der Geschäftsleitung.
• Informationen zur IP-Adresse können bei der Anmeldung genutzt werden, um bestimmte Regionen und Länder komplett vom Zugang zum eigenen Mandanten abzugrenzen. Dieses sogenannte Geofencing ist eine sehr effektive Methode, um die Grundbedrohung von Angriffen auf Identitäten zu reduzieren, die sehr oft aus bestimmten Regionen oder Ländern erfolgen.
• Informationen über das Gerät geben Ausschluss darüber, ob eine Anmeldung von einem durch das Unternehmen verwalteten oder einem privaten Gerät kommt. Damit können Sie den Zugriff auf Daten von fremden Geräten effektiv einschränken.
• Es ist ebenfalls möglich, anhand der Applikation stärkere Sicherheitsmassnahmen anzufordern (wenn man zum Beispiel bestimmte SharePoint-Seiten gegen Datenverlust schützen möchte und den Zugang nur mit Unternehmensgeräten erlaubt).

Auswertung und Anwendung der vorhandenen Conditional Access Policies

Auf Grundlage der oben genannten Signale bewertet Microsoft Entra ID, welche (eine oder mehrere) Richtlinie(n) für den Benutzer und das Gerät anzuwenden ist bzw. sind.

Wenn mehrere Richtlinien vorhanden sind, werden immer alle Zugriffskontrollen aus allen anwendbaren Richtlinien angewendet. Wenn eine der Zugriffskontrollen nicht erfüllt werden kann oder eine Richtlinie angewendet wird, bei der ein Zugriff blockiert werden muss, kann sich der Benutzer nicht anmelden.

Welche Zugriffskontrollen können angewendet werden?

Microsoft unterscheidet verschiedene Zugriffskontrollen, die erzwungen werden können, damit sich ein Benutzer anmelden darf. Zugriffskontrollen sind wie Mindestanforderungen, die erfüllt sein müssen, damit ein Benutzer auf die gewünschten Ressourcen zugreifen kann. So ist es zum Beispiel möglich, für den Outlook-Zugriff von extern nur eine Multi-Faktor-Authentifizierung zu verlangen, den Zugriff auf eine interne SharePoint-Seite aber nur dann zu erlauben, wenn der Zugriff darüber hinaus von einem durch das Unternehmen verwalteten Gerät erfolgt.

Gängige Zugriffskontrollen sind:

• MFA (Multi-Faktor-Authentifizierung) fordert von dem Benutzer einen zusätzlichen Faktor bei der Anmeldung an, sei es über den Microsoft Authenticator oder andere zugelassene Faktoren wie FIDO2, SMS oder E-Mail.
• Ein Compliant Device oder Microsoft Entra Hybrid Joined Device stellt sicher, dass das Endgerät des Benutzers entweder gewissen Mindestanforderungen entspricht oder vom Unternehmen selbst verwaltet wird.
• Das Verwenden von veralteten Anmeldeprotokollen, die keine MFA unterstützen, kann mit einer Block-Richtlinie auf Legacy Authentication unterbunden werden.

Weitere Zugriffskontrollen bieten die Option, die Dauer der Gültigkeit einer Anmeldung festzulegen oder für Administratoren eine gegen Phishing resistente MFA-Methode zu verlangen. Mit einer «Microsoft Entra ID P2″-Lizenz besteht zusätzlich Zugriff auf Risikobewertungen und die Möglichkeit, bei einem Benutzer mit einem erhöhten Anmelderisiko beispielsweise einen Passwortwechsel zu erzwingen.

Stolpersteine bei der Implementierung von Conditional Access Policies

Bei der erstmaligen Implementierung von Conditional Access Policies gibt es einige wesentliche Aspekte zu beachten. Im Folgenden werden die wichtigsten Faktoren erläutert.

Interne Kommunikation

Bereits vor der geplanten Umsetzung der Conditional Access Policies sollte definiert werden, wie und wann die Mitarbeitenden über die Veränderungen informiert werden. Auch wenn die Richtlinien im sogenannten Report–only Mode erfasst werden, können diese bereits Interaktionen mit dem Endgerät auslösen, zum Beispiel «Compliant Device»-Prüfungen. Unerwartete Veränderungen oder fehlgeschlagene Login-Versuche können zu einem vermehrten Aufkommen von Support-Anfragen führen und den Helpdesk überlasten. Um dies zu vermeiden, sollte eine klare Strategie für die Kommunikation der Umstellungen entwickelt werden.

Notfall- und Dienstkonten

Eine der grösseren Gefahren bei der Umsetzung einer strikten Zugriffsstrategie ist, dass man sich selbst aussperrt oder kritische Dienste nicht mehr funktionieren, weil diese kein MFA unterstützen.

Microsoft empfiehlt die Einrichtung von mindestens zwei Notfallkonten («Break Glass Accounts»), die von allen Richtlinien ausgenommen sind. Dies kann auch nützlich sein, wenn der Cloud-Dienst von Microsoft, der die MFA-Funktion bereitstellt, nicht mehr funktioniert, wie es vor einigen Jahren der Fall war. Für Notfallkonten sollten lange und komplexe Passwörter festgelegt werden, deren Speicherung und Zugriff geregelt ist. Zusätzlich sollte eine Alarmierungsregel eingerichtet werden, sodass eine Benachrichtigung erfolgt, sobald ein Notfallkonto verwendet wird.

Dienstkonten sind ebenfalls nicht in der Lage, MFA oder andere Zugriffskontrollen zu erfüllen, weil sich diese nicht interaktiv anmelden. Als Beispiel hierfür kann, insbesondere in hybriden Szenarien, der Microsoft-Dienst für die Verzeichnissynchronisierung zwischen dem lokalen AD und der Entra ID angeführt werden.

Bei der Planung und Analyse des Anmeldeverhaltens einzelner Konten kann ein Simulationstool («What If»-Tool) unterstützen. Dieses ist in der Entra-ID-Administrationsoberfläche eingebunden (mehr dazu ist unter Troubleshooting Conditional Access using the What If tool zu finden). Darüber hinaus kann das Anmeldeprotokoll von Benutzer- und Servicekonten zur Identifizierung der angewandten Richtlinien verwendet werden. Dort werden alle Anmeldefaktoren und Richtlinien für 30 Tage gespeichert.

Microsoft stellt auf seiner Website unter Manage emergency access accounts in Microsoft Entra ID weitere Informationen dazu zur Verfügung.

Grundlegende Vorlagen für Conditional Access Policies

Microsoft selbst empfiehlt, bei der ersten Implementierung von Conditional Access Policies die Richtlinien aus der «Secure Foundation»-Vorlagenkategorie umzusetzen. Diese Vorlagen können bequem direkt aus der Entra-ID-Administrationsoberfläche importiert werden und dienen als Basishärtung (weitere Informationen unter Conditional Access templates).

Die Vorlagen beinhalten eine Reihe von vordefinierten Richtlinien für unterschiedliche Szenarien, darunter auch folgende Richtlinien:

• Securing security info registration dient als Richtlinie um zu kontrollieren, unter welchen Bedingungen Benutzer MFA einrichten dürfen. Administratoren können damit den MFA-Registrierungsprozess an sich absichern.
• Require multifactor authentication for all users schreibt allen Benutzern MFA vor.
• Require multifactor authentication for admins steuert das MFA-Abfrageverhalten anhand der administrativen Entra-Rollen, die einem Benutzer zugewiesen sind. Ist das Konto beispielsweise ein Benutzeradministrator, ist ein zweiter Faktor erforderlich.
• Require multifactor authentication for Azure management ist eine ähnliche Policy wie oben, kann aber dazu genutzt werden, zusätzliche Anforderungen (zum Beispiel gegen Phishing resistente Anmeldefaktoren) zu stellen, wenn Einstellungen am Kern des Mandanten vorgenommen werden müssen.
• Require compliant or Microsoft Entra hybrid joined device or multifactor authentication for all users bietet die Möglichkeit, auf MFA zu verzichten, solange die Benutzer ein Gerät benutzen, das vom Unternehmen verwaltet wird oder den Unternehmensanforderungen entspricht. Durch das Unternehmen verwaltete Geräte bieten zusätzlich den Vorteil, dass durch weitere Richtlinien das sogenannte Session Token an das verwaltete Gerät gebunden werden kann und somit ein zusätzlicher Schutz gegen bestimmte Angriffe wie beispielsweise Token-Diebstahl gegeben ist.
• Block legacy authentication ist wichtig, damit veraltete Anmeldeprotokolle unterbunden werden, die technisch keinen zweiten Faktor unterstützen.
• Block access by location ist gerade für die Unternehmen interessant, die zwar Cloud-Dienste nutzen wollen, aber in einem geographisch klar definierten Gebiet tätig sind und so schon mal einen Grossteil von illegitimen Anmeldeversuchen aus der ganzen Welt abblocken können.

Nachdem mit diesen Richtlinien sichere Grundlagen geschaffen sind, sollten möglichst viele Richtlinien aus den Vorlagenkategorien Zero Trust, Remote work, Protect administrator und Emerging threats übernommen werden.

Konzeptionelle Überlegungen zu einer langfristigen Strategie

Es gibt viele Richtlinien und unterschiedliche Möglichkeiten, wie man Conditional Access Policies umsetzen kann. Sobald jedoch eine gewisse Komplexität erreicht ist, empfiehlt es sich, über konzeptionelle Aspekte nachzudenken.

Eine erste Überlegung besteht darin, welche Benutzer mit welchem Workload und welchen Geräten von der Realisierung betroffen sein werden. Eventuell müssen gewisse Anwendungsfälle klar getrennt werden, während andere zusammengefasst werden können.

Microsoft bietet mit dem Persona-Konzept einen Ansatz, bei dem Benutzer in Anforderungsgruppen eingeteilt werden können, wie zum Beispiel «Intern», «Extern» oder «Gäste». Unter Conditional Access architecture and personas kann man mehr darüber erfahren. Zudem sind dort zusätzliche Hilfsmittel beschrieben, die bei der Erarbeitung von Konzepten hilfreich sein können.

Eine letzte Empfehlung ist die Einführung eines Namenskonzepts für die Richtlinien. Dadurch werden die Richtlinien konsistent benannt, wodurch potenzielle Lücken bei der Abdeckung aufgrund übermässiger Komplexität verhindert werden können.

Microsoft empfiehlt eine Benennung der Richtlinien (basierend auf dem Artikel Conditional Access framework and policies) gemäss folgendem Schema:

CANumber – Persona – PolicyType – App – Platform – GrantControl – OptionalDescription

Damit sind die elementaren Informationen zum Zweck einer Richtlinie bereits im Namen ersichtlich, wodurch die tägliche Arbeit mit den Richtlinien erleichtert wird.

Im Internet sind zudem ausgearbeitete Baukastenmodelle verfügbar, welche zwar auf den ersten Blick überwältigend wirken können, aber durchaus durchdacht sind, wie die Modelle von Kenneth van Surksum und Robert Brandso auf GitHub sowie das Konzept von Daniel Chronlund.

Fazit

Die sichere und nachhaltige Implementierung von Conditional Access Policies kann ein aufwendiges Unterfangen darstellen, das häufig unterschätzt wird. Es ist entscheidend, die Funktionsweise der Richtlinien gründlich zu verstehen, bevor mit der Implementierung begonnen wird. Dies bildet eine solide Grundlage für die konzeptionelle Arbeit. Die Richtlinien müssen sorgfältig an die Anforderungen verschiedener Nutzergruppen innerhalb des Unternehmens angepasst werden, um gleichzeitig eine umfassende Abdeckung sicherzustellen und potenzielle Lücken zu vermeiden.

Falls Sie zusätzliche Unterstützung oder Beratung benötigen oder wenn Sie Ihre Implementierung von einem erfahrenen Penetration Tester überprüfen lassen möchten, stehen wir Ihnen gerne zur Verfügung.