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