Re: Database Security

Brant wrote:

>I would like to discuss with anyone who has experience in Oracle database
>security. Any suggestion is also appreciate. Right now we are facing a very
>important issue in database developement. We use Oracle as our database
>server. In our application code we would like to have different roles enabled
>at different time. To do this we create different roles and grant them to all
>the users. By use: Alter User Default Role None, we disable all the roles from
>all the users and use Set Role command in the application code to enable
>different role at different time. It looks fine at the first look. However, if
>it happen that any of the users can get a chance to have a look of the source
>code, he would be able to grant a role to himself by writing his own
>application code. It is really a big hole in the security of Oracle database.
>We don't want the users to get any information from the application code. But
>it looks like that Oracle can't do anything about it. I would like to hear
>from you about this Security stuff in Oracle.

Once you give the user access to SQL*Net or the command line on your server there is no way to stop them. Given a user name and password they will be able to do anything that you must grant them the ability to do through your application.

The only airtight scheme is to place your database and applications on one server, capture the user in a menu system at login and use operating system logins only. This will prevent them from using anything but your applications. Of course this eliminates client/server apps. You could also take a hybrid approach and create two accounts for each user, one ops$username and one username/password. Grant select privs to the second and let them use SQL*Net for query apps only.

Moving as much of the validation/referential integrity into the database server helps keep the corruption to a minimum. The problem is that you can't move everything (given the cascade update problem), including the "Do you REALLY wish to delete all your data?" alerts. Backup well. A thought here is to archive log and use the SQL*Trax (tm) tool to find and undo specific transactions. Knowing that someone screwed up is the hard part.

I've heard of a couple schemes to hide info in the apps, such as modifying the password so the user doesn't know it to connect with later. This is more security through obscurity and is demonstratably weak. It may be worth looking into though, as it will keep out all but the more determined. Hopefully they will know enough not to screw things up too badly.

Let me know if you find anything better.

David Jordan Received on Tue Feb 07 1995 - 14:19:40 CET