SQL Server 2008中的加密和密鑰管理
服務(wù)器級安全可能是系統(tǒng)管理員最關(guān)心的問題,而對于數(shù)據(jù)庫來說,所有操作都是在生產(chǎn)環(huán)境中完成的。在大多數(shù)情況下,數(shù)據(jù)庫管理員會將數(shù)據(jù)庫細(xì)節(jié)的問題留給數(shù)據(jù)庫開發(fā)人員處理,只要開發(fā)人員在環(huán)境的限制內(nèi)工作。SQL Server 2008提供了大量確保數(shù)據(jù)庫安全的功能。
數(shù)據(jù)加密
SQL Server 2000 及其早期版本不支持加密存儲在數(shù)據(jù)庫中的數(shù)據(jù)。為什么需要加密存儲在安全性良好的數(shù)據(jù)庫(位于安全地嵌套在最新的防火墻之后的安全服務(wù)器上)中的數(shù)據(jù)?這是因為一個重要的、叫做 defense in depth 的舊安全規(guī)范。Defense in depth 的意味著分層防御,即使攻擊者成功打破了最外層防御,他們?nèi)匀恍枰黄埔粚咏右粚拥姆烙拍塬@得成功。在數(shù)據(jù)庫中,這意味著攻擊者通過了防火墻和從服務(wù)器到數(shù)據(jù)庫的 Windows 安全以后,仍然需要進行一些惡劣的、野蠻的和強制的黑客攻擊來解碼您的數(shù)據(jù)。另外,在如今這個立法保護數(shù)據(jù)和隱私的大環(huán)境中,數(shù)據(jù)需要加強保護。
SQL Server 2008 使用對稱密鑰、非對稱密鑰和數(shù)字證書,為各種類型的數(shù)據(jù)加密提供了豐富的支持。最出色的是,它為您管理密鑰,而密鑰管理是迄今為止加密中最難的部分。保密是一件很難的事情。
管理員可能至少需要管理圖10所示層次結(jié)構(gòu)中的上級密鑰。數(shù)據(jù)庫管理員需要理解服務(wù)器級的服務(wù)主密鑰和數(shù)據(jù)庫級的數(shù)據(jù)庫主密鑰。每一個密鑰都保護其子密鑰,子密鑰又保護其子密鑰,從樹形結(jié)構(gòu)圖依次向下。密碼保護對稱密鑰或證書時例外,這是 SQL Server 使用戶管理自己的密鑰,以及負(fù)責(zé)保密密鑰的方法。
圖 1:SQL Server 2008 中的加密密鑰層次結(jié)構(gòu)
注意:Microsoft 不推薦直接使用證書或非對稱密鑰加密數(shù)據(jù)。非對稱密鑰加密的速度很慢,并且使用此機制保護的數(shù)據(jù)量有限(這取決于密鑰模數(shù)的大?。???梢允褂妹艽a,而不是數(shù)據(jù)庫主密鑰保護證書和非對稱密鑰。
服務(wù)主密鑰是一個規(guī)定 SQL Server 中所有密鑰和證書的密鑰。它是 SQL Server 在安裝期間自動創(chuàng)建的對稱密鑰。顯然,它是一個至關(guān)重要的密鑰,因為如果此密鑰泄露了,那么攻擊者最終將解碼服務(wù)中由 SQL Server 管理的每個密鑰。Windows 中的數(shù)據(jù)保護 API (Data Protection API, DPAPI) 保護服務(wù)主密鑰。
SQL Server 為您管理服務(wù)主密鑰。雖然您可以對其執(zhí)行維護任務(wù),將其轉(zhuǎn)存到一個文件中,重新生成它,以及從文件中將其還原。不過,大多數(shù)情況下,無需對密鑰做任何更改。備份服務(wù)主密鑰以防止密鑰損壞對于管理員來說是明智的選擇。
在數(shù)據(jù)庫范圍內(nèi),數(shù)據(jù)庫主密鑰是數(shù)據(jù)庫中所有密鑰、證書和數(shù)據(jù)的根加密對象。每個數(shù)據(jù)庫都有惟一的主密鑰;嘗試創(chuàng)建第二個密鑰時,會出現(xiàn)錯誤提示。必須在使用前通過 CREATE MASTER KEY Transact-SQL 語句和用戶提供的密碼創(chuàng)建一個數(shù)據(jù)庫主密鑰:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'EOhnDGS6!7JKv'
SQL Server 使用由密碼和服務(wù)主密鑰派生出來的三重 DES 密鑰加密密鑰。第一個副本存儲在數(shù)據(jù)庫中,第二個存儲在主數(shù)據(jù)庫中。由于服務(wù)主密鑰保護數(shù)據(jù)庫主密鑰,因此可能在需要時由SQL Server 自動加密數(shù)據(jù)庫主密鑰。最終應(yīng)用程序或用戶無需使用密碼顯式打開主密鑰,這是層次結(jié)構(gòu)保護密鑰的主要優(yōu)勢。
分離一個存在現(xiàn)有主密鑰的數(shù)據(jù)庫,并將其移動到另一個服務(wù)器上是一個難題。問題在于新服務(wù)器的服務(wù)主密鑰與舊服務(wù)器的服務(wù)主密鑰不同。因此,服務(wù)器不能自動解密數(shù)據(jù)庫主密鑰??梢酝ㄟ^使用加密密碼打開數(shù)據(jù)庫主密鑰,然后使用 ALTER MASTER KEY 語句以新的服務(wù)主密鑰對其加密的方法避開這個問題。否則,總是需要顯式打開數(shù)據(jù)庫主密鑰以后才能使用。
如果存在數(shù)據(jù)庫主密鑰,那么開發(fā)人員就可以使用它創(chuàng)建三種類型中的任何一種密鑰,具體取決于加密所需求的類型:
非對稱密鑰,使用公鑰/私鑰對進行公鑰加密
對稱密鑰,用于在同一個密鑰分別加密和解密數(shù)據(jù)的方面共享秘密
證書,實質(zhì)上用于包裝公鑰
由于所有加密選項及其已經(jīng)深層集成于服務(wù)器和數(shù)據(jù)庫中,因此現(xiàn)在加密是將防御的最終層添加到數(shù)據(jù)的可行方法。然而,需明智使用工具,因為加密給服務(wù)器增加了大量的處理開銷。
透明數(shù)據(jù)加密
在 SQL Server 2005 中,可以使用數(shù)據(jù)庫引擎加密功能,通過編寫自定義 Transact-SQL 加密數(shù)據(jù)庫中的數(shù)據(jù)。SQL Server 2008 引入了透明的數(shù)據(jù)加密,改進了這種狀況。
透明數(shù)據(jù)加密在數(shù)據(jù)庫級執(zhí)行所有加密操作,這消除了應(yīng)用程序開發(fā)人員創(chuàng)建自定義代碼來加密和解密數(shù)據(jù)的需要。數(shù)據(jù)在寫入磁盤時被加密,在從磁盤讀取時解密。通過使用 SQL Server 透明地管理加密和解密,就可以在不改變現(xiàn)有應(yīng)用程序的情況下確保數(shù)據(jù)庫中業(yè)務(wù)數(shù)據(jù)的安全,如圖 11 所示。
圖 2:透明數(shù)據(jù)加密
數(shù)據(jù)庫加密密鑰(Database Encryption Key,DEK)用于執(zhí)行加密和解密操作,該DEK存儲在數(shù)據(jù)庫啟動記錄中,以便在恢復(fù)過程中使用??梢允褂梅?wù)主密鑰(Service Master Key)或硬件安全模塊(Hardware Security Module,HSM)保護 DEK。HSM 通常是 USB 設(shè)備或智能卡,因為不易被盜或丟失。
#p#
擴展的密鑰管理
隨著法規(guī)遵從性需求的不斷增長以及對數(shù)據(jù)隱私的整體關(guān)注,越來越多的組織將加密用作提供深層防御解決方案的手段。隨著組織越來越多地使用加密和密鑰來保護數(shù)據(jù),密鑰管理也變得更加復(fù)雜。一些高安全性數(shù)據(jù)庫要使用數(shù)千個密鑰,并且必須部署一個系統(tǒng)來存儲、注銷和重新生成這些密鑰。而且,應(yīng)該將這些密鑰與數(shù)據(jù)分開存儲以增強安全性。
SQL Server 2008 為第三方供應(yīng)商的使用公開了加密功能。這些解決方案可以與 SQL Server 2005 和 SQL Server 2008 數(shù)據(jù)庫無縫地一起工作并提供了企業(yè)級專用密鑰管理。這將密鑰管理工作負(fù)載從 SQL Server 轉(zhuǎn)移到了專用密鑰管理系統(tǒng)。
SQL Server 2008 中擴展的密鑰管理還支持使用 HSM 提供密鑰與數(shù)據(jù)的物理分離。
代碼模塊簽名
在 SQL Server 中提供加密的一個好處就是它提供了使用證書對代碼模塊(存儲過程、函數(shù)、觸發(fā)器和事件通知)進行數(shù)字簽名的能力。這提供了對數(shù)據(jù)庫表和其他對象訪問的更細(xì)粒度的控制。像加密數(shù)據(jù)一樣,您使用證書中的私鑰簽名代碼。其結(jié)果是在該經(jīng)過簽名的代碼模塊中使用的表只能通過該代碼訪問并且不允許在代碼模塊之外。換句話說,只能使用已經(jīng)用于簽名該模塊的證書獲得對該表的訪問。
對于存儲過程而言,效果也是一樣的。例如,如果有完整的所有權(quán)鏈,您可以謹(jǐn)慎控制哪些用戶獲得該過程的 EXECUTE 權(quán)限,并且可以拒絕他們對基礎(chǔ)表的直接訪問。但這在過程的所有權(quán)鏈被破壞或執(zhí)行動態(tài) SQL 時不起作用,此時要求執(zhí)行該過程的用戶擁有對基礎(chǔ)表的權(quán)限。實現(xiàn)同樣效果的另一種方式是使用 EXECUTE AS,但這改變了過程執(zhí)行的安全上下文。這可能不是理想的情況,例如,需要在表中記錄實際使該過程運行的用戶時(沒有要求將用戶名作為過程的參數(shù))。
簽名代碼模塊的另一個好處就是防止對代碼模塊作出未經(jīng)授權(quán)的更改。像其他經(jīng)過數(shù)字簽名的文檔一樣,在代碼改變時,證書將失效。代碼不在證書上下文中執(zhí)行,因此任何被提供了證書訪問權(quán)限的對象都將不可訪問。
要繼續(xù)訪問它們,需要創(chuàng)建一個證書,將該證書與新用戶關(guān)聯(lián)并使用該證書簽名過程。授予該用戶執(zhí)行該存儲過程必要的任何權(quán)限。實質(zhì)上,已經(jīng)將該用戶作為次級身份標(biāo)識添加到了存儲過程安全上下文中。然后,授予需要執(zhí)行該過程的任何用戶或角色執(zhí)行權(quán)限。以下代碼展示了這些步驟。假設(shè)您想要簽名 mySchema.GetSecretStuff 過程,并且所有引用的對象已經(jīng)存在于數(shù)據(jù)庫中:
CREATE CERTIFICATE certCodeSigning -- Sign the stored procedure -- Map a user to the certificate --Assign SELECT permissions to new certUser -- Grant execute permission to the user who will run the code |
現(xiàn)在只有明確授予對該存儲過程具有 EXECUTE 權(quán)限的用戶能夠訪問該表的數(shù)據(jù)。
【編輯推薦】