建站
咨詢
售后
建站咨詢
新聞中心
“xxx拖庫”、“xxxx數(shù)據(jù)泄露”等等層出不窮的安全事件表明，要想根本上解決這種越過網(wǎng)絡防護，繞開權(quán)控體系，直接復制文件塊并異地還原解析的“內(nèi)鬼”式攻擊方式，必須采用存儲層的加密技術(shù)，確保敏感信息一旦落盤，必須密文存儲。隨著數(shù)據(jù)庫加密技術(shù)在國內(nèi)市場的興起，更多數(shù)據(jù)安全企業(yè)的涌入，市面上出現(xiàn)了幾種具有代表性的數(shù)據(jù)庫加密技術(shù)。
一、前置代理及加密網(wǎng)關(guān)技術(shù)
1. 技術(shù)原理
該方案的總體技術(shù)思路即在數(shù)據(jù)庫之前增加一道安全代理服務，對數(shù)據(jù)庫訪問的用戶都必須經(jīng)過該安全代理服務，在此服務中實現(xiàn)如數(shù)據(jù)加解密、存取控制等安全策略。然后安全代理服務通過數(shù)據(jù)庫的訪問接口實現(xiàn)數(shù)據(jù)存儲。安全代理服務存在于客戶端應用與數(shù)據(jù)庫存儲引擎之間，負責完成數(shù)據(jù)的加解密工作，加密數(shù)據(jù)存儲在安全代理服務中。
2. 利弊分析：前置代理及代理網(wǎng)關(guān)加密技術(shù)，邁不過去的“坎”
- 由于在安全增強代理中需要存儲加密數(shù)據(jù)，因此要解決與數(shù)據(jù)庫存儲數(shù)據(jù)的一致性問題，這基本不可實現(xiàn)。
- 數(shù)據(jù)的聯(lián)合檢索問題：由于在數(shù)據(jù)庫內(nèi)外都存在數(shù)據(jù)，這些數(shù)據(jù)的聯(lián)合檢索將變得很困難;SQL語法的完全兼容也非常困難。
- 開發(fā)無法透明問題：數(shù)據(jù)庫協(xié)議雖然存在標準，但事實上每個不同的數(shù)據(jù)庫版本都會進行若干變更、擴展和增強，使用了這些特性的用戶必須進行改造。同時在安全代理中對數(shù)據(jù)庫通訊協(xié)議的模擬非常困難。
- 數(shù)據(jù)庫的優(yōu)化處理、事務處理、并發(fā)處理等特性都無法使用：查詢分析、優(yōu)化處理、事務處理、并發(fā)處理工作都需要在安全增強器中完成，無法使用數(shù)據(jù)庫在并發(fā)處理和查詢優(yōu)化上的優(yōu)勢，系統(tǒng)的性能和穩(wěn)定性更多地依賴于安全代理;
- 對于對存儲過程、觸發(fā)器、函數(shù)等存儲程序的實現(xiàn)支持也非常困難。
另外此種方案需要在安全代理服務層提供非常復雜的數(shù)據(jù)庫管理功能，如：SQL命令解析，通訊服務，加密數(shù)據(jù)索引存儲管理、事務管理等等，因此存在巨大的開發(fā)工作量及很高的技術(shù)復雜度，此外還有類似于存儲過程、觸發(fā)器等無法解決的技術(shù)問題。
二、應用層改造加密技術(shù)
1. 技術(shù)原理
應用層加密方案的主要技術(shù)原理是應用系統(tǒng)通過加密API(JDBC,ODBC,CAPI等)對敏感數(shù)據(jù)進行加密，將加密數(shù)據(jù)存儲到數(shù)據(jù)庫的底層文件中;在進行數(shù)據(jù)檢索時，將密文數(shù)據(jù)取回到客戶端，再進行解密，應用系統(tǒng)自行管理密鑰體系。
2. 利弊分析：應用層加密技術(shù)，只是看起來很美
最主要不足在于：應用程序必須對數(shù)據(jù)進行加解密，增加編程復雜度，而且無法對現(xiàn)有系統(tǒng)做到透明，應用程序必須進行大規(guī)模改造。這種技術(shù)無法利用數(shù)據(jù)庫的索引機制，加密后數(shù)據(jù)的檢索性能大幅下降。
三、基于文件級的加解密技術(shù)
1. 技術(shù)原理
顧名思義，基于文件級的加解密技術(shù)是不與數(shù)據(jù)庫自身原理融合，只是對數(shù)據(jù)存儲的載體從操作系統(tǒng)或文件系統(tǒng)層面進行加解密的技術(shù)手段。
這種技術(shù)通過在操作系統(tǒng)中植入具有一定入侵性的“鉤子”進程，在數(shù)據(jù)存儲文件被打開的時候進行解密動作，在數(shù)據(jù)落地的時候執(zhí)行加密動作，具備基礎(chǔ)加解密能力的同時，能夠根據(jù)操作系統(tǒng)用戶或者訪問文件的進程ID進行基本的訪問權(quán)限控制。
2. 利弊分析：跳出“體系”之外，優(yōu)勢與風險同在
這種技術(shù)巧妙的繞過了讓各路英雄頭疼的問題。對數(shù)據(jù)庫高端特性兼容、查詢檢索性能保障、統(tǒng)計分析效率等關(guān)鍵技術(shù)指標均有較好的適應情況。
然而在這種機制下，存在的問題也會比較明顯，包含以下幾類:
- 操作系統(tǒng)或文件系統(tǒng)級加解密，對不同平臺適應性較差，而且與內(nèi)核綁定過重，一旦出現(xiàn)程序故障，會對操作系統(tǒng)造成較大影響，容易導致業(yè)務中斷。
- 操作系統(tǒng)或文件級加解密的權(quán)控在系統(tǒng)層，因此無法單獨完成對不同數(shù)據(jù)庫賬號的訪問權(quán)限的設置，需要和其他產(chǎn)品與技術(shù)進行組合。
- 操作系統(tǒng)或文件級的加解密針對落地文件進行操作，加解密粒度比較粗糙，無法針對列級進行加密。
四、基于視圖及觸發(fā)器的后置代理技術(shù)
1. 技術(shù)原理
這種技術(shù)是使用“視圖”+“觸發(fā)器”+“擴展索引”+“外部調(diào)用”的方式實現(xiàn)數(shù)據(jù)加密，同時保證應用完全透明。核心思想是充分利用數(shù)據(jù)庫自身提供的應用定制擴展能力，分別使用其觸發(fā)器擴展能力、索引擴展能力、自定義函數(shù)擴展能力以及視圖等技術(shù)來滿足數(shù)據(jù)存儲加密，加密后數(shù)據(jù)檢索，對應用無縫透明等核心需求。
2. 利弊分析：后置代理，獨自過獨木橋
以傳統(tǒng)的列加密DBCoffer為代表的后置代理加密技術(shù)，經(jīng)過幾年演進逐步被大家接受，這種技術(shù)擁有前置代理和應用改造所不具備的透明性，靈活性以及數(shù)據(jù)庫高端技術(shù)的兼容性，可謂率先走過了數(shù)據(jù)庫加密這一風險與挑戰(zhàn)都巨大的“獨木橋”。然而向前看，“獨木橋”還在。
“應用環(huán)境下，單表億級數(shù)據(jù)規(guī)模，加密后查詢檢索性能會不會受到明顯影響?”“對密文數(shù)據(jù)的統(tǒng)計分析操作，如何保證速度基本不下降?”“實施加密后，對密文數(shù)據(jù)的運維、遷移、備份等操作，如何將改動降至最低”“大量的數(shù)據(jù)加密，會否帶來更大量的空間膨脹”……這些自數(shù)據(jù)庫加密技術(shù)問世以來就相伴而生的問題，不僅變成了用戶心頭的疑云，也成為了后置代理加密技術(shù)提供商亟待解決的當務之急。
網(wǎng)站標題：四種常見數(shù)據(jù)庫加密技術(shù)分析
網(wǎng)址分享：http://www.dlmjj.cn/article/djhophh.html
