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 データ保護スタックが長期にわたって置き換えとして機能するように設計、 <machineKey> ASP.NET 内の要素の 1.x 4.x です。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

全体的な問題ステートメントは、1 つの文で簡潔に記述できます。後で取得は、信頼できる情報を保持する必要がありますが、永続化メカニズムを信頼しません。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. サーバーを生成、"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. したがって、2 番目の要件: 機密性。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. 暗号方式の範囲内で動作するすべてのサービスが平等に信頼されているし、データが生成または、直接の管理下にあるサービスの外部で使用する必要があることを仮定します。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 サービスへの各要求を暗号方式 1 回以上移行するための操作ができるだけ高速である必要があります。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.

  • 可能であれば rest でキーを保護する必要があります。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

データ保護システムは、5 つのメイン パッケージに分割されます。The data protection system is divided into five main packages. これらの Api のさまざまなターゲットの 3 つの主な対象ユーザー。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 のホスト