最近遇到一些腳本誘發的審計相關BUG,感受有必要從新梳理一下11g與12c的審計模式,因而根據官網修正了一下之前的一篇筆記這裏發出來。html
1、審計功能的開啓:python
SQL> show parameter audit
--主要有如下四個參數:
AUDIT_TRAIL(default:DB)
AUDIT_FILE_DEST(default:ORACLE_BASE/admin/ORACLE_SID/adump or ORACLE_HOME/rdbms/audit)
AUDIT_SYS_OPERATIONS(default:FALSE)
AUDIT_SYSLOG_LEVEL(no default)
audit_trail參數的值能夠設置爲如下幾種(11G,12C適用):
sql
https://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams017.htm#REFRN10006數據庫
1. none --不開啓
2. os --啓用數據庫審計,並將數據庫審計記錄定向到操做系統文件,存儲目錄爲AUDIT_FILE_DEST
3. db --開啓審計功能 啓用數據庫審計,並將數據庫全部審計記錄定向到數據庫的SYS.AUD$表
5. db, extended --extened以前的空格必須有,啓用數據庫審計,並將數據庫全部審計記錄定向到數據庫的SYS.AUD$表,另外填充SYS.AUD$表的SQLBIND列和SQLTEXT列
6. xml --相似os,可是是將審計記錄存放於XML格式的文件中
7. xml, extended --將審計記錄存放於操做系統的xml文件中並填充sql_text和sql_bind信息
#此參數沒法動態修改,所以須要重啓數據庫才能生效,示例:
alter system set AUDIT_TRAIL=db scope=spfile;
#對於db和db, extended兩種審計模式,若是數據庫是read-only模式的,那麼數據庫默認使用os審計模式,無視已有設置(由於不能向數據庫表寫入數據)。
AUDIT_SYS_OPERATIONS設置爲true那麼sys用戶的操做也會被審計,但此值默認爲false,此參數控制以sysdba和sysoper權限登錄的用戶以及sys用戶自己的登錄,審計記錄必定會寫在操做系統文件中(不管AUDIT_TRAIL參數如何設置)。安全
AUDIT_SYSLOG_LEVEL則表示當涉及到向操做系統文件寫入審計記錄時,直接寫入到系統日誌中而不是AUDIT_FILE_DEST(僅適用於類unix系統)。oracle
--Oracle Database audits the following privileges by default: ALTER ANY PROCEDURE CREATE ANY LIBRARY DROP ANY TABLE ALTER ANY TABLE CREATE ANY PROCEDURE DROP PROFILE ALTER DATABASE CREATE ANY TABLE DROP USER ALTER PROFILE CREATE EXTERNAL JOB EXEMPT ACCESS POLICY ALTER SYSTEM CREATE PUBLIC DATABASE LINK GRANT ANY OBJECT PRIVILEGE ALTER USER CREATE SESSION GRANT ANY PRIVILEGE AUDIT SYSTEM CREATE USER GRANT ANY ROLE CREATE ANY JOB DROP ANY PROCEDURE --Oracle Database audits the following SQL statement shortcuts by default: ROLE SYSTEM AUDIT PUBLIC SYNONYM DATABASE LINK PROFILE SYSTEM GRANT --此外經過audit命令指定的審計也是標準審計。
標準審計記錄存儲在SYS.AUD$表中,精細審計的記錄存放於SYS.FGA_LOG$表中,分別能夠經過DBA_AUDIT_TRAIL和DBA_FGA_AUDIT_TRAIL查看標準和精細審計的審計記錄。spa
兩種審計模式還有一個共同的視圖能夠看:DBA_COMMON_AUDIT_TRAIL,包含了標準+精細審計的記錄。操作系統
truncate table aud$; --能夠截斷相關表,清理審計數據。
查看dba_common_audit_trail(包含標準和精細審計的記錄)能夠看到記錄的主要字段包含:線程
SESSION_ID:並不是是真正的會話id,應該只是一個審計的會話ID標識,反正與當前會話的ID對不上。
記錄生成時間
DB_USER、OS_USER、USERHOST
OS_PROCESS:服務端對應的server process的系統進程ID,若是帶冒號:,冒號後邊的是線程ID
RETURNCODE:服務端的返回錯誤碼,好比密碼驗證失敗就會顯示1017的錯誤碼,即ORA-1017:"invalid username/password; logon denied"
COMMENT_TEXT:若是是遠程登陸還會包含客戶端鏈接使用的TNS信息,包括使用的端口號
LOGOFF_TIME:會話登出時間
LOGOFF_LREAD、LOGOFF_PREAD、LOGOFF_LWRITE、LOGOFF_DLOCK:會話期間的邏輯讀、物理讀、物理寫、死鎖次數
ACTION:審計記錄對應的操做號
STATEMENT_TYPE:審計記錄對應的操做號表示的具體操做,也能夠用過查詢audit_actions視圖來獲取action與STATEMENT_TYPE的對應關係
提示:設計
12c中的unified審計記錄不在AUD$表中,而是存儲在AUDSYS schema下,能夠經過AUDSYS.UNIFIED_AUDIT_TRAIL表查詢,開啓unified審計後傳統的AUD$和dba_common_audit_trail等再也不包含任何審計記錄。
3、關於精細審計(fine-grained auditing):
https://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG525
若是想要細粒度的審計某個schema下針對某個表的某些數據的操做記錄,能夠開啓精細審計,這容許你設計很細粒度的策略,例如創造一個fga策略以下:
--查看相關包的用法:
desc DBMS_FGA;
BEGIN
DBMS_FGA.ADD_POLICY(
OBJECT_SCHEMA=>'HR',
OBJECT_NAME =>'EMPLOYEES',
POLICY_NAME =>'SAL_AUD',
AUDIT_CONDITION =>'SALARY>3000',
AUDIT_COLUMN =>'SALARY',
ENABLE=>TRUE,
STATEMENT_TYPES=>'SELECT,UPDATE');
END;
--在sqlplus 中直接/執行,或者做爲存儲過程在plsql中exec dbms_fga.add_policy(...........);
查看精細審計策略:
DESC dba_audit_policies;
--查看已建立的精細審計策略
SELECT OBJECT_NAME,POLICY_NAME,ENABLED FROM DBA_AUDIT_POLICIES;
刪除精細策略:
begin
dbms_fga.drop_policy (
object_schema=>'HR',
object_name=>'TEST',
policy_name=>'SAL_AUD');
end;
/
4、查看審計記錄:
DBA_COMMON_AUDIT_TRAIL:https://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_3077.htm#REFRN23393
desc dba_common_audit_trail;
--示例:12c以前查看由於密碼驗證失敗的審計記錄:
select
EXTENDED_TIMESTAMP,DB_USER, OS_USER, USERHOST, COMMENT_TEXT
from dba_common_audit_trail
where
DB_USER = 'EASYITS'
and RETURNCODE = 1017
and EXTENDED_TIMESTAMP between
to_timestamp('2019-04-18 21:30:00', 'YYYY-MM-DD HH24:MI:SS') and
to_timestamp('2019-04-18 22:30:00', 'YYYY-MM-DD HH24:MI:SS');
5、12c審計:
官網參考:
12c的傳統審計(即11g裏的標準審計和精細審計):
12c的unified審計:
12c中新引入的審計機制名爲unified audit,你能夠將其理解爲一種更加輕便的精細審計。
咱們知道在12c以前想要使用精細審計就要用dbms_fga包去建立審計策略,想要使用標準審計就要用audit語句去審計特定的權限和SQL,相關的視圖也很是多,這致使審計策略的管理很是混亂,audit的語法也很是的反人類。而12c的unified audit則對設置審計策略的方式作了統一和簡化,只須要使用如下三種語句來設置審計策略就能夠了:
而開啓和關閉審計策略也極簡,只須要使用簡單的audit和noaudit語句:
audit policy <policy_name>;
noaudit policy <policy_name>;
能夠看到咱們只要熟悉建立/修改審計策略的語法就能夠了。
至於原有的標準審計和精細審計的建立模式,12c中依然保留,在混合審計模式下你依然可使用dbms包建立精細審計,audit命令也保留着建立標準審計的語法。
Unified審計模式的開啓:
12c的Unified Auditing參數默認爲false:
select parameter,value from v$option where parameter='Unified Auditing';
這種默認設置表示既支持12c以前的那種標準+精細的傳統審計模式,也可使用unified審計模式,這種默認的模式也被稱做混合審計模式(mixed)。
而若是開啓unified audting,那麼傳統審計模式就會被禁用,audit_trail參數被忽略,AUD$和FGA_LOG$等相關表再也不新增任何審計記錄,只能在AUDSYS.UNIFIED_AUDIT_TRAIL中看到unified審計的記錄。
如何開啓unified審計?
SQL> shutdown immediate;
ORACLE instance shut down.
SQL> host ( cd $ORACLE_HOME/rdbms/lib ; make -f ins_rdbms.mk uniaud_&2 ioracle ORACLE_HOME=$ORACLE_HOME )
12c混合審計模式下的審計表現:
咱們知道11g中,只要audit_trail不爲none,那麼數據庫會默認審計一些操做,例如logon,logout和涉及數據庫安全的操做等。而在12c中系統也預設了一些unified審計策略,能夠經過AUDIT_UNIFIED_ENABLED_POLICIES視圖查看已生效的審計策略,經過AUDIT_UNIFIED_POLICIES能夠查看全部預設審計策略。
12c的混合模式下,對於11g中那些標準審計默認審計的審計項們也依然進行審計,只不過方式變了,變爲了經過默認開啓一些unified審計策略來進行這些默認審計(DBA_STMT_AUDIT_OPTS也再也不包含記錄)。咱們能夠看一下這些默認開啓的審記策略:
select * from AUDIT_UNIFIED_ENABLED_POLICIES;
以上爲12c中默認開啓的審計策略,其中ORA_LOGON_FAILURES在12.1.0.2之後被從ORA_SECURECONFIG獨立出來,而且只審計失敗的登陸.
而從AUDIT_UNIFIED_POLICIES視圖能夠看出ORA_SECURECONFIG其實就包含了之前的那些默認標準審計項。
混合模式下不管是傳統審計記錄,仍是經過預設的unified auditing policy進行的默認審計,其審計記錄在dba_common_audit_trail中均可以查看。