基于PostgreSQL數(shù)據(jù)庫(kù)的幾種數(shù)據(jù)加密實(shí)現(xiàn)方法

摘要:采用加密技術(shù)是保護(hù)數(shù)據(jù)庫(kù)信息的一種較為有效的手段。在數(shù)據(jù)庫(kù)中對(duì)數(shù)據(jù)進(jìn)行加密保護(hù)，其加密機(jī)制主要涉及加密算法、加密粒度、密鑰生成和管理、查詢(xún)操作的實(shí)施以及對(duì)系統(tǒng)性能的影響等五個(gè)方面。該文針對(duì)加密粒度機(jī)制和對(duì)開(kāi)源的PostgreSQL數(shù)據(jù)庫(kù)研究的基礎(chǔ)上提出了幾種實(shí)現(xiàn)數(shù)據(jù)庫(kù)數(shù)據(jù)加密的加密方案，并基于實(shí)際相關(guān)數(shù)據(jù)庫(kù)安全平臺(tái)課題的研究簡(jiǎn)要分析了這幾種方法的優(yōu)點(diǎn)與不足，為未來(lái)實(shí)現(xiàn)完備的數(shù)據(jù)庫(kù)保護(hù)提供一些借鑒。

關(guān)鍵詞:數(shù)據(jù)庫(kù)加密;加密粒度;字段加密;PostgreSQL數(shù)據(jù)庫(kù)

中圖分類(lèi)號(hào):TP311文獻(xiàn)標(biāo)識(shí)碼:A文章編號(hào):1009-3044(2009)33-9130-02

Methods of Achieving Field-Encryption Based on PostgreSQL

LI Xin-jun， ZHANG Yan-jing

(Jiangnan Institute of Computing Technology， Wuxi 214083， China)

Abstract: Encryption technology to protect the database information is an effective means. In the database to protect data， the encryption mechanism mainly involves encryption algorithm， encryption granularity， key generation and management， the implementation of query operators as well as the impact of system performance in five aspects. In this paper， based on the study of encryption granularity and PostgreSQL open source database， several methods are ， and based on the actual issues related to database security platform for the study of this brief analysis of the merits of several methods and inadequate for the future to achieve a comprehensive protection database to provide some references.

Key words: database encryption; encryption granularity; field-encryption; PostgreSQL database

作為應(yīng)用最廣泛的信息存儲(chǔ)和處理系統(tǒng)，數(shù)據(jù)庫(kù)中存在大量敏感數(shù)據(jù)，如何防止數(shù)據(jù)被竊取和篡改是重中之重。加密技術(shù)是提高數(shù)據(jù)庫(kù)安全的一個(gè)重要手段，在對(duì)數(shù)據(jù)庫(kù)中存儲(chǔ)數(shù)據(jù)進(jìn)行加密時(shí)，需要結(jié)合它們的特點(diǎn)，對(duì)加密算法、加密粒度以及加密方式進(jìn)行合理選擇。比如，在選擇加密算法時(shí)，對(duì)加密尤其是解密速度要求比較快，不能因?yàn)榧?解密過(guò)程而導(dǎo)致系統(tǒng)性能大幅度下降。其次，應(yīng)當(dāng)支持靈活的加密粒度。根據(jù)用戶(hù)的需要，能夠選擇對(duì)數(shù)據(jù)庫(kù)、表、記錄、字段、數(shù)據(jù)項(xiàng)進(jìn)行加密。同時(shí)，還應(yīng)結(jié)合目前DBMS選擇適當(dāng)加密方式。

但不是什么加密方法和方式都是適合數(shù)據(jù)庫(kù)的，在加密數(shù)據(jù)的同時(shí)，也會(huì)帶來(lái)一些相關(guān)問(wèn)題，如果處理不好，不僅會(huì)降低數(shù)據(jù)庫(kù)的安全性，而且還會(huì)帶來(lái)其它如性能的影響。

本文簡(jiǎn)要介紹和分析了在一個(gè)基于開(kāi)源數(shù)據(jù)庫(kù)PostgreSQL的安全數(shù)據(jù)庫(kù)系統(tǒng)研究的基礎(chǔ)上，如何針對(duì)PostgreSQL數(shù)據(jù)庫(kù)的存儲(chǔ)數(shù)據(jù)的不同層次，對(duì)數(shù)據(jù)庫(kù)的文件(或表、頁(yè))、記錄、字段等多個(gè)層次實(shí)現(xiàn)了加密。

