Re: audit response

"Quarkman" <quarkman_at_myrealbox.com> wrote in message news:oprsvw9bw0r9lm4d_at_haydn...
> I disagree with Brian, actually. Trust doesn't have to come into it, and
if
> security is really needed, it shouldn't.
>
> For example, in 9i Release 2, you can audit SYS actions (set
> AUDIT_SYS_OPERATIONS=TRUE). That produces a trace file at the O/S level,
> and one presumes that it would be possible (and sensible) to arrange for
> the file to be written to a directory to which the DBA doesn't have
rights.
> In Windows, the audit trail thus produced goes into the Event Viewer...
and
> again, one hopes that the DBA doesn't also have the ability to wipe that.
>
> In other words, by separating the functions of sysadmins and DBAs, and by
> investing in the latest releases of the software, you *can* audit SYS
> activity, reliably and securely.
>
> Sure, the DBA could modify the init.ora, and set the audit option to
> false... but then you make that a disciplinary offence.
>
> Likewise, the routine auditing of everybody's SQL is easily done with
> AUDIT_TRAIL=DB. Sure, a privileged user could wipe the SYS.AUD$ table to
> remove the records. But if you create an audit policy such as 'audit
delete
> on SYS.AUD$ by access', wiping AUD$ causes one new record to be added
which
> reads 'JOE DELETED THE AUD$ TABLE!!'... and you'd never be able to get rid
> of that.
>
> So there are technical ways to do it. And, more importantly perhaps, there
> are managerial approaches, to job differentiation and acceptable practice,
> which can do it, too.
>
> In this day and age, any secure system that relies ultimately on trust
> isn't secure.
>

I completely agree with Brian. Anyway, what is the point of trying to restrict what the DBA can do in the database, (with the oracle unix account) when the Unix Admins who have root anyway, can do whatever they like?

In descending order of importance, you have to trust:

1. The authorised cheque signatories
2. Anyone who has access to the company letterhead stationery
3. The security guard who has the key to the server room
4. The sysadmin who has root password
5. The DBA.

Regards,
Paul Received on Tue Jul 29 2003 - 14:30:03 CDT