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.
No matter which mode you would like to use after the migration, it is good idea to enable unified auditing at the very beginning, by relinking database binaries with parameter uniaud_on. This will let you avoid unavailability, if you decide to go for unified (or mixed-mode) auditing at a later stage. Please use following query to find if it is properly enabled:
SQL> select parameter, value from v$option where parameter = 'Unified Auditing'; PARAMETER VALUE ----------------------- ---------- Unified Auditing TRUE
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.
Another small, but very nice enhancement is that in 12c users are not allowed to configure auditing for objects in their own schemas (without any additional privileges), so possibility of local DOS attack, when malicious user configures auditing of his own table and then generate big number of audited actions on it, is much lowered. Security is also enhanced, by the fact that with unified auditing is now allowed to audit all tables, unlike in 11g:
-- 11g
SQL> audit all on sys.user$;
audit all on sys.user$
*
ERROR at line 1:
ORA-00701: object necessary for warmstarting database cannot be altered
Looking from security point of view, this was quite big limitation, which currently, as a result of complete redesign of auditing in 12c, has been lifted. For example:
-- 12c SQL> create audit policy test_pol actions all on sys.user$; Audit policy created. SQL> audit policy test_pol; Audit succeeded.
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!