Securing the database from the DBA

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I've been thinking a lot lately about the additional security
requirements that the recent onslaught of legislations placed on
databases (HIPAA, Sarbanes-Oxley, Gramm-Leach-Bliley, California SB

Specifically, consider the requirements for keeping an audit trail of
data accesses and modifications.  Within Oracle, triggers can be used
to track DDL, DML, logon, logoff, and a myriad of other interesting
events.  Fine Grain Auditing can be used to audit SQL queries, and can
be coupled with Flashback so that you can see exactly what was seen by
those queries.

All of these methods, and many of Oracle's other security features,
put the responsibility on the shoulders of the DBA.  But doesn't this
also give the DBA the powers to circumvent these measures?  Can't he
delete rows from the audit logs?  Can't he disable triggers or FGA
policies before doing something sneaky?  When using the database's
facilities as your audit trail tool, doesn't the DBA have the
knowledge and ability to circumvent and cover up _anything_?

What do you do if you want to protect the data from the DBA?

Many companies now have separate security departments, as seen by the
rise of the 'Chief Security Officer'.  If they wanted to put the
responsibilities of maintaining the database audit trail in the
security department, would they hire a DBA in that department to watch
the DBA in the IT department?  Or should they use mechanisms outside
of Oracle for securing the database, such as some third party tool?

Maybe these concerns too far from the real world.  Do most companies
simply let the DBA handle the database security, and worry about
whether he _should_ be the one handling security only after there is
an incident?

Thanks for your opinions!

Re: Securing the database from the DBA (David M. Lee) wrote:

Quoted text here. Click to load it

The database should log the actions that can be used to disable any of
these features.  So if something suspicious happens with the database,
and you see this in the log, it's strong circumstantial evidence that
the DBA was responsible.

Logs can be sent to remote devices or hardcopy that only the security
department has physical access to.

If you really need a high level of checks and balances, I suppose you
could implement something analogous to the way nuclear missiles are
launched: two keys have to be turned simultaneously, and they're located
far enough apart that one person can't do it by himself.  Something
analogous would be a requirement that two people in different rooms
enter commands to disable the database logging/auditing policies.

Barry Margolin,
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Securing the database from the DBA

Quoted text here. Click to load it

There are also audit packages that can identify unauthorized database
access even if done by the DB admin him/her self - without them
knowing their actions are logged.

Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.

Re: Securing the database from the DBA

DBAs, and all IT practitioners as well, have a professional responsibilty to
secure their work, e.g., dB, servers, routers, etc.

IT Security professionals have responsibilities to setup security standards
and enforce complicance.

Quoted text here. Click to load it

Re: Securing the database from the DBA (David M. Lee) wrote in message
Quoted text here. Click to load it

Couple things I have done in regards to this.  
1.  For personnel information use a unique key to identify people.
Have the user's personal information with the unique key in a separate
table under control of a different DBA.
2.  For logging.  Create a web service on a separate server for the
purpose of collecting logs and events from all machines on the
network.  All machines immediately send a web service post (via custom
app, or in the Oracle case, just use its native web service ability)
to the remote web service for events.  The granualarity of reporting
is tunable by machine but on a DB even shows changes to roles,
permissions and settings (Including logging).

The Orlok

Site Timeline