Datenschutzüberlegungen

Das folgende Diagramm veranschaulicht, wie Dienste Microsoft Entra-Objektdaten über eine Autorisierungsebene für die rollenbasierte Zugriffssteuerung speichern und abrufen. Diese Ebene ruft die interne Verzeichnisdatenzugriffsebene auf, um sicherzustellen, dass die Datenanforderung des Benutzers zulässig ist:

Zugriff auf interne Microsoft Entra-Schnittstellen: Die Dienst-zu-Dienst-Kommunikation mit anderen Microsoft-Diensten, z. B. Microsoft 365, verwendet Microsoft Entra ID-Schnittstellen die die Aufrufer des Diensts mithilfe von Clientzertifikaten autorisieren.

Zugriff auf externe Microsoft Entra-Schnittstellen: Die externe Microsoft Entra-Schnittstelle hilft dabei, mithilfe von RBAC Datenlecks zu verhindern. Wenn ein Sicherheitsprinzipal, z. B. ein Benutzer, eine Zugriffsanforderung zum Lesen von Informationen über Microsoft Entra ID-Schnittstellen sendet, muss ein Sicherheitstoken die Anforderung begleiten. Das Token enthält Ansprüche über den Prinzipal, der die Anforderung stellt.

Die Sicherheitstoken werden vom Microsoft Entra-Authentifizierungsdienst ausgestellt. Informationen zur Existenz, dem Aktivierungsstatus und der Rolle des Benutzers werden vom Autorisierungssystem verwendet, um zu entscheiden, ob der angeforderte Zugriff auf den Zielmandanten für diesen Benutzer in dieser Sitzung autorisiert ist.

Anwendungszugriff: Da Anwendungen ohne Benutzerkontext auf die APIs (Application Programming Interfaces) zugreifen können, enthält die Zugriffsüberprüfung Informationen zur Anwendung des Benutzers und zum angeforderten Zugriffsbereich, z. B. schreibgeschützt, Lese-/Schreibzugriff usw. Viele Anwendungen verwenden OpenID Connect oder OAuth, um Token für den Zugriff auf das Verzeichnis im Namen des Benutzers abzurufen. Diesen Anwendungen muss explizit Zugriff auf das Verzeichnis gewährt werden. Andernfalls erhalten sie kein Token vom Microsoft Entra-Authentifizierungsdienst und sie greifen auf Daten aus dem gewährten Bereich zu.

Überwachung: Der Zugriff wird überwacht. Beispielsweise können autorisierte Aktionen wie Benutzererstellung und Kennwortzurücksetzung einen Überwachungspfad erstellen, den ein Mandantenadministrator zum Verwalten von Maßnahmen zum Einhalten der Compliance oder Untersuchungen verwenden kann. Mandantenadministratoren können Überwachungsberichte mithilfe der Microsoft Entra-Überwachungs-API generieren.

Weitere Informationen: Überwachungsprotokolle in Microsoft Entra ID

Mandantenisolation: Die Erzwingung der Sicherheit in einer mehrmandantenfähigen Microsoft Entra-Umgebung trägt dazu bei, zwei primäre Ziele zu erreichen:

• Verhindern von Datenlecks und mandantenübergreifender Zugriff: Daten, die zu Mandant 1 gehören, können von Benutzern in Mandant 2 nicht ohne explizite Autorisierung durch Mandant 1 abgerufen werden.
• Mandantenübergreifende Ressourcenzugriffsisolation: Vorgänge, die von Mandant 1 ausgeführt werden, können sich nicht auf den Zugriff auf Ressourcen für Mandant 2 auswirken.

Mandantenisolation

Die folgenden Informationen beschreiben die Mandantenisolation.

• Der Dienst schützt Mandanten mithilfe einer RBAC-Richtlinie, um die Datenisolation sicherzustellen.
• Um den Zugriff auf einen Mandanten zu ermöglichen, muss sich ein Prinzipal, z. B. ein Benutzer oder eine Anwendung, bei Microsoft Entra ID authentifizieren können, um Kontext abzurufen und er muss über explizite Berechtigungen verfügen, die im Mandanten definiert sind. Wenn ein Prinzipal im Mandanten nicht autorisiert ist, wird das resultierende Token keine Berechtigungen enthalten, und das RBAC-System lehnt Anforderungen in diesem Kontext ab.
• RBAC stellt sicher, dass der Zugriff auf einen Mandanten durch einen im Mandanten autorisierten Sicherheitsprinzipal erfolgt. Mandantenübergreifender Zugriff ist möglich, wenn ein Mandantenadministrator eine Sicherheitsprinzipalvertretung im selben Mandanten erstellt (z. B. Bereitstellung eines Gastbenutzerkontos mithilfe der B2B-Zusammenarbeit) oder wenn ein Mandantenadministrator eine Richtlinie erstellt, um eine Vertrauensbeziehung mit einem anderen Mandanten zu aktivieren. Beispielsweise eine mandantenübergreifende Zugriffsrichtlinie zum Aktivieren einer direkten B2B-Verbindung. Jeder Mandant ist eine Isolationsgrenze. Die Existenz in einem Mandanten entspricht nicht der Existenz in einem anderen Mandanten, es sei denn, der Administrator lässt dies zu.
• Microsoft Entra-Daten für mehrere Mandanten werden auf demselben physischen Server und Laufwerk für eine bestimmte Partition gespeichert. Die Isolation wird sichergestellt, da der Zugriff auf die Daten durch das RBAC-Autorisierungssystem geschützt wird.
• Eine Kundenanwendung kann nicht ohne die erforderliche Authentifizierung auf Microsoft Entra ID zugreifen. Die Anforderung wird abgelehnt, wenn sie nicht im Rahmen des Prozesses der ersten Verbindungsaushandlung mit Anmeldeinformationen begleitet wird. Diese Dynamik verhindert den nicht autorisierten Zugriff auf einen Mandanten durch benachbarte Mandanten. Nur das Token der Benutzeranmeldeinformationen oder das SAML (Security Assertion Markup Language)-Token wird mit einer Verbundvertrauensstellung vermittelt. Daher wird sie anhand der vom Anwendungsbesitzer konfigurierten gemeinsam genutzten Schlüssel von Microsoft Entra ID überprüft.
• Da es keine Anwendungskomponente gibt, die über den Kernspeicher ausgeführt werden kann, ist es nicht möglich, dass ein Mandant die Integrität eines benachbarten Mandanten gewaltsam verletzt.

