Oracle7 Server Administrator's Guide
Guidelines for Auditing
This section describes guidelines for auditing and includes the following topics:
Audit via the Database or Operating System
The data dictionary of every database has a table named SYS.AUD$, commonly referred to as the database audit trail.
Either the database or operating system audit trail can store all audit records generated as the result of statement, privilege, or object auditing.
Your operating system may or may not support database auditing to the operating system audit trail. If this option is available, consider the advantages and disadvantages of using either the database or operating system auditing trail to store database audit records.
Using the database audit trail offers the following advantages:
- You can view selected portions of the audit trail with the predefined audit trail views of the data dictionary.
- You can use Oracle tools (such as ReportWriter) to generate audit reports.
Alternatively, your operating system audit trail may allow you to consolidate audit records from multiple sources including Oracle and other applications. Therefore, examining system activity might be more efficient because all audit records are in one place.
See Also: Your operating system may also contain an audit trail that stores audit records generated by the operating system auditing facility. However, this facility is operating system-dependent. See your operating system-specific Oracle documentation.
Keep Audited Information Manageable
Although auditing is relatively inexpensive, limit the number of audited events as much as possible. This will minimize the performance impact on the execution of statements that are audited, and minimize the size of the audit trail.
Use the following general guidelines when devising an auditing strategy:
- Evaluate your purpose for auditing.
After you have a clear understanding of the reasons for auditing, you can devise an appropriate auditing strategy and avoid unnecessary auditing.
For example, suppose you are auditing to investigate suspicious database activity. This information by itself is not specific enough. What types of suspicious database activity do you suspect or have you noticed? A more focused auditing purpose might be to audit unauthorized deletions from arbitrary tables in the database. This purpose narrows the type of action being audited and the type of object being affected by the suspicious activity.
Audit the minimum number of statements, users, or objects required to get the targeted information. This prevents unnecessary audit information from cluttering the meaningful information and consuming valuable space in the SYSTEM tablespace. Balance your need to gather sufficient security information with your ability to store and process it.
For example, if you are auditing to gather information about database activity, determine exactly what types of activities you are tracking, audit only the activities of interest, and audit only for the amount of time necessary to gather the information you desire. Do not audit objects if you are only interested in each session's logical I/O information.
Auditing Suspicious Database Activity
When you audit to monitor suspicious database activity, use the following guidelines:
- Audit generally, then specifically.
When starting to audit for suspicious database activity, it is common that not much information is available to target specific users or schema objects. Therefore, audit options must be set more generally at first. Once preliminary audit information is recorded and analyzed, the general audit options should be turned off and more specific audit options enabled. This process should continue until enough evidence is gathered to make concrete conclusions about the origin of the suspicious database activity.
When auditing for suspicious database activity, protect the audit trail so that audit information cannot be added, changed, or deleted without being audited.
See Also: For more information about the audit trail, see "Protecting the Audit Trail" ![[*]](jump.gif)
.
Auditing Normal Database Activity
When your purpose for auditing is to gather historical information about particular database activities, use the following guidelines:
- Audit only pertinent actions.
To avoid cluttering meaningful information with useless audit records and reduce the amount of audit trail administration, only audit the targeted database activities.
- Archive audit records and purge the audit trail.
After you have collected the required information, archive the audit records of interest and purge the audit trail of this information.