Protokollierung und Analyse der Schutznutzung von Azure Information Protection
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 Microsoft Purview Information Protection-Client (ohne das Add-In) ist allgemein verfügbar.
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-AipServiceFü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/2016Fü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.