數(shù)據(jù)庫安全審計(jì)常見8種缺陷

?2016數(shù)據(jù)庫安全審計(jì)常見8種缺陷作者安華金和劉曉韜隨著信息化的發(fā)展，數(shù)據(jù)庫安全問題成為當(dāng)前政府和企事業(yè)單位用戶關(guān)注的焦點(diǎn)，數(shù)據(jù)庫審計(jì)產(chǎn)品已經(jīng)成為當(dāng)前信息安全產(chǎn)品的盛寵。當(dāng)前在市面上存在著幾十種數(shù)據(jù)庫審計(jì)產(chǎn)品，這些產(chǎn)品集中起來大約可分四種類型：在網(wǎng)絡(luò)審計(jì)產(chǎn)品的基礎(chǔ)上經(jīng)過簡(jiǎn)單包裝推出數(shù)據(jù)庫審計(jì)產(chǎn)品的既有網(wǎng)絡(luò)審計(jì)產(chǎn)品廠商，比如國(guó)內(nèi)幾大安全廠商推出的數(shù)據(jù)庫審計(jì)產(chǎn)品，安全圈都知道，不再例舉；針對(duì)數(shù)據(jù)庫通訊協(xié)議的特點(diǎn)開發(fā)出專門的數(shù)據(jù)庫審計(jì)產(chǎn)品的國(guó)內(nèi)細(xì)分領(lǐng)域安全廠商，比如安華金和、思福迪、國(guó)都興業(yè)、帕拉迪等；國(guó)外的數(shù)據(jù)庫審計(jì)產(chǎn)品，比如Imperva、Guardium等；OEM第三方的數(shù)據(jù)庫審計(jì)產(chǎn)品，OEM對(duì)象可能來自國(guó)內(nèi)，也可能來自國(guó)外，比如Imperva或韓國(guó)的DBInsight。隨著國(guó)產(chǎn)化采購政策的推動(dòng)，處于安全性的考慮，國(guó)外數(shù)據(jù)庫審計(jì)產(chǎn)品，不在本文的評(píng)論范圍內(nèi)。筆者將重點(diǎn)對(duì)國(guó)內(nèi)數(shù)據(jù)庫審計(jì)產(chǎn)品常見缺陷進(jìn)行分析。以下分門別類，針對(duì)最常見的8類數(shù)據(jù)庫安全審計(jì)產(chǎn)品缺陷展開講解。長(zhǎng)SQL語句漏審大多數(shù)的SQL語句都在1K以里長(zhǎng)度，市面上的數(shù)據(jù)庫審計(jì)產(chǎn)品大多都能準(zhǔn)確記錄下，也能實(shí)現(xiàn)正常的解析；但在SQL語句超過1.5K時(shí)，很多的數(shù)據(jù)庫審計(jì)產(chǎn)品就會(huì)發(fā)生漏審，或者只能審計(jì)下部分SQL語句。一般Oracle一個(gè)通訊包的長(zhǎng)度在2K，單一包內(nèi)能夠容納的語句長(zhǎng)度大約在1.4K多一點(diǎn)（大約為1460）；超過這個(gè)大小的SQL語句一般會(huì)拆分成多包；在Oracle11g下通常通訊包為2K，最大可以達(dá)到8K；對(duì)于Oracle數(shù)據(jù)庫沒有明確說明可兼容的SQL語句的長(zhǎng)度，有的說32K或64K是個(gè)臨界點(diǎn)，但筆者也曾作過嘗試2M做的SQL語句也能發(fā)送并被Oracle正常解析。對(duì)于一些數(shù)據(jù)庫審計(jì)產(chǎn)品，由于沒有將多個(gè)SQL通訊包進(jìn)行有效解析和關(guān)聯(lián)，在發(fā)生長(zhǎng)SQL語句時(shí)會(huì)發(fā)生無法解析或解析不全的情況；具體表現(xiàn)是，對(duì)于長(zhǎng)SQL語句并未記錄，或僅記錄了前半部分。這種情況的危害是，對(duì)于有些業(yè)務(wù)系統(tǒng)中自身就包含長(zhǎng)SQL語句，比如經(jīng)分系統(tǒng)，報(bào)表系統(tǒng)，這些SQL語句會(huì)被漏記；同時(shí)，一些黑客或攻擊人員會(huì)利用這樣的一些漏洞，進(jìn)行數(shù)據(jù)庫攻擊而不留下痕跡。比如，若某個(gè)數(shù)據(jù)庫審計(jì)產(chǎn)品，是基于單包解析機(jī)制進(jìn)行的，則對(duì)于超過1.5K的SQL語句無法記錄或僅記錄了前1.5K，則攻擊者可以首先加入1.5K長(zhǎng)的注釋，然后再寫語句，這樣會(huì)發(fā)生漏審或被審計(jì)下來的信息無效。多語句無法有效分割多語句是SQLServer上的一個(gè)特定情況。在其它的數(shù)據(jù)庫管理系統(tǒng)中，語句之間都有明確的分割標(biāo)識(shí)；而在SQLServe中語句之間可以沒有明確的分隔符。下面是一個(gè)示例：useopencmsSETNOCOUNTONselect*fromopencms.opencms.CMS_LOGwhere1=1or‘a(chǎn)’=’b’select*fromopencms.opencms.CMS_HISTORY_PROJECTSwhere1=1在這些語句之間沒有類似于；號(hào)這樣的明確分隔標(biāo)識(shí)符；它們實(shí)際代表了四條語句：useopencmsSETNOCOUNTONselect*fromopencms.opencms.CMS_LOGwhere1=1or‘a(chǎn)’=’b’select*fromopencms.opencms.CMS_HISTORY_PROJECTSwhere1=1SQLServer會(huì)將這些語句不加分割地組織在一個(gè)數(shù)據(jù)庫通訊包中發(fā)送；對(duì)于一些專業(yè)化程度不高的數(shù)據(jù)庫審計(jì)產(chǎn)品，會(huì)將這些語句作為一條語句審計(jì)下來。有效地實(shí)現(xiàn)多語句分割，需要非常專業(yè)的SQL解析技術(shù)。一些簡(jiǎn)單的方法，比如用select、use、set這樣的關(guān)鍵字來進(jìn)行語句分割，稍微復(fù)雜的情況就不好處理了；下面這個(gè)示例，就無法用這種簡(jiǎn)單的方法處理：Select*fromt1wheret1.col1=1unionselect*fromt2wheret2.col1=1select*fromt2wheret2.col1=1即使采用稍微復(fù)雜一些的技術(shù)，比如正則表達(dá)式，也很難做到準(zhǔn)確切割；非專業(yè)化的數(shù)據(jù)庫審計(jì)產(chǎn)品都存在這個(gè)缺陷。對(duì)無法準(zhǔn)確切割多語句的缺陷，在不同的產(chǎn)品中表現(xiàn)不同，所造成的審計(jì)問題也不同，但大體可以總結(jié)為如下幾點(diǎn)：（1）在審計(jì)記錄中，不能準(zhǔn)確記錄下每條語句的SQL操作類型，從而造成一些高危操作不能有效地被識(shí)別或告警，比如drop、truncate這些語句。（2）在審計(jì)記錄中，不能準(zhǔn)確記錄下每條SQL語句的數(shù)據(jù)庫對(duì)象，從而造成對(duì)敏感對(duì)象的訪問不能有效地被識(shí)別或告警。（3）在審計(jì)記錄中，不能準(zhǔn)確地記錄每條語句是否執(zhí)行成功；比如多條語句中第一條語句執(zhí)行成功，后面的語句執(zhí)行失敗了，往往會(huì)被整體記錄為一個(gè)結(jié)果，往往記錄的結(jié)果是成功。（4）在審計(jì)記錄中，不能準(zhǔn)確地反饋出每條語句造成的影響行數(shù)，從而也無法觸發(fā)基于影響行的安全策略；往往記錄下來的都是第一條語句的影響行，其余語句的影響行都被忽略掉了。不夠?qū)I(yè)化的審計(jì)界面這個(gè)問題主要是針對(duì)基于網(wǎng)絡(luò)審計(jì)而發(fā)展來的數(shù)據(jù)庫審計(jì)產(chǎn)品，這種產(chǎn)品由于在設(shè)計(jì)之初就不是專門面向數(shù)據(jù)庫用戶的，因此并未按照數(shù)據(jù)庫的訪問類別、會(huì)話追蹤、數(shù)據(jù)庫對(duì)象層次進(jìn)行界面組織，造成這類產(chǎn)品的界面極其不易使用。過度冗余的審計(jì)信息存儲(chǔ)很多應(yīng)用系統(tǒng)會(huì)采用動(dòng)態(tài)拼接SQL語句