Jak Azure RMS funguje?How does Azure RMS work? Pod pokličkouUnder the hood

Platí pro: Azure Information Protection, Office 365Applies to: Azure Information Protection, Office 365

Důležité pochopit o fungování Azure RMS, je, že tato služba ochrany dat z Azure Information Protection, ani neukládá vaše data v rámci procesu ochrany.An important thing to understand about how Azure RMS works, is that this data protection service from Azure Information Protection, does not see or store your data as part of the protection process. Informace, které chráníte je nikdy odeslat nebo uložená v Azure, pokud je výslovně uložit v Azure nebo nepoužijete jinou cloudovou službu, která je uloží v Azure.Information that you protect is never sent to or stored in Azure, unless you explicitly store it in Azure or use another cloud service that stores it in Azure. Azure RMS jednoduše vytvoří data v dokumentu, který je nečitelný pro všechny, kteří nejsou autorizovanými uživateli a službami:Azure RMS simply makes the data in a document unreadable to anyone other than authorized users and services:

  • Data se šifrují na úrovni aplikace a zahrnují zásadu, která definuje oprávněné použití tohoto dokumentu.The data is encrypted at the application level and includes a policy that defines the authorized use for that document.

  • Pokud chráněný dokument používán oprávněným uživatelem nebo je zpracován autorizovanou službou, data v dokumentu se dešifrují a jsou vynucována práva, které jsou definována v zásadách.When a protected document is used by a legitimate user or it is processed by an authorized service, the data in the document is decrypted and the rights that are defined in the policy are enforced.

Jak tento proces funguje uvidíte na vysoké úrovni na následujícím obrázku.At a high level, you can see how this process works in the following picture. Dokument obsahující tajný vzorec je chráněn a pak úspěšně otevřen oprávněným uživatelem nebo službou.A document containing the secret formula is protected, and then successfully opened by an authorized user or service. Dokument je chráněn pomocí klíče obsahu (zelený klíč na tomto obrázku).The document is protected by a content key (the green key in this picture). Je jedinečný pro každý dokument a je umístěn v záhlaví souboru, kde je chráněn kořenovým klíčem tenanta Azure Information Protection (červený klíč na tomto obrázku).It is unique for each document and is placed in the file header where it is protected by your Azure Information Protection tenant root key (the red key in this picture). Váš klíč tenanta může být generován a spravován společností Microsoft nebo můžete vygenerovat a spravovat vlastní klíč tenanta.Your tenant key can be generated and managed by Microsoft, or you can generate and manage your own tenant key.

V celém procesu ochrany, když Azure RMS šifruje a dešifruje, autorizuje a vynucuje omezení se tajný vzorec nikdy neodesílá do Azure.Throughout the protection process when Azure RMS is encrypting and decrypting, authorizing, and enforcing restrictions, the secret formula is never sent to Azure.

Jak Azure RMS chrání soubor

Podrobný popis co se děje naleznete v části Prohlídka pracovního postupu Azure RMS: první použití, ochrana obsahu, spotřeba obsahu v tomto článku.For a detailed description of what’s happening, see the Walkthrough of how Azure RMS works: First use, content protection, content consumption section in this article.

Technické podrobnosti o algoritmech a délce klíčů, které Azure RMS používá, naleznete v další části.For technical details about the algorithms and key lengths that Azure RMS uses, see the next section.

Kryptografické prvky používané službou Azure RMS: Algoritmy a délky klíčůCryptographic controls used by Azure RMS: Algorithms and key lengths

I v případě, že nemusíte vědět podrobně fungování této technologie, můžete být požádáni o ovládání kryptografie tak používá.Even if you don't need to know in detail how this technology works, you might be asked about the cryptographic controls that it uses. Chcete-li například potvrďte, že je ochrana zabezpečení Standardní.For example, to confirm that the security protection is industry-standard.

Ovládání kryptografieCryptographic controls Použití v Azure RMSUse in Azure RMS
Algoritmus: AESAlgorithm: AES

