Zum Hauptinhalt wechseln

 Subscribe

Azure Active Directory (Azure AD) is now Microsoft Entra ID. Learn more.

„Damit unsere Reihe zur Zuverlässigkeit von Azure in Bezug auf Initiativen zur Verbesserung der Verfügbarkeit weiterhin so transparent wie möglich bleibt, wenden wir uns heute Azure Active Directory zu. Microsoft Azure Active Directory (Azure AD) ist ein Cloudidentitätsdienst, der sicheren Zugriff auf über 250 Millionen monatlich aktive Benutzer ermöglicht, über 1,4 Millionen einzigartige Anwendungen vernetzt und über 30 Milliarden Authentifizierungsanforderungen pro Tag verarbeitet. Dadurch ist Azure AD nicht nur die umfangreichste Identitäts- und Zugriffsverwaltungslösung für Unternehmen, sondern sogar einer der größten Dienste weltweit. Dieser Beitrag wurde von Nadim Abdo verfasst, Partner Director im Engineering, der in diesen Bestrebungen eine führende Rolle einnimmt.“ – Mark Russinovich, CTO bei Azure.


 

Unsere Kunden vertrauen darauf, dass Azure AD den sicheren Zugriff auf alle ihre Anwendungen und Dienste verwaltet. Für uns bedeutet das, dass jede Authentifizierungsanforderung ein unternehmenskritischer Vorgang ist. Aufgrund der Kritikalität und des Umfangs des Diensts liegt die oberste Priorität unseres Identitätsteams in dessen Zuverlässigkeit und Sicherheit. Azure AD wurde für Zuverlässigkeit und Sicherheit entwickelt. Dafür kommt eine cloudnative, hyperskalierbare Architektur mit mehreren Mandanten zum Einsatz. Unser Team arbeitet stetig daran, die Zuverlässigkeit und Sicherheit weiter zu verbessern.

Azure AD: Kernprinzipien zur Verfügbarkeit

Das Entwickeln eines so umfangreichen, komplexen Diensts, dessen Verfügbarkeit unternehmenskritisch ist, stellt in einer Zeit, in der Fehler unvermeidlich sind, eine große Herausforderung dar.

Unsere Bemühungen für Resilienz orientieren sich an folgenden Zuverlässigkeitsprinzipien:

o	Die Bemühungen für Resilienz in Azure AD orientieren sich an folgenden Zuverlässigkeitsprinzipien:

Wir stellen die Verfügbarkeit sicher, indem wir einen mehrstufigen Sicherheitsansatz einführen, um die Wahrscheinlichkeit eines für Kunden wahrnehmbaren Fehlers auf ein Minimum zu reduzieren. Zudem soll im Fall eines Fehlers dessen Auswirkung so gering wie möglich gehalten werden, und die Zeit zur Wiederherstellung und zur Behebung der Auswirkungen nach einem Fehler soll so weit wie möglich verringert werden.

In den kommenden Wochen und Monaten erläutern wir den Aufbau und die Praxistauglichkeit dieser Prinzipien näher und veröffentlichen Beispiele, wie unsere Kunden diese einsetzen.

Hochredundant

Azure AD ist ein globaler Dienst mit einer mehrstufigen internen Redundanz und automatischer Wiederherstellbarkeit. Azure AD wird in über 30 Rechenzentren weltweit bereitgestellt und nutzt Azure-Verfügbarkeitszonen, wenn sie vor Ort vorhanden sind. Mit der Bereitstellung weiterer Azure-Regionen wächst deren Anzahl rapide.

Zur Sicherstellung der Beständigkeit werden alle in Azure AD geschriebenen Daten je nach Mandantenkonfiguration in vier bis dreizehn Rechenzentren repliziert. In jedem Rechenzentrum werden die Daten noch einmal mindestens neunmal repliziert, um nicht nur die Beständigkeit, sondern auch die Skalierbarkeit sicherzustellen, falls eine hohe Authentifizierungslast zu bewältigen ist. Das bedeutet, dass selbst in der kleinsten Region jederzeit mindestens 36 Kopien Ihrer Verzeichnisdaten in unserem Dienst vorhanden sind. Weiterhin sorgen wir für Beständigkeit, indem Schreibvorgänge in Azure AD nicht abgeschlossen werden, bis ein erfolgreicher Commit an ein Rechenzentrum in einer anderen Region erfolgt ist.

