1、數(shù)據(jù)庫安全審計常見8 種缺陷作者安華金和劉曉韜隨著信息化的發(fā)展，數(shù)據(jù)庫安全問題成為當前政府和企事業(yè)單位用戶關注的焦點，數(shù)據(jù)庫審計產品已經成為當前信息安全產品的盛寵。當前在市面上存在著幾十種數(shù)據(jù)庫審計產品，這些產品集中起來大約可分四種類型：（ 1）在網絡審計產品的基礎上經過簡單包裝推出數(shù)據(jù)庫審計產品的既有網絡審計產品廠商 ，比如國內幾大安全廠商推出的數(shù)據(jù)庫審計產品，安全圈都知道，不再例舉；（ 2）針對數(shù)據(jù)庫通訊協(xié)議的特點開發(fā)出專門的數(shù)據(jù)庫審計產品的國內細分領域安全廠商 ，比如安華金和、思福迪、國都興業(yè)、帕拉迪等；（ 3）國外的數(shù)據(jù)庫審計產品 ，比如 Imperva 、Guardium 等；（ 4

2、）OEM 第三方的數(shù)據(jù)庫審計產品 ， OEM 對象可能來自國內，也可能來自國外，比如 Imperva 或韓國的 DBInsight 。隨著國產化采購政策的推動，處于安全性的考慮，國外數(shù)據(jù)庫審計產品，不在本文的評論范圍內。 筆者將重點對國內數(shù)據(jù)庫審計產品常見缺陷進行分析。 以下分門別類， 針對最常見的 8 類數(shù)據(jù)庫安全審計產品缺陷展開講解。長 SQL 語句漏審大多數(shù)的 SQL 語句都在1K 以里長度， 市面上的數(shù)據(jù)庫審計產品大多都能準確記錄下，也能實現(xiàn)正常的解析；但在SQL 語句超過1.5K 時，很多的數(shù)據(jù)庫審計產品就會發(fā)生漏審，或者只能審計下部分SQL語句。一般 Oracle 一個通訊包的長度

3、在2K ，單一包內能夠容納的語句長度大約在1.4K 多一點（大約為1460 ）；超過這個大小的SQL 語句一般會拆分成多包；在Oracle 11g下通常通訊包為2K ，最大可以達到8K ；對于 Oracle 數(shù)據(jù)庫沒有明確說明可兼容的SQL 語句的長度，有的說 32K 或 64K 是個臨界點， 但筆者也曾作過嘗試2M 做的 SQL 語句也能發(fā)送并被Oracle正常解析。長對于一些數(shù)據(jù)庫審計產品，由于沒有將多個SQL 語句時會發(fā)生無法解析或解析不全的情況；SQL 通訊包進行有效解析和關聯(lián)，在發(fā)生具體表現(xiàn)是，對于長 SQL 語句并未記錄，或僅記錄了前半部分。這種情況的危害是，對于有些業(yè)務系統(tǒng)中自身

4、就包含長SQL語句，比如經分系統(tǒng)，報表系統(tǒng)，這些SQL 語句會被漏記；同時，一些黑客或攻擊人員會利用這樣的一些漏洞，進行數(shù)據(jù)庫攻擊而不留下痕跡。比如，若某個數(shù)據(jù)庫審計產品，是基于單包解析機制進行的，則對于超過1.5K 的 SQL 語句無法記錄或僅記錄了前1.5K ，則攻擊者可以首先加入1.5K 長的注釋，然后再寫語句，這樣會發(fā)生漏審或被審計下來的信息無效。多語句無法有效分割多語句是 SQL Server 上的一個特定情況。在其它的數(shù)據(jù)庫管理系統(tǒng)中，語句之間都有明確的分割標識；而在 SQL Serve 中語句之間可以沒有明確的分隔符。下面是一個示例： use opencms SET NOCOUN

5、T ON select * from opencms.opencms.CMS_LOG where1=1 or a = b select * from opencms.opencms.CMS_HISTORY_PROJECTS where 1=1在這些語句之間沒有類似于；號這樣的明確分隔標識符；它們實際代表了四條語句：use opencmsSET NOCOUNT ONselect * from opencms.opencms.CMS_LOG where 1=1 or a = b select * from opencms.opencms.CMS_HISTORY_PROJECTS where 1=1

