Azure RMS 如何工作? 在底层

适用于:Azure信息保护、Office 365

相关:AIP 统一标签客户端和经典客户端

注意

为了提供统一且简化的客户体验,Azure 门户中的Azure信息保护经典客户端和标签管理在2021年 3 月 31 日已弃用。 不再提供对经典客户端的进一步支持,并且将不再发布维护版本。

经典客户端将于 2022 年 3 月 31 日正式停用并停止运行。

所有当前的 Azure 信息保护经典客户端客户必须迁移到统一Microsoft 信息保护平台,并升级到统一标签客户端。 在迁移博客 中了解更多信息

若要了解 Azure RMS 的工作原理,一个很重要的事情是,来自 Azure 信息保护的此数据保护服务不会在保护过程中查看或存储数据。 保护的信息永远不会发送到 Azure 或存储在 Azure 中,除非显式将信息存储在 Azure 中,或者使用另一个云服务将该信息存储在 Azure 中。 Azure RMS 只是使文档中的数据对于除授权用户和服务外的其他任何人都不可读:

  • 数据在应用程序级别加密,并包含定义该文档的授权使用的策略。

  • 当受保护文档由合法用户使用或由授权服务处理时,将解密文档中的数据,并强制实施策略中定义的权利。

从较高层面看,可以在下图中了解此过程的工作原理。 包含机密公式的文档受到保护,然后由授权用户或服务成功打开。 此文档受内容密钥保护, (图片中的绿色) 。 它对于每个文档都是唯一的,并放置在受 Azure 信息保护租户根密钥保护的文件标头中 (此图中的红色) 。 租户密钥由 Microsoft 生成和管理,也可以生成和管理自己的租户密钥。

在整个保护过程中,当 Azure RMS 加密和解密、授权和强制实施限制时,机密公式永远不会发送到 Azure。

Azure RMS 如何保护文件

有关发生的情况的详细说明,请参阅本文中的 Azure RMS 工作原理演练:首次使用、内容保护、内容使用部分。

有关 Azure RMS 使用的算法和密钥长度的技术详细信息,请参阅下一部分。

Azure RMS 使用的加密控制:算法和密钥长度

即使不需要详细说明此技术的工作原理,也可能会询问其使用的加密控件。 例如,确认安全保护是行业标准的。

加密控件 在 Azure RMS 中使用
算法:AES

密钥长度:128 位和 256 位 [1]
内容保护
算法:RSA

密钥长度:2048 位 [2]
密钥保护
SHA-256 证书签名
脚注 1

Azure 信息保护客户端在以下情况中使用了 256 位:

  • 通用保护 (.pfile) 。

  • 当文档已使用 PDF 加密的 ISO 标准进行保护,或者生成的受保护文档具有 .p pdf 文件扩展名时,对 PDF 文档进行本机保护。

  • 文本或图像文件的本机保护 (如 .ptxt 或 .pjpg) 。

脚注 2

2048 位是激活 Azure Rights Management 服务时的关键长度。 以下可选方案支持 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) 时,此安全性通过在每个 Azure 区域使用一组高端硬件安全模块 (HSM) 来增强,而在任何情况下都无法提取、导出或共享密钥。 有关租户密钥和 BYOK 的信息,请参阅 规划和实现 Azure 信息保护租户密钥

发送到 Windows 设备的许可证和证书受客户端设备私钥的保护,这是用户在设备上首次使用 Azure RMS 时创建的。 反过来,此私钥在客户端上受 DPAPI 的保护,它使用派生自用户密码的密钥来保护这些机密。 在移动设备上,密钥只会使用一次,因此,由于这些密钥未存储在客户端上,因此不需要在设备上保护这些密钥。

Azure RMS 工作原理演练:第一次使用、内容保护、内容使用

若要更详细地了解 Azure RMS 的工作原理,让我们演练激活 Azure Rights Management服务后的典型流程,以及当用户首次使用 Windows 计算机上权限管理服务时 (此过程有时称为初始化用户环境或启动) ,保护内容 (文档或电子邮件) , 然后使用 (,并使用) 他人保护的内容。