Délka klíče: 128 bitů a 256 bitů [1]Key length: 128 bits and 256 bits [1]
Ochrana dokumentaceDocumentation protection
Algoritmus: RSAAlgorithm: RSA

Délka klíče: 2 048 bitů [2]Key length: 2048 bits [2]
Ochrana klíčeKey protection
SHA-256SHA-256 Podepisování certifikátuCertificate signing
Poznámka pod čarou 1Footnote 1

256 bitů se používá klientem služby Azure Information Protection a aplikací pro sdílení obsahu služby Rights Management pro nativní a obecnou ochranu, když soubor obsahuje příponu názvu souboru .ppdf nebo je chráněn text nebo soubor bitové kopie (například .ptxt nebo .pjpg).256 bits is used by the Azure Information Protection client and the Rights Management sharing application for generic protection and native protection when the file has a .ppdf file name extension or is a protected text or image file (such as .ptxt or .pjpg).

Poznámka pod čarou 2Footnote 2

2 048 bitů je délka klíče, když služba Azure Rights Management je aktivována.2048 bits is the key length when the Azure Rights Management service is activated. 1024 bitů je podporována pro následující volitelné scénáře:1024 bits is supported for the following optional scenarios:

  • Při migraci z místní v případě, že cluster AD RMS běží v kryptografického režimu 1.During a migration from on-premises if the AD RMS cluster is running in Cryptographic Mode 1.

  • Po migraci z místního, pokud byl clusteru AD RMS pomocí Exchange Online.After a migration from on-premises, if the AD RMS cluster was using Exchange Online.

  • Pro archivovaných klíčů, které byly vytvořeny na místě před migrací, aby obsah, který byl předtím chráněný službou AD RMS dál otevřít pomocí služby Azure Rights Management post migrace.For archived keys that were created on-premises before the migration, so that content that was previously protected by AD RMS can continue to be opened by the Azure Rights Management service post migration.

  • Pokud se zákazníci rozhodnou použít vlastní klíč (BYOK) pomocí služby Azure Key Vault.If customers choose to bring their own key (BYOK) by using Azure Key Vault. Podporuje Azure Information Protection délky klíčů 1024 bitů a 2048 bitů.Azure Information Protection supports key lengths of 1024 bits and 2048 bits. Pro vyšší zabezpečení doporučujeme délku klíče 2 048 bitů.For higher security, we recommend a key length of 2048 bits.

Ukládání a zabezpečení kryptografických klíčů Azure RMSHow the Azure RMS cryptographic keys are stored and secured

Pro každý dokument nebo e-mail, který je chráněný službou Azure RMS, vytvoří služba Azure RMS jeden klíč standardu AES („klíč obsahu“) a tento klíč je vložen do dokumentu a přetrvává v průběhu úprav dokumentu.For each document or email that is protected by Azure RMS, Azure RMS creates a single AES key (the "content key"), and that key is embedded to the document, and persists through editions of the document.

Klíč obsahu je chráněný pomocí klíče RSA organizace („klíče tenanta Azure Information Protection“) v rámci zásad v dokumentu a zásady jsou také podepsány autorem dokumentu.The content key is protected with the organization’s RSA key (the "Azure Information Protection tenant key") as part of the policy in the document, and the policy is also signed by the author of the document. Tento klíč tenanta je společný pro všechny dokumenty a e-maily, které jsou chráněné službou Azure Rights Management pro organizaci, a tento klíč může změnit jenom správce Azure Information Protection, pokud organizace používá klíč tenanta, který je spravovaný zákazníkem (označuje se jako „přineste si vlastní klíč“ –Bring Your Own Key (BYOK)).This tenant key is common to all documents and emails that are protected by the Azure Rights Management service for the organization and this key can only be changed by an Azure Information Protection administrator if the organization is using a tenant key that is customer-managed (known as "bring your own key", or BYOK).