6、SQL Server會將這些語句不加分割地組織在一個數(shù)據(jù)庫通訊包中發(fā)送；對于一些專業(yè)化程度不高的數(shù)據(jù)庫審計產品，會將這些語句作為一條語句審計下來。有效地實現(xiàn)多語句分割，需要非常專業(yè)的SQL解析技術。一些簡單的方法，比如用select 、 use、 set這樣的關鍵字來進行語句分割，稍微復雜的情況就不好處理了；下面這個示例， 就無法用這種簡單的方法處理：Select * from t1 where t1.col1 = 1 union select * fromt2 where t2.col1 = 1 select * from t2where t2.col1 = 1即使采用稍微復雜一些的技術，比

7、如正則表達式，也很難做到準確切割；非專業(yè)化的數(shù)據(jù)庫審計產品都存在這個缺陷。 對無法準確切割多語句的缺陷， 在不同的產品中表現(xiàn)不同，所造成的審計問題也不同，但大體可以總結為如下幾點：（ 1）在審計記錄中，不能準確記錄下每條語句的SQL 操作類型，從而造成一些高危操作不能有效地被識別或告警，比如drop 、 truncate這些語句。（ 2）在審計記錄中，不能準確記錄下每條 SQL 語句的數(shù)據(jù)庫對象，從而造成對敏感對象的訪問不能有效地被識別或告警。（ 3）在審計記錄中，不能準確地記錄每條語句是否執(zhí)行成功；比如多條語句中第一條語句執(zhí)行成功， 后面的語句執(zhí)行失敗了， 往往會被整體記錄為一個結果， 往往

8、記錄的結果是成功。（ 4）在審計記錄中，不能準確地反饋出每條語句造成的影響行數(shù)，從而也無法觸發(fā)基于影響行的安全策略； 往往記錄下來的都是第一條語句的影響行， 其余語句的影響行都被忽略掉了。數(shù)據(jù)庫對象解析錯誤數(shù)據(jù)庫審計產品中一個重要需求是要有效記錄下來SQL 語句的操作類型、訪問對象；根據(jù)這些操作類型和訪問對象，審計產品可以有效地制訂告警策略，可以有效地根據(jù)操作類型、訪問對象進行事后的追蹤與檢索。我國相關部門的數(shù)據(jù)庫審計產品標準中要求：應對數(shù)據(jù)庫網絡訪問對象的名稱進行準確審計，包括數(shù)據(jù)庫服務器名稱、IP 名稱、數(shù)據(jù)庫名稱、表、視圖、序列、包、存儲過程、函數(shù)、庫、索引和觸發(fā)器等。目前國內大多數(shù)數(shù)據(jù)

9、庫審計產品都會宣稱支持對SQL 語句操作類型和訪問對象的審計支持； 但事實上，很多審計產品的支持能力有限，往往只能支持一些簡單語句的解析，比如這樣的語句：Select * from tbl1 where col1 1;但筆者曾經見過一家大型的信息安全廠商的產品，僅僅是在表名前增加一個schema名稱， 就發(fā)生了令人震驚的錯誤；這個產品居然將schema名稱審計為了表名。如上面這條語句改為；Select * from user1.tbl1 where col1 1;這種數(shù)據(jù)庫審計產品就會將user1 記錄為表名。事實上， 上面被誤報的例子，是一個非常簡單的例子，大多數(shù)專業(yè)的數(shù)據(jù)庫審計產品都不會犯

10、這樣的錯誤。事實上，真正的挑戰(zhàn)要比上面的例子復雜很多。參數(shù)審計錯誤參數(shù)綁定是數(shù)據(jù)庫編程中常用的一種方法，通過這種方法， 數(shù)據(jù)庫系統(tǒng)可以減少編譯次數(shù)，快速執(zhí)行， 提升效率； 但這種編程方法將對數(shù)據(jù)庫的審計帶來挑戰(zhàn)，在筆者所見到的若干數(shù)據(jù)庫審計產品中，在這種情況下都出了不少的錯誤。有的是漏審了語句，有的是記錄下了操作的語句， 但將具體執(zhí)行時所使用的參數(shù)記錯了或漏記了。這些缺陷對于審計產品無疑很是致命。為了詳解這種情況， 我們來看一下參數(shù)綁定的基本概念。 我們在常規(guī)的圖形化或命令行工具中，往往都是直接寫上 SQL 語句，比如：Selec t * from person_info where id=

