目前，數(shù)據(jù)庫審計是數(shù)據(jù)庫安全市場中接受度最高的產(chǎn)品，但即使該產(chǎn)品幾乎是數(shù)據(jù)庫安全的首選，但真正用起來的概率并不樂觀，不少已經(jīng)淪為僵尸機，更多時候只是為了應(yīng)付檢查，滿足合規(guī)。其最根本的風(fēng)險監(jiān)控預(yù)警能力根本沒有得到釋放。

怪用戶安全意識不強？當(dāng)然不完全是。我們經(jīng)手的不少審計項目并不是沒有數(shù)據(jù)庫審計系統(tǒng)，而是原品牌替換，詢問原因常聽到這樣的回答：

產(chǎn)品不好用。該風(fēng)險告警的時候不報，正常操作卻沒完沒了的報，真要是天天開著，光是處理誤報就要耗費很大精力。

為什么會有這么多誤報？SQL語句解析是關(guān)鍵。

目前市面上的數(shù)據(jù)庫審計產(chǎn)品按照解析方式的不同主要有兩類，一類是基于語法語義進行協(xié)議解析的審計技術(shù)；一類是基于正則表達式匹配的審計技術(shù)，大多數(shù)采用后者。而在實際測試中，后者的準(zhǔn)確率明顯低于前者。原理是什么？我們簡單分析：

基于語法語義的解析技術(shù)

這種解析技術(shù)采用的是“智能”理解的方式，不受限于SQL語句長度、復(fù)雜度等影響，能夠精確定義每一條SQL語句，準(zhǔn)確理解其真正的含義，從而實現(xiàn)精準(zhǔn)告警。

基于正則表達式的解析技術(shù)

正則表達式是一種“傻瓜式”的通用字符串匹配的方法，通常用于簡單的場景匹配指定字符。對于超長的、多層嵌套、多表關(guān)聯(lián)等復(fù)雜的SQL語句，使用正則表達式很容易造成誤識別或漏識別。

有點聽不懂？舉個栗子：

你希望的安全策略是：僅對b表插入數(shù)據(jù)的SQL操作定義為風(fēng)險。

語法語義解析的思路：語句操作關(guān)鍵字為insert into并且作用表對象為b。

正則表達式配置規(guī)則思路：語句中包含insert into、b等關(guān)鍵字。

這時候，數(shù)據(jù)庫接收到這樣一條訪問請求：

insert into a select * from b;

識別結(jié)果將會是這樣：

語法語義解析后：識別該語句將test b中的所有數(shù)據(jù)插入到a中，準(zhǔn)確判定為非風(fēng)險操作——不予告警

正則表達式匹配SQL后：發(fā)現(xiàn)該語句中包括insert into和b關(guān)鍵字，識別為風(fēng)險操作——進行告警

除了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)品價值完美匹配用戶需求，請諸君巧思量。