I don't think our staffing level would permit that.
1 DBA, 2 SA's and 1 contractor SA.
On Tue, 2004-03-16 at 17:47, MacGregor, Ian A. wrote:
> There is also the idea of two-man control. No one is allowed
> sole access to the machine room. No one knows the entire root/admin
> or dba password. I know of many places which implement two-man
> control for physical security, but none that have carried it to the
> computer security level. It would be so burdensome.
>
>
> Ian MacGregor
> Stanford Linear Accelerator Center
> ian_at_slac.stanford.edu
>
> ______________________________________________________________________
> From: Jared.Still_at_radisys.com [mailto:Jared.Still_at_radisys.com]
> Sent: Tuesday, March 16, 2004 5:08 PM
> To: oracle-l_at_freelists.org
> Subject: Re: Database security
>
>
> Thanks you Paul for the detailed info, and all others that replied.
>
> You have pretty much confirmed what I thought to be true.
>
> * you can't stop a determined SA
> * I don't want to be the SA
> * encryption is the only way to prevent access to data by the DBAs
> and SAs. This of course introduces key management.
>
> This supplies me with some solid material as we do gap analysis
> on our database security.
>
> Jared
>
>
>
>
> Paul Drake
> <discgolfdba_at_yahoo.com>
> Sent by:
> oracle-l-bounce_at_freelists.org
>
> 03/16/2004 04:59 PM
> Please respond to
> oracle-l
>
>
>
> To:
> oracle-l_at_freelists.org
> cc:
> Subject:
> Re: Database security
>
>
> --- Jared.Still_at_radisys.com wrote:
> > List,
> >
> > Here in the midst of Sarbanes Oxley, I've been
> > pondering methods
> > that might be used to prevent a system administrator
> > from connecting
> > to any databases running on that box.
> >
> > I know that it is possible to setup Oracle on
> > Windows so that without
> > a password, you cannot logon to the database as
> > sysdba.
> >
> > eg. sqlplus "/ as sysdba" will require a password.
> >
> > The caveat to this is that the SA can simply:
> >
> > * stop the Oracle service
> > * change the init.ora parm
> > remote_login_passwordfile to 'none'
> > * start up the database
> > * create a dba account
> > * shutdown the database
> > * re-enable the password file
> > * restart the database
> >
> > That won't get you SYSDBA, but it will get you DBA,
> > which is probably
> > enough
> > for any nefarious activities.
> >
> > On *nix it is a bit different of course. Anyone
> > with root can simply su
> > to oracle.
> >
> > I have been perusing Pete Finnigan's "Oracle
> > Security Step-by-Step" but
> > have
> > not yet found information pertaining to this
> > particular topic, other than
> > revoking
> > privs from the DBA account. That action is not
> > applicable here, as the
> > team of
> > DBA's consists of me by myself.
> >
> > And TIA Mladen, but I already know how it works on
> > unix, and that MS is
> > the
> > dark side of the force, but is unfortunately what I
> > have to live with.
> >
> > Jared
>
> Jared,
>
> I wish we would have talked this over last week while
> enjoying a tasty beverage.
>
> DBA and SYSDBA are different animals.
>
> The quick answer is, you can't do it.
>
> You can prevent the (MCSE) Domain Admin from
> connecting to an Oracle database instance on a win32
> box, when it really isn't a windows box anymore. that
> takes alot of work and testing. If he can gain access
> to the server room, you can't stop him.
>
> The verbose answer is, you can make it a large PITA
> for him to get into it, but the a user having local
> administrator can re-grant the local ORA_DBA or
> ORA_%ORACLE_SID%_DBA group to the administrators local
> group or their account, or could construct a new
> password file and connect as sysdba.
>
> You can setup the filesystem permissions such that the
> local administrators cannot access the oracle files
> (at client sites I allow them read access for backup
> purposes, via a local OPER group).
>
> You can audit permissions changes to filesystems.
>
> But you cannot prevent a member of the local
> administrators group from clearing the log files, e.g.
> security event log.
>
> You can, however, run a syslog client to send such
> messages to a *nix box, that a local administrator of
> the win32 box (or Domain Admin) could not access. If
> you have a security administrator, I'm sure that you'd
> muck something up in PERL to send them alerts for such
> things in an automated fashion, hopefully not thru the
> local MS Exchange server that the evil MS SysAdmin
> could also compromise (or already manages).
>
> Now, if the SysAdmin grants a local group to his
> account (or local group) or takes ownership of files -
> it will show up in the log files on the *nix box.
>
> It depends upon what you are trying to accomplish.
> If you simply want to be able to track that a user has
> gained access as sysdba, the event logs already
> include such information, just get that information
> off of the box in real-time fashion. That may be
> sufficient for your purposes.
>
> If you seriously want to prevent the Admin from
> accessing the database files, you're going to have to
> prevent him from accessing any of the backup sets
> (including those at rest, on tapes at the offsite
> location, etc). That is pretty much impossible without
> encrypting the data.
>
> I have done alot of work on making Oracle on Windows
> as secure as possible. Some of it as an exercise, some
> for real. I had a w2k box that only had one port
> listed in a netstat command output, that was the
> listener's.
> The box was not real useful outside of the listener
> and the instance (which is good).
>
> Have you considered, removing the box from the domain,
> so that it is in its own workgroup, (thinking clean
> re-install) and not granting any accounts out to any
> others?
>
> After Nimda hit our network (years ago), all the
> oracle servers that were win32 left the domain, and
> had netbios ripped out (as well as the server service,
> etc.).
>
> If the SysAdmin has no accounts to log onto the box,
> then he's not really the SysAdmin anymore. You would
> be. caution.
>
> That is the responsibility that I assumed (took) here
> years ago. Its alot of work. Careful what you wish
> for. I get to apply the hotfixes, change the virus
> software, verify that the backupsets were transported
> to the staging servers, read the logs.
>
> It meant that the developers no longer had access to
> /udump. That is a large price to pay for OS and
> filesystem security.
>
> The developers do get access (via ssh) to the new 9.2
> dev db running on RHEL 3.0 ES. All ports on that are
> closed off below 1024 except for ssh (this is a box on
> the internal LAN, and yes, I still run a firewall on
> the box).
>
> There is no rpm for sendmail on the server.
> There is no rpm for bind on the server.
>
> I did open everything above 1024 tcp so that dedicated
> server processes could be obtained and I would not
> want to ask anyone to read a trace file created via a
> shared server. If it turns out that we're only using
> ports below 4000, I'll tighten up the range that
> iptables is accepting incoming connections for tcp.
>
> time for beef and beer.
>
> Paul
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - More reliable, more storage, less spam
> http://mail.yahoo.com
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
>
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Wed Mar 17 2004 - 00:10:16 CST
