Sdílet prostřednictvím


Jak funguje Azure RMS? Pod pokličkou

Důležité informace o tom, jak Azure RMS funguje, je to, že tato služba ochrany dat z Azure Information Protection nezobrazuje ani neukládá vaše data v rámci procesu ochrany. Informace, které chráníte, se nikdy neodesílají ani neukládají v Azure, pokud je explicitně neukládáte v Azure nebo nepoužíváte jinou cloudovou službu, která je ukládá v Azure. Azure RMS jednoduše znepřístupňuje data v dokumentu nečitelné komukoli jinému než autorizovaným uživatelům a službám:

  • Data se šifrují na úrovni aplikace a obsahují zásady, které definují autorizované použití pro daný dokument.

  • Pokud chráněný dokument používá legitimní uživatel nebo ho zpracovává autorizovaná služba, data v dokumentu se dešifrují a vynucují se práva definovaná v zásadách.

Na nejvyšší úrovni vidíte, jak tento proces funguje, na následujícím obrázku. Dokument obsahující tajný vzorec je chráněn a úspěšně otevřen autorizovaným uživatelem nebo službou. Dokument je chráněn klíčem obsahu (zelený klíč na tomto obrázku). Je jedinečný pro každý dokument a je umístěn v hlavičce souboru, kde je chráněn kořenovým klíčem tenanta Azure Information Protection (červený klíč na tomto obrázku). Váš klíč tenanta může generovat a spravovat Microsoft, nebo můžete vygenerovat a spravovat vlastní klíč tenanta.

V celém procesu ochrany, když Azure RMS šifruje a dešifruje, autorizuje a vynucuje omezení, tajný vzorec se nikdy neodesílají do Azure.

Jak Azure RMS chrání soubor

Podrobný popis toho, co se děje, najdete v návodu , jak Azure RMS funguje: první použití, ochrana obsahu, část o spotřebě obsahu v tomto článku.

Technické podrobnosti o algoritmech a délkách klíčů, které Azure RMS používá, najdete v další části.

Kryptografické ovládací prvky používané službou Azure RMS: Algoritmy a délky klíčů

I když nepotřebujete podrobně vědět, jak tato technologie funguje, můžete být požádáni o kryptografické ovládací prvky, které používá. Pokud chcete například ověřit, že je ochrana zabezpečení standardní.

Kryptografické ovládací prvky Použití v Azure RMS
Algoritmus: AES

Délka klíče: 128 bitů a 256 bitů [1]
Ochrana obsahu
Algoritmus: RSA

Délka klíče: 2048 bitů [2]
Ochrana klíčů
SHA-256 Podepisování certifikátů
Poznámka pod čarou 1

Klient služby Azure Information Protection používá 256 bitů v následujících scénářích:

  • Obecná ochrana (.pfile).

  • Nativní ochrana dokumentů PDF, pokud byl dokument chráněn standardem ISO pro šifrování PDF nebo výsledný chráněný dokument má příponu .ppdf.

  • Nativní ochrana pro textové soubory nebo soubory obrázků (například .ptxt nebo .pjpg).

Poznámka pod čarou 2

2048 bitů je délka klíče při aktivaci služby Azure Rights Management. Pro následující volitelné scénáře se podporuje 1024 bitů:

  • Během migrace z místního prostředí, pokud je cluster AD RMS spuštěný v kryptografickém režimu 1.

  • Pro archivované klíče, které byly vytvořeny místně před migrací, takže obsah, který byl dříve chráněný službou AD RMS, může po migraci dál otevírat služba Azure Rights Management.

Způsob ukládání a zabezpečení kryptografických klíčů Azure RMS

Pro každý dokument nebo e-mail chráněný službou Azure RMS vytvoří Azure RMS jeden klíč AES ("klíč obsahu") a tento klíč se vloží do dokumentu a zachová se v edicích dokumentu.

