Question

我们的内部安全要求我们的开发人员不了解我们的生产数据库的用户名和密码。

我们正在尝试使用web.config转换来减少部署期间手动编辑web.config文件时发生的人为错误的数量。理想情况下，我们希望web.configs完全自动化，无需人工干预。

据我了解，这需要开发人员（他们是我们组织中唯一知道如何创建和修改web.config转换的人员）来了解生产环境的连接字符串信息。

是否有一种方法可以让开发人员不知道生产连接字符串，但让他们独自负责维护web.config转换？

Answer 1

这是我提出的解决方案，我向我的团队提出建议。

<强>问题：我们希望实现一个新标准，要求使用web.config转换来消除环境之间部署期间发生的人为配置错误。这要求负责创建web.config转换文件的人员知道每个环境的所有配置值，包括连接到其他环境的字符串的用户名和密码。基础结构团队有一个策略，除了他们之外，没有人能够知道具有写访问权限的数据库用户的用户名和密码。因此，我们有冲突。

提议的解决方案： web.config中的任何配置部分都可以指向包含该部分配置的外部文件，而不是在web.config文件本身中明确定义它。
例如，不要将连接字符串部分定义为：

<connectionStrings>
    <add name="conn_ExceptionManagement" connectionString="Data source=mydb;database=App_Error_Logging;uid=user;pwd=password" providerName="System.Data.SqlClient" />
  </connectionStrings>

我们可以这样定义：

<connectionStrings configSource="myApp.ConnectionStrings.config"/>

然后创建一个名为“myApp.ConnectionStrings.config”的文件，其中包含以下内容：

<?xml version="1.0"?>
<connectionStrings>
    <add name="conn_ExceptionManagement" connectionString="Data source=mydb;database=App_Error_Logging;uid=user;pwd=password" providerName="System.Data.SqlClient" />
  </connectionStrings>

所以...我们可以在Web服务器的根目录中创建一个名为“CONFIG”的文件夹，并在其中放置一个名为“myAppName.ConnectionStrings.config”的应用程序的文件。在该文件中，我们将所有用于应用程序的连接字符串放在该环境中。然后，在我们的web.config转换中，我们不是显式更新连接字符串，而是将连接字符串配置部分更改为指向Web服务器上的该文件。这样，基础架构团队是唯一真正看到这些环境的连接字符串的人，我们无需在部署期间修改web.config中的连接字符串。此外，他们很少需要更新引用的文件（仅在更改密码或添加/删除连接字符串时），这样还可以减少部署期间发生的人为配置错误。

Answer 2

考虑一下：

带有加密密码的数据库（例如，使用SHA-2），其中包含一些“salt”。密码通过明文“密钥”识别。
一个Web服务，它返回给定密钥的加密密码。
一个标准库，用于解密密码（给定盐）并返回明文密码。

您的Web应用程序可以完整地存储连接字符串，但使用占位符作为密码。当准备好连接时，应用程序调用webservice，获取加密密码，解密密码（ EDIT：解密密码，必须使用存储在Web应用程序中的salt ），修改连接字符串，建立连接，然后忘记密码。

虽然不是一个完美的解决方案（如果你不能相信你的IT人员，那么为什么会为你工作？），但它确实可以防止程序员知道密码。另外一个好处是，您可以单独管理密码（例如，使它们过期），而无需更新Web配置中的连接字符串。

如果你真的想要“全力以赴”，你可能也会对SecureString感兴趣（这是一篇讨论SecureStrings使用的好文章，虽然你必须将SecureString转换为明文才能构建连接字符串，但它确实毫无意义：http://blogs.msdn.com/b/fpintos/archive/2009/06/12/how-to-properly-convert-securestring-to-string.aspx）

修改
最终，最安全的选择是将数据库连接包装在Web服务中，然后使用您自己的自定义凭证系统（或类似Active Directory）来访问Web服务。 Web服务将全权负责查询数据库，并可以集中维护。使用它的网站（以及这些网站的程序员）将不了解数据库细节。

这种方法有很多好处，包括完全重新构建数据库的能力（表/存储过程更改只涉及Web服务），服务器之间的切换（从SQL Server到MySQL而不是来自消费网站的打嗝），负载平衡，额外的安全层等等。

Answer 3

是的，请查看加密连接字符串：http://msdn.microsoft.com/en-us/library/ms254494(v=vs.100).aspx

Answer 4

使用可以加密和解密webconfig连接字符串的类。每次在你解密和使用的连接字符串上执行get时，加密将更像是一种工具方法，用于初始加密连接字符串以将其放入web.config文件中

您可以使用多种双向加密提供程序来执行此操作。

Answer 5

自动更新web.config绝对是一个很好的方法，但我没有看到使用web.config转换为此目的有多大价值。有一些XML API可以从脚本语言中调用（例如VBScript，PowerShell），这样就可以轻松，灵活。

如果您在web.config中使用数据库凭据，我会考虑以下部分或全部内容。

如果您的数据库支持，则理想情况下使用Windows身份验证连接数据库（例如SQL Server）。这使您免于管理数据库凭据的任务。
编写一个小实用程序，可以更新web.config中连接字符串中的密码。使用标准XML API很容易做到这一点。管理员可以在部署到生产服务器时使用它来更新密码。
使用Protected Configuration加密生产服务器上的web.config。通过直接在服务器上执行加密，您可以避免在其他任何位置复制加密密钥。例如，如果它是单个服务器，请使用DPAPI;或RSA，如果您需要在多个服务器（例如Web场）上使用web.config。

您的密码更新实用程序可以自动执行此操作。

使用web.config转换保护连接字符串的建议方法

5 个答案: