Field level security

Last Post 22 Mar 2010 07:45 AM by rm. 3 Replies.
AddThis - Bookmarking and Sharing Button Printer Friendly
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
PaulMcKibben
New Member
New Member

--
21 Mar 2010 11:23 AM
I need to secure certain fields, Name, SSN, for example, in a table's rows. 

I know about SQL encryption, but is there another way to secure the individual fields, or cells, in a table row?  I have read the "Implementing Row- and Cell-Level Security in Classified Databases Using SQL Server 2005"  The do***ent does not cover cell level security in any detail without encryption.

Anyone know of any other methods to secure fields at the database level, by chance?

Thank you
rm
New Member
New Member

--
21 Mar 2010 12:28 PM
You can grant/revoke permission for specific column.
PaulMcKibben
New Member
New Member

--
21 Mar 2010 05:27 PM
If I revoke permissions, like Select, from a field, though, my understanding is that no one will be able to retrieve the data from that field. 

I need to block certain data, like SSN, from being displayed by default.  If certain users have the right permissions, they will be able to see the data.

I understand putting the different users in different windows groups and giving each group different security. 

I have found references of how to secure down rows in a table, applying different levels of security to the database and table, and know about encryption.  My belief is that there has to be a way to secure the field. 

Maybe another table that lists the sensitive field names and what level of security they need to be visible and a table of users and their level of security.  If someone believes that that is possible, then my question would be how to join the "field" table to verify that the data should be displayed.

Thank you
rm
New Member
New Member

--
22 Mar 2010 07:45 AM
You can revoke permission to specific db user only, that will not affect other users.
You are not authorized to post a reply.

Acceptable Use Policy