||Oracle Tips by Burleson
Chapter 8 General Oracle Auditing
there is no need to catch the same action in the
The fourth case is also interesting. The user
SYSDBA1 now connects normally and performs the same select query.
select * from claim_schema.claims
The query will fail since the user did not
connect as SYSDBA and does not have any other privilege to perform
the query. If you examine the audit destination, you will also find
that there is no audit record for these actions. The reason is also
simple to understand – the user connected normally, not as SYSDBA,
and therefore the action was not audited. In the first case, the
user did connect as SYSDBA, triggering the audit. The mere
possession of the SYSDBA privilege does not trigger the sys
auditing; hence the privilege must be used.
records go to the filesystem (in UNIX) or Event Log (in Windows),
not to the database tables, even if the parameter audit_trail is set to DB. The
Only the users who connected as SYSDBA, SYSOPER
A user who has the SYSDBA privilege, but
connects normally, is not audited in this setup. For the auditing to
be triggered, the user has to connect as SYSDBA.
The user SYS is audited. In Oracle 9i, the user
SYS can connect only as SYSDBA; so there is no possibility of user
SYS connecting normally.
The above text is
an excerpt from:
Oracle Privacy Security Auditing
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
and has an
immediate download of working security scripts: