Re: Application userid security

Sound like your requirement is:

1. A developer is allowed to use the application to connect to the production database.
2. That exact same machine should not be allowed to connect to the production database with any other tool using the Oracle account the application connects with.
3. That exact same machine should be allowed to connect to the production database using some other Oracle account.

Is that right?

If so, this requires authenticating the application. Without embedding a secret password in the application I can see no way to achieve that.

Richard

Ed Stevens wrote:
>
> 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 - 16:28:18 CDT