Tento klíč tenanta je chráněn v online službách společnosti Microsoft, ve vysoce řízeném prostředí a za pečlivého monitorování.This tenant key is protected in Microsoft’s online services, in a highly controlled environment and under close monitoring. Pokud používáte klíč tenanta spravovaného zákazníkem (BYOK), je toto zabezpečení rozšířeno pomocí pole špičkových modulů hardwarového zabezpečení (HSM) v každé oblasti Azure bez možnosti klíčů extrakce, exportu nebo za žádných okolností sdílet.When you use a customer-managed tenant key (BYOK), this security is enhanced by the use of an array of high-end hardware security modules (HSMs) in each Azure region, without the ability for the keys to be extracted, exported, or shared under any circumstances. Další informace o klíči tenanta a BYOK najdete v článku Plánování a implementace klíče tenanta služby Azure Information Protection.For more information about the tenant key and BYOK, see Planning and implementing your Azure Information Protection tenant key.

Licence a certifikáty, které se odesílají do zařízení se systémem Windows jsou chráněny soukromým klíčem klientského zařízení, který se vytvoří při prvním použití Azure RMS uživatelem v zařízení.Licenses and certificates that are sent to a Windows device are protected with the client’s device private key, which is created the first time a user on the device uses Azure RMS. Tento soukromý klíč je pak chráněn rozhraním DPAPI na straně klienta, které chrání tato tajná data pomocí klíče odvozeného z hesla uživatele.This private key, in turn, is protected with DPAPI on the client, which protects these secrets by using a key derived from the user’s password. Na mobilních zařízeních se klíče používají pouze jednou, takže vzhledem k tomu, že nejsou uloženy v klientských počítačích, není třeba tyto klíče chránit na zařízení.On mobile devices, the keys are used only one time, so because they are not stored on the clients, these keys don’t need to be protected on the device.

Prohlídka funkce Azure RMS: první použití, ochrana obsahu, spotřeba obsahuWalkthrough of how Azure RMS works: First use, content protection, content consumption

Abyste lépe pochopili, jak Azure RMS funguje, projděme si obvyklý tok, když uživatel po aktivaci služby Azure Rights Management poprvé použije službu Rights Management na svém počítači s Windows (tento proces se někdy označuje jako inicializace uživatelského prostředí nebo zavádění), chrání obsah (dokumenty nebo e-maily) a pak využívá (otevírá a používá) obsah, který je chráněný jiným uživatelem.To understand in more detail how Azure RMS works, let's walk through a typical flow after the Azure Rights Management service is activated and when a user first uses the Rights Management service on their Windows computer (a process sometimes known as initializing the user environment or bootstrapping), protects content (a document or email), and then consumes (opens and uses) content that has been protected by somebody else.

Po inicializaci uživatelského prostředí může tento uživatel chránit dokumenty nebo využívat chráněné dokumenty v daném počítači.After the user environment is initialized, that user can then protect documents or consume protected documents on that computer.

Poznámka

Pokud se tento uživatel přesune do jiného počítače se systémem Windows nebo tento stejný počítač se systémem Windows používá jiný uživatel, proces inicializace se opakuje.If this user moves to another Windows computer, or another user uses this same Windows computer, the initialization process is repeated.

Inicializace uživatelského prostředíInitializing the user environment

Předtím, než uživatel může chránit obsah nebo využívat chráněný obsah na počítači se systémem Windows, musí být v zařízení připraveno uživatelské prostředí.Before a user can protect content or consume protected content on a Windows computer, the user environment must be prepared on the device. To je jednorázový proces a dochází k němu automaticky bez zásahu uživatele, když se uživatel pokusí chránit nebo využívat chráněný obsah:This is a one-time process and happens automatically without user intervention when a user tries to protect or consume protected content:

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

Co se děje v kroku 1: Klient RMS v počítači se nejprve připojí ke službě Azure Rights Management a ověřuje uživatele pomocí jeho účtu Azure Active Directory.What's happening in step 1: The RMS client on the computer first connects to the Azure Rights Management service, and authenticates the user by using their Azure Active Directory account.

