Architecture Overview

Auditing is always about accountability, and is frequently done to protect and preserve privacy for the information stored in databases. Concern about privacy policies and practices has been rising steadily with the ubiquitous use of databases in businesses and on the Internet. Oracle Database provides a depth of auditing that readily enables system administrators to implement enhanced protections, early detection of suspicious activities, and finely-tuned security responses.

Unified and Conditional Auditing

Oracle Database 12c Unified Auditing enables selective and effective auditing inside the Oracle database using policies and conditions. The new policy based syntax simplifies management of auditing within the database and provides the ability to accelerate auditing based on conditions. For example, audit policies can be configured to audit based on specific IP addresses, programs, time periods, or connection types such as proxy authentication. In addition, specific schemas can be easily exempted from auditing when the audit policy is enabled.

New roles have been introduced for management of policies and the viewing of audit data. The AUDIT_ADMIN and AUDIT_VIEWER roles provide separation of duty and flexibility to organizations who wish to designate specific users to manage audit settings and view audit activity. The new architecture unifies the existing audit trails into a single audit trail, enabling simplified management and increasing the security of audit data generated by the database. Audit data can only be managed using the built-in audit data management package within the database and not directly updated or removed using SQL commands. Three default policies are configured and shipped out of the box. Oracle Audit Vault and Database Firewall 12.1.1 is integrated with the new Oracle Database 12c Unified Auditing for audit consolidation. Please refer to the Oracle documentation for additional details on auditing with the Oracle database.

Traditional Database Auditing

Oracle Database provides robust audit support in both the Enterprise and Standard Edition of the database. Audit records include information about the operation that was audited, the user performing the operation, and the date and time of the operation. Audit records can be stored in the database audit trail or in files on the operating system. Standard auditing includes operations on privileges, schemas, objects, and statements.

Oracle recommends that the audit trail be written to the operating system files as this configuration imposes the least amount of overhead on the source database system. To enable database auditing, the initialization parameter, AUDIT_TRAIL, should be set to one of these values:

AUDIT_TRAIL settings
Parameter Value Meaning
DB Enables database auditing and directs all audit records to the database audit trail (SYS.AUD$), except for records that are always written to the operating system audit trail
DB,EXTENDED Does all actions of AUDIT_TRAIL=DB and also populates the SQL bind and SQL text columns of the SYS.AUD$ table
XML Enables database auditing and directs all audit records in XML format to an operating system file
XML,EXTENDED Does all actions of AUDIT_TRAIL=XML, adding the SQL bind and SQL text columns
OS (recommended) Enables database auditing and directs all audit records to an operating system file

In addition, the following database parameters should be set:

  • init.ora parameter: AUDIT_FILE_DEST — Dynamic parameter specifying the location of the operating system audit trail. The default location on Unix/Linux is $ORACLE_BASE/admin/$ORACLE_SID/adump. The default on Windows is the event log. For optimal performance, it should refer to a directory on a disk that is locally attached to the host running the Oracle instance.
  • init.ora parameter: AUDIT_SYS_OPERATIONS — Enables the auditing of operations issued by user SYS, and users connecting with SYSDBA, SYSOPER, SYSASM, SYSBACKUP, SYSKM and SYSDG privileges. The audit trail data is written to the operating system audit trail. This parameter should be set to true.

For more information and best practices on Oracle Database Auditing please read the best practices paper on the Oracle Audit Vault OTN page. Detailed information on database auditing can be found in the introductory Oracle Database 2 Day + Security Guide and the Oracle Database Security Guide.