在保密你的服務器和數據，防備當前復雜的攻擊，SQL Server有你需要的一切。但在你能有效使用這些安全功能前，你需要理解你面對的威脅和一些基本的安全概念。這篇文章提供了基礎，因此你可以對SQL Server裡的安全功能充分利用，不用在面對特定威脅，不能保護你數據的功能上浪費時間。
從讓人眼花缭亂的客戶端使用連接，通過到處分布的網絡，尤其是互聯網，關系數據庫在各種應用程序裡廣泛使用。這使數據對任何人，在任何地方都可訪問。數據庫可以保存人類知識的很大部分，包括高度敏感的個人信息和讓國際商務工作的關鍵數據。
對於想要偷取數據或通過篡改數據來傷害數據的擁有者的 人來說，這些功能使數據庫成為有吸引力的目標。確保你的數據安全是SQL Server配置和使用它來保存數據的程序的重要部分。這個系列會探尋SQL Server 2012安全的基本，這樣的話你可以保護你的數據和服務器資源，按你需要的安全等級來保護數據，免受這些威脅對你數據的影響。大部分信息對SQL Server的早期版本也適用，回到SQL Server 2005也可以，因為那是微軟在產品裡徹底檢查安全的時候。但我也會談論只在SQL Server 2012和後續版本裡才有的功能。
如果攻擊者能拿到包含數據庫的磁盤文件的訪問，即使做好防護的數據還是容易受到攻擊。單元格級別的加密可以保護部分數據，但應付這列攻擊的完整保護是必須加密文件而不是數據。這就是透明數據加密（Transparent Data Encryption (TDE)）要做的，在這篇文章裡你會學到TDE做什麼，如何工作，還有如何使用它來保護你的數據庫文件。
在SQL Server 2008，微軟引入了透明數據加密（Transparent Data Encryption (TDE)）。TDE可以在文件層對數據和日志文件進行實時加密和解密。不需要特定的編程，盡管有支持的T-SQL管理TDE，在這篇文章裡稍後你就會看到。這讓TDE很容易配置和維護，盡管當的復制和移動數據庫到不同位置和SQL Server實例時需要更多工作。
TDE在寫入數據庫就加密數據，然後在讀取的時候解密數據，一旦你在數據庫啟用TDE就會自動處理。TDE的目的是在數據庫和日志裡，保護休息時的數據庫，保持它的安全，遠離直接從文件直接訪問數據的攻擊者。有個特定的場景對此非常有用，當你需要通過一夜包裹投遞服務來運輸你的數據庫文件，例如FedEx或UPS。沒有TDE，攻擊者可以從運輸卡車後面偷取你的包裹，附加數據庫到他有sysadmin權限的SQL Server實例，拿到數據訪問。但如果在數據庫上啟用了TDE，整個數據被安全加密了；沒有密匙的話，就不能訪問到數據。其它TDE也很有用的場景是擔心例如內部的攻擊者，可以用任何方式獲得物理文件的訪問，或者你需要保持歸檔數據庫副本的安全。
TDE需要證書來訪問物理數據庫文件。沒有證書來加密數據庫，數據只是無法使用的，加密的一堆胡言亂語。這就是說不能在數據庫附近的任何地方放置證書的備份，這個非常重要——例如在用來運輸數據庫文件的同個FedEx包裹裡！不然的話，攻擊者有他想要的一切東西。他需要做的只是在他控制的SQL Server實例上安全證書，用它來附加數據庫，給她解密數據的完全訪問。
TDE加密所有寫入數據庫的數據，理解這個非常重要。然後它解密需要的數據來響應查詢。因此只有當數據在休息的時候，存儲在數據庫裡，它才受TDE保護。TDE在讀寫數據的時候會在8K的頁裡加密或解密數據。
如果SQL Server實例的任何數據庫，即使幾十個中的一個數據庫附加到實例，受TDE保護的，那麼SQL Server自動用TDE保護tempdb。即使受TDE保護的數據庫不使用tempdb。這樣做是有道理的，因為從受保護的一些數據會自動存儲在tempdb。數據會在休息——即使很短的時間——因此完整保護tempdb同樣需要使用TDE保護。這樣會帶來性能上的問題。所有的數據在tempdb裡加密保存，在實例裡所有的其它未受TDE保護的數據庫，有任何數據存儲在tempdb的話也會被加密。因此這些數據庫的性能也會受到影響。
要配置TDE，你需要有創建數據庫主密匙，在mater數據裡創建一個證書，在用戶數據庫上有CONTROL許可來啟用TDE。大多數時間，sysadmin可以在數據庫上啟用TDE，因此需要的許可不是問題。
為了高效使用TDE，你應該理解TDE做什麼和它有什麼好和不好的地方。考慮下TDE的這些限制：
如你所見，這些限制沒有TDE作什麼用的限制多，這表示它不能作為安全的靈丹妙藥那麼有用。但是如果對你數據的威脅對應於它提供的保護，TDE會是重要的安全功能。
但你看TDE時，有一個你要考慮的問題是性能。考慮到需要的處理周期，加密是個昂貴的操作。TDE表現還是相當不錯的，因為TDE不在SQL 緩存裡加密數據。只有當它寫入磁盤時才加密數據。因此如果它不在緩存的話，每次你訪問數據的時候也不需要加密，這提高了全局的效率。在數據庫裡，微軟花了大量的時間讓加密盡可能的高效。但當數據被讀寫時，還是會帶來一定的性能問題，因為加密要用到復雜的算法。
現在我們通過實例來演示下你如何使用TDE，還有它在數據庫上的作用。下列代碼顯示了備份AdventureWorks2012數據庫，然後還原了一個新的數據庫AdventureWorks2012Copy。你可以按照自己的實際情況修改文件路徑，例如文件備份路徑，C:\Data文件夾用來備份證書。
-- *** Beginning of setup code ***
-- *******************************
-- Make a copy of AdventureWorks2012 database
-- Change the path to the appropriate backup directory
BACKUP DATABASE AdventureWorks2012
TO DISK = N'D:\SQLBackups\AdventureWorks2012.bak'
WITH NOFORMAT, INIT, NAME = N'AdventureWorks2012 Full Database Backup',
SKIP, NOREWIND, NOUNLOAD, STATS = 10;
GO
RESTORE DATABASE AdventureWorks2012Copy
FROM DISK = N'D:\SQLBackups\AdventureWorks2012.bak'
WITH
FILE = 1, NOUNLOAD, REPLACE, STATS = 10,
MOVE 'AdventureWorks2012_Data' TO N'D:\SQLData\AdventureWorks2012Copy.mdf',
MOVE 'AdventureWorks2012_Log' TO N'D:\SQLData\AdventureWorks2012Copy.ldf';
GO
-- *** End of setup code ***
-- *************************
一旦你進行了下列配置步驟，代碼進行了4個步驟為數據庫啟用TDE：
代碼9.1展示了在master數據庫裡創建證書需要的代碼，在數據庫裡它用來保護數據庫加密密匙。它創建數據庫主密匙，使用強密碼保護它，然後創建AdventureWorks2012TDECert證書。作為預防，代碼然後備份證書到D:\Data目錄。你應該在穩妥可靠的地方存儲它，在你移動受TDE保護的數據庫的時候就可以用到它。
USE master;
GO
-- TDE hooks into encryption key hierarchy in SQL Server
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '!drJP9QXC&Vi%cs';
GO
-- Create the certificate used to protect the database encryption key
CREATE CERTIFICATE AdventureWorks2012TDECert WITH SUBJECT = 'Certificate to implement TDE on AdventureWorks2012Copy';
GO
-- Backup the certificate
-- Either create the C:\Data folder or change it in the code below
BACKUP CERTIFICATE AdventureWorks2012TDECert TO FILE = 'D:\Data\AdventureWorks2012TDECert'
WITH PRIVATE KEY ( FILE = 'D:\Data\AdventureWorks2012TDECertPrivateKey' ,
ENCRYPTION BY PASSWORD = 'RISiS9Ul%CByEk6' );
GO
代碼9.1：創建並備份用來保護TDE數據庫的證書
在進一步使用TDE之前，運行代碼9.2，這個列出的代碼在SQL Server的當前實例裡加密數據庫，連同它們的加密狀態，如果有的話。在新的，剛安裝的SQL Server，這應該返回一個空的結果。接下來，在實施TDE後，你會看到狀態如何改變。
SELECT DB_NAME(database_id) AS DatabaseName,
key_algorithm AS [Algorithm],
key_length AS KeyLength,
CASE encryption_state
WHEN 0 THEN 'No database encryption key present, no encryption'
WHEN 1 THEN 'Unencrypted'
WHEN 2 THEN 'Encryption in progress'
WHEN 3 THEN 'Encrypted'
WHEN 4 THEN 'Key change in progress'
WHEN 5 THEN 'Decryption in progress'
END AS EncryptionStateDesc,
percent_complete AS PercentComplete
FROM sys.dm_database_encryption_keys;
GO
代碼9.2 在SQL Server實例裡列出加密數據庫的狀態
現在是時候對AdventureWorks2012Copy數據庫啟用TDE。執行代碼9.3，它開始使用你剛才在master數據庫裡創建的證書創建數據庫加密密匙。你會收到一條警告信息：如果你還沒備份證書的話，請備份；請留意這個建議！然後代碼使用SET ENCRYPTION ON子句的ALTER DATABASE語句為數據庫啟用TDE。取決於與數據庫的大小和服務器的速度，完全加密數據庫需要一些時間，可能幾個小時或幾天。
USE AdventureWorks2012Copy;
GO
-- Create the database encryption key for TDE. Analogous to database master key for data encryption.
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = TRIPLE_DES_3KEY
ENCRYPTION BY SERVER CERTIFICATE AdventureWorks2012TDECert;
GO
-- Get a warning about backing up the key, if you haven't already
-- ...take the advice and back it up!
-- Now need to turn TDE on.
ALTER DATABASE AdventureWorks2012Copy SET ENCRYPTION ON;
代碼9.3：創建數據庫加密密匙並啟用TDE
當在加密數據庫的時候，可以反復執行代碼9.2來跟蹤下進度。你會看到如插圖9.1的結果，我在截屏的時候，已經100%完成了。注意插圖顯示了2個數據庫：現在在實例裡至少有一個數據庫使用TDE，tempdb也會自動加密。一旦初始化加密完成，所有的數據庫PercentComplete列會顯示為0（是的，這個數字有點誤導，因為當它完成的時候不是100%這樣的顯示）。
插圖9.1：使用sys.dm_database_encryption_keys來監控數據庫加密進度的結果
注意在圖中AdventureWorks2012Copy數據庫使用了Triple DES加密算法。那是我們在代碼9.1裡指定的算法，你可以用SQL Server支持的任何加密算法選項。還有tempdb默認也使用256位AES加密算法。
通過執行對數據庫的查詢測試加密，如代碼9.4所示。在打開TDE之前，只要你有必要的許可訪問數據庫，你就能訪問數據。這對任何應用程序的數據訪問也是如此。
SELECT TOP 500 * FROM Production.Product;
代碼9.4：在啟用TDE後測試數據庫訪問的樣本代碼。
如果你想為數據庫關閉TDE，你可以使用代碼9.5：
ALTER DATABASE AdventureWorks2012Copy
SET ENCRYPTION OFF;
GO
代碼9.5：為數據庫停用TDE
測試下安全功能確保它如你預計的正常工作總是明智的。樣本代碼包含測試TDE的一些步驟，包括你不小心刪除用來為TDE保護數據庫加密密匙的證書。代碼9.5備份AdventureWorks2012Copy數據庫，刪除AdventureWorks2012TDECert證書，模擬丟失證書。（這也模擬了當你附加加密數據庫到不同的SQL Server實例，它上面並沒有安裝原始的證書。）
BACKUP DATABASE AdventureWorks2012Copy
TO DISK = N'D:\SQLBackups\AdventureWorks2012Copy.bak'
WITH NOFORMAT, INIT, NAME = N'AdventureWorks2012Copy Full Database Backup',
SKIP, NOREWIND, NOUNLOAD, STATS = 10;
GO
USE master
GO
DROP DATABASE AdventureWorks2012Copy;
GO
-- Oops! We lost the certificate and don't have a copy!
-- Or, going to restore the database to another server instance
DROP CERTIFICATE AdventureWorks2012TDECert;
GO
代碼9.6：備份數據庫，刪除數據庫，扔掉了證書
接下來，嘗試使用代碼9.7還原數據庫，你會收到如插圖9.2的錯誤信息。這是TDE在起作用的保護：如果數據庫實例沒有安裝原始加密證書，是不可能還原或附加數據庫的。
RESTORE DATABASE AdventureWorks2012Copy
FROM DISK = N'D:\SQLBackups\AdventureWorks2012Copy.bak'
WITH
FILE = 1, NOUNLOAD, REPLACE, STATS = 10;
代碼9.7：嘗試還原受TDE保護的數據庫
插圖9.2：嘗試在沒有安裝保護證書的數據庫上還原數據庫
但如果你備份了證書，並沒有丟失全部！使用代碼9.8從備份文件裡還原證書，使用文件裡剛才用來保護證書的密碼，然後嘗試還原數據庫。這次完全可用的數據庫——還是用TDE保護——已經成功還原。
-- Recover from the problem
-- Restore the certificate
CREATE CERTIFICATE AdventureWorks2012TDECert
FROM FILE = 'D:\DATA\AdventureWorks2012TDECert'
WITH PRIVATE KEY ( FILE = 'D:\DATA\AdventureWorks2012TDECertPrivateKey',
DECRYPTION BY PASSWORD = 'RISiS9Ul%CByEk6');
-- Now try to restore the database
RESTORE DATABASE AdventureWorks2012Copy
FROM DISK = N'D:\SQLBackups\AdventureWorks2012Copy.bak'
WITH
FILE = 1, NOUNLOAD, REPLACE, STATS = 10;
代碼9.8：從備份文件還原刪除的證書，然後再次嘗試還原數據庫
通過在這篇和上一篇文章，你應該能很好的理解SQL Server提供的兩種主要加密方式，還有什麼時候使用它們。總結下與在列級別數據庫加密的主要不同：
通常，你會想為小量數據使用列級別數據加密來保護大多數敏感信息，在服務器上節約處理周期。
這引出了一個問題：在SQL Server 2008和後續版本應該使用哪個加密方式？關鍵是要理解你要保護面對的威脅，但實施任何安全功能時，這個是關鍵。
如果威脅是竊取、數據庫和日志文件的濫用，使用透明數據加密（Transparent Data Encryption）。TDE會阻止附加數據庫到另一個SQL Server實例和獲得數據訪問。
如果威脅是在你服務器上的入侵數據，列級別加密沒准是更好的選擇。當黑客在數據庫服務器上拿到訪問後，正確實施的列級別數據加密可以阻止數據訪問。
如果你兩者之間不能選擇，你可能需要同時面對兩種威脅。幸運的是，2個可以結合使用，各個會阻止它特定的威脅。
透明數據加密（Transparent Data Encryption）進行數據和日志文件的實時加密和解密。這個會在數據庫和日志裡加密所有數據，阻止攻擊著從另一個SQL Server實例附加數據庫，獲得數據訪問。如果你需要防范的威脅是數據文件的濫用，TDE可以提供強的數據保護，不需要架構和程序改變。使用得當的話，它可以為整體深度防御，提供強大的安全層。
http://www.sqlservercentral.com/articles/Stairway+Series/125948/
