Microsoft Entra ID und Datenresidenz

  • Artikel

Microsoft Entra ID ist eine IDaaS-Lösung (Identity-as-a-Service), die Identitäten und Zugriffsdaten in der Cloud speichert und verwaltet. Sie können diese Daten verwenden, um den Zugriff auf Clouddienste zu ermöglichen und zu verwalten, Mobilitätsszenarios umzusetzen und Ihre Organisation zu schützen. Eine Instanz des Microsoft Entra-Diensts, die als Mandant bezeichnet wird, besteht aus isolierten Verzeichnisobjektdaten, die der Kunde bereitstellt und besitzt.

Hinweis

Microsoft Entra External ID ist eine Kundenidentitäts- und Zugriffsverwaltungslösung (CIAM), die Daten in einem separaten Mandanten speichert und verwaltet, der für Ihre kundenorientierten Apps und Kundenverzeichnisdaten erstellt wurde. Dieser Mandant wird als externer Mandant bezeichnet. Beim Erstellen eines externen Mandanten haben Sie die Möglichkeit, den geografischen Standort für die Datenspeicherung auszuwählen. Dabei muss beachtet werden, dass sich die Verfügbarkeit von Datenstandorten und -regionen von denen von Microsoft Entra ID unterscheidet, wie in diesem Artikel angegeben.

Zentraler Speicher

Der zentrale Speicher besteht aus Mandanten, die in Skalierungseinheiten gespeichert sind, die jeweils mehrere Mandanten enthalten. Vorgänge zum Aktualisieren oder Abrufen von Daten im Microsoft Entra Core-Speicher werden basierend auf dem Sicherheitstoken des Benutzers für einen einzelnen Mandanten durchgeführt, wodurch eine Mandantenisolation erreicht wird. Skalierungseinheiten werden einem geografischen Standort zugewiesen. Jeder geografische Standort verwendet mindestens zwei Azure-Regionen zum Speichern der Daten. In jeder Azure-Region werden die Daten einer Skalierungseinheit in die physischen Rechenzentren repliziert, um Resilienz und Leistung zu gewährleisten.

Weitere Informationen: Skalierungseinheiten Microsoft Entra Core-Speicher

Microsoft Entra ID ist in den folgenden Clouds verfügbar

  • Öffentlich
  • China*
  • US Government*

* Derzeit nicht für externe Mandanten verfügbar

In der öffentlichen Cloud werden Sie während der Erstellung eines Mandanten aufgefordert, einen Standort auszuwählen (wenn Sie sich z. B. für Office 365 oder Azure registrieren oder weitere Microsoft Entra-Instanzen über das Azure-Portal erstellen). Microsoft Entra ID ordnet die Auswahl einem geografischen Standort und einer einzelnen Skalierungseinheit darin zu. Der Mandantenstandort kann nach dem Festlegen nicht mehr geändert werden.

Der bei der Erstellung des Mandanten ausgewählte Standort entspricht einem der folgenden geografischen Standorte:

  • Australien*
  • Asien-Pazifik
  • Europa, Naher Osten und Afrika (EMEA)
  • Japan*
  • Nordamerika
  • Weltweit

* Derzeit nicht für externe Mandanten verfügbar

Microsoft Entra ID verarbeitet Core-Speicherdaten basierend auf Nutzbarkeit, Leistung, Herkunft oder anderen Anforderungen des jeweiligen geografischen Standorts. Microsoft Entra ID repliziert jeden Mandanten rechenzentrumsübergreifend über seine Skalierungseinheit. Dabei gelten die folgenden Kriterien:

  • Microsoft Entra Core-Speicherdaten, die in Rechenzentren gespeichert werden, die dem Standort des Mandanten am nächsten sind, um die Latenzzeit zu verringern und eine schnelle Benutzeranmeldung zu ermöglichen
  • Microsoft Entra Core-Speicherdaten, die in geografisch isolierten Rechenzentren gespeichert sind, um die Verfügbarkeit bei unvorhergesehenen Naturkatastrophen in einem einzelnen Rechenzentrum sicherzustellen
  • Einhaltung von Datenresidenz oder anderen Anforderungen für spezifische Kunden und geografische Räume

Microsoft Entra-Cloudlösungsmodelle

In der folgenden Tabelle finden Sie Microsoft Entra-Cloudlösungsmodelle basierend auf Infrastruktur, Datenspeicherort und Betriebssouveränität.

