Funktionsweise des Azure Rights Management-Diensts: Technische Details

Verwenden Sie die folgenden Informationen, wenn Sie die Funktionsweise des Azure Rights Management-Diensts ausführlicher verstehen möchten. Sie müssen diese Informationsebene nicht kennen, um die Verschlüsselungseinstellungen zum Schutz Ihrer Daten zu konfigurieren oder anzuwenden.

Ein wichtiges Konzept, das Sie über den Azure Rights Management-Dienst verstehen sollten, ist, dass dieser Dienst Ihre Daten nicht im Rahmen des Verschlüsselungsprozesses einsehen oder speichert. Informationen, die Sie verschlüsseln, werden niemals an Azure gesendet oder in Azure gespeichert, es sei denn, Sie speichern sie explizit in Azure oder verwenden einen anderen Clouddienst, der sie in Azure speichert. Der Azure Rights Management-Dienst macht die Daten in einem Element für andere Benutzer und Dienste als autorisierte Benutzer und Dienste einfach unlesbar:

• Die Daten werden auf Anwendungsebene verschlüsselt und enthalten eine Richtlinie, die die autorisierte Verwendung für dieses Element definiert.

• Wenn ein verschlüsseltes Element von einem legitimen Benutzer verwendet oder von einem autorisierten Dienst verarbeitet wird, werden die Daten im Element entschlüsselt, und die in der Richtlinie definierten Rechte werden erzwungen.

In der folgenden Abbildung können Sie sehen, wie dieser Prozess funktioniert. Ein Dokument, das die Geheimnisformel enthält, wird verschlüsselt und dann erfolgreich von einem autorisierten Benutzer oder Dienst geöffnet. Das Dokument wird mit einem Inhaltsschlüssel verschlüsselt (der grüne Schlüssel in dieser Abbildung). Der Inhaltsschlüssel ist für jedes Dokument eindeutig und wird in der Dateikopfzeile platziert, wo er mit Dem Stammschlüssel ihres Azure Rights Management-Mandanten verschlüsselt wird (der rote Schlüssel in dieser Abbildung). Ihr Mandantenschlüssel kann von Microsoft generiert und verwaltet werden, oder Sie können Ihren eigenen Mandantenschlüssel generieren und verwalten.

Während des gesamten verschlüsselten Prozesses, wenn der Azure Rights Management-Dienst Einschränkungen ver- und entschlüsselt, autorisiert und erzwingt, wird die Geheimnisformel nie an Azure gesendet.

Eine ausführliche Beschreibung der Vorgänge finden Sie im Abschnitt Exemplarische Vorgehensweise zur Funktionsweise des Diensts: Erste Verwendung, Inhaltsverschlüsselung, Inhaltsnutzung in diesem Artikel.

Ausführliche Informationen zu den Algorithmen und Schlüssellängen, die der Dienst verwendet, finden Sie im nächsten Abschnitt.

Kryptografische Steuerelemente: Algorithmen und Schlüssellängen

Auch wenn Sie nicht im Detail wissen müssen, wie diese Technologie funktioniert, werden Sie möglicherweise zu den kryptografischen Steuerelementen gefragt, die sie verwendet. Beispielsweise, um zu bestätigen, dass die Verschlüsselung branchenüblicher Standard ist.

Fußnote 1

256 Bits werden vom Microsoft Purview Information Protection-Client in den folgenden Szenarien verwendet:

• Generische Verschlüsselung (.pfile).

• Native Verschlüsselung für PDF-Dokumente, wenn das Dokument mit dem ISO-Standard für die PDF-Verschlüsselung verschlüsselt wurde oder das resultierende verschlüsselte Dokument über die Dateinamenerweiterung .ppdf verfügt.

• Native Verschlüsselung für Text- oder Bilddateien (z. B. PTXT oder PJPG).

Fußnote 2

2048 Bit ist die Schlüssellänge, wenn der Azure Rights Management-Dienst aktiviert wird. 1024 Bits werden für die folgenden optionalen Szenarien unterstützt:

• Während einer Migration aus der lokalen Umgebung, wenn der AD RMS-Cluster im Kryptografiemodus 1 ausgeführt wird.

• Für archivierte Schlüssel, die vor der Migration lokal erstellt wurden, damit Inhalte, die zuvor von AD RMS verschlüsselt wurden, nach der Migration weiterhin vom Azure Rights Management-Dienst geöffnet werden können.

Wie die kryptografischen Schlüssel gespeichert und gesichert werden

Für jedes Dokument oder jede E-Mail, die vom Azure Rights Management-Dienst geschützt ist, erstellt der Dienst einen einzelnen AES-Schlüssel (den "Inhaltsschlüssel"), und dieser Schlüssel wird in das Dokument eingebettet und über Editionen des Dokuments beibehalten.

