ORACLE Audit

Auditing
• Auditing is the monitoring of selected user

database actions
• Used to
– Investigate suspicious database activity
– Gather information about specific database
activities
16-22 Copyright © Oracle Corporation, 2001. All rights reserved.
Auditing
If an unauthorized user is deleting data, the DBA might decide to audit all connections to the
database and all successful and unsuccessful deletions from all tables in the database. The DBA
can gather statistics about which tables are being updated, how many logical I/Os are performed,
and how many concurrent users connect at peak times.
DBA Fundamentals I 16-22

Auditing Guidelines
• Define what you want to audit

– Audit users, statements, or objects
– Statement executions
– Successful statement executions,
unsuccessful statement executions or both
• Manage your audit trail
– Monitor the growth of the audit trail
– Protect the audit trail from unauthorized
access
Auditing Guidelines
Restrict auditing by first identifying the auditing requirements, and setting minimal auditing
options that will cater to the requirements. Object auditing must be used where possible to reduce
the number of entries generated. If statement or privilege auditing needs to be used, the following
settings can minimize audit generation:
• Specifying users to audit
• Auditing by session, and not by access
• Auditing either successes or failures, but not both
• Audit records may be written to either SYS.AUD$ or the operating system’s audit trail. The
ability to use the operating system’s audit trail is operating system dependent.
Monitoring the Growth of the Audit Trail
If the audit trail becomes full, no more audit records can be inserted, and audited statements will
not execute successfully. Errors are returned to all users that issue an audited statement. You must
free some space in the audit trail before these statements can be executed.

Monitoring the Growth of the Audit Trail (continued)
To ensure the audit trail does not grow too rapidly:
• Enable auditing only when necessary.
• Be selective about which audit options are specified.
• Tightly control schema object auditing. Users can turn on auditing for the objects that they
own.
• The AUDIT ANY privilege also enables a user to turn on auditing, so grant it sparingly.
Periodically remove audit records from the audit trail with the DELETE or TRUNCATE command.
Audit files are located in $ORACLE_HOME/rdbms/audit directory.
Protecting the Audit Trail
You should protect the audit trail so that audit information cannot be added, modified, or deleted.
Issue the command:
AUDIT delete ON sys.aud$ BY ACCESS;
To protect the audit trail from unauthorized deletions, only the DBA should have the
DELETE_CATALOG_ROLE role.
Moving the Audit Trail out of the System Tablespace
As new records get inserted into the database audit trail, the AUD$ table can grow without bound.
Although you should not drop the AUD$ table, you can delete or truncate from it because the rows
are for information only and are not necessary for the Oracle instance to run. Because the AUD$
table grows and then shrinks, it should be stored outside of the system tablespace.
To move AUD$ to the AUDIT_TAB tablespace:
• Ensure that auditing is currently disabled.
• Enter the following command:
ALTER TABLE aud$ MOVE TABLESPACE AUDIT_TAB;
• Enter the following command:
CREATE INDEX i_aud1 ON aud$(sessionid, ses$tid)
TABLESPACE AUDIT_IDX;
• Enable auditing for the instance.

Auditing Categories
• Audited by default
– Instance startup and Instance shutdown
– Administrator privileges
• Database auditing
– Enabled by DBA
– Cannot record column values
• Value-based or application auditing
– Implemented through code
– Can record column values
– Used to track changes to tables
Auditing categories
Regardless of whether database auditing is enabled, Oracle always records some database
operations into the operating system audit trail. These are:
• Instance startup: The audit record details the operating system user starting the instance, the
users terminal identifier, the date and time stamp and whether database auditing was
enabled or disabled.
• Instance shutdown: This details the operating system user shutting down the instance, the
user’s terminal identifier, the date and time stamp.
• Administrator privileges: This details the operating system user connecting to Oracle with
administrator privileges.
Database Auditing
Database auditing is the monitoring and recording of selected user database actions. Information
about the event is stored in the audit trail.
The audit trail can be used to investigate suspicious activity. For example, if an unauthorized user
is deleting data from tables, the database administrator may decide to audit all connections to the
database in conjunction with successful and unsuccessful deletions of rows from tables in the
database.

