Conditional Access: Identity ist das neue Security-Perimeter

Unternehmensanwendungen und Daten befinden sich längst nicht mehr ausschließlich innerhalb eines klar abgegrenzten Firmennetzwerks. Mitarbeiter*innen greifen aus unterschiedlichen Netzwerken, mit verschiedenen Geräten und über Cloud-Dienste auf Ressourcen zu. Conditional Access in Microsoft Entra ID setzt deshalb nicht allein auf die klassische Netzwerkgrenze. Stattdessen werden Identität, Gerät und weitere Signale in die Entscheidung einbezogen, ob und unter welchen Bedingungen ein Zugriff erlaubt wird.

Microsoft bezeichnet Conditional Access als Policy Engine seiner Zero-Trust-Architektur. Für Administrator*innen bedeutet das: Zugriffe können wesentlich differenzierter gesteuert werden als mit einer einfachen Entscheidung zwischen „innerhalb“ und „außerhalb“ des Unternehmensnetzwerks.

Warum wird Identity zum neuen Security-Perimeter?

Traditionelle Sicherheitsmodelle gingen häufig davon aus, dass sich vertrauenswürdige Benutzer*innen und Geräte innerhalb eines geschützten Unternehmensnetzwerks befinden. Cloud-Dienste, mobiles Arbeiten und hybride IT-Umgebungen haben diese klare Grenze zunehmend aufgelöst. Der Netzwerkstandort allein reicht daher nicht aus, um die Vertrauenswürdigkeit eines Zugriffs zu beurteilen. Bei einem identitätsorientierten Ansatz rückt stattdessen die Frage in den Mittelpunkt: Wer möchte unter welchen Bedingungen auf welche Ressource zugreifen? Neben der Identität können beispielsweise Gerätestatus, Netzwerk, Anwendung oder ein erkanntes Anmelderisiko berücksichtigt werden.

Damit unterstützt Conditional Access zentrale Zero-Trust-Prinzipien: Zugriffe werden explizit geprüft, Berechtigungen sollen möglichst restriktiv vergeben werden und Sicherheitskonzepte gehen grundsätzlich davon aus, dass eine Kompromittierung möglich ist. Conditional Access ist damit eine wichtige Kontrollschicht innerhalb einer Zero-Trust-Strategie. Eine vollständige Zero-Trust-Architektur ersetzt die Funktion jedoch nicht.

Wie funktioniert Conditional Access?

Das Grundprinzip von Conditional Access lässt sich als Wenn-Dann-Logik verstehen. Wenn eine definierte Situation eintritt, muss eine festgelegte Zugriffskontrolle erfüllt werden. Ein einfaches Beispiel lautet: Wenn Benutzer*innen auf eine bestimmte Cloud-Anwendung zugreifen, müssen sie eine Multi-Faktor-Authentifizierung (MFA) durchführen. Eine Policy kombiniert dafür sogenannte Assignments mit Access Controls. Administrator*innen legen fest, für welche Benutzer*innen oder Gruppen und für welche Ressourcen eine Richtlinie gilt. Zusätzlich können Bedingungen und Signale berücksichtigt werden. Zu den möglichen Kontrollen gehören beispielsweise MFA, eine bestimmte Authentication Strength oder die Anforderung eines als konform eingestuften Geräts.

Wichtig ist dabei das Zusammenspiel mehrerer Policies. Für eine Anmeldung können gleichzeitig mehrere Conditional-Access-Richtlinien relevant sein. Verlangt eine Policy MFA und eine weitere ein konformes Gerät, müssen die jeweils anwendbaren Anforderungen erfüllt werden. Deshalb sollte Conditional Access nicht als Sammlung voneinander isolierter Regeln betrachtet werden, sondern als zusammenhängendes Policy-Design.

Typische Conditional-Access-Policies in der Praxis

Ein verbreitetes Basisszenario ist die Anforderung von MFA für Benutzer*innen. Statt ausschließlich Benutzername und Passwort zu akzeptieren, verlangt die Policy einen zusätzlichen Authentifizierungsfaktor. Dabei müssen Ausnahmen und Abhängigkeiten bewusst geplant werden, bevor eine solche Regel breit ausgerollt wird. Privilegierte Konten benötigen besonderen Schutz. Administrator*innen besitzen weitreichende Rechte und sind entsprechend attraktive Ziele für Angriffe. Für administrative Rollen kann deshalb eine stärkere Authentifizierung verlangt werden. Conditional Access lässt sich so einsetzen, dass für diese Konten beispielsweise eine phishingresistente Authentication Strength erforderlich ist.

