Asp.net 如何确保多个connectionString密码安全、独立且易于部署？

我知道这里已经有很多关于这个主题的问题（我已经读了尽可能多的内容），但我还没能找出如何最好地满足我的特定标准。以下是目标：

ASP.NET应用程序将在几个不同的web服务器上运行，包括用于开发的本地主机工作站。这意味着无法使用计算机密钥加密web.config。web服务器的每个“类型”或环境（dev、test、prod）都有自己相应的数据库（dev、test、prod）。我们希望分离这些连接字符串，以便处理“dev”代码的开发人员无法看到任何“prod”连接字符串密码，也不允许将这些生产密码部署到错误的服务器或提交到SVN

应用程序应该能够根据服务器名称（使用switch语句）决定尝试使用哪个连接字符串。例如，“localhost”和“dev.example.com”应该知道如何使用DevDatabaseConnectionString，“test.example.com”将使用TestDatabaseConnectionString，“www.example.com”将使用ProdDatabaseConnectionString。这样做的原因是为了限制任何部署事故的发生，即错误类型的web服务器连接到错误的数据库

理想情况下，完全相同的可执行文件和web.config应该能够在这些环境中的任何一个上运行，而无需在每次部署时分别定制或配置每个环境（在部署过程中，似乎有一天很容易忘记/搞糟一些事情，这就是为什么我们不再只在每个目标上更改一个连接字符串的原因）。部署目前是通过FTP完成的。更新：使用“构建事件”并修改部署过程可能不是一个坏主意

我们将不具有对生产web服务器的命令行访问权限。这意味着使用aspnet_regiis.exe加密web.config已退出。更新：我们可以通过编程方式执行此操作，因此这一点没有意义

我们希望不必在密码更改时重新编译应用程序，因此使用web.config（或db.config或其他什么）似乎最有意义

开发人员不应该能够获取生产数据库密码。如果开发人员将源代码签出到其本地主机笔记本电脑上（这将确定它应该使用DevDatabaseConnectionString，还记得吗？）如果笔记本电脑丢失或被盗，则不可能获取其他连接字符串。因此，不能考虑使用一个RSA私钥来取消对所有三个密码的加密。（与上面的第3条相反，如果我们这样做的话，我们似乎需要三个独立的密钥文件；它们可以在每台机器上安装一次，如果错误的密钥文件部署到错误的服务器上，最糟糕的情况是应用程序无法解密任何内容，并且不允许错误的主机访问错误的数据库！）

更新/附录：该应用程序有几个独立的面向web的组件：一个经典的ASMX web服务项目、一个ASPX web表单应用程序和一个更新的MVC应用程序。为了避免在每个单独的项目中为每个单独的环境配置相同的连接字符串，最好只在一个pla中出现ce。（可能在我们的DAL类库中或在单个链接的配置文件中。）

我知道这可能是一个主观的问题（要求以“最佳”的方式做某事），但考虑到我提到的标准，我希望确实会出现一个最佳答案

谢谢大家!

您可以有多个具有相同加密密钥的web服务器。您可以在机器配置中执行此操作，只要确保每个密钥相同即可

一种常见的做法是将加密的第一个连接字符串存储在计算机上的某个位置，例如注册表。服务器使用该字符串进行连接后，它将检索数据库中管理的所有其他连接字符串（也加密）。这样可以根据授权要求（请求者、正在使用的应用程序等）动态生成连接字符串。例如，根据上下文和用户/组，可以使用不同的权限访问相同的表

---

我相信此方案解决了您的所有（或大部分？）问题。

集成身份验证/windows身份验证是一个很好的选择。没有密码，至少没有需要存储在web.config中的密码。事实上，除非管理员明确地将其从我手中拿走，否则这是我更喜欢的选项

就我个人而言，对于因机器而异的任何内容（不仅仅是连接字符串），我使用以下技术从web.config中输入了一个外部引用：

当我把代码扔给生产服务器管理员时，他得到了一个新的web.config，但没有得到外部文件——他使用了他以前的文件。

（首先，哇，我想2或3个“快速段落”比我想象的要长一点！我来了…）

我得出的结论是（也许你不同意我的观点）在服务器上“保护”web.config的能力（或通过使用aspnet_iisreg）只有有限的好处，可能不是一件好事，因为它可能会给人一种错误的安全感。我的理论是，如果有人能够访问文件系统以便首先读取此web.config，那么他们也可能有权创建自己的简单ASPX文件，该文件可以“取消保护”但如果未经授权的人在您的文件系统中四处游荡……那么您手头就有更大的问题，所以我的所有担心现在都没有意义了！1

我还意识到，在DLL中安全地隐藏密码也不是万无一失的方法，因为它们