在我最近撰寫的一本書中，我嘗試著為菜鳥SQL Server管理員解釋SQL Server的安全性。必須承認的一點是，很少有應用程序是以SQL Server安全所希望的方式來進行編寫的。我把問題歸咎于懶惰的數(shù)據(jù)庫開發(fā)人員。

不 足為奇的是，這本書早期的評審就是幾個開發(fā)人員，而且對我的評論表現(xiàn)出了反感。有一個人寫到，“SQL Server 并非唯一的數(shù)據(jù)庫，我編寫的代碼還必須要與Oracle相匹配。”換句話說，要取代對每個數(shù)據(jù)庫平臺安全的特定考量，他只要采用***標準即可，因為它簡單 易行，而且不用考慮對用戶產(chǎn)生的影響。

你需要意識到數(shù)據(jù)庫開發(fā)人員和廠商的態(tài)度，而且你需要與其抗爭。

[[130414]]

數(shù)據(jù)庫安全技術***的標準是在數(shù)據(jù)庫中只創(chuàng)建一個用戶賬戶，然后讓每個應用程序副本都使用此單一用戶賬戶登錄。此應用程序會實現(xiàn)其自身的“安全性”，對于微軟，Oracle以及其他平臺公司數(shù)以百記專家開發(fā)出來的平臺安全性，我是確信它是健壯的。

此方法的問題主要體現(xiàn)在以下幾個重要方面：

審計：當只有一個用戶賬戶可以訪問數(shù)據(jù)的時候，你無法知道到底是誰在操作。當然，應用程序可以實現(xiàn)其自身的審計跟蹤，但是任何有相關知識的用戶如果擁有賬戶名和密碼都可以繞過審計跟蹤。

安全性：將用戶名和密碼嵌入進一個連接字符串使其不易讓人發(fā)現(xiàn)信息?，F(xiàn)成的工具可以在幾秒鐘內反編譯常見的企業(yè)應用程序，這使得連接字符串和其密碼都采取了明文的方式。

故障排除：由于你不能將一個單獨的數(shù)據(jù)庫連接指定給某個人，因此很難對性能和操作問題進行故障排除。當一個用戶抱怨運行緩慢的時候，管理員也無法準確定位問題。這就意味著問題會持續(xù)更長的時間。

而 對于一個開發(fā)人員來說，換做讓他的應用程序使用SQL Server自帶安全幾乎是不費吹灰之力。只需要對主連接字符串做出更改，移除用戶名和密碼并讓用戶的Windows登錄憑證加以通過。在大多數(shù)環(huán)境中， 除了授權服務器端的權限讓人們可以讀寫必要的數(shù)據(jù)之外，這都是數(shù)據(jù)庫管理員所需要做的。你會利用SQL Server自己的審計功能，更好的進行故障排除，并且對于每個應用程序副本中嵌入的全能用戶不提供明文密碼來提升安全性。

那么你要如何與 ***標準的數(shù)據(jù)庫安全技術相對抗呢?很簡單。建立采購標準。確保新應用程序使用SQL Server的Windows身份驗證機制。改變現(xiàn)有的應用程序。你可能需要和廠商制定一個時間表或是讓他們了解到豐厚的“維護費用”收入不是那么好賺 的。掌控你的環(huán)境——有些人可以為你提供***的安全性但這對他們而言一切都很簡單，不要把公司交給這種人。