談一談Oracle11gR2的審計管理

談一談Oracle11gR2的審計管理

作者:趙全文 網名:guestart

  在Oracle數據庫的安全特性當中，審計被作為特別重要的一個方面。數據庫的審計功能主要是用來審計各種類型的DDL和DML語句，而審計管理作為一項新特性被引進到Oracle的11g R1版本當中，此時它的審計功能并不強大而且還有許多bug，然而到了11gR2時，已經修復了很多bug及它的審計功能進一步增強。

  今天我和大家分享一下，在Oracle 11gR2的版本中，有關審計的一些特性。出于美國安全法，Oracle在11g 的版本對審計管理的策略有所改變，初始化參數AUDIT_TRAIL的默認值為'DB'，也就是說把所有的審計數據都存放到AUD$表，而這個表又默認是在SYSTEM的表空間里。

  當我們在生產環境中部署一套Oracle數據庫以后，默認審計功能是開啟的，業務剛上線那段時間，數據量不大時，SYSTEM表空間的容量很寬裕，并沒有什么壓力。當業務運行了一段時間，突然有一天，前端應用就會反映說，數據庫特別慢。這時我們DBA對數據庫進行各種檢查，就會發現SYSTEM表空間的已用空間百分比為99.97%，這一點毫不夸張，我就親身經歷過。我們說這是事后救火，其實我們完全可以在上線前，把AUD$表遷移到其它的專門存放審計數據的表空間，在業務上線并運行一段時間之后，評估一下審計數據的數據量，然后設置審計數據的維護策略。

  下面，我們采取三種方法對Oracle數據庫的審計進行設置。嚴格的來說，是兩種方法，第一種更為粗暴，直接關閉審計功能，就是將初始化參數AUDIT_TRAIL的值設為'NONE'，然后重啟數據庫使之生效；第二種和第三種是針對開啟數據庫審計功能的維護管理。在生產環境中，不建議使用第一種，因為關閉審計以后，數據庫出現安全隱患以后不利于排查分析。為了大家有所了解，我也一并演示操作。

  首先，查看數據庫的版本，我所演示的環境為Oracle 11.2.0.4.0。

第一種方法，關閉審計功能。

第二種方法，把SYSTEM表空間里的AUD$表遷移到其它的表空間，以減輕SYSTEM表空間的壓力。

(1)查詢AUD$表所在的表空間

(2)查詢AUD$表的數據量有多少，發現竟然有80多G

(3)創建專門存放AUD$表的單獨的表空間AUDIT_TBS

(4)遷移AUD$表到新的表空間AUDIT_TBS

使用Oracle自帶的包DBMS_AUDIT_MGMT中的存儲過程SET_AUDIT_TRAIL_LOCATION來實現，該存儲過程接受2個參數，順序依次是AUDIT_TRAIL_TYPE和AUDIT_TRAIL_LOCATION_VALUE，參見官方文檔的如下截圖，

其中參數AUDIT_TRAIL_TYPE有以下幾種取值，見官方文檔的如下截圖，

各種取值的中文解釋如下：

AUDIT_TRAIL_ALL 所有的審計類型,包括標準數據庫審計、細粒度審計、操作系統審計和XML文件審計

AUDIT_TRAIL_AUD_STD 標準數據庫審計

AUDIT_TRAIL_DB_STD 標準數據庫審計和細粒度審計

AUDIT_TRAIL_FGA_STD 細粒度審計

AUDIT_TRAIL_FILES 操作系統和XML文件審計

AUDIT_TRAIL_OS 操作系統審計,審計數據存放在操作系統的文件里

AUDIT_TRAIL_XML XML文件審計,審計數據存放在XML文件里

在這里，我們使用標準數據庫審計，所以使用參數AUDIT_TRAIL_AUD_STD。

參數AUDIT_TRAIL_LOCATION_TYPE的取值是要遷移到的表空間的名字AUDIT_TBS，要執行的存儲過程如下圖所示，

從中發現，執行了將近一個小時，才遷移完成。

此時，AUDIT_TBS表空間已有數據，SYSTEM表空間已經釋放，壓力減輕。見下圖所示，

第三種方法，上面雖然減輕了SYSTEM表空間的壓力，但是如果不對審計數據進行定時清除和歸檔這種維護管理的話，新的表空間的容量也會有不足的時候，因此也需要不定期的擴充容量才可以。顯然，這也不是個完美的解決辦法。下面給審計設置維護策略， 6 / 12

(1)查詢AUD$表的數據開始生成的時間戳，現在是2017年2月8日，說明審計數據已保留了將近8個月。

