Conditional Access Policies: Welche Richtlinien Unternehmen verwenden sollten und häufige Missverständnisse

Empfohlene Richtlinien für einen soliden Grundschutz

Dieses Kapitel stellt Richtlinien vor, die einen soliden Grundschutz für Ihren Microsoft-Mandanten gewährleisten.

Ausnahmen für Notfallaccounts

Für den Fall, dass alle Stricke reißen und der Zugriff auf den Mandanten verloren geht, sollten zwei Notfallaccounts angelegt werden, die mit "Global Administrator"-Berechtigungen ausgestattet sind. Damit diese Accounts im Ernstfall ihren Zweck erfüllen können, müssen sie zwingend von allen regulären CAPs ausgenommen sein. Um die Übersicht zu behalten, sollten für Notfallaccounts dedizierte CAPs angelegt werden. Ansonsten verhindert im schlimmsten Fall eine CAP auch die Anmeldung mit den Notfallaccounts.

Daraus ergibt sich die erste Empfehlung.

Empfehlung 1: Bei allen regulären CAPs Ausnahmen für Notfallaccounts anlegen.

Achtung: Durch die CAP-Ausnahmen sind Notfallaccounts schlechter vor Angriffen geschützt. Es ist daher essenziell, diese Accounts ausschließlich im Notfall zu nutzen und mit einem langen und komplexen Passwort zu schützen! Zudem wird empfohlen, die Accounts mit einem zweiten Authentisierungsfaktor zu sichern. Microsoft empfiehlt passwortlose Methoden. Wichtig ist, für Notfallaccounts eine andere Methode zu verwenden als für gewöhnliche Administratorkonten.

Multi-Faktor-Authentifizierung

Selbst Sicherheitsexperten können auf gut durchgeführte Phishing-Angriffe hereinfallen, wie ein Vorfall bei Troy Hunt, dem Betreiber der Datenleck-Datenbankseite Have I Been Pwned, im vergangenen Jahr zeigte.

Daher ist es unerlässlich, Phishing-Angriffe zu erschweren, indem die Multi-Faktor-Authentifizierung (MFA) für alle Benutzer erzwungen wird. Microsoft hat die MFA zwar seit Ende 2025 verpflichtend für alle Benutzer eingeführt, dies umfasst jedoch nur Anmeldungen an ausgewählten Anwendungen. Daher bedarf es einer spezifischen CAP, um MFA für alle User zu erzwingen, wie in folgender Abbildung gezeigt ist.

Empfehlung 2: MFA für alle Benutzer erzwingen.

Auch gängige MFA-Methoden wie die "Microsoft Authenticator"-App, SMS oder E-Mail-One-Time Password konnten Angreifer in der Vergangenheit durch Lauschangriffe oder Social Engineering überwinden. Microsoft hat daher eine Kategorie für Phishing-resistente MFA-Methoden geschaffen. Wie der Name suggeriert, sind diese kaum durch Phishing-Angriffe überwindbar. Mindestens hochprivilegierte Benutzer sollten durch diese stärkeren MFA-Methoden geschützt werden.

Empfehlung 3: Phishing-resistente MFA für alle Administratoren erzwingen.

Damit sind jedoch noch nicht alle Zugriffsszenarien abgedeckt. Bei der Auswahl der Zielressourcen verstecken sich unter "Benutzeraktionen" zwei weitere Zugriffsszenarien:

• Geräte registrieren oder verbinden
• Sicherheitsinformationen registrieren

Um auch für diese Zugriffe MFA zu fordern, müssen also separate Richtlinien angelegt werden. Warum dies sinnvoll ist, sollen die folgenden Angriffsszenarien veranschaulichen:

• Szenario 1: Ein Angreifer erbeutet das Passwort eines Benutzers. Ohne den zweiten Faktor kann er nicht auf die Microsoft-Cloud zugreifen. Allerdings hat das Unternehmen des Benutzers eine Ausnahmeregel definiert, die MFA nicht abfragt, wenn die Anmeldung von einem konformen ("compliant") Gerät erfolgt. Der Angreifer kann nun, ohne einen zweiten Faktor zu benötigen, ein fiktives Gerät in Entra ID registrieren. Auch das Gerät in Intune einzubinden, ist für Angreifer mit dem Python-Tool Pytune von Yuya Chudo kein Problem. Angreifer hätten somit vollen Zugriff auf die Microsoft-Cloud.

