Pete Finnigan's Oracle Security Weblog

Is it possible to audit the DBA with certainty that the DBA cannot alter or remove the audit trail? This was the subject of a thread a couple of days ago on comp.databases.oracle.server. This subject is discussed from time to time on various newsgroups and mailing lists. Generally the talk falls into two or three camps, first suggestions to fire the DBA if you do not trust him or suggest that he has free reign if you do trust him because auditing him is pointless or suggest ways to comply and audit him whilst understanding that if he is determined he can probably get around your measures.

The need to audit the DBA’s activities as well as everyone else’s has become a real requirement for companies that have to comply with new regulations that have sprung up in recent years. From 9i you can use the parameter audit_sys_operations to create trace files in the location pointed at by audit_file_dest parameter. Ideally this will write to a directory that the DBA's do not have access to. Ensuring that methods that can be used within the database to access operating system files are restricted is essential in this case so that the DBA cannot use the database engine to alter or remove the files. Fine Grained Audit is also a possibility if the SYS.FGA_LOG$ table can be protected. The best method to do this is to copy it to another database or to the file system either in real time or on a regular basis. This could be done by moving the table out of the SYSTEM tablespace and even from the SYS user (pointing back with synonyms) so that a trigger can be added to it to copy the data. This is most likely not supported by Oracle. The same techniques can be used with SYS.AUD$. Notes on metalink exist to show how to do this. Again this is not supported by Oracle but could still be done. Auditing the normal audit trail in the database for changes to it is also possible. Again this could be turned off or the contents of the audit trail changed by a DBA who wanted to do it.

I think it all comes down to compromise as do most of these very difficult problems that need to be solved. You can audit the DBA and its possible to write the audit records from audit_sys_operations to a file system the DBA cannot access but having DBA's you trust is also necessary!