Home » Migrating to Oracle Database 12c - what to do with auditing?
If you consider migrating to Oracle Database 12c, no matter if you think of development, testing or production environments, one of many decisions you need to take is to define what to do with the auditing. The biggest new feature in this area is so-called Unified Auditing, which captures auditing information from different sources, like for example "normal" and FGA audit records, application contexts, RMAN or DataPump plus few others and stores it in common format and place, which is read-only, partitioned table in AUDSYS schema, by default residing in SYSAUX tablespace and using Oracle SecureFiles feature.
Fortunately, Oracle gave us flexibility as regards available migration options. For example it is still possible in 12c to use traditional auditing, similarly as it is in 11g. There is even possibility to go for mixed mode auditing, in which both traditional and unified audit trails are populated. Of course using only unified approach is also possible. I would like to give you an overview of available features and changes, that hopefully will help you to take an appropriate decision on how to proceed with auditing in your environment.
All auditing initialization parameters used before (audit_trail, audit_file_dest, audit_sys_operations, audit_syslog_level) have no meaning (in case of using only unified auditing). Nevertheless, they are still available, as they’re needed for traditional and mixed modes.
Considering migrations, you also have to decide what to do with old audit records. Even when traditional auditing is disabled, there is still a possibility to archive and then purge audit records from traditional audit trails using dbms_audit_mgmt package, so it could be done before, during or after upgrade.
What should convince you that unified auditing is a significant improvement comparing to traditional approach?
Probably the most important advantage is embedded in word "unified" – the fact that all audit records are available through unified_audit_trail view and in case of multitenant environment in cdb_unified_audit_trail view, which provides audit records of every PDB (available in root only). It looks like Oracle has analysed all auditing options and features available in previous versions and designed unified auditing as more consistent, secure and easier to manage. Starting from 12c, you could forget about different handling of records located in aud$, fga_log$ or OS files. Still, when the database is not writeable (e.g. closed, mounted, opened read-only), audit records will be put to OS files (located in $ORACLE_BASE/audit/$ORACLE_SID, which unfortunately seems to be not changeable). It has to be done that way – it is crucial to audit operations like connecting as sysdba, but of course it cannot be persisted in non-writeable database. Fortunately, currently there is a possibility to load audit files located in this directory into the database using dbms_audit_mgmt.load_unified_audit_files procedure. Afterwards, they could be handled as other audit records, without the need of implementing dedicated parsers etc.
Speaking about easier auditing management, we have to remember not only about audit records handling, but also about configuring what should be audited. It is very different comparing to 11g - now it is defined in auditing policies. You could have many such policies defined and enable/disable them independently, but please keep in mind that according to Oracle documentation, number of audit policies enabled at the same time in the database should be limited (http://docs.oracle.com/cd/E16655_01/network.121/e17607/audit_config.htm#CHDBFCDG). Please look into audit_unified_policies and audit_unified_enabled_policies views to check your unified auditing configuration.
As you can find in $ORACLE_HOME/rdbms/admin/secconf.sql file, there are 3 default audit policies defined for new 12c installations: ora_account_mgmt, ora_database_parameter, ora_secureconfig. Only the last one is enabled by default, but it is good idea to clear the default configuration and use it as a starting point in designing your own auditing policy. While doing that, please keep in mind, that there is a number of activities mandatorily audited (http://docs.oracle.com/cd/E16655_01/network.121/e17607/audit_admin.htm#CHDHAEJD). Management in terms of access to audit data is also simplified, thanks to introducing two new roles, with self-descriptive names: audit_admin and audit_viewer.
If you are still not convinced to use unified auditing, it’s time to think about the performance. But this is material for another post... Stay tuned!