Když je uživatelský účet federovaný pomocí služby Azure Active Directory, je toto ověřování automatické a uživatel nebude vyzván k zadání přihlašovacích údajů.When the user’s account is federated with Azure Active Directory, this authentication is automatic and the user is not prompted for credentials.

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 na tenanta Azure Information Protection pro organizaci, která vydává certifikáty umožňující uživateli provést ověření ve službě Azure Rights Management, aby bylo možné využívat chráněný obsah a chránit obsah v offline režimu.What's happening in step 2: After the user is authenticated, the connection is automatically redirected to the organization’s Azure Information Protection tenant, which issues certificates that let the user authenticate to the Azure Rights Management service in order to consume protected content and to protect content offline.

Jedním z těchto certifikátů je certifikát účtu práv, často se používá zkratka RAC.One of these certificates is the rights account certificate, often abbreviated to RAC. Tento certifikát ověřuje uživatele do Azure Active Directory a je platné po dobu 31 den.This certificate authenticates the user to Azure Active Directory and is valid for 31 day. Certifikát je automaticky obnovit klienta služby RMS, poskytuje uživatelský účet je stále v Azure Active Directory a účet je povolen.The certificate is automatically renewed by the RMS client, providing the user account is still in Azure Active Directory and the account is enabled. Tento certifikát se nedá konfigurovat správcem.This certificate is not configurable by an administrator.

Kopii tohoto certifikátu se ukládají v Azure, takže pokud se uživatel přesune na jiné zařízení, certifikáty budou vytvořeny pomocí stejné klíče.A copy of this certificate is stored in Azure so that if the user moves to another device, the certificates are created by using the same keys.

Ochrana obsahuContent protection

Když uživatel chrání dokument, klient služby RMS provede následující akce u nechráněného dokumentu:When a user protects a document, the RMS client takes the following actions on an unprotected document:

Ochrana dokumentu RMS – krok 1, dokument se zašifruje

Co se děje v kroku 1: klient RMS vytvoří náhodný klíč (klíč obsahu) a zašifruje dokument pomocí tohoto klíče s algoritmem symetrického šifrování AES.What's happening in step 1: The RMS client creates a random key (the content key) and encrypts the document using this key with the AES symmetric encryption algorithm.

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

Co se děje v kroku 2: Klient RMS pak vytvoří certifikát, který obsahuje zásady pro dokument, jejichž součástí jsou práva k používání pro uživatele nebo skupiny a další omezení, například datum vypršení platnosti.What's happening in step 2: The RMS client then creates a certificate that includes a policy for the document that includes the usage rights for users or groups, and other restrictions, such as an expiration date. Tato nastavení lze definovat v šabloně, která správce dříve nakonfigurován, nebo zadaná v době, kdy je chráněný obsah (někdy označované jako "ad hoc zásady").These settings can be defined in a template that an administrator previously configured, or specified at the time the content is protected (sometimes referred to as an "ad hoc policy").

Hlavním atributem Azure AD, který se používá k identifikaci vybraných uživatelů a skupin, je atribut Azure AD proxyAddress, který uchovává všechny e-mailové adresy uživatele nebo skupiny.The main Azure AD attribute used to identify the selected users and groups is the Azure AD ProxyAddresses attribute, which stores all the email addresses for a user or group. Pokud však uživatelský účet nemá v atributu AD ProxyAddresses žádnou hodnotu, použije se hodnota UserPrincipalName daného uživatele.However, if a user account doesn't have any values in the AD ProxyAddresses attribute, the user's UserPrincipalName value is used instead.

