2011年隨著個人資料保護法及施行細則草案的公佈，廠商在很多場合提出各種因應方案，當然不乏存放最多資料的儲存地資料庫，隨著上路時間逼近，眼尖的你在後期的研討會上應該有發現，「資料庫稽核(DB Audit )」解決方案已正名成「資料庫行為監控(DAM)」。這意味著廠商希望能呼應企業對資料庫安全的需求，已從只做事後的稽核延伸為能做更多即時的監控。
需要第三方資料庫行為監控工具的8個理由
企業在開始評估資料庫行為監控之前，或許會認為資料庫原有日誌稽核功能(Audit Log)，開啟不就得了？根本不需要解決產品。日誌稽核功能主要是做為短期協助資料庫管理師查找問題的輔助工具，資料庫原廠多半預設關閉該功能，主要是啟動資料庫原生日誌後耗用主機資源過多，往往系統無法負荷造成營運停擺，通常也不建議長時間啟用；另一點因為資料庫管理師擁有刪除日誌稽核權限，只要抓準時間就能船過水無痕。稽核過程中，有個問題，你應該也不陌生，如何搬出現行規章、管理辦法來幫資料庫管理師自清？這是有相當難度的。其實在個人資料保護法三讀通過前，國外就發展出資料庫行為監控產品。
因此，企業在決定是要評估第三方工具，或者利用資料庫預設功能自行開發加工，可以先思考以下8個問題：
1.資料庫管理師擁有開啟與關閉日誌稽核功能，也具有刪除日誌稽核權限，如何證明日誌稽核完整度？
2.原有日誌稽核功能(Audit Log) 無法真正判別共用帳號存取行為。
3.日誌稽核功能長時間開啟下，當設備規格不足夠時，系統無法承擔負荷造成營運停擺，是否有因應措施？
4.在每一個需受保護的Table借用Trigger記錄存取行為，多個應用程式存取邏輯是否能一次掌握。
5.若自行開發，集中多份稽核記錄，萃取出可用的人、事、時、地、物，所花費的人力、時間不會小於建立一個資料倉儲系統。
6.Trigger運作時，Transaction Log 至少會暴增兩倍，資料成長空間無法預估，如何控管營運風險？
7.自行開發稽核程式無法完整監控，如何優化效能及一致性控管保護？
8.日誌稽核資訊不足無法自清，如同自行開發Oracle程式，透過SQL TRACE 進行SQL跟蹤，也僅能監控通過v$session的登入與登出的時間，範例請參考表1。
上述8個問題，以第1.3.7點最為關鍵。尤其若以法規遵循為前提下，如何證明相關日誌稽核記錄未被擁有權限
的資料庫管理師竄改，這正是第三方工具發揮作用的地方。
表1、下面範例程式碼說明自行開發搭配資料庫預設功能只能監控到某一部份的登出入
|
一、建立 audit table,
$ sqlplus / as sys資料庫管理師
SQL> create table userlog
2 (
3 user_id varchar2(30),
4 session_id number(8),
5 host varchar2(20),
6 logon_time varchar2(20),
7 logoff_time varchar2(20));
二、建立 login trigger:
SQL> create or replace trigger logon_audit
2 after logon on database
3 begin
4 insert into userlog values
5 (
6 user,
7 sys_context(''USERENV'',''SESSIONID''),
8 sys_context(''USERENV'',''HOST''),
9 to_char(sysdate,''hh24:mi:ss''),
10 null);
11 end;
12 /
三、建立 logoff trigger
SQL> create or replace trigger logoff_audit
2 before logoff on database
3 begin
4 update userlog set
5 logoff_time=to_char(sysdate,''hh24:mi:ss'')
6 where sys_context(''USERENV'',''SESSIONID'') = session_id;
7 end;
8 /
===============================================================
進行測試: (使用 hr 與 scott 登入與登出)
[oracle@db11gr2 ~]$ sqlplus hr/hr
SQL*Plus: Release 11.2.0.2.0 Production on Tue Aug 7 21:30:07 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@db11gr2 ~]$ sqlplus scott/tiger
SQL*Plus: Release 11.2.0.2.0 Production on Tue Aug 7 21:30:11 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
==================================================================
檢查 userlog 所記錄的 audit 資訊:
SQL> select * from userlog order by user_id;
USER_ID SESSION_ID HOST LOGON_TIME LOGOFF_TIME
HR 180405 db11gr2 21:29:42 21:30:05
HR 180406 db11gr2 21:30:07 21:30:08
HR 180403 db11gr2 21:29:29 21:29:31
SCOTT 180404 db11gr2 21:29:35 21:29:42
SCOTT 180407 db11gr2 21:30:11 21:30:12
SYS 0 db11gr2 21:32:12
SYS 0 db11gr2 21:26:12
SYS 0 db11gr2 21:30:12
SYS 0 db11gr2 21:28:12
SYS 0 db11gr2 21:27:12
SYS 0 db11gr2 21:31:12
SYS 0 db11gr2 21:29:12
SYS 0 db11gr2 21:31:12
註：程式碼由高宇駿提供
|
PoC驗證須留意的功能
DAM解決長久以來無法長時間開啟資料庫原生日誌稽核功能、獨立監控下權責分工問題，並可利用監控記錄追蹤溯源，協助追查事件原因與界定責任，降低安全管理上的複雜性等。評估實務上得回頭來看，在PoC驗證導入過程中，需要留意以下細節：
1. 事先定義監控對象，外網來的請求、內網來的請求、應用程式端來的請求、資料庫本機端來的請求。
2. 需要即時還是非即時追查異常原因？要觀察DAM正規化儲存監控記錄時間。
3. 一般設備都會受到實體安全的保護，如果有特殊作業時會由本機端發起請求，這時得考量代理程式資源耗用程度，才能在不影響資料庫主機本體下進行行為監控。
4. 全都錄方式監控好處是不會遺漏，資料庫活動變動性很大，驗證時上正式區實際量測，才能估算出正確的儲存空間。
5. 可由人為介入程序來判斷設備安全。
6. 加密連線是否可解析。
7. 監控記錄至少要含來源IP、Hostname、來源應用程式名稱、資料庫帳號、目標資料庫、完整SQL指令與資料庫回傳時間、錯誤訊息等資訊。
8. 靈活度高的SQL會使用內嵌變數，因此需能解析「SQL使用內嵌變數」才能了解指令執行後的影響範圍。
9. 進行AP User Tracking大多需要改寫應用程式，以SQL Dummy來做辨別，這種方法誤判率最低。知名ERP大廠與BI系統，目前有些DAM已有內建支援，僅需要在設備上設定相關參數即可。
10. 遮罩功能會利用 Buffer 運作，但會有Masking筆數限制，且欄位內容格式需固定。目前大都無法Masking中文，還是找專門Masking工具做專門的事效果比較好。
11. 異動前後記錄。現有原理採用資料庫Trigger模式但需要在資料庫監控主機上新建專屬資料庫，資源耗用程度及空間無法估算，也有可支援Oracle資料庫，但筆者認為還是自行開發應用程式留存異動前後記錄，會比較理想。
12. 在不熟悉Table內容時，一般會下不限定欄位及條件，進行短時間的存取，來了解Table結構。因此調閱功能應提供多種複雜的查詢過濾條件，以幫助產出正確資訊。
13. 可以留意多筆指令一起執行中間無go或分號時，是否自動分割指令。此外，統計數值應求一目了然，監控記錄除了能自動分割指令，要能逐筆列示。
14. 定義不同權限產製不同報表內容，驗證資料正確性。
15. Mail 發送是否有限定條件。
面對市場上琳瑯滿目的DAM解決方案，除了上述功能在PoC過程中需實際驗證外。以下幾點也是在評估過程中，需特別注意的：
1)訂定管理方針。一個成功的資料庫行為監控專案一定要在先前有完善的管理政策，工具才能有效發揮，建議可參考支付卡產業資料安全標準(PCI DSS) 。
2)資料庫支援版本。通常企業內擁有多種不同類型資料庫，但基於預算考量會先就重要系統開始分批佈署，因此需要特別考量資料庫支援版本，以避免重複投資，最後監控記錄無法集中，徒增管理複雜度。
3) stored procedure往往功能強大，且資料庫運行中會經過編譯，可利用監控到的執行時間來判斷是否有異常行為，但也因為編譯後無法得知內容，在管理上要特別控管stored procedure上版作業及一致性比對。
4)啟用阻擋功能拒絕異常存取。這取決於企業的資料庫提供服務時間，如果提供服務時間固定，可以設定直接阻擋，儘可能的不提供服務。
一套DAM所費不貲，要達到最佳投資報酬以及獲得全面性的保護，首先要清楚欲保護的重要資訊資產有哪些，並搭配管理面加強帳號密碼強度界定使用權限，以及長時間不定期檢視和追蹤，才有其效果。此外，現今的資安事件多半採用多層次、多面向的複合式攻擊手法，資料庫行為監控(DAM)屬末端防護設備，記載的資料量非常大，除了平時自行查看監視外，當資安事件發生欲追蹤溯源時，需要資安監控中心或前端防護設備（例如，防火牆、應用程式防火牆、IPS、DLP等），提供可疑的時間或IP，就可幫助加速追查原因與協助界定責任。
本文作者任職金融業，具系統開發、安控專長。如有任何問題，歡迎來信交流isnews@newera.messefrankfurt.com