ASP.NET Core 数据保护概述

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

Web 应用通常需要存储敏感数据。 Windows 数据保护 API (DPAPI) 不适用于 Web 应用。

ASP.NET Core 数据保护堆栈旨在:

  • 为大多数 Web 方案提供内置解决方案。
  • 解决以前的加密系统的许多缺陷。
  • 用作 ASP.NET 1.x - 4.x 中 <machineKey> 元素的替换项。

问题陈述

我需要保留受信任的信息以供以后检索,但我不信任持久性机制。 在 Web 术语中,这可以编写为“我需要通过不受信任的客户端往返传递受信任状态”。

真实性、完整性和防篡改是一项要求。 这一点的典型示例是身份验证 cookie 或持有者令牌。 服务器会生成一个“我是 Groot 并拥有 xyz 权限”令牌,然后将它发送给客户端。 客户端将该令牌返回呈现给服务器,但服务器需要某种保证,以确保客户端没有伪造该令牌。

保密性是一项要求。 由于服务器信任持久性状态,因此这种状态可能包含不应向不受信任的客户端披露的信息。 例如:

  • 文件路径。
  • 权限。
  • 句柄或其他间接引用。
  • 某些特定于服务器的数据。

隔离是一项要求。 由于新式应用已组件化,因此各个组件无需考虑系统中的其他组件即可利用此系统。 例如,请考虑使用此堆栈的持有者令牌组件。 它应该在没有任何干扰的情况下运行,例如,例如来自也使用相同堆栈的反 CSRF 机制的干扰。

一些常见假设可以缩小要求的范围:

  • 加密系统内运行的所有服务都同样受信任。
  • 无需在直接控制的服务外部生成或使用数据。
  • 运行速度必须很快,因为对 Web 服务的每个请求可能会一次或多次通过加密系统。 由于对速度的要求,对称加密成为理想选择。 只有在需要时,才会使用非对称加密。

设计理念

ASP.NET Core 数据保护是易于使用的数据保护堆栈。 它基于以下原则:

  • 配置容易度。 系统力求实现零配置。 在开发人员需要在某个方面(如密钥存储库)实现特定配置的情况下,这些特定配置并不困难。
  • 提供面向使用者的基本 API。 以正确方式使用这些 API 简单且直观,但要以错误方式使用则非常困难。
  • 开发人员不必了解密钥管理原则。 系统会代表开发人员处理算法选择和密钥生存期。 开发人员无权访问原始密钥材料。
  • 密钥在 rest 期间会受到最大程度的保护。 系统会确定适当的默认保护机制并自动应用该机制。

数据保护 API 并非主要用于无限期保留机密有效负载。 其他技术(如 Windows CNG DPAPIAzure Rights Management)更适合用于无限期存储的方案。 它们具有相应的强大密钥管理功能。 也就是说,ASP.NET Core 数据保护 API 可用于长期保护机密数据。

受众

数据保护系统提供面向三类主要受众的 API:

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

    “我不想了解堆栈如何运行或堆栈的配置方式。 我只想在成功概率较高的情况下使用 API 执行一些操作。

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

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

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

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

程序包布局

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

其他资源

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

Web 应用通常需要存储敏感数据。 Windows 数据保护 API (DPAPI) 不适用于 Web 应用。

ASP.NET Core 数据保护堆栈旨在:

  • 为大多数 Web 方案提供内置解决方案。
  • 解决以前的加密系统的许多缺陷。
  • 用作 ASP.NET 1.x - 4.x 中 <machineKey> 元素的替换项。

问题陈述

我需要保留受信任的信息以供以后检索,但我不信任持久性机制。 在 Web 术语中,这可以编写为“我需要通过不受信任的客户端往返传递受信任状态”。

真实性、完整性和防篡改是一项要求。 这一点的典型示例是身份验证 cookie 或持有者令牌。 服务器会生成一个“我是 Groot 并拥有 xyz 权限”令牌,然后将它发送给客户端。 客户端将该令牌返回呈现给服务器,但服务器需要某种保证,以确保客户端没有伪造该令牌。

保密性是一项要求。 由于服务器信任持久性状态,因此这种状态可能包含不应向不受信任的客户端披露的信息。 例如:

  • 文件路径。
  • 权限。
  • 句柄或其他间接引用。
  • 某些特定于服务器的数据。

隔离是一项要求。 由于新式应用已组件化,因此各个组件无需考虑系统中的其他组件即可利用此系统。 例如,请考虑使用此堆栈的持有者令牌组件。 它应该在没有任何干扰的情况下运行,例如,例如来自也使用相同堆栈的反 CSRF 机制的干扰。

一些常见假设可以缩小要求的范围:

  • 加密系统内运行的所有服务都同样受信任。
  • 无需在直接控制的服务外部生成或使用数据。
  • 运行速度必须很快,因为对 Web 服务的每个请求可能会一次或多次通过加密系统。 由于对速度的要求,对称加密成为理想选择。 只有在需要时,才会使用非对称加密。

设计理念

ASP.NET Core 数据保护是易于使用的数据保护堆栈。 它基于以下原则:

  • 配置容易度。 系统力求实现零配置。 在开发人员需要在某个方面(如密钥存储库)实现特定配置的情况下,这些特定配置并不困难。
  • 提供面向使用者的基本 API。 以正确方式使用这些 API 简单且直观,但要以错误方式使用则非常困难。
  • 开发人员不必了解密钥管理原则。 系统会代表开发人员处理算法选择和密钥生存期。 开发人员无权访问原始密钥材料。
  • 密钥在 rest 期间会受到最大程度的保护。 系统会确定适当的默认保护机制并自动应用该机制。

数据保护 API 并非主要用于无限期保留机密有效负载。 其他技术(如 Windows CNG DPAPIAzure Rights Management)更适合用于无限期存储的方案。 它们具有相应的强大密钥管理功能。 也就是说,ASP.NET Core 数据保护 API 可用于长期保护机密数据。

受众

数据保护系统提供面向三类主要受众的 API:

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

    “我不想了解堆栈如何运行或堆栈的配置方式。 我只想在成功概率较高的情况下使用 API 执行一些操作。

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

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

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

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

程序包布局

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

其他资源