11、12XXXXX6722;在這里查詢條件是身份證號碼。 根據(jù)身份證號碼查詢個人信息， 是一種常用功能， 也是會重復使用的語句，為了提升效率，編程中可以這么寫：String sql1= Select * from person_info where id=?;PreparedStatement pStmt = testConn.getConnection().prepareStatement(sql);pStmt.setInt(1, 12XXXXX6722 );pStmt.execute();下一次再使用時，就不用再發(fā)送語句了，可以直接發(fā)送：pStmt.setInt(1, 22XXXXX5399

12、);pStmt.execute();對于數(shù)據(jù)庫審計系統(tǒng)而言，單純地記錄下來Select * from person_info where id=?是存在缺陷的， 因為你無法明確額操作人員到底訪問了哪個用戶的信息，必須明確下來具體的參數(shù)才行。這就要求將設定的參數(shù)，與Prepare 的語句有效的關聯(lián)，形成可視化的審計記錄展現(xiàn):Sele ct * from person_info where id= 12XXXXX6722;Select * from person_info where id= 22XXXXX5399;這實際上要求審計系統(tǒng)比起單純的記錄語句要完成更多的工作；其中一個重要任務的就是句柄

13、追蹤，本質上SQL 語句的執(zhí)行過程追蹤就是句柄追蹤過程。在上面顯示的例子中，pStmt.execute()，在通訊過程中并不發(fā)送具體的語句，而僅是告知服務器要執(zhí)行哪個語句句柄，服務器端會根據(jù)內部記錄的句柄所對應的已經編譯完成的SQL 語句的執(zhí)行計劃，進行語句執(zhí)行。 數(shù)據(jù)庫審計要完成相應的工作，需要執(zhí)行類似的過程，在系統(tǒng)的內部也維護這樣的映射關系； 同時由于大多數(shù)數(shù)據(jù)庫的句柄，是在會話級的，句柄是可重用的，因此在數(shù)據(jù)庫審計中還要有效地維護句柄與session 的關聯(lián)，以及句柄的消亡。在句柄維護之外，另一個有挑戰(zhàn)的工作就是參數(shù)的還原。參數(shù)的還原， 首要的是要明確參數(shù)所對應的句柄；在調用pStmt.

14、setInt(1, 22XXXXX5399 )時，在網絡中發(fā)送的包，會標明這個參數(shù)是針對哪個句柄的，是針對第幾個參數(shù)的。作為數(shù)據(jù)庫審計產品，需要將參數(shù)與語句進行映射；更重要地要準確地填回參數(shù)所在的位置，上面這個例子由于只有一個參數(shù)，沒有什么挑戰(zhàn)性，參數(shù)的綁定情況遠比這個復雜。除了以上列舉的4 個常見缺陷，在實際情況下還有一些常見的缺陷：錯誤的應答結果，特別是影響行數(shù)解析不正確對于 SQL 操作是否成功，是數(shù)據(jù)庫審計的基本需求；對數(shù)據(jù)庫操作讀取或影響了多少行是用戶的實際需求。 但 SQL 操作成功與否的準確記錄，需要仰仗SQL 語句的合理切割和句柄的準確追蹤及對返回結果集的完全解析；大多數(shù)數(shù)據(jù)庫審計產品在多語句情況，或者通過FETCH 操作批量獲取等環(huán)節(jié)下，無法準確獲得查詢執(zhí)行的正確性以及影響行數(shù)。充滿失真率的應用用戶關聯(lián)市場上的數(shù)據(jù)庫審計產品大多數(shù)都宣傳支持三層關聯(lián)審計，實現(xiàn)SQL語句與業(yè)務用戶的關聯(lián)。這種基于三層關聯(lián)審計的技術，是通過http協(xié)議中的參數(shù)與SQL語句中的參數(shù)的匹配，以及時間的匹配來完成的，屬于模