1 引言
隨著電子商務和電子政務的迅速發展，網絡中的數據呈爆炸式增長，數據規模越來越大，涉及的技術越來越復雜。2002 年，Hakan Hacigumus 首次提出了“databases as a service”，即“外包數據庫的概念”。在外包數據庫系統中，組織將數據業務外包給專門的數據庫服務器，由它們去完成數據的存儲和管理等復雜技術工作，而數據庫用戶通過網絡從外包數據庫中獲得服務。在這種運行模式中，數據存儲在非可信的第三方服務器中，最大的問題就是如何保證數據的安全性，特別是如何防止內部人員（如：數據庫管理員）泄露、丟失、甚至破壞數據。傳統的一些安全機制，如操作系統安全機制、訪問控制機制由服務器端操作，在外包數據庫這種模式中不能完全保障其安全性。而利用加密技術來保護數據的安全性是一種非常理想的選擇，即使入侵者可以利用操作系統漏洞或者繞過訪問控制機制非法竊取數據文件，但是沒有密鑰進行解密，所獲取的信息是不可讀的。
2 相關工作
一些工作人員對數據庫加密進行了研究。文獻[5]提出了一種同態加密方法。同態加密的思想是加密后的數據仍然保持原明文數據的有序性，從而可以實現不用解密數據而對加密數據直接進行訪問和算術運算。然而，從安全性角度來看，這種加密方法本身具有其固有的缺陷，因為它要求密文數據仍然保持有序性，這與安全的加密算法是相悖的。文獻[6]中，在數據庫作為一種服務（Database As a Service）的背景下，提出了對加密數據查詢的方法。存儲時，除了對關系表中的元組加密外，還增加一個索引字段，用來存儲加密字段的分桶號（Bucket ID），桶號表示明文數據值落在某段區間內。查詢時，客戶端提交的SQL查詢語句可以直接執行在加密數據上，而無須解密，但查詢結果中包含不滿足調節的元組，需要解密進行二次查詢。文獻[7]進一步對它如何分桶進行改進，給出最優分桶算法，使得查詢代價最少。但是，這種方法對于多表連接查詢的代價非常大。文獻[8]提出了一種保持有序的加密方法。給定一個目標分布函數，對明文值進行轉換得到密文，使得密文不僅保持有序，而且服從某一目標函數的分布。由于其密文保持有序，無須解密就可以直接對密文進行等值和范圍查詢，也可以進行MAX、MIN、COUNT 和ORDER BY查詢。但這種方法由于密文保持有序性，容易遭受選擇密文攻擊。也就是說，如果攻擊者能夠選擇一定數量的明文（或密文），并且把它們加密（或解密）成對應的密文（或明文），那么他就能夠以較大的概率估計出密文對應的明文值。類似地，如果攻擊者知道這個域的一些信息，比如說該域的數據分布，他也能夠以較大的概率估計密文對應的明文值。文獻[9]中，智能卡具有加密和查詢處理能力，它把數據加密后存儲在服務器中，密鑰也存儲在智能卡中。查詢時，智能卡能夠對等值查詢語句進行轉換，使之能夠對密文數據進行查詢。但是，它不能對實數類數據進行范圍查詢。文獻[10]中使用序列加密（stream cipher）方法對文本數據進行加密處理，這樣可以無須解密而直接對加密文本搜索關鍵詞，但是這種方法沒有涉及到如何應用到數據庫中。文獻[11]和[12]對數據庫中字符型數據的加密以及加密數據的快速查詢進行了研究。
3 數據加密的體系結構
數據庫加密，大致可以分為兩種方式：DBMS 外部加密和DBMS 內部加密。DBMS 外部加密，一般選擇在應用程序和操作系統，通過調用加/解密函數來完成加密數據的存儲和訪問。例如，在操作系統層次實現加密時，可以利用它管理文件系統的功能，直接對存儲數據的文件進行加密。在操作系統中加密時，加密的粒度是基于文件，對應到數據庫中的表或者整個數據庫，這種加密粒度是非常粗糙，最直接的影響是，加/解密的工作相當大，極大地降低系統性能。DBMS 內部加密，一般選擇在數據物理存取之前進行加/解密操作。也就是說，DBMS 在將內存中的數據寫到磁盤時，進行加密操作，而從磁盤讀取數據到內存中時，進行相應的解密操作。BMS 能夠區分各種粒度的數據，所以可以支持各種粒度的加密，加密的靈活性較好。另外，在DBMS 內部實現加密，可以更有效地和DBMS 內部的訪問控制機制、授權機制等各種功能結合起來。此外，數據庫中的數據具有高度結構化，共享性高等特點，在對數據庫中存儲數據進行加密時，需要結合它們的特點，對加密算法、加密粒度以及加密方式進行合理選擇。首先，在選擇加密算法時，對加密尤其是解密速度要求比較快，不能因為加/解密過程而導致系統性能大幅度下降。其次，應當支持靈活的加密粒度。根據用戶的需要，能夠選擇對數據庫、表、記錄、字段、數據項進行加密。同時，還應結合目前DBMS 選擇適當加密方式。
在設計數據加密的體系結構時，采用基于DBMS 內核層加密方法，加密的粒度為表級，如圖1 所示。其中系統表和加解密組件是新增的。設計思想是：用戶在創建表的時候，可以指定是否對其加密存儲，如果需要加密，則在系統表的安全字典中插入一條相應的記錄。在DBMS 將數據寫到磁盤上時，查詢系統表的安全字典，如果需要加密，則首先對數據加密，再將其寫出到外存。當DBMS 從磁盤中讀入數據塊時，如果數據塊是加密過的，則加/解密模塊查詢安全字典，取出相應的密鑰解密數據塊。
圖1 數據庫加密體系結構圖
4 加密實現
依據上面數據庫加密體系結構，在PostgreSQL 中實現了基于塊的表級存儲數據加密。PostgreSQL是以加州大學伯克利分校開發的POSTGRES 版本4.2 為基礎的對象關系型數據庫管理系統（ORDBMS），被廣泛地認為是目前特性最齊全的開放源碼數據庫管理系統。數據加密時，使用了GOST 算法，GOST 是一種分組對稱加密算法，來自于對DES 的改進，它采用64 位分組和256 位密鑰。
4.1 系統內核頁面的結構
系統內核中的每一個頁（page）對應外存上的一個塊（block）。默認情況下，他們的大小是8K，最大可以為32K。每個頁面分為頁頭信息（PageHeaderData）、頁中存儲的具體數據以及頁尾中關于頁面類型的頁面特定信息（Special-Space）三部分，具體結構如圖2 所示。
圖2 頁面結構圖
PageHeaderData 存放每一頁都必有的公共信息，即頁面空間管理信息，對于每種類型的頁面都是定長的，主要包含如下幾個字段：
（1）pd_pagesize_version，兩個字節，高8 位指示頁面大小，低8 位指示當前版本號；
（2）pd_lower，指出頁內當前可用空間的起始偏移；
（3）pd_upper，指出頁內當前可用空間的終止偏移；
（4）pd_special，指出頁內關于頁面類型的特定信息起始偏移。因為對于不同類型的頁面，SpecialSpace 的大小及存放數據內容是不一樣的。
比如，B 樹索引的頁面與heap 關系的頁面，其SpecialSpace 是不同的，B 樹索引頁面比heap 關系多了指向其左右兄弟頁面及父頁面的指針。
在頁頭信息和pd_lower 之間是一個數組，它的每一個元素Linp 存放了一條記錄在頁面中的起始偏移。數組中元素的個數也就是頁面中存放記錄的條數。在pd_upper和pd_special之間的Item是關系中的記錄，它們是從后向前存放的。系統支持變長字段，所以記錄不是定長的。
4.2 加解密流程
進行加解密的基本思想是：在DBMS 將內存中的頁面寫出到外存中時，首先查詢安全字典，如果需要加密存儲，則用安全字典中當前密鑰加密。在將數據從外存讀入內存后，如果頁頭標識頁面是加密過的，則取出相應的密鑰解密。
加密時，只加密頁面中的數據域。因為加密算法通常是分組加密，所以要處理加密數據長度不是分組長度整數倍的情況。假設采用加密算法是64 位分組，如果數據域不是64 的整數倍，則采用雙向加密技術。雙向加密技術的思想是，對數據域中的數據，從前往后加密，如果最后一組數據長度小于分組長度，取前面的加密數據進行填充。例如，在圖2 中，按照順序加密數據域itemN，item（N－1），…，如果最后一項item1長度不夠，取前面已經加密數據進行填充后再加密。加密后，在頁頭的pd_pagesize_version 域使用兩個比特來設置加密標識，目前其低8 位只用了最低1 位來標識版本號，文中使用其中的高2 位來標識當前頁面已加密及使用的密鑰的編號，00－未加密，01－使用密鑰1 加密，10－使用密鑰2 加密。
解密時，當數據塊從外存讀入內存時，如果頁頭標識頁面是加密過的，則從安全字典中取出相應的密鑰解密數據域。由于可能存在中間部分被加密兩次的情況，應該先解密最后一組數據，然后從前向后順序地解密。
4.3 安全字典
為了支持數據庫加密，在系統表中增加了一個安全字典。它由兩個表組成，一個是加密關系表，另一個是用戶授權表。圖3 和圖4 分別是加密關系表和用戶授權表中記錄的結構。
圖3 加密關系表中記錄的結構
圖4 用戶授權表中記錄的結構
其中，在加密關系表中，DID和RID分別是數據庫ID和關系ID，它們作為主鍵來唯一標識一條記錄。Etag 標識關系表是否需要加密存儲（1－加密，0－不需加密）。CurID、Key1、Key2、UpdtTime、UpdtTag 分別是當前使用密鑰編號、密鑰1、密鑰2、上次密鑰更新日期以及更新是否完成標識（1－完成，0－未完成），之所以有兩個密鑰，主要是用于密鑰的更新，在后面的密鑰管理中介紹。
在用戶授權表中，UID、DID、RID作為主鍵來唯一標識一條記錄。UID是用戶ID，DID和RID分別是數據庫ID和關系ID，是指向加密關系表的外鍵，ValidTag 指示當前記錄是否有效（1－有效，0－無效），StartTime 和EndTime 表示用戶訪問加密關系權限的起始及截止日期。
同時，增設了系統安全管理員（SSA），使用專門的接口來管理和維護安全字典。他通過在用戶授權表中添加記錄來授予某些用戶訪問機密數據的權限，也可以調整密鑰的更新周期，還負責用戶UID的發放和管理。數據庫管理員（DBA）負責常規的數據庫維護，用戶自主訪問控制（DAC）的授權等，但DBA 沒有權限訪問加密過的數據，也不能訪問安全字典，這樣就避免了DBA 仿冒用戶來竊取和篡改數據庫中的敏感數據。圖5 是在增加安全字典后用戶訪問數據庫的流程。
圖5 加密數據庫的訪問流程圖
具體的訪問過程如下：
（1）用戶首先使用DBA分配的用戶名和密碼登錄系統；
（2）訪問控制模塊對用戶名與密碼進行鑒別，如果正確，DBMS 與用戶建立連接；
（3）用戶提交查詢語句；
（4）訪問控制模塊首先檢測用戶是否有權限訪問語句中指定的關系（由DBA授權），驗證通過后，執行查詢；
（5）查詢執行器從外存中讀取關系數據塊；
（6）如果數據塊是未加密過的（由頁頭判斷）則直接將數據傳給查詢執行器，并轉到（9），如果讀出的數據塊是加密過的，則調用安全控制模塊進行安全權限驗證；
（7）安全控制模塊獲取用戶的密鑰ID（可以是磁卡、指紋及口令，只要唯一標識該用戶，這個ID是系統安全員（SSA）授予的），查詢安全字典以獲取解密密鑰。查詢安全字典的步驟如下：
①首先查詢用戶授權表，依次進行如下驗證：是否存在主鍵為（密鑰ID，當前數據庫ID，當前訪問關系ID）的記錄；記錄是否有效；當前時間是否在起始與終止有效期之間。只有全為真時，用戶才有權限訪問加密關系；
②根據（當前數據庫ID，當前訪問關系ID）以及頁頭的加密密鑰編號從加密關系表中取出密鑰；
（8）使用密鑰解密數據，并將解密后的明文傳給查詢執行器；
（9）查詢執行器執行查詢，將查詢結果返回給用戶。
4.4 SQL的擴展
要實現對數據庫加密，需要擴展ANSI SQL92 標準的數據定義語言DDL。主要在兩個方面擴展：一是關系的創建語句；另一個是關系結構的修改語句。
在創建新關系時，可以指明是否對此關系中的數據加密存儲，擴展后的語法為：
CREATE TABLE 關系名（屬性名類型，… ，完整性約束，… [，ENCRY]）
對于已經創建的關系，可以修改關系中的數據是否加密存儲，擴展后的語法為：
ALTER TABLE 關系名WITH ENCRY [NOW] | WITHOUTENCRY
當用戶創建一個關系時，如果指出這個關系中的數據需要加密存儲（即帶有ENCRY項），那么密鑰產生器就會自動產生一個密鑰，并在安全字典的加密關系表中插入如下一條記錄：（數據庫ID，新創建關系ID，1，新產生密鑰，0，當前系統時間，1，0，默認密鑰有效期）
將ETag 設為1 表示關系需要加密存儲，并且當前活動密鑰是密鑰1。因為還沒用到密鑰2，將Key2 置0。將UpdtTag設為1 表示已完成密鑰的更新。
在關系已經創建后，關系所有者和系統安全員（SSA）可以修改加密選項。如果將加密改為不再加密，即使用選項WITHOUT ENCRY，只需在加密關系表中將相應記錄的ETag字段設為0，指示出關系不再需要加密存儲，并不用對整個關系進行解密操作。用戶以后訪問這個關系時，如果從外存讀入的數據塊是加密過的，則系統自動從安全字典的加密關系表中取出相應的加密密鑰解密。在將其寫回到外存上時，先將頁頭的是否加密標識設為未加密，再明文寫回。也就是說，在用戶對原加密存儲的關系訪問的過程中完成了關系數據由密文存儲到明文存儲的轉變。
在將以前未加密存儲的關系修改為需要加密存儲時，即使用選項WITH ENCRY，那么同新創建一個關系且指定加密時一樣，在安全字典的加密關系表中插入如下一條記錄：（數據庫ID，被修改關系ID，1，新產生密鑰，0，當前系統時間，0，0，默認密鑰有效期）
同新創建一個關系且指定加密存儲時的區別是，將更新是否完成標識UpdtTag 設置為0，指示當前更新未完成。因為在修改是否加密項的時候，關系中可能已有數據，而且通常不是DBMS 負荷較低的時候，為了避免影響系統的性能，沒有立即將數據轉為加密存儲的形式。通過這一設定，把關系由非加密存儲到加密存儲的轉變交給密鑰更新程序去完成。在系統低負荷時自動運行的密鑰更新程序會自動完成關系的加密存儲。
5 實驗
實驗的主要目的是評估數據庫加密后對DBMS 性能的影響。根據TPC-H標準，利用dbgen 工具自動生成數據庫，數據庫的大小為200M。實驗使用機器的配置是PVI 2.0 GHzCPU，512 MB內存，操作系統是Red Hat Linux 9，PostgreSQL的版本是7.4.2。數據庫的操作語句如圖6 所示。其中，插入操作是在customer 表中批量插入30 000 條記錄；刪除操作是將國家代碼在12 到15 之間的客戶記錄刪除；更新操作是將累積金額在5 500 到6 000 之間的記錄累積金額加50 000；查詢操作是查詢訂單總價在10 000 到10 050 之間訂單的訂單號、客戶名字及所在國家，涉及三個表的聯接操作。
圖6 測試用例
對于每一種操作分別測試在四種環境下的平均運行時間，這四種環境分別是：
（1）關系中的數據未加密存儲，并且未對關系中的字段建立索引；
（2）關系中的數據加密存儲，但未對關系中的字段建立索引；
（3）關系中的數據未加密存儲，但對關系中的字段建立索引；
（4）關系中的數據加密存儲，并且對關系中的字段建立索引。
圖7 給出了數據庫操作在四種測試環境下的運行時間比較。
從圖7 可知，在批量插入30 000 條記錄的時候，關系加密存儲和未加密存儲在無索引和有索引的情況下性能分別降低了2%和7%；在做刪除操作時，關系加密存儲和未加密存儲在無索引和有索引的情況下性能分別降低了23%和32%；在做更新操作時，關系加密存儲和未加密存儲在無索引和有索引的情況下性能分別降低了31%和36%；在做查詢操作時，關系加密存儲和未加密存儲在無索引和有索引的情況下性能分別降低了26%和18%，為了保障敏感數據的安全，這樣的代價是可以接受的。
在有索引的情形下刪除與查詢的速度比無索引的情形下快了許多。這是因為可以利用索引來定位記錄所在的塊，大大減少了I/O 次數。從圖中可以看出，即使在關系加密存儲（索引亦加密存儲）的情況下，使用索引也比關系明文存儲但沒有使用索引的情形也快了8 倍多。這充分說明采用的方案不會影響DBMS 索引建立功能所帶來的好處。由于傳統的數據加密方式會影響到索引的建立，如果沒有索引，這些加密方式性能最好的情形也只能是與關系未加密且不使用索引的情形相同。
圖7 數據庫加密的性能測試
6 總結
加密技術是外包數據庫安全中的一種重要機制，提出了基于DBMS 內核加密的一種方法，通過安全字典和SQL 的擴展，實現了數據的加密存儲和有效查詢，并在開源的postgresql中對查詢性能進行了測試，驗證該方法的有效性和可行性。以后將針對數據加密粒度、多表連接、多條件查詢進行進一步的研究。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：外包數據庫中數據加密的設計和實現
相關文章