1 數(shù)據(jù)庫(kù)不同加密粒度實(shí)現(xiàn)

按照PostgreSQL數(shù)據(jù)庫(kù)的結(jié)構(gòu)層次，數(shù)據(jù)庫(kù)的加密粒度可以分為相應(yīng)的數(shù)據(jù)庫(kù)級(jí)、表級(jí)、記錄級(jí)、字段級(jí)和數(shù)據(jù)項(xiàng)級(jí)。根據(jù)不同的應(yīng)用需要，選擇合適的加密粒度。

1.1 對(duì)整個(gè)數(shù)據(jù)庫(kù)加密

加密整個(gè)數(shù)據(jù)庫(kù)，就是對(duì)數(shù)據(jù)庫(kù)中所有的系統(tǒng)表、數(shù)據(jù)表、索引、視圖和存儲(chǔ)過(guò)程等進(jìn)行加密處理。這種加密方法簡(jiǎn)單快捷，只需對(duì)相應(yīng)數(shù)據(jù)庫(kù)文件進(jìn)行加密處理即可，對(duì)于企業(yè)或者用戶(hù)簡(jiǎn)單的備份整個(gè)數(shù)據(jù)庫(kù)，可以采取這種操作方便加密粒度。但是，使用中的數(shù)據(jù)庫(kù)如果采用這種方法則會(huì)非常不合適，因?yàn)閿?shù)據(jù)庫(kù)中的數(shù)據(jù)共享性高，會(huì)同時(shí)被多個(gè)用戶(hù)和應(yīng)用訪(fǎng)問(wèn)使用，即使只需要查詢(xún)一條記錄，也需要對(duì)整個(gè)數(shù)據(jù)庫(kù)進(jìn)行解密，對(duì)系統(tǒng)性能會(huì)產(chǎn)生極大的影響。因此對(duì)此整個(gè)數(shù)據(jù)庫(kù)加密的方式我們不作過(guò)多的研究和討論。

1.2 數(shù)據(jù)庫(kù)的表級(jí)(頁(yè)面)加密

安全數(shù)據(jù)庫(kù)將表分成兩大類(lèi)，含加密字段的表和不含加密字段的表。對(duì)于加密的數(shù)據(jù)表則整個(gè)塊加密，否則不加密，且每塊使用一個(gè)密鑰。安全數(shù)據(jù)庫(kù)中，如果一個(gè)表中存放敏感數(shù)據(jù)，那么這個(gè)表的每一個(gè)頁(yè)面的數(shù)據(jù)域在內(nèi)存中是明文，在外存中是密文。

表級(jí)加密的對(duì)象是數(shù)據(jù)庫(kù)中的表。與數(shù)據(jù)庫(kù)級(jí)加密比較，采用表級(jí)加密粒度，系統(tǒng)的查詢(xún)性能會(huì)有所改善，因?yàn)閷?duì)于未加密表的查詢(xún)，與傳統(tǒng)查詢(xún)方法一樣，系統(tǒng)性能不會(huì)受到影響，對(duì)于加密表的查詢(xún)，只需要解密對(duì)應(yīng)的加密表，而不要解密整個(gè)數(shù)據(jù)庫(kù)。在實(shí)行表級(jí)加密時(shí)，可以采用對(duì)存儲(chǔ)數(shù)據(jù)的磁盤(pán)塊(頁(yè)面)進(jìn)行加密。這種方法與DBMS集成時(shí)，需要對(duì)DBMS內(nèi)部一些核心模塊進(jìn)行修改，包括對(duì)詞法分析器、解釋器和查詢(xún)執(zhí)行器的修改，這里我們對(duì)開(kāi)放源代碼的數(shù)據(jù)庫(kù)管理系統(tǒng)PostgreSQL的源碼進(jìn)行修改。

1.2.1 加解密數(shù)據(jù)結(jié)構(gòu)

加密函數(shù):

Char cipherpage(char *buffer，int size，BlockNumber blocknum， Relation reln);

解密函數(shù):

Char decipherpage(char *buffer，int size，BlockNumber blocknum， Relation reln);

輸入:

Buffer:加解密數(shù)據(jù)塊所在內(nèi)存緩沖區(qū);

Size:數(shù)據(jù)塊大小;

Blocknum:數(shù)據(jù)塊定位信息，需要寫(xiě)入或讀出的數(shù)據(jù)塊;

Reln:記錄數(shù)據(jù)庫(kù)名，數(shù)據(jù)庫(kù)關(guān)系表，數(shù)據(jù)空間的信息;

返回值:

