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