Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Userid's/Passwords and Application Development

Re: Userid's/Passwords and Application Development

From: Van Messner <vmessner_at_bestweb.net>
Date: Fri, 11 Jul 2003 18:52:07 -0400
Message-ID: <vgug1qn89ebi10@corp.supernews.com>


It partly depends on how your databases are organized. In our case single databases support multiple projects although some parts of some projects may interlink with one another.

For project X we have three accounts:

schema X owns the non-code objects - tables, sequences, etc. Developers send their script to the DBAs who run them. Only DBAs have password in devl test and prod. DBAs also check scripts for standards and good practices.

schema X_APP owns the code objects - packages, functions etc. In devl, developers have the password. In test and prod they do not. X_APP has privileges to whatever objects in schema X (and possibly other schemas) that X_APP needs.

user X_USER owns no objects and has rights to use objects in X_APP and sometimes to use (but not alter) objects in other schemas.

Van

"Burton Peltier" <burttemp1REMOVE_THIS_at_bellsouth.net> wrote in message news:vhCPa.1995$_j.76_at_fe05.atl2.webusenet.com...
> 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
>
>
>
Received on Fri Jul 11 2003 - 17:52:07 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US