Datensicherheit

Verschlüsselung während der Übertragung: Um Datensicherheit zu gewährleisten, werden Verzeichnisdaten in Microsoft Entra ID signiert und während der Übertragung zwischen Rechenzentren innerhalb einer Skalierungseinheit verschlüsselt. Die Daten werden auf Microsoft Entra-Hauptspeicherebene ver- und entschlüsselt, die sich in geschützten Serverhostingbereichen der zugehörigen Microsoft-Rechenzentren befindet.

Kundenorientierte Webdienste sind mit dem Protokoll TLS (Transport Layer Security) geschützt.

Geheimnisspeicher: Das Microsoft Entra-Dienst-Back-End verwendet eine Verschlüsselung, um vertrauliches Material für die Dienstnutzung mittels proprietärer Microsoft-Technologie zu speichern, z. B. Zertifikate, Schlüssel, Anmeldeinformationen und Hashes. Der verwendete Speicher hängt vom Dienst, dem Vorgang, dem Umfang des Geheimnisses (benutzer- oder mandantenweit) und anderen Anforderungen ab.

Diese Speicher werden von einer auf Sicherheit fokussierten Gruppe über etablierte Automatisierung und Workflows betrieben, einschließlich Zertifikatanforderung, Verlängerung, Sperrung und Zerstörung.

Es gibt eine Aktivitätsüberwachung im Zusammenhang mit diesen Speichern/Workflows/Prozessen, und es gibt keinen ständigen Zugriff. Der Zugriff erfolgt auf Anforderungs- und Genehmigungsbasis und für einen begrenzten Zeitraum.

Weitere Informationen zur Verschlüsselung ruhender Geheimnisse finden Sie in der folgenden Tabelle.

Algorithmen: In der folgenden Tabelle sind die von Microsoft Entra-Komponenten verwendeten Mindestkryptografiealgorithmen aufgeführt. Als Clouddienst bewertet und verbessert Microsoft die Kryptografie anhand von Sicherheitsforschungsergebnissen, internen Sicherheitsüberprüfungen, Schlüsselstärke im Vergleich zur Hardwareentwicklung usw.

Daten/Szenario	Kryptografiealgorithmus
Kennworthashsynchronisierung Cloudkontokennwörter	Hash: Kennwortschlüsselableitungsfunktion 2 (Password Key Derivation Function 2, PBKDF2) unter Verwendung von Hash-based Message Authentication Code (HMAC)-SHA256 @ 1.000 Iterationen
Verzeichnis, das zwischen Rechenzentren übermittelt wird	AES-256-CTS-HMAC-SHA1-96 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Passthrough-Authentifizierung für Benutzeranmeldeinformationsflow	RSA 2048-Public/Private-Schlüsselpaar Weitere Informationen: Passthrough-Authentifizierung in Microsoft Entra – Tiefenanalyse der Sicherheit
Self-Service-Kennwortzurücksetzung – Kennwortrückschreiben mit Microsoft Entra Connect: Kommunikation zwischen der Cloud und der lokalen Umgebung	RSA 2048 Private/Public-Schlüsselpaar AES_GCM (256-Bit-Schlüssel, 96 Bit IV-Größe)
Self-Service-Kennwortzurücksetzung: Antworten auf Sicherheitsfragen	SHA256
SSL-Zertifikate für Microsoft Entra-Anwendung Veröffentlichte Proxyanwendungen	AES-GCM 256-Bit
Verschlüsselung auf Datenträgerebene	XTS-AES 128
Nahtloses Einmaliges Anmelden (Single Sign-On, SSO)Dienstkontokennwort Anmeldeinformationen für SaaS-Anwendungsbereitstellung (Software-as-a-Service)	AES-CBC 128 Bit
Verwaltete Identitäten für Azure-Ressourcen	AES-GCM 256-Bit
Microsoft Authenticator-App: Kennwortlose Anmeldung bei Microsoft Entra ID	Asymmetrischer RSA-Schlüssel 2048-Bit
Microsoft Authenticator-App: Sicherung und Wiederherstellung von Unternehmenskontometadaten	AES-256

Ressourcen

• Microsoft-Dienstvertrauensstellung – Dokumentation
• Microsoft Azure Trust Center
• Wiederherstellen nach Löschungen in Microsoft Entra ID

Nächste Schritte

• Microsoft Entra ID und Datenresidenz
• Betriebliche Überlegungen zu Daten
• Datenschutzüberlegungen (Sie befinden sich hier)