Re: logon best practices???

Hi Ed,

What I would do:
Use ops$ accounts for end-users/operators. The schema of course resides in a non-ops$ account and is accessed by synonyms. This allows the end-user to connect with a simple /, so no hardcoded passwords.
Of course these accounts should be disabled from the sqlplus/odbc level by - creating a role for normal application access. This role is not enabled by default, it is enabled by the application. - creating a role for ODBC access. This role has select privileges only. It's the only role enabled by default.
Of course there is integrity by constraints and triggers on the application schema.
Then I would have normal accounts for developers, so accounts with passwords.
The philosophy behind this is partly, if you have been able to break NT/Unix security already, nothing is safe for you. Having no-hardcoded passwords in the application adds security. Another reason for this is quite often you want to be able to track who issued that insert/update/delete. Running everything on one single account is not allowing you to do this. Of course this is all IMO.

Hth,

Sybrand Bakker, Oracle DBA

Ed Stevens <Ed.Stevens_at_nmm.nissan-usa.com> wrote in message news:7pjsvp$u3t$1_at_nnrp1.deja.com...
> I'm sure this issue has been beat to death before, so please bear with
> me. I'm seeking "best practice" ideas for logon security for Oracle
> databases in an NT environment.
>
> Currently, we are having applications use a single, common userid (say,
> "AppUser") to log on to the databases. Obviously, we do not wish for
> that userid/pswd to become known because with it a user could use
> Excel, Access or any other tool to connect to the database with full
> update authority and without the constraints imposed by the
> applications. We have separate development projects going on in
> Powerbuilder, Visual Basic, and Cobol. The problem is how to deliver
> the userid and (more importantly) the password to the applications from
> a central "repository" so that they don't have to hard-code them into
> the app.
>
> So, my question is "how do your home-grown apps know what user-id/pswd
> to use and how do you secure this information from the general user
> community? Secondly, do you make any attempt to hide the password from
> the application developers?"
>
> Could the use of roles be part of the solution? If so, how?
>
> TIA.
>
> Ed Stevens
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
Received on Fri Aug 20 1999 - 12:29:18 CDT