初始化用户环境后,该用户就可以保护文档,或者使用该计算机上受保护的文档。

注意

如果此用户移动到另一Windows计算机,或者其他用户在计算机Windows,则初始化过程会重复。

初始化用户环境

用户必须先在设备上准备好用户Windows才能保护内容或使用受保护的内容。 这是一个一次过程,当用户尝试保护或使用受保护的内容时,系统会自动执行此过程,无需用户干预:

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

步骤 1中发生的情况:计算机的 RMS 客户端首先连接到 Azure Rights Management 服务,然后使用用户的 Azure Active Directory 进行身份验证。

当用户帐户与 Azure Active Directory时,此身份验证是自动的,系统不会提示用户输入凭据。

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

步骤2:对用户进行身份验证后,连接会自动重定向到组织的 Azure 信息保护租户,该租户颁发证书,让用户向 Azure Rights Management 服务进行身份验证,以便使用受保护的内容和脱机保护内容。

这些证书之一是权限帐户证书,通常缩写为 RAC。 此证书对用户进行身份验证,Azure Active Directory有效期为 31 天。 该证书由 RMS 客户端自动续订,但提供用户帐户仍在Azure Active Directory并且该帐户已启用。 管理员无法配置此证书。

此证书的副本存储在 Azure 中,以便如果用户移到另一台设备,则使用相同的密钥创建证书。

内容保护

当用户保护文档时,RMS 客户端对未受保护的文档执行以下操作:

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

步骤 1中发生的情况:RMS 客户端在内容密钥 (创建随机密钥) 通过 AES 对称加密算法使用此密钥加密文档。

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

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

用于Azure AD用户和组的主要属性是 Azure AD ProxyAddresses 属性,该属性存储用户或组的所有电子邮件地址。 但是,如果用户帐户在 AD ProxyAddresses 属性中没有任何值,则改为使用用户的 UserPrincipalName 值。

然后,RMS 客户端使用在初始化用户环境时获取的组织密钥,并使用此密钥来加密策略和对称内容密钥。 RMS 客户端还会使用初始化用户环境时获取的用户证书对策略进行签名。

RMS 文档保护 - 步骤 3 中嵌入了策略

步骤 3中发生的情况:最后,RMS 客户端将策略嵌入到包含以前加密的文档正文的文件中,该文件共同构成一个受保护的文档。

本文档可以存储在任何位置,也可使用任意方法共享,策略始终与加密文档保持一起。

内容使用

当用户想要使用受保护的文档时,RMS 客户端首先请求访问 Azure Rights Management 服务:

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

步骤 1 中发生的情况:经过身份验证的用户将文档策略和用户的证书发送到 Azure Rights Management 服务。 该服务将解密和评估策略,并生成权限列表 (用户) 文档的任何权限列表。 若要标识用户,Azure AD ProxyAddresses 属性用于用户作为成员的帐户和组。 出于性能原因,缓存了 组成员身份。 如果用户帐户没有 proxyAddresses Azure AD值,则改为使用 Azure AD UserPrincipalName 中的值。

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

步骤 2 中发生的情况:然后,服务从解密的策略中提取 AES 内容密钥。 然后,使用通过请求获取的用户公共 RSA 密钥加密此密钥。

然后,重新加密的内容密钥将嵌入到具有用户权限列表的加密使用许可证中,然后返回到 RMS 客户端。

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

步骤 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 服务,以了解现有应用程序如何与 Azure Rights Management 集成以提供信息保护解决方案。

查看 Azure 信息保护的术语,以便熟悉配置和使用 Azure Rights Management 服务时可能遇到的条款,并且在开始部署之前,请务必同时检查 Azure 信息保护的要求。 若要深入了解并自己尝试,请使用快速入门和教程:

如果已准备好开始为组织部署数据保护,请使用适用于部署步骤的分类、标记和保护 的 AIP 部署路线图和操作说明链接。

提示

有关其他信息和帮助,请使用 Azure 信息保护的信息和支持中的 资源和链接