Klíč obsahu je chráněn klíčem RSA organizace (klíč tenanta Azure Information Protection) v rámci zásad v dokumentu a tato zásada je také podepsána autorem dokumentu. Tento klíč tenanta je společný pro všechny dokumenty a e-maily chráněné službou Azure Rights Management pro organizaci a tento klíč může změnit jenom správce služby Azure Information Protection, pokud organizace používá klíč tenanta spravovaný zákazníkem (označovaný jako "Přineste si vlastní klíč" nebo BYOK).

Tento klíč tenanta je chráněný v online služby Microsoftu v prostředí s vysokou kontrolou a při úzkém monitorování. Pokud používáte klíč tenanta spravovaný zákazníkem (BYOK), toto zabezpečení se vylepšuje použitím pole vysoce kvalitních modulů hardwarového zabezpečení (HSM) v každé oblasti Azure, aniž by bylo možné klíče extrahovat, exportovat nebo sdílet za jakýchkoli okolností. Další informace o klíči tenanta a BYOK najdete v tématu Plánování a implementace klíče tenanta služby Azure Information Protection.

Licence a certifikáty odesílané do zařízení s Windows jsou chráněné privátním klíčem zařízení klienta, který se vytvoří při prvním použití Azure RMS uživatelem zařízení. Tento privátní klíč je zase chráněný pomocí rozhraní DPAPI na klientovi, který chrání tyto tajné kódy pomocí klíče odvozeného z hesla uživatele. Na mobilních zařízeních se klíče používají jenom jednou, takže protože nejsou uložené v klientech, nemusí být tyto klíče chráněné na zařízení.

Návod, jak Azure RMS funguje: První použití, ochrana obsahu, spotřeba obsahu

Abychom pochopili, jak Azure RMS funguje podrobněji, projdeme si typický tok po aktivaci služby Azure Rights Management a když uživatel poprvé použije službu Rights Management na počítači s Windows (proces se někdy označuje jako inicializace uživatelského prostředí nebo spouštění), chrání obsah (dokument nebo e-mail) a pak využívá (otevře a používá) obsah chráněný někým jiným.

Po inicializaci uživatelského prostředí může tento uživatel chránit dokumenty nebo využívat chráněné dokumenty v tomto počítači.

Poznámka:

Pokud se tento uživatel přesune do jiného počítače s Windows nebo jiný uživatel používá stejný počítač s Windows, proces inicializace se opakuje.

Inicializace uživatelského prostředí

Aby uživatel mohl chránit obsah nebo využívat chráněný obsah na počítači s Windows, musí být na zařízení připravené uživatelské prostředí. Jedná se o jednorázový proces, který se automaticky provede bez zásahu uživatele, když se uživatel pokusí chránit nebo využívat chráněný obsah:

Tok aktivace klienta RMS – krok 1, ověření klienta

Co se děje v kroku 1: Klient SLUŽBY RMS v počítači se nejprve připojí ke službě Azure Rights Management a ověří uživatele pomocí svého účtu Microsoft Entra.

Pokud je účet uživatele federovaný s ID Microsoft Entra, toto ověřování je automatické a uživatel nebude vyzván k zadání přihlašovacích údajů.

Aktivace klienta RMS – krok 2, certifikáty se stáhnou do klienta.

Co se děje v kroku 2: Po ověření uživatele se připojení automaticky přesměruje do tenanta služby Azure Information Protection organizace, který vydává certifikáty, které uživateli umožňují ověřit se ve službě Azure Rights Management, aby mohl využívat chráněný obsah a chránit obsah offline.

Jedním z těchto certifikátů je certifikát účtu práv, který se často zkracuje na RAC. Tento certifikát ověřuje uživatele v MICROSOFT Entra ID a je platný po dobu 31 dnů. Certifikát se automaticky prodloužil klientem služby RMS, přičemž uživatelský účet je stále v ID Microsoft Entra a účet je povolený. Tento certifikát nemůže konfigurovat správce.

Kopie tohoto certifikátu je uložená v Azure, takže pokud se uživatel přesune na jiné zařízení, vytvoří se certifikáty pomocí stejných klíčů.

Ochrana obsahu

Když uživatel chrání dokument, klient služby RMS provede u nechráněného dokumentu následující akce:

