Protokollierung und Analyse der Schutznutzung von Azure Information Protection

Artikel
10/18/2023

Hinweis

Suchen Sie nach Microsoft Purview Information Protection, ehemals Microsoft Information Protection (MIP)?

Das Azure Information Protection-Add-In wird eingestellt und durch Bezeichnungen ersetzt, die in Ihre Microsoft 365-Apps und -Dienste integriert sind. Erfahren Sie mehr über den Supportstatus anderer Azure Information Protection-Komponenten.

Der neue Microsoft Information Protection-Client (ohne das Add-In) befindet sich derzeit in der Vorschau und ist für die allgemeine Verfügbarkeit geplant.

Verwenden Sie diese Informationen, um zu verstehen, wie Sie die Nutzungsprotokollierung für den Schutzdienst (Azure Rights Management) von Azure Information Protection verwenden können. Dieser Schutzdienst bietet den Datenschutz für die Dokumente und E-Mails Ihres Unternehmens und kann jede Anfrage an ihn protokollieren. Diese Anforderungen umfassen, wann Benutzer Dokumente und E-Mails schützen, wann sie diese Inhalte nutzen, Aktionen, die von Ihren Administratoren für diesen Dienst ausgeführt werden, und Aktionen, die von Microsoft-Operatoren ausgeführt werden, um Ihre Azure Information Protection-Bereitstellung zu unterstützen.

Sie können diese Schutzverwendungsprotokolle dann zur Unterstützung der folgenden Geschäftsszenarien verwenden:

Analysieren von Geschäftseinblicken

Die vom Schutzdienst generierten Protokolle können in ein Repository Ihrer Wahl importiert werden (z. B. eine Datenbank, ein OLAP-System (Online Analytical Processing) oder ein Zuordnen/Reduzieren-System), um die Informationen zu analysieren und Berichte zu erstellen. Als Beispiel könnten Sie identifizieren, wer auf Ihre geschützten Daten zugreift. Sie können bestimmen, auf welche geschützten Daten Personen zugreifen, und von welchen Geräten und von wo aus. Sie können herausfinden, ob Personen geschützte Inhalte erfolgreich lesen können. Sie können auch ermitteln, welche Personen ein wichtiges Dokument gelesen haben, das geschützt wurde.
Überwachen auf Missbrauch

Logging-Informationen über die Nutzung des Schutzes stehen Ihnen nahezu in Echtzeit zur Verfügung, so dass Sie die Nutzung des Schutzdienstes durch Ihr Unternehmen kontinuierlich überwachen können. 99,9 % der Protokolle sind innerhalb von 15 Minuten nach einer initiierten Aktion für den Dienst verfügbar.

Sie können beispielsweise benachrichtigt werden, wenn plötzlich mehr Personen geschützte Daten außerhalb der Standardarbeitszeit lesen, was darauf hindeutet, dass ein böswilliger Benutzer Informationen sammelt, um an Wettbewerber zu verkaufen. Oder, wenn derselbe Benutzer scheinbar innerhalb eines kurzen Zeitraums auf Daten aus zwei verschiedenen IP-Adressen zugreift, was darauf hindeuten könnte, dass ein Benutzerkonto kompromittiert wurde.
Forensische Analyse durchführen

Wenn Sie über ein Informationsleck verfügen, werden Sie wahrscheinlich gefragt, wer kürzlich auf bestimmte Dokumente zugegriffen hat und auf welche Informationen eine verdächtige Person kürzlich zugegriffen hat. Sie können diese Arten von Fragen beantworten, wenn Sie Protokollierung verwenden, weil Personen, die geschützte Inhalte verwenden, immer eine Rights Management-Lizenz abrufen müssen, um Dokumente und Bilder zu öffnen, die mit Azure Information Protection geschützt sind. Das gilt auch dann, wenn diese Dateien per E-Mail verschoben oder auf USB-Laufwerke oder andere Speichergeräte kopiert werden. Das bedeutet, dass Sie diese Protokolle als endgültige Informationsquelle für forensische Analysen nutzen können, wenn Sie Ihre Daten mit Azure Information Protection schützen.