Modell Speicherorte Speicherort der Daten Betriebspersonal Mandant ins Modell einfügen
Öffentlicher geografischer Standort Australien*, Nordamerika, EMEA, Japan*, Asien-Pazifik Im Ruhezustand, am Zielstandort. Ausnahmen nach Dienst oder Feature Microsoft ist der Betreiber. Mitarbeiter*innen in Microsoft-Rechenzentren müssen eine Hintergrundprüfung bestehen. Erstellen Sie den Mandanten über die Registrierungsoberfläche. Wählen Sie den Standort für die Datenresidenz aus.
Weltweit öffentlich Weltweit Alle Standorte Microsoft ist der Betreiber. Mitarbeiter*innen in Microsoft-Rechenzentren müssen eine Hintergrundprüfung bestehen. Die Mandantenerstellung erfolgt über den offiziellen Supportkanal und liegt im Ermessen von Microsoft.
Sovereign Clouds oder nationale Clouds US Government*, China* Im Ruhezustand, am Zielstandort. keine Ausnahmen Ein Data Custodian (1) ist der Betreiber. Die Mitarbeiter*innen werden den Anforderungen entsprechend geprüft. Jede nationale Cloudinstanz verfügt über eine Registrierungsoberfläche.

* Derzeit nicht für externe Mandanten verfügbar

Tabellenverweise:

(1) Datenverwalter: Rechenzentren in der US Government-Cloud werden von Microsoft betrieben. In China wird Microsoft Entra ID über eine Partnerschaft mit 21Vianet betrieben.

Weitere Informationen:

Datenresidenz über Microsoft Entra-Komponenten hinweg

Weitere Informationen: Microsoft Entra Produktübersicht

Hinweis

Informationen zum Speicherort von Dienstdaten, z. B. Exchange Online oder Skype for Business, finden Sie in der entsprechenden Dienstdokumentation.

Microsoft Entra-Komponenten und Datenspeicherort

Microsoft Entra-Komponente Beschreibung Datenspeicherort
Microsoft Entra-Authentifizierungsdienst Dieser Dienst ist zustandslos. Die Daten für die Authentifizierung befinden sich im zentralen Microsoft Entra-Speicher. Dieser enthält keine Verzeichnisdaten. Der Microsoft Entra-Authentifizierungsdienst generiert Protokolldaten in Azure Storage und in dem Rechenzentrum, in dem die Dienstinstanz ausgeführt wird. Wenn Benutzer oder Benutzerinnen versuchen, sich bei Microsoft Entra ID zu authentifizieren, werden sie an eine Instanz im geografisch nächstgelegenen Rechenzentrum weitergeleitet, das Teil der logischen Microsoft Entra-Region ist. Am geografischen Standort
Microsoft Entra Identitäts- und Zugriffsverwaltungsdienste (Identity and Access Management, IAM) Benutzer- und Verwaltungsoberflächen: Die Microsoft Entra-Verwaltungsoberfläche ist zustandslos und enthält keine Verzeichnisdaten. Sie generiert Protokoll- und Nutzungsdaten, die in Azure Table Storage gespeichert werden. Die Benutzeroberfläche ähnelt dem Azure-Portal.
Geschäftslogik und Berichterstellungsdienste für die Identitätsverwaltung: Diese Dienste verfügen über einen lokal zwischengespeicherten Datenspeicher für Gruppen und Benutzer*innen. Die Dienste generieren Protokoll- und Nutzungsdaten, die an Azure Table Storage, Azure SQL und Microsoft-Berichterstellungsdienste für die elastische Suche gesendet werden.		 Am geografischen Standort
Multi-Faktor-Authentifizierung in Microsoft Entra Weitere Informationen zur Speicherung und Aufbewahrung von Daten zu Vorgängen bei der Multi-Faktor-Authentifizierung finden Sie unter Datenresidenz und Kundendaten für die Microsoft Entra-Multi-Faktor-Authentifizierung. Microsoft Entra Multi-Faktor-Authentifizierung protokolliert den Benutzerprinzipalnamen (User Principal Name, UPN), die Telefonnummern von Sprachanrufen und SMS-Captchas. Für Captchas in mobilen Apps protokolliert der Dienst den UPN und ein eindeutiges Gerätetoken. Die Rechenzentren in der Region Nordamerika speichern die Microsoft Entra-Multi-Faktor-Authentifizierung und die damit erstellten Protokolle. Nordamerika
Microsoft Entra Domain Services Die Regionen, in denen Microsoft Entra Domain Services veröffentlicht wurde, finden Sie unter Verfügbare Produkte nach Region. Der Dienst speichert Systemmetadaten global in Azure Table Storage. Diese enthalten keine personenbezogenen Daten. Am geografischen Standort
Microsoft Entra Connect Health Microsoft Entra Connect Health generiert Warnungen und Berichte in Azure Table Storage und Blob Storage. Am geografischen Standort
Gruppen mit dynamischer Mitgliedschaft in Microsoft Entra, Self-Service-Gruppenverwaltung in Microsoft Entra Der Azure Table Storage enthält Regeldefinitionen für dynamische Mitgliedergruppen. Am geografischen Standort
Microsoft Entra-Anwendungsproxy Der Microsoft Entra-Anwendungsproxy speichert Metadaten zu Mandanten, Connectorcomputern und Konfigurationsdaten in Azure SQL. Am geografischen Standort
Microsoft Entra-Kennwortrückschreiben in Microsoft Entra Connect Während der Erstkonfiguration generiert Microsoft Entra Connect mithilfe des RSA-Kryptosystems (Rivest-Shamir-Adleman) ein asymmetrisches Schlüsselpaar. Anschließend wird der öffentliche Schlüssel an den Clouddienst für die Self-Service-Kennwortzurücksetzung (Self-Service Password Reset, SSPR) gesendet, der zwei Vorgänge ausführt:

