Oracle透明資料加密(TDE)真實環境流量分析，oracletde

Oracle透明資料加密(TDE)真實環境流量分析，oracletde

　　從Oracle資料庫1Og的R2版本開始，一個叫做透明資料加密(TDE)的特性讓資料加密變得極其容易。我們所需要做的就是把某列聲明成加密的，剩下的全部由Oracle完成。當使用者輸入資料時，列值會被截獲、加密，然後用加密後的格式儲存。然後，當這一列被查詢時，又會自動對列值進行解密，然後把解密後的文本（明文）返回給使用者。使用者甚至都不需要知道發生過加密和解密——也就是所謂的透明。全部都是由Oracle代碼內部完成，不需要任何觸發器或者複雜的過程邏輯。

下面是一個使用TDE的例子：

要想把表ACCOUNTS中的SSN列聲明成加密的，只需這樣聲明：

ALTER TABLE accounts MODIFY  (ssn ENCRYPT  USING  'AES256')

　　Oracle資料庫馬上就會用AES演算法以及一個256位的金鑰組SSN -列進行加密。密鑰被儲存在資料字典表中，不過為了防止被竊，這個密鑰還會用一個主要金鑰加密，這個主要金鑰儲存在一個單獨的叫做錢包的位置。這個錢包，預設時，位於$ORACLE_BASE/admin/$ORACLE- SID/wallet。不過我們也可以在SQLNET.ORA檔案中指定一個不同的位置。

當使用者用下面語句插入資料時：

 INSERT INTO accounts (ssn) VALUES (’123456789’)

真實的值是以加密格式放在資料檔案、重做日誌以及歸檔日誌中的，因此也會在備份檔案中。當一個使用者以後查詢這個資料時，加密的值會自動被解密，顯示的還是最初的值。上述語句執行之前，必須要先由DBA或者安全性系統管理員開啟這個錢包。

　　TDE的目的只有一個：用最小的代價加密敏感性資料，避免可能的對資料檔案的盜竊帶來的破壞。不過，注意，強調的重點是透明——也就是說，加密是自動進行的，解密也一樣。在資料庫中。Oracle不會區分使用者。當一個使用者查詢資料庫時，Oracle不管這個驗證使用者到底是誰，都會給他明文值。

TDE也有一些限制：

　　一方面，不能對外鍵列使用TDE，對於許多公司專屬應用程式來說這確實是一個限制。另一方面，對於使用了TDE的列我們只能建立b樹索引。不過，如果我們是用PL/SQL實現我們自己的加密過程，這些限制就無所謂了。在判斷TDE是否能夠符合我們的目標時，自動化是我們必須要考慮的另一個方面。對於TDE來說，錢包（主要金鑰儲存在這裡）必須要由DBA通過類似於下面的命令開啟：

ALTER SYSTEM SET ENCRYPTION WALLET OPEN AUTHENTICATED BY "pooh"

餞包的密碼是“pooh”。如果資料庫資料檔案（或者重做記錄檔、或者這些檔案的備份檔案）被偷了，由於小偷不知道密碼“pool"加密列的內容還是加密的，有了這個密碼他才能開啟錢包。每次資料庫啟動之後，錢包都必須要由DBA顯式地開啟，然後才能用於插入或者訪問過程的加密。如果錢包沒有開啟，對這些列的插入以及訪問就會失敗。因此，這也是在資料庫開啟之後需要執行的額外一步操作。另外，我們必須要保證負責開啟資料庫的人知道錢包的密碼。
　　為了讓這一步更加容易和更加自動化，我們一般都會考慮建立一個資料庫啟動觸發器，在其中調用ALTER SYSTEM命令（前面顯示的）開啟錢包。不過，如果你這麼做，這個啟動觸發器就會去掉對於錢包的唯一保護，接著，就是加密的列。因此，如果我們使用TDE，我們永遠都不能使用這樣的啟動觸發器，我們必須準備好每次資料庫啟動之後再執行額外的一步操作。不過，如果我們構建我們自己的加密基礎設施，那麼只要資料庫啟動它就可用，就不需要額外的步驟，也沒有錢包密碼需要記憶和輸入。
　　總的來說。TDE的功能有限。它提供了一個對資料檔案、重做日誌、備份檔案進行加密的快速容易方法。不過，它沒有根據使用者的不同保護資料；它的解密是基於訪問的。如果我們需要對解密過程有更多的控制能力，我們就需要依賴我們自己的加密基礎設施。

　　在許多情況下，我們還是需要構造一個更複雜的系統，在這個系統中，只有當發出請求的使用者確實被授權閱讀這些資料時，解密後的明文才會顯示給他，如果不是這樣，返回的就是加密的值。使用TDE是不可能滿足這個需求的，因為TDE會不分青紅皂白地對一切資料解密。不過，我們可以構建一個自己的架構實現這個目的。