Hur fungerar Azure RMS? Under huven

En viktig sak att förstå om hur Azure RMS fungerar är att den här dataskyddstjänsten från Azure Information Protection inte ser eller lagrar dina data som en del av skyddsprocessen. Information som du skyddar skickas aldrig till eller lagras i Azure, såvida du inte uttryckligen lagrar den i Azure eller använder en annan molntjänst som lagrar den i Azure. Azure RMS gör helt enkelt data i ett dokument oläsliga för andra än auktoriserade användare och tjänster:

• Data krypteras på programnivå och innehåller en princip som definierar den auktoriserade användningen för dokumentet.

• När ett skyddat dokument används av en legitim användare eller om det bearbetas av en auktoriserad tjänst dekrypteras data i dokumentet och de rättigheter som definieras i principen framtvingas.

På hög nivå kan du se hur den här processen fungerar i följande bild. Ett dokument som innehåller den hemliga formeln skyddas och öppnas sedan av en behörig användare eller tjänst. Dokumentet skyddas av en innehållsnyckel (den gröna nyckeln i den här bilden). Det är unikt för varje dokument och placeras i filhuvudet där det skyddas av din Azure Information Protection-klientrotnyckel (den röda nyckeln i den här bilden). Din klientnyckel kan genereras och hanteras av Microsoft, eller så kan du generera och hantera din egen klientnyckel.

Under hela skyddsprocessen när Azure RMS krypterar och dekrypterar, auktoriserar och tillämpar begränsningar skickas aldrig den hemliga formeln till Azure.

En detaljerad beskrivning av vad som händer finns i genomgången av hur Azure RMS fungerar: Första användning, innehållsskydd, innehållsförbrukning i den här artikeln.

Teknisk information om de algoritmer och nyckellängder som Azure RMS använder finns i nästa avsnitt.

Kryptografiska kontroller som används av Azure RMS: Algoritmer och nyckellängder

Även om du inte behöver veta i detalj hur den här tekniken fungerar kan du bli tillfrågad om de kryptografiska kontroller som används. Till exempel för att bekräfta att säkerhetsskyddet är branschstandard.

Fotnot 1

256 bitar används av Azure Information Protection-klienten i följande scenarier:

• Allmänt skydd (.pfile).

• Internt skydd för PDF-dokument när dokumentet har skyddats med ISO-standarden för PDF-kryptering, eller om det resulterande skyddade dokumentet har filnamnstillägget .ppdf.

• Internt skydd för text- eller bildfiler (till exempel .ptxt eller .pjpg).

Fotnot 2

2048 bitar är nyckellängden när Azure Rights Management-tjänsten aktiveras. 1 024 bitar stöds för följande valfria scenarier:

• Under en migrering från en lokal plats om AD RMS-klustret körs i kryptografiskt läge 1.

• För arkiverade nycklar som skapades lokalt före migreringen, så att innehåll som tidigare skyddades av AD RMS kan fortsätta att öppnas av Azure Rights Management-tjänsten efter migreringen.

Så här lagras och skyddas kryptografiska Azure RMS-nycklar

För varje dokument eller e-post som skyddas av Azure RMS skapar Azure RMS en enda AES-nyckel ("innehållsnyckeln") och den nyckeln är inbäddad i dokumentet och bevaras via utgåvor av dokumentet.

Innehållsnyckeln skyddas med organisationens RSA-nyckel ("Azure Information Protection-klientnyckeln") som en del av principen i dokumentet, och principen signeras också av dokumentets författare. Den här klientnyckeln är gemensam för alla dokument och e-postmeddelanden som skyddas av Azure Rights Management-tjänsten för organisationen och den här nyckeln kan bara ändras av en Azure Information Protection-administratör om organisationen använder en klientnyckel som är kundhanterad (kallas "bring your own key" eller BYOK).

Den här klientnyckeln skyddas i Microsofts onlinetjänster, i en mycket kontrollerad miljö och under noggrann övervakning. När du använder en kundhanterad klientnyckel (BYOK) förbättras den här säkerheten med hjälp av en matris med avancerade maskinvarusäkerhetsmoduler (HSM: er) i varje Azure-region, utan att nycklarna kan extraheras, exporteras eller delas under några omständigheter. Mer information om klientnyckeln och BYOK finns i Planera och implementera din Azure Information Protection-klientnyckel.

Licenser och certifikat som skickas till en Windows-enhet skyddas med klientens privata enhetsnyckel, som skapas första gången en användare på enheten använder Azure RMS. Den här privata nyckeln skyddas i sin tur med DPAPI på klienten, vilket skyddar dessa hemligheter med hjälp av en nyckel som härleds från användarens lösenord. På mobila enheter används nycklarna bara en gång, så eftersom de inte lagras på klienterna behöver dessa nycklar inte skyddas på enheten.

