Steve Jones - Editor (8/6/2010)
Auditing sysadmins is hard. Especially since the sysadmin has to set things up!SQL 2008 has good auditing capabilities, and what you need to do is write audit records to a file where the DBAs can't access. Only some security group. The SQL Service account should only have write access.
I'd also state that writing audit records to some kind of WORM media (journaled, like MO platters, or not, like printers and DVD+R), and then having another department audit the journal on said media, is an important step.
If one insists on writing said auditing to SQL Server tables, I'd have to say that writing transaction log backups of the logging database to WORM media every few seconds would be a reasonable, necessary, and still insufficient step. Another way to do this might be to set up the transaction log itself to write to WORM media; one would have to accept horrendously slow performance, however, and constantly change the physical platter/tape/whatever the log writes to, which could be... interesting.
Log files should be written directly and immediately to WORM media, absolutely minimizing any delay in which they can be changed prior to being archived. For those SQL Server trace flag experts out there, is there a trace flag that does this, and that can shut down SQL Server when auditing fails?
In particular, auditing changes to the auditing is critical.