法律法規日益要求正規企業擴大稽核範圍，將 IT 資源納入其中。稽核人員尤其關心資料庫中與企業應用程式的管制資料，而 SOX、HIPAA、PC 和其他法規條例更要求實施最佳控制措施來保護敏感資料。
資料庫稽核人員必讀，資料庫稽核五大關鍵問題
作者/IMPERVA公司亞太區技術總監 周達偉
編輯/Ciphertech 亞利安科技 徐福祥
在資料庫稽核中，IT 專業人員必須對以下這五個問題做出回答，以據此檢查合規性：
1. 稽核過程與被稽核的資料庫系統是否相互獨立？
2. 稽核記錄是否設立了用戶責任？
3. 稽核記錄是否包含了適當的詳細資訊？
4. 稽核記錄是否識別異於活動基準的重大差異？
5. 稽核記錄的範圍是否足夠廣泛？
所採用的稽核機制不同，對這些問題的答案也隨之變化。遺憾的是，許多資料庫稽核機制在設計之初，並沒有考慮要滿足規章稽核人員的要求，因此也就不能對這些問題做出圓滿解答。本文將探討不同稽核機制在這些問題上的優缺點。其目的是要向讀者提供一些必要的資訊，使其在選擇要部署的稽核機制時，掌握充分的資訊，從而滿足合規性稽核的要求。
稽核是獨立的嗎？
為了確保稽核的公正性，整個稽核過程必須獨立於被稽核的 DB Server 和 DBA。由於 DBA 和 DB Server 均在被稽核的系統範圍之內，因此不應讓其對自身進行稽核。例如，一個能夠連線稽核記錄的惡意管理員可以輕易地篡改稽核記錄，從而掩蓋自己的行為。同樣，非管理員可以利用資料庫漏洞，提升自己的許可權並篡改稽核記錄。
獨立性對稽核系統的設計提出了3個要求：
1. 稽核責任應與資料庫管理相分離。
2. 稽核資料的收集應獨立於資料庫軟體自身功能。
3. 外部稽核方案可滿足獨立性，但更為重要的是要確保稽核不依賴於任何資料庫軟體自身功能。
責任人是誰？
資料庫稽核記錄必須將所稽核資料庫事務歸於特定用戶。例如，SOX 稽核機制要求必須記錄對財務報告資料的每個更改及執行此更改的用戶姓名。但是，當用戶 通過 Web 應用程式連線資料庫時，資料庫軟體自身稽核日誌根本無法獲知具體用戶。因此，即使自身稽核日誌發現欺騙性的資料庫事務，也無法找到責任用戶。稽核 Web 應用程式連線的問題在於用戶從不直接與資料庫進行交互。而是由 Web 應用程式採用一種稱為「池連接」的機制來代表用戶連線資料庫。Web 應用程式獨立驗證 每個用戶，然後將所有用戶通信合併為幾個只標識了該 Web 應用程式帳戶名稱的資料庫連接。由於根本沒有建立單個用戶的唯一連接，因此資料庫不會收到實際用 戶的任何身份資訊。通過避免對每個用戶進行驗證並為其建立唯一連接，Web 應用程式在性能上具備顯著優勢。但其結果是資料庫稽核記錄將所有活動都關聯到 Web 應用程式帳戶名，而這明顯違反稽核人員對責任的要求。怎樣才能消除這一盲點？
可考慮採用以下方法
1.重寫應用程式：
重寫 Web 應用程式和資料庫軟體是最容易想到，但也可能是最不切實際的解決用戶責任問題的方法。有兩種常用的重寫應用程式的方法也許可以採用：唯一帳戶和嵌入式引用。
唯一帳戶： 我們所考慮的第一種方法是重寫 Web 應用程式軟體，使每個用戶連線唯一的資料庫帳戶。這樣做的好處是，所有標準資料庫自身稽核工具均可在記錄每個事務的同時記錄相應的用戶名。但也存在一些問題：效能、用戶管理、第三方軟體的限制、成本、時間與風險。毫無疑問，為每個資料庫用戶建立唯一連接是不可取的。另一種方法是繼續使用池連接，但在每個資料庫請求中嵌入一個用戶標識引用。必須對資料庫重新編程，以在稽核記錄中加入嵌入式引用資訊。
2.專用資料庫解決方案：
一些資料庫平臺內置了可跟蹤應用程式用戶身份的機制。遺憾的是，為了將特殊資料庫請求包含到所有代碼模組中，這些機制仍然需要重寫Web應用程式。因 此，該方法具有前述大部分重寫缺點：第三方軟體限制、成本、時間進度和風險。此外，專用解決方案從根本上是特定於供應商的。因此，擁有多個資料庫供應商的 組織將無法解決涉及整個組織的問題，或者不得不設計和支持多個解決方案。
3.Web應用程式稽核資料：
一些組織試圖通過在資料庫稽核資料中補充 Web應用程式稽核資料來滿足資料庫責任稽核要求。例如，如果可疑資料庫事務來自於「應用程式帳戶」，則稽核人員可能會嘗試檢查具有相似時間戳的Web應用程式稽核資料，以識別破壞者。這個辦法聽起來不錯，但卻不容易實現。
稽核記錄是否包含了足夠的細節？
為了有效地重建以往資料庫事件，稽核人員需要詳細的稽核記錄資訊，詳細到準確的查詢和回應屬性這一級別。假設有下面2條稽核記錄，有關名叫「John」的客戶服務中心客服代理。
A. John 向客戶資料庫請求資料，資料庫返回資料。
B. John 向客戶資料庫請求所有客戶的姓、名、電子郵件位址、電話號碼和信用卡號，資料庫返回 634577 條記錄。假定在正常工作中，John 有權連線單個客戶記錄，則從第一條不甚詳細的稽核記錄
（例 A）中發現不了任何異常活動。但第二條較為詳細的稽核記錄
（例 B）則清楚地表明有可疑活動發生。因為沒有理由要連線 634577 位元客戶的個人資訊（包括信用卡號）。
若要徹底瞭解該事務，稽核記錄需要全部相關細節。
稽核系統能否識別重大差異？
對於稽核系統來說，僅提供按時間排列的所有資料庫事務的列表是不夠的。大多數資料庫環境會生成大量資訊，這會使這樣的系統根本無法用作識別欺詐活動的工 具。一個有效的稽核系統應提供事件優先順序視圖，能夠將重大差異與合法的或稱「基準」用戶活動分開。但是，多數自身稽核方案或外部稽核方案提供的是無優先 順序視圖，這迫使稽核人員進行代價高昂的手動日誌檢查處理。
稽核的範圍是否足夠廣泛？
資料庫稽核記錄的範圍應足夠廣泛，以識別欲利用資料庫平臺軟體（應用程式、作業系統等）或協定實現中存在的漏洞的任何企圖。SQL Slammer 漏洞和 Windows RPC 漏洞就是眾多此類漏洞的兩個代表，攻擊者曾利用這些漏洞對世界範圍內的資料庫基礎結構造成了嚴重破壞。我們需要專業的入侵防禦系統 (IPS) 和協議驗證方案來識別此類攻擊。因此，為了向稽核人員提供資料庫活動的完整情況，將從這些資料源收集來的資料整合到稽核記錄中是非常有必要的。合規性要求日益督促正規企業擴大稽核範圍，將 IT資源納入其中。稽核人員要求 IT 人員證明敏感資料庫系統滿足管理和使用的最佳做法要求。
Imperva 資料庫稽核解決方案
本文載於網路資訊 (Netoworking COmputing Magazine) 2008年3月刊