Re: Database security methods?

In article <3oll73$f4r_at_huey.cadvision.com> yeer_at_cadvision.com (Doris Jetz) writes:
>In article <MIKEE.95May4083842_at_sys8.wfc.com>,
>mikee_at_wfc.com says...
>
>>Hi,
 

>>I'm looking for everyone's opinions on database security
>>implementation methods. I have considered using schemas and using a
>>security table.
 

>>schemas:
>>create one schema for the logical database
>>create N schemas for N groups that have different
>> permissions/capabilities
>>grant users access to one or more of the security schemas
 

>>security table:
>>create table with name and password
>>create table with all possible module names
>>create table that relates users with modules with an individual access
>> lever per module
 

>>This is what I've thought of so far. Anyone have any opinions or
>>different ideas?
>
>What database are you using? If it is oracle, why don't you use
>roles? You can create roles and assign all kinds of object and
>system privilegs to the roles and then assign the role to the users.
>The roles can be protected by passwords.
>
>This makes administration much easier and can leave you with a fairly
>secure database.
>
>Doris

I have to agree with Doris. Why reinvent the wheel, especially if you might might make it worse. Database people have been working on these problems for years. Also, there's an interesting situation you are describing with the second option. If you put user id's and passwords in a database table, then that table should be more secure than any other table of yours. But then why not apply that same level of security to all your tables? Do you see the problem? Typically, the security of a schema would be the sum of the security of each object in the schema. In the second case described above, the security of the entire schema can be reduced to the security of only one table. Not a good situation.

Best,

Ted Karas   Received on Thu May 11 1995 - 00:00:00 CEST