| |
 |
|
Oracle Tips by Burleson |
Chapter 11 Oracle Fine Grained Auditing
If a user queries the table, and the policy
condition as well as the columns are satisfied, by default, the
action is written into the table fga_log$ owned by SYS. However, it
is not mandatory that the records be written into this table alone.
In some cases, as we will see, it may be desirable to have a
separate table to record the audit functionality.
Maintainability
– The file grained audit
functionality, just like the regular audit, also needs sophisticated
archival and purge setups, where the trails can be preserved for
analysis later. The best method to achieve this is using a
partitioned table for the audit trails. When the time comes to
purge, the partition can be simply dropped. If it needs to be
preserved, the partition can be converted to a table, and the table
can be archived via export or via transportable tablespace. Since
partitioning the table fga_log$ is not supported, the next best
option is to create a user defined audit table and record there
manually.
Extended Functionality
– The audit handler can
do a lot of things in addition to storing the audit record, such as
send an e-mail when a certain audit event occurs, e.g. when someone
selects from the highly sensitive procedure codes outside business
hours. This functionality may seem a little extreme, but in
situations where an immediate action is required based on some
auditing event, the functionality can be implemented using the
handler function.
First we will create a table to hold the audit
records.
The above text is
an excerpt from:
Oracle Privacy Security Auditing
The
Final Word on Oracle Security
This is the only authoritative
book on Oracle Security, Oracle Privacy, and Oracle Auditing written
by two of the world’s leading Oracle Security experts.
This indispensable book is only
$39.95
and has an
immediate download of working security scripts:
|