Klient služby RMS pak použije klíč společnosti, který byl získán při inicializaci uživatelského prostředí, a použije tento klíč k šifrování zásad a klíče symetrického obsahu.The RMS client then uses the organization’s key that was obtained when the user environment was initialized and uses this key to encrypt the policy and the symmetric content key. Klient služby RMS také podepisuje zásady pomocí certifikátu uživatele, který byl získán při inicializaci uživatelského prostředí.The RMS client also signs the policy with the user’s certificate that was obtained when the user environment was initialized.

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ásady do souboru spolu s textem dříve šifrovaného dokumentu, což dohromady vytvoří chráněný dokument.What's happening in step 3: Finally, the RMs client embeds the policy into a file with the body of the document encrypted previously, which together comprise a protected document.

Tento dokument lze uložit kdekoli nebo sdílet pomocí libovolné metody a zásady vždy zůstanou u zašifrovaného dokumentu.This document can be stored anywhere or shared by using any method, and the policy always stays with the encrypted document.

Využívání obsahuContent consumption

Pokud chce uživatel využívat chráněný dokument, začne klient služby RMS žádostí o přístup ke službě Azure Rights Management:When a user wants to consume a protected document, the RMS client starts by requesting access to the Azure Rights Management service:

Využití dokumentu RMS – krok 1, uživatel je ověřený 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.What's happening in step 1: The authenticated user sends the document policy and the user’s certificates to the Azure Rights Management service. Služba dešifruje a vyhodnotí zásady a vytvoří seznam oprávnění (pokud existuje), které má uživatel k dokumentu.The service decrypts and evaluates the policy, and builds a list of rights (if any) the user has for the document. K identifikaci uživatele slouží atribut Azure AD ProxyAddresses pro účet uživatele a skupiny, kterých je daný uživatel členem.To identify the user, the Azure AD ProxyAddresses attribute is used for the user's account and groups to which the user is a member. Kvůli výkonu se členství ve skupinách ukládá do mezipaměti.For performance reasons, group membership is cached. Pokud uživatelský účet nemá v atributu Azure AD ProxyAddresses žádnou hodnotu, použije se hodnota Azure AD UserPrincipalName.If the user account has no values for the Azure AD ProxyAddresses attribute, the value in the Azure AD UserPrincipalName is used instead.

Využití dokumentu RMS – krok 2, licence k použití se vrátí ke klientovi

Co se děje v kroku 2: Služba poté rozbalí klíč obsahu AES z dešifrovaných zásad.What's happening in step 2: The service then extracts the AES content key from the decrypted policy. Tento klíč je poté zašifrován pomocí veřejného klíče RSA uživatele získaného v požadavku.This key is then encrypted with the user’s public RSA key that was obtained with the request.

Znovu zašifrovaný klíč obsahu se pak vloží do šifrované licence používání společně se seznamem uživatelských oprávnění, který je pak vrácen do klienta služby RMS.The re-encrypted content key is then embedded into an encrypted use license with the list of user rights, which is then returned to the RMS client.

Využívání dokumentu RMS – krok 3, dokumentu se dešifrují a jsou vynucována práva

Co se děje v kroku 3: nakonec klient služby RMS vezme šifrovanou licenci použití a dešifruje ji pomocí vlastního soukromého klíče uživatele.What's happening in step 3: Finally, the RMS client takes the encrypted use license and decrypts it with its own user private key. To umožňuje klientům služby RMS dešifrovat text dokumentu dle potřeby a vykreslit ho na obrazovce.This lets the RMS client decrypt the document’s body as it is needed and render it on the screen.

Klient také dešifruje seznam oprávnění a předává je do aplikace, která vynucuje tato práva v uživatelském rozhraní aplikace.The client also decrypts the rights list and passes them to the application, which enforces those rights in the application’s user interface.

Poznámka

Když uživatelé, kteří jsou mimo vaši organizaci, využívají obsah, u kterého jste nastavili ochranu, postup využití je stejný.When users who are external to your organization consume content that you've protected, the consumption flow is the same. V tomto scénáři se změní jen způsob ověření uživatele.What changes for this scenario, is how the user is authenticated. Další informace najdete v tématu Když sdílím chráněný dokument s někým, kdo nepracuje v moji společností, jak tento uživatel získá ověření?.For more information, see When I share a protected document with somebody outside my company, how does that user get authenticated?

