Re: Security Question

Look into roles with passwords that you do not tell the users. =

The application can activate the roll and get rights to alter =

the data.

Having everyone log as the same user is generally a poor idea. =

It does not allow for traceability, and troubleshooting is a =

bear when all sessions show up as user DoeJ!

Bill Jonnard wrote:
> =
 

> How can I prevent a group of users from performing any kind of manual
> adjustments to the data, while still allowing them to use SQL*Plus to
> do ad hoc queries? Currently, I have multiple users, but only one
> Oracle user ID, so once somebody gets into SQL*Plus, I can=92t prevent
> them from performing manual inserts, etc. which I want to do.
> =
 

> If I set up a second Oracle ID that uses synonyms into the main
> database (and is only granted select privs on all the tables), the
> user could easily defeat this measure by logging into the "view-only"
> Oracle ID, and then running the "connect ID/password" command from the
> SQL prompt to get into the "main" database. Obviously, this isn=92t
> much of a solution. It would be useful to be able to somehow disable
> the connect command, and thus prevent someone from switching into one
> database from another, but I do not know how (or if) this is possible.
> =
 

> Similarly, it would appear that even if I were to set up separate
> Oracle IDs/roles for each specific user, someone could still run the
> "Connect ID/Password" command, and I=92d be back where I started.
> Again, I am unaware of any means to restrict a user to using a certain
> Oracle ID specified at the Operating System level, or how to somehow
> disallow "write access" to the database while still allowing "read
> access". (The OS is VMS)
> =
 

> Is there any way to let someone use SQL*Plus, but to absolutely
> prevent them from modifying the data unless they have been given the
> explicit "GRANT INSERT/DELETE/UPDATE" privs on that table? If anyone
> could give me a few pointers as to how to best solve these problems,
> I=92d appreciate it very much. Thanks in advance for any help.
Received on Wed Mar 27 1996 - 00:00:00 CET