Microsoft Purview Information Protection
Microsoft Purview Information Protection
Grundlagen der DKE-Verschlüsselung und -Entschlüsselung verstehen
Grundlage: MPIP / Azure RMS
Das Verständnis des standardmäßigen MPIP/Azure-RMS-Workflows ist unerlässlich, bevor Sie sich mit den DKE-Besonderheiten befassen, da DKE auf dieser Grundlage aufbaut.
Kernfunktionalität
MPIP ist im Grunde eine clientseitige Verschlüsselungstechnologie, die die Schlüsselverwaltung für Endbenutzer automatisiert und den Schutz im Vergleich zur klassischen PKI vereinfacht. Sie stützt sich stark auf Microsoft Entra ID für die Benutzeridentität (unter Verwendung von E-Mail-Adressen oder User Principal Names), um die Autorisierung zu steuern.
Über die Verschlüsselung hinaus erzwingt sie Nutzungsbeschränkungen (Rechte) – etwa das Verhindern des Druckens, das Einschränken der Bearbeitung oder das Festlegen von Ablaufdaten – die vom Autor oder durch zentrale Richtlinien (z. B. Vertraulichkeitsbezeichnungen) definiert werden.
Schlüsselkonzept: Diese Rechte begleiten die verschlüsselte Datei.
Schlüsselkonzepte & Komponenten
| Komponente | Beschreibung |
|---|---|
| Microsoft Entra ID | Stellt Identitätsdienste und Mandantenisolierung bereit. Benutzer-/Gruppenidentitäten steuern die Autorisierung. |
| Purview Information Protection Service | Cloud-Dienst zur Verwaltung von Vertraulichkeitsbezeichnungen und Schutzeinstellungen |
| Azure Rights Management (Azure RMS) | Zentraler Cloud-Dienst, der die kryptografischen Schlüssel des Mandanten hält und Anfragen verarbeitet |
| Clients | Anwendungen auf Benutzergeräten oder autorisierte Cloud-Dienstinstanzen, die mit geschützten Inhalten interagieren |
| DKE Web Service | Kundengesteuerte Komponente für Double Key Encryption (separat behandelt) |
Standard-Verschlüsselungsprozess (MPIP/Azure RMS)
Dies beschreibt, wie Inhalte ohne DKE ausschließlich mit dem von Microsoft verwalteten Schlüssel geschützt werden:
Anwendung der Bezeichnung
Ein Benutzer wendet in einer RMS-fähigen Anwendung (z. B. Word) eine für die Verschlüsselung konfigurierte Vertraulichkeitsbezeichnung an.
Generierung des Content Key
Die Anwendung generiert im Arbeitsspeicher einen eindeutigen symmetrischen AES-Schlüssel (Content Key) für dieses spezifische Dokument (gebunden an dessen documentID).
Dateiverschlüsselung
Die Anwendung verschlüsselt den Inhaltsdatenstrom des Dokuments mit diesem eindeutigen Content Key.
Erstellung der Publishing License (PL)
Die Anwendung erstellt eine Publishing License (PL). Diese XML-Struktur enthält den Content Key, die durch die Bezeichnung oder den Autor definierten Nutzungsrechte/Berechtigungen sowie weitere Metadaten.
Verschlüsselung & Einbettung der PL
Die Anwendung verschlüsselt die sensiblen Teile der PL (am wichtigsten den Content Key) mit dem öffentlichen Schlüssel des Azure-RMS-Mandanten (abgerufen und aus dem Azure-RMS-Dienst zwischengespeichert). Die verschlüsselte PL wird dann in die Dateistruktur des Dokuments eingebettet.
Die Schritte 2–4 finden lokal im Arbeitsspeicher der Anwendung statt.
Einige Metadaten innerhalb der PL, wie die URL des Azure-RMS-Dienstes des Mandanten, bleiben unverschlüsselt, damit Clients den richtigen Dienst finden können.
Standard-Entschlüsselungsprozess (MPIP/Azure RMS)
Dies beschreibt, wie autorisierte Benutzer oder Dienste auf ohne DKE geschützte Inhalte zugreifen:
Öffnungsversuch & Dienstermittlung
Ein Benutzer öffnet das geschützte Dokument in einer RMS-fähigen Anwendung. Die Anwendung liest die Azure-RMS-Dienst-URL aus dem unverschlüsselten Teil der PL.
Authentifizierung & GIC
Der Benutzer authentifiziert sich beim Azure-RMS-Dienst über Microsoft Entra ID. Bei der ersten Interaktion des Benutzers mit RMS stellt der Dienst ein benutzerspezifisches RSA-Schlüsselpaar bereit (Global Identity Certificate (GIC)). Der private GIC-Schlüssel wird sicher im lokalen Profil des Benutzers gespeichert; der öffentliche Schlüssel ist RMS bekannt.
Lizenzanforderung
Die Anwendung sendet die verschlüsselte PL (nicht die vollständige Datei) und einen Identitätsnachweis des Benutzers (einschließlich seines öffentlichen GIC-Schlüssels) an den in Schritt 1 ermittelten Azure-RMS-Dienst.
Autorisierungsprüfung
Azure RMS validiert die Identität des Benutzers anhand der in der PL definierten Berechtigungen und prüft dabei möglicherweise Microsoft-Entra-ID-Gruppenmitgliedschaften oder andere Attribute. Es ermittelt die effektiven Rechte des Benutzers für dieses spezifische Dokument (Berechtigungen sind additiv, wenn sie über mehrere Gruppen gewährt werden).
Ausstellung der Use License (UL/EUL)
Falls autorisiert, verwendet Azure RMS seinen privaten Mandantenschlüssel, um den Content Key aus der PL zu entschlüsseln. Anschließend erstellt es eine End User License (EUL), auch als Use License bekannt. Die EUL enthält den entschlüsselten Content Key und die spezifischen effektiven Berechtigungen des Benutzers. Diese EUL wird dann mit dem öffentlichen GIC-Schlüssel des Benutzers verschlüsselt.
Inhaltsentschlüsselung & Durchsetzung
Die Anwendung empfängt die verschlüsselte EUL. Sie verwendet den privaten GIC-Schlüssel des Benutzers (lokal gespeichert), um die EUL zu entschlüsseln und so den Content Key abzurufen. Die Anwendung verwendet dann den Content Key, um den eigentlichen Dokumentinhalt zu entschlüsseln, und setzt gleichzeitig die in der EUL angegebenen Berechtigungen durch (z. B. das Anzeigen erlauben, aber das Drucken oder Kopieren deaktivieren).
Hinweis zum Dienstzugriff
Autorisierte Cloud-Dienste
Dieser RMS-Ablauf ist nicht auf Endbenutzeranwendungen beschränkt. Autorisierte Cloud-Dienste können ebenfalls als RMS-Clients fungieren:
Exchange Online
Transportregeln
DLP-Dienste
Data Loss Prevention
eDiscovery
Microsoft Purview
Microsoft Copilot
KI-Dienste
Sie authentifizieren sich bei Azure RMS, erhalten – falls zulässig – eine Use License und entschlüsseln Inhalte, um ihre Funktionen auf den Klartextdaten auszuführen.
Wichtig – dies gilt nicht für DKE-geschützte Inhalte. Da DKE den vom Kunden gehaltenen zweiten Schlüssel erfordert, können Microsoft-Cloud-Dienste (einschließlich Copilot, Inhaltssuche, eDiscovery und Office-Web-Apps) DKE-geschützte Inhalte nicht entschlüsseln oder darauf zugreifen. Das oben beschriebene Verhalten gilt nur für standardmäßige Azure-RMS-/Vertraulichkeitsbezeichnungs-Inhalte.