 |
|
Oracle Tips by Burleson |
Chapter 8 General Oracle Auditing
These two assumptions are fundamental to the
tracking of application users; but unfortunately, these assumptions
are easily circumvented. The user may not call the procedure to set
the client identifier, either deliberately or inadvertently. Nothing
will then go into the CLEINTID column of the aud$ table, nor will it
cause an error. The application will continue to run fine without
the vital auditing information. Because of this, the omission may
not be even detected.
Similarly the user may not supply the correct
value for the application user id. The human user Clara can login as
APPUSER and then issue dbms_session.set_identifier (‘JOE’). This
will record all the auditing information as being done by Joe, not
Clara.
Therefore the above setup in its present form
is not adequate. We need some extensive work to make it more secure.
Making the application call the procedures
directly can solve the problem. After the application authenticates
the user using some mechanism such as Domain Authentication, the
username is known. After it connects to the database, the
application can execute the procedure dbms_session.set_identifier
with the proper username. The user has no chance of entering
anything in there.
However, what if the user connects to the
database outside the application, e.g. using SQL*Plus or some other
tools like TOAD? Then the client_identifier is not set.
The above text is
an excerpt from
the bestselling book:
Oracle
Privacy Security Auditing.
It's only $39.95 and has an
download of working security scripts:
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
download of working security scripts:
http://rampant-books.com/book_2003_2_audit.htm
|
Download your Oracle scripts now:
www.oracle-script.com
The
definitive Oracle Script collection for every Oracle professional DBA
|
|