1. Es werden zwei Azure Service Bus-Relays für den lokalen Microsoft Entra Connect-Dienst erstellt, um sicher mit dem SSPR-Dienst zu kommunizieren
2. Es wird der AES-Schlüssel (Advanced Encryption Standard) K1 generiert.

Die Azure Service Bus-Relayspeicherorte, die zugehörigen Listenerschlüssel und eine Kopie des AES-Schlüssels (K1) werden in der Antwort an Microsoft Entra Connect übergeben. Die zukünftige Kommunikation zwischen SSPR und Microsoft Entra Connect erfolgt über den neuen Service Bus-Kanal und wird mit SSL verschlüsselt.
Neue Kennwortzurücksetzungen, die während des Betriebs übermittelt werden, werden mit dem öffentlichen RSA-Schlüssel verschlüsselt, der vom Client während des Onboardings generiert wird. Der private Schlüssel auf dem Microsoft Entra Connect-Computer entschlüsselt sie, wodurch verhindert wird, dass Pipelinesubsysteme auf das Klartextkennwort zugreifen.
Der AES-Schlüssel verschlüsselt die Nachrichtennutzdaten (verschlüsselte Kennwörter, weitere Daten und Metadaten), wodurch verhindert wird, dass Service Bus-Angreifer*innen diese manipulieren, auch wenn sie Vollzugriff auf den internen Service Bus-Kanal haben.
Für das Kennwortrückschreiben benötigt Microsoft Entra Connect Schüssel und Daten:

– Den AES-Schlüssel (K1), der die Nutzdaten zur Zurücksetzung verschlüsselt, oder Änderungsanforderungen vom SSPR-Dienst an Microsoft Entra Connect über die Service Bus-Pipeline
– Den privaten Schlüssel aus dem asymmetrischen Schlüsselpaar, der das Kennwort verschlüsselt, in den Nutzdaten für die Zurücksetzung oder Änderungsanforderung
– Die Service Bus-Listenerschlüssel