• Szenario 2: Ein Dienstleister soll für ein Projekt Cloud-Zugriff erhalten. Das Passwort für sein neues Benutzerkonto wird ihm per E-Mail zugesendet. Das Projekt wird kurzfristig storniert, sodass der Dienstleister das Benutzerkonto doch nicht benötigt. Idealerweise würde das Benutzerkonto dann von der IT-Abteilung des Unternehmens deaktiviert werden. Häufig wird das aber vergessen. Ein Angreifer, der nun in den Besitz des Initialpassworts gelangt – etwa durch die Kompromittierung des E-Mail-Postfachs des Dienstleisters –, kann das Konto nutzen und einen eigenen Zweitfaktor registrieren.

Empfehlung 4: MFA für das Registrieren von Geräten und Sicherheitsinformationen fordern.

Um Benutzern initial Zugriff zu ermöglichen, kann vorab durch die Administration eine MFA-Methode hinterlegt werden. Alternativ können Temporary Access Passes genutzt werden. Diese sind nur begrenzt gültig und stellen eine zweite Schutzschicht zum Initialpasswort dar.

Risikobehaftete Benutzer

Im Kontext von CAPs spielen die Risikoeinstufungen durch Microsoft "Benutzerrisiko", "Anmelderisiko" und "Insiderrisiko" eine zentrale Rolle bei der Absicherung von Identitäten und Zugriffen:

• "Benutzerrisiko" bewertet, ob ein Benutzerkonto kompromittiert sein könnte.
• "Anmelderisiko" analysiert jede einzelne Anmeldung in Echtzeit auf verdächtige Merkmale.
• "Insiderrisiko" fokussiert sich auf das potenzielle Risiko durch legitime Benutzer, die absichtlich oder unabsichtlich sensible Daten gefährden könnten. 

Während die Risikoeinstufungen bei allen Lizenzstufen verfügbar sind, können besonders feingranulare Einstellungen nur mit einer P2-Lizenz vorgenommen werden. CAPs sollten für diese Risikoszenarien definiert werden, um auf erkannte Risiken reagieren zu können. 

Hierbei ist jedoch Vorsicht geboten: Durch gesperrte Benutzer kann der Arbeitsbetrieb erheblich gestört werden. Mindestens bei einem hohen Benutzerrisiko sollten manuelle Risikobehebungsmaßnahmen notwendig sein.

Empfehlung 5: Benutzer mit hoher Risikoeinstufung sollten zur Behebung manuelle Maßnahmen durch einen Administrator erfordern.

Jedoch sind weitere Maßnahmen, wie beispielsweise eine erzwungene Passwortrotation bei einem erkannten mittleren Risiko, sinnvoll.

Device Code Flow

Der Device Code Flow erlaubt es, den Loginprozess auf einem anderen Gerät als jenem durchzuführen, das authentisiert wird. Was als Feature für Geräte mit begrenzten Eingabemöglichkeiten gedacht war, ist gleichzeitig besonders anfällig für Phishing-Angriffe, wie die folgende Grafik zeigt.

Es ist daher empfehlenswert, Device Code Flow zu deaktivieren und nur dort Ausnahmen hinzuzufügen, wo sie unbedingt notwendig sind.

Empfehlung 6: Device Code Flow so weitgehend wie möglich unterbinden.

Fallstricke

Dieses Kapitel geht auf zwei Eigenschaften von CAPs ein, die häufig falsch eingeschätzt werden.

Geräte- und Plattformfilter

Über geräte- und plattformbasierte Richtlinien kann feingranular eingestellt werden, welche Bedingungen das Gerät, von dem die Authentisierungsanfrage aus durchgeführt wird, erfüllen muss oder was es nicht darf. Beispielsweise ist es möglich, Loginversuche von iOS- und Android-Geräten zu unterbinden.

Oder es werden nur Loginanfragen von Geräten akzeptiert, die in Intune als "compliant" markiert sind.

Allerdings sind diese Richtlinien nur bedingt geeignet, um Angreifer einzuschränken oder gar fernzuhalten, wie Microsoft selbst einräumt: "Registrierungseinschränkungen stellen keine Sicherheitsfunktionen dar. Gefährdete Geräte können falsche Angaben zu ihren Eigenschaften enthalten. Diese Einschränkungen sind eine bestmögliche Barriere für nicht böswillige Benutzer."

Grund hierfür ist, dass die Filterkriterien auf Informationen basieren, die vom Gerät selbst gesendet werden. Somit können diese grundsätzlich gefälscht werden. Die Geräteplattform beispielsweise wird bei unregistrierten Geräten allein über den User Agent bestimmt – eine Zeichenfolge, die bei jeder Anfrage an den Server mitgeschickt wird.

