Fine-Grained Auditing

FROM employees, departments

WHERE employees.department_id = departments.department_id;

AUDIT SELECT ON employees_departments;

SELECT * FROM employees_departments;

As a result of the query on employees_departments, two audit records are generated: one for the query on the employees_departments view and one for the query on the base table employees (indirectly through the employees_ departments view). The query on the base table departments does not generate an audit record because the SELECT audit option for this table is not enabled. All audit records pertain to the user that queried the employees_departments view.

The audit options for a view or procedure are determined when the view or procedure is first used and placed in the shared pool. These audit options remain set until the view or procedure is flushed from, and subsequently replaced in, the shared pool. Auditing a schema object invalidates that schema object in the cache and causes it to be reloaded. Any changes to the audit options of base schema objects are not observed by views and procedures in the shared pool.

Continuing with the previous example, if auditing of SELECT statements is turned off for the employees table, use of the employees_departments view no longer generates an audit record for the employees table.

Fine-Grained Auditing

Fine-grained auditing allows the monitoring of data access based on content. A built-in audit mechanism in the database prevents users from by-passing the audit. Oracle triggers can potentially monitor DML actions such as INSERT, UPDATE, and DELETE. However, monitoring on SELECT is costly and might not work for certain cases. In addition, users might want to define their own alert action in addition to just inserting an audit record into the audit trail. This feature provides an extensible interface to audit SELECT statements on tables and views.

The DBMS_FGA package administers these value-based audit policies. Using DBMS_ FGA, the security administrator creates an audit policy on the target table. If any of the rows returned from a query block matches the audit condition (these rows are referred to as interested rows), then an audit event entry, including username, SQL text, bind variable, policy name, session ID, time stamp, and other attributes, is inserted into the audit trail. As part of the extensibility framework, administrators can also optionally define an appropriate event handler, an audit event handler, to

Auditing 24-9