2005年，游俠的老東家就在賣數(shù)據(jù)庫審計，到現(xiàn)在也算是八年抗戰(zhàn)了……說一點點感想：

?

在不算久遠的過去，那時候應用基本都是C/S模式，數(shù)據(jù)庫審計非常簡單

客戶端→數(shù)據(jù)庫服務器

只需要把流量鏡像過來就OK了

無非就是審計源和目的IP、源和目的MAC、登錄賬號、數(shù)據(jù)庫名、表名、語句、返回值

?

漸漸的，三層架構的業(yè)務系統(tǒng)開始增多，包括：

1、網站模式

2、中間件模式

或者說，IIS、Apache、Nginx也算一種中間件，其實對數(shù)據(jù)庫審計而言，一樣

這個時候，數(shù)據(jù)庫如果在同一臺機器上，則幾乎沒辦法

當然，可以裝客戶端的方式來解決，但是大型客戶一定不會同意

——以前有一家做軟件數(shù)據(jù)庫審計的，一家關門大吉了

?

那么，如果不在服務器上不輸任何客戶端，則通過旁路的方式，客戶最能接受

其實中間還有一個折中，就是管理員訪問數(shù)據(jù)庫的時候，通過堡壘機的方式實現(xiàn)

這樣的方式，可以設定阻斷策略，對管理員的操作進行數(shù)據(jù)庫操作阻斷

但是，多數(shù)客戶依然會選擇旁路的方案，因為最簡單，無風險

并且，我所遇到的客戶，全部都不想在中間件安裝客戶端

所以，只剩下了：

1、鏡像“瀏覽器客戶端→中間件或服務器”流量

2、鏡像“中間件或服務器→數(shù)據(jù)庫服務器”流量

然后，二者進行關聯(lián)……

?

理所當然的，如各位所考慮的，做不到百分之百的準確

甚至，有一次測試，去了4家，其中3家都說百分之五六十、六七十的準確性

客戶放棄了！我們去的比較晚，所以我也沒機會親自測試到底準確性有多少

?

各類語句，包括select、delete、insert、update等都沒問題

登錄操作、退出操作等，也沒有問題，這一點，無需多慮

性能上，如果單臺搞不定，通過“agent+host”的方式，部署多臺agent

在agent上對數(shù)據(jù)庫日志進行壓縮、歸并，然后發(fā)送到host，這不是問題

?

公司以前是純粹的做數(shù)據(jù)庫審計，后來推出了業(yè)務數(shù)據(jù)庫審計，比以前強很多

可以定義特定操作進行報警，可以針對操作頻率報警，也可以阻斷非合規(guī)客戶端

不但像以前那樣可以審計到計算機（IP），也可以抓到多人一機的帳號

（三班倒的情況，多人共用一臺計算機，并且是B/S模式）

關于存儲，我們做到12TB了……并且可以直接存到存儲上去，這個不是大問題

?

告警方式：郵件、snmp trap、短信、syslog，不建議短信，煩死

SQL語句翻譯，思福迪的業(yè)務數(shù)據(jù)庫審計系統(tǒng)是做了，比看語句直觀的多！

?

游俠建議數(shù)據(jù)庫審計、網絡審計一起部署，網絡審計可以做數(shù)據(jù)庫審計的有益補充

同時，針對管理員的操作，部署堡壘機，基本算是比較完善的解決方案了

?

一直想寫一篇數(shù)據(jù)庫審計的文章，稍微細致一些的，不過現(xiàn)在太懶了！

并且，因為自己公司就在做數(shù)據(jù)庫審計，所以……估計別人也不放心把資料給我。

?

文章部分圖片來自思福迪公司資料，部分來自思福迪審計產品。

?

作者：張百川（網路游俠）www.youxia.org 轉載請注明來源！謝謝

本文轉自網路游俠 51CTO博客，原文鏈接:http://blog.51cto.com/youxia/1086085

總結

以上是生活随笔為你收集整理的游侠随笔：关于业务型数据库审计 有图有真相的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。