Im folgenden Beispiel führen wir einen Loginversuch von einem Kali-Linux-System aus und weisen roadtx an, den für iPhones typischen User Agent zu nutzen.

In den Sign-in-Logs erscheint der Loginversuch so, als hätten wir den Safari-Browser auf einem iPhone genutzt.

Aber auch beim Registrierungsvorgang von Geräten kann die genutzte Plattform gefälscht werden. Mithilfe des Tools Pytune können wir fiktive Geräte in Entra ID registrieren und in Intune einbinden. Die einzige Voraussetzung ist, dass das Limit für die Anzahl der registrierten Geräte für diesen Nutzer nicht überschritten wird. Hier empfiehlt Microsoft jedoch einen sehr großzügigen Standardwert von 20 Geräten pro Nutzer.

Die Filtermöglichkeiten für Geräte sind also primär dafür geeignet, um technisch unversierte Mitarbeiter davon abzuhalten, eigene potenziell mit Schadsoftware befallene Geräte für den Zugriff auf die Microsoft-Cloud zu verwenden.

Fallstrick 1: Plattformfilter sind einfach auszuhebeln und sollten daher nicht als Sicherheitsmechanismus genutzt werden.

Dennoch kann nach Erfahrung der SySS eine Regel, die als zusätzliche Schutzschicht konforme Geräte für den Zugriff auf interne Ressourcen fordert, Angreifern das Leben erheblich erschweren. Um eine solche Regel nicht abzuschwächen, sollten weitere plattformbasierte Anforderungen in separaten Regeln definiert werden.

Wichtig ist dabei, dass neu in Intune eingebundene Geräte standardmäßig nicht als konform markiert werden.

Ergänzend ist es sinnvoll, die Anzahl der Geräte pro Benutzer auf die tatsächlich benötigte Zahl zu reduzieren. Ist Intune nicht im Einsatz, kann zudem in den Geräteeinstellungen die Registrierung von Geräten für Benutzer deaktiviert werden.

Rollenbasierte Richtlinien und PIM

Das Privileged Identity Management (PIM) von Entra ID ermöglicht die temporäre Aktivierung von Rollen, wenn sie benötigt werden. Ein Benutzer, der beispielsweise für die "User Administrator"-Rolle berechtigt ist, kann diese ad hoc aktivieren, um Benutzer und Gruppen zu verwalten. PIM ermöglicht so eine bessere Kontrolle über die Vergabe von Berechtigungen und eine bessere Nachvollziehbarkeit von administrativen Tätigkeiten. Um PIM nutzen zu können, werden P2-Lizenzen benötigt.

Grundsätzlich ist der Einsatz von PIM empfehlenswert. In Kombination mit CAPs kann es jedoch zu unerwünschten Nebeneffekten kommen, sodass manche Richtlinien nicht greifen. Denn CAPs berücksichtigen nur die Rollen, die ein Benutzer innehat, jedoch nicht, für welche er berechtigt ist. 

In unserem Beispiel ist der Benutzer "syss" berechtigt, die Rolle "User Administrator" zeitweise einzunehmen. Eine CAP ist aktiv, die MFA bei der Anmeldung aller Administratoren verlangt. Solange der Benutzer die Rolle jedoch nicht aktiviert hat, kann er oder ein potenzieller Angreifer sich allein mit dem Passwort anmelden. 

Mit den Standardberechtigungen des Benutzers können keine neuen Benutzer angelegt werden.

Wenn nun der Benutzer via PIM die Rolle "User Administrator" aktiviert, greift die rollenbasierte CAP.

Ein Angreifer kann sich somit nicht mehr allein mit dem Passwort anmelden, da er nun auch einen weiteren Authentisierungsfaktor benötigt. Auch die Ausstellung eines neuen Zugangstokens mithilfe von Refresh-Token ist nicht möglich, da auch hierfür eine MFA erforderlich wäre.

Allerdings bleibt das zuvor ausgestellte Zugangstoken weiterhin bis zu seinem Ablaufdatum gültig. Da das Token keine Rolleninformationen enthält, können mit dem zuvor ausgestellten Token nun auch die erweiterten Berechtigungen des "User Administrator" genutzt werden. Beispielsweise ist es nun möglich, einen neuen Benutzer (hier "Persist Hacker") anzulegen, um sich im Mandanten zu persistieren.

Ein Blick in die Benutzerübersicht zeigt, dass der neue Benutzer tatsächlich angelegt wurde.