有關資料庫連線安全性的考慮

最近客戶在安裝某款國內著名erp管理軟體時，我在現場指導過程發現了乙個有意思的問題，雖然該軟體是由具有數十年經驗，並占有財務軟體絕對市場控制權的企業開發的，但是從其安裝過程看，還是有很多漏洞的。

其系統安裝時需要ms sqlserver的sa帳號進行配置，廠商的安裝人員想都沒想就配置了個空sa密碼，經提醒後倒是設了個密碼，不過設定完後發現已經在客戶端安裝的軟體都沒法用了，又無奈改回了空sa密碼...

從其安裝過程看，作為c/s架構的軟體，其最起碼有如下問題：

1. 這種現象說明其在安裝過程中沒有建立資料庫專用管理賬戶，而是使用了資料庫伺服器的最高管理員賬戶。如果資料庫伺服器存在多個軟體系統的資料庫，只要破解了連線帳號，就可以通吃了。

2. 該軟體客戶端的資料庫連線字串應該時記錄在客戶端的，早期的版本據說配置檔案連加密都沒做，直接將sa密碼敞開口**。此種做法一方面不安全，另一方面一旦db管理員修改了sa密碼，所有客戶機都將無法連線。

其實，改變這種問題的方法很簡單，開發難度也不大，只要做好兩件事即可：

1. 安裝過程中的資料庫配置處理

伺服器端安裝過程中，很容易做到僅使用一次資料庫伺服器管理員密碼，建立號資料庫後，自動為資料庫設定專用的操作賬戶，並自動生成賬戶密碼，記錄在配置檔案中，這樣做就可以由軟體系統負責資料庫連線帳號的安全管理(為了提高安全性，所建立的帳號應禁用帳號的登入功能）。

2. 客戶端的資料庫連線字串獲取處理

c/s模式的sql資料庫連線必須配置資料庫連線字串，而該字串包含了資料庫名，帳號及密碼，目前的做法主要有如下幾種：

1）直接明碼的方式寫入客戶端配置檔案中，安全性就不說它了。

2）使用sspi整合認證方式，但對於此方式，客戶端自動就具有資料庫的操作權，可以在不使用軟體情況下直接對資料庫操作。因此是不安全的。

3）使用加密的配置檔案，雖然具有一定的安全性，但一旦資料庫密碼發生改變，所有客戶端仍然不能登入。

由於以上三種做法都存在問題，因此我們的做法如下：

- 資料庫連線字串的配置檔案只存在於伺服器中，而不存在於客戶端中。

- 伺服器開闢專用的認證埠用於接收客戶機的認證請求，埠通訊可以配置諸多加密手段保護。

- 客戶端通過認證後，伺服器使用加密通道將資料庫連線字串傳送給客戶端

- 客戶端的資料庫連線字串儲存在記憶體中，而不是在配置檔案中，可以保證一定程度的安全。

- 一旦發現密碼洩露，只需要調整伺服器端配置檔案即可，不用改變客戶機的配置。

可見，採用埠通訊的方式設定客戶端的資料庫連線字串更加安全，也更易於管理。

當然，要想進一步提高資料庫的安全性，防止通過記憶體分析的方式獲取連線字串，還可以設定動態連線的方式處理，比如伺服器控制每個連線使用不同的帳號，並根據需求動態的改變帳號密碼。