ASP.NET Core 数据保护(Data Protection 集群场景)【下】

前言

接【中篇】,在有一些场景下,我们需要对 ASP.NET Core 的加密方法进行扩展,来适应我们的需求,这个时候就需要使用到了一些 Core 提供的高级的功能。

本文还列举了在集群场景下,有时候我们需要实现自己的一些方法来对Data Protection进行分布式配置。

加密扩展

IAuthenticatedEncryptor 和 IAuthenticatedEncryptorDescriptor

IAuthenticatedEncryptor是 Data Protection 在构建其密码加密系统中的一个基础的接口。
一般情况下一个key 对应一个IAuthenticatedEncryptorIAuthenticatedEncryptor封装了加密操作中需要使用到的秘钥材料和必要的加密算法信息等。

下面是IAuthenticatedEncryptor接口提供的两个 api方法:

其中接口中的参数additionalAuthenticatedData表示在构建加密的时候提供的一些附属信息。

IAuthenticatedEncryptorDescriptor接口提供了一个创建包含类型信息IAuthenticatedEncryptor实例方法。

密钥管理扩展

在密钥系统管理中,提供了一个基础的接口IKey,它包含以下属性:

IKey还提供了一个创建IAuthenticatedEncryptor实例的方法CreateEncryptorInstance。

IKeyManager接口提供了一系列用来操作Key的方法,包括存储,检索操作等。他提供的高级操作有:

  • 创建一个Key 并且持久存储
  • 从存储库中获取所有的 Key
  • 撤销保存到存储中的一个或多个键

XmlKeyManager
通常情况下,开发人员不需要去实现IKeyManager来自定义一个 KeyManager。我们可以使用系统默认提供的XmlKeyManager类。

XMLKeyManager是一个具体实现IKeyManager的类,它提供了一些非常有用的方法。

  • IAuthenticatedEncryptorConfiguration 主要是规定新 Key 使用的算法。
  • IXmlRepository 主要控制 Key 在哪里持久化存储。

IXmlRepository

IXmlRepository接口主要提供了持久化以及检索XML的方法,它只要提供了两个API:

  • GetAllElements() : IReadOnlyCollection
  • StoreElement(XElement element, string friendlyName)

我们可以通过实现IXmlRepository接口的StoreElement方法来定义data protection xml的存储位置。

GetAllElements来检索所有存在的加密的xml文件。

接口部分写到这里吧,因为这一篇我想把重点放到下面,更多接口的介绍大家还是去官方文档看吧~

集群场景

上面的API估计看着有点枯燥,那我们就来看看我们需要在集群场景下借助于Data Protection来做点什么吧。

就像我在【上篇】总结中末尾提到的,在做分布式集群的时候,Data Protection的一些机制我们需要知道,因为如果不了解这些可能会给你的部署带来一些麻烦,下面我们就来看看吧。

在做集群的时,我们必须知道并且明白关于 ASP.NET Core Data Protection 的三个东西:

1、程序识别者

“Application discriminator”,它是用来标识应用程序的唯一性。
为什么需要这个东西呢?因为在集群环境中,如果不被具体的硬件机器环境所限制,就要排除运行机器的一些差异,就需要抽象出来一些特定的标识,来标识应用程序本身并且使用该标识来区分不同的应用程序。这个时候,我们可以指定ApplicationDiscriminator

services.AddDataProtection(DataProtectionOptions option)的时候,ApplicationDiscriminator可以作为参数传递,来看一下代码:

可以看到这个扩展返回的是一个IDataProtectionBuilder,在IDataProtectionBuilder还有一个扩展方法叫 SetApplicationName ,这个扩展方法在内部还是修改的ApplicationDiscriminator的值。也就说以下写法是等价的:

也就是说集群环境下同一应用程序他们需要设定为相同的值(ApplicationName or ApplicationDiscriminator)。

2、主加密键

“Master encryption key”,主要是用来加密解密的,包括一客户端服务器在请求的过程中的一些会话数据,状态等。有几个可选项可以配置,比如使用证书或者是windows DPAPI或者注册表等。如果是非windows平台,注册表和Windows DPAPI就不能用了。

如果在集群环境中,他们需要具有配置相同的主加密键。

3、加密后存储位置

在【上篇】的时候说过,默认情况下Data Protection会生成 xml 文件用来存储session或者是状态的密钥文件。这些文件用来加密或者解密session等状态数据。

就是上篇中说的那个私钥存储位置:

1、如果程序寄宿在 Microsoft Azure下,存储在“%HOME%\ASP.NET\DataProtection-Keys” 文件夹。
2、如果程序寄宿在IIS下,它被保存在HKLM注册表的ACLed特殊注册表键,并且只有工作进程可以访问,它使用windows的DPAPI加密。
3、如果当前用户可用,即win10或者win7中,它存储在“%LOCALAPPDATA%\ASP.NET\DataProtection-Keys”文件夹,同样使用的windows的DPAPI加密。
4、如果这些都不符合,那么也就是私钥是没有被持久化的,也就是说当进程关闭的时候,生成的私钥就丢失了。

集群环境下:
最简单的方式是通过文件共享、DPAPI或者注册表,也就是说把加密过后的xml文件都存储在相同的地方。为什么说最简单,因为系统已经给封装好了,不需要写多余的代码了,但是要保证文件共享相关的端口是开放的。如下:

你也可以自己扩展方法来自己定义一些存储,比如使用数据库或者Redis等。

不过通常情况下,如果在linux上部署的话,都是需要扩展的。下面来看一下我们想要用redis存储,该怎么做呢?

如何扩展加密键集合的存储位置?

首先,定义个针对IXmlRepository接口的 redis 实现类RedisXmlRepository.cs

然后任意一个扩展类中先定义一个扩展方法:

最终Services中关于DataProtection是这样的:

在上面的配置中,我把所有可以使用的配置都列出来了哦,实际项目中应该视实际情况选择。

总结

关于ASP.NET Core Data Protection 系列终于写完了,其实这这部分花了蛮多时间的,对于Data Protection来说我也是一个循循渐进的学习过程,希望能帮助到一些人。

如果您觉得本篇文章对你有用的话,不妨点个【推荐】。


本文地址:http://www.cnblogs.com/savorboard/p/dotnetcore-data-protected-farm.html
作者博客:Savorboard
欢迎转载,请在明显位置给出出处及链接

发表评论