Backup-Authentifizierungssystem von Microsoft Entra ID

Organisationen auf der ganzen Welt verlassen sich 24 Stunden am Tag und sieben Tage die Woche auf die Hochverfügbarkeit der Microsoft Entra-Authentifizierung für Benutzer*innen und Dienste. Wir versprechen eine Verfügbarkeit mit einem Servicelevel von 99,99 % für die Authentifizierung und streben eine ständige Verbesserung an, indem wir die Resilienz unseres Authentifizierungsdiensts verbessern. Um die Ausfallsicherheit weiter zu erhöhen, haben wir 2021 ein Sicherungssystem implementiert.

Das Microsoft Entra-Sicherungsauthentifizierungssystem besteht aus mehreren Sicherungsdiensten, die zusammenarbeiten, um die Authentifizierungsresilienz bei einem Ausfall zu erhöhen. Dieses System verarbeitet die Authentifizierungen für unterstützte Anwendungen und Dienste transparent und automatisch, wenn der primäre Microsoft Entra-Dienst nicht verfügbar oder heruntergestuft ist. Zusätzlich zu den vorhandenen Redundanzebenen wird eine zusätzliche Resilienzebene hinzugefügt. Diese Resilienz wird im Blogbeitrag Verbesserte Dienstresilienz in Microsoft Entra ID durch den Sicherungsauthentifizierungsdienst beschrieben. Dieses System synchronisiert Authentifizierungsmetadaten, wenn das System fehlerfrei ist, und verwendet diese, um Benutzer*innen bei Ausfällen des primären Dienstes weiterhin den Zugriff auf Anwendungen zu ermöglichen und gleichzeitig Richtlinienkontrollen zu erzwingen.

Während eines Ausfalls des primären Diensts können Benutzer*innen weiterhin mit ihren Anwendungen arbeiten, sofern sie in den letzten drei Tagen von demselben Gerät aus darauf zugegriffen haben und keine Sperrrichtlinien bestehen, die ihren Zugriff einschränken würden:

Zusätzlich zu Microsoft-Anwendungen wird Folgendes unterstützt:

• Native E-Mail-Clients unter iOS und Android.
• Im App-Katalog verfügbare SaaS-Anwendungen (Software-as-a-Service) wie ADP, Atlassian, AWS, GoToMeeting, Kronos, Marketo, SAP, Trello, Workday und mehr.
• Ausgewählte Branchenanwendungen, basierend auf ihren Authentifizierungsmustern.

Dienst-zu-Dienst-Authentifizierung, die auf verwalteten Identitäten für Azure-Ressourcen basiert oder auf Azure-Diensten erbaut ist, erhält eine erhöhte Resilienz vom Sicherungsauthentifizierungssystem.

Microsoft erweitert kontinuierlich die Anzahl unterstützter Szenarien.

Welche Nicht-Microsoft-Workloads werden unterstützt?

Das Sicherungsauthentifizierungssystem bietet automatisch inkrementelle Resilienz für Zehntausende von unterstützten Nicht-Microsoft-Anwendungen auf der Grundlage ihrer Authentifizierungsmuster. Eine Liste der gängigsten Nicht-Microsoft-Anwendungen und deren Abdeckungsstatus finden Sie im Anhang. Eine ausführliche Erklärung, welche Authentifizierungsmuster unterstützt werden, finden Sie im Artikel Grundlegendes zur Anwendungsunterstützung für das Sicherungsauthentifizierungssystem.

• Native Anwendungen, die das Protokoll Open Authorization (OAuth) 2.0 verwenden, um auf Ressourcenanwendungen zuzugreifen, z. B. beliebte Nicht-Microsoft-E-Mail- und Chat-Clients wie Apple Mail, Aqua Mail, Gmail, Samsung Email und Spark.
• Branchenspezifische Webanwendungen, die für die Authentifizierung mit OpenID Connect konfiguriert sind und nur ID-Token verwenden.
• Webanwendungen, die sich mit dem SAML-Protokoll (Security Assertion Markup Language) authentifizieren, wenn sie für vom Identitätsanbieter initiiertes einmaliges Anmelden (SSO) konfiguriert sind, wie ADP, Atlassian Cloud, AWS, GoToMeeting, Kronos, Marketo, Palo Alto Networks, SAP Cloud Identity Trello, Workday und Zscaler.

