加脫密引擎

資料庫安全越來越成為使用各相關軟體的企業關心的重點，為了保證資料庫安全，資料庫加密系統越來越多的套用到各種資料庫系統中。在資料庫加密系統中有兩個功能獨立的主要部件：一個是加密字典管理程式，另一個是資料庫加脫密引擎。

加脫密引擎是資料庫加密系統的核心模組，它工作在後台，負責數據的加密和脫密，並且加脫密過程對於用戶是透明的。

基本介紹

• 中文名：加脫密引擎
• 外文名：Database Encryption Engine
• 領域：計算機
• 釋義：資料庫加密系統的核心模組
• 組成：加脫密處理模組、語法分析模組等
• 關鍵問題：加密的數據類型問題等

背景

在現有的許多信息系統中，資料庫因存放了大量重要的信息和數據而成為這些系統的核心部分，因而資料庫中數據的安全問題就成為十分重要的問題。以明文形式存放的數據，即使置於口令、防火牆和入侵檢測系統的保護之下，也是很容易被竊取、盜用和破壞的。另外，網際網路的普及，移動通信、筆記本電腦的廣泛使用也對資料庫安全構成了極大的威脅。所以，資料庫的安全問題己成為當前行業和企業用戶迫在眉睫的安全問題。

在現有的技術條件下，對資料庫保護的最有效方法是對敏感數據進行加密處理，將明文數據以密文方式保存，訪問時再進行解密操作。這樣即使能夠通過竊取、拷貝、截獲等非法途徑得到資料庫內的數據，沒有相應的密鑰，也得不到其明文形式。資料庫加密之後的密文數據由用戶用自己的用戶密鑰來進行訪問，不同的用戶只能訪問自己許可權以內的數據，這樣就大大提高了資料庫的安全性。要對資料庫中的數據和信息進行加密保護，就必須建立資料庫加密系統。

加脫密引擎系統結構

資料庫加/脫密引擎位於應用程式與資料庫伺服器之間，負責在後台完成資料庫信息的加、脫密處理，對套用開發人員和操作人員是透明的。資料庫加脫密引擎駐留在記憶體中，通過內部接口與加密字典管理程式和用戶應用程式通信，它沒有自己的用戶操作界面，在需要時由作業系統自動載入。 資料庫加/脫密引擎由三大模組組成：加脫密處理模組、語法分析模組、資料庫接口模組。其系統結構如圖1所示。

圖1 加脫密引擎系統結構圖

設計原理

客戶端客戶傳送對資料庫進行相關操作的請求命令，命令以sql語句形式傳送至加脫密引擎中，先經過語法分析模組進行語法分析，“語法分析模組”先對SQL命令進行詞法分析，分割成各個詞法單位，再輸入語法分析器，得到一棵語法樹。“語法分析模組”還包括語法樹反向生成SOL命令的功能函式，用於將經過加密變換的語法樹轉換成新的SQL命令。

圖2 加脫密引擎各模組及內外接口

資料庫加密系統中加脫密引擎各模組及內外接口如圖2所示。

語法分析模組

通常，“語法分析模組”只被“加脫密處理模組”調用，輸人參數是SQL命令，輸出參數是二叉樹形式的分析結果，語法分析並不需要能識別所有類型的SOL命令，可以不考慮那些與加脫密無關的SQL命令，遇到不認識的SQL命令，則返回空語法樹。

加脫密處理模組

“加脫密處理模組”是資料庫加脫密引擎的核心模組，模組首先將加密系統配置檔案中數據讀出對引擎進行初始化，並將信息存放在記憶體中，這些配置包括客戶端與伺服器間傳輸的數據包大小，加密字典cache刷新問隔等。加密字典存放資料庫中的加密配置信息，最近訪問的加密字典信息存放在加密字典緩衝區記憶體中。處理模組首先判斷客戶端命令是否是引擎內部命令，若是，則在引擎內部處理；若是要求資料庫命令，則根據命令檢索加密字典，若sql命令中的數據項在加密字典信息中，則需要對sql命令中的相關信息進行相應的加脫密處理，若sql命令中的數據項不在加密字典信息中，則直接調用數據接口模組對資料庫進行相應操作。

對sql語句進行加脫密變換包括包括：將select語句from從句中明表名替換為密表名；向select語句增加行標記列；將here語句、order by語句中的明表名替換為密表名；節點明文數值變換為密文數值等。其中節點值變換包括：插入新的記錄中包含加密列；更新加密列的值；更新語句或刪除語句的where字句包含加密列。

資料庫接口模組