Genomgång av hur Azure RMS fungerar: Första användning, innehållsskydd, innehållsförbrukning

För att förstå mer detaljerat hur Azure RMS fungerar ska vi gå igenom ett typiskt flöde när Azure Rights Management-tjänsten har aktiverats och när en användare först använder Rights Management-tjänsten på sin Windows-dator (en process som ibland kallas att initiera användarmiljön eller bootstrapping), skyddar innehåll (ett dokument eller ett e-postmeddelande) och sedan använder (öppnar och använder) innehåll som har skyddats av någon annan.

När användarmiljön har initierats kan användaren sedan skydda dokument eller använda skyddade dokument på datorn.

Initiera användarmiljön

Innan en användare kan skydda innehåll eller använda skyddat innehåll på en Windows-dator måste användarmiljön förberedas på enheten. Det här är en engångsprocess och sker automatiskt utan användarintervention när en användare försöker skydda eller använda skyddat innehåll:

Vad som händer i steg 1: RMS-klienten på datorn ansluter först till Azure Rights Management-tjänsten och autentiserar användaren med hjälp av sitt Microsoft Entra-konto.

När användarens konto federeras med Microsoft Entra-ID sker den här autentiseringen automatiskt och användaren uppmanas inte att ange autentiseringsuppgifter.

Vad som händer i steg 2: När användaren har autentiserats omdirigeras anslutningen automatiskt till organisationens Azure Information Protection-klientorganisation, som utfärdar certifikat som låter användaren autentisera till Azure Rights Management-tjänsten för att använda skyddat innehåll och skydda innehåll offline.

Ett av dessa certifikat är rättighetskontocertifikatet, som ofta förkortas RAC. Det här certifikatet autentiserar användaren till Microsoft Entra-ID och är giltigt i 31 dagar. Certifikatet förnyas automatiskt av RMS-klienten, förutsatt att användarkontot fortfarande finns i Microsoft Entra-ID och kontot är aktiverat. Det här certifikatet kan inte konfigureras av en administratör.

En kopia av det här certifikatet lagras i Azure så att certifikaten skapas med samma nycklar om användaren flyttar till en annan enhet.

Innehållsskydd

När en användare skyddar ett dokument vidtar RMS-klienten följande åtgärder i ett oskyddat dokument:

Vad som händer i steg 1: RMS-klienten skapar en slumpmässig nyckel (innehållsnyckeln) och krypterar dokumentet med hjälp av den här nyckeln med den symmetriska AES-krypteringsalgoritmen.

Vad som händer i steg 2: RMS-klienten skapar sedan ett certifikat som innehåller en princip för dokumentet som innehåller användningsrättigheter för användare eller grupper och andra begränsningar, till exempel ett förfallodatum. De här inställningarna kan definieras i en mall som en administratör tidigare har konfigurerat eller angett när innehållet skyddas (kallas ibland för en "ad hoc-princip").

Det huvudsakliga Microsoft Entra-attributet som används för att identifiera de valda användarna och grupperna är attributet Microsoft Entra ProxyAddresses, som lagrar alla e-postadresser för en användare eller grupp. Men om ett användarkonto inte har några värden i AD ProxyAddresses-attributet används användarens UserPrincipalName-värde i stället.

RMS-klienten använder sedan organisationens nyckel som erhölls när användarmiljön initierades och använder den här nyckeln för att kryptera principen och den symmetriska innehållsnyckeln. RMS-klienten signerar också principen med användarens certifikat som erhölls när användarmiljön initierades.

Vad som händer i steg 3: Slutligen bäddar RMS-klienten in principen i en fil med brödtexten i dokumentet krypterat tidigare, som tillsammans utgör ett skyddat dokument.

Det här dokumentet kan lagras var som helst eller delas med valfri metod, och principen finns alltid kvar i det krypterade dokumentet.

Innehållsförbrukning

När en användare vill använda ett skyddat dokument börjar RMS-klienten med att begära åtkomst till Azure Rights Management-tjänsten:

Vad som händer i steg 1: Den autentiserade användaren skickar dokumentprincipen och användarens certifikat till Azure Rights Management-tjänsten. Tjänsten dekrypterar och utvärderar principen och skapar en lista över rättigheter (om några) som användaren har för dokumentet. För att identifiera användaren används attributet Microsoft Entra ProxyAddresses för användarens konto och grupper som användaren är medlem i. Av prestandaskäl cachelagras gruppmedlemskap. Om användarkontot inte har några värden för attributet Microsoft Entra ProxyAddresses används värdet i Microsoft Entra UserPrincipalName i stället.

