根据我的阅读here，建议在开发过程中使用秘密管理器存储机密，然后在部署时使用环境变量 IIS。我不太清楚最好的方法是什么 - 我需要能够在不同的IIS应用程序中将相同的变量设置为不同的值，因此系统范围的环境变量设置不起作用。
我知道我可以在web.config中为应用程序设置变量，但是当您执行Web部署时，即使项目中没有web.config，VS也会覆盖服务器上的web.conifg。我知道使用Web部署来部署到生产可能不是一个好习惯，但我们希望将其用于暂存环境等。
如果目标网站上已存在覆盖web.config，是否有办法阻止Web部署？
答案 0 :(得分：5)
ASP.NET Core不使用Web.config。它是作为发布的一部分添加的，仅用于与IIS中的托管兼容。您无意以任何有意义的方式修改或使用它。
ASP.NET Core中的配置提供程序的内置选项包括：JSON，命令行参数，用户秘密，环境变量和Azure Key Valult。但是，User Secrets仅用于开发，并且在IIS中托管时难以使用命令行参数。 （从技术上讲，您实际上可以修改Web.config以添加命令行参数，但如上所述，这将在下一次发布时被覆盖，因此它不是最稳定的方法。）
在JSON，环境变量和Azure Key Vault的其余选项中，只有Azure Key Vault支持加密。无论您是否实际在Azure中托管，都可以使用Azure Key Vault，但它不是免费的。不过，它也不是很贵，所以可能值得一试。
JSON可能是最糟糕的选择，在安全方面，主要是因为它要求您实际将秘密存储在源控件中，这是（或应该）非启动器。环境变量虽然未加密，但可以得到保护。但是，如果相同的环境变量需要不同的秘密，那么在同一台服务器上运行多个应用程序很困难（尽管技术上并非不可能）。您可以在技术上在用户级别设置环境变量，然后您还可以指定应用程序池以作为特定用户运行。这虽然有很多设置。
也就是说，完全可以创建自己的配置提供程序，这意味着您可以在技术上使用您喜欢的任何内容。例如，您可以编写SQL Server配置提供程序，然后将凭据存储在那里。您仍然需要在某处配置连接字符串，但也许您可以为所有站点的配置使用相同的连接字符串。
答案 1 :(得分：3)
可以通过新配置API添加的任何其他文件配置源（如appsettings.json）在未加密之前无法使用。
可以使用环境变量，但前提是您可以保证不能在prod机器上执行env变量的快照。查看Environment Variables Considered Harmful for Your Secrets以了解有关此风险的更多详细信息。
如果您在Azure上托管，请查看Azure Key Vault
有许多工具/服务，例如Hashicorp Vault，有助于处理敏感数据