SQL Server中保護數(shù)據(jù)的安全選項
不同于以往所有過分宣傳的數(shù)據(jù)庫漏洞，以及幾十個隱私和安全規(guī)范，新出現(xiàn)了一個讓SQL Server開發(fā)人員和數(shù)據(jù)庫管理員們陷入了不得不面對強勢用戶的尷尬境地。他們問：
你如何保護數(shù)據(jù)庫中的敏感數(shù)據(jù)?
你對你的數(shù)據(jù)庫使用了什么加密方法?
你如何將我們的數(shù)據(jù)與其他人的分離開來?
我們有很多不同的客戶——你能加密每個數(shù)據(jù)集嗎?(這是以上最壞的問題。)
雖然這些問題看上去很古怪，但是他們問出來了，你就需要知道如何應(yīng)對，無論你是一個獨立的軟件開發(fā)人員，還是給一家大公司工作，或者是在兩者之間。
許多人都這樣盲目地要求數(shù)據(jù)庫分離和加密。他們受到來自審計員、經(jīng)理們、銷售人員，或者那些不懂得數(shù)據(jù)庫安全措施工作方式的客戶們的壓力。許多人都認為分離數(shù)據(jù)集并且采用數(shù)據(jù)庫加密就像電閘開關(guān)一樣簡單。
他們不知道數(shù)據(jù)庫管理員和開發(fā)人員面臨著什么。這里有性能的需求，代碼重新編寫，必要的系統(tǒng)升級，第三方控制的實現(xiàn)，系統(tǒng)維護等等內(nèi)容。更不必說，所有這些的價格對于需要它們的人來說通常就像是一片難以下咽的藥片。
我從來不是一個大驚小怪的人，如果說到數(shù)據(jù)庫分離和加密，沒有人會拒絕這樣的事實：數(shù)據(jù)庫里面有黃金，壞人都希望在攻擊你的系統(tǒng)的時候有最大的收獲。如果數(shù)據(jù)庫沒有被充分保護，這就任憑攻擊者的處置了。
對于數(shù)據(jù)庫分離和加密，你有很多的選項。你可以升級到SQL Server 2005，編寫你自己的加密機制，或者部署一個第三方的加密系統(tǒng)，你還可以：
為每個用戶創(chuàng)建一個唯一的數(shù)據(jù)庫
為每個客戶建立一個唯一的應(yīng)用程序和數(shù)據(jù)庫服務(wù)器
為不同的數(shù)據(jù)庫和表建立(并管理)不同的用戶賬號
為每個用戶建立唯一的加密密鑰，這樣他們就可以訪問他們存放在數(shù)據(jù)庫中的自己的數(shù)據(jù)了
但是所有這些都沒有完成整個畫面。這里有太多的變數(shù)了。大多數(shù)數(shù)據(jù)庫安全技術(shù)的問題是，如果前端應(yīng)用程序或者經(jīng)過授權(quán)的SQL Server賬號可以訪問并且解密敏感數(shù)據(jù)，那么那些進行SQL注入的攻擊者或者破解了弱密碼的人也可以做。
最大多數(shù)情況中，無論你是在服務(wù)器上有一個單獨的數(shù)據(jù)庫，還是有多個數(shù)據(jù)庫分散在多個系統(tǒng)中，這一點都是適用的。底線——如果你的前端應(yīng)用程序虛弱的話，那么你的數(shù)據(jù)庫中的敏感數(shù)據(jù)仍然是有風(fēng)險的。
我想要說的是，數(shù)據(jù)庫安全控制，例如分離和加密都不輕松或者便宜。盡管有一件事情是必然的——如果你把敏感數(shù)據(jù)和私人數(shù)據(jù)放在了你的數(shù)據(jù)庫里面，那么它基本上是安全的，人們會開始問，你做了什么來保護它。你不會讓它離開你的視線的。
看看實現(xiàn)這些額外的數(shù)據(jù)庫安全控制需要涉及多少方面。把你的方式解釋給他們聽，你如何分隔每個數(shù)據(jù)庫，加密敏感信息等。給他們一個你不能做的理由。按照你已經(jīng)部署的其它控制，減少數(shù)據(jù)庫分離和加密的需求.
例如，輸入過濾，強有力的認真，甚至是所有磁盤的加密，以防你的整個數(shù)據(jù)庫服務(wù)器或者硬盤被偷去。還有，不要忽視利用好工具和人工評估進行的滲透測試。
還有正式的利用一些工具的數(shù)據(jù)庫安全審計，例如AppDetective 和NGSSQuirreL，甚至是源代碼分析工具，例如Compuware, Ounce Labs, Fortify Software, SPI Dynamics, 和 Klocwork公司提供的針對你的應(yīng)用程序的分析工具。
【相關(guān)推薦】