OdchylkyVariations

Předchozí návody se týkají standardních scénářů, ale existuje několik odchylek:The preceding walkthroughs cover the standard scenarios but there are some variations:

  • E-mailu ochrany: když Exchange Online a šifrování zpráv Office 365 pomocí nové funkce, které se používá k ochraně e-mailové zprávy, ověřování pro používání můžete použít také federace se k poskytovateli sociální identity nebo pomocí jednorázové heslo.Email protection: When Exchange Online and Office 365 Message Encryption with new capabilities is used to protect email messages, authentication for consumption can also use federation with a social identity provider or by using a one-time passcode. Potom toky procesu jsou velmi podobné, s tím rozdílem, že spotřeba obsahu se stane, straně služby v rámci relace prohlížeče webové přes dočasně uložené v mezipaměti kopii odchozí e-mailu.Then, the process flows are very similar, except that content consumption happens service-side in a web browser session over a temporarily cached copy of the outbound email.

  • Mobilní zařízení: Když mobilní zařízení chrání nebo využívají soubory pomocí služby Azure Rights Management, jsou toky zpracování mnohem jednodušší.Mobile devices: When mobile devices protect or consume files with the Azure Rights Management service, the process flows are much simpler. Mobilní zařízení neprochází nejprve procesem inicializace uživatele, protože je místo toho každá transakce (při ochraně nebo využívání obsahu) nezávislá.Mobile devices don’t first go through the user initialization process because instead, each transaction (to protect or consume content) is independent. Podobně jako počítače s Windows se mobilní zařízení připojí ke službě Azure Rights Management a provedou ověření.As with Windows computers, mobile devices connect to the Azure Rights Management service and authenticate. V případě ochrany obsahu odešlou mobilní zařízení zásady a služba Azure Rights Management jim zašle licence pro publikování a symetrický klíč k ochraně dokumentu.To protect content, mobile devices submit a policy and the Azure Rights Management service sends them a publishing license and symmetric key to protect the document. V případě využívání obsahu mobilní zařízení po připojení ke službě Azure Rights Management a provedení ověření zašlou do služby Azure Rights Management zásady dokumentu a požádají o licenci k využívání dokumentu.To consume content, when mobile devices connect to the Azure Rights Management service and authenticate, they send the document policy to the Azure Rights Management service and request a use license to consume the document. Jako odpověď zašle služba Azure Rights Management do mobilních zařízení nezbytné klíče a omezení.In response, the Azure Rights Management service sends the necessary keys and restrictions to the mobile devices. Oba tyto procesy využívají TLS k ochraně výměny klíčů a další komunikaci.Both processes use TLS to protect the key exchange and other communications.

  • Konektor služby RMS: Když se služba Azure Rights Management používá s konektorem služby RMS, zůstávají toky zpracování stejné.RMS connector: When the Azure Rights Management service is used with the RMS connector, the process flows remain the same. Jediným rozdílem je to, že konektor funguje jako předávací článek mezi místními službami (například Exchange Server a SharePoint Server) a službou Azure Rights Management.The only difference is that the connector acts as a relay between the on-premises services (such as Exchange Server and SharePoint Server) and the Azure Rights Management service. Konektor sám neprovádí žádné operace, například inicializaci uživatelského prostředí, šifrování nebo dešifrování.The connector itself does not perform any operations, such as the initialization of the user environment, or encryption or decryption. Jednoduše předává komunikaci, která by obvykle přešla na server služby AD RMS řešící překlad mezi protokoly, které se používají na každé straně.It simply relays the communication that would usually go to an AD RMS server, handling the translation between the protocols that are used on each side. Tento scénář vám umožní používat službu Azure Rights Management s místními službami.This scenario lets you use the Azure Rights Management service with on-premises services.

  • Obecná ochrana (.pfile): Když služba Azure Rights Management obecně chrání soubor, je tok v podstatě stejný jako pro ochranu obsahu, ale s tím rozdílem, že klient služby RMS vytvoří zásadu, která uděluje všechna práva.Generic protection (.pfile): When the Azure Rights Management service generically protects a file, the flow is basically the same for content protection except that the RMS client creates a policy that grants all rights. Když je soubor zpracován, dešifruje se předtím, než je předán do cílové aplikace.When the file is consumed, it is decrypted before it is passed to the target application. Tento scénář umožňuje chránit všechny soubory i v případě, že nativně nepodporují RMS.This scenario lets you protect all files, even if they don’t natively support RMS.

  • Chráněné PDF (.ppdf): Když služba Azure Rights Management nativně chrání soubor sady Office, vytvoří také kopii tohoto souboru a chrání ji stejným způsobem.Protected PDF (.ppdf): When the Azure Rights Management service natively protects an Office file, it also creates a copy of that file and protects it in the same way. Jediným rozdílem je, že kopírování souborů probíhá ve formátu souboru PPDF, který klient služby Azure Information Protection a aplikace Sdílení RMS umí otevřít pouze pro účely zobrazení.The only difference is that the file copy is in PPDF file format, which the Azure Information Protection client viewer and the RMS sharing application knows how to open for viewing only. Tento scénář umožňuje odesílat chráněné přílohy prostřednictvím e-mailu, zároveň budete vědět, že příjemce v mobilním zařízení můžete vždy načíst i v případě mobilní zařízení neobsahuje aplikaci, která nativně podporuje chráněné soubory sady Office.This scenario lets you send protected attachments via email, knowing that the recipient on a mobile device can always read them even if the mobile device doesn’t have an app that natively supports protected Office files.

  • Účty Microsoft: Azure Information Protection může autorizovat e-mailové adresy pro používání, když se ověří pomocí účtu Microsoft.Microsoft accounts: Azure Information Protection can authorize email addresses for consumption when they are authenticated with a Microsoft account. Ne všechny aplikace však můžete otevřít chráněný obsah, když účet Microsoft se používá k ověřování.However, not all applications can open protected content when a Microsoft account is used for authentication. Další informace.More information.

