Security

SQL Server 2008加密的簡單實現

  • October 27, 2011

我正在考慮使用一些 SQL Server 2008 的加密。

我在 MSDN 上閱讀了以下文章:

**Q1a:**是否為每個數據庫實例創建主密鑰密碼?

IF NOT EXISTS 
   (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
   CREATE MASTER KEY ENCRYPTION BY 
   PASSWORD = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
GO

Q1b:如果我在 Server1 上創建主密鑰密碼並加密表上的列。當我備份該數據庫(.bak)時,我是否能夠將數據庫恢復到另一個 Server2,或者我是否必須在 Server2 上使用相同的密碼創建一個主密鑰?

Q2 : 如果我想恢復到另一台伺服器,是否需要備份證書、主密鑰或對稱密鑰?

CREATE CERTIFICATE HumanResources037
  WITH SUBJECT = 'Employee Social Security Numbers';
GO

CREATE SYMMETRIC KEY SSN_Key_01
   WITH ALGORITHM = AES_256
   ENCRYPTION BY CERTIFICATE HumanResources037;
GO

Q3 : 什麼時候應該打開對稱密鑰?是否應該在每次選擇之前完成然後關閉?即在儲存過程開始時打開,然後關閉。

-- Open the symmetric key with which to encrypt the data.
OPEN SYMMETRIC KEY SSN_Key_01
  DECRYPTION BY CERTIFICATE HumanResources037;

Q4:我應該擔心誰可以打開和關閉對稱密鑰嗎?我將 SQL Server 2008 用於 ASP.NET Web 應用程序。數據庫託管在 Windows Server 2008 VPS 上。我通常創建一個 SysAdmin 類型的數據庫使用者,並從 web.config 文件中提供連接詳細資訊。我將是唯一可以訪問 VPS 的人,因此我不需要考慮其他開發人員訪問數據庫。但是,如果 VPS/Windows 安全遭到破壞並且攻擊者獲得了對 VPS 和/或數據庫的訪問權限。他們會損害我的數據庫和資訊嗎?

Q1a:是否為每個數據庫實例創建主密鑰密碼?

A1a:假設問題的真正含義是“是否為每個數據庫創建了主密鑰?” “然後答案是肯定的。每個數據庫都有一個不同的主密鑰。還有一個叫做服務主密鑰的東西,它是每個 SQL Server 實例的。

Q1b:當我備份那個數據庫(.bak)時,我可以將數據庫恢復到另一個 Server2 嗎?

A1b:是的。恢復的數據庫中的主密鑰可以使用原始密碼打開。然後可以將 Server2 服務主密鑰加密添加到恢復的 DB 主密鑰中。

Q2:如果我想恢復到另一台伺服器,是否需要備份證書、主密鑰或對稱密鑰?

A2: 不會。所有這些對像都是數據庫的一部分,它們會隨數據庫一起恢復。備份單個密鑰的特定需求可能來自操作要求(例如密鑰託管)。

Q3:對稱密鑰應該什麼時候打開?

A3:需要打開的鑰匙必須在會話中打開。一旦打開,它們將保持打開狀態,直到顯式關閉或會話斷開連接。“打開”鍵僅在打開它的會話中“打開” 。

Q4:我應該擔心誰可以打開和關閉對稱密鑰嗎?…

A4:現在這是真正的問題。你真的有兩個選擇,它們對應於兩個不同的場景:

場景 A:當服務需要訪問加密數據而不要求使用者輸入數據密碼時。這是絕大多數情況。在這種情況下,服務需要以某種方式打開密鑰。解決方案是SQL Server使用服務主密鑰加密數據庫主密鑰,數據庫主密鑰用於加密證書的私鑰,私鑰用於加密對稱密鑰,對稱密鑰加密數據。SQL Server本身可以訪問此鏈之後的任何數據,因為它可以訪問服務主密鑰。在這種情況下,僅對數據進行加密保護以防止意外的媒體失去:帶有數據庫的失去的筆記型電腦,或帶有備份文件數據庫的未正確處置的硬碟等。對於所有其他威脅,數據不受加密保護,僅受訪問控制保護:因為 SQL Server 本身可以在不需要使用者密碼的情況下解密數據,任何具有足夠權限的使用者都可以在不知道密碼的情況下訪問數據。換言之,受感染的 ASP 應用程序可能允許訪問加密數據。需要注意的是,加密的根是儲存在 ASP Web 應用程序本身上的某個秘密的場景只是對此的(設計糟糕的)變體,不會改變任何東西

場景 B:當服務要求使用者提供密碼時。密碼必須來自最終使用者。在 Web 應用程序中,使用者必須在瀏覽器中的表單中輸入密碼,密碼通過 SSL 通道發送到 ASP 應用程序,後者將其傳遞給 SQL 會話(同樣在 SSL 通道上),SQL 現在可以解密數據使用此密碼。這種情況對於租戶提供數據訪問密碼的多租戶應用程序來說是典型的。在這種情況下,數據受到加密保護以防止未經授權的訪問,因為 SQL Server 本身和中間 ASP Web 應用程序根本不知道密碼。即使對於所有的 syadmin 使用者權限將不可能讀取數據。數據可以隨意移動,並且仍然是難以捉摸的,因為它只能由知道加密鏈根密碼的最終使用者讀取。請注意,在此場景中的任何“快捷方式”偏差,其中密碼在中間某個地方“保存”並且最終使用者未提供此場景會立即降級到第一個場景 A。

必讀:加密層次結構

引用自:https://dba.stackexchange.com/questions/7296