谈一谈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学习笔记，您的支持是对我最大的鼓励！
