ASP.NET Core 数据保护概述

ASP.NET Core 数据保护提供了一个加密 API,用于保护密钥管理和轮换等数据。

Web 应用通常需要存储对安全性敏感的数据。 Windows 提供了一个数据保护 API (DPAPI),但 Windows DPAPI 并不适用于 Web 应用程序。

在 ASP.NET 1.x - 4.x 中,ASP.NET Core 数据保护堆栈旨在用作 machineKey 元素的长期替换项<>。 它旨在解决旧加密堆栈的许多缺点,同时为现代应用程序可能会遇到的大多数用例提供现成的解决方案。

问题陈述

整体问题陈述可以用一句话简明扼要地表述:我需要保持受信任信息以供以后检索,但我不信任持久性机制。 在 Web 术语中,这可以编写为“我需要通过不受信任的客户端往返受信任状态”。

这一点的典型示例是身份验证 cookie 或持有者令牌。 服务器会生成一个“我是 Groot 并拥有 xyz 权限”令牌,然后将它传递给客户端。 在将来的某个日期,客户端会向服务器呈现该令牌,但服务器需要某种类型的保证,即客户端未伪造令牌。 因此,第一个要求是验证(也称为完整性、防篡改)。

由于持久状态受服务器信任,因此我们预计此状态可能包含特定于操作环境的信息。 这可以采用文件路径、权限、句柄或其他间接引用的形式,或是其他特定于服务器的数据片段。 此类信息通常不应泄露给不受信任的客户端。 因此,第二个要求是保密性。

最后,由于现代应用程序是组件化的,我们看到的是,单个组件要利用此系统,而不考虑系统中的其他组件。 例如,如果持有者令牌组件在使用此堆栈,那么它应在没有来自可能也使用相同堆栈的抗 CSRF 机制的干扰下运行。 因此,最终要求是隔离。

我们可以提供进一步的约束,以便缩小需求范围。 我们假设在加密系统中运行的所有服务都是同等受信任,并且无需在我们直接控制下的服务外部生成或使用数据。 此外,我们需要尽可能快地执行操作,因为向 Web 服务发出的每个请求都可能会一次或多次经过加密系统。 这使得对称加密非常适合我们的方案,我们可以在需要非对称加密之前不考虑非对称加密。

设计理念

我们首先标识现有堆栈的问题。 确定了问题后,我们调查了现有解决方案的状况,并得出结论,没有任何现有解决方案可完全具备我们所寻求的功能。 我们随后基于多个指导原则设计了解决方案。

  • 系统应提供简单的配置。 理想情况下,系统无需配置,开发人员可以立即开始运行。 在开发人员需要配置特定方面(例如密钥存储库)的情况下,应考虑简化这些特定配置。

  • 提供面向使用者的简单 API。 API 应易于使用,并且不容易误用。

  • 开发人员不必了解密钥管理原则。 系统应代表开发人员处理算法选择和密钥生存期。 理想情况下,开发人员绝不应有权访问原始密钥材料。

  • 应尽可能对密钥进行静态保护。 系统应确定适当的默认保护机制并自动进行应用。

考虑到这些原则,我们开发了一种简单、易用的数据保护堆栈。

ASP.NET Core 数据保护 API 并非主要用于无限期保留机密有效负载。 Windows CNG DPAPIAzure Rights Management 等其他技术更适用于无限期存储的场景,这些技术具有相应强大的密钥管理功能。 也就是说,开发人员也可以使用 ASP.NET Core 数据保护 API 来长期保护机密数据。

目标受众

数据保护系统划分为五个主要包。 这些 API 的各个方面面向三种主要受众;

  1. 使用者 API 概述面向应用程序和框架开发人员。

    “我不想了解堆栈如何操作或如何进行配置。 我只是想以尽可能简单的方法执行某种操作,而成功使用 API 的可能性较高。”

  2. 配置 API 面向应用程序开发人员和系统管理员。

    “我需要告诉数据保护系统,我的环境需要非默认路径或设置。”

  3. 扩展性 API 面向负责实现自定义策略的开发人员。 这些 API 的使用仅限于极少情况和经验丰富的了解安全性的开发人员。

    “我需要在系统中替换整个组件,因为我有真正独一无二的行为要求。 我愿意了解 API 图面的不常用部分,以便构建满足我的要求的插件。”

程序包布局

数据保护堆栈由五个包组成。

其他资源