Der AES-Schlüssel (K1) und das asymmetrische Schlüsselpaar rotieren mindestens alle 180 Tage. Diesen Rhythmus können Sie bei bestimmten Konfigurationsereignissen für das Onboarding oder Offboarding ändern. Ein Beispiel ist, dass ein Kunde oder eine Kundin das Kennwortrückschreiben deaktiviert und erneut aktiviert, was bei Komponentenupgrades während der Wartung der Fall sein kann.
Die in der Microsoft Entra Connect-Datenbank gespeicherten Rückschreibeschlüssel und -daten werden von der Datenschutz-API (CALG_AES_256) verschlüsselt. Das Ergebnis ist der ADSync-Masterverschlüsselungsschlüssel, der im Windows-Anmeldeinformationstresor im Kontext des lokalen ADSync-Dienstkontos gespeichert ist. Der Windows-Anmeldeinformationstresor verschlüsselt Geheimnisse automatisch erneut, wenn sich das Kennwort für das Dienstkonto ändert. Durch das Zurücksetzen des Dienstkontokennworts werden Geheimnisse im Windows-Anmeldeinformationstresor für das Dienstkonto ungültig. Gespeicherte Geheimnisse können durch manuelle Änderungen an einem neuen Dienstkonto ungültig werden.
Standardmäßig wird der ADSync-Dienst im Kontext eines virtuellen Dienstkontos ausgeführt. Das Konto kann während der Installation an ein Domänendienstkonto mit den geringsten Rechten, ein verwaltetes Dienstkonto (Managed Service Account, MSA) oder ein gruppenverwaltetes Dienstkonto (gMSA) angepasst werden. Während virtuelle und verwaltete Dienstkonten über eine automatische Kennwortrotation verfügen, verwalten Kunden die Kennwortrotation für ein benutzerdefiniertes bereitgestelltes Domänenkonto selbst. Wie bereits erwähnt, führt das Zurücksetzen des Kennworts zum Verlust gespeicherter Geheimnisse.		 Am geografischen Standort
Microsoft Entra-Geräteregistrierungsdienst Im Microsoft Entra Geräteregistrierungsdienst erfolgt die Lebenszyklusverwaltung für Computer und Geräte im Verzeichnis, wodurch Szenarios wie der bedingte Zugriff nach Gerätestatus und die Verwaltung mobiler Geräte ermöglicht werden. Am geografischen Standort
Microsoft Entra-Bereitstellung Die Microsoft Entra-Bereitstellung erstellt, entfernt und aktualisiert Benutzer und Benutzerinnen in Systemen, z. B. SaaS-Anwendungen (Software-as-a-Service). Sie verwaltet die Benutzererstellung in Microsoft Entra ID und lokalem Microsoft Windows Server Active Directory aus HR-Cloudquellen wie Workday. Der Dienst speichert seine Konfiguration in einer Azure Cosmos DB-Instanz, in der wiederum die Gruppenmitgliedschaftsdaten für das von ihm gespeicherte Benutzerverzeichnis gespeichert werden. Azure Cosmos DB repliziert die Datenbank in mehrere Rechenzentren in derselben Region wie der Mandant, wodurch die Daten gemäß dem Microsoft Entra-Cloudlösungsmodell isoliert werden. Die Replikation erzeugt Hochverfügbarkeit und mehrere Lese- und Schreibendpunkte. Azure Cosmos DB ermöglicht eine Verschlüsselung der Datenbankinformationen, und die Verschlüsselungsschlüssel werden im Geheimnisspeicher für Microsoft gespeichert. Am geografischen Standort
Microsoft Entra B2B Collaboration Microsoft Entra B2B Collaboration enthält keine Verzeichnisdaten. Benutzer*innen und andere Verzeichnisobjekte in einer B2B-Beziehung mit einem anderen Mandanten führen dazu, dass Benutzerdaten in andere Mandanten kopiert werden, was Auswirkungen auf die Datenresidenz haben kann. Am geografischen Standort
Microsoft Entra ID-Schutz Microsoft Entra ID Protection verwendet Benutzeranmeldedaten in Echtzeit mit mehreren Signalen aus Unternehmens- und Branchenquellen, um seine Machine-Learning-Systeme zu trainieren, die anomale Anmeldungen erkennen. Personenbezogene Daten werden aus Echtzeit-Anmeldedaten entfernt, bevor sie an das Machine-Learning-System übergeben werden. Die verbleibenden Anmeldedaten identifizieren potenziell riskante Benutzernamen und Anmeldungen. Nach der Analyse werden die Daten an Microsoft-Berichterstellungssysteme gesendet. Riskante Anmeldungen und Benutzernamen werden in den Berichten für Administrator*innen angezeigt. Am geografischen Standort
Verwaltete Identitäten für Azure-Ressourcen Verwaltete Identitäten für Azure-Ressourcen mit verwalteten Identitätssystemen können sich bei Azure-Diensten authentifizieren, ohne Anmeldedaten zu speichern. Verwaltete Identitäten authentifizieren sich mit Zertifikaten statt Benutzernamen und Kennwörtern bei Azure-Diensten. Der Dienst schreibt die Zertifikate, die er in Azure Cosmos DB ausstellt, in die Region „USA, Osten“, und führt bei Bedarf ein Failover in eine andere Region durch. Die Georedundanz von Azure Cosmos DB wird durch globale Datenreplikation erzielt. Bei der Datenbankreplikation wird in jeder Region, in der verwaltete Microsoft Entra-Identitäten ausgeführt werden, eine schreibgeschützte Kopie erstellt. Weitere Informationen finden Sie unter Azure-Dienste mit Nutzung verwalteter Identitäten für den Zugriff auf andere Dienste. Microsoft isoliert jede Azure Cosmos DB-Instanz in einem Microsoft Entra-Cloudlösungsmodell.
Der Ressourcenanbieter, z. B. der VM-Host, speichert das Zertifikat für die Authentifizierung und Identitätsflows bei anderen Azure-Diensten. Der Dienst speichert seinen Hauptschlüssel für den Zugriff auf Azure Cosmos DB in einem Geheimnisverwaltungsdienst für Rechenzentren. Azure Key Vault speichert die Hauptverschlüsselungsschlüssel.		 Am geografischen Standort

Weitere Informationen zur Datenresidenz in Microsoft Cloud-Angeboten finden Sie in den folgenden Artikeln:

Nächste Schritte