Der Inhaltsschlüssel wird mit dem RSA-Schlüssel des organization (dem "Azure Rights Management-Mandantenschlüssel") als Teil der Richtlinie im Dokument verschlüsselt, und die Richtlinie wird auch vom Autor des Dokuments signiert. Dieser Mandantenschlüssel ist für alle Dokumente und E-Mails gemeinsam, die vom Azure Rights Management-Dienst für die organization geschützt sind, und dieser Schlüssel kann nur von einem Administrator für den Dienst geändert werden, wenn der organization einen kundenseitig verwalteten Mandantenschlüssel verwendet (bekannt als "Bring Your Own Key" oder BYOK).

Dieser Mandantenschlüssel wird in der Onlinedienste von Microsoft, in einer streng kontrollierten Umgebung und unter strenger Überwachung geschützt. Wenn Sie einen kundenseitig verwalteten Mandantenschlüssel (BYOK) verwenden, wird diese Sicherheit durch die Verwendung eines Arrays von High-End-Hardwaresicherheitsmodulen (HSMs) in jeder Azure-Region verbessert, ohne dass die Schlüssel extrahiert, exportiert oder freigegeben werden können. Weitere Informationen zum Mandantenschlüssel und zum BYOK finden Sie unter Verwalten des Stammschlüssels für Ihren Azure Rights Management-Dienst.

Lizenzen und Zertifikate, die an ein Windows-Gerät gesendet werden, werden mit dem privaten Geräteschlüssel des Clients verschlüsselt. Dieser private Schlüssel wird erstellt, wenn ein Benutzer auf dem Gerät den Azure Rights Management-Dienst zum ersten Mal verwendet. Dieser private Schlüssel wird wiederum mit DPAPI auf dem Client verschlüsselt, wodurch diese Geheimnisse mithilfe eines Schlüssels geschützt werden, der aus dem Kennwort des Benutzers abgeleitet wird. Auf mobilen Geräten werden die Schlüssel nur einmal verwendet. Da sie also nicht auf den Clients gespeichert sind, müssen diese Schlüssel nicht auf dem Gerät verschlüsselt werden.

Exemplarische Vorgehensweise zur Funktionsweise des Diensts: Erste Verwendung, Inhaltsverschlüsselung, Inhaltsnutzung

Um genauer zu verstehen, wie der Azure Rights Management-Dienst funktioniert, sehen wir uns einen typischen Ablauf durch, nachdem der Azure Rights Management-Dienst aktiviert wurde und wenn ein Benutzer den Rights Management-Dienst zum ersten Mal von seinem Windows-Computer aus verwendet (ein Prozess, der manchmal als Initialisieren der Benutzerumgebung oder Bootstrapping bezeichnet wird), Inhalte ( ein Dokument oder eine E-Mail) verschlüsselt. und nutzt dann Inhalte, die von einer anderen Person verschlüsselt wurden, (öffnet und verwendet).

Nachdem die Benutzerumgebung initialisiert wurde, kann dieser Benutzer Dokumente verschlüsseln oder verschlüsselte Dokumente auf diesem Computer nutzen.

Initialisieren der Benutzerumgebung

Bevor ein Benutzer Inhalte verschlüsseln oder verschlüsselte Inhalte auf einem Windows-Computer nutzen kann, muss die Benutzerumgebung auf dem Gerät vorbereitet werden. Dies ist ein einmaliger Prozess, der automatisch ohne Benutzereingriff erfolgt, wenn ein Benutzer versucht, verschlüsselte Inhalte zu verschlüsseln oder zu nutzen:

Was geschieht in Schritt 1: Der Client für den Azure Rights Management-Dienst, der auf dem Computer ausgeführt wird, stellt zuerst eine Verbindung mit dem Dienst her, und der Dienst authentifiziert den Benutzer mithilfe seines Microsoft Entra-Kontos.

Wenn das Konto des Benutzers mit Microsoft Entra-ID verbunden ist, erfolgt diese Authentifizierung automatisch, und der Benutzer wird nicht zur Eingabe von Anmeldeinformationen aufgefordert.

Was in Schritt 2 geschieht: Nachdem der Benutzer authentifiziert wurde, wird die Verbindung automatisch an den Mandanten des organization umgeleitet, der Zertifikate ausstellt, mit denen sich der Benutzer beim Azure Rights Management-Dienst authentifizieren kann, um verschlüsselte Inhalte zu nutzen und Inhalte offline zu verschlüsseln.

