ホームページ >バックエンド開発 >C#.Net チュートリアル >ASP.NET Core データ保護
API インターフェイス
ASP.NET Core Data Protectio は、主に、IDataProtectionProvider と IDataProtector という 2 つのインターフェイスを一般の開発者向けに提供します。
まず、これら 2 つのインターフェイス間の関係を見てみましょう:
namespace Microsoft.AspNetCore.DataProtection { // // 摘要: // An interface that can provide data protection services. public interface IDataProtector : IDataProtectionProvider { byte[] Protect(byte[] plaintext); byte[] Unprotect(byte[] protectedData); } }
IDataProtector が IDataProtectionProvider を継承し、2 つのメソッド Protect および Unprotect を提供していることがわかります。命名の観点からは、1 つは暗号化で、もう 1 つは復号です。 。署名はバイト配列で渡されます。つまり、すべてのオブジェクトを暗号化および復号化できます。返されるものもバイト配列です。つまり、実際の使用では、それを自分で追加するか、システムの拡張メソッドを使用してニーズを指定する必要があります。
IDataProtectionProvider インターフェイスをもう一度見てみましょう:
namespace Microsoft.AspNetCore.DataProtection { public interface IDataProtectionProvider { IDataProtector CreateProtector(string purpose); } }
IDataProtectionProvider は、目的文字列を渡すことによって IDataProtector インターフェイス オブジェクトを生成するメソッドを提供します (詳細は以下を参照)。
このインターフェースの名前から判断すると、プロバイダーで終わります。これは、この部分で独自の暗号化と復号化のセットを実装できることを意味します。
Microsoft プロジェクトのソース コードを読むと、よく xxxxProvider で終わるオブジェクトがいくつかありますが、その責任と役割は何でしょうか?
実際、これは Microsoft が ASP.NET 用に特別に設計したデザイン パターンであり、Microsoft が考案した 23 のデザイン パターンのいずれにも属さないとも言えます。機能的な観点からは、工場と戦略の組み合わせである必要があります。 Microsoft は、ASP.NET 2.0 以降、主にアプリケーション構成の複数の実装を実装するためにこの設計パターンを導入しました。たとえば、開発者に最もよく知られている web.config は、データベース接続文字列、バイナリ、XML などの構成に使用されます。このモードは現在、他の場所でますます使用されています。
CreateProtector メソッド シグネチャの目的文字列について話しましょう。前回のブログ投稿では、読者が理解しやすいように、受信目的は公開キーとして理解できると述べました。厳密ではありませんが、現在のプロテクターの目的を示すロゴとして理解できます。
IDataProtector を使用すると、Microsoft.AspNetCore.DataProtection 名前空間の下にいくつかの拡張メソッドがあることがわかります:
public static class DataProtectionCommonExtensions { public static IDataProtector CreateProtector(this IDataProtectionProvider provider, IEnumerable<string> purposes); public static IDataProtector CreateProtector(this IDataProtectionProvider provider, string purpose, params string[] subPurposes); public static IDataProtector GetDataProtector(this IServiceProvider services, IEnumerable<string> purposes); public static IDataProtector GetDataProtector(this IServiceProvider services, string purpose, params string[] subPurposes); public static string Protect(this IDataProtector protector, string plaintext); public static string Unprotect(this IDataProtector protector, string protectedData); }
ご覧のとおり、CreateProtector は複数の目的を渡すことができるメソッドも提供します。 (IEnumerable, params string[])、なぜそのような必要があるのでしょうか?
実際、DataProtector には階層構造があります。IDataProtector インターフェイスをもう一度見てください。これは、IDataProtectionProvider インターフェイスも実装しています。つまり、IDataProtector 自体も IDataProtector を作成できます。
例: 私たちはメッセージ通信システムに取り組んでいますが、メッセージ通信プロセス中に、CreateProtector("Security.BearerToken") を使用して暗号化する必要があります。ただし、暗号化する場合、信頼できないクライアントからメッセージが送信されるとは限りませんので、この時点で「Security.BearerToken」という名前のユーザーがいる場合は、CreateProtector("username") で暗号化することを考えました。 Security.BearerToken をラベルとして使用する別の Protector と競合するため、
CreateProtector([ "Security.BearerToken", "User: username" ]) を使用できます。これは、
Provider.CreateProtector("Security.BearerToken).CreateProtector("User: username") と同等です。これは、最初に "Security.BearerToken" という名前のプロテクターを作成し、次に、目的 1 の下に "User: username" という名前のプロテクターを作成することを意味します。プロテクター。たとえば、ユーザーがパスワードを取得するとき、リセット コマンドを含む電子メールがユーザーのメールボックスに送信されます。このリセットには有効期限が設定されている必要があります。この有効期限が過ぎると無効になります。以前は、送信時刻をマークするためにデータベースに時刻を保存し、復号化して時刻の差をデータベースと比較する必要がありました
これを実行した後は、その必要がなくなりました。コアは、デフォルトで ITimeLimitedDataProtector というインターフェイスを提供します。まず、このインターフェイスの定義を見てみましょう:
CreateProtector(string purpose) : ITimeLimitedDataProtector This API is similar to the existing IDataProtectionProvider.CreateProtector in that it can be used to create purpose chains from a root time-limited protector. Protect(byte[] plaintext, DateTimeOffset expiration) : byte[] Protect(byte[] plaintext, TimeSpan lifetime) : byte[] Protect(byte[] plaintext) : byte[] Protect(string plaintext, DateTimeOffset expiration) : string Protect(string plaintext, TimeSpan lifetime) : string Protect(string plaintext) : string
ITimeLimitedDataProtector は、ライフサイクルを設定するためのいくつかのオーバーロードされたメソッドを提供します。暗号化メソッドの場合、ユーザーは Date TimeOffset を通じて時間を設定できます。 TimeSpan およびその他のパラメーター
対応する復号化方法があります。興味のある学生は、こちらの公式ドキュメントを参照してください。
データ保護を設定します。
在我们的 ASP.NET Core 运行的时候,系统会基于当前机器的运行环境默认配置一些关于 Data Protection 的东西,但是有些时候可能需要对这些配置做一些改变,比如在分布式部署的时候,在上一篇博文的末尾也提到过,下面就来看一下具体怎么配置的吧。
上篇文章已经提到过,我们通过以下方式来把 Data Protection 注册到服务中:
public void ConfigureServices(IServiceCollection services) { services.AddDataProtection(); }
其中AddDataProtection 返回的是一个 IDataProtectionBuilder 接口,这个接口提供了一个扩展方法PersistKeysToFileSystem() 来存储私钥。可以通过它传入一个路径来指定私钥存储的位置:
public void ConfigureServices(IServiceCollection services) { services.AddDataProtection() .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\")); }
可以传入一个共享文件夹,来存储私钥,这样在不同机器的私钥就可以保存到一个位置了。可以通过此种方式在分布式部署的时候,隔离开了机器的差异化。
如果你觉得不安全,还可以配置一个X.509证书来,进行加密:
public void ConfigureServices(IServiceCollection services) { services.AddDataProtection() .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\")) .ProtectKeysWithCertificate("thumbprint"); }
上篇文章讲过,Data Protection 的默认保存时间是90天,你可以通过以下方式来修改默认的保存时间:
public void ConfigureServices(IServiceCollection services) { services.AddDataProtection() .SetDefaultKeyLifetime(TimeSpan.FromDays(14)); }
默认情况下,即使使用相同的物理密钥库,Data Protection 也会把不同的应用程序隔离开,因为这样可以防止从一个应用程序获取另外一个应用程序的密钥。所以如果是相同的应用程序,可以设置相同的应用程序名称:
public void ConfigureServices(IServiceCollection services) { services.AddDataProtection() .SetApplicationName("my application"); }
有时候需要禁用应用程序生成密钥,或者是说我只有一个程序用来生成或者管理密钥,其他程序只是负责读的话,那么可以这样:
public void ConfigureServices(IServiceCollection services) { services.AddDataProtection() .DisableAutomaticKeyGeneration(); }
修改加密算法
可以使用UseCryptographicAlgorithms方法来修改ASP.NET Core Data Protection的默认加密算法,如下:
services.AddDataProtection() .UseCryptographicAlgorithms(new AuthenticatedEncryptionSettings() { EncryptionAlgorithm = EncryptionAlgorithm.AES_256_CBC, ValidationAlgorithm = ValidationAlgorithm.HMACSHA256 });
总结:
本篇主要是介绍了一些常用的API, 下篇介绍一些高级的用法。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持PHP中文网。
更多ASP.NET Core 数据保护(Data Protection)相关文章请关注PHP中文网!