ASP.NET Core 数据保护

Web 应用程序通常需要存储安全敏感数据。 Windows 为桌面应用程序提供 DPAPI,但这不适用于 Web 应用程序。 ASP.NET Core 数据保护堆栈提供了一个简单、易于使用的加密 API,开发人员可以使用它来保护数据,包括密钥管理和轮换。

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

问题陈述

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

这种情况的规范示例是身份验证 cookie 或 bearer 令牌。 服务器生成"I am Groot 并拥有 xyz 权限"令牌,并动手给客户端。 在将来的某一日期,客户端会向服务器提供该令牌,但服务器需要某种保证,即客户端尚未伪造令牌。 因此,第一个要求是 (,即 完整性、防篡改) 。

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

最后,由于新式应用程序是组件化的,我们看到的是,单个组件需要利用此系统,而不考虑系统中的其他组件。 例如,如果持有者令牌组件正在使用此堆栈,则它应在不干扰可能使用同一堆栈的 CSRF 机制的情况下运行。 因此,最终要求:隔离。

我们可以提供进一步的约束来缩小需求的范围。 假设在 cryptosystem 内运行的所有服务都是同等信任的,并且无需在我们的直接控制下生成或使用服务外部的数据。 此外,我们还需要尽可能快地执行操作,因为每次向 web 服务发出的请求可能会经过 cryptosystem 一次或多次。 这使得对称加密非常适合我们的方案,并且我们可以为非对称加密提供折扣,直到需要这样的时间。

设计理念

首先,我们要找出现有堆栈的问题。 完成这一工作后,我们调查了现有解决方案的前景,并最终找不到现有解决方案。 然后,基于多个指导原则对解决方案进行了设计。

  • 系统应简化配置。 理想情况下,系统将是零配置,开发人员可以在运行。 当开发人员需要配置特定的方面 (例如密钥存储库) 时,应考虑将这些特定的配置简化。

  • 提供简单的面向用户的 API。 Api 应易于使用,并且难以正确使用。

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

  • 应尽可能保护密钥。 系统应确定适当的默认保护机制,并自动应用它。

根据这些原则,我们开发了一个简单 、易于使用的 数据保护堆栈。

ASP.NET 核心数据保护 API 主要不用于机密有效负载的无限期持久性。 Windows CNG DPAPIAzure Rights Management 等其他技术更适合无限存储的方案,它们相应地具有强大的密钥管理功能。 也就是说,没有禁止开发人员使用 ASP.NET Core 数据保护 API 长期保护机密数据。

目标受众

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

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

    "我不想了解堆栈的运行方式或堆栈的配置方式。 我只需以尽可能简单的方式执行某些操作,且成功使用 API 的概率很高。"

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

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

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

    "我需要替换系统内的整个组件,因为我有真正独特的行为要求。 我愿意学习 API 图面中不常见使用的部分,以便生成满足我要求的插件。"

程序包布局

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

其他资源

在 Web 场中托管 ASP.NET Core