Re: Userid's/Passwords and Application Development

Applications like these should never connect as the schema that owns the data. The application should connect with some other account that is granted whatever privileges make sense (select only for reporting).

However, if you don't allow developers to connect as the schema that owns the data, then you take on the responsibility of making all data model changes?

Seems a better approach is to first have a test and production environment and go ahead and allow the developers to connect as the schema that owns the data. Then, have a good "change control" process where you review what they want to do in production before they change it.

Have you ever been a developer? Seems to me this should be required. Having a DBA that does not understand what developers do is not good. As a DBA, I see developers as my "customer" . Of course, I was a developer for a long time before being the DBA.

-- 
"Pete's" <empete2000_at_yahoo.com> wrote in message
news:6724a51f.0307110458.2d53a82a_at_posting.google.com...


> I've got a bunch of developers that think they need to have schema

> password to develop their apps.  Not only that, but, they hard code

> the userid/password in their web apps.  However, they are protecting

> the pages via Active Directory and a product called Directory

> Smart(DS).  Being a DBA for over 5 years, I believe that how they are

> using the Userid/Password is not an idustry acceptable practice and

> that they really don't know how Oracle Security works.  I'm trying to

> slightly change they way in which they develop so that any user

> logging into my DB's is not using a single userid/password(even if it

> is embedded).  Note that when they enter the page, DS requires them in

> some manner to be a trusted user.  My position is that DS protects the

> apps for being used by trusted users, but does not do enough to ensure

> protecting the database from a rogue user whether it be an internal or

> external user to the company.  The passwords that get embedded appear

> to not ever change, which is bad.  Another part of my position is that

> having this kind of setup, will never pass a real outside Audit.

>

> What I'm looking for is any sites/documents/information regarding

> Industry acceptable practices in the use of Userid/passwords in Oracle

> Databases.  If anyone has info regarding this, I would be grateful if

> you send me links or places to search.  I'm also in the CYA mode here

> because what's going on is not acceptable, i.e. letting the developers

> be responsible for protecting the data.

>

> My apologies it if sounds as if I'm venting.

>

> TIA,

> Pete's