加解密成功后，返回?cái)?shù)據(jù)塊所在的內(nèi)存緩沖區(qū)。

1.2.2 加解密流程的實(shí)現(xiàn)

當(dāng)DBMS將內(nèi)存中的頁(yè)面寫(xiě)出到外存中時(shí)，首先查詢(xún)安全字典，如果需要加密存儲(chǔ)，則用安全字典中當(dāng)前密鑰加密。在將數(shù)據(jù)從外存讀入內(nèi)存后，如果頁(yè)頭標(biāo)識(shí)頁(yè)面是加密過(guò)的(由函數(shù)iscryptic()進(jìn)行判斷)，則取出相應(yīng)的密鑰解密。加密時(shí)，只加密頁(yè)面中的數(shù)據(jù)域。這里也是由iscryptic()對(duì)進(jìn)行讀寫(xiě)的關(guān)系表進(jìn)行判斷是否需要加解密，來(lái)對(duì)當(dāng)前的數(shù)據(jù)塊進(jìn)行加密或解密。解密時(shí)，當(dāng)數(shù)據(jù)塊從外存讀入內(nèi)存時(shí)，如果頁(yè)頭標(biāo)識(shí)頁(yè)面是加密過(guò)的，則從安全字典中取出相應(yīng)的密鑰解密數(shù)據(jù)域。加解密的密鑰通過(guò)主密鑰和頁(yè)塊的ID計(jì)算得出。

我們跟蹤數(shù)據(jù)的寫(xiě)入和讀入流程，找到寫(xiě)入和讀出數(shù)據(jù)塊(block)的位置，對(duì)該數(shù)據(jù)塊進(jìn)行加解密。如圖1。

和對(duì)整個(gè)數(shù)據(jù)庫(kù)加密一樣，對(duì)數(shù)據(jù)庫(kù)進(jìn)行表級(jí)加密實(shí)現(xiàn)方法簡(jiǎn)單，但是加密的粒度較粗，一張表中會(huì)含有大量不需要加密的數(shù)據(jù)，這樣也會(huì)導(dǎo)致效率低下。

1.3 使用TOAST技術(shù)實(shí)現(xiàn)字段加密

使用TOAST技術(shù)，將加密的字段從原始的數(shù)據(jù)中分離出來(lái)，單獨(dú)存放。按照此種處理方案，同一個(gè)表中的明文密文存放在不同的文件或頁(yè)面中。

首先對(duì)TOAST (The Oversized-Attribute Storage Technique，超大尺寸字段存儲(chǔ)技術(shù))進(jìn)行一個(gè)簡(jiǎn)單的概述。

PostgreSQL 數(shù)據(jù)庫(kù)的頁(yè)面大小是固定的(通常是 8Kb)，并且不允許行跨越多個(gè)頁(yè)面，因此不可能直接存儲(chǔ)非常大的字段值。為了突破這個(gè)限制，大的字段值被壓縮和/或打碎成多個(gè)物理行。(這些事情對(duì)用戶(hù)都是透明的)。這個(gè)技術(shù)的昵稱(chēng)是 TOAST(\"切片面包之后最好的東西\")。TOAST 代碼只有在準(zhǔn)備向某表中存儲(chǔ)超過(guò) BLCKSZ/4 字節(jié)(通常是 2KB)的行的時(shí)候才會(huì)觸發(fā)。TOAST 代碼將在對(duì)應(yīng)于主表的TOAST表中壓縮和/或另存字段值，直到數(shù)值比 BLCKSZ/4 字節(jié)短，或者無(wú)法得到更好的結(jié)果的時(shí)候才停止。

1.3.1 字段加密的實(shí)現(xiàn)

借助于TOAST技術(shù)我們可以將TOAST 代碼的觸發(fā)時(shí)機(jī)移植到當(dāng)需要對(duì)某一數(shù)據(jù)庫(kù)表的字段進(jìn)行加密時(shí)。這樣主表中需要加密的字段中只是存儲(chǔ)實(shí)際已經(jīng)加密的字段數(shù)據(jù)所在位置的索引值，實(shí)現(xiàn)的關(guān)鍵技術(shù)就是學(xué)習(xí)TOAST技術(shù)，這是實(shí)現(xiàn)的難點(diǎn)。

需要加密字段的數(shù)據(jù)在這里不是被分裂成(壓縮后)固定字節(jié)的塊后被存儲(chǔ)到相應(yīng)的TOAST表中，而是每個(gè)被加密后的字段數(shù)據(jù)塊都作為獨(dú)立的行在TOAST表里為所屬主表存儲(chǔ)。每個(gè)TOAST 表都有chunk_id字段(一個(gè)表示特定TOAST值的OID)、chunk_seq(一個(gè)序列號(hào)，存儲(chǔ)該塊在數(shù)值中的位置)、chunk_data(該塊實(shí)際的數(shù)據(jù))。在chunk_id 和chunk_seq上有一個(gè)唯一索引，提供對(duì)數(shù)值的快速檢索。因此，一個(gè)表示線(xiàn)外 TOAST 值的指針數(shù)據(jù)需要存儲(chǔ)要查閱的 TOAST 的OID和特定數(shù)值的OID(它的chunk_id)。這樣在主表中依據(jù)這些標(biāo)識(shí)就可以順利找到被加密的字段，解密后即可使用。

TOAST 過(guò)的字段的大體積數(shù)值只是在把結(jié)果集發(fā)送給客戶(hù)端的時(shí)候才抽出來(lái)。因此，主表要小得多，并且它的大部分行都存儲(chǔ)在共享緩沖區(qū)里，因此就可以不需要任何線(xiàn)外存儲(chǔ)。排序集也縮小了，并且排序?qū)⒏嗟卦趦?nèi)存里完成。TOAST 表存儲(chǔ)將近一半大小的裸數(shù)據(jù)，而主表只包含全部數(shù)據(jù)的 10%，這與在一個(gè)非 TOAST 的表對(duì)比起來(lái)，沒(méi)有任何運(yùn)行時(shí)的區(qū)別。因此我們不必?fù)?dān)心TOAST帶來(lái)性能上的影響，如圖2所示。

