Re: Application security question

Hi,

    You shouldn't make the RDBMS responsible for physical security. The problem you describe can be resolved by making and enforcing rules that no terminals/PCs be left logged in to the database unless the person assigned the terminal or PC is at the keyboard.

    If management persists in wanting Oracle to assume the role of Rent-a-Cop you could always write routines in PL/SQL that would access the data only after checking the user id and password. In order to make this work you will probably have to limit the users to access only through views and not let them know the names of the underlying tables and columns.

    Of course you could always use Trusted Oracle, but I am not sure that Trusted Oracle or even a provably secure operating system will permit the type of checking you are seeking.

    The least expensive solution is to establish and enforce an access policy. After all if it is good enough for the intelligence community, it should be good enough for anyone -- although you can't throw people in jail for security violations and they can.

regards
Jerry Gitomer

Douglas Scott wrote in message ...
>My company has a requirement to validate that a user
>is really who they are suppose to be within a
>particular application. This is mainly caused by
>computers being in a shared area which means that
>someone could login to the database with their Oracle
>account and then another person access the application
>and make a change that that person would not be able
>to do if they were logged into the database using
>their own account. What we want to do is implement a
>second layer of security that will prompt the user for
>a password if they try to update an item that has been
>identified as a restricted item. Does anyone know of
>good way to do this? We don't want to store a password
>in a table that someone could see through sql.
>
>Thanks
>Douglas Scott
>
>
>
> -**** Posted from RemarQ, http://www.remarq.com/?c ****-
> Search and Read Usenet Discussions in your Browser
Received on Tue Jul 20 1999 - 20:43:49 CEST