Dieser Ansatz bedeutet eine Beständigkeit der Daten und eine enorme Redundanz, denn mehrere Netzwerkpfade und Rechenzentren können jede eingehende Autorisierungsanforderung verarbeiten, und das System führt automatisch und intelligent wiederholte Versuche und Fehlerumgehungen innerhalb eines Rechenzentrums und zwischen Rechenzentren durch.

Wir überprüfen die ordnungsgemäße Funktionalität regelmäßig, indem wir testweise Fehler injizieren und so die Fehlerresilienz der Systemkomponenten überprüfen, auf denen Azure AD basiert. Dabei gehen wir sogar regelmäßig so weit, gesamte Rechenzentren außer Kraft zu setzen, damit wir bestätigen können, dass das System den Verlust eines Rechenzentrums ohne Auswirkungen für Kunden verkraftet.

Kein Single Point of Failure (SPOF)

Wie bereits erwähnt ist Azure AD mit einer mehrstufigen internen Resilienz ausgestattet. Unsere Prinzipien dehnen sich jedoch auch auf externe Abhängigkeiten aus, um deren Resilienz zu gewährleisten. Das zeigt sich in unserem SPOF-Prinzip (Single Point of Failure).

Aufgrund der Kritikalität unserer Dienste akzeptieren wir keinen SPOF in kritischen externen Systemen wie Distributed Name Services, Content Delivery Networks oder Telekommunikationsanbietern, die unsere mehrstufige Authentifizierung (MFA) inklusive SMS und Stimmerkennung verarbeiten. Für jedes dieser Systeme nutzen wir mehrere redundante Systeme, die eine vollständig Active/Active-Konfiguration aufweisen.

Ein Großteil der Arbeit an diesem Prinzip wurde im Lauf des letzten Kalenderjahrs abgeschlossen. Das zeigte sich vor Kurzem auch daran, dass Azure AD nicht von einem Ausfall eines großen DNS-Anbieters betroffen war, da wir einen Active/Active-Pfad zu einem Alternativanbieter eingesetzt haben.

Flexible Skalierbarkeit

Azure AD ist bereits ein sehr umfangreiches System, in dem über 300.000 CPU-Kerne ausgeführt werden und das auf die enorme Skalierbarkeit der Azure-Cloud baut, um nach Bedarf dynamisch und schnell skalierbar zu sein. Dabei kann es sich um gewöhnliche Steigerungen des Datenverkehrs wie eine Spitze in Authentifizierungsanforderungen zu Arbeitsbeginn in einer bestimmten Region, aber auch um einen enormen und schnellen Anstieg in neuem Datenverkehr durch Azure Active Directory B2C handeln. Dieser Dienst wird für einige der weltweit größten Ereignisse genutzt und muss häufig Millionen neuer Benutzer verarbeiten.

Für zusätzliche Resilienz erfolgt eine Überbereitstellung der Kapazität durch Azure AD. Zudem wurde der Dienst so entwickelt, dass bei einem Failover eines gesamten Rechenzentrums keine erneute Bereitstellung der Kapazität erforderlich ist, um die umverteilte Auslastung zu verarbeiten. Dadurch wissen wir, dass die erforderliche Kapazität in einem Notfall bereitsteht.

Sichere Bereitstellung

Durch eine sichere Bereitstellung wird sichergestellt, dass Änderungen am Code oder der Konfiguration nach und nach aufeinander aufbauen, um von der internen Automatisierung über Microsoft-interne Self-Hosting-Ringsysteme bis hin zur Produktion zu gelangen. In der Produktion setzen wir einen gestaffelten und langsam steigenden Prozentsatz an Benutzern einer Änderung aus. Durch automatisierte Integritätsprüfungen beschränken wir das Fortschreiten von einem Bereitstellungsring zum nächsten. Das gesamte Rollout einer Änderung in der Produktion nimmt über eine Woche in Anspruch. Nach Bedarf kann jederzeit ein Rollback auf den letzten überprüften Integritätszustand erfolgen.

Durch dieses System werden regelmäßig potenzielle Fehler in den sogenannten „Early Rings“ erfasst, die Microsoft-intern sind und das Rollout an Ringe verhindern, die sich auf den Datenverkehr für Kunden oder Produktion auswirken würden.

Moderne Überprüfung