Zusätzlich zu dieser Verwendungsprotokollierung haben Sie auch die folgenden Protokollierungsoptionen:

Protokollierungsoption	Beschreibung
Administratorprotokoll	Protokolliert administrative Aufgaben für den Schutzdienst. Wenn der Dienst beispielsweise deaktiviert wird, wenn das Superbenutzerfeature aktiviert ist und Benutzer Administratorberechtigungen für den Dienst delegiert werden. Weitere Informationen finden Sie im PowerShell-Cmdlet, Get-AipServiceAdminLog.
Dokumentkontrolle	Dokumentkontrolle: Ermöglicht Benutzern das Nachverfolgen und Widerrufen ihrer Dokumente, die sie mit dem Azure Information Protection-Client nachverfolgt haben. Globale Administratoren können diese Dokumente auch im Namen von Benutzern nachverfolgen. Weitere Informationen finden Sie unter Konfigurieren und Verwalten von Vorlagen für Azure Information Protection.
Clientereignisprotokolle	Clientereignisprotokolle: Nutzungsaktivität für den Azure Information Protection-Client, protokolliert im lokalen Windows Anwendungs- und Dienstereignisprotokoll, Azure Information Protection. Weitere Informationen finden Sie unter Nutzungsprotokollierung für den Azure Information Protection Scanner.
Protokolldateien des Clients	Problembehandlungsprotokolle für den Azure Information Protection-Client, die sich in %localappdata%\Microsoft\MSIP befinden. Diese Dateien sind für Microsoft-Support ausgelegt.

Darüber hinaus werden Informationen aus den Azure Information Protection-Clientnutzungsprotokollen und dem Azure Information Protection-Scanner gesammelt und aggregiert, um Berichte im Azure-Portal zu erstellen. Weitere Informationen finden Sie unter Azure Information Protection – Preise.

In den folgenden Abschnitten finden Sie weitere Informationen über die Nutzungsprotokollierung für den Schutzdienst.

So aktivieren Sie die Protokollierung der Schutzverwendung

Die Protokollierung der Schutznutzung ist standardmäßig für alle Kunden aktiviert.

Es gibt keine zusätzlichen Kosten für den Protokollspeicher oder für die Protokollierungsfunktion.

Zugriff auf und Verwendung von Protokollen zur Nutzung Ihres Schutzes

Azure Information Protection schreibt Protokolle als eine Reihe von Blobs in ein Azure-Speicherkonto, das automatisch für Ihren Mandant erstellt wird. Jedes Blob enthält einen oder mehrere Protokolleinträge im erweiterten W3C-Protokollformat. Die Blobnamen sind Zahlen in der Reihenfolge, in der sie erstellt wurden. Der Abschnitt zur Interpretation Ihrer Azure Rights Management-Verwendungsprotokolle weiter unten in diesem Dokument enthält weitere Informationen zu den Protokollinhalten und deren Erstellung.

Es kann einen Moment dauern, bis nach einer Protection-Aktion Protokolle in Ihrem Speicherkonto angezeigt werden. Die meisten Protokolle werden innerhalb von 15 Minuten angezeigt. Verwendungsprotokolle sind nur verfügbar, wenn der Feldname „Datum“ einen Wert eines vorherigen Datums (in UTC-Zeit) enthält. Verwendungsprotokolle aus dem aktuellen Datum sind nicht verfügbar. Es wird empfohlen, die Protokolle in den lokalen Speicher herunterzuladen, z. B. einen lokalen Ordner, eine Datenbank oder ein Zuordnungsrepository.

Um Ihre Nutzungsprotokolle herunterzuladen, verwenden Sie das AIPService PowerShell-Modul für Azure Information Protection. Installationsanweisungen finden Sie unter Installation des AIPService PowerShell-Moduls.

So laden Sie Ihre Verwendungsprotokolle mithilfe von PowerShell herunter

