有多條新聞提到了有人可以從外部訪問數(shù)據(jù)庫——通常是應該受到保護的商業(yè)解決方案——發(fā)現(xiàn)數(shù)據(jù)庫中的敏感信息，例如用戶姓名、密碼、信用卡號或者地址都是以明文存儲的，這種事情已經(jīng)太多了。因此，大多數(shù)人創(chuàng)建數(shù)據(jù)庫驅動的解決方案的第一條設計決策就是如何加密存儲數(shù)據(jù)，以便于保證它的安全，免受窺探。
sql server 中有哪一種支持可以用于加密對象和數(shù)據(jù)?從一開始就討論一下sql server 欠缺什么是明智的，或者是對于sql server中的加密部分你不應該做什么。
首先，sql server有兩個內置的密碼函數(shù)——即，pwdencrypt() 和 pwdcompare()。同時，還有兩個sql server用來管理密碼哈希的沒有正式記錄的函數(shù):pwdencrypt() 將密碼哈希過后進行存儲;pwdcompare()將提供的字符串與哈希后的字符串進行比較。不幸的是，這個哈希函數(shù)不是非常安全，它可以通過字典攻擊算法被*(類似命令行應用程序!)。
這些函數(shù)隨著sql server的版本發(fā)展而不斷進行修改，這也是另一個沒有使用它們的原因。早期版本的sql server對密碼進行的哈希，在后來的版本中無法解密，所以如果你依賴一個版本中的函數(shù)，那么當升級的時候，所有你的加密數(shù)據(jù)就都沒有用了，除非你可以首先對其解密——這也就違背了加密的最初的目的。
第二，你可能會嘗試去創(chuàng)建一個針對你的數(shù)據(jù)庫的自制的加密解決方案，但是有以下三個理由說明你不要這樣做:
除非你是加密專家，否則胡亂編寫的加密系統(tǒng)只會提供非常低級的價值不高的保護。新鮮的是，單向密碼哈希或者'rotx'形式的加密幾乎不需要費事就可以被輕松打敗。
如果由于你自己的能力的缺乏而導致加密被*，那么你的數(shù)據(jù)就完蛋了。你需要將所有的東西進行沒有加密的備份，是嗎?(即使你加密了，那里有沒有安全漏洞?)
當市面上提供有專業(yè)級別的，具有工業(yè)強度的加密解決方案的時候，你就不值得花費時間去自己做。把你的時間用于構建一個好的，堅固的數(shù)據(jù)庫，而不是再重新發(fā)明一次車輪。
那么，什么才是好的加密數(shù)據(jù)的方式呢?
對于新手，微軟提供了一個自己生成的加密解決方案，cryptoapi 。對于輕量級的加密，軍用級別的安全就不在考慮范圍之內，它具有相對容易實現(xiàn)的優(yōu)勢:管理員可以安裝一個名為capicom 的activex 控制，它可以在t-sql存儲過程中提供cryptoapi 功能。capicom 支持各種類型的雙向加密和單向哈希算法，所以管理員可以挑選最適合應用程序的問題的部分。
如果你對使用微軟的解決方案不感興趣，還有一些很好的第三方的方案可以使用。一家名為activecrypt 的軟件有限責任公司制造了xp_crypt ，它是sql server的插件，可以在視圖、程序和觸發(fā)器中通過擴展存儲過程和用戶自定義函數(shù)(在sql server 2000中)來完成加密。你可以下載一個支持無線的md5,des ，以及sha1哈希的免費版本的應用程序;其他的加密模型就是在比特深度上進行的。(完全版本是無限的。)在你自己的代碼中，你可以使用xp_crypt，與activex 控制一樣(在受限的免費版本中)。對于asp程序員來說，一個名為aspencrypt 的組件提供了一種將高級加密整合到你的代碼中的簡單方式。
對數(shù)據(jù)庫文件自身進行加密或者提供傳輸層上的安全保護怎么樣?對于前者，你可以在windows系統(tǒng)中持續(xù)使用加密文件系統(tǒng)。然而，你必須保存加密密鑰的備份，在出現(xiàn)問題的時候，這個數(shù)據(jù)有可能會丟失。對于后者，有ipsec和sql server自己的ssl加密，都是sql server和windows自帶的。你主要精力應該放在避免以明文存儲敏感數(shù)據(jù)，因為從數(shù)據(jù)庫中抽取沒有加密的數(shù)據(jù)也是最容易受到攻擊的地方。
sql server 中有哪一種支持可以用于加密對象和數(shù)據(jù)?從一開始就討論一下sql server 欠缺什么是明智的，或者是對于sql server中的加密部分你不應該做什么。
首先，sql server有兩個內置的密碼函數(shù)——即，pwdencrypt() 和 pwdcompare()。同時，還有兩個sql server用來管理密碼哈希的沒有正式記錄的函數(shù):pwdencrypt() 將密碼哈希過后進行存儲;pwdcompare()將提供的字符串與哈希后的字符串進行比較。不幸的是，這個哈希函數(shù)不是非常安全，它可以通過字典攻擊算法被*(類似命令行應用程序!)。
這些函數(shù)隨著sql server的版本發(fā)展而不斷進行修改，這也是另一個沒有使用它們的原因。早期版本的sql server對密碼進行的哈希，在后來的版本中無法解密，所以如果你依賴一個版本中的函數(shù)，那么當升級的時候，所有你的加密數(shù)據(jù)就都沒有用了，除非你可以首先對其解密——這也就違背了加密的最初的目的。
第二，你可能會嘗試去創(chuàng)建一個針對你的數(shù)據(jù)庫的自制的加密解決方案，但是有以下三個理由說明你不要這樣做:
除非你是加密專家，否則胡亂編寫的加密系統(tǒng)只會提供非常低級的價值不高的保護。新鮮的是，單向密碼哈希或者'rotx'形式的加密幾乎不需要費事就可以被輕松打敗。
如果由于你自己的能力的缺乏而導致加密被*，那么你的數(shù)據(jù)就完蛋了。你需要將所有的東西進行沒有加密的備份，是嗎?(即使你加密了，那里有沒有安全漏洞?)
當市面上提供有專業(yè)級別的，具有工業(yè)強度的加密解決方案的時候，你就不值得花費時間去自己做。把你的時間用于構建一個好的，堅固的數(shù)據(jù)庫，而不是再重新發(fā)明一次車輪。
那么，什么才是好的加密數(shù)據(jù)的方式呢?
對于新手，微軟提供了一個自己生成的加密解決方案，cryptoapi 。對于輕量級的加密，軍用級別的安全就不在考慮范圍之內，它具有相對容易實現(xiàn)的優(yōu)勢:管理員可以安裝一個名為capicom 的activex 控制，它可以在t-sql存儲過程中提供cryptoapi 功能。capicom 支持各種類型的雙向加密和單向哈希算法，所以管理員可以挑選最適合應用程序的問題的部分。
如果你對使用微軟的解決方案不感興趣，還有一些很好的第三方的方案可以使用。一家名為activecrypt 的軟件有限責任公司制造了xp_crypt ，它是sql server的插件，可以在視圖、程序和觸發(fā)器中通過擴展存儲過程和用戶自定義函數(shù)(在sql server 2000中)來完成加密。你可以下載一個支持無線的md5,des ，以及sha1哈希的免費版本的應用程序;其他的加密模型就是在比特深度上進行的。(完全版本是無限的。)在你自己的代碼中，你可以使用xp_crypt，與activex 控制一樣(在受限的免費版本中)。對于asp程序員來說，一個名為aspencrypt 的組件提供了一種將高級加密整合到你的代碼中的簡單方式。
對數(shù)據(jù)庫文件自身進行加密或者提供傳輸層上的安全保護怎么樣?對于前者，你可以在windows系統(tǒng)中持續(xù)使用加密文件系統(tǒng)。然而，你必須保存加密密鑰的備份，在出現(xiàn)問題的時候，這個數(shù)據(jù)有可能會丟失。對于后者，有ipsec和sql server自己的ssl加密，都是sql server和windows自帶的。你主要精力應該放在避免以明文存儲敏感數(shù)據(jù)，因為從數(shù)據(jù)庫中抽取沒有加密的數(shù)據(jù)也是最容易受到攻擊的地方。