Vad som händer i steg 2: Tjänsten extraherar sedan AES-innehållsnyckeln från den dekrypterade principen. Den här nyckeln krypteras sedan med användarens offentliga RSA-nyckel som hämtades med begäran.

Den omkrypterade innehållsnyckeln bäddas sedan in i en krypterad användningslicens med listan över användarrättigheter, som sedan returneras till RMS-klienten.

Vad som händer i steg 3: Slutligen tar RMS-klienten den krypterade användningslicensen och dekrypterar den med en egen privat användarnyckel. På så sätt kan RMS-klienten dekryptera dokumentets brödtext när det behövs och återge det på skärmen.

Klienten dekrypterar också rättighetslistan och skickar dem till programmet, vilket framtvingar dessa rättigheter i programmets användargränssnitt.

Variationer

Föregående genomgångar beskriver standardscenarierna, men det finns några varianter:

• E-postskydd: När Exchange Online och Office 365-meddelandekryptering med nya funktioner används för att skydda e-postmeddelanden kan autentisering för förbrukning också använda federation med en social identitetsprovider eller med hjälp av ett engångslösenord. Processflödena är sedan mycket lika, förutom att innehållsförbrukning sker på tjänstsidan i en webbläsarsession över en tillfälligt cachelagrad kopia av den utgående e-postmeddelandet.

• Mobila enheter: När mobila enheter skyddar eller använder filer med Azure Rights Management-tjänsten är processflödena mycket enklare. Mobila enheter går inte först igenom användarens initieringsprocess eftersom varje transaktion (för att skydda eller använda innehåll) i stället är oberoende. Precis som med Windows-datorer ansluter mobila enheter till Azure Rights Management-tjänsten och autentiserar. För att skydda innehåll skickar mobila enheter en princip och Azure Rights Management-tjänsten skickar en publiceringslicens och en symmetrisk nyckel för att skydda dokumentet. När mobila enheter ansluter till Azure Rights Management-tjänsten och autentiserar för att använda innehåll skickar de dokumentprincipen till Azure Rights Management-tjänsten och begär en användningslicens för att använda dokumentet. Som svar skickar Azure Rights Management-tjänsten nödvändiga nycklar och begränsningar till de mobila enheterna. Båda processerna använder TLS för att skydda nyckelutbytet och annan kommunikation.

• RMS-anslutningsapp: När Azure Rights Management-tjänsten används med RMS-anslutningstjänsten förblir processflödena desamma. Den enda skillnaden är att anslutningsappen fungerar som ett relä mellan de lokala tjänsterna (till exempel Exchange Server och SharePoint Server) och Azure Rights Management-tjänsten. Själva anslutningsappen utför inga åtgärder, till exempel initiering av användarmiljön, kryptering eller dekryptering. Den vidarebefordrar helt enkelt kommunikationen som vanligtvis går till en AD RMS-server och hanterar översättningen mellan de protokoll som används på varje sida. Med det här scenariot kan du använda Azure Rights Management-tjänsten med lokala tjänster.

• Allmänt skydd (.pfile): När Azure Rights Management-tjänsten allmänt skyddar en fil är flödet i princip detsamma för innehållsskydd, förutom att RMS-klienten skapar en princip som ger alla rättigheter. När filen används dekrypteras den innan den skickas till målprogrammet. Med det här scenariot kan du skydda alla filer, även om de inte har inbyggt stöd för RMS.

• Microsoft-konton: Azure Information Protection kan auktorisera e-postadresser för förbrukning när de autentiseras med ett Microsoft-konto. Alla program kan dock inte öppna skyddat innehåll när ett Microsoft-konto används för autentisering. Mer information.

Nästa steg

Om du vill veta mer om Azure Rights Management-tjänsten kan du använda de andra artiklarna i avsnittet Förstå och utforska , till exempel Hur program stöder Azure Rights Management-tjänsten för att lära dig hur dina befintliga program kan integreras med Azure Rights Management för att tillhandahålla en informationsskyddslösning.

Granska Terminologi för Azure Information Protection så att du är bekant med de villkor som du kan stöta på när du konfigurerar och använder Azure Rights Management-tjänsten och se till att även kontrollera kraven för Azure Information Protection innan du påbörjar distributionen. Om du vill gå in och prova själv kan du använda snabbstarten och självstudierna:

• Snabbstart: Distribuera klienten för enhetlig etikettering
• Självstudie: Installera azure informationsskyddsskannern (AIP) för enhetlig etikettering
• Självstudie: Hitta känsligt innehåll med Azure Information Protection-skannern (AIP)
• Självstudie: Förhindra överdelning i Outlook med hjälp av Azure Information Protection (AIP)

Om du är redo att börja distribuera dataskydd för din organisation använder du AIP-distributionsöversikten för klassificering, etikettering och skydd för dina distributionssteg och länkar för instruktioner.