Starten Sie Windows PowerShell mit der Option Als Administrator ausführen und verwenden Sie das Cmdlet Connect-AipService, um eine Verbindung zu Azure Information Protection herzustellen:
```
Connect-AipService
```
Führen Sie den folgenden Befehl aus, um die Protokolle für ein bestimmtes Datum herunterzuladen:
```
Get-AipServiceUserLog -Path <location> -fordate <date>
```
Beispiel: Nach dem Erstellen eines Ordners namens Protokolle auf Ihrem E:-Laufwerk:
- Um Protokolle für ein bestimmtes Datum (z. B. 1.02.2016) herunterzuladen, führen Sie den folgenden Befehl aus: Get-AipServiceUserLog -Path E:\Logs -fordate 2/1/2016
- Führen Sie zum Herunterladen von Protokollen für einen Datumsbereich (z. B. vom 01.02.2016 bis zum 14.02.2016) den folgenden Befehl aus: Get-AipServiceUserLog -Path E:\Logs -fromdate 2/1/2016 –todate 2/14/2016

Wenn Sie den Tag nur angeben, wie in unseren Beispielen, wird davon ausgegangen, dass die Uhrzeit in Ihrer Ortszeit 00:00:00 ist und dann in UTC konvertiert wird. Wenn Sie eine Uhrzeit mit den Parametern -fromdate oder -todate angeben (z. B. -fordate „2.1.2016 15:00:00“), wird dieses Datum und die Uhrzeit in UTC konvertiert. Der Befehl Get-AipServiceUserLog ruft dann die Protokolle für diesen UTC-Zeitraum ab.

Sie können nicht weniger als einen ganzen Tag für den Download angeben.

Standardmäßig verwendet dieses Cmdlet drei Threads, um die Protokolle herunterzuladen. Wenn Sie über ausreichende Netzwerkbandbreite verfügen und die zum Herunterladen der Protokolle erforderliche Zeit verringern möchten, verwenden Sie den Parameter -NumberOfThreads, der einen Wert von 1 bis 32 unterstützt. Wenn Sie beispielsweise den folgenden Befehl ausführen, werden mit dem Cmdlet 10 Threads zum Herunterladen der Protokolle erstellt: Get-AipServiceUserLog -Path E:\Logs -fromdate 2/1/2016 –todate 2/14/2016 -numberofthreads 10

Tipp

Sie können alle heruntergeladenen Protokolldateien in einem CSV-Format aggregieren, indem Sie den Log Parser von Microsoft verwenden. Dabei handelt es sich um ein Tool zum Konvertieren zwischen verschiedenen bekannten Protokollformaten. Sie können dieses Tool auch verwenden, um Daten in das SYSLOG-Format zu konvertieren oder in eine Datenbank zu importieren. Nachdem Sie das Tool installiert haben, führen LogParser.exe /? Sie Hilfe und Informationen zur Verwendung dieses Tools aus.

Sie können beispielsweise den folgenden Befehl ausführen, um alle Informationen in ein PROTOKOLLDATEI-Format zu importieren: logparser –i:w3c –o:csv "SELECT * INTO AllLogs.csv FROM *.log"

So interpretieren Sie Ihre Nutzungsprotokolle

Die folgenden Informationen helfen Ihnen bei der Interpretation der Schutzverwendungsprotokolle.

Die Protokollsequenz

Azure Information Protection schreibt die Protokolle als eine Reihe von Blobs.

Jeder Eintrag im Protokoll weist einen UTC-Zeitstempel auf. Da der Schutzdienst auf mehreren Servern in mehreren Datencentern ausgeführt wird, scheinen die Protokolle manchmal nicht in der richtigen Reihenfolge zu sein, auch wenn sie nach Zeitstempel sortiert sind. Der Unterschied ist jedoch klein und in der Regel innerhalb einer Minute. In den meisten Fällen ist dies kein Problem, das für die Protokollanalyse ein Problem darstellen würde.

Blob-Dateiformat

Jedes Blob befindet sich im erweiterten W3C-Protokollformat. Sie beginnt mit den folgenden beiden Zeilen:

#Software: RMS

#Version: 1.1