Zur Unterstützung der Integritätsprüfungen, die die sichere Bereitstellung beschränken und unserem Entwicklungsteam Einblicke in die Systemintegrität ermöglichen, gibt Azure AD eine enorme Menge interner Telemetriedaten und Signale aus, die zur Überwachung der Systemintegrität genutzt werden. In unserem Maßstab bedeutet das über 11 Petabyte an Signalen pro Woche, die den automatisierten Integritätsüberwachungssystemen zugeführt werden. Diese Systeme lösen wiederum Warnungen für die Automatisierung und unser ganzjährig verfügbares Entwicklerteam, das auf mögliche Beeinträchtigungen bei der Verfügbarkeit der Quality of Service (QoS) reagiert.

Diese Telemetriedaten werden visualisiert, sodass Einblicke in die Dienstintegrität sowie Metriken verfügbar sind, die die Gesamtintegrität eines bestimmten Szenarios für einen bestimmten Mandanten veranschaulichen. Unser Team erstellt intern bereits Warnungen zu diesen Metriken, und es wird überprüft, wie diese mandantenbasierten Integritätsdaten für Kunden direkt im Azure-Portal verfügbar gemacht werden können.

Partitionierung und präzise abgestimmte Fehlerdomänen

Eine gute Analogie zu Azure AD sind die Tanks eines U-Boots, die so konzipiert sind, dass sie mit Wasser gefüllt werden können, ohne die anderen Tanks oder die Unversehrtheit des gesamten U-Boots zu beeinträchtigen.

Das Äquivalent hierzu ist bei Azure AD eine Fehlerdomäne. Die Skalierungseinheiten, die für bestimmte Mandanten in einer Fehlerdomäne zuständig sind, sind entwicklungsbedingt vollständig von anderen Skalierungseinheiten einer Fehlerdomäne isoliert. Diese Fehlerdomänen ermöglichen eine strikte Isolation vieler Fehlerarten, da der Schaden durch einen Fehler sich nur auf eine bestimmte Fehlerdomäne erstrecken kann.

Bisher bestand Azure AD aus fünf separaten Fehlerdomänen. Seit letztem Jahr erhöhen wir diese, und bis zum Sommer sollen 50 Fehlerdomänen verfügbar sein. Zudem werden viele Dienste wie Azure Multi-Factor Authentication (MFA) verschoben, damit diese vollständig in diesen Fehlerdomänen isoliert werden können.

Die viele Arbeit, die wir in die Partitionierung investiert haben, dient dem Ziel, dass maximal 2 % unserer Benutzer von Ausfällen oder Fehlern betroffen sind. Im kommenden Jahr planen wir, die Anzahl auf Hunderte Fehlerdomänen zu erhöhen.

Ausblick auf unsere Pläne

Durch die hier beschriebenen Prinzipien soll der Azure AD-Kerndienst gehärtet werden. Da Azure AD ein wichtiger Dienst ist, ist unsere Arbeit damit noch lange nicht beendet. In zukünftigen Beiträgen informieren wir Sie über neue Projekte wie das Rollout eines zweiten und vollständig von Fehlern unabhängigen Identitätsdiensts in der Produktion, der eine nahtlose Fallbackauthentifizierung unterstützt, falls ein Fehler im Azure AD-Hauptdienst auftritt.

Diesen können Sie sich wie einen Ersatzgenerator oder eine Anlage für unterbrechungsfreie Stromversorgung vorstellen, die im Fall einer Störung der primären Stromversorgung für einen flüssigen und sicheren Betrieb sorgt. Das System ist vollständig transparent und steht Endbenutzern nahtlos zur Verfügung. Derzeit wird es in der Produktion eingesetzt, um einige unserer kritischen Authentifizierungsflows für bestimmte M365-Workloads zu schützen. Wir arbeiten daran, dessen Anwendbarkeit auf weitere Szenarios und Workloads auszudehnen.

Bald werden weitere Beiträge auf dem Azure Active Directory Identity Blog veröffentlicht. Stellen Sie uns gern Fragen, und teilen Sie uns mit, zu welchen Themen Sie zukünftig Beiträge lesen möchten.

  • Explore

     

    Let us know what you think of Azure and what you would like to see in the future.

     

    Provide feedback

  • Build your cloud computing and Azure skills with free courses by Microsoft Learn.

     

    Explore Azure learning


Join the conversation