nicholas van
nick at frasiervan.com
Wed May 11 12:59:44 CDT 2005
Mark has covered most of the main design points. As always, Higher Security = Greater Inconvenience I think it may be interesting to clarify what is meant by not letting the sysadmins and DBA get into the data. Even if the data itself is encrypted the DBA and System adminstrators will have the enough access to seriously compromise the integrity of the data. Even if you cannot know the exact data because it is encrypted, we are talking about people who can effectively deny access to all others, or in other ways render the data meaningless. As was pointed out with the encyption scheme, the most important point of control is to make sure that the people who have access to the encrypted data do not also have access to the encryption keys. Where we are right now we deal with some confidential data and we make sure the people with the devryption key access do not have database access, and vice versa. ---------- Original Message ---------------------------------- From: "Charlotte Foust" <cfoust at infostatsystems.com> Reply-To: dba-sqlserver at databaseadvisors.com Date: Wed, 11 May 2005 10:14:55 -0700 >Somehow, I think you're going to have to work out a compromise with >them. Could you promise not to peek, wear a blindfold when the table is >open, point out that they get a dba with the database, not one from >column A OR one from column B? <g> > >Charlotte Foust > > >-----Original Message----- >From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] >Sent: Wednesday, May 11, 2005 8:31 AM >To: 'dba-sqlserver at databaseadvisors.com' >Subject: RE: [dba-SQLServer] Fwd: Security & encryption > > >I AM a DBA I can trust!!! But HR sadly don't feel the same way. :( >