建議使用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。

  您的密碼更新實用程序可以自動執行此操作。