Re: Application userid security

Again, developers write that application and will know any secret token embedded into it. Keeping developers away from production is actually not a technical issue - the only way you can do it is to enable auditing and track all access to the production database, review it and detect any illegal access (whatever this means for your organization), then act accordingly (fire them, bring them to court, whatever).

This reminds me of an old story about Bull Systems developing a unix-like OS which they intended to certify for A2. When asked, why won't they go for A1 right away, project manager answered that they, of course, could, but this would be inhumane as they would have to shoot all developers...

Keeping developers away from production systems while granting them occasional access is impractical. Better solution is to mirror production system to a testbed (probably stripping off any sensitive data you want to keep secret, or replacing it with fake generated data) and if any problem arises, developers may use the mirror to resolve it and then production DBA and network admins will roll out the fix into production. Other than this, I don't see any other way but auditing (and you will need it anyway to be sure there's no unauthorized access).

--
Vladimir Zakharychev (bob@dpsp-yes.com)                http://www.dpsp-yes.com
Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet applications.
All opinions are mine and do not necessarily go in line with those of my employer.


"Richard Kuhler" <noone_at_nowhere.com> wrote in message
news:SjIt8.36975$VQ2.18941543_at_twister.socal.rr.com...


> 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.

>