Eines dieser Zertifikate ist das Berechtigungskontozertifikat, das häufig als RAC abgekürzt wird. Dieses Zertifikat authentifiziert den Benutzer bei Microsoft Entra ID und ist 31 Tage gültig. Das Zertifikat wird vom Client automatisch erneuert, vorausgesetzt, das Benutzerkonto befindet sich noch in Microsoft Entra ID und ist aktiviert. Dieses Zertifikat kann nicht von einem Administrator konfiguriert werden.

Eine Kopie dieses Zertifikats wird in Azure gespeichert, sodass die Zertifikate mit denselben Schlüsseln erstellt werden, wenn der Benutzer zu einem anderen Gerät wechselt.

Inhaltsverschlüsselung

Wenn ein Benutzer ein Dokument verschlüsselt, führt der Client für den Azure Rights Management-Dienst die folgenden Aktionen für ein unverschlüsseltes Dokument aus:

Was geschieht in Schritt 1: Der Client erstellt einen zufälligen Schlüssel (den Inhaltsschlüssel) und verschlüsselt das Dokument mithilfe dieses Schlüssels mit dem symmetrischen AES-Verschlüsselungsalgorithmus.

Was in Schritt 2 geschieht: Der Client erstellt dann ein Zertifikat, das eine Richtlinie für das Dokument enthält, die die Nutzungsrechte für Benutzer oder Gruppen sowie andere Einschränkungen wie ein Ablaufdatum enthält. Diese Einstellungen können mit Verschlüsselungseinstellungen für Vertraulichkeitsbezeichnungen definiert werden, die ein Administrator zuvor konfiguriert oder zum Zeitpunkt der Inhaltsverschlüsselung angegeben hat (manchmal auch als "benutzerdefinierte Berechtigungen" oder "Ad-hoc-Richtlinie" bezeichnet).

Das haupt Microsoft Entra Attribut, das zum Identifizieren der ausgewählten Benutzer und Gruppen verwendet wird, ist das attribut Microsoft Entra ProxyAddresses, das alle E-Mail-Adressen für einen Benutzer oder eine Gruppe speichert. Wenn ein Benutzerkonto jedoch keine Werte im AD ProxyAddresses-Attribut enthält, wird stattdessen der UserPrincipalName-Wert des Benutzers verwendet.

Der Client verwendet dann den Schlüssel des organization, der bei der Initialisierung der Benutzerumgebung abgerufen wurde, und verwendet diesen Schlüssel, um die Richtlinie und den symmetrischen Inhaltsschlüssel zu verschlüsseln. Der Client signiert die Richtlinie auch mit dem Zertifikat des Benutzers, das beim Initialisieren der Benutzerumgebung abgerufen wurde.

Was in Schritt 3 passiert: Schließlich bettet der Client die Richtlinie in eine Datei mit dem Textkörper des zuvor verschlüsselten Dokuments ein, die zusammen ein verschlüsseltes Dokument bilden.

Dieses Dokument kann an einer beliebigen Stelle gespeichert oder mit einer beliebigen Methode freigegeben werden, und die Richtlinie bleibt immer für das verschlüsselte Dokument erhalten.

Inhaltsnutzung

Wenn ein Benutzer ein verschlüsseltes Dokument nutzen möchte, fordert der Client zunächst Zugriff auf den Azure Rights Management-Dienst an:

Was geschieht in Schritt 1: Der authentifizierte Benutzer sendet die Dokumentrichtlinie und die Zertifikate des Benutzers an den Azure Rights Management-Dienst. Der Dienst entschlüsselt und wertet die Richtlinie aus und erstellt eine Liste der Rechte (falls vorhanden), über die der Benutzer für das Dokument verfügt. Um den Benutzer zu identifizieren, wird das Microsoft Entra ProxyAddresses-Attribut für das Konto und die Gruppen des Benutzers verwendet, in denen der Benutzer Mitglied ist. Aus Leistungsgründen wird die Gruppenmitgliedschaft zwischengespeichert. Wenn das Benutzerkonto keine Werte für das Microsoft Entra ProxyAddresses-Attribut aufweist, wird stattdessen der Wert im Microsoft Entra UserPrincipalName verwendet.

Was geschieht in Schritt 2: Der Dienst extrahiert dann den AES-Inhaltsschlüssel aus der entschlüsselten Richtlinie. Dieser Schlüssel wird dann mit dem öffentlichen RSA-Schlüssel des Benutzers verschlüsselt, der mit der Anforderung abgerufen wurde.

Der neu verschlüsselte Inhaltsschlüssel wird dann in eine verschlüsselte Nutzungslizenz mit der Liste der Benutzerrechte eingebettet, die dann an den Client zurückgegeben wird.

Was geschieht in Schritt 3: Schließlich verwendet der Client die verschlüsselte Nutzungslizenz und entschlüsselt sie mit seinem eigenen privaten Benutzerschlüssel. Dadurch kann der Client den Text des Dokuments nach Bedarf entschlüsseln und auf dem Bildschirm rendern.

