Hur fungerar Azure RMS? Under motorhuven

Gäller för:Azure Information Protection, Office 365

Relevant för:AIP unified labeling client and classic client.

Obs!

För att ge en enhetlig och smidig kundupplevelse är den klassiska Azure Information Protection-klienten och Etiketthantering i Azure-portalen inaktuella sedan den 31 mars 2021. Inget ytterligare stöd tillhandahålls för den klassiska klienten och underhållsversioner kommer inte längre att släppas.

Den klassiska klienten upphör officiellt och slutar fungera den 31 mars 2022.

Alla aktuella kunder med Azure Information Protection för klassiska klienter måste migrera till Microsoft Information Protection unified labeling-plattformen och uppgradera till den enhetliga etikettklienten. Läs mer i vår migreringsblogg.

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. Med Azure RMS blir bara informationen i ett dokument oläslig för alla andra än behöriga användare och tjänster:

  • Data krypteras på programnivå och innehåller en princip som definierar behörig användning för dokumentet.

  • När ett skyddat dokument används av en legitim användare eller det bearbetas av en behörig tjänst dekrypteras data i dokumentet och de rättigheter som definieras i principen tillämpas.

På en 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 tangenten i den här bilden). Det är unikt för varje dokument och placeras i filrubriken där det skyddas av Azure Information Protection-klientrotnyckeln (den röda nyckeln på den här bilden). Din klientnyckel kan genereras och hanteras av Microsoft, eller så kan du skapa och hantera din egen klientnyckel.

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

Hur Azure RMS skyddar en fil

En detaljerad beskrivning av vad som händer finns i Genomgång av hur Azure RMS fungerar: Första användningen, innehållsskydd och innehållsanvändning i den här artikeln.

Mer teknisk information om de algoritmer och nyckellängder som används i Azure RMS finns i nästa avsnitt.

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

Även om du inte behöver veta mer om 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.

Kryptografiska kontroller Använd i Azure RMS
Algoritmen: AES

Nyckellängd: 128 bitar och 256 bitar [1]
Innehållsskydd
Algoritm: RSA

Nyckellängd: 2 048 bitar [2]
Nyckelskydd
SHA-256 Certifikatsignering
Fotnot 1

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

  • Allmänt skydd (.pfile).

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

  • Inbyggt skydd för text- eller bildfiler (t.ex. .ptxt eller .pjpg).

Fotnot 2

2 048 bitar är nyckellängden när Azure Rights Management-tjänsten aktiveras. 1024 bitar stöds för följande valfria scenarier:

  • Under en migrering från en lokal miljö om AD RMS-klustret körs i Cryptographic Mode 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.

Hur Azure RMS-kryptografiska nycklar lagras och skyddas

För varje dokument eller e-post som skyddas av Azure RMS skapar Azure RMS en enda AES-nyckel ("innehållsnyckeln"), och den nyckeln bäddas in i dokumentet och finns kvar i utgåvor av dokumentet.

Innehållsnyckeln är skyddad med organisationens RSA-nyckel (Azure Information Protection-klientnyckeln) som en del av principen i dokumentet, och principen signeras även av dokumentets författare. Den här klientnyckeln är gemensam för alla dokument och e-postmeddelanden som skyddas av tjänsten Azure Rights Management 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 kundhanteringsstyrd (kallas "ta med en egen nyckel" eller BYOK).

Den här klientnyckeln är skyddad i Microsofts onlinetjänster, i en miljö med mycket kontroll och under noggrann övervakning. När du använder en kund hanterad klientnyckel (BYOK) förbättras den här säkerheten med hjälp av en matris med avancerade maskinvarusäkerhetsmoduler (HSMs) i varje Azure-region, utan möjligheten för nycklar att extraheras, exporteras eller delas under några omständigheter. Mer information om klientnyckeln och BYOK finns i Planera och implementera Azure Information Protection-klientnyckeln.

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, som skyddar dessa hemligheter genom att använda en nyckel som härleds från användarens lösenord. På mobila enheter används nycklarna bara en gång, vilket gör att dessa nycklar inte behöver skyddas på enheten eftersom de inte lagras på klienterna.

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

Mer detaljerad information om hur Azure RMS fungerar kan du läsa igenom ett vanligt flöde efter att Azure Rights Management-tjänsten har aktiverats och när en användare först använder rättighetshanteringstjänsten på sin Windows-dator (en process som ibland kallas för att initiera användarmiljön eller startprogram), skydda innehåll (ett dokument eller e-post) och sedan använda (öppna och använda) 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å den datorn.

Obs!

Om användaren flyttar till en Windows dator eller en annan användare använder Windows samma dator upprepas initieringsprocessen.

Initiera användarmiljön

Innan en användare kan skydda innehåll eller använda skyddat innehåll på Windows dator måste användarmiljön vara förberedd på enheten. Det här är en process som bara sker en gång och sker automatiskt utan att användaren behöver göra något när en användare försöker skydda eller använda skyddat innehåll:

Aktiveringsflöde för RMS-klienten – steg 1, autentisera klienten

Vad 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 Azure Active Directory konto.

