为什么无法从AppSettings.json加载ASP.NET Core AddDataProtection键

Question

我想知道为什么没有一种简单的方法可以从AppSettings.json加载安全密钥，而不是将其作为XML加载到文件系统之外？

这里是Microsoft文档中的示例。

services.AddDataProtection()
    .PersistKeysToFileSystem("{PATH TO COMMON KEY RING FOLDER}")
    .SetApplicationName("SharedCookieApp");

services.ConfigureApplicationCookie(options => {
    options.Cookie.Name = ".AspNet.SharedCookie";
    options.Cookie.Path = "/";
});

我只是想知道为什么没有以下内容。

services.AddDataProtection()
    .PersistKeysToAppSetings("EncryptionKeys")
    .SetApplicationName("SharedCookieApp");

services.ConfigureApplicationCookie(options => {
    options.Cookie.Name = ".AspNet.SharedCookie";
    options.Cookie.Path = "/";
});

我不明白为什么将密钥存储在XML文件中与将密钥存储在AppSettigs.json中为什么会有所不同。现在我知道格式是不同的，但是它或多或少不是安全的吗？对吗？

我只想确保我没有错过任何东西。

假设：

1. AppSettings.json与磁盘上的其他XML文件一样安全
2. Azure AppSettings已安全存储，并且只能由允许的帐户访问
3. Azure AppSettings值将覆盖任何上传的“开发人员”值
4. 开发人员肯定不会将其生产密钥存储在源代码中，对吗？ ：）
5. 我知道这对于过期/回收密钥不起作用

Answer 1

“很复杂”

1. 我们按需创建密钥。
2. 我们创建了多个密钥，在密钥过期之前，我们创建了一个新密钥。
3. 我们需要在应用程序之间同步密钥。
4. 我们需要尽可能对密钥进行加密。

AppSettings不提供任何这些功能，应用程序无法更新其自己的设置文件，因此规则1和2不会在网站之间复制，而实例3除外，网站不会复制已更改的应用程序设置文件，您可以不要对应用设置中的内容进行加密，以排除4。

格式不是问题，您可以编写自己的加密包装程序来应对＃4，但是其余的操作仍然是必需的，因此现在您必须更改设置的工作方式，以便对其进行读/写（和安全地读写），然后说服Web主机支持实例之间自定义设置文件的同步。