Der Client entschlüsselt auch die Rechteliste und übergibt sie an die Anwendung, die diese Rechte in der Benutzeroberfläche der Anwendung erzwingt.

Variationen

In den vorherigen exemplarischen Vorgehensweisen werden die Standardszenarien behandelt, es gibt jedoch einige Variationen:

• Email Verschlüsselung: Wenn Exchange Online und Microsoft Purview-Nachrichtenverschlüsselung verwendet wird, um E-Mail-Nachrichten zu verschlüsseln, kann die Authentifizierung für die Nutzung auch den Verbund mit einem Identitätsanbieter für soziale Netzwerke oder mithilfe einer Einmalkennung verwenden. Dann sind die Prozessabläufe sehr ähnlich, mit der Ausnahme, dass die Inhaltsnutzung dienstseitig in einer Webbrowsersitzung über eine vorübergehend zwischengespeicherte Kopie der ausgehenden E-Mail erfolgt.

• Mobile Geräte: Wenn mobile Geräte Dateien mit dem Azure Rights Management-Dienst verschlüsseln oder nutzen, sind die Prozessabläufe einfacher. Mobile Geräte durchlaufen nicht zuerst den Benutzerinitialisierungsprozess, da stattdessen jede Transaktion (zum Verschlüsseln oder Nutzen von Inhalten) unabhängig ist. Wie bei Windows-Computern stellen mobile Geräte eine Verbindung mit dem Azure Rights Management-Dienst her und authentifizieren sich. Zum Verschlüsseln von Inhalten übermitteln mobile Geräte eine Richtlinie, und der Azure Rights Management-Dienst sendet ihnen eine Veröffentlichungslizenz und einen symmetrischen Schlüssel, um das Dokument zu verschlüsseln. Wenn mobile Geräte eine Verbindung mit dem Azure Rights Management-Dienst herstellen und sich authentifizieren, senden sie die Dokumentrichtlinie an den Azure Rights Management-Dienst und fordern eine Nutzungslizenz für die Nutzung des Dokuments an, um verschlüsselte Inhalte zu nutzen. Als Reaktion sendet der Azure Rights Management-Dienst die erforderlichen Schlüssel und Einschränkungen an die mobilen Geräte. Beide Prozesse verwenden TLS, um den Schlüsselaustausch und andere Kommunikationen zu schützen.

• Rights Management-Connector: Wenn der Azure Rights Management-Dienst mit dem Rights Management-Connector verwendet wird, bleiben die Prozessabläufe unverändert. Der einzige Unterschied besteht darin, dass der Connector als Relay zwischen den lokalen Diensten (z. B. Exchange Server und SharePoint Server) und dem Azure Rights Management-Dienst fungiert. Der Connector selbst führt keine Vorgänge aus, z. B. die Initialisierung der Benutzerumgebung oder die Verschlüsselung oder Entschlüsselung. Es leitet einfach die Kommunikation weiter, die normalerweise an einen AD RMS-Server gehen würde, und verarbeitet die Übersetzung zwischen den protokollen, die auf jeder Seite verwendet werden. In diesem Szenario können Sie den Azure Rights Management-Dienst mit lokalen Diensten verwenden.

• Generische Verschlüsselung (PFILE): Wenn der Azure Rights Management-Dienst eine Datei generisch verschlüsselt, ist der Ablauf für die Inhaltsverschlüsselung grundsätzlich identisch, mit der Ausnahme, dass der Client eine Richtlinie erstellt, die alle Rechte gewährt. Wenn die Datei genutzt wird, wird sie entschlüsselt, bevor sie an die Zielanwendung übergeben wird. In diesem Szenario können Sie alle Dateien verschlüsseln, auch wenn sie den Azure Rights Management-Dienst nicht nativ unterstützen.

• Microsoft-Konten: Der Azure Rights Management-Dienst kann E-Mail-Adressen für die Nutzung autorisieren, wenn sie mit einem Microsoft-Konto authentifiziert werden. Allerdings können nicht alle Anwendungen verschlüsselte Inhalte öffnen, wenn ein Microsoft-Konto für die Authentifizierung verwendet wird. Weitere Informationen.

Nächste Schritte

Eine weniger technische Übersicht über den Azure Rights Management-Dienst finden Sie unter Informationen zum Azure Rights Management-Dienst.

Wenn Sie bereit für die Bereitstellung empfohlener Schritte sind, die Verschlüsselung zum Schutz Ihrer Daten umfassen, finden Sie weitere Informationen unter Bereitstellen einer Informationsschutzlösung mit Microsoft Purview.