Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Auditing DBAs

Re: Auditing DBAs

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Sun, 17 Oct 2004 10:56:07 +1000
Message-Id: <4171c327$0$20129$afc38c87@news.optusnet.com.au>


Mark D Powell wrote:

> Daniel Morgan <damorgan_at_x.washington.edu> wrote in message
> news:<1097949538.946698_at_yasure>...

>> Howard J. Rogers wrote:
>> 
>> > I presumably missed the bit where everyone posted the fact that in 9i
>> > Release 2, auditing SYS operations is a piece of cake, and requires
>> > the setting of one init.ora/spfile parameter.
>> 
>> I did.
>> 
>> > Audit_sys_operations=true is your friend.
>> > 
>> > It requires that you set the directory where the SYS audit trail is
>> > written to, and that requires in turn that you set appropriate O/S
>> > permissions on that directory so that Mr. DBA doesn't just waltz in to
>> > the directory and delete the audit trail. But nothing a moderately
>> > competent Unix administrator couldn't cope with, I suspect.
>> > 
>> > Regards
>> > HJR

>
> And since the DBA has access to the OS Oracle Id, which naturally has
> full OS permissions to the audit trail directory, cleaning up the
> audit trail should be a snap. 8-D

I bow to superior Unix knowledge wherever I can get it, but it should not be beyond the wit of a system administrator to devise a directory with permissions that let an Oracle instance write to the directory, but not permit an Oracle user, however well qualified as a DBA, to delete it.

I seem to recall that the business of setting up an oinstall and dba groups when installing Oracle was precisely to allow the DBA to administer the database, because he is a member of the dba one, but only to permit the system administrator to patch or upgrade the installation itself (because only he is a member of the oinstall group).

That division of labour is precisely what is required to make this sort of auditing work just fine, I would have thought.

>
> If the off-shore DBA's only have DBA privilege within the database and
> do not have access to the OS id then auditing SYS might work for some
> sites.

That is, of course, precisely how Oracle on Unix is *supposed* to be installed, so it should actually be true for most sites.

> But the reality is that if the DBA has access to the OS ID
> then the audit trail is more of "Yes, we audit the DBA" in name but
> not in substance.

Obviously. But that is not how one is supposed to install Oracle. One doesn't, in other words, need root privileges to administer a database, nor SYSDBA privileges to be root.  

> The IBM VM System Programmers manual had a note in for auditors.
> Because the VM administrator could bring the system up without the
> security package, do whatever they wanted without an audit trail, stop
> and restart with security and leave no record that they had ever
> played with the system that you should trust you VM System Programmers
> or get new ones.
>
> The are reasonable steps that every company should take to monitor its
> DBA's and System Administrators, but the most basic step is that they
> should hire reliable people.

Not good enough, I'm afraid, and you wouldn't get ISO-9001 certification if that's the best you can do. Of course you trust your staff. But you also verify that trust. And Audit_sys_operations is a perfectly adequate way of doing that.

HJR
>
> IMHO -- Mark D Powell --
Received on Sat Oct 16 2004 - 19:56:07 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US