När användarens konto är federerat med Azure Active Directory, används den här autentiseringen automatiskt och användaren uppmanas inte att ange autentiseringsuppgifter.

AKTIVERING AV RMS-klient – steg 2: Certifikat laddas ned till klienten

Vad händer i steg 2:När användaren har autentiserats omdirigeras anslutningen automatiskt till organisationens Azure Information Protection-klient, 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 behörighetskontocertifikatet, som ofta förkortas till RAC. Det här certifikatet autentiserar användaren att Azure Active Directory och är giltigt i 31 dagar. Certifikatet förnyas automatiskt av RMS-klienten, vilket innebär att användarkontot fortfarande Azure Active Directory och kontot aktiveras. Certifikatet kan inte konfigureras av en administratör.

En kopia av 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 för ett oskyddat dokument:

RMS-dokumentskydd – steg 1, dokumentet krypteras

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

RMS-dokumentskydd – steg 2, princip skapas

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

Det huvudsakliga Azure AD-attributet som används för att identifiera de valda användarna och grupperna är azure AD-proxyAddresses-attributet, 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 inhämtades 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 även principen med användarens certifikat som erhållits när användarmiljön initierades.

RMS-dokumentskydd – steg 3: principen bäddas in i dokumentet

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

Det här dokumentet kan lagras var som helst eller delas med valfri metod, och principen förblir alltid med det krypterade dokumentet.

Innehållsanvändning

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

RMS-dokumentanvändning – steg 1, användaren autentiseras och får listan över rättigheter

Vad händer i steg 1:Den autentiserade användaren skickar dokumentprincipen och användarens certifikat till Tjänsten Azure Rights Management. Tjänsten dekrypterar och utvärderar principen och skapar en lista över rättigheter (om någon) användaren har för dokumentet. För att identifiera användaren används attributet Azure AD 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 Azure AD ProxyAddresses används värdet i Azure AD UserPrincipalName i stället.

RMS-dokumentanvändning – steg 2: Använda licens returneras till klienten

Vad händer i steg 2:Tjänsten extraherar AES-innehållsnyckeln från den dekrypterade principen. Den här nyckeln krypteras sedan med användarens offentliga RSA-nyckel som erhållits 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.

RMS-dokumentanvändning – steg 3, dokumentet dekrypteras och rättigheter tillämpas

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

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

Obs!

När användare som är externa i organisationen använder innehåll som du har skyddat blir förbrukningsflödet detsamma. Vad som ändras i det här scenariot är hur användaren autentiseras. Mer information finns i Hur autentiseras den användaren när jag delar ett skyddat dokument med någon utanför företaget?

Variationer

I de föregående genomgångarna beskrivs standardscenarion men det finns några varianter:

  • E-postskydd: När Exchange Online och Meddelandekryptering i Office 365 med nya funktioner används för att skydda e-postmeddelanden kan autentisering för användning också använda federation med en person som tillhandahåller en social identitetsleverantör eller med ett lösenordskod för ett enda lösenord. Sedan är processflödena väldigt lika, förutom att innehållsanvändningen sker på tjänstsidan i en webbläsarsession under en tillfälligt cachelagrad kopia av den utgående e-posten.

  • Mobila enheter:När mobila enheter skyddar eller använder filer med Azure Rights Management-tjänsten är processflödena mycket enklare. Mobila enheter använder inte först initieringsprocessen eftersom varje transaktion (för att skydda eller använda innehåll) är oberoende. Precis som Windows datorer ansluter mobila enheter till tjänsten Azure Rights Management och autentiserar. För att skydda innehåll skickar mobila enheter en princip, och tjänsten Azure Rights Management skickar en publiceringslicens till dem samt en symmetrisk nyckel för att skydda dokumentet. När mobila enheter ansluter till tjänsten Azure Rights Management och autentiserar 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 tjänsten Azure Rights Management nödvändiga nycklar och begränsningar till mobila enheter. Båda processerna använder TLS för att skydda nyckelutbyte och annan kommunikation.

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

  • Allmänt skydd (.pfile): När Azure Rights Management-tjänsten generellt skyddar en fil är flödet i stort sett detsamma för innehållsskydd, förutom att RMS-klienten skapar en princip som beviljar 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 stöd för RMS på ett inbyggt sätt.

  • Microsoft-konton:Azure Information Protection kan auktorisera e-postadresser för användning när de autentiseras med ett Microsoft-konto. Men alla program kan 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å utforska, till exempel Hur program stöder Azure Rights Management-tjänsten för att ta reda på hur dina befintliga program kan integreras med Azure Rights Management för att tillhandahålla en informationsskyddslösning.

Läs terminologin för Azure Information Protection så att du är bekant med termer som du kan stöta på när du konfigurerar och använder tjänsten Azure Rights Management, och kontrollera även krav för Azure Information Protection innan du börjar distributionen. Om du vill börja testa själv direkt kan du använda snabbstartsguider och självstudiekurser:

Om du är redo att börja distribuera dataskydd för organisationen kan du använda AIP-distributionsöversikten för klassificering, märkning och skydd för distributionsstegen och länkar till instruktioner.

Tips!

Om du vill ha mer information och hjälp kan du använda resurserna och länkarna i Information och support för Azure Information Protection.