(unknown charset) Re: Question About Oracle Security issue.....

OTOH, if such untrustworthy folk are around they should be fired BEFORE such measures become necessary.  Doing all this leads to huge distrust between people and groups.  Don't become a seff appointed security sleuth.

\R
 

Sybrand Bakker wrote:

> Ok here are some othe guidelines, and I can only hope you already
> implemented them, but on many sites they are just too lazy
> (This is assuming you are using Oracle 8i)
> 1 Change the sys password
> 2 Change the system password
> 3 Make sure the server has an appropiate password
> 4 Make sure all users are forced to change their passwords at least once a
> month
> 5 Don't give every developer DBA privilege (this sounds stupid, but most
> sites do this)
> 6 Do not provide your developers unnecessary priviliges
> 7 Run a separate development and production instance, the developers don't
> get a password on the production instance.
> 8 Enable auditing on the production instance
> 9 If you have applied all those measures, so you didn't *create* an
> opportunity for your developers to spy, and you still don't trust them, have
> them fired.
> As Oracle is not easy to crack I'm sure 99 percent of 'spying' is caused by
> not taking the measures outlined above.
>
> Hth,
>
> Sybrand Bakker, Oracle DBA
>
> "Richard" <richchen_at_ms6.hinet.net> wrote in message
> news:9ai1dv$9el_at_netnews.hinet.net...
> > Hello,
> >
> > Thank you Cliff and Daniel.
> >
> > To prevent potential fraud caused by internal staffs is the primary reason
 I
> > need this solution.
> >
> > Some developers/Power users may "spy" the confidential information in
> > databases. The confidential information means the data itself and database
> > schema.
> >
> > For technical guys, it is easy to intrude database with some tools like
> > SQL*PLUS (to get more data information) or ERWin ( to get database
 schema )
> >
> > if they have valid userid/password.  From the viewpoint of internal audit,
> > that is a threat for information security.
> >
> > If any one have better solution than this one , i.e., to prevent
> > unauthorized client machines and/or unauthorized applications to access
> > database,
> >
> > please let me share your idea.
> >
> > Thank you...
> >
> > Richard L. Chen
> >
> > ( PS: Actually, I don't think that would be difficult for Oracle to
> > implement this idea.)
> >
> >
> > C Palmer <cliff_at_palmercs.com> wrote in message
> > news:3ACC6B13.3DD6A8F8_at_palmercs.com...
> > > Richard, *if* the oracle server machine is (or can be) seperated from
> > > *all* the client machines onto a different network segment, you might be
> > > able to place an intellegent router between the segments and configure
 the
> > > router to deny routing  to ports 1521 and 1527 on the oracle server box
> > > from the specific workstations you wish.  In addition to that you could
> > > implement challeneged access in other fashions.
> > >
> > > I have to echo Daniel A Morgan's concerns about the wisdom of this
> > > notion.  This sounds like a really unworkable idea to me and probably
 wont
> > > really solve your problem..  Remember that a fair number of users know
 how
> > > to change their IP/IPX address or they can simply go sit at someone
 else's
> > > workstation.
> > >
> > > HTH
> > > Cliff
> > >
> > > Richard wrote:
> > >
> > > > Hi,
> > > >
> > > > Is there any possible solution to prevent unauthorized client machines
> > > > and/or unauthorized applications to access
> > > > Oracle database, even with valid USER ID and PASSWORD ??
> > > >
> > > > Thanks,
> > > >
> > > > Richard
> > > > richchen_at_ms6.hinet.net
> > >
> >
> >
Received on Thu Apr 05 2001 - 19:24:44 CEST