Ochrana dokumentu RMS – krok 1, dokument je šifrovaný

Co se děje v kroku 1: Klient SLUŽBY RMS vytvoří náhodný klíč (klíč obsahu) a zašifruje dokument pomocí tohoto klíče pomocí algoritmu symetrického šifrování AES.

Ochrana dokumentu RMS – krok 2, vytvoří se zásada

Co se děje v kroku 2: Klient SLUŽBY RMS pak vytvoří certifikát, který obsahuje zásady pro dokument, který obsahuje práva k používání pro uživatele nebo skupiny a další omezení, například datum vypršení platnosti. Tato nastavení se dají definovat v šabloně, kterou správce nakonfiguroval dříve, nebo v době, kdy je obsah chráněný (někdy označovaný jako "ad hoc zásady").

Hlavním atributem Microsoft Entra sloužícím k identifikaci vybraných uživatelů a skupin je atribut Microsoft Entra ProxyAddresses, který ukládá všechny e-mailové adresy pro uživatele nebo skupinu. Pokud však uživatelský účet nemá žádné hodnoty v atributu AD ProxyAddresses, použije se místo toho hodnota UserPrincipalName uživatele.

Klient služby RMS pak použije klíč organizace, který byl získán při inicializaci uživatelského prostředí, a tento klíč použije k šifrování zásad a symetrického klíče obsahu. Klient služby RMS také podepíše zásadu certifikátem uživatele, který byl získán při inicializaci uživatelského prostředí.

Ochrana dokumentu RMS – krok 3, zásady se vloží do dokumentu.

Co se děje v kroku 3: Nakonec klient SLUŽBY RMS vloží zásadu do souboru s textem dříve zašifrovaného dokumentu, který společně tvoří chráněný dokument.

Tento dokument lze uložit kdekoli nebo sdílet pomocí libovolné metody a zásady vždy zůstanou se šifrovaným dokumentem.

Spotřeba obsahu

Když chce uživatel využívat chráněný dokument, klient SLUŽBY RMS začne vyžadovat přístup ke službě Azure Rights Management:

Spotřeba dokumentů RMS – krok 1, uživatel se ověří a získá seznam práv.

Co se děje v kroku 1: Ověřený uživatel odešle zásady dokumentu a certifikáty uživatele do služby Azure Rights Management. Služba dešifruje a vyhodnocuje zásady a sestaví seznam práv (pokud existuje), která má uživatel pro dokument. K identifikaci uživatele se atribut Microsoft Entra ProxyAddresses používá pro účet a skupiny uživatele, kterým je uživatel členem. Z důvodů výkonu se členství ve skupinách ukládá do mezipaměti. Pokud uživatelský účet nemá žádné hodnoty pro atribut Microsoft Entra ProxyAddresses, použije se místo toho hodnota v microsoft Entra UserPrincipalName.

Spotřeba dokumentů RMS – krok 2, použití licence se vrátí klientovi.

Co se děje v kroku 2: Služba pak extrahuje klíč obsahu AES z dešifrovaných zásad. Tento klíč se pak zašifruje pomocí veřejného klíče RSA uživatele, který byl získán pomocí požadavku.

Znovu zašifrovaný klíč obsahu se pak vloží do šifrované licence pro použití se seznamem uživatelských práv, která se pak vrátí klientovi SLUŽBY RMS.

Spotřeba dokumentů RMS – krok 3, dokument se dešifruje a vynucují se práva

Co se děje v kroku 3: Nakonec klient SLUŽBY RMS vezme zašifrovanou licenci k použití a dešifruje ji vlastním uživatelským privátním klíčem. Klient SLUŽBY RMS tak může dešifrovat tělo dokumentu podle potřeby a vykreslit ho na obrazovce.

Klient také dešifruje seznam práv a předá je aplikaci, která vynucuje tato práva v uživatelském rozhraní aplikace.

Poznámka:

