21 Introduction to Auditing

What Is Auditing?

Auditing is the monitoring and recording of configured database actions, from both database users and nondatabase users^Foot 1 . You can base auditing on individual actions, such as the type of SQL statement executed, or on combinations of data that can include the user name, application, time, and so on.

You can configure auditing for both successful and failed activities, and include or exclude specific users from the audit. In a multitenant environment, you can audit individual actions of the pluggable database (PDB) or individual actions in the entire multitenant container database (CDB). In addition to auditing the standard activities the database provides, auditing can include activities from Oracle Database Real Application Security, Oracle Recovery Manager, Oracle Data Pump, Oracle Data Mining, Oracle Database Vault, Oracle Label Security, and Oracle SQL*Loader direct path events.

Auditing is enabled by default. All audit records are written to the unified audit trail in a uniform format and are made available through the UNIFIED_AUDIT_TRAIL view. These records reside in the AUDSYS schema. The audit records are stored in the SYSAUX tablespace by default. Oracle recommends that you configure a different tablespace for the unified audit trail. Be aware that for most Oracle Database editions except for Enterprise Edition, you can only associate the tablespace for unified auditing once. You should perform this association before you generate any audit records for the unified audit trail. After you have associated the tablespace, you cannot modify it because partitioning is only supported on Enterprise Edition.

You can configure auditing by using any of the following methods:

• Group audit settings into one unified audit policy. You can create one or more unified audit policies that define all the audit settings that your database needs. "Auditing Activities with Unified Audit Policies and the AUDIT Statement" describes how to accomplish this.

• Use one of the default unified audit policies. Oracle Database provides three default unified audit policies that encompass the standard audit settings that most regulatory agencies require. See "Auditing Activities with the Predefined Unified Audit Policies".

• Create fine-grained audit policies. You can create fine-grained audit policies that capture data such as the time an action occurred. See "Auditing Specific Activities with Fine-Grained Auditing".

Oracle recommends that you audit your databases. Auditing is an effective method of enforcing strong internal controls so that your site can meet its regulatory compliance requirements, as defined in the Sarbanes-Oxley Act. This enables you to monitor business operations, and find any activities that may deviate from company policy. Doing so translates into tightly controlled access to your database and the application software, ensuring that patches are applied on schedule and preventing ad hoc changes. By creating effective audit policies, you can generate an audit record for audit and compliance personnel. Be selective with auditing and ensure that it meets your business compliance needs.

Why Is Auditing Used?

You typically use auditing to monitor user activity.

Auditing can be used to accomplish the following:

• Enable accountability for actions. These include actions taken in a particular schema, table, or row, or affecting specific content.

• Deter users (or others, such as intruders) from inappropriate actions based on their accountability.

• Investigate suspicious activity. For example, if a user is deleting data from tables, then a security administrator can audit all connections to the database and all successful and unsuccessful deletions of rows from all tables in the database.

• Notify an auditor of the actions of an unauthorized user. For example, an unauthorized user could be changing or deleting data, or the user has more privileges than expected, which can lead to reassessing user authorizations.

• Monitor and gather data about specific database activities. For example, the database administrator can gather statistics about which tables are being updated, how many logical I/Os are performed, or how many concurrent users connect at peak times.

• Detect problems with an authorization or access control implementation. For example, you can create audit policies that you expect will never generate an audit record because the data is protected in other ways. However, if these policies generate audit records, then you will know the other security controls are not properly implemented.

• Address auditing requirements for compliance. Regulations such as the following have common auditing-related requirements:

  • Sarbanes-Oxley Act

  • Health Insurance Portability and Accountability Act (HIPAA)

  • International Convergence of Capital Measurement and Capital Standards: a Revised Framework (Basel II)

  • Japan Privacy Law

  • European Union Directive on Privacy and Electronic Communications

Best Practices for Auditing

You should follow best practices guidelines.

• As a general rule, design your auditing strategy to collect the amount of information that you need to meet compliance requirements, but focus on activities that cause the greatest security concerns. For example, auditing every table in the database is not practical, but auditing tables with columns that contain sensitive data, such as salaries, is. With both unified and fine-grained auditing, there are mechanisms you can use to design audit policies that focus on specific activities to audit.

• Periodically archive and purge the audit trail data. See "Purging Audit Trail Records" for more information.

What Is Unified Auditing?

In unified auditing, the unified audit trail captures audit information from a variety of sources.

• Audit records (including SYS audit records) from unified audit policies and AUDIT settings

• Fine-grained audit records from the DBMS_FGA PL/SQL package

