Re: Oracle OS level security

Nothing can prevent an SA from wreaking havoc. The best we can do is narrow the number of people who can and DBAs can be removed from that group, if desired...

> ----- Original Message -----
> From: "Jared Still" <jkstill_at_cybcon.com>
> To: <ORACLE-L_at_fatcity.com>; "Tim Gorman" <Tim_at_SageLogix.com>
> Sent: Thursday, November 28, 2002 5:45 PM
> Subject: Re: Oracle OS level security
>
>
> > On Thursday 28 November 2002 12:03, Tim Gorman wrote:
> > > My $0.02...
> > >
> > > Oracle9i provides the AUDIT_SYS_OPERATIONS parameter, which will audit
> only
> > > to the OS audit trail. Thus, anything that SYSDBA does can be
audited.
> > >
> > > The reason for the OS audit-trail only? Because SYSDBA can always
erase
> a
> > > DB audit trail (even if the act of erasure is still audited). All
> SYSDBA
> > > however, can be prevented from reading or modifying the OS audit
trail.
> >
> > This doesn't prevent a SA with DBA knowledge from wreaking havoc.
> >
> > > I believe the only secure configuration for an Oracle database has the
> > > "software owner" (typically named "oracle") and OS_SYSDBA and
OS_SYSOPER
> > > groups under control of SysAdmins only. Those with SYSDBA do not need
> > > access to that OS account or those OS groups.
> >
> > SA's still a problem.
> >
> > >
> > > The real problem is DBAs ourselves, who seem to treasure day-to-day
> usage
> > > of the Oracle software owner and membership of private accounts in the
> > > OS_SYSDBA and OS_SYSOPER groups...
> >
> > Personally, I log into the 'oracle' or 'root' account only as needed.
> >
> > Except on NT of course, where I need admin access to do my job
> > properly. Maybe in a larger shop that wouldn't be necessary, but
> > in a small shop it's very difficult to have an SA at your side when
> > needed for admin level access.
> >
> > Jared
> >
> >
> > >
> > > ----- Original Message -----
> > > To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> > > Sent: Thursday, November 28, 2002 4:53 AM
> > >
> > > > Jared,
> > > >
> > > > Very interested in the "thread" you hypothetical raised. I'm
working
> in
> > > > a pharamceutical site which is subject to FDA and other regualtions
> part
> > > > of which is the whole buisness of audit trails.
> > > >
> > > > We has a Standard Operating Procedure which states that whilst DBA's
> have
> > >
> > > a
> > >
> > > > access to data they will not change it. A recognition of the DBA's
> > > > capabilties but stating on paper company trust they will "behave"
> > > > themselves.
> > > >
> > > > On a more practical point with NT/W2K Oracle audit trail can be set
to
> > >
> > > write
> > >
> > > > audit trail records to the event logs. DBA's can be prevented from
> > >
> > > changing
> > >
> > > > the event logs. So now it would take at least 2 people to instigate
a
> > > > fraud. Hey this might foster even better relations between DBA's
and
> > > > SA's ;)
> > > >
> > > > Just my 2 cent worth :)
> > > > -------------------------
> > > > Seán O' Neill
> > > > Organon (Ireland) Ltd.
> > > > [subscribed: digest mode]
> > > >
> > > > >> From: Jared.Still_at_radisys.com
> > > > >> Date: Tue, 26 Nov 2002 14:40:24 -0800
> > > > >> Subject: Oracle OS level security
> > > > >>
> > > > >>Dear list,
> > > > >>
> > > > >>Let me toss a hypothetical situation at you.
> > > >
> > > > etc. etc.
> > > > --------------------------------------------------------------------
> > > > This message, including attached files, may contain confidential
> > > > information and is intended only for the use by the individual
> > > > and/or the entity to which it is addressed. Any unauthorized use,
> > > > dissemination of, or copying of the information contained herein is
> > > > not allowed and may lead to irreparable harm and damage for which
> > > > you may be held liable. If you receive this message in error or if
> > > > it is intended for someone else please notify the sender by
> > > > returning this e-mail immediately and delete the message.
> > > > --------------------------------------------------------------------
> > > > --
> > > > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > > > --
> > > > Author: O'Neill, Sean
> > > > INET: Sean.ONeill_at_organon.ie
> > > >
> > > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > > > San Diego, California -- Mailing list and web hosting
services
> > >
> ---------------------------------------------------------------------
> > > > To REMOVE yourself from this mailing list, send an E-Mail message
> > > > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > > > the message BODY, include a line containing: UNSUB ORACLE-L
> > > > (or the name of mailing list you want to be removed from). You may
> > > > also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Tim Gorman
  INET: Tim_at_SageLogix.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).