Další krokyNext steps

Více informací o službě Azure Rights Management najdete v dalších článcích v části Porozumění a prozkoumávání, třeba v článku Jak aplikace podporují službu Azure Rights Management, kde se dozvíte, jak integrovat existující aplikace s Azure Rights Management a poskytovat řešení pro ochranu informací.To learn more about the Azure Rights Management service, use the other articles in the Understand & Explore section, such as How applications support the Azure Rights Management service to learn how your existing applications can integrate with Azure Rights Management to provide an information protection solution.

Projděte si terminologii pro Azure Information Protection a seznamte se s podmínkami, se kterými se můžete setkat při konfiguraci a používání služby Azure Rights Management. Než zahájíte nasazení, podívejte se také na požadavky pro Azure Information Protection.Review Terminology for Azure Information Protection so that you’re familiar with the terms that you might come across as you’re configuring and using the Azure Rights Management service, and be sure to also check Requirements for Azure Information Protection before you start your deployment. Pokud si chcete službu rovnou vyzkoušet sami, projděte si Rychlý úvodní kurz pro Azure Information Protection.If you want to dive right in and try it out for yourself, use the Quick start tutorial for Azure Information Protection.

Pokud máte všechno připravené a chcete začít s nasazením ochrany dat v organizaci, použijte Plán nasazení služby Azure Information Protection, který vás provede kroky nasazení a nabídne odkazy na návody.If you’re ready to start deploying data protection for your organization, use the Azure Information Protection deployment roadmap for your deployment steps and links for how-to instructions.

Tip

Další informace a pomoc najdete ve zdrojích informací a odkazech v tématu Informace a podpora služby Azure Information Protection.For additional information and help, use the resources and links in Information and support for Azure Information Protection.

KomentářeComments

Před přidáním komentáře se podívejte na naše pravidla organizace.Before commenting, we ask that you review our House rules.