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: Application userid security

Re: Application userid security

From: Ed Stevens <spamdump_at_nospam.noway.nohow>
Date: Fri, 12 Apr 2002 20:04:34 GMT
Message-ID: <3cb7398a.353286729@ausnews.austin.ibm.com>


On 12 Apr 2002 00:19:23 -0700, pagesflames_at_usa.net (Dusan Bolek) wrote:

<snip>
>If you'll use browser based application, then your problem will be
>solved. That's a middleware tier (as Mr. Vladimir point out). Your
>database will be accesible only from web server and no one can get
>into your DBs by SQL*Plus or something like this.
>
>> Second, the developers do occasionally have legitimate need to get into the
>> production DB outside of the app -- to fix data in resolving production
>> problems. Using a firewall to lock them out based on machine id or IP address
>> would prevent this. Our current strategy in these situations is to have them
>> request a "special" userid which we create and give to them, and then drop when
>> their fix is done.
>
>No problem at all. Your web based application should use a secret
>password, some kind of hash for example and you developers will use
>their private accounts. Do not forget to turn auditing on access by
>these accounts.
>
>--
>_________________________________________
>
>Dusan Bolek, Ing.
>Oracle team leader

<snip>

Not sure I follow. Having the app code run on the web server instead of the desktop doesn't put a layer between the app developer and the database. If the developers know how to make their app connect to the database, then THEY know how to connect to the database. Unless you're talking about using some kind of IP blocking scheme, but then we're back to blocking the developer when he has a legit need to get in.

Looks more and more that the only way to achieve what we're after is to write a module that can be called by VB, COBOL, C, and Java, and have THAT module connect to the database (and pass thru queries and results) at the request of the app. So that the app say, in effect, "hey there, please connect to this database, have it execute this SQL, then give me the results. I don't know where that database is or how you connect, but I trust that you know how." That's what happens on the mainframe, where the app is actually passing any I/O request (including SQL) to a subsystem such as CICS. And this is really what management (whose on technical background is strictly mainframe) are thinking about, even if they don't realise it.

Of course, if I were convinced this were the only solution, I wouldn't be here asking for someone to beat some sense into me. I can't really belive everyone else jumps through the kind of hoops we are, so I am left with one of two conclusions -- either there is a simple and elegant solution that I am not comprehending, or we are the only shop that has these requirements of keeping the developers out of production data except on an exception basis.

Keep talking to me folks. I'm not trying to be obtuse. My gut feeling is I'm simply missing something that's obvious to everyone else, and I'm trying desperately to see it. Received on Fri Apr 12 2002 - 15:04:34 CDT

Original text of this message

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