Azure RMS 的工作原理How does Azure RMS work? 揭秘Under the hood

适用于: Azure 信息保护Office 365Applies to: Azure Information Protection, Office 365

了解 Azure RMS 工作原理时的一个要点是,Azure 信息保护的这种数据保护服务不会在保护过程中查看或存储你的数据。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. 要保护的信息永远不会发送或存储到 Azure 中,除非显式将其存储在 Azure 中,或者使用其他可用于在 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 只会在文档中保存数据,除已获授权的用户和服务以外,其他任何人都无法读取该文档:Azure RMS simply makes the data in a document unreadable to anyone other than authorized users and services:

  • 数据在应用程序级别进行加密,并包含策略用于定义该文档的授权用法。The data is encrypted at the application level and includes a policy that defines the authorized use for that document.

  • 当合法用户使用受保护的文档,或者已获授权的服务处理文档时,将会解密文档中的数据,并强制实施策略中定义的权限。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.

下图在较高级别显示了此过程的工作方式。At a high level, you can see how this process works in the following picture. 包含机密公式的文档将受到保护,然后成功地由已获授权的用户或服务成功打开。A document containing the secret formula is protected, and then successfully opened by an authorized user or service. 文档由内容密钥(图中的绿色钥匙)保护。The document is protected by a content key (the green key in this picture). 每个文档的内容密钥都是唯一的,它放置在文件标头中,并受 Azure 信息保护租户根密钥(图中的红色钥匙)保护。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). 可以生成并由 Microsoft 管理租户密钥,也可以生成和管理自己的租户密钥。Your tenant key can be generated and managed by Microsoft, or you can generate and manage your own tenant key.

在整个保护过程中,当 Azure RMS 加密、解密、授权以及强制实施限制时,机密公式永远不会发送到 Azure。Throughout the protection process when Azure RMS is encrypting and decrypting, authorizing, and enforcing restrictions, the secret formula is never sent to Azure.

Azure RMS 如何保护文件

有关所发生情况的详细说明,请参阅本文中的 Azure RMS 工作原理演练:首次使用、内容保护、内容使用部分。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.

有关 Azure RMS 使用的算法和密钥长度的技术详细信息,请参阅下一部分。For technical details about the algorithms and key lengths that Azure RMS uses, see the next section.

Azure RMS 使用的加密控制:算法和密钥长度Cryptographic controls used by Azure RMS: Algorithms and key lengths

即使你不太了解此技术的工作原理,也可能会被问到它使用的加密控件。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. 例如,确认安全保护是否符合行业标准时。For example, to confirm that the security protection is industry-standard.

加密控件Cryptographic controls 在 Azure RMS 中使用Use in Azure RMS
算法:AESAlgorithm: AES

密钥长度:128 位和 256 位 [1]Key length: 128 bits and 256 bits [1]
内容保护Content protection
算法:RSAAlgorithm: RSA

密钥长度:2048 位 [2]Key length: 2048 bits [2]
密钥保护Key protection
SHA-256SHA-256 证书签名Certificate signing
脚注 1Footnote 1

Azure 信息保护客户端在以下情况中使用 256 位:256 bits is used by the Azure Information Protection client in the following scenarios:

  • 常规保护 (.pfile)。Generic protection (.pfile).

  • 当文档受到 PDF 加密的 ISO 标准保护时,PDF 文档将受到本机保护,或者生成的受保护文档具有 .ppdf 文件扩展名。Native protection for PDF documents when the document has been protected with the ISO standard for PDF encryption, or the resulting protected document has a .ppdf file name extension.

  • 文本或映像文件(例如 .ptxt 或 .pjpg)的本机保护。Native protection for text or image files (such as .ptxt or .pjpg).

脚注 2Footnote 2

2048 位是激活 Azure Rights Management 服务时的密钥长度。2048 bits is the key length when the Azure Rights Management service is activated. 1024 位支持以下可选方案:1024 bits is supported for the following optional scenarios:

  • 在从本地进行迁移的过程中 - 如果 AD RMS 群集在加密模式 1 中运行。During a migration from on-premises if the AD RMS cluster is running in Cryptographic Mode 1.

  • 用于迁移前在本地创建的存档密钥,以便迁移后可以继续通过 Azure Rights Management 服务打开先前由 AD RMS 保护的内容。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.

如何存储和保护 Azure RMS 加密密钥How the Azure RMS cryptographic keys are stored and secured

