若要深入了解 Azure Rights Management 服务 的工作原理，请使用以下信息。 无需知道此信息级别，就可以配置或应用加密设置来保护数据。
注意
当 Azure Rights Management 服务作为独立产品而不是Microsoft Purview 信息保护的一部分提供时，它通常缩写为 Azure RMS。 本文图片中显示了此缩写。
了解 Azure Rights Management 服务的一个重要概念是，此服务不会在加密过程中查看或存储数据。 加密的信息永远不会发送到 Azure 或存储在 Azure 中，除非你将其显式存储在 Azure 中，或者使用将它存储在 Azure 中的另一个云服务。 Azure Rights Management 服务只是使除授权用户和服务以外的任何人无法读取项目中的数据：
数据在应用程序级别加密，并包含一个策略，用于定义该项的授权用途。
当合法用户使用加密项或由授权服务处理时，将解密该项中的数据，并强制实施策略中定义的权限。
概括而言，下图显示了此过程的工作原理。 包含机密公式的文档已加密，然后由授权用户或服务成功打开。 此图中的绿色密钥 (内容密钥) 对文档进行加密。 内容密钥对于每个文档都是唯一的，并放置在文件头中，其中 Azure Rights Management 租户根密钥 (此图) 中的红色密钥进行加密。 可以通过Microsoft生成和管理租户密钥，也可以生成和管理自己的租户密钥。
在 Azure Rights Management 服务加密和解密、授权和执行限制的整个加密过程中，机密公式永远不会发送到 Azure。
有关所发生情况的详细说明，请参阅本文中的 演练服务工作原理：首次使用、内容加密、内容使用 部分。
有关服务使用的算法和密钥长度的详细信息，请参阅下一部分。
加密控制：算法和密钥长度
即使不需要详细了解此技术的工作原理，也可能会询问你它使用的加密控件。 例如，确认加密是行业标准。
| 加密控制 | 在 Azure Rights Management 服务中使用 |
|---|---|
| 算法：AES 密钥长度：128 位和 256 位 [1] |
内容加密 |
| 算法：RSA 密钥长度：2048 位 [2] |
密钥加密 |
| SHA-256 | 证书签名 |
脚注 1
Microsoft Purview 信息保护客户端在以下方案中使用 256 位：
通用加密 (.pfile) 。
如果文档已使用用于 PDF 加密的 ISO 标准进行加密，或者生成的加密文档具有 .p pdf 文件扩展名，则 PDF 文档的本机加密。
文本或图像文件 (（如 .ptxt 或 .pjpg) ）的本机加密。
脚注 2
激活 Azure Rights Management 服务时，2048 位是密钥长度。 以下可选方案支持 1024 位：
从本地迁移期间，如果 AD RMS 群集在加密模式 1 中运行。
对于迁移之前在本地创建的存档密钥，以便 Azure Rights Management 服务在迁移后可以继续打开以前由 AD RMS 加密的内容。
如何存储和保护加密密钥
对于受 Azure Rights Management 服务保护的每个文档或电子邮件，该服务 (“内容密钥”) 创建一个 AES 密钥，并且该密钥将嵌入到文档中，并持续到文档的各个版本。
内容密钥使用组织的 RSA 密钥 (“Azure Rights Management 租户密钥”) 作为文档中策略的一部分进行加密，并且该策略也由文档作者签名。 此租户密钥是组织受 Azure Rights Management 服务保护的所有文档和电子邮件的通用密钥，并且仅当组织使用客户管理的租户密钥 (（称为“自带密钥”或 BYOK) ）时，该服务的管理员才能更改此密钥。
此租户密钥在Microsoft联机服务、高度受控的环境中和密切监视下受到保护。 使用客户管理的租户密钥 (BYOK) 时，通过使用一组高端硬件安全模块 (HSM) 在每个 Azure 区域中增强这种安全性，在任何情况下都无法提取、导出或共享密钥。 有关租户密钥和 BYOK 的详细信息，请参阅 管理 Azure Rights Management 服务的根密钥。
发送到 Windows 设备的许可证和证书使用客户端的设备私钥进行加密。 此私钥是在设备上用户首次使用 Azure Rights Management 服务时创建的。 反过来，此私钥在客户端上使用 DPAPI 进行加密，从而通过使用派生自用户密码的密钥来保护这些机密。 在移动设备上，密钥只使用一次，因此由于这些密钥未存储在客户端上，因此无需在设备上加密这些密钥。
服务工作原理演练：首次使用、内容加密、内容使用
为了更详细地了解 Azure Rights Management 服务的工作原理，让我们演练激活 Azure Rights Management 服务 后的典型流程，当用户首次从其 Windows 计算机使用 Rights Management 服务时， (有时称为 初始化用户环境 或启动) 的过程， (文档或电子邮件) 加密内容 ， 然后 ，使用 打开 (并使用) 已由其他人加密的内容。
初始化用户环境后，该用户可以加密文档或使用该计算机上的加密文档。
注意
如果此用户移动到另一台 Windows 计算机，或另一个用户使用同一台 Windows 计算机，初始化过程将重复。
初始化用户环境
用户必须先在设备上准备用户环境，然后才能在 Windows 计算机上加密内容或使用加密内容。 这是一次性过程，当用户尝试加密或使用加密内容时，无需用户干预即可自动执行：
步骤 1 中发生的情况：计算机上运行的 Azure Rights Management 服务的客户端首先连接到该服务，并且该服务使用其Microsoft Entra帐户对用户进行身份验证。
当用户的帐户与 Microsoft Entra ID 联合时，此身份验证是自动的，并且不会提示用户输入凭据。
步骤 2 中发生的情况：对用户进行身份验证后，连接会自动重定向到组织的租户，该租户会颁发证书，让用户向 Azure Rights Management 服务进行身份验证，以便使用加密内容并脱机加密内容。
其中一个证书是权限帐户证书，通常缩写为 RAC。 此证书对用户进行身份验证以Microsoft Entra ID，有效期为 31 天。 证书由客户端自动续订，前提是用户帐户仍Microsoft Entra ID 且帐户已启用。 管理员无法配置此证书。
此证书的副本存储在 Azure 中，以便在用户移动到另一台设备时，使用相同的密钥创建证书。
内容加密
当用户加密文档时，Azure Rights Management 服务的客户端对未加密的文档执行以下作：
步骤 1 中发生的情况：客户端创建一个随机密钥 (内容密钥) ，并将此密钥与 AES 对称加密算法结合使用来加密文档。
步骤 2 中发生的情况：客户端随后创建一个证书，其中包含文档的策略，该策略包括用户或组 的使用权限 以及其他限制，例如到期日期。 可以使用管理员先前配置的敏感度标签加密设置来定义这些设置，或者在对内容进行加密时指定 (有时称为“用户定义的权限”或“临时策略”) 。
用于标识所选用户和组的主要Microsoft Entra属性是Microsoft Entra ProxyAddresses 属性，该属性存储用户或组的所有电子邮件地址。 但是，如果用户帐户在 AD ProxyAddresses 属性中没有任何值，则会改用用户的 UserPrincipalName 值。
然后，客户端使用在初始化用户环境时获取的组织密钥，并使用此密钥加密策略和对称内容密钥。 客户端还使用初始化用户环境时获取的用户证书对策略进行签名。
步骤 3 中发生的情况：最后，客户端将策略嵌入到一个文件中，其中文档正文以前已加密，该文档共同构成一个加密文档。
此文档可以存储在任何位置或使用任何方法共享，并且策略始终与加密的文档一起保留。
内容消耗
当用户想要使用加密的文档时，客户端首先会请求访问 Azure Rights Management 服务：
步骤 1 中发生的情况：经过身份验证的用户将文档策略和用户的证书发送到 Azure Rights Management 服务。 如果用户对文档有任何) ，该服务将解密和评估策略，并生成 (权限列表。 为了标识用户，Microsoft Entra ProxyAddresses 属性用于用户帐户和用户所属的组。 出于性能原因，将 缓存组成员身份。 如果用户帐户没有 Microsoft Entra ProxyAddresses 属性的任何值，则改用 Microsoft Entra UserPrincipalName 中的值。
步骤 2 中发生的情况：服务随后从解密的策略中提取 AES 内容密钥。 然后，此密钥将使用通过请求获取的用户公共 RSA 密钥进行加密。
然后，将重新加密的内容密钥嵌入到具有用户权限列表的加密使用许可证中，该列表随后会返回到客户端。
步骤 3 中发生的情况：最后，客户端获取加密的使用许可证，并使用自己的用户私钥对其进行解密。 这允许客户端根据需要解密文档的正文，并将其呈现在屏幕上。
客户端还会解密权限列表并将其传递给应用程序，后者在应用程序的用户界面中强制实施这些权限。
注意
当组织外部的用户使用已加密的内容时，消耗流是相同的。 此方案的更改是用户进行身份验证的方式。 有关详细信息，请参阅 当我与公司外部的人共享加密文档时，该用户如何进行身份验证？
变体
前面的演练介绍了标准方案，但有一些变化：
Email加密：当Exchange Online和Microsoft Purview 邮件加密用于加密电子邮件时，使用身份验证还可以使用与社交标识提供者的联合身份验证或使用一次性密码。 然后，进程流非常相似，只不过内容消耗发生在 Web 浏览器会话的服务端，而出站电子邮件的临时缓存副本。
移动设备：当移动设备使用 Azure Rights Management 服务加密或使用文件时，流程流会更简单。 移动设备不会首先完成用户初始化过程，因为每个事务 (加密或使用内容) 是独立的。 与 Windows 计算机一样，移动设备连接到 Azure Rights Management 服务并进行身份验证。 若要加密内容，移动设备会提交策略，Azure Rights Management 服务会向他们发送发布许可证和对称密钥来加密文档。 若要使用加密内容，当移动设备连接到 Azure Rights Management 服务并进行身份验证时，它们会将文档策略发送到 Azure Rights Management 服务，并请求使用许可证来使用文档。 作为响应，Azure Rights Management 服务会将必要的密钥和限制发送到移动设备。 这两个进程都使用 TLS 来保护密钥交换和其他通信。
Rights Management 连接器：当 Azure Rights Management 服务与 Rights Management 连接器一起使用时，进程流保持不变。 唯一的区别在于，连接器充当本地服务 (（如 Exchange Server 和 SharePoint Server) ）与 Azure Rights Management 服务之间的中继。 连接器本身不会执行任何作，例如用户环境的初始化，或者加密或解密。 它只是中继通常会转到 AD RMS 服务器的通信，处理每一端使用的协议之间的转换。 此方案允许将 Azure Rights Management 服务与本地服务配合使用。
通用加密 (.pfile) ：当 Azure 权限管理服务对文件进行一般加密时，除了客户端创建授予所有权限的策略外，流与内容加密基本相同。 使用文件时，会在将其传递给目标应用程序之前对其进行解密。 此方案允许加密所有文件，即使它们本身不支持 Azure Rights Management 服务。
Microsoft帐户：使用 Microsoft 帐户进行身份验证时，Azure Rights Management 服务可以授权电子邮件地址供使用。 但是，使用 Microsoft 帐户进行身份验证时，并非所有应用程序都可以打开加密内容。 详细信息。
后续步骤
有关 Azure Rights Management 服务的不太技术概述，请参阅 了解 Azure Rights Management 服务。
如果已准备好部署建议的步骤（包括加密以保护数据），请参阅 使用 Microsoft Purview 部署信息保护解决方案。