ASP.NET Core中IOptions存储对称密钥的安全性及替代方案咨询

IOptions模式本身没有任何针对敏感密钥的特殊安全防护能力，和你直接用单例存密钥的安全风险没有本质区别。
你现在的实现里，IOptions<EncryptingOptions> 默认注册为单例生命周期，配置对象里存的SymmetricKey是明文常驻进程内存的，和你自己写个单例服务存密钥的内存暴露风险完全一致：只要攻击者能拿到应用进程的内存dump、或者拿到依赖注入容器的访问权限，就能直接读到明文密钥，你之前听说的“单例存密钥不安全”的问题，原生IOptions模式半分都没解决。
甚至你控制器里的写法还额外增加了风险：你直接把存了明文密钥的Options对象存在控制器的实例字段里，等于扩大了密钥的可访问边界，后续任何能拿到控制器实例的代码都能直接读走密钥。

• 优先不要在应用进程里长期留存明文对称密钥
  生产环境优先对接系统级或者云厂商的密钥管理服务：Windows环境可以用DPAPI加密存储密钥，Linux环境用系统自带的密钥环，部署在云上就直接用对应云厂商的KMS服务，加解密操作直接走密钥服务接口，不需要把明文密钥加载到应用进程里长期驻留，从根源上掐断内存泄露密钥的可能。
• 如果业务要求必须在应用内持有对称密钥，别用普通IOptions明文存储
  可以用.NET自带的IDataProtector数据保护能力，先把对称密钥加密之后再存到配置源，要用密钥的时候临时解密，用完就释放明文副本，别把明文密钥赋值给全局单例对象的公开属性长期留存。
• 把密钥的访问范围缩到最小
  别把存了密钥的配置对象直接注入到控制器这种对外暴露的边界组件里，把加解密逻辑封装成独立的加密服务，密钥只在这个服务内部按需获取、按需使用，上层控制器只依赖加密服务的抽象接口，接触不到实际的密钥值，尽可能缩小敏感数据的可访问面。

内容的提问来源于stack exchange，提问作者Szyszka947