对于受 Azure RMS 保护的每个文档或电子邮件,Azure RMS 都会创建一个 AES 密钥(称为“内容密钥”),并将该密钥嵌入到文档中,并在文档的所有版本中进行保存。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.

内容密钥作为文档中的策略的一部分,使用组织的 RSA 密钥(称为“Azure 信息保护租户密钥”)进行保护,并且策略也由文档的作者签名。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. 此租户密钥由受 Azure Rights Management 服务保护的组织的所有文档和电子邮件共有,如果组织使用的是客户管理的租户密钥(称为“自带密钥”或 BYOK),则此密钥只能由 Azure 信息保护管理员更改。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).

此租户密钥在 Microsoft Online Services 中、在高度控制的环境中和严密监视下进行保护。This tenant key is protected in Microsoft’s online services, in a highly controlled environment and under close monitoring. 使用客户托管的租户密钥 (BYOK) 时,通过在每个 Azure 区域中使用一组高端硬件安全模块 (HSM) 增强了此安全性,从而在任何情况下都无法提取、导出或共享这些密钥。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. 有关租户密钥和 BYOK 的详细信息,请参阅计划和实施 Azure 信息保护租户密钥For more information about the tenant key and BYOK, see Planning and implementing your Azure Information Protection tenant key.

发送到 Windows 设备的许可证和证书使用客户端设备私钥(用户在设备上第一次使用 Azure RMS 时创建)进行保护。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. 而该私钥则使用客户端上的 DPAPI 进行保护,DPAPI 使用从用户的密码派生的密钥来保护这些机密。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. 在移动设备上,只使用这些密钥一次,因此由于这些密钥不存储在客户端上,而无需在设备上保护这些密钥。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.

Azure RMS 工作原理演练:首次使用、内容保护、内容使用Walkthrough of how Azure RMS works: First use, content protection, content consumption

为了更详细地了解 Azure RMS 的工作原理,让我们通过在激活 Azure Rights Management 服务之后,当用户首次在其 Windows 计算机上使用 Rights Management 服务(有时称为初始化用户环境或引导的过程)时,保护内容(文档或电子邮件),然后使用(打开并使用)被其他某人保护的内容,来演练一个典型的工作流。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.

初始化用户环境后,该用户可以保护文档,或使用该计算机上的受保护文档。After the user environment is initialized, that user can then protect documents or consume protected documents on that computer.

备注

如果此用户移至另一台 Windows 计算机,或另一个用户使用这同一台 Windows 计算机,请重复该初始化过程。If this user moves to another Windows computer, or another user uses this same Windows computer, the initialization process is repeated.

初始化用户环境Initializing the user environment

在用户可以保护内容或使用 Windows 计算机上的受保护内容之前,必须在设备上准备用户环境。Before a user can protect content or consume protected content on a Windows computer, the user environment must be prepared on the device. 这是一次性的过程,当用户尝试保护或使用受保护内容时会自动发生,无需用户干预:This is a one-time process and happens automatically without user intervention when a user tries to protect or consume protected content:

RMS 客户端激活流程 - 步骤 1,对客户端进行身份验证

步骤 1 中发生的情况:计算机上的 RMS 客户端首先连接到 Azure Rights Management 服务,并通过使用其 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.

将用户的帐户与 Azure Active Directory 联合时,会自动进行这种身份验证,并且不会提示用户输入凭据。When the user’s account is federated with Azure Active Directory, this authentication is automatic and the user is not prompted for credentials.

RMS 客户端激活-步骤 2,证书已下载到客户端

步骤 2 中发生的情况:对用户进行身份验证后,连接将自动重定向到组织的 Azure 信息保护租户,该租户将颁发证书,让用户在 Azure Rights Management 服务上进行身份验证,以便使用受保护内容并脱机保护内容。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.

其中一个证书是通常缩写为 RAC 的权限帐户证书。One of these certificates is the rights account certificate, often abbreviated to RAC. 此证书对用户进行身份验证,以便在31天内 Azure Active Directory 和有效。This certificate authenticates the user to Azure Active Directory and is valid for 31 days. 如果用户帐户仍然在 Azure Active Directory 中并且启用了该帐户,RMS 客户端将自动续订证书。The certificate is automatically renewed by the RMS client, providing the user account is still in Azure Active Directory and the account is enabled. 该证书不可由管理员进行配置。This certificate is not configurable by an administrator.