Database Auditing (continued)
Auditing might also be used to 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, and how many concurrent users connect at peak times.
Value-Based Auditing
Database auditing cannot record column values. If the changes to database columns need to be
tracked and column values need to be stored for each change, use application auditing.
Application auditing can be done either through client code, stored procedures, or database
triggers.

Database Auditing
Enable database Execute command

auditing
DBA Parameter file User
Server
Review Specify process
audit audit options Generate
information
audit trail
Audit options
OS audit
Database trail
Audit trail
Enabling and Disabling Database Auditing

Once you have decided what to audit, you set the AUDIT_TRAIL initialization parameter to
enable auditing for the instance. This parameter indicates whether the audit trail is written to a
database table or the operating system audit trail.
AUDIT_TRAIL = value
where value can be one of the following:
DB enables auditing and directs all audit records to the database
audit trail (SYS.AUD$)
OS enables auditing and directs all audit records to the operating
system audit trail (if permitted on the operating system)
NONE disables auditing (this is the default value)

Enabling Database Auditing (continued)
Audit records will not be written to the audit trail unless the DBA has set the AUDIT_TRAIL
parameter to DB or OS. Although the SQL statements AUDIT and NOAUDIT can be used at any
time, records will only be written to the audit trail if the DBA has set the AUDIT_TRAIL
parameter in the initialization file.
Note: The Installation and Configuration Guide for your operating system provides information
on writing audit records to the OS audit trail.
Specifying Audit Options
Next, you set specific auditing options using the AUDIT command. With the AUDIT command,
you indicate which commands, users, objects, or privileges to audit. You can also indicate
whether an audit record should be generated for each occurrence or once per session. If an
auditing option is no longer required, you can turn off the option with the NOAUDIT command.
Execution of Statements
When users execute PL/SQL and SQL statements, the server process examines the auditing
options to determine if the statement being executed should generate an audit record. SQL
statements inside PL/SQL program units are individually audited, as necessary, when the program
unit is executed. Because views and procedures may refer to other database objects, several audit
records may be generated as the result of executing a single statement.
Generating Audit Data
The generation and insertion of an audit trail record is independent of a user’s transaction;
therefore, if a user’s transaction is rolled back, the audit trail record remains intact. Since the
audit record is generated during the execute phase, a syntax error, which occurs during the parse
phase, will not cause an audit trail record to be generated.
Reviewing Audit Information
Examine the information generated during auditing by selecting from the audit trail data
dictionary views or by using an operating system utility to view the operating system audit trail.
This information is used to investigate suspicious activity and to monitor database activity.

Auditing Options
• Statement auditing
AUDIT TABLE;
• Privilege auditing
AUDIT create any trigger;
• Schema object auditing

AUDIT SELECT ON emi.orders;
Audit Options
Statement auditing: This is the selective auditing of SQL statements, not the specific schema
objects on which it operates. For example, AUDIT TABLE tracks several DDL statements
regardless of the table on which they are issued. You can set statement auditing to audit selected
users or every user in the database.
Privilege auditing: This is the selective auditing of system privileges to perform corresponding
actions, such as AUDIT CREATE ANY TRIGGER. You can set privilege auditing to audit a
selected user or every user in the database.
Schema object auditing: This is the selective auditing of specific statements on a particular
schema object, such as AUDIT SELECT ON HR.EMPLOYEES. Schema object auditing always
applies to all users of the database.
You can specify any auditing option, and specify the following conditions:
• WHENEVER SUCCESSFUL / WHENEVER NOT SUCCESSFUL
• BY SESSION / BY ACCESS
For specific users or for all users in the database (statement and privilege auditing only).

Auditing Options
Fine-Grained Auditing
• Provides the monitoring of data access based on
content
• Implemented using the DBMS_FGA package
Audit Options
Fine Grained auditing: This provides the monitoring of data access based on content. A PL/SQL
package DBMS_FGA administers value-based audit policies. Using DBMS_FGA, the DBA creates
an audit policy on the target table. If any of the rows returned from a query block matches the
audit condition, an audit event entry, including username, SQL text, bind variable, policy name,
session id, timestamp, and other attributes are inserted into the audit trail.
Disabling Auditing
Use the NOAUDIT statement to stop auditing chosen by the AUDIT command.
Note: A NOAUDIT statement reverses the effect of a previous AUDIT statement. Note that the
NOAUDIT statement must have the same syntax as the previous AUDIT statement and that it
only reverses the effects of that particular statement. Therefore, if one AUDIT statement
(statement A) enables auditing for a specific user, and a second (statement B) enables auditing for
all users, then a NOAUDIT statement to disable auditing for all users reverses statement B, but
leaves statement A in effect and continues to audit the user that statement A specified.

Viewing Auditing Options
Data Dictionary Views

• ALL_DEF_AUDIT_OPTS
• DBA_STMT_AUDIT_OPTS
• DBA_PRIV_AUDIT_OPTS
• DBA_OBJ_AUDIT_OPTS
Viewing Auditing Options

Data Dictionary View Description
-------------------- ----------------------
ALL_DEF_AUDIT_OPTS Default audit options
DBA_STMT_AUDIT_OPTS Statement auditing options
DBA_PRIV_AUDIT_OPTS Privilege auditing options
DBA_OBJ_AUDIT_OPTS Schema object auditing options

Obtaining Audit Records
• Data Dictionary Views

– DBA_AUDIT_TRAIL
– DBA_AUDIT_EXISTS
– DBA_AUDIT_OBJECT
– DBA_AUDIT_SESSION
– DBA_AUDIT_STATEMENT
Listing Audit Records

The database audit trail (SYS.AUD$) is a single table in each Oracle database’s dictionary.
Several predefined views are available. Some of the views are listed in the slide. These views are
created by the DBA.
Data Dictionary View Description
-------------------- ---------------------------------
DBA_AUDIT_TRAIL All audit trail entries
DBA_AUDIT_EXISTS Records for AUDIT EXISTS/NOT EXISTS
DBA_AUDIT_OBJECT Records concerning schema objects
DBA_AUDIT_SESSION All connect and disconnect entries
DBA_AUDIT_STATEMENT Statement auditing records

ORACLE Audit

Uploaded by

Copyright:

Available Formats

ORACLE Audit

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ORACLE Audit

Uploaded by

Copyright:

Available Formats

Auditing

• Auditing is the monitoring of selected user

16-22 Copyright © Oracle Corporation, 2001. All rights reserved.

DBA Fundamentals I 16-22

• Define what you want to audit

16-23 Copyright © Oracle Corporation, 2001. All rights reserved.

DBA Fundamentals I 16-23

DBA Fundamentals I 16-24

16-25 Copyright © Oracle Corporation, 2001. All rights reserved.

DBA Fundamentals I 16-25

DBA Fundamentals I 16-26

Enable database Execute command

16-27 Copyright © Oracle Corporation, 2001. All rights reserved.

Enabling and Disabling Database Auditing

DBA Fundamentals I 16-27

DBA Fundamentals I 16-28

• Schema object auditing

16-29 Copyright © Oracle Corporation, 2001. All rights reserved.

DBA Fundamentals I 16-29

16-30 Copyright © Oracle Corporation, 2001. All rights reserved.

DBA Fundamentals I 16-30

Data Dictionary Views

16-31 Copyright © Oracle Corporation, 2001. All rights reserved.

Viewing Auditing Options

DBA Fundamentals I 16-31

• Data Dictionary Views

16-32 Copyright © Oracle Corporation, 2001. All rights reserved.

Listing Audit Records

DBA Fundamentals I 16-32

You might also like