Securing the database from the DBA

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?