Re: Application userid security

On Wed, 10 Apr 2002 20:20:30 GMT, spamdump_at_nospam.noway.nohow (Ed Stevens) wrote:

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

Let me give some follow-up additional information.

First, we are in this situation because of management's desire (requirement) that we manage the server based DB and development environment as much like the mainframe (IBM OS390, DB2, CICS, RACF) as much as possible. Of course, in that environment, the app doesn't connect directly to the database. That is handled by the subsystem (CICS or JES) that under which the app is running. Since those apps never has to issue a CONNECT, the developer never needs or even has the opportunity to see the keys to the kingdom.

Second, we have a mix of client-server apps (Oracle client is individual desktops) and web-based (oracle client is the web server -- test or production). The client server apps will eventually become web-based, but c/s will not be totally eliminated any time soon. Of course, we also have some packaged apps.

Third, developers do occasionally have legitimate need to get into prod DBs. Currently the approved procedure is for them to come to DBA when they have a need, and we create a special userid for them which we drop at the end of the day.

Fourth, the possibiility exists (though slim) to convince management that we can address their security concerns (in this case, developers having free access to production data) without haveing to "replicate" the policys and procedures used on the mainframe. I'd have to make a VERY solid case. Received on Thu Apr 11 2002 - 08:41:44 CDT