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

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转换中，而不是显式更新连接字符串，而是改为更改连接字符串config部分以指向Web服务器上的该文件。 这样，基础架构团队是唯一真正看到这些环境的连接字符串的人员，并且我们消除了在部署过程中他们需要在web.config中修改连接字符串的需求。 此外，他们很少需要更新引用的文件（仅在更改密码或添加/删除连接字符串时），这样还可以减少部署期间发生的人为配置错误。

Answer 2

考虑一下：

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

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

• 一个标准的库，它解密密码（给定密码）并返回纯文本密码。

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

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

如果您真的想“全力以赴”，您可能也对SecureString感兴趣。
（这里有一篇很好的文章，讨论了SecureString的用法，尽管考虑到必须将SecureString转换为纯文本以构建连接字符串，它的确是没有意义的： http : //blogs.msdn.com/b/fpintos/存档/ 2009/06/12 /如何正确将安全字符串转换为string.aspx ）

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

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

Answer 3

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

Answer 4

使用可加密和解密webconfig连接字符串的类。 每次对您解密并使用的连接字符串执行一次获取操作时...加密更像是一种用于最初加密连接字符串以将其放入web.config文件的工具方法

您可以使用多种方式提供加密提供程序。

Answer 5

自动化对web.config的更新绝对是个好方法，但是我真的没有发现为此目的使用web.config转换会有太大价值。 有一些XML API可从脚本语言（例如VBScript，PowerShell）中调用，这将既简单又灵活。

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

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

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

• 使用“ 受保护的配置”对生产服务器上的web.config进行加密。 通过直接在服务器上进行加密，您无需将加密密钥复制到其他任何地方。 例如，如果是单个服务器，请使用DPAPI；否则，请使用DPAPI。 或RSA（如果您需要在多个服务器（例如Web场））上使用web.config。

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