資料庫接口模組包括：前端資料庫客戶訪問資料庫加脫密引擎的接口函式；資料庫加脫密引擎訪問後台資料庫伺服器的接口函式。客戶端套用開發工具或套用訪問資料庫，首先要建立伺服器的連線，客戶端API為之提供一組接口函式，最終建立的一條邏輯鏈路，稱之為SQLLink。用戶訪問資料庫加脫密引擎的入口點是“資料庫接口模組”，用戶通過SQLLink及SQL命令等參數調用“資料庫接口模組”提供的用戶接口函式，對於不同的資料庫套用編程接口，用戶接口函式的定義是不同的。“資料庫接口模組”的主要工作是接受用戶的操作請求，並傳遞給“加脫密處理模組”，此外還要代替“加脫密處理模組”去訪問資料庫伺服器，在這些過程中，需要完成外部資料庫接口參數與資料庫加脫密引擎內部數據結構之間的轉換。

實現資料庫加脫密引擎的關鍵問題

加密的基本單位問題

資料庫系統由於具有檔案(表)、記錄、欄位等多個層次的概念，所以對資料庫信息的加密也就可以分別選用以檔案、記錄、欄位作為加密基木單位的方案。根據套用時具體要求的不同，實現時應採用不同的方法。

（1）基於檔案的資料庫加密技術。

把資料庫檔案作為整體，用加密算法對整個資料庫檔案加密來保證信息的真實性和完整性。利用這種方法，數據的共享是通過用戶用解密密鑰對整個資料庫檔案進行解密來實現的。但多方面的缺點極大地限制了這一方法的實際套用：首先，數據修改的工作將變得十分困難，需要進行解密、修改、複製和加密4個操作，極大地增加了系統的時空開銷;其次，即使用戶只是需要查看某一條記錄，也必須將整個資料庫檔案解密，這樣無法實現對檔案中不需要讓用戶知道的信息的控制。因此，這種方法只適用於能迴避這些限制的套用環境。

（2）基於記錄的資料庫加密技術。

一般而言，資料庫系統中每條記錄所包含的信息具有一定的封閉性，即在某種程度上說它獨立完整地存儲了一個實體的數據。因此，基於記錄的加密技術是最常用的資料庫信息加密手段。這種方法的基木思路是：在各自密鑰的作用下，將資料庫的每一個記錄加密成密文並存放於資料庫檔案中；記錄的查找是通過將需查找的值加密成密碼文後進行的。然而基於記錄的資料庫保護有一個缺點，就是在解密一個記錄的數據時，無法實現對在這個記錄中不需要的欄位不解密;在選擇某個欄位的某些記錄時，如果不對這個含有這個欄位的所有記錄進行解密就無法進行選擇。

（3）基於欄位的資料庫加密技術。

基於欄位的資料庫加密，就是以不同記錄的不同欄位為基木加密單元進行加密。該方法可以對資料庫中單個數據元素進行加密。其優點在於具有最小的加密粒度，具有更好的靈活性和適應性，缺點在於：(1)加解密效率低；(2)若用資料庫密鑰對單個數據元素重複加密，對於密文搜尋攻擊是脆弱的；(3)若各欄位的數據元素分別用不同的密鑰加密，則密鑰個數=記錄個數x欄位個數，其量是非常驚人的，根本無法管理。

加密的數據類型問題

數據類型是設計加脫密引擎時要考慮的一個關鍵問題。不同的資料庫其包含的數據類型也是不一樣的，MS SQL Server包包含的數據類型有21種，而Oracle的數據類型有16種之多(見圖3)。這么多的數據類型單獨進行處理顯然不太現實。

圖3

密文的存放問題

數據加密以後，加密後的數據有兩種存儲方式：一種是存儲到原表數據存放的位置，另一種是另外建立一張密文表，將加密的數據存入其中。

第一種存儲方式從理論上講，是一種較好的存儲方式，因為其不會增加附加的存儲空間，但從實踐上來看，它不具有可操作性。舉一個簡單的例子，在SQL Server中，對一個integer類型的數據加密，假如用的是64位DES算法，integer數據類型數據的大小為4個位元組共32位，用DES加密時，該類型的數據會通過添0的方法擴充為64位，加密後也為64位即8個位元組，8個位元組的密文顯然不能存入原來只能存4個位元組數據的存儲空間。那能不能先把該欄位的類型更改為二進制類型並使存儲空間為8個位元組呢?兩個原因使這種做法不可行。一是變更數據類型會造成數據丟失；二是一般的資料庫都不支持對非全空的欄位進行欄位數據類型轉換。