ASP.NET Core 数据保护ASP.NET Core Data Protection

Web 应用程序通常需要存储安全敏感数据。Web applications often need to store security-sensitive data. Windows 提供了 DPAPI 用于桌面应用程序,但这不适用于 web 应用程序。Windows provides DPAPI for desktop applications but this is unsuitable for web applications. ASP.NET Core 数据保护堆栈提供简单易用的加密 API,开发人员可以使用它来保护数据,包括密钥管理和旋转。The ASP.NET Core data protection stack provide a simple, easy to use cryptographic API a developer can use to protect data, including key management and rotation.

ASP.NET Core 的数据保护堆栈旨在充当 < ASP.NET 1.x-4.x 中 machineKey 元素的长期替换项 > 。The ASP.NET Core data protection stack is designed to serve as the long-term replacement for the <machineKey> element in ASP.NET 1.x - 4.x. 它旨在解决旧加密堆栈的许多缺点,同时为大多数用例提供现成的解决方案,最新的应用程序可能会遇到这种情况。It was designed to address many of the shortcomings of the old cryptographic stack while providing an out-of-the-box solution for the majority of use cases modern applications are likely to encounter.

问题陈述Problem statement

整体问题声明可在一个句子中简单地表述:我需要保存可信信息供以后检索,但不信任持久性机制。The overall problem statement can be succinctly stated in a single sentence: I need to persist trusted information for later retrieval, but I don't trust the persistence mechanism. 在 web 术语中,这可能被编写为 "我需要通过不受信任的客户端往返的受信任状态。"In web terms, this might be written as "I need to round-trip trusted state via an untrusted client."

此规范的典型示例是身份验证 cookie 令牌或持有者令牌。The canonical example of this is an authentication cookie or bearer token. 服务器生成一个 "I Groot" 和 "xyz 权限" 令牌并将其交给客户端。The server generates an "I am Groot and have xyz permissions" token and hands it to the client. 在将来的某个日期,客户端会将该令牌提供给服务器,但服务器需要某种形式的保证,那就是客户端未伪造令牌。At some future date the client will present that token back to the server, but the server needs some kind of assurance that the client hasn't forged the token. 因此,第一个要求是 (也称为Thus the first requirement: authenticity (a.k.a. 完整性、防篡改) 。integrity, tamper-proofing).

由于持久状态受服务器信任,因此我们预计此状态可能包含特定于操作环境的信息。Since the persisted state is trusted by the server, we anticipate that this state might contain information that's specific to the operating environment. 这可能是文件路径、权限、句柄或其他间接引用的形式,也可能是其他特定于服务器的数据的形式。This could be in the form of a file path, a permission, a handle or other indirect reference, or some other piece of server-specific data. 此类信息通常不会泄露给不受信任的客户端。Such information should generally not be disclosed to an untrusted client. 因此,第二个要求:保密性。Thus the second requirement: confidentiality.

最后,由于新式应用程序是组件化的,我们看到的是,单个组件需要利用此系统,而不考虑系统中的其他组件。Finally, since modern applications are componentized, what we've seen is that individual components will want to take advantage of this system without regard to other components in the system. 例如,如果持有者令牌组件正在使用此堆栈,则它应在不干扰可能使用同一堆栈的 CSRF 机制的情况下运行。For instance, if a bearer token component is using this stack, it should operate without interference from an anti-CSRF mechanism that might also be using the same stack. 因此,最终要求:隔离。Thus the final requirement: isolation.

我们可以提供进一步的约束来缩小需求的范围。We can provide further constraints in order to narrow the scope of our requirements. 假设在 cryptosystem 内运行的所有服务都是同等信任的,并且无需在我们的直接控制下生成或使用服务外部的数据。We assume that all services operating within the cryptosystem are equally trusted and that the data doesn't need to be generated or consumed outside of the services under our direct control. 此外,我们还需要尽可能快地执行操作,因为每次向 web 服务发出的请求可能会经过 cryptosystem 一次或多次。Furthermore, we require that operations are as fast as possible since each request to the web service might go through the cryptosystem one or more times. 这使得对称加密非常适合我们的方案,并且我们可以为非对称加密提供折扣,直到需要这样的时间。This makes symmetric cryptography ideal for our scenario, and we can discount asymmetric cryptography until such a time that it's needed.