In der ersten Zeile wird angegeben, dass es sich um Schutzprotokolle von Azure Information Protection handelt. Die zweite Zeile gibt an, dass der Rest des Blobs der Spezifikation version 1.1 folgt. Es wird empfohlen, alle Anwendungen, die diese Protokolle analysieren, diese beiden Zeilen zu überprüfen, bevor Sie den Rest des Blobs analysieren.

Die dritte Zeile listet eine Liste von Feldnamen auf, die durch Registerkarten getrennt sind:

#Fields: date time row-id request-type user-id result correlation-id content-id owner-email issuer template-id file-name date-published c-info c-ip admin-action acting-as-user

Jede der nachfolgenden Zeilen ist ein Protokolldatensatz. Die Werte der Felder sind in der gleichen Reihenfolge wie die vorhergehende Zeile und werden durch Registerkarten getrennt. Gehen Sie bei den Aufforderungen gemäß der folgenden Tabelle vor:

Feldname	W3C-Datentyp	Beschreibung	Beispielswert
date	Date	UTC-Datum, an dem die Anforderung bereitgestellt wurde. Die Quelle ist die lokale Uhr auf dem Server, der die Anforderung bedient hat.	25.06.2013
time	Zeit	UTC-Zeit im 24-Stunden-Format, als die Anforderung bereitgestellt wurde. Die Quelle ist die lokale Uhr auf dem Server, der die Anforderung bedient hat.	21:59:28
row-id	Text	Eindeutige GUID für diesen Protokolldatensatz. Wenn kein Wert vorhanden ist, verwenden Sie den Korrelations-ID-Wert, um den Eintrag zu identifizieren. Dieser Wert ist nützlich, wenn Sie Protokolle aggregieren oder Protokolle in ein anderes Format kopieren.	1c3fe7a9-d9e0-4654-97b7-14fafa72ea63
request-type	Name	Name der RMS-API, die angefordert wurde.	AcquireLicense
Benutzer-ID	String	Benutzer, von dem die Anmeldeanforderung stammt. Der -Wert wird in einfaches Anführungszeichen (') eingeschlossen. Aufrufe von einem Mandantenschlüssel, der von Ihnen (BYOK) verwaltet wird, haben den Wert ", der auch gilt, wenn die Anforderungstypen anonym sind.	'joe@contoso.com'
result	String	„Erfolg“, wenn die Anforderung erfolgreich war. Der Fehlertyp in einfachen Anführungszeichen, wenn die Anforderung fehlgeschlagen ist.	'Success'
correlation-id	Text	GUID, die zwischen dem RMS-Clientprotokoll und dem Serverprotokoll für eine bestimmte Anforderung üblich ist. Dieser Wert kann hilfreich sein, um clientseitige Probleme zu beheben.	cab52088-8925-4371-be34-4b71a3112356
content-id	Text	GUID, eingeschlossen in geschweifte Klammern, die den geschützten Inhalt (z. B. ein Dokument) identifiziert. Dieses Feld weist nur dann einen Wert auf, wenn der Anforderungstyp AcquireLicense ist und für alle anderen Anforderungstypen leer ist.	{bb4af47b-cfed-4719-831d-71b98191a4f2}
Besitzer-E-Mail	String	Geben Sie die E-Mail-Adresse des neuen Besitzers ein. Dieses Feld ist leer, wenn der Anforderungstyp RevokeAccess lautet.	alice@contoso.com
issuer	String	E-Mail-Adresse des Dokumentausstellers. Dieses Feld ist leer, wenn der Anforderungstyp RevokeAccess lautet.	alice@contoso.com oder FederatedEmail.4c1f4d-93bf-00a95fa1e042@contoso.onmicrosoft.com.
template-id	String	ID der Vorlage, die zum Schutz des Dokuments verwendet wird. Dieses Feld ist leer, wenn der Anforderungstyp RevokeAccess lautet.	{6d9371a6-4e2d-4e97-9a38-202233fed26e}
file-name	String	Dateiname eines geschützten Dokuments, das mithilfe des Azure Information Protection-Clients für Windows nachverfolgt wird. Derzeit werden einige Dateien (z. B. Office-Dokumente) anstelle des tatsächlichen Dateinamens als GUIDs angezeigt. Dieses Feld ist leer, wenn der Anforderungstyp RevokeAccess lautet.	TopSecretDocument.docx
date-published	Datum	Datum, an dem das Dokument geschützt wurde. Dieses Feld ist leer, wenn der Anforderungstyp RevokeAccess lautet.	2015-10-15T21:37:00
c-info	String	Informationen über die Clientplattform, die die Anforderung stellt. Die spezifische Zeichenfolge variiert je nach Anwendung (z. B. Betriebssystem oder Browser).	„MSIPC; version=1.0.623.47; AppName=WINWORD.EXE; AppVersion=15.0.4753.1000; AppArch=x86; OSName=Windows; OSVersion=6.1.7601; OSArch=amd64“
c-ip	Adresse	Die IP-Adresse des Clients, der die Anforderung gestellt hat.	64.51.202.144
Administratoraktion	Bool	Gibt an, ob ein Administrator im Administratormodus auf die Dokumentverfolgungswebsite zugegriffen hat.	True
acting-as-user	String	Die E-Mail-Adresse des Benutzers, für den ein Administrator auf die Dokumentverfolgungswebsite zugreift.	'joe@contoso.com'

Ausnahmen für das Benutzer-ID-Feld

Obwohl das Feld Benutzer-ID in der Regel den Benutzer angibt, der die Anforderung gestellt hat, gibt es zwei Ausnahmen, bei denen der Wert keinem echten Benutzer zugeordnet ist:

Der Wert 'microsoftrmsonline@<YourTenantID.rms>.<region.aadrm.com>'.

Dies zeigt an, dass die Anforderung von einem Office 365-Dienst wie Exchange Online oder Microsoft SharePoint stammt. In der Zeichenfolge steht <YourTenantID> für die GUID Ihres Mandanten und <Region> für die Region, in der Ihr Mandant registriert ist. Na stellt z. B. Nordamerika dar, eu stellt Europa dar und ap stellt Asien dar.
Wenn Sie den RMS-Connector verwenden.

Anforderungen von diesem Connector werden mit dem Dienstprinzipalnamen Aadrm_S-1-7-0 protokolliert, der automatisch generiert wird, wenn Sie den RMS-Connector installieren.

Typische Anforderungstypen

Es gibt viele Anfragetypen für den Schutzdienst, aber in der folgenden Tabelle sind einige der am häufigsten verwendeten Anfragetypen aufgeführt.

Anforderungstyp	Beschreibung
AcquireLicense	Ein Client von einem Windows-basierten Computer fordert eine Lizenz für geschützte Inhalte an.
AcquirePreLicense	Ein Kunde beantragt im Namen eines Nutzers eine Lizenz für geschützte Inhalte.
AcquireTemplates	Es wurde ein Aufruf zum Abrufen von Vorlagenvorlagen basierend auf Vorlagen-IDs durchgeführt.
AcquireTemplateInformation	Es wurde ein Aufruf ausgeführt, um die IDs der Vorlage vom Dienst abzurufen.
AddTemplate	Vom Azure-Portal wird ein Aufruf zum Hinzufügen einer Vorlage ausgelöst.
AllDocsCsv	Ein Aufruf erfolgt über die Dokumentverfolgungswebsite, um die CSV-Datei von der Seite Alle Dokumente herunterzuladen.
BECreateEndUserLicenseV1	Zur Erstellung einer Endbenutzerlizenz wird ein Anruf von einem mobilen Gerät aus getätigt.
BEGetAllTemplatesV1	Von einem mobilen Gerät (Backend) aus wird ein Anruf getätigt, um alle Vorlagen abzurufen.
Certify	Der Kunde zertifiziert den Benutzer für den Verbrauch und die Erstellung geschützter Inhalte.
FECreateEndUserLicenseV1	Ähnlich wie die AcquireLicense-Anforderung, aber von mobilen Geräten.
FECreatePublishingLicenseV1	Identisch mit Zertifizieren und GetClientLicensorCert kombiniert von mobilen Clients.
FEGetAllTemplates	Von einem mobilen Gerät (Frontend) wird ein Anruf getätigt, um die Vorlagen zu erhalten.
FindServiceLocationsForUser	Es wird ein Aufruf ausgeführt, um URLs abzufragen, die zum Aufrufen von Zertifizieren oder AcquireLicense verwendet werden.
GetClientLicensorCert	Der Client fordert ein Veröffentlichungszertifikat (das später zum Schutz von Inhalten verwendet wird) von einem Windows-basierten Computer an.
GetConfiguration	Ein Azure PowerShell-Cmdlet wird aufgerufen, um die Konfiguration des Azure RMS-Mandanten abzurufen.
Get Verbinden orAuthorizations	Die RMS-Konnektoren werden aufgerufen, um ihre Konfiguration aus der Cloud abzurufen.
GetRecipients	Ein Aufruf erfolgt über die Dokumentverfolgungswebsite, um zur Listenansicht für ein einzelnes Dokument zu navigieren.
GetTenantFunctionalState	Das Azure-Portal prüft, ob der Schutzdienst (Azure Rights Management) aktiviert ist.
KeyVaultDecryptRequest	Der Client versucht, den RMS-geschützten Inhalt zu entschlüsseln. Gilt nur für einen vom Kunden verwalteten Mandantenschlüssel (BYOK) in Azure Key Vault.
KeyVaultGetKeyInfoRequest	Es wird ein Aufruf ausgeführt, um zu überprüfen, ob auf den in Azure Key Vault für den Azure Information Protection-Mandantenschlüssel zugegriffen werden soll und nicht bereits verwendet wird.
KeyVaultSignDigest	Ein Aufruf erfolgt, wenn ein vom Kunden verwalteter Schlüssel (BYOK) in Azure Key Vault zu Signierungszwecken verwendet wird. Dies wird in der Regel einmal pro AcquireLicence (oder FECreateEndUserLicenseV1), Zertifizieren und GetClientLicensorCert (oder FECreatePublishingLicenseV1) aufgerufen.
KMSPDecrypt	Der Client versucht, den RMS-geschützten Inhalt zu entschlüsseln. Gilt nur für einen älteren vom Kunden verwalteten Mandantenschlüssel (BYOK).
KMSPSignDigest	Ein Aufruf erfolgt, wenn ein älteren vom Kunden verwalteter Schlüssel (BYOK) für Signaturzwecke verwendet wird. Dies wird in der Regel einmal pro AcquireLicence (oder FECreateEndUserLicenseV1), Zertifizieren und GetClientLicensorCert (oder FECreatePublishingLicenseV1) aufgerufen.
ServerCertify	Von einem RMS-fähigen Client (z. B. SharePoint) wird ein Aufruf zur Zertifizierung des Servers gemacht.
SetUsageLogFeatureState	Es erfolgt ein Aufruf zur Aktivierung der Nutzungsprotokollierung.
SetUsageLogStorageAccount	Es erfolgt ein Aufruf, um den Speicherort der Protokolle des Azure Rights Management-Dienstes anzugeben.
UpdateTemplate	Vom Azure-Portal wird ein Aufruf zum Aktualisieren einer vorhandenen Vorlage ausgelöst.

Schutznutzungsprotokolle und einheitliches Microsoft 365-Überwachungsprotokoll

Dateizugriffs- und verweigerte Ereignisse enthalten derzeit keinen Dateinamen und sind im einheitlichen Microsoft 365-Überwachungsprotokoll nicht zugänglich. Diese Ereignisse werden erweitert, um eigenständig nützlich zu sein und zu einem späteren Zeitpunkt vom Rights Management Service hinzugefügt zu werden.

PowerShell-Referenz

Das einzige PowerShell-Cmdlet, das Sie für den Zugriff auf die Protokollierung der Schutznutzung benötigen, ist Get-AipServiceUserLog.

Weitere Informationen zur Verwendung von PowerShell für Azure Information Protection finden Sie unter Verwalten des Schutzes von Azure Information Protection mit PowerShell.