Ein weiteres typisches Szenario verbindet Identity Security mit dem Gerätestatus. Eine Policy kann den Zugriff auf ausgewählte Unternehmensressourcen davon abhängig machen, dass ein Gerät als compliant, also konform mit den definierten Compliance-Vorgaben, eingestuft wurde. Das ist besonders bei sensiblen Anwendungen relevant. Die Anforderung „Require compliant device“ sollte allerdings nicht pauschal aktiviert werden: Gerätemanagement, Benutzergruppen, Ausnahmen und technische Abhängigkeiten müssen zum jeweiligen Anwendungsszenario passen.

Auch Risiken können in Zugriffsentscheidungen einbezogen werden. Risk-based Conditional Access ermöglicht es, auf erkannte Benutzer- oder Anmelderisiken zu reagieren. Je nach Konfiguration kann ein erhöhtes Risiko zusätzliche Kontrollen auslösen oder dazu führen, dass ein Zugriff blockiert wird. Die Nutzung von Microsoft Entra ID Protection-Risikosignalen in Conditional Access setzt die entsprechenden Lizenzvoraussetzungen voraus. Nicht jeder Zugriff muss identisch behandelt werden. Die Anforderungen können sich danach richten, welche Identität auf welche Ressource zugreift und welche Signale dabei vorliegen.

Authentication Strengths: MFA ist nicht gleich MFA

Die Aussage „MFA ist aktiviert“ beschreibt noch nicht, welche Authentifizierungsmethoden tatsächlich zugelassen sind. Microsoft Entra unterscheidet bei den integrierten Authentication Strengths zwischen Multifactor authentication strength, Passwordless MFA strength und Phishing-resistant MFA strength.

Mit Authentication Strengths lässt sich in einer Conditional-Access-Policy festlegen, welche Kombinationen von Authentifizierungsmethoden für den Zugriff auf eine Ressource akzeptiert werden. Dadurch können Organisationen für besonders sensible Ressourcen stärkere Anforderungen definieren als für weniger kritische Anwendungen. Zur integrierten phishingresistenten MFA-Stärke zählen unter anderem Passkeys auf Basis von FIDO2, Windows Hello for Business beziehungsweise Platform Credentials und die mehrstufige zertifikatbasierte Authentifizierung.

Vor der Durchsetzung muss allerdings sichergestellt werden, dass die betroffenen Benutzer*innen eine zulässige Methode verwenden können und diese korrekt eingerichtet wurde. Eine technisch strenge Policy hilft wenig, wenn legitime Benutzer*innen die geforderte Authentifizierung nicht durchführen können. Authentication Strengths sollten deshalb gemeinsam mit der unternehmensweiten Strategie für Authentifizierungsmethoden geplant werden.

Conditional Access kontrolliert einführen und betreiben

Eine der wichtigsten Regeln beim Aufbau von Conditional Access lautet: Neue Policies sollten nicht ohne vorherige Prüfung tenantweit aktiviert werden. Microsoft empfiehlt, die Bereitstellung zu planen, Auswirkungen zu testen und Änderungen gegenüber den betroffenen Benutzer*innen zu kommunizieren. Dafür steht unter anderem der Report-only-Modus zur Verfügung. Eine Policy kann ausgewertet werden, ohne ihre Zugriffskontrollen tatsächlich durchzusetzen. Administrator*innen erhalten dadurch Informationen darüber, welche Anmeldungen von einer Richtlinie betroffen wären. Ergänzend ermöglicht das What-If-Tool, konkrete Anmeldeszenarien zu simulieren und zu prüfen, welche Policies unter den gewählten Bedingungen greifen.

Besondere Aufmerksamkeit benötigen Emergency-Access-Konten, häufig auch als Break-Glass-Accounts bezeichnet. Diese Konten sollen den administrativen Zugriff ermöglichen, wenn reguläre Verfahren oder Abhängigkeiten nicht verfügbar sind. Microsoft empfiehlt, solche Konten von Conditional-Access-Policies auszunehmen, die eine Anmeldung blockieren oder einschränken könnten, und ihre Funktionsfähigkeit regelmässig zu überprüfen.

Für die Praxis ergibt sich daraus ein kontrollierter Ablauf: Policies zunächst fachlich planen, mit ausgewählten Testbenutzer*innen prüfen, im Report-only-Modus beobachten, mit geeigneten Werkzeugen validieren und erst danach schrittweise aktivieren. Ebenso wichtig ist die laufende Pflege. Neue Anwendungen, Authentifizierungsmethoden, Gerätekonzepte und organisatorische Änderungen können bestehende Regeln beeinflussen.

Conditional Access macht damit deutlich, was „Identity als neues Perimeter“ praktisch bedeutet: Vertrauen entsteht nicht allein dadurch, dass sich ein Zugriff innerhalb einer bestimmten Netzwerkgrenze befindet. Entscheidend ist der Kontext einer Anmeldung. Genau diese kontextbezogene Prüfung macht Conditional Access zu einem zentralen Baustein für Identity Security und Zero Trust.