2

我们有一种情况，我们的内部安全要求我们的开发人员不知道我们生产数据库的用户名和密码。

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

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

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

4

5 回答 5

3

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

问题： 我们希望实施一个新标准，要求使用 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 中的连接字符串的需要。此外，

于 2012-10-05T13:46:49.617 回答
2

考虑一下：

  • 具有加密密码（例如使用 SHA-2）的数据库，其中包括一些“盐”。密码通过明文“密钥”识别。

  • 返回给定密钥的加密密码的 Web 服务。

  • 解密密码（给定盐）并返回明文密码的标准库。

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

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

如果您真的想“全力以赴”，您可能也对SecureString感兴趣。
（这里有一篇很好的文章讨论了 SecureStrings 的使用，虽然考虑到您必须将 SecureString 转换为纯文本才能构建连接字符串，但这确实有点毫无意义：http: //blogs.msdn.com/b/fpintos/存档/2009/06/12/how-to-properly-convert-securestring-to-string.aspx）

编辑
最终，最安全的选择是将数据库连接包装在 Web 服务中，然后使用您自己的自定义凭据系统（或 Active Directory 之类的系统）访问 Web 服务。Web 服务将单独负责查询数据库并且可以集中维护。使用它的网站（以及这些网站的程序员）将不知道数据库的详细信息。

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

于 2012-10-04T20:32:24.027 回答
0

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

于 2012-10-04T20:27:38.860 回答
0

使用一个类来加密和解密 webconfig 连接字符串。每次对您解密和使用的连接字符串执行获取...

您可以使用多种两种方式的加密提供程序来执行此操作。

于 2012-10-04T20:32:00.097 回答
0

自动更新 web.config 绝对是一种好方法，但我并没有真正看到为此目的使用 web.config 转换的价值。有可从脚本语言（例如 VBScript、PowerShell）调用的 XML API，这将同样简单且更灵活。

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

  • 如果您的数据库支持（例如 SQL Server），最好使用 Windows 身份验证连接到数据库。这使您免于管理数据库凭据的任务。

  • 编写一个小实用程序，可以更新 web.config 中连接字符串中的密码。使用标准 XML API 很容易做到这一点。管理员可以在部署到生产服务器时使用它来更新密码。

  • 使用Protected Configuration在生产服务器上加密 web.config 。通过直接在服务器上进行加密，您可以避免将加密密钥复制到其他任何地方。例如，如果是单个服务器，则使用 DPAPI；或 RSA，如果您需要在多个服务器（例如网络场）上使用 web.config。

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

于 2012-10-04T20:59:35.363 回答