數(shù)據(jù)安全治理關(guān)鍵技術(shù)之?dāng)?shù)據(jù)庫脫敏技術(shù)詳解
數(shù)據(jù)安全治理之API監(jiān)測系統(tǒng) ,解決API接口安全問題【安華金和】
新一代數(shù)據(jù)庫脫敏技術(shù),為敏感數(shù)據(jù)建立保護(hù)盾!
數(shù)據(jù)庫脫敏系統(tǒng)與金融行業(yè)案例解讀
數(shù)據(jù)安全治理建設(shè)思路的著力點——數(shù)據(jù)安全咨詢服務(wù)【安華金和】
數(shù)據(jù)庫防火墻功能有哪些?-數(shù)據(jù)安全-安華金和
數(shù)據(jù)安全關(guān)鍵技術(shù)之?dāng)?shù)據(jù)庫脫敏技術(shù)詳解【安華金和】
中國數(shù)據(jù)安全治理落地指導(dǎo)書籍《數(shù)據(jù)安全治理白皮書5.0》正式發(fā)布(附下載)
目前,數(shù)據(jù)庫審計是數(shù)據(jù)庫安全市場中接受度最高的產(chǎn)品,但即使該產(chǎn)品幾乎是數(shù)據(jù)庫安全的首選,但真正用起來的概率并不樂觀,不少已經(jīng)淪為僵尸機(jī),更多時候只是為了應(yīng)付檢查,滿足合規(guī)。其最根本的風(fēng)險監(jiān)控預(yù)警能力根本沒有得到釋放。
怪用戶安全意識不強(qiáng)?當(dāng)然不完全是。我們經(jīng)手的不少審計項目并不是沒有數(shù)據(jù)庫審計系統(tǒng),而是原品牌替換,詢問原因常聽到這樣的回答:
產(chǎn)品不好用。該風(fēng)險告警的時候不報,正常操作卻沒完沒了的報,真要是天天開著,光是處理誤報就要耗費很大精力。
為什么會有這么多誤報?SQL語句解析是關(guān)鍵。
目前市面上的數(shù)據(jù)庫審計產(chǎn)品按照解析方式的不同主要有兩類,一類是基于語法語義進(jìn)行協(xié)議解析的審計技術(shù);一類是基于正則表達(dá)式匹配的審計技術(shù),大多數(shù)采用后者。而在實際測試中,后者的準(zhǔn)確率明顯低于前者。原理是什么?我們簡單分析:
基于語法語義的解析技術(shù)
這種解析技術(shù)采用的是“智能”理解的方式,不受限于SQL語句長度、復(fù)雜度等影響,能夠精確定義每一條SQL語句,準(zhǔn)確理解其真正的含義,從而實現(xiàn)精準(zhǔn)告警。
基于正則表達(dá)式的解析技術(shù)
正則表達(dá)式是一種“傻瓜式”的通用字符串匹配的方法,通常用于簡單的場景匹配指定字符。對于超長的、多層嵌套、多表關(guān)聯(lián)等復(fù)雜的SQL語句,使用正則表達(dá)式很容易造成誤識別或漏識別。
有點聽不懂?舉個栗子:
你希望的安全策略是:僅對b表插入數(shù)據(jù)的SQL操作定義為風(fēng)險。
語法語義解析的思路:語句操作關(guān)鍵字為insert into并且作用表對象為b。
正則表達(dá)式配置規(guī)則思路:語句中包含insert into、b等關(guān)鍵字。
這時候,數(shù)據(jù)庫接收到這樣一條訪問請求:
insert into a select * from b;
識別結(jié)果將會是這樣:
語法語義解析后:識別該語句將test b中的所有數(shù)據(jù)插入到a中,準(zhǔn)確判定為非風(fēng)險操作——不予告警
正則表達(dá)式匹配SQL后:發(fā)現(xiàn)該語句中包括insert into和b關(guān)鍵字,識別為風(fēng)險操作——進(jìn)行告警
除了SQL語句解析能力,通過在應(yīng)用系統(tǒng)中部署agent,可以準(zhǔn)確將應(yīng)用會話與數(shù)據(jù)庫會話做唯一的組合匹配,有了唯一的組合匹配即可實現(xiàn)百分百的信息關(guān)聯(lián)。而傳統(tǒng)數(shù)據(jù)庫審計通常是通過同時鏡像應(yīng)用前端的流量做通過時間戳的匹配關(guān)聯(lián),此種做法往往會在高壓、高并發(fā)的場景中造成“張冠李戴”的錯審現(xiàn)象。
審計產(chǎn)品如果連基本的準(zhǔn)確性都沒辦法保障,要它何用呢?僅從技術(shù)視角做兩種審計產(chǎn)品的對比科普,如何讓產(chǎn)品價值完美匹配用戶需求,請諸君巧思量。