Logga och analysera skyddsanvändningen från Azure Information Protection
Kommentar
Letar du efter Microsoft Purview Information Protection, tidigare Microsoft Information Protection (MIP)?
Azure Information Protection-tillägget dras tillbaka och ersätts med etiketter som är inbyggda i dina Microsoft 365-appar och -tjänster. Läs mer om supportstatus för andra Azure Information Protection-komponenter.
Microsoft Purview Information Protection-klienten (utan tillägget) är allmänt tillgänglig.
Lär dig hur du kan använda användningsloggning för skyddstjänsten (Azure Rights Management) från Azure Information Protection. Den här skyddstjänsten tillhandahåller dataskydd för organisationens dokument och e-postmeddelanden och kan logga varje begäran till den. Dessa begäranden omfattar när användare skyddar dokument och e-post och även använder det här innehållet, åtgärder som utförs av dina administratörer för den här tjänsten och åtgärder som utförs av Microsoft-operatörer för att stödja din Azure Information Protection-distribution.
Du kan sedan använda dessa användningsloggar för skydd för att stödja följande affärsscenarier:
Analysera för affärsinsikter
Loggarna som genereras av skyddstjänsten kan importeras till valfri lagringsplats (till exempel en databas, ett OLAP-system (Online Analytical Processing) eller ett map-reduce-system) för att analysera informationen och skapa rapporter. Du kan till exempel identifiera vem som har åtkomst till dina skyddade data. Du kan avgöra vilka skyddade data som personer har åtkomst till och från vilka enheter och varifrån. Du kan ta reda på om personer kan läsa skyddat innehåll. Du kan också identifiera vilka personer som har läst ett viktigt dokument som har skyddats.
Övervaka missbruk
Loggningsinformation om skyddsanvändningen är tillgänglig för dig nästan i realtid, så att du kontinuerligt kan övervaka företagets användning av skyddstjänsten. 99,9 % av loggarna är tillgängliga inom 15 minuter efter en initierad åtgärd för tjänsten.
Du kanske till exempel vill bli aviserad om det sker en plötslig ökning av personer som läser skyddade data utanför standardarbetstid, vilket kan tyda på att en obehörig användare samlar in information för att sälja till konkurrenter. Eller om samma användare tydligen kommer åt data från två olika IP-adresser inom en kort tidsperiod, vilket kan tyda på att ett användarkonto har komprometterats.
Utföra kriminalteknisk analys
Om du har en informationsläcka kommer du sannolikt att bli tillfrågad om vem som nyligen har använt specifika dokument och vilken information som en misstänkt person nyligen fick åtkomst till. Du kan besvara dessa typer av frågor när du använder den här loggningen eftersom personer som använder skyddat innehåll alltid måste få en Rights Management-licens för att öppna dokument och bilder som skyddas av Azure Information Protection, även om dessa filer flyttas via e-post eller kopieras till USB-enheter eller andra lagringsenheter. Det innebär att du kan använda dessa loggar som en slutgiltig informationskälla för kriminalteknisk analys när du skyddar dina data med hjälp av Azure Information Protection.
Utöver den här användningsloggningen har du även följande loggningsalternativ:
Loggningsalternativ | beskrivning |
---|---|
Administratörslogg | Loggar administrativa uppgifter för skyddstjänsten. Om tjänsten till exempel är inaktiverad, när superanvändarfunktionen är aktiverad och när användare har delegerat administratörsbehörigheter till tjänsten. Mer information finns i PowerShell-cmdleten Get-AipServiceAdminLog. |
Dokumentspårning | Låter användare spåra och återkalla sina dokument som de har spårat med Azure Information Protection-klienten. Globala administratörer kan också spåra dessa dokument för användarnas räkning. Mer information finns i Konfigurera och använda dokumentspårning för Azure Information Protection. |
Händelseloggar för klient | Användningsaktivitet för Azure Information Protection-klienten, loggad i den lokala Windows-program - och tjänsthändelseloggen , Azure Information Protection. Mer information finns i Användningsloggning för Azure Information Protection-klienten. |
Klientloggfiler | Felsöka loggar för Azure Information Protection-klienten som finns i %localappdata%\Microsoft\MSIP. Dessa filer är utformade för Microsoft Support. |
Dessutom samlas information från Azure Information Protection-klientanvändningsloggarna och Azure Information Protection-skannern in och aggregeras för att skapa rapporter i Azure-portalen. Mer information finns i Rapportering för Azure Information Protection.
Använd följande avsnitt för mer information om användningsloggning för skyddstjänsten.
Så här aktiverar du loggning för skyddsanvändning
Skyddsanvändningsloggning är aktiverad som standard för alla kunder.
Logglagringen eller loggningsfunktionen kostar inget extra.
Så här kommer du åt och använder dina användningsloggar för skydd
Azure Information Protection skriver loggar som en serie blobar till ett Azure-lagringskonto som skapas automatiskt för din klientorganisation. Varje blob innehåller en eller flera loggposter i W3C-utökat loggformat. Blobnamnen är tal i den ordning de skapades. Avsnittet Så här tolkar du dina Azure Rights Management-användningsloggar senare i det här dokumentet innehåller mer information om logginnehållet och hur de skapas.
Det kan ta en stund innan loggar visas i ditt lagringskonto efter en skyddsåtgärd. De flesta loggar visas inom 15 minuter. Användningsloggar är endast tillgängliga när fältnamnet "datum" innehåller ett värde för ett tidigare datum (i UTC-tid). Användningsloggar från det aktuella datumet är inte tillgängliga. Vi rekommenderar att du laddar ned loggarna till lokal lagring, till exempel en lokal mapp, en databas eller en map-reduce-lagringsplats.
Om du vill ladda ned dina användningsloggar använder du AIPService PowerShell-modulen för Azure Information Protection. Installationsinstruktioner finns i Installera AIPService PowerShell-modulen.
Så här laddar du ned dina användningsloggar med hjälp av PowerShell
Starta Windows PowerShell med alternativet Kör som administratör och använd cmdleten Anslut-AipService för att ansluta till Azure Information Protection:
Connect-AipService
Kör följande kommando för att ladda ned loggarna för ett visst datum:
Get-AipServiceUserLog -Path <location> -fordate <date>
När du till exempel har skapat en mapp med namnet Loggar på E:-enheten:
Om du vill ladda ned loggar för ett visst datum (till exempel 2016-02-01) kör du följande kommando:
Get-AipServiceUserLog -Path E:\Logs -fordate 2/1/2016
Kör följande kommando för att ladda ned loggar för ett datumintervall (till exempel från 2/1/2016 till 2/14/2016):
Get-AipServiceUserLog -Path E:\Logs -fromdate 2/1/2016 –todate 2/14/2016
När du endast anger dagen, som i våra exempel, antas tiden vara 00:00:00 i din lokala tid och sedan konverteras till UTC. När du anger en tid med parametrarna -fromdate eller -todate (till exempel -fordate "2/1/2016 15:00:00"), konverteras datum och tid till UTC. Kommandot Get-AipServiceUserLog hämtar sedan loggarna för den UTC-tidsperioden.
Du kan inte ange mindre än en hel dag att ladda ned.
Som standard använder den här cmdleten tre trådar för att ladda ned loggarna. Om du har tillräckligt med nätverksbandbredd och vill minska den tid som krävs för att ladda ned loggarna använder du parametern -NumberOfThreads, som stöder ett värde från 1 till 32. Om du till exempel kör följande kommando skapar cmdleten 10 trådar för att ladda ned loggarna: Get-AipServiceUserLog -Path E:\Logs -fromdate 2/1/2016 –todate 2/14/2016 -numberofthreads 10
Dricks
Du kan aggregera alla nedladdade loggfiler i ett CSV-format med hjälp av Microsofts Log Parser, som är ett verktyg för att konvertera mellan olika välkända loggformat. Du kan också använda det här verktyget för att konvertera data till SYSLOG-format eller importera dem till en databas. När du har installerat verktyget kör LogParser.exe /?
du för hjälp och information för att använda det här verktyget.
Du kan till exempel köra följande kommando för att importera all information till ett .log filformat: logparser –i:w3c –o:csv "SELECT * INTO AllLogs.csv FROM *.log"
Så här tolkar du dina användningsloggar
Använd följande information för att tolka användningsloggarna för skydd.
Loggsekvensen
Azure Information Protection skriver loggarna som en serie blobar.
Varje post i loggen har en UTC-tidsstämpel. Eftersom skyddstjänsten körs på flera servrar i flera datacenter kan loggarna ibland verka vara ur ordning, även när de sorteras efter tidsstämpeln. Skillnaden är dock liten och vanligtvis inom en minut. I de flesta fall är detta inte ett problem som skulle vara ett problem för logganalys.
Blobformatet
Varje blob är i W3C utökat loggformat. Det börjar med följande två rader:
#Software: RMS
#Version: 1.1
Den första raden identifierar att det här är skyddsloggar från Azure Information Protection. Den andra raden identifierar att resten av blobben följer version 1.1-specifikationen. Vi rekommenderar att alla program som parsar dessa loggar verifierar dessa två rader innan de fortsätter att parsa resten av blobben.
Den tredje raden räknar upp en lista med fältnamn som avgränsas med flikar:
#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
Var och en av de efterföljande raderna är en loggpost. Fältens värden är i samma ordning som föregående rad och avgränsas med flikar. Använd följande tabell för att tolka fälten.
Fältnamn | W3C-datatyp | beskrivning | Exempelvärde |
---|---|---|---|
Datum | Datum | UTC-datum då begäran delgavs. Källan är den lokala klockan på servern som hanterade begäran. |
2013-06-25 |
Tid | Tid | UTC-tid i 24-timmarsformat när begäran hanterades. Källan är den lokala klockan på servern som hanterade begäran. |
21:59:28 |
rad-ID | Text | Unikt GUID för den här loggposten. Om ett värde inte finns använder du korrelations-ID-värdet för att identifiera posten. Det här värdet är användbart när du sammanställer loggar eller kopierar loggar till ett annat format. |
1c3fe7a9-d9e0-4654-97b7-14fafa72ea63 |
request-type | Name | Namnet på RMS-API:et som begärdes. | AcquireLicense |
användar-ID | String | Användaren som gjorde begäran. Värdet omges av enkla citattecken. Anrop från en klientnyckel som hanteras av dig (BYOK) har värdet ", vilket även gäller när begärandetyperna är anonyma. |
'joe@contoso.com' |
Resultatet | String | "Lyckades" om begäran har hanterats. Feltypen i enkla citattecken om begäran misslyckades. |
"Lyckades" |
korrelations-ID | Text | GUID som är vanligt mellan RMS-klientloggen och serverloggen för en viss begäran. Det här värdet kan vara användbart för att felsöka klientproblem. |
cab52088-8925-4371-be34-4b71a3112356 |
content-id | Text | GUID, omgivet av klammerparenteser som identifierar det skyddade innehållet (till exempel ett dokument). Det här fältet har endast ett värde om typen av begäran är AcquireLicense och är tom för alla andra typer av begäranden. |
{bb4af47b-cfed-4719-831d-71b98191a4f2} |
ägar-e-post | String | E-postadress till dokumentets ägare. Det här fältet är tomt om begärandetypen är RevokeAccess. |
alice@contoso.com |
Emittenten | String | E-postadress till dokument utfärdaren. Det här fältet är tomt om begärandetypen är RevokeAccess. |
alice@contoso.com (eller) FederatedEmail.4c1f4d-93bf-00a95fa1e042@contoso.onmicrosoft.com' |
template-id | String | ID för mallen som används för att skydda dokumentet. Det här fältet är tomt om begärandetypen är RevokeAccess. |
{6d9371a6-4e2d-4e97-9a38-202233fed26e} |
filnamn | String | Filnamn för ett skyddat dokument som spåras med hjälp av Azure Information Protection-klienten för Windows. För närvarande visas vissa filer (till exempel Office-dokument) som GUID i stället för det faktiska filnamnet. Det här fältet är tomt om begärandetypen är RevokeAccess. |
TopSecretDocument.docx |
datumpublicerad | Datum | Datum då dokumentet skyddades. Det här fältet är tomt om begärandetypen är RevokeAccess. |
2015-10-15T21:37:00 |
c-info | String | Information om klientplattformen som gör begäran. Den specifika strängen varierar beroende på programmet (till exempel operativsystemet eller webbläsaren). |
"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 | Adress | IP-adressen för klienten som skickar begäran. | 64.51.202.144 |
admin-action | Bool | Om en administratör har åtkomst till webbplatsen för dokumentspårning i administratörsläge. | Sant |
agera som användare | String | E-postadressen till den användare som en administratör har åtkomst till webbplatsen för dokumentspårning för. | 'joe@contoso.com' |
Undantag för användar-ID-fältet
Även om användar-ID-fältet vanligtvis anger den användare som gjorde begäran, finns det två undantag där värdet inte mappas till en verklig användare:
Värdet "microsoftrmsonline@<YourTenantID.rms>.<region.aadrm.com>'.
Detta indikerar att en Office 365-tjänst, till exempel Exchange Online eller Microsoft SharePoint, gör begäran. I strängen <är YourTenantID> GUID för din klientorganisation och< regionen> är den region där din klientorganisation är registrerad. Till exempel representerar na Nordamerika, eu representerar Europa och ap representerar Asien.
Om du använder RMS-anslutningstjänsten.
Begäranden från den här anslutningsappen loggas med tjänstens huvudnamn för Aadrm_S-1-7-0, som genereras automatiskt när du installerar RMS-anslutningstjänsten.
Vanliga typer av begäranden
Det finns många typer av begäranden för skyddstjänsten, men i följande tabell identifieras några av de mest använda typerna av begäranden.
Typ av begäran | beskrivning |
---|---|
AcquireLicense | En klient från en Windows-baserad dator begär en licens för skyddat innehåll. |
AcquirePreLicense | En klient begär för användarens räkning en licens för skyddat innehåll. |
AcquireTemplates | Ett anrop gjordes för att hämta mallar baserat på mall-ID:t |
AcquireTemplateInformation | Ett anrop gjordes för att hämta ID:t för mallen från tjänsten. |
AddTemplate | Ett anrop görs från Azure-portalen för att lägga till en mall. |
AllDocsCsv | Ett anrop görs från webbplatsen för dokumentspårning för att ladda ned CSV-filen från sidan Alla dokument . |
BECreateEndUserLicenseV1 | Ett anrop görs från en mobil enhet för att skapa en slutanvändarlicens. |
BEGetAllTemplatesV1 | Ett anrop görs från en mobil enhet (serverdel) för att hämta alla mallar. |
Intyga | Klienten certifierar användaren för förbrukning och skapande av skyddat innehåll. |
FECreateEndUserLicenseV1 | Liknar AcquireLicense-begäran men från mobila enheter. |
FECreatePublishingLicenseV1 | Samma som Certify och GetClientLicensorCert tillsammans, från mobila klienter. |
FEGetAllTemplates | Ett anrop görs från en mobil enhet (klientdelen) för att hämta mallarna. |
FindServiceLocationsForUser | Ett anrop görs för att fråga efter URL:er, som används för att anropa Certify eller AcquireLicense. |
GetClientLicensorCert | Klienten begär ett publiceringscertifikat (som senare används för att skydda innehåll) från en Windows-baserad dator. |
GetConfiguration | En Azure PowerShell-cmdlet anropas för att hämta konfigurationen av Azure RMS-klientorganisationen. |
Get Anslut orAuthorizations | Ett anrop görs från RMS-anslutningstjänsten för att hämta deras konfiguration från molnet. |
GetRecipients | Ett anrop görs från webbplatsen för dokumentspårning för att navigera till listvyn för ett enda dokument. |
GetTenantFunctionalState | Azure-portalen kontrollerar om skyddstjänsten (Azure Rights Management) är aktiverad. |
KeyVaultDecryptRequest | Klienten försöker dekryptera RMS-skyddat innehåll. Gäller endast för en kundhanterad klientnyckel (BYOK) i Azure Key Vault. |
KeyVaultGetKeyInfoRequest | Ett anrop görs för att verifiera att nyckeln som anges för att användas i Azure Key Vault för Azure Information Protection-klientnyckeln är tillgänglig och inte redan används. |
KeyVaultSignDigest | Ett anrop görs när en kundhanterad nyckel (BYOK) i Azure Key Vault används i signeringssyfte. Detta kallas vanligtvis en gång per AcquireLicence (eller FECreateEndUserLicenseV1), Certify och GetClientLicensorCert (eller FECreatePublishingLicenseV1). |
KMSPDecrypt | Klienten försöker dekryptera RMS-skyddat innehåll. Gäller endast för en äldre kundhanterad klientnyckel (BYOK). |
KMSPSignDigest | Ett anrop görs när en äldre kundhanterad nyckel (BYOK) används i signeringssyfte. Detta kallas vanligtvis en gång per AcquireLicence (eller FECreateEndUserLicenseV1), Certify och GetClientLicensorCert (eller FECreatePublishingLicenseV1). |
ServerCertify | Ett anrop görs från en RMS-aktiverad klient (till exempel SharePoint) för att certifiera servern. |
SetUsageLogFeatureState | Ett anrop görs för att aktivera användningsloggning. |
SetUsageLogStorageAccount | Ett anrop görs för att ange platsen för Azure Rights Management-tjänstloggarna. |
UpdateTemplate | Ett anrop görs från Azure-portalen för att uppdatera en befintlig mall. |
Skyddsanvändningsloggar och Microsoft 365 enhetlig granskningslogg
Filåtkomst och nekade händelser innehåller för närvarande inte filnamn och är inte tillgängliga i microsoft 365 enhetlig granskningslogg. Dessa händelser kommer att förbättras så att de är fristående användbara och läggs till från Rights Management-tjänsten vid ett senare tillfälle.
PowerShell-referens
Den enda PowerShell-cmdlet som du behöver för att komma åt din skyddsanvändningsloggning är Get-AipServiceUserLog.
Mer information om hur du använder PowerShell för Azure Information Protection finns i Administrera skydd från Azure Information Protection med hjälp av PowerShell.