(2)用Oracle自帶的包DBMS_AUDIT_MGMT中的存儲過程SET_AUDIT_TRAIL_PROPERTY設置審計的維護屬性,即每清除多少條數據提交一次。該存儲過程接受3個參數，順序依次是AUDIT_TRAIL_TYPE、AUDIT_TRAIL_PROPERTY和AUDIT_TRAIL_PROPERTY_VALUE。

其中參數AUDIT_TRAIL_TYPE的取值在第二種方法已說明，參數AUDIT_TRAIL_PROPERTY和AUDIT_TRAIL_PROPERTY_VALUE的取值見下面的官方文檔說明,

這里，我們使用參數AUDIT_TRAIL_TYPE的取值為AUDIT_TRAIL_AUD_STD，參數AUDIT_TRAIL_PROPERTY的取值為DB_DELETE_BATCH_SIZE，參數AUDIT_TRAIL_PROPERTY_VALUE的取值為10000。那么執行下面的存儲過程，

(3)用Oracle自帶的包DBMS_AUDIT_MGMT中的存儲過程INIT_CLEANUP設置審計數據保留的天數，該存儲過程接受2個參數，順序依次是AUDIT_TRAIL_TYPE和DEFAULT_CLEANUP_INTERVAL。見官方文檔的說明，其中參數DEFAULT_CLEANUP_INTERVAL的取值為1至999，單位為小時。

用Oracle自帶的包DBMS_AUDIT_MGMT中的存儲過程SET_LAST_ARCHIVE_TIMESTAMP設置上次歸檔審計記錄的時間戳，該存儲過程接受2個參數，順序依次是AUDIT_TRAIL_TYPE、LAST_ARCHIVE_TIME和RAC_INSTANCE_NUMBER。見官文檔的說明，參數RAC_INSTANCE_NUMBER取默認值NULL，可以不寫。

這里，我們設置審計數據保留的天數為30天，即720小時，上次歸檔審計記錄的時間戳為30天之前。那么執行下面的存儲過程，

(4)用Oracle自帶的包DBMS_AUDIT_MGMT中的存儲過程CREATE_PURGE_JOB設置每隔多長時間清除審計數據的JOB，該存儲過程接受4個參數，順序依次是AUDIT_TRAIL_TYPE、AUDIT_TRAIL_PURGE_INTERVAL、AUDIT_TRAIL_PURGE_NAME和USE_LAST_ARCH_TIMESTAMP。見官方文檔的說明，

這里，我們每隔7天，即168小時清除一次審計數據，那么設參數AUDIT_TRAIL_PURGE_INTERVAL的值為168，設參數USE_LAST_ARCH_TIMESTAMP的值為TRUE(也是默認值)。那么執行下面的存儲過程，

同時，在EMCC 12C的監控界面下已經看到一個名叫“PURGE_AUD_STD”的JOB在運行，還有相應的SQL也在運行。見下圖，

  由于上次以來沒有進行審計清理，現在保留了近8個月的數據，所以現在一次清理，只保留30天的數據會稍顯費時。不過執行完這次JOB，以后再清理歷史數據就不費吹灰之力了。

  上面就把三種維護審計的方法都介紹完了，我們演示的只是將審計數據保存在DB里，其實還可以保存在OS和XML里，不過我不建議這樣做，按照官方文檔來說，保存在DB里由Oracle進行維護會減少和OS通信的IO操作。

總結:

1.直接關閉審計，修改初始化參數AUDIT_TRAIL的值為NONE，并重啟數據庫生效；

2.將SYSTEM表空間中的AUD$表遷移到其它的表空間，以減輕SYSTEM表空間的壓力；

3.在第2種方法的基礎上，設置審計數據保留天數并定時清除過期的審計數據。

另外，本文在編寫過程中，參考了以下網址，特別說明

官方文檔 https://docs.oracle.com/cd/E18283_01/appdev.112/e16760/d_audit_mgmt.htm#BABDAHBG

oraclewiki http://www.oracle-wiki.net/startdocshowtomanageaudit

Laurent Leturgez https://laurent-leturgez.com/2011/06/09/managing-database-audit-trail-in-oracle-11gr2/

Suresh Karthikeyan https://www.pythian.com/blog/oracle-database-script-to-purge-aud-table-using-dbms_audit_mgmt-package/

  如果您覺得此篇文章對您有幫助，歡迎關注微信公眾號：guestart的DBA學習筆記，您的支持是對我最大的鼓勵！