最近遇到一些脚本诱发的审计相关BUG，感觉有必要重新梳理一下11g与12c的审计模式，于是根据官网修正了一下以前的一篇笔记这里发出来。
一、审计功能的开启：
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适用）：
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系统）。
- 标准审计：主要记录一些涉及数据库安全性的SQL操作和权限变更等，官网列出的默认标准审计项包含如下操作（通过DBA_STMT_AUDIT_OPTS查看）：
--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命令指定的审计也是标准审计。
- 精细审计：提供非常细粒度的审计，例如可以使你审计针对某个表的某些字段在某一段时间内的某种DML操作，还可以限定客户端的IP等。
标准审计记录存储在SYS.AUD$表中，精细审计的记录存放于SYS.FGA_LOG$表中,分别可以通过DBA_AUDIT_TRAIL和DBA_FGA_AUDIT_TRAIL查看标准和精细审计的审计记录。
两种审计模式还有一个共同的视图可以看：DBA_COMMON_AUDIT_TRAIL，包含了标准+精细审计的记录。
truncate table aud$; --可以截断相关表，清理审计数据。
查看dba_common_audit_trail（包含标准和精细审计的记录）可以看到记录的主要字段包含：
SESSION_ID：会话ID，并非实际数据库会话的id，应该只是一个自增的ID
EXTENDED_TIMESTAMP：记录生成时间
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等不再包含任何审计记录。
三、关于精细审计（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;
/
四、查看审计记录：
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');
五、12c审计：
官网参考：
12c的传统审计（即11g里的标准审计和精细审计）：
12c的unified审计：
12c中新引入的审计机制名为unified audit，你可以将其理解为一种更加轻便的精细审计。
我们知道在12c之前想要使用精细审计就要用dbms_fga包去创建审计策略，想要使用标准审计就要用audit语句去审计特定的权限和SQL，相关的视图也非常多，这导致审计策略的管理非常混乱，audit的语法也非常的反人类。而12c的unified audit则对设置审计策略的方式做了统一和简化，只需要使用以下三种语句来设置审计策略就可以了：
- create audit policy (unified auditing)
- alter audit policy (unified auditing)
- drop audit policy (unified auditing)
而开启和关闭审计策略也极简，只需要使用简单的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 lsnrctl stop
--如果有EM启用，那么暂时关闭：emctl stop oms
SQL> host ( cd $ORACLE_HOME/rdbms/lib ; make -f ins_rdbms.mk uniaud_on ioracle )
--同样的关闭方式就是：make -f ins_rdbms.mk uniaud_off ioracle
SQL> startup
SQL> select * from v$option where PARAMETER = 'Unified Auditing';
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中都可以查看。