证书副本存储在 Azure 中,因此,如果用户转移到另一台设备,将使用相同的密钥创建证书。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.

内容保护Content protection

当用户保护文档时,RMS 客户端将对未受保护的文档执行以下操作:When a user protects a document, the RMS client takes the following actions on an unprotected document:

RMS 文档保护 - 步骤 1,文档已加密

步骤 1 中发生的情况:RMS 客户端创建一个随机密钥 (内容密钥),并结合使用此密钥与 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.

RMS 文档保护 - 步骤 2,策略已创建

步骤 2 中发生的情况:RMS 客户端随后会为文档创建一个包含策略的证书,策略包括用户或组的使用权和其他限制,例如过期日期。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. 这些设置可在管理员之前配置的模板中进行定义,或在内容受保护时进行指定(有时称为“临时策略”)。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").

用于标识所选用户和组的主要 Azure AD 属性是 Azure AD ProxyAddresses 属性,该属性用于存储用户或组的所有电子邮件地址。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. 但是,如果用户帐户的 AD ProxyAddresses 属性中没有任何值,则改用用户的 UserPrincipalName 值。However, if a user account doesn't have any values in the AD ProxyAddresses attribute, the user's UserPrincipalName value is used instead.

然后,RMS 客户端使用初始化用户环境时获取的组织密钥,并使用此密钥来加密策略和对称内容密钥。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. RMS 客户端还使用初始化用户环境时获得的用户证书对策略进行签名。The RMS client also signs the policy with the user’s certificate that was obtained when the user environment was initialized.

RMS 文档保护 - 步骤 3,策略已嵌入到文档中

步骤3中发生的情况:最后,RMS 客户端将该策略嵌入到一个文件中,该文件的正文是以前加密的文档的正文,它们共同构成了一个受保护的文档。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.

可将此文档存储在任意位置,或者使用任何方法将其共享,加密的文档始终附带该策略。This document can be stored anywhere or shared by using any method, and the policy always stays with the encrypted document.

内容使用Content consumption

当用户想要使用受保护的文档时,将通过请求对 Azure Rights Management 服务的访问来启动 RMS 客户端:When a user wants to consume a protected document, the RMS client starts by requesting access to the Azure Rights Management service:

RMS 文档使用 - 步骤 1,用户已通过身份验证并获取权限列表

步骤 1 中发生的情况:经过身份验证的用户将文档策略和用户的证书发送到 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. 服务解密并评估该策略,并生成用户对该文档拥有的权限列表(如果有)。The service decrypts and evaluates the policy, and builds a list of rights (if any) the user has for the document. 若要标识用户,可将 Azure AD ProxyAddresses 属性用于用户的帐户和该用户所属的组。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. 出于性能原因,会缓存组成员身份。For performance reasons, group membership is cached. 如果用户帐户的 Azure AD ProxyAddresses 属性中没有任何值,则改用 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.

RMS 文档使用 - 步骤 2,使用许可证已返回到客户端

步骤 2 中发生的情况:然后,服务将从已解密的策略中提取 AES 内容密钥。What's happening in step 2: The service then extracts the AES content key from the decrypted policy. 然后,使用通过请求获取的用户公共 RSA 密钥来加密此密钥。This key is then encrypted with the user’s public RSA key that was obtained with the request.

重新加密的内容密钥将连同用户权限列表一起嵌入到加密的使用许可证中,随后使用许可证将返回到 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.

RMS 文档使用 - 步骤 3,文档已解密并且权限已强制实施

步骤 3 中发生的情况:最后,RMS 客户端将采用加密的使用许可证,并使用其自身的用户私钥来解密该许可证。What's happening in step 3: Finally, the RMS client takes the encrypted use license and decrypts it with its own user private key. 这样,RMS 客户端便可以根据需要解密文档的正文,并在屏幕上呈现其内容。This lets the RMS client decrypt the document’s body as it is needed and render it on the screen.

客户端还将解密权限列表,并将其传递到应用程序,应用程序将在应用程序的用户界面中强制实施这些权限。The client also decrypts the rights list and passes them to the application, which enforces those rights in the application’s user interface.

备注

组织外部的用户使用保护的内容时,使用流程是相同的。When users who are external to your organization consume content that you've protected, the consumption flow is the same. 对于此方案,有所更改的是如何对用户进行身份验证。What changes for this scenario, is how the user is authenticated. 有关详细信息,请参阅如果我与公司之外的用户共享受保护文档,该用户如何进行身份验证?For more information, see When I share a protected document with somebody outside my company, how does that user get authenticated?

