安華金和全面適配國(guó)產(chǎn)化操作系統(tǒng)及芯片CPU
數(shù)據(jù)安全治理關(guān)鍵技術(shù)之?dāng)?shù)據(jù)庫(kù)脫敏技術(shù)詳解
數(shù)據(jù)安全治理之API監(jiān)測(cè)系統(tǒng) ,解決API接口安全問(wèn)題【安華金和】
新一代數(shù)據(jù)庫(kù)脫敏技術(shù),為敏感數(shù)據(jù)建立保護(hù)盾!
數(shù)據(jù)庫(kù)脫敏系統(tǒng)與金融行業(yè)案例解讀
數(shù)據(jù)安全治理建設(shè)思路的著力點(diǎn)——數(shù)據(jù)安全咨詢服務(wù)【安華金和】
數(shù)據(jù)庫(kù)防火墻功能有哪些?-數(shù)據(jù)安全-安華金和
數(shù)據(jù)安全關(guān)鍵技術(shù)之?dāng)?shù)據(jù)庫(kù)脫敏技術(shù)詳解【安華金和】
中國(guó)數(shù)據(jù)安全治理落地指導(dǎo)書籍《數(shù)據(jù)安全治理白皮書5.0》正式發(fā)布(附下載)
隨著信息化的發(fā)展,數(shù)據(jù)庫(kù)安全問(wèn)題成為當(dāng)前政府和企事業(yè)單位用戶關(guān)注的焦點(diǎn),數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品已經(jīng)成為當(dāng)前信息安全產(chǎn)品的盛寵。
當(dāng)前在市面上存在著幾十種數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品,這些產(chǎn)品集中起來(lái)大約可分四種類型:
(1)在網(wǎng)絡(luò)審計(jì)產(chǎn)品的基礎(chǔ)上經(jīng)過(guò)簡(jiǎn)單包裝推出數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品的既有網(wǎng)絡(luò)審計(jì)產(chǎn)品廠商,比如國(guó)內(nèi)幾大安全廠商推出的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品,安全圈都知道,不再例舉;
(2)針對(duì)數(shù)據(jù)庫(kù)通訊協(xié)議的特點(diǎn)開發(fā)出專門的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品的國(guó)內(nèi)細(xì)分領(lǐng)域安全廠商,比如安華金和、思福迪、國(guó)都興業(yè)、帕拉迪等;
(3)國(guó)外的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品,比如Imperva、Guardium等;
(4)OEM第三方的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品,OEM對(duì)象可能來(lái)自國(guó)內(nèi),也可能來(lái)自國(guó)外,比如Imperva或韓國(guó)的DBInsight。
隨著國(guó)產(chǎn)化采購(gòu)政策的推動(dòng),處于安全性的考慮,國(guó)外數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品,不在本文的評(píng)論范圍內(nèi)。筆者將重點(diǎn)對(duì)國(guó)內(nèi)數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品常見缺陷進(jìn)行分析。以下分門別類,針對(duì)最常見的8類數(shù)據(jù)庫(kù)安全審計(jì)產(chǎn)品缺陷展開講解。
大多數(shù)的SQL語(yǔ)句都在1K以里長(zhǎng)度,市面上的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品大多都能準(zhǔn)確記錄下,也能實(shí)現(xiàn)正常的解析;但在SQL語(yǔ)句超過(guò)1.5K時(shí),很多的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品就會(huì)發(fā)生漏審,或者只能審計(jì)下部分SQL語(yǔ)句。
一般Oracle一個(gè)通訊包的長(zhǎng)度在2K,單一包內(nèi)能夠容納的語(yǔ)句長(zhǎng)度大約在1.4K多一點(diǎn)(大約為1460);超過(guò)這個(gè)大小的SQL語(yǔ)句一般會(huì)拆分成多包;在Oracle 11g下通常通訊包為2K,最大可以達(dá)到8K;對(duì)于Oracle數(shù)據(jù)庫(kù)沒(méi)有明確說(shuō)明可兼容的SQL語(yǔ)句的長(zhǎng)度,有的說(shuō)32K或64K是個(gè)臨界點(diǎn),但筆者也曾作過(guò)嘗試2M做的SQL語(yǔ)句也能發(fā)送并被Oracle正常解析。
對(duì)于一些數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品,由于沒(méi)有將多個(gè)SQL通訊包進(jìn)行有效解析和關(guān)聯(lián),在發(fā)生長(zhǎng)SQL語(yǔ)句時(shí)會(huì)發(fā)生無(wú)法解析或解析不全的情況;具體表現(xiàn)是,對(duì)于長(zhǎng)SQL語(yǔ)句并未記錄,或僅記錄了前半部分。
這種情況的危害是,對(duì)于有些業(yè)務(wù)系統(tǒng)中自身就包含長(zhǎng)SQL語(yǔ)句,比如經(jīng)分系統(tǒng),報(bào)表系統(tǒng),這些SQL語(yǔ)句會(huì)被漏記;同時(shí),一些黑客或攻擊人員會(huì)利用這樣的一些漏洞,進(jìn)行數(shù)據(jù)庫(kù)攻擊而不留下痕跡。比如,若某個(gè)數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品,是基于單包解析機(jī)制進(jìn)行的,則對(duì)于超過(guò)1.5K的SQL語(yǔ)句無(wú)法記錄或僅記錄了前1.5K,則攻擊者可以首先加入1.5K長(zhǎng)的注釋,然后再寫語(yǔ)句,這樣會(huì)發(fā)生漏審或被審計(jì)下來(lái)的信息無(wú)效。
多語(yǔ)句是SQL Server上的一個(gè)特定情況。在其它的數(shù)據(jù)庫(kù)管理系統(tǒng)中,語(yǔ)句之間都有明確的分割標(biāo)識(shí);而在SQL Serve中語(yǔ)句之間可以沒(méi)有明確的分隔符。下面是一個(gè)示例:
use opencms SET NOCOUNT ON select * from opencms.opencms.CMS_LOG where 1=1 or ‘a(chǎn)’ =’b’ select * from opencms.opencms.CMS_HISTORY_PROJECTS where 1=1
在這些語(yǔ)句之間沒(méi)有類似于 ;號(hào)這樣的明確分隔標(biāo)識(shí)符;它們實(shí)際代表了四條語(yǔ)句:
use opencms
SET NOCOUNT ON
select * from opencms.opencms.CMS_LOG where 1=1 or ‘a(chǎn)’ =’b’
select * from opencms.opencms.CMS_HISTORY_PROJECTS where 1=1
SQL Server會(huì)將這些語(yǔ)句不加分割地組織在一個(gè)數(shù)據(jù)庫(kù)通訊包中發(fā)送;對(duì)于一些專業(yè)化程度不高的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品,會(huì)將這些語(yǔ)句作為一條語(yǔ)句審計(jì)下來(lái)。有效地實(shí)現(xiàn)多語(yǔ)句分割,需要非常專業(yè)的SQL解析技術(shù)。一些簡(jiǎn)單的方法,比如用select、use 、set這樣的關(guān)鍵字來(lái)進(jìn)行語(yǔ)句分割,稍微復(fù)雜的情況就不好處理了;下面這個(gè)示例,就無(wú)法用這種簡(jiǎn)單的方法處理:
Select * from t1 where t1.col1 = 1 union select * from t2 where t2.col1 = 1 select * from t2 where t2.col1 = 1
即使采用稍微復(fù)雜一些的技術(shù),比如正則表達(dá)式,也很難做到準(zhǔn)確切割;非專業(yè)化的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品都存在這個(gè)缺陷。 對(duì)無(wú)法準(zhǔn)確切割多語(yǔ)句的缺陷,在不同的產(chǎn)品中表現(xiàn)不同,所造成的審計(jì)問(wèn)題也不同,但大體可以總結(jié)為如下幾點(diǎn):
(1)在審計(jì)記錄中,不能準(zhǔn)確記錄下每條語(yǔ)句的SQL操作類型,從而造成一些高危操作不能有效地被識(shí)別或告警,比如drop、truncate這些語(yǔ)句。
(2)在審計(jì)記錄中,不能準(zhǔn)確記錄下每條SQL語(yǔ)句的數(shù)據(jù)庫(kù)對(duì)象,從而造成對(duì)敏感對(duì)象的訪問(wèn)不能有效地被識(shí)別或告警。
(3)在審計(jì)記錄中,不能準(zhǔn)確地記錄每條語(yǔ)句是否執(zhí)行成功;比如多條語(yǔ)句中第一條語(yǔ)句執(zhí)行成功,后面的語(yǔ)句執(zhí)行失敗了,往往會(huì)被整體記錄為一個(gè)結(jié)果,往往記錄的結(jié)果是成功。
(4)在審計(jì)記錄中,不能準(zhǔn)確地反饋出每條語(yǔ)句造成的影響行數(shù),從而也無(wú)法觸發(fā)基于影響行的安全策略;往往記錄下來(lái)的都是第一條語(yǔ)句的影響行,其余語(yǔ)句的影響行都被忽略掉了。
數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品中一個(gè)重要需求是要有效記錄下來(lái)SQL語(yǔ)句的操作類型、訪問(wèn)對(duì)象;根據(jù)這些操作類型和訪問(wèn)對(duì)象,審計(jì)產(chǎn)品可以有效地制訂告警策略,可以有效地根據(jù)操作類型、訪問(wèn)對(duì)象進(jìn)行事后的追蹤與檢索。我國(guó)相關(guān)部門的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品標(biāo)準(zhǔn)中要求:應(yīng)對(duì)數(shù)據(jù)庫(kù)網(wǎng)絡(luò)訪問(wèn)對(duì)象的名稱進(jìn)行準(zhǔn)確審計(jì),包括數(shù)據(jù)庫(kù)服務(wù)器名稱、IP名稱、數(shù)據(jù)庫(kù)名稱、表、視圖、序列、包、存儲(chǔ)過(guò)程、函數(shù)、庫(kù)、索引和觸發(fā)器等。
目前國(guó)內(nèi)大多數(shù)數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品都會(huì)宣稱支持對(duì)SQL語(yǔ)句操作類型和訪問(wèn)對(duì)象的審計(jì)支持;但事實(shí)上,很多審計(jì)產(chǎn)品的支持能力有限,往往只能支持一些簡(jiǎn)單語(yǔ)句的解析,比如這樣的語(yǔ)句:
Select * from tbl1 where col1 > ’1’;
但筆者曾經(jīng)見過(guò)一家大型的信息安全廠商的產(chǎn)品,僅僅是在表名前增加一個(gè)schema名稱,就發(fā)生了令人震驚的錯(cuò)誤;這個(gè)產(chǎn)品居然將schema名稱審計(jì)為了表名。如上面這條語(yǔ)句改為;
Select * from user1.tbl1 where col1 > ‘1’;
這種數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品就會(huì)將user1記錄為表名。
事實(shí)上,上面被誤報(bào)的例子,是一個(gè)非常簡(jiǎn)單的例子,大多數(shù)專業(yè)的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品都不會(huì)犯這樣的錯(cuò)誤。事實(shí)上,真正的挑戰(zhàn)要比上面的例子復(fù)雜很多。
參數(shù)綁定是數(shù)據(jù)庫(kù)編程中常用的一種方法,通過(guò)這種方法,數(shù)據(jù)庫(kù)系統(tǒng)可以減少編譯次數(shù),快速執(zhí)行,提升效率;但這種編程方法將對(duì)數(shù)據(jù)庫(kù)的審計(jì)帶來(lái)挑戰(zhàn),在筆者所見到的若干數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品中,在這種情況下都出了不少的錯(cuò)誤。有的是漏審了語(yǔ)句,有的是記錄下了操作的語(yǔ)句,但將具體執(zhí)行時(shí)所使用的參數(shù)記錯(cuò)了或漏記了。這些缺陷對(duì)于審計(jì)產(chǎn)品無(wú)疑很是致命。
為了詳解這種情況,我們來(lái)看一下參數(shù)綁定的基本概念。我們?cè)诔R?guī)的圖形化或命令行工具中,往往都是直接寫上SQL語(yǔ)句,比如:
Select * from person_info where id=’12XXXXX6722’;
在這里查詢條件是身份證號(hào)碼。根據(jù)身份證號(hào)碼查詢個(gè)人信息,是一種常用功能,也是會(huì)重復(fù)使用的語(yǔ)句,為了提升效率,編程中可以這么寫:
String sql1=’Select * from person_info where id=?;’
PreparedStatement pStmt = testConn.getConnection().prepareStatement(sql);
pStmt.setInt(1, ’12XXXXX6722’);
pStmt.execute();
下一次再使用時(shí),就不用再發(fā)送語(yǔ)句了,可以直接發(fā)送:
pStmt.setInt(1, ’22XXXXX5399’);
pStmt.execute();
對(duì)于數(shù)據(jù)庫(kù)審計(jì)系統(tǒng)而言,單純地記錄下來(lái)‘Select * from person_info where id=?’是存在缺陷的,因?yàn)槟銦o(wú)法明確額操作人員到底訪問(wèn)了哪個(gè)用戶的信息,必須明確下來(lái)具體的參數(shù)才行。
這就要求將設(shè)定的參數(shù),與Prepare的語(yǔ)句有效的關(guān)聯(lián),形成可視化的審計(jì)記錄展現(xiàn):
Select * from person_info where id=’12XXXXX6722’;
Select * from person_info where id=’22XXXXX5399’;
這實(shí)際上要求審計(jì)系統(tǒng)比起單純的記錄語(yǔ)句要完成更多的工作;其中一個(gè)重要任務(wù)的就是句柄追蹤,本質(zhì)上SQL語(yǔ)句的執(zhí)行過(guò)程追蹤就是句柄追蹤過(guò)程。在上面顯示的例子中,pStmt.execute(),在通訊過(guò)程中并不發(fā)送具體的語(yǔ)句,而僅是告知服務(wù)器要執(zhí)行哪個(gè)語(yǔ)句句柄,服務(wù)器端會(huì)根據(jù)內(nèi)部記錄的句柄所對(duì)應(yīng)的已經(jīng)編譯完成的SQL語(yǔ)句的執(zhí)行計(jì)劃,進(jìn)行語(yǔ)句執(zhí)行。數(shù)據(jù)庫(kù)審計(jì)要完成相應(yīng)的工作,需要執(zhí)行類似的過(guò)程,在系統(tǒng)的內(nèi)部也維護(hù)這樣的映射關(guān)系;同時(shí)由于大多數(shù)數(shù)據(jù)庫(kù)的句柄,是在會(huì)話級(jí)的,句柄是可重用的,因此在數(shù)據(jù)庫(kù)審計(jì)中還要有效地維護(hù)句柄與session的關(guān)聯(lián),以及句柄的消亡。
在句柄維護(hù)之外,另一個(gè)有挑戰(zhàn)的工作就是參數(shù)的還原。參數(shù)的還原,首要的是要明確參數(shù)所對(duì)應(yīng)的句柄;在調(diào)用pStmt.setInt(1, ’22XXXXX5399’)時(shí),在網(wǎng)絡(luò)中發(fā)送的包,會(huì)標(biāo)明這個(gè)參數(shù)是針對(duì)哪個(gè)句柄的,是針對(duì)第幾個(gè)參數(shù)的。作為數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品,需要將參數(shù)與語(yǔ)句進(jìn)行映射;更重要地要準(zhǔn)確地填回參數(shù)所在的位置,上面這個(gè)例子由于只有一個(gè)參數(shù),沒(méi)有什么挑戰(zhàn)性,參數(shù)的綁定情況遠(yuǎn)比這個(gè)復(fù)雜。
除了以上列舉的4個(gè)常見缺陷,在實(shí)際情況下還有一些常見的缺陷:
對(duì)于SQL操作是否成功,是數(shù)據(jù)庫(kù)審計(jì)的基本需求;對(duì)數(shù)據(jù)庫(kù)操作讀取或影響了多少行是用戶的實(shí)際需求。但SQL操作成功與否的準(zhǔn)確記錄,需要仰仗SQL語(yǔ)句的合理切割和句柄的準(zhǔn)確追蹤及對(duì)返回結(jié)果集的完全解析;大多數(shù)數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品在多語(yǔ)句情況,或者通過(guò)FETCH操作批量獲取等環(huán)節(jié)下,無(wú)法準(zhǔn)確獲得查詢執(zhí)行的正確性以及影響行數(shù)。
市場(chǎng)上的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品大多數(shù)都宣傳支持三層關(guān)聯(lián)審計(jì),實(shí)現(xiàn)SQL語(yǔ)句與業(yè)務(wù)用戶的關(guān)聯(lián)。這種基于三層關(guān)聯(lián)審計(jì)的技術(shù),是通過(guò)http協(xié)議中的參數(shù)與SQL語(yǔ)句中的參數(shù)的匹配,以及時(shí)間的匹配來(lái)完成的,屬于模糊匹配。這種方法在http參數(shù)經(jīng)過(guò)加工后或基于邏輯判斷后再發(fā)出SQL語(yǔ)句,也即SQL語(yǔ)句的參數(shù)與http參數(shù)沒(méi)有直接的匹配關(guān)系時(shí)將完全失效;在高并發(fā)時(shí)更是一個(gè)災(zāi)難。這種方法的準(zhǔn)確率往往很難超過(guò)80%。
這個(gè)問(wèn)題主要是針對(duì)基于網(wǎng)絡(luò)審計(jì)而發(fā)展來(lái)的數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品,這種產(chǎn)品由于在設(shè)計(jì)之初就不是專門面向數(shù)據(jù)庫(kù)用戶的,因此并未按照數(shù)據(jù)庫(kù)的訪問(wèn)類別、會(huì)話追蹤、數(shù)據(jù)庫(kù)對(duì)象層次進(jìn)行界面組織,造成這類產(chǎn)品的界面極其不易使用。
很多應(yīng)用系統(tǒng)會(huì)采用動(dòng)態(tài)拼接SQL語(yǔ)句的方式來(lái)實(shí)現(xiàn)對(duì)數(shù)據(jù)庫(kù)的訪問(wèn);這會(huì)造成大量SQL語(yǔ)句語(yǔ)法形式相同而僅僅是SQL語(yǔ)句中的參數(shù)值不同的語(yǔ)句。當(dāng)前的很多審計(jì)產(chǎn)品將這些語(yǔ)句進(jìn)行重復(fù)地記錄和存儲(chǔ),造成了審計(jì)效率的低下,存儲(chǔ)設(shè)備的浪費(fèi),并會(huì)對(duì)SQL語(yǔ)句的分析和排查效率造成致命影響。
作為國(guó)內(nèi)專業(yè)的數(shù)據(jù)庫(kù)安全廠商,安華金和數(shù)據(jù)庫(kù)審計(jì)產(chǎn)品(DBAudit)可以有效避免以上8類缺陷常見缺陷。
試用申請(qǐng)
在線咨詢
咨詢電話
TOP