Když uživatelé, kteří jsou mimo vaši organizaci, využívají obsah, který jste ochránili, je tok spotřeby stejný. Jaké změny v tomto scénáři se změní, je způsob ověření uživatele. Další informace najdete v tématu Když sdílím chráněný dokument s někým mimo mou společnost, jak se tento uživatel ověří?

Variace

Předchozí názorné postupy se týkají standardních scénářů, ale existují některé varianty:

  • Ochrana e-mailu: Když se k ochraně e-mailových zpráv používá Šifrování zpráv Exchange Online a Office 365 s novými možnostmi, může ověřování ke spotřebě používat také federaci se zprostředkovatelem sociální identity nebo jednorázovým heslem. Toky procesu jsou pak velmi podobné, s tím rozdílem, že spotřeba obsahu probíhá na straně služby ve webové relaci prohlížeče přes dočasně uloženou kopii odchozího e-mailu v mezipaměti.

  • Mobilní zařízení: Když mobilní zařízení chrání nebo využívají soubory pomocí služby Azure Rights Management, jsou toky procesů mnohem jednodušší. Mobilní zařízení nejprve neprocházejí procesem inicializace uživatele, protože každá transakce (k ochraně nebo využívání obsahu) je nezávislá. Stejně jako u počítačů s Windows se mobilní zařízení připojují ke službě Azure Rights Management a ověřují se. Pokud chcete chránit obsah, mobilní zařízení odesílají zásady a služba Azure Rights Management jim pošle licenci publikování a symetrický klíč k ochraně dokumentu. Pokud chcete využívat obsah, mobilní zařízení se připojují ke službě Azure Rights Management a ověřují se, posílají zásady dokumentů službě Azure Rights Management a požadují licenci k používání dokumentu. V reakci na to služba Azure Rights Management odesílá na mobilní zařízení potřebné klíče a omezení. Oba procesy používají protokol TLS k ochraně výměny klíčů a další komunikace.

  • Rms Connector: Když se služba Azure Rights Management používá s konektorem RMS, toky procesu zůstanou stejné. Jediným rozdílem je, že konektor funguje jako přenos mezi místními službami (například Exchange Server a SharePoint Server) a službou Azure Rights Management. Samotný konektor neprovádí žádné operace, jako je inicializace uživatelského prostředí nebo šifrování nebo dešifrování. Jednoduše předá komunikaci, která by obvykle přešla na server AD RMS, a zpracovává překlad mezi protokoly, které se používají na každé straně. Tento scénář umožňuje používat službu Azure Rights Management s místními službami.

  • Obecná ochrana (.pfile):: Když služba Azure Rights Management obecně chrání soubor, tok je v podstatě stejný pro ochranu obsahu s tím rozdílem, že klient SLUŽBY RMS vytvoří zásadu, která uděluje všechna práva. Když se soubor použije, dešifruje se před předáním cílové aplikaci. Tento scénář umožňuje chránit všechny soubory, i když nativně nepodporují RMS.

  • Účty Microsoft: Azure Information Protection může autorizovat e-mailové adresy pro použití při ověřování pomocí účtu Microsoft. Ne všechny aplikace ale můžou otevřít chráněný obsah, když se pro ověřování používá účet Microsoft. Další informace.

Další kroky

Další informace o službě Azure Rights Management najdete v dalších článcích v části Vysvětlení a prozkoumání , například jak aplikace podporují službu Azure Rights Management, abyste se dozvěděli, jak se vaše stávající aplikace můžou integrovat se službou Azure Rights Management, aby poskytovaly řešení ochrany informací.

Projděte si terminologii služby Azure Information Protection , abyste se seznámili s termíny, se kterými se můžete setkat při konfiguraci a používání služby Azure Rights Management, a nezapomeňte před zahájením nasazení také zkontrolovat požadavky na Azure Information Protection . Pokud se chcete rovnou ponořit a vyzkoušet si ho sami, použijte rychlý start a kurzy:

Pokud jste připraveni začít nasazovat ochranu dat pro vaši organizaci, použijte plán nasazení AIP pro klasifikaci, označování popisky a ochranu kroků nasazení a odkazy na návody.