|
Posted by The Orlok on April 9, 2004, 4:40 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> 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
> <><
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
| 
XML site map