[科普中國]-加脫密引擎

在現(xiàn)有的許多信息系統(tǒng)中，數(shù)據(jù)庫因存放了大量重要的信息和數(shù)據(jù)而成為這些系統(tǒng)的核心部分，因而數(shù)據(jù)庫中數(shù)據(jù)的安全問題就成為十分重要的問題。以明文形式存放的數(shù)據(jù)，即使置于口令、防火墻和入侵檢測系統(tǒng)的保護之下，也是很容易被竊取、盜用和破壞的。另外，互聯(lián)網(wǎng)的普及，移動通信、筆記本電腦的廣泛使用也對數(shù)據(jù)庫安全構(gòu)成了極大的威脅。所以，數(shù)據(jù)庫的安全問題己成為當前行業(yè)和企業(yè)用戶迫在眉睫的安全問題。

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

數(shù)據(jù)庫加/脫密引擎位于應(yīng)用程序與數(shù)據(jù)庫服務(wù)器之間，負責在后臺完成數(shù)據(jù)庫信息的加、脫密處理，對應(yīng)用開發(fā)人員和操作人員是透明的。數(shù)據(jù)庫加脫密引擎駐留在內(nèi)存中，通過內(nèi)部接口與加密字典管理程序和用戶應(yīng)用程序通信，它沒有自己的用戶操作界面，在需要時由操作系統(tǒng)自動加載。 數(shù)據(jù)庫加/脫密引擎由三大模塊組成：加脫密處理模塊、語法分析模塊、數(shù)據(jù)庫接口模塊。其系統(tǒng)結(jié)構(gòu)如圖1所示。3

客戶端客戶發(fā)送對數(shù)據(jù)庫進行相關(guān)操作的請求命令，命令以sql語句形式發(fā)送至加脫密引擎中，先經(jīng)過語法分析模塊進行語法分析，“語法分析模塊”先對SQL命令進行詞法分析，分割成各個詞法單位，再輸入語法分析器，得到一棵語法樹?！罢Z法分析模塊”還包括語法樹反向生成SOL命令的功能函數(shù)，用于將經(jīng)過加密變換的語法樹轉(zhuǎn)換成新的SQL命令。

數(shù)據(jù)庫加密系統(tǒng)中加脫密引擎各模塊及內(nèi)外接口如圖2所示。

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

“加脫密處理模塊”是數(shù)據(jù)庫加脫密引擎的核心模塊，模塊首先將加密系統(tǒng)配置文件中數(shù)據(jù)讀出對引擎進行初始化，并將信息存放在內(nèi)存中，這些配置包括客戶端與服務(wù)器間傳輸?shù)臄?shù)據(jù)包大小，加密字典cache刷新問隔等。加密字典存放數(shù)據(jù)庫中的加密配置信息，最近訪問的加密字典信息存放在加密字典緩沖區(qū)內(nèi)存中。處理模塊首先判斷客戶端命令是否是引擎內(nèi)部命令，若是，則在引擎內(nèi)部處理；若是要求數(shù)據(jù)庫命令，則根據(jù)命令檢索加密字典，若sql命令中的數(shù)據(jù)項在加密字典信息中，則需要對sql命令中的相關(guān)信息進行相應(yīng)的加脫密處理，若sql命令中的數(shù)據(jù)項不在加密字典信息中，則直接調(diào)用數(shù)據(jù)接口模塊對數(shù)據(jù)庫進行相應(yīng)操作。

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

數(shù)據(jù)庫接口模塊包括：前端數(shù)據(jù)庫客戶訪問數(shù)據(jù)庫加脫密引擎的接口函數(shù)；數(shù)據(jù)庫加脫密引擎訪問后臺數(shù)據(jù)庫服務(wù)器的接口函數(shù)?？蛻舳藨?yīng)用開發(fā)工具或應(yīng)用訪問數(shù)據(jù)庫，首先要建立服務(wù)器的連接，客戶端API為之提供一組接口函數(shù)，最終建立的一條邏輯鏈路，稱之為SQLLink。用戶訪問數(shù)據(jù)庫加脫密引擎的入口點是“數(shù)據(jù)庫接口模塊”，用戶通過SQLLink及SQL命令等參數(shù)調(diào)用“數(shù)據(jù)庫接口模塊”提供的用戶接口函數(shù)，對于不同的數(shù)據(jù)庫應(yīng)用編程接口，用戶接口函數(shù)的定義是不同的?！皵?shù)據(jù)庫接口模塊”的主要工作是接受用戶的操作請求，并傳遞給“加脫密處理模塊”，此外還要代替“加脫密處理模塊”去訪問數(shù)據(jù)庫服務(wù)器，在這些過程中，需要完成外部數(shù)據(jù)庫接口參數(shù)與數(shù)據(jù)庫加脫密引擎內(nèi)部數(shù)據(jù)結(jié)構(gòu)之間的轉(zhuǎn)換。3

數(shù)據(jù)庫系統(tǒng)由于具有文件(表)、記錄、字段等多個層次的概念，所以對數(shù)據(jù)庫信息的加密也就可以分別選用以文件、記錄、字段作為加密基木單位的方案。根據(jù)應(yīng)用時具體要求的不同，實現(xiàn)時應(yīng)采用不同的方法。

（1）基于文件的數(shù)據(jù)庫加密技術(shù)。

把數(shù)據(jù)庫文件作為整體，用加密算法對整個數(shù)據(jù)庫文件加密來保證信息的真實性和完整性。利用這種方法，數(shù)據(jù)的共享是通過用戶用解密密鑰對整個數(shù)據(jù)庫文件進行解密來實現(xiàn)的。但多方面的缺點極大地限制了這一方法的實際應(yīng)用：首先，數(shù)據(jù)修改的工作將變得十分困難，需要進行解密、修改、復制和加密4個操作，極大地增加了系統(tǒng)的時空開銷;其次，即使用戶只是需要查看某一條記錄，也必須將整個數(shù)據(jù)庫文件解密，這樣無法實現(xiàn)對文件中不需要讓用戶知道的信息的控制。因此，這種方法只適用于能回避這些限制的應(yīng)用環(huán)境。

（2）基于記錄的數(shù)據(jù)庫加密技術(shù)。

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

（3）基于字段的數(shù)據(jù)庫加密技術(shù)。

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

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

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

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