Well, tough one actually. The main problem here is that application handles
the authentication - and developers certainly can find out how this happens
no matter how obfuscated is might look. The only way to prevent this without
touching the database is to create some middleware that will be the only
software connecting to the database directly - you can limit listener to
communicate only with one known address where this middleware is. All
applications will connect to the middleware and this middleware, depending
on certain criteria, will communicate with either production or development
db to serve the client (and possibly filter the result sets).
Another way is to try using VDB aka FGAC and create an on logon trigger
that will set up some context depending on connected IP and other parameters
known at logon time. Then you can cut off developers from seeing and/or
modifying any data in production db by setting 'where 1=0' policy for them.
--
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.
"Ed Stevens" <spamdump_at_nospam.noway.nohow> wrote in message
news:3cb45f57.166379531_at_ausnews.austin.ibm.com...
> Subject: Application userid security
>
> Platform: Oracle SE 8.0.5 and 8.1.7 on NT
>
> I'm pretty sure others must have addressed this issue (and solved it more
> elegantly than our shop) but a search of the ng archives didn't turn anything
> up.
>
> Requirement is to prevent development staff from being able to connect to
> production databases. Individual users do not have Oracle userids. The
> application connects with its own id.
>
> Current solution: Applications have no knowledge of connect string or
> credentials. All apps call a common routine that returns to the app the userid,
> pswd, and connect string. This prevents the developers from having a *need* to
> know what the connect credentials are, but of course they can still find out if
> they want to by simply stepping through their pgms in debug mode and seeing what
> comes back from the called routine. For their own work "outside" of the apps,
> they are provided with a userid that does not exist in the production DBs.
>
> The mechanics of the system work fine and is being used by over a dozen
> applications written in Powerbuilder, VB, and COBOL. But of course it doesn't
> really provide the security of preventing the developers from knowing how to get
> into a production DB.
>
> Surely (???) others have dealt with this problem. Everything I've looked at
> regarding Oracle security and user authentication still brings me back to a
> solution that allows the developers to be able to easily discover the keys to
> the production DB. Perhaps I've been staring at the solution and not seeing it.
>
Received on Thu Apr 11 2002 - 06:38:35 CDT