Nicht von Microsoft stammende Anwendungstypen, die nicht geschützt sind

Folgende Authentifizierungsmuster werden derzeit nicht unterstützt:

• Webanwendungen, die sich mit OpenID Connect authentifizieren und Zugriffstoken anfordern
• Webanwendungen, die das SAML-Protokoll für die Authentifizierung verwenden, wenn sie als vom Dienstanbieter initiiertes SSO konfiguriert sind

Was macht einen Benutzer durch das Backup-Authentifizierungssystem unterstützbar?

Während eines Ausfalls können sich Benutzer*innen über das Sicherungsauthentifizierungssystem authentifizieren, wenn die folgenden Bedingungen erfüllt sind:

1. Der Benutzer/die Benutzerin hat sich in den letzten drei Tagen erfolgreich unter Verwendung derselben App und desselben Geräts authentifiziert.
2. Es ist keine interaktive Authentifizierung erforderlich.
3. Der Benutzer greift als Mitglied seines eigenen Mandanten und nicht in einem B2B- oder B2C-Szenario auf eine Ressource zu.
4. Der Benutzer/die Benutzerin unterliegt keinen Richtlinien für den bedingten Zugriff, die das Sicherungsauthentifizierungssystem einschränken, z. B. das Deaktivieren von Resilienzstandardeinstellungen.
5. Der Benutzer/die Benutzerin war seit der letzten erfolgreichen Authentifizierung nicht Gegenstand eines Sperrungsereignisses, z. B. einer Änderung der Anmeldedaten.

Wie wirken sich die interaktive Authentifizierung und Benutzeraktivitäten auf die Resilienz aus?

Das Sicherungsauthentifizierungssystem stützt sich auf die Metadaten einer früheren Authentifizierung, um Benutzer*innen während eines Ausfalls erneut zu authentifizieren. Ein Benutzer muss in den letzten drei Tagen die gleiche App auf demselben Gerät authentifiziert haben, damit der Sicherungsdienst wirksam ist. Benutzer*innen, die inaktiv sind oder sich noch nicht bei einer bestimmten App authentifiziert haben, können das Sicherungsauthentifizierungssystem für die betreffende Anwendung nicht verwenden.

Wie wirken sich Richtlinien für den bedingten Zugriff auf die Resilienz aus?

Bestimmte Richtlinien können vom Sicherungsauthentifizierungssystem nicht in Echtzeit ausgewertet werden. Das System muss sich daher auf vorherige Auswertungen dieser Richtlinien stützen. Bei Ausfällen verwendet der Dienst standardmäßig eine vorherige Auswertung, um die Resilienz zu maximieren. Beispielsweise wird der Zugriff, der auf einen Benutzer mit einer bestimmten Rolle (z. B. Anwendungsadministrator) beschränkt ist, während eines Ausfalls auf der Grundlage der Rolle fortgesetzt, die der Benutzer bei der letzten Authentifizierung hatte. Wenn die Verwendung einer vorherigen Auswertung bei Ausfällen eingeschränkt werden muss, können Mandantenadmins eine strikte Auswertung aller Richtlinien für bedingten Zugriff auch unter Ausfallbedingungen auswählen, indem sie Standardeinstellungen für die Resilienz deaktivieren. Diese Entscheidung sollte mit Bedacht getroffen werden, da durch die Deaktivierung der Resilienzstandardeinstellungen für eine bestimmte Richtlinie die betreffenden Benutzer*innen von der Verwendung der Sicherungsauthentifizierung ausgeschlossen werden. Die Standardwerte für Resilienz müssen vor einem Ausfall erneut aktiviert werden, damit das Sicherungssystem Resilienz bietet.

Bestimmte andere Richtlinientypen unterstützen die Verwendung des Sicherungsauthentifizierungssystems nicht. Die Verwendung der folgenden Richtlinien verringert die Resilienz:

• Verwendung der Anmeldefrequenzsteuerung als Teil einer Richtlinie für bedingten Zugriff.
• Verwendung der Authentifizierungsmethodenrichtlinie.
• Verwendung klassischer Richtlinien für bedingten Zugriff.

Auswertung von Nur-Bericht-Richtlinien für bedingten Zugriff