與前面幾種數(shù)據(jù)庫(kù)加密方法不同，對(duì)數(shù)據(jù)庫(kù)進(jìn)行字段加密不需要對(duì)所有的數(shù)據(jù)進(jìn)行加密，加密的粒度更小，對(duì)于不需要訪(fǎng)問(wèn)到的記錄，完全不需要進(jìn)行任何操作，所以使用起來(lái)效率會(huì)高一些。但是由于每一個(gè)字段都必須有一個(gè)密鑰與之匹配，因此產(chǎn)生和管理記錄密鑰比較復(fù)雜。以記錄為單位的加密分析與以字段為單位的加密情況相似。這里就不再進(jìn)行敘述。

1.4 其他方式

在PostgreSQL數(shù)據(jù)庫(kù)中，所有的記錄都被構(gòu)造成一個(gè)TUPLE。在構(gòu)造的過(guò)程中，將加密列上的屬性進(jìn)行加密，保障內(nèi)存中的數(shù)據(jù)是加密的，當(dāng)一條記錄被引用時(shí)根據(jù)TUPLE中的標(biāo)識(shí)對(duì)其相應(yīng)的字段進(jìn)行解密，如圖3所示。

2 結(jié)束語(yǔ)

本文基于PostgreSQL數(shù)據(jù)庫(kù)自身特點(diǎn)簡(jiǎn)要討論了幾種 數(shù)據(jù)庫(kù)不同加密粒度式，用戶(hù)根據(jù)應(yīng)用場(chǎng)合的不同， 可分別選用以數(shù)據(jù)庫(kù)表、記錄、字段作為加密基本單位的方案。由于層次不同， 這三個(gè)方案的適用環(huán)境與實(shí)現(xiàn)難度各不相同。一般而言， 加密單位越小， 適用范圍越廣， 但實(shí)現(xiàn)時(shí)的困難也越大。而數(shù)據(jù)庫(kù)的安全性仍然不斷面臨新的安全技術(shù)挑戰(zhàn)，這有待我們?nèi)ミM(jìn)一步解決。

參考文獻(xiàn):

[1] 王正飛.數(shù)據(jù)庫(kù)加密技術(shù)及其應(yīng)用研究[D].復(fù)旦大學(xué)，2005.

[2] 曾凡號(hào).數(shù)據(jù)庫(kù)加密技術(shù)研究[J].軟件導(dǎo)刊，2006(9).

[3] 楊寅春，李麗萍，何守才.基于Oracle DBMS的數(shù)據(jù)庫(kù)系統(tǒng)安全加固模型[J].計(jì)算機(jī)科學(xué)，2005.

[4] 夏明.數(shù)據(jù)庫(kù)加密與驗(yàn)證的算法和實(shí)現(xiàn)機(jī)制研究[D].浙江工業(yè)大學(xué)，2005(12).