使用Oracle的TDE特性加密

使用作為Oracle高級安全選件（版本 10.2 及更高版本）的一部分引入的Oracle數據庫透明數據加密(TDE)，可以有選擇地對保留在數據庫底層數據文件中的敏感數據庫數據以及所有下游文件組件（如聯機重做日志、歸檔重做日志和數據庫備份）進行加密。TDE 的基本目標是保護在這些原始操作系統文件中發現的敏感數據，防止不懷好意的人訪問磁盤或備份磁帶時對這些數據進行窺探，然後嘗試還原數據庫或掃描原始操作系統文件中的數據，如個人可識別信息或信用卡信息。

作為我的咨詢慣例的一部分，我已經實施 TDE 多次。但是，在其中一個最近的合約之前，我一直使用 TDE 對現有表中的新列或屬於全新表的列進行加密。在這兩種情況下使用 TDE 非常簡單，因為目標列為空，因此由於缺乏數據和現有應用程序相關性而不會涉及較大的風險。

我最近實施 TDE 的體驗有所不同。我幫助一家大型公司對一個已超過一百萬行的表中的現有列進行加密。還有一個依賴於列的關鍵任務應用程序，因此，您可以設想一下，在開始工作之前有很多重要的事情要考慮。在 Internet 上搜索可提供經驗的類似情形之後，我發現只有幾個優秀的資源可以幫助我。

本文概述了我在通過使用 TDE 對現有數據進行加密的過程中總結出的經驗教訓。如果您嘗試對現有列數據使用 TDE，我希望此處提供的信息可幫助您迅速有效地開展類似工作。

確定可能的限制

研究客戶的系統時，我做的第一件事情就是查找與目標列有關的將禁止我們對列加密的數據模型特征，或者查找可能對現有操作產生負面影響的有關列的事項。該研究包括查找列索引和完整性約束。

正如Oracle文檔明確聲明，當您想對具有索引的某個列進行加密時，需要了解很多限制條件。Oracle 不允許對具有位圖索引的列進行加密，這與我們的情況沒有密切關系。但是，目標列具有多個普通的（B 樹）索引。盡管Oracle允許對具有普通索引的列進行加密，但是Oracle禁止對索引列進行“salt 處理”加密。Salt 處理通過在加密之前向數據添加隨機字符串來提高重復數據的安全性，因此竊賊使用模式匹配識別技術更加難於破解加密的數據。總而言之，經過這個最初的分析之後，我們會遇到一種情況，那就是我們可以對列進行加密，但不能進行 salt 處理。

對列索引進行分析後，我本可以到此為止，但是我想回答的下一個問題是“使用這些索引合適嗎？”我的思考過程是這樣：如果索引沒有用，那麼我會將其刪除，從而減少維護索引條目所必需的系統開銷，尤其是考慮到加密的額外負擔。要判斷索引是否有用，我使用Oracle數據庫的索引監視特性。我發現，實際上索引正處於使用當中，因此我們必須對其繼續進行維護。

接下來，我查看了引用完整性約束條件中是否涉及目標列。由於每個表都具有其自己的加密密鑰，因此Oracle不允許您使用 TDE 對外鍵關系中涉及的列進行加密。在我們的情況下，引用完整性約束條件中未涉及目標列。