Re: Securing the database from the DBA

sybrandb_at_yahoo.com wrote in message news:<a1d154f4.0403300346.276462b_at_posting.google.com>...
> leedm777_at_hotmail.com (David M. Lee) wrote in message news:<8df1fe79.0403292233.7a991f15_at_posting.google.com>...
> > 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
> > 1386).
> >
> > 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!
> > dave
> > <><
>
>
> Sometimes you have to trust someone.
> If you don't trust him/her, fire him/her!
> BTW, do you also want to secure the system from the system
> administrator?
> <snip>
> Sybrand Bakker
> Senior Oracle DBA

There are limitations to all plans and at some point you have to realize that all practical steps have been taken.

If the contents of data is truely sensative then encrypt it, make all access go through supplied, wrapped packages that provide the encrypt/decrypt value, and produce an audit trail from the package for all access.

But someone has to write the package, and the source will have to be stored somewhere, so there are still possbile weak points.

Limit access to the data via specified applications, require passwords to get at the applications, hide the application server behind a firewall. Do not allow direct access to the db servers except via the application servers, etc...

IMHO -- Mark D Powell -- Received on Tue Mar 30 2004 - 18:54:04 CEST