如何避免數(shù)據(jù)庫行為監(jiān)控系統(tǒng)部署問題
在部署數(shù)據(jù)庫行為監(jiān)控（DAM）系統(tǒng)時有兩個最常見的問題：數(shù)據(jù)采集的準確性問題和DAM系統(tǒng)的性能問題。這篇文章，我們將討論如何避免掉入DAM的上述陷進中。
不當?shù)谋O(jiān)控方式會影響審計的準確性
DAM產(chǎn)品一個經(jīng)常被忽視的缺點就是網(wǎng)絡監(jiān)視。對于非關鍵的數(shù)據(jù)庫基礎設施，通過網(wǎng)絡監(jiān)視采集SQL行為是可行的。但如果出于合規(guī)需要，則最好選擇代理型的DAM產(chǎn)品。這類產(chǎn)品通過在數(shù)據(jù)庫平臺上安裝代理來檢測所有的數(shù)據(jù)庫連接，包括管理員的行為。
上述兩種采集方式都能夠收集各種原始SQL語句，包括嵌入在查詢中的變量，而這是系統(tǒng)自帶的審計以及大部分其他采集方式所無法做到的。然而，對于網(wǎng)絡流量檢測和基于代理的檢測兩種部署方式而言，在數(shù)據(jù)收集的準確性和完整性方面有著很大的差別。在高負載的情況下，某些方法就會丟失數(shù)據(jù)包。由于丟失查詢語句很少被注意到，通常不會引起什么抱怨。但是如果正在對一組事務（譯注：事務即Transaction，屬于數(shù)據(jù)庫管理系統(tǒng)的術語，相當于一組數(shù)據(jù)庫操作的集合）進行SOX合規(guī)審計，那么丟失的事務記錄將導致審計報告失效。
第二個不易察覺的嚴重問題是DAM系統(tǒng)收集SQL語句返回信息的能力很弱。所有的查詢都會產(chǎn)生響應，一般是一組數(shù)據(jù)，有時候則僅僅是一個標志成功或者失敗的返回碼。如果一個查詢失敗，查詢沒有被真正執(zhí)行，這就意味著數(shù)據(jù)庫沒有發(fā)生變化。最近我做的一項非正式的調查顯示某個產(chǎn)品僅僅能夠收集45%的微軟SQL Server數(shù)據(jù)庫的返回信息，以及15%的Oracle返回信息。僅僅因為一條查詢請求被收集到了，并不意味著它就能夠成為審計線索的合法部分，還要看這個查詢請求的響應信息。
正是由于這些原因，在合規(guī)審計的背景下，最好的部署方式是將網(wǎng)絡代理方式或者內(nèi)存掃描器方式與系統(tǒng)自身的審計數(shù)據(jù)收集方式結合起來。將系統(tǒng)自身的審計信息與（通過網(wǎng)絡檢測或者代理檢測等方式獲得的）包含在原始查詢中的數(shù)據(jù)結合起來，提供了一種兩全其美的確保數(shù)據(jù)準確性的方法。
策略過載和性能過載
性能依然是數(shù)據(jù)庫行為監(jiān)控系統(tǒng)需要關注的一個問題。對于任何一款安全產(chǎn)品，隨著在產(chǎn)品中生效的策略數(shù)量的增長，行為分析所需的整體計算開銷會出現(xiàn)超負荷。每條收集到的查詢語句或者事務執(zhí)行語句都要匹配所有的策略，策略數(shù)量從20條增長到40條與每天分析的事務數(shù)從200萬條到400萬一樣，都會對性能產(chǎn)生影響。因此，DAM產(chǎn)品的性能極限既取決于分析的事務數(shù)，也取決于生效的策略數(shù)。
要使得DAM產(chǎn)品性能維持在可接受的水平，可以遵循以下幾條指南：
1）行為分析策略會使得行為資料數(shù)據(jù)隨行為分析的進行而增長。應該盡量保持行為資料數(shù)據(jù)最小化，因為對這些資料的分析更加復雜。
2）要決定DAM系統(tǒng)何時匹配這些策略。在收集到記錄（即行為資料數(shù)據(jù)）后進行策略匹配，還是在將記錄存儲到DAM產(chǎn)品后再進行策略匹配？存儲延遲和對收集到的記錄的再查詢都會造成額外的計算開銷，顯然對產(chǎn)品提供商而言不是一個好的選擇?！ ?/P>
3）要對策略進行優(yōu)化，盡量使得策略匹配過程中最快和最簡單的部分被首先執(zhí)行。這就跟查詢語句的優(yōu)化是一個道理，策略的規(guī)則表達方式對于性能會產(chǎn)生戲劇性的影響。重新評估和優(yōu)化那些策略規(guī)則，同時，必要的話，讓DAM供應商重寫那些低效的規(guī)則。
【編輯推薦】