设计理念Design philosophy

首先,我们要找出现有堆栈的问题。We started by identifying problems with the existing stack. 完成这一工作后,我们调查了现有解决方案的前景,并最终找不到现有解决方案。Once we had that, we surveyed the landscape of existing solutions and concluded that no existing solution quite had the capabilities we sought. 然后,基于多个指导原则对解决方案进行了设计。We then engineered a solution based on several guiding principles.

  • 系统应简化配置。The system should offer simplicity of configuration. 理想情况下,系统将是零配置,开发人员可以在运行。Ideally the system would be zero-configuration and developers could hit the ground running. 当开发人员需要配置特定的方面 (例如密钥存储库) 时,应考虑将这些特定的配置简化。In situations where developers need to configure a specific aspect (such as the key repository), consideration should be given to making those specific configurations simple.

  • 提供简单的面向用户的 API。Offer a simple consumer-facing API. Api 应易于使用,并且难以正确使用。The APIs should be easy to use correctly and difficult to use incorrectly.

  • 开发人员不应了解关键管理原则。Developers shouldn't learn key management principles. 系统应代表开发人员处理算法选择和密钥生存期。The system should handle algorithm selection and key lifetime on the developer's behalf. 理想情况下,开发人员绝不会有权访问原始密钥材料。Ideally the developer should never even have access to the raw key material.

  • 应尽可能保护密钥。Keys should be protected at rest when possible. 系统应该找出适当的默认保护机制,并自动应用它。The system should figure out an appropriate default protection mechanism and apply it automatically.

考虑到这些原则,我们开发了简单 易用 的数据保护堆栈。With these principles in mind we developed a simple, easy to use data protection stack.

ASP.NET Core 的数据保护 Api 主要用于机密负载的无限持久性。The ASP.NET Core data protection APIs are not primarily intended for indefinite persistence of confidential payloads. 其他技术(如 WINDOWS CNG DPAPIAzure Rights Management )更适用于无限存储的情况,并且具有相应的强大密钥管理功能。Other technologies like Windows CNG DPAPI and Azure Rights Management are more suited to the scenario of indefinite storage, and they have correspondingly strong key management capabilities. 也就是说,不会阻止开发人员使用 ASP.NET Core 的数据保护 Api 来长期保护机密数据。That said, there's nothing prohibiting a developer from using the ASP.NET Core data protection APIs for long-term protection of confidential data.

目标受众Audience

数据保护系统分为五个主要包。The data protection system is divided into five main packages. 这些 Api 的各个方面面向三个主要受众;Various aspects of these APIs target three main audiences;

  1. 使用者 Api 概述目标应用程序和框架开发人员。The Consumer APIs Overview target application and framework developers.

    "我不想了解堆栈如何操作或如何进行配置。"I don't want to learn about how the stack operates or about how it's configured. 我只是想要尽可能简单的方式执行一些操作,而使用 Api 成功的可能性很高。 "I simply want to perform some operation in as simple a manner as possible with high probability of using the APIs successfully."

  2. 配置 api面向应用程序开发人员和系统管理员。The configuration APIs target application developers and system administrators.

    "我需要告诉数据保护系统,我的环境需要非默认路径或设置。""I need to tell the data protection system that my environment requires non-default paths or settings."

  3. 扩展性 Api 面向开发人员负责实现自定义策略的目标。The extensibility APIs target developers in charge of implementing custom policy. 这些 Api 的使用仅限于极少的情况和经验丰富的安全感知开发人员。Usage of these APIs would be limited to rare situations and experienced, security aware developers.

    "我需要替换系统中的整个组件,因为我有真正独特的行为要求。"I need to replace an entire component within the system because I have truly unique behavioral requirements. 我愿意了解 API 表面不常见使用的部分,以便构建满足我的需求的插件。 "I am willing to learn uncommonly-used parts of the API surface in order to build a plugin that fulfills my requirements."

程序包布局Package layout

数据保护堆栈包含5个包。The data protection stack consists of five packages.

其他资源Additional resources

在 Web 场中托管 ASP.NET Core