Wenn eine Anforderung vom Sicherungsauthentifizierungssystem verarbeitet wird, werden Richtlinien im Nur-Bericht-Modus für den bedingten Zugriff unter der Registerkarte "Bedingter Zugriff" in Entra ID>Monitoring & Health>Anmeldeprotokolle für dieses Anmeldeereignis angezeigt und nicht in der Registerkarte "Nur-Bericht". Beachten Sie, dass Richtlinien, die in dieser Ansicht im Nur-Bericht-Modus konfiguriert sind, niemals erzwungen werden. Um festzustellen, ob Token über das Sicherungsauthentifizierungssystem innerhalb Ihres Mandanten ausgestellt wurden, können Sie die Anmeldeprotokolle verwenden. Fügen Sie in Entra ID>Monitoring & Health>Sign-In Logs den Filter Token issuer type == Microsoft Entra Backup Auth hinzu, um die vom Sicherungsauthentifizierungssystem verarbeiteten Protokolle anzuzeigen.

Zertifikatsperrung und das Sicherungsauthentifizierungssystem

Um den Resilienzstatus zu verbessern, kann das Sicherungsauthentifizierungssystem keine neuen Sperrprüfungen durchführen. Stattdessen beruht sie auf dem Status der Zertifikatsperrlistenprüfung (Certificate Revocation List, CRL), die beim letzten Sichern der Sitzung durchgeführt wurde. Wenn Sie vor Ablauf dieser Sicherung widerrufen müssen, sollten Sie die Sitzung explizit widerrufen, anstatt auf die CRL zu warten.

Resilienz der Workloadidentität im Sicherungsauthentifizierungssystem

Zusätzlich zur Benutzerauthentifizierung bietet das Sicherungsauthentifizierungssystem Resilienz für verwaltete Identitäten und andere wichtige Azure-Infrastrukturelemente, indem es einen regional isolierten Authentifizierungsdienst bietet, der redundant mit dem primären Authentifizierungsdienst geschichtet ist. Dank dieses Systems kann die Infrastrukturauthentifizierung innerhalb einer Azure-Region resilient gegenüber Problemen gemacht werden, die in einer anderen Region oder innerhalb des umfassenderen Microsoft Entra-Diensts auftreten können. Dieses System ergänzt die regionenübergreifende Architektur von Azure. Wenn Sie Ihre eigenen Anwendungen mithilfe von MI erstellen und die bewährten Methoden von Azure für Resilienz und Verfügbarkeit befolgen, sind Ihre Anwendungen äußerst resilient. Zusätzlich zu MI schützt dieses regional resiliente Sicherungssystem wichtige Azure-Infrastrukturelemente und -Dienste, die die Funktionstüchtigkeit der Cloud gewährleisten.

Zusammenfassung der Unterstützung der Infrastrukturauthentifizierung

• Ihre auf der Azure-Infrastruktur aufgebauten Dienste, die verwaltete Identitäten verwenden, werden durch das Sicherungsauthentifizierungssystem geschützt.
• Azure-Dienste, die sich gegenseitig authentifizieren, werden durch das Sicherungsauthentifizierungssystem geschützt.
• Ihre auf oder außerhalb von Azure erstellten Dienste, bei denen die Identitäten als Dienstprinzipale und nicht als „verwaltete Identitäten“ registriert sind, werden nicht durch das Sicherungsauthentifizierungssystem geschützt.

Cloudumgebungen, die das Sicherungsauthentifizierungssystem unterstützen

Das Sicherungsauthentifizierungssystem wird in allen Cloudumgebungen unterstützt, ausgenommen Microsoft Azure, betrieben von 21Vianet. Die unterstützten Identitätstypen variieren je nach Cloud und weisen separate Authentifizierungsendpunkte auf, wie in der folgenden Tabelle beschrieben.

Anhang

Beliebte nicht von Microsoft stammende native Client-Apps und App-Kataloganwendungen

Azure-Ressourcen und deren Status

Nächste Schritte

• Anwendungsanforderungen an das Sicherungsauthentifizierungssystem
• Einführung in das Sicherungsauthentifizierungssystem
• Resilienzstandardeinstellungen für bedingten Zugriff
• Berichterstattung zur Performance der Service-Level-Vereinbarung (SLA) von Microsoft Entra