变体Variations

前面的演练包括标准方案,但存在一些变体:The preceding walkthroughs cover the standard scenarios but there are some variations:

  • 电子邮件保护:将 Exchange Online 和具有新功能的 Office 365 消息加密用于保护电子邮件消息时,还可通过社会标识提供者或使用一次性密码进行联合身份验证。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. 其中,流程非常相似,而出站电子邮件临时缓存副本中的 Web 浏览器会话服务端发生内容使用的除外。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.

  • 移动设备:当移动设备通过 Azure Rights Management 服务保护或使用文件时,流程要简单得多。Mobile devices: When mobile devices protect or consume files with the Azure Rights Management service, the process flows are much simpler. 因为每个事务(保护或使用内容)是独立的,移动设备首先不会经历用户初始化过程。Mobile devices don’t first go through the user initialization process because instead, each transaction (to protect or consume content) is independent. 与 Windows 计算机一样,移动设备将连接到 Azure Rights Management 服务并进行身份验证。As with Windows computers, mobile devices connect to the Azure Rights Management service and authenticate. 为了保护内容,移动设备将提交一个策略,然后 Azure Rights Management 服务将为移动设备发送一个发布许可证和对称密钥用于保护文档。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. 为了使用内容,当移动设备连接到 Azure Rights Management 服务并进行身份验证时,它们将文档策略发送到 Azure Rights Management 服务,并请求一个使用许可证以使用文档。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. 在响应中,Azure Rights Management 服务会将所需的密钥和限制发送到移动设备。In response, the Azure Rights Management service sends the necessary keys and restrictions to the mobile devices. 这两个进程使用 TLS 来保护密钥交换和其他通信。Both processes use TLS to protect the key exchange and other communications.

  • RMS 连接器:当 Azure Rights Management 服务与 RMS 连接器结合使用时,流程保持不变。RMS connector: When the Azure Rights Management service is used with the RMS connector, the process flows remain the same. 唯一的差别在于,连接器充当本地服务(如 Exchange Server 和 SharePoint Server)与 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. 连接器本身不执行任何操作,例如用户环境初始化,或者加密或解密。The connector itself does not perform any operations, such as the initialization of the user environment, or encryption or decryption. 它只会中继通常要定向到 AD RMS 服务器的通信,处理每一端使用的协议之间的转换。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. 此方案让你可以将 Azure Rights Management 服务与本地服务结合使用。This scenario lets you use the Azure Rights Management service with on-premises services.

  • 常规保护 (.pfile):当 Azure Rights Management 服务对文件提供一般性保护时,流程基本上与内容保护相同,不过,RMS 客户端将创建一个授予所有权限的策略。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. 使用该文件时,会先将它解密,然后将它传递到目标应用程序。When the file is consumed, it is decrypted before it is passed to the target application. 使用这种方案可以保护所有文件,即使它们本机不支持 RMS。This scenario lets you protect all files, even if they don’t natively support RMS.

  • “Microsoft 帐户”****:使用 Microsoft 帐户对电子邮件地址进行身份验证时,Azure 信息保护可以授权其可供使用。Microsoft accounts: Azure Information Protection can authorize email addresses for consumption when they are authenticated with a Microsoft account. 但是,并非所有应用程序都可以在使用 Microsoft 帐户进行身份验证时打开受保护的内容。However, not all applications can open protected content when a Microsoft account is used for authentication. 详细信息More information.

后续步骤Next steps

若要了解 Azure Rights Management 服务的详细信息,请参阅了解和探索部分中的其他文章(如应用程序如何支持 Azure Rights Management 服务),了解现有应用程序如何通过与 Azure Rights Management 集成来提供信息保护解决方案。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.

请查看 Azure 信息保护术语,熟悉在配置和使用 Azure Rights Management 服务时可能遇到的术语。此外,请确保在开始部署前查看 Azure 信息保护的要求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. 如果要进一步研究并亲自尝试一下,请使用编辑策略并创建新标签教程。If you want to dive right in and try it out for yourself, use the Edit the policy and create a new label tutorial.

做好开始为组织部署数据保护的准备时,请使用 Azure 信息保护部署路线图获取部署步骤和操作说明链接。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.

提示

提示有关其他信息和帮助,请使用 Azure 信息保护的信息和支持中的资源与链接。For additional information and help, use the resources and links in Information and support for Azure Information Protection.