安全審計打造固若金湯的數據堡壘(三)
在安全審計系列的文章（一）和文章（二）中，我們介紹了審計數據庫的登入和登出，審計使用數據庫的源頭等。本文我們將介紹安全審計中的審計數據庫錯誤等內容。
審計數據庫錯誤
審計由數據庫返回的錯誤也是很重要的，它是你應實施的首個審計日志之一。從安全的觀點來看，這尤其重要。例如，在許多情況下，攻擊者會進行很多嘗試直至得逞。攻擊者可以使用基于UNION的攻擊，他需要猜測數據表的正確欄數，直到他得到正確的數字，數據庫將會不斷地返回一個錯誤代碼，表明SELECT語句所選擇的欄數不匹配。如果你記錄了所有的錯誤，就可以確認這種攻擊并做出響應。失敗的登錄是需要進行記錄和監視的錯誤之一，即使你并沒審計數據庫的登錄。最后，任何失敗的提升特權的試圖操作都表明攻擊正在發生。
從質量的觀點看，錯誤審計也很重要，它符合合規要求。我們應該確認并修復漏洞和應用程序錯誤，而記錄SQL錯誤通常是確認這些問題的一種簡單方法。因而，即使你關心的是安全問題，將這種信息提供給應用程序的所有者也很有意義，因為誰都不愿意運行存在著問題的代碼。幸運的話，這些錯誤甚至會向你指出那些影響響應時間和可用性的問題。
數據庫廠商都支持詳細的錯誤審計，你可以參考具體的數據庫環境指南。在Oracle中，你可以使用系統觸發器：
下一步，創建一個可用于新登錄的觸發器：
在SQL Server中，你可以使用審計特性或跟蹤特性。如果你選擇使用跟蹤特性，你需要使用sp_trace_event來建立與錯誤有關的正確事件。這包括下表所示的事件ID：
多種DB2事件監視器與錯誤審計相關，并且你必須使用這些事件類型。對于所需要的每一種類型，你都應當過濾那些與錯誤相關的記錄。例如，你應當為拒絕訪問（ACCESS DENIED ）記錄選擇檢查（CHECKING）記錄，并在VALIDATE類型中查看AUTHENTICATE_PASSWORD 和 VALIDATE_USER事件。
雖然在有些環境中，記錄錯誤和審計錯誤是可能的，但外部的審計系統更加普遍。如果你監視所有進入的SQL請求和響應，跟蹤和報告所有的錯誤是很簡單的，且不會給數據庫帶來任何額外負擔。可以使用任何一種標準集來報告錯誤，這種信息對于制定基準是很益的。
如果你的應用環境不太完善，制定基準就顯得很重要。不是每一個數據庫和應用環境都十全十美，在多數環境中，有些應用程序會產生數據庫錯誤，即使是在生產過程中也會如此。事實上，應用程序所產生的錯誤是重復性的：在大體相同的地方發生了相同的錯誤，這類錯誤往往是由缺陷引起的，且這些缺陷并不會發生改變。如果制定了錯誤基準，卻突然發現其它方面所產生的錯誤，或者你看到了完全不同的錯誤代碼，那么你該調查發生了什么問題。
存儲過程和觸發器的來源變更審計
由于數據庫木馬使用了靈活但卻完全過程化的編程語言，要隱藏惡意代碼是很容易的。因此，你應采取最佳方法來審計這些結構的所有變更。
有幾種方法可實現這種審計。最簡單的方法是基于配置控制的，可以通過定期（如每天）從數據庫中檢索代碼并將其與前一段時期所檢索的代碼相比較來實施這種審計。通過使用一些工具和腳本程序（如diff），這種方法相對易于實施。
第二種選擇是使用一個外部的數據庫安全和審計系統。這種系統可以實時地對創建或修改命令向管理員發出警告，并且很輕松地就生成可以詳細描述各種變化的報告，下圖顯示的就是觸發器的變更：
第三個選擇是使用內置的數據庫特性。例如，在SQL Server中，你可以使用Recompile事件來跟蹤對存儲過程的變更：
在多數數據庫環境中，這種特性是通過DDL審計來支持的，雖然從命令中析取源代碼并以一種易于審計的方式維持代碼并不容易。
【編輯推薦】
