Konfigurieren Sie im Microsoft Entra ID eine Richtlinie für bedingten Zugriff, werden Sie früher oder später über zwei Begriffe stoßen, die offensichtlich in einem ähnlichen Anwendungsbereich angesiedelt sind, nämlich Authentifizierungsstärken und Authentifizierungskontexte.
Hier bei handelt es sich um zwei zwar unterschiedliche, aber miteinander kombinierbare Konzepte im Bereich des bedingten Zugriffs.
Authentifizierungsstärke
Mit einer Authentifizierungsstärke legen Sie explizit fest, welche Kombinationen von Authentifizierungsmethoden (z. B. Passwort, FIDO2, Authenticator-App) für den Zugriff auf eine Ressource erlaubt oder erforderlich sind. Das Ziel ist sicherzustellen, dass Benutzer sich mit einer ausreichend sicheren Methode anmelden wie z. B. Phishing-resistent. Machen Sie nämlich in einer CA-Richtlinie „nur“ MFA erforderlich, ist quasi jede registrierte MFA-Methode erlaubt, auch die unsichereren wie SMS oder Voice-Mail.
Hier zwei Beispiele:
- Phishing-resistente MFA-Stärke
- Nur FIDO2-Sicherheitsschlüssel oder Windows Hello for Business sind erlaubt.
- Einsatz: Zugriff auf hochsensible Daten wie Finanzsysteme.
- Kennwortlose MFA-Stärke
- Nur Authenticator-App mit Push-Bestätigung oder biometrische Anmeldung.
- Einsatz: Zugriff auf interne HR-Systeme.
bei 2. ist übrigens noch zu unterscheiden zwischen ..
- Multi-Factor Authentication (MFA), also z. B. Passwort + Push mit Zahl.
- Passwordless Authentication: z. B. Authenticator-App mit biometrischer Bestätigung ohne Passwort.
Wenn Sie also in ihrer CA-Richtlinie „Nur Authenticator-App mit Push-Bestätigung“ verlangen, könnten beide Methoden zulässig sein, je nach Kontext – aber:
- Wenn Sie Passwordless explizit voraussetzen, ist nur die zweite Methode gültig.
- Verlangen Sie hingegen nur MFA mit Push, ist die erste Methode ausreichend.
Technisch wird die Funktion mit Hilfe einer Authentifizierungsmethodenrichtlinie definiert und in einer bedingten Zugriffsrichtlinie mit dem Steuerelement „Erfordern der Authentifizierungsstärke“ verwendet
Authentifizierungskontext
Ein Authentifizierungskontext ist ein Art benutzerdefinierter Sicherheitsmarker, der in einer bedingten Zugriffsrichtlinie verwendet werden kann, um „zusätzliche Anforderungen“ an ganz bestimmte Aktionen oder Ressourcen zu stellen. Das Ziel ist eine möglichst feingranulare Steuerung von Zugriffen „innerhalb“ einer Anwendung oder eines Workflows – z. B. bei sicherheitsrelevanten Aktionen.
Hier wieder zwei Beispiele:
- Hohe Sicherheit erforderlich
- Wird in einer App wie SharePoint verwendet, um z. B. den Zugriff auf vertrauliche Dokumente zu schützen.
- Nur Benutzer mit MFA und aus vertrauenswürdigem Netzwerk dürfen zugreifen.
- Vertrauliche Aktion
- Wird in z. B. in „Power Apps“ oder „benutzerdefinierten Anwendungen“ verwendet, um z. B. das Zurücksetzen von Passwörtern oder Ändern von Bankdaten abzusichern.
Technisch werden Authentifizierungskontexte ebenfalls in Entra ID erstellt und können in bedingten Zugriffsrichtlinien sowie in Ressourcenanwendungen (z. B. SharePoint, Power Apps) referenziert werden. Microsoft liefert übrigens im Entra ID „Konfigurationsschritte“ für den schnellen Einstieg mit Verweisen in die Dokumentation mit:
