Funktionsweise von Azure RMS Hinter den Kulissen

Ein wichtiger Aspekt der Funktionsweise von Azure RMS ist, dass dieser Datenschutzdienst von Azure Information Protection Ihre Daten im Rahmen des Schutzprozesses weder sieht noch speichert. Informationen, die Sie schützen, 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. Azure RMS sorgt lediglich dafür, dass die Daten in einem Dokument nur für autorisierte Benutzer und Dienste lesbar sind:

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

• Wenn ein geschütztes Dokument von einem legitimen Benutzer verwendet oder von einem autorisierten Dienst verarbeitet wird, werden die Daten im Dokument entschlüsselt und die Rechte, die in der Richtlinie definiert sind, werden durchgesetzt.

Die folgende Abbildung gibt einen Überblick über die Funktionsweise dieses Prozesses. Ein Dokument, das die geheime Formel enthält, ist geschützt und wird dann von einem autorisierten Benutzer oder Dienst erfolgreich geöffnet. Das Dokument wird durch einen Inhaltsschlüssel (der grüne Schlüssel in der Abbildung) geschützt. Er ist für jedes Dokument eindeutig und wird im Dateiheader gespeichert. Dort ist er durch den Stammschlüssel Ihres Azure Information Protection-Mandanten geschützt (der rote Schlüssel in der 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 Schutzprozesses, bei dem Azure RMS verschlüsselt und entschlüsselt, autorisiert und Einschränkungen durchsetzt, wird die geheime Formel niemals an Azure gesendet.

Eine ausführliche Beschreibung der Funktionsweise finden Sie im Abschnitt Exemplarische Vorgehensweise zur Funktionsweise von Azure RMS: Erste Verwendung, Inhaltsschutz, Inhaltsnutzung in diesem Artikel.

Technische Details zu den Algorithmen und Schlüssellängen, die Azure RMS verwendet, finden Sie im nächsten Abschnitt.

Von Azure RMS verwendete kryptografische Steuerelemente: Algorithmen und Schlüssellängen

Auch wenn Sie die Funktionsweise dieser Technologie nicht im Detail kennen müssen, werden Ihnen möglicherweise Fragen zu den verwendeten kryptografischen Steuerelementen gestellt. Beispielsweise müssen Sie ggf. bestätigen, dass der Sicherheitsschutz dem Branchenstandard entspricht.

Kryptografische Steuerelemente	Verwendung in Azure RMS
Algorithmus: AES Schlüssellänge: 128 Bits und 256 Bits [1]	Inhaltsschutz
Algorithmus: RSA Schlüssellänge: 2048 Bits [2]	Schlüsselschutz
SHA-256	Zertifikatsignierung

Fußnote 1

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

• Generischer Schutz (.pfile).

• Nativer Schutz für PDF-Dokumente, wenn das Dokument mit dem ISO-Standard für die PDF-Verschlüsselung geschützt wurde, oder das resultierende geschützte Dokument hat eine PPDF-Dateinamenerweiterung.

• Systemeigener Schutz für Text- oder Bilddateien (z. B. PTXT oder PJPG).

Fußnote 2

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

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

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

Speichern und Schützen kryptografischer Azure RMS-Schlüssel

Für jedes Dokument oder jede E-Mail, das bzw. die von Azure RMS geschützt wird, erstellt Azure RMS einen einzelnen AES-Schlüssel (den „Inhaltsschlüssel“), und dieser Schlüssel wird in das Dokument eingebettet und bleibt bei allen Editionen des Dokuments erhalten.

Der Inhaltsschlüssel wird mit dem RSA-Schlüssel der Organisation (dem „Azure Information Protection-Mandantenschlüssel“) als Teil der Richtlinie im Dokument geschützt, und die Richtlinie wird auch vom Autor des Dokuments signiert. Dieser Mandantenschlüssel gilt für alle Dokumente und E-Mails, die vom Azure Rights Management-Dienst für die Organisation geschützt werden, und dieser Schlüssel kann von einem Azure Information Protection-Administrator nur geändert werden, wenn die Organisation einen Mandantenschlüssel verwendet, der kundenverwaltet ist (als „Bring-Your-Own-Key“ oder BYOK bezeichnet).

Dieser Mandantenschlüssel wird in den Onlinediensten von Microsoft, in einer umfassend kontrollierten Umgebung und unter enger Beobachtung geschützt. Wenn Sie einen vom Kunden verwalteten Mandantenschlüssel (BYOK) verwenden, wird diese Sicherheit erweitert, indem in jeder Azure-Region ein Array von hochleistungsfähigen Hardwaresicherheitsmodulen (HSMs) verwendet wird, ohne dass irgendeine Möglichkeit besteht, die Schlüssel zu extrahieren, zu exportieren oder freizugeben. Weitere Informationen zum Mandantenschlüssel und BYOK finden Sie unter Planen und Implementieren Ihres Azure Information Protection-Mandantenschlüssels.

Lizenzen und Zertifikate, die an ein Windows-Gerät gesendet werden, sind mit dem privaten Geräteschlüssel des Clients geschützt. Dieser Schlüssel wird erstellt, wenn ein Benutzer das erste Mal Azure RMS auf dem Gerät verwendet. Dieser private Schlüssel wird wiederum mit DPAPI auf dem Client geschützt, die diese geheimen Informationen unter Verwendung eines Schlüssels schützt, der aus dem Kennwort des Benutzers abgeleitet wurde. Auf mobilen Geräten werden die Schlüssel nur ein Mal verwendet, also müssen sie, weil sie nicht auf den Clients gespeichert werden, auf dem jeweiligen Gerät nicht geschützt werden.

Exemplarische Vorgehensweise zur Funktionsweise von Azure RMS: Erste Verwendung, Inhaltsschutz, Inhaltsnutzung

Sehen Sie sich zum besseren Verständnis der Funktionsweise von Azure RMS einen typischen Ablauf an, nachdem der Azure Rights Management-Dienst aktiviert wurde und ein Benutzer den Rights Management-Dienst erstmals auf seinem Windows-Computer verwendet (ein Vorgang, der auch als Initialisierung der Benutzerumgebung oder Bootstrapping bezeichnet wird), Inhalte geschützt werden (ein Dokument oder eine E-Mail) und dann ein Inhalt genutzt (geöffnet und verwendet) wird, der durch eine andere Person geschützt wurde.

Nach der Initialisierung der Benutzerumgebung kann der Benutzer Dokumente schützen oder geschützte Dokumente auf diesem Computer nutzen.

Hinweis

Wenn dieser Benutzer zu einem anderen Windows-Computer wechselt oder ein anderer Benutzer den gleichen Windows-Computer verwendet, wird der Initialisierungsvorgang wiederholt.

Initialisieren der Benutzerumgebung

Bevor ein Benutzer Inhalte schützen oder geschützte Inhalte auf einem Windows-Computer nutzen kann, muss die Benutzerumgebung auf dem Gerät vorbereitet werden. Dies ist ein einmaliger Vorgang. Er geschieht automatisch ohne Benutzereingriff, wenn ein Benutzer versucht, Inhalte zu schützen oder geschützte Inhalte zu nutzen:

Ablauf in Schritt 1: Der RMS-Client auf dem Computer stellt zunächst eine Verbindung mit dem Azure Rights Management-Dienst her und authentifiziert den Benutzer mithilfe seines Azure Active Directory-Kontos.

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

Ablauf in Schritt 2: Nachdem der Benutzer authentifiziert wurde, wird die Verbindung automatisch an den Azure Information Protection-Mandanten der Organisation umgeleitet, der Zertifikate ausstellt, mit denen sich der Benutzer beim Azure Rights Management-Dienst authentifiziert, um geschützte Inhalte zu nutzen und Inhalte offline zu schützen.

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

Eine Kopie des Zertifikats des Benutzers wird in Azure gespeichert, damit die Zertifikate mithilfe der gleichen Schlüsseln erstellt werden, wenn der Benutzer ein anderes Gerät verwendet.

Inhaltsschutz

Wenn ein Benutzer ein Dokument schützt, führt der RMS-Client die folgenden Aktionen für ein ungeschütztes Dokument aus:

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

Ablauf in Schritt 2: Der RMS-Client erstellt dann ein Zertifikat, das eine Richtlinie für das Dokument enthält, das die Benutzerrechte für Benutzer oder Gruppen einschließt sowie andere Einschränkungen, z. B. ein Ablaufdatum. Diese Einstellungen können in einer zuvor von einem Administrator konfigurierten Vorlage definiert oder zu dem Zeitpunkt angegeben werden, zu dem der Inhalt geschützt wird (Letzteres wird zuweilen auch als „Ad-hoc-Richtlinie“ bezeichnet).

Das Microsoft Entra ID-Attribut, das hauptsächlich verwendet wird, um die ausgewählten Benutzer und Gruppen zu identifizieren, ist das Attribut Microsoft Entra ID ProxyAddresses, das alle E-Mail-Adressen für einen Benutzer oder eine Gruppe speichert. Wenn ein Benutzerkonto jedoch keine Werte im Attribut „Azure AD ProxyAddresses“ enthält, wird stattdessen der „UserPrincipalName“-Wert des Benutzers verwendet.

Der RMS-Client verwendet dann den Schlüssel der Organisation, der beim Initialisieren der Benutzerumgebung abgerufen wurde, zum Verschlüsseln der Richtlinie und des symmetrischen Inhaltsschlüssels. Der RMS-Client signiert die Richtlinie außerdem mit dem Zertifikat des Benutzers, das beim Initialisieren der Benutzerumgebung abgerufen wurde.

Ablauf in Schritt 3: Schließlich bettet der RMS-Client die Richtlinie in eine Datei mit dem Text des zuvor verschlüsselten Dokuments ein. Zusammen ergibt dies ein geschütztes Dokument.

Dieses Dokument kann an einem beliebigen Ort gespeichert oder mithilfe einer beliebigen Methode freigegeben werden. Die Richtlinie verbleibt immer im verschlüsselten Dokument.

Inhaltsnutzung

Wenn ein Benutzer ein geschütztes Dokument nutzen möchte, fordert der RMS-Client im ersten Schritt Zugriff auf den Azure Rights Management-Dienst an:

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

Ablauf 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 erneut verschlüsselte Inhaltsschlüssel wird dann in eine verschlüsselte Nutzungslizenz mit der Liste der Benutzerrechte eingebettet, die dann an den RMS-Client zurückgegeben wird.

Ablauf in Schritt 3: Schließlich verwendet der RMS-Client die verschlüsselte Nutzungslizenz und entschlüsselt diese mit dem privaten Schlüssel seines eigenen Benutzers. Auf diese Weise kann der RMS-Client den Text des Dokuments nach Bedarf entschlüsseln und auf dem Bildschirm darstellen.

Der Client entschlüsselt außerdem die Rechteliste und übergibt sie an die Anwendung, die diese Rechte in der Benutzeroberfläche der Anwendung durchsetzt.

Hinweis

Wenn Benutzer, die sich außerhalb Ihrer Organisation befinden, von Ihnen geschützten Inhalt nutzen, bleibt der Nutzungsfluss derselbe. Es ändert sich in diesem Szenario nur die Art und Weise, wie der Benutzer authentifiziert wird. Weitere Informationen finden Sie unter Wenn ich ein geschütztes Dokument mit jemandem außerhalb meines Unternehmens teile, wie wird dieser Benutzer authentifiziert?

Abweichungen

Die vorherigen exemplarischen Vorgehensweisen beschreiben die Standardszenarien. Es gibt jedoch einige Variationen:

• E-Mail-Schutz: Wenn die Exchange Online- und Office 365-Nachrichtenverschlüsselung mit neuen Funktionen zum Schutz von E-Mail-Nachrichten verwendet wird, kann die Authentifizierung für den Verbrauch auch einen Partnerverbund mit einem Anbieter für soziale Netzwerke oder mithilfe einer einmaligen Kennung verwenden. Anschließend sind die Prozessflüsse sehr ähnlich, mit der Ausnahme, dass die Inhaltsnutzung in einer Webbrowsersitzung über eine vorübergehend zwischengespeicherte Kopie der ausgehenden E-Mail dienstseitig erfolgt.

• Mobile Geräte: Wenn mobile Geräte Dateien mit dem Azure Rights Management-Dienst schützen oder nutzen, sind die Prozessabläufe wesentlich einfacher. Mobile Geräte durchlaufen nicht zuerst den Initialisierungsprozess, da stattdessen jede Transaktion (zum Schützen oder Nutzen von Inhalten) unabhängig ist. Ebenso wie Windows-Computer stellen mobile Geräte eine Verbindung mit dem Azure Rights Management-Dienst her und authentifizieren sich. Zum Schützen von Inhalten übermitteln mobile Geräte eine Richtlinie, und der Azure Rights Management-Dienst sendet ihnen eine Veröffentlichungslizenz und einen symmetrischen Schlüssel zum Schützen des Dokuments. Zum Nutzen von Inhalten senden mobile Geräte die Dokumentrichtlinie an den Azure Rights Management-Dienst und fordern eine Nutzungslizenz an, um das Dokument zu nutzen, wenn sie eine Verbindung mit dem Azure Rights Management-Dienst herstellen und sich authentifizieren. Als Antwort sendet der Azure Rights Management-Dienst die erforderlichen Schlüssel und Einschränkungen an das mobile Gerät. Beide Prozesse verwenden TLS, um den Schlüsselaustausch und andere Kommunikation zu schützen.

• RMS-Connector: Wenn der Azure Rights Management-Dienst mit dem RMS-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 Ver- und Entschlüsselung. Er leitet lediglich die Kommunikation weiter, die normalerweise an einen AD RMS-Server gehen würde, und verarbeitet die Übersetzung zwischen den Protokollen, die auf beiden Seiten verwendet werden. In diesem Szenario können Sie den Azure Rights Management-Dienst mit lokalen Diensten verwenden.

• Generischer Schutz (PFILE): Wenn der Azure Rights Management-Dienst eine Datei generisch schützt, ist der Ablauf beim Inhaltsschutz grundsätzlich identisch, jedoch mit der Ausnahme, dass der RMS-Client eine Richtlinie erstellt, die alle Rechte gewährt. Bei Nutzung der Datei wird sie entschlüsselt, bevor sie an die Zielanwendung übergeben wird. In diesem Szenario können Sie alle Dateien selbst dann schützen, wenn sie keine systemeigene Unterstützung für RMS besitzen.

• Microsoft-Konten: Azure Information Protection kann E-Mail-Adressen für den Verbrauch autorisieren, wenn sie mit einem Microsoft-Konto authentifiziert werden. Nicht alle Anwendungen können geschützte Inhalte öffnen, wenn ein Microsoft-Konto zur Authentifizierung verwendet wird. Weitere Informationen.

Nächste Schritte

Wenn Sie weitere Informationen zum Azure Rights Management-Dienst benötigen, lesen Sie die anderen Artikel im Abschnitt Verstehen und Kennenlernen, z. B. Unterstützung des Azure Rights Management-Diensts durch Anwendungen, um zu erfahren, wie Ihre vorhandenen Anwendungen zur Bereitstellung einer Datenschutzlösung in Azure Rights Management integriert werden können.

Lesen Sie Terminologie für Azure Information Protection, um sich mit den Begriffen vertraut zu machen, auf die Sie möglicherweise stoßen werden, wenn Sie den Azure Rights Management-Dienst konfigurieren und verwenden. Außerdem sollten Sie unbedingt Anforderungen an Azure Information Protection lesen, bevor Sie mit der Bereitstellung beginnen. Wenn Sie gleich loslegen und es selbst ausprobieren möchten, nutzen Sie den Schnellstart und die Tutorials:

• Schnellstart: Bereitstellen des Clients für einheitliche Bezeichnungen
• Tutorial: Installieren des AIP-Scanners (Azure Information Protection) für einheitliche Bezeichnungen
• Tutorial: Suchen nach vertraulichen Inhalten mit dem AIP-Scanner (Azure Information Protection)
• Tutorial: Verhindern übermäßiger Freigaben in Outlook mithilfe von Azure Information Protection (AIP)

Wenn Sie bereit sind, mit dem Datenschutz für Ihr Unternehmen zu beginnen, verwenden Sie die AIP-Roadmap für Klassifizierung, Bezeichnung und Schutz für Ihre Implementierungsschritte und Links für Anleitungen.