• Oracle Database Real Application Security audit records

• Oracle Recovery Manager audit records

• Oracle Database Vault audit records

• Oracle Label Security audit records

• Oracle Data Mining records

• Oracle Data Pump

• Oracle SQL*Loader Direct Load

The unified audit trail, which resides in a read-only table in the AUDSYS schema in the SYSAUX tablespace, makes this information available in a uniform format in the UNIFIED_AUDIT_TRAIL data dictionary view, and is available in both single-instance and Oracle Database Real Application Clusters environments. In addition to the user SYS, users who have been granted the AUDIT_ADMIN and AUDIT_VIEWER roles can query these views. If your users only need to query the views but not create audit policies, then grant them the AUDIT_VIEWER role.

When the database is writeable, audit records are written to the unified audit trail. If the database is not writable, then audit records are written to new format operating system files in the $ORACLE_BASE/audit/$ORACLE_SID directory.

Benefits of the Unified Audit Trail

The benefits of a unified audit trail are many.

• After unified auditing is enabled, it does not depend on the initialization parameters that were used in previous releases. See Table G-1 for a list of these initialization parameters.

• The audit records, including records from the SYS audit trail, for all the audited components of your Oracle Database installation are placed in one location and in one format, rather than your having to look in different places to find audit trails in varying formats. This consolidated view enables auditors to co-relate audit information from different components. For example, if an error occurred during an INSERT statement, standard auditing can indicate the error number and the SQL that was executed. Oracle Database Vault-specific information can indicate whether this error happened because of a command rule violation or realm violation. Note that there will be two audit records with a distinct AUDIT_TYPE. With this unification in place, SYS audit records appear with AUDIT_TYPE set to Standard Audit.

• The management and security of the audit trail is also improved by having it in single audit trail.

• Overall auditing performance is greatly improved. The default mode that unified audit works is Queued Write mode. In this mode, the audit records are batched in SGA queue and is persisted in a periodic way. Because the audit records are written to SGA queue, there is a significant performance improvement. To set the performance mode, see "Auditing Activities with Unified Audit Policies and the AUDIT Statement".

• You can create named audit policies that enable you to audit the supported components listed at the beginning of this section, as well as SYS administrative users. Furthermore, you can build conditions and exclusions into your policies.

• If you are using an Oracle Audit Vault and Database Firewall environment, then the unified audit trail greatly facilitates the collection of audit data, because all of this data will come from one location. See Oracle Audit Vault and Database Firewall Administrator's Guide for more information.

Checking if Your Database Has Migrated to Unified Auditing

You can find if your database has been migrated to unified auditing by querying the V$OPTION dynamic view.

• Query the VALUE column of the V$OPTION dynamic view as follows, entering Unified Auditing in the case shown:

  SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';
  
  PARAMETER         VALUE
  ----------------  ----------
  Unified Auditing  TRUE
  

This output shows that unified auditing is enabled. If unified auditing has not been enabled, then the output is FALSE.

Mixed Mode Auditing

Mixed mode auditing is the default auditing in a newly installed database.

Topics:

• About Mixed Mode Auditing

• How Database Creation Determines the Type of Auditing You Have Enabled

• Capabilities of Mixed Mode Auditing

Who Can Perform Auditing?

In order to perform any kind of auditing, you must be granted either the AUDIT_ADMIN role or the AUDIT_VIEWER role.

• AUDIT_ADMIN role. This role enables you to create unified and fine-grained audit policies, use the AUDIT and NOAUDIT SQL statements, view audit data, and manage the audit trail administration. Grant this role only to trusted users.

• AUDIT_VIEWER role. This role enables users to view and analyze audit data. The kind of user who needs this role is typically an external auditor.

Using Auditing in a Multitenant Environment

You can apply audit settings to individual PDBs or to the CDB as a whole, depending on the type of policy. In a Multitenant environment, each PDB, including the root, has own unified audit trail.

See the following sections for more information:

• Unified audit policies created with the CREATE AUDIT POLICY and AUDIT statements: You can create policies for both the root and individual PDBs. See"Using the Unified Audit Policies or AUDIT Settings in a Multitenant Environment".

• Fine-grained audit policies: You can create policies for individual PDBs only, not the root. See "Creating a Fine-Grained Audit Policy".

• Purging the audit trail: You can perform purge operations for both the root and individual PDBs. See "Purging Audit Trail Records".

Auditing in a Distributed Database

Auditing is site autonomous. A database instance audits only the statements issued by directly connected users. A local Oracle Database node cannot audit actions that take place in a remote database.