[dba-SQLServer] Fwd: Security & encryption

Charlotte Foust cfoust at infostatsystems.com
Wed May 11 12:14:55 CDT 2005


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. :(

-----Original Message-----
From: Francisco Tapia [mailto:fhtapia at gmail.com] 
Sent: 11 May 2005 16:00
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Fwd: Security & encryption


Well this seems most appropriate, just hire a dba you can trust :)

---------- Forwarded message ----------
From: Mark Allison <markallison at gmail.com>
Date: May 11, 2005 2:12 AM
Subject: Re: Security & encryption
To: SQL Server 2k List <sql2k at ls.sswug.org>

Francisco,

I would approach this by recommending the HR department only encrypt the

data that really needs to be encrypted. This data should then be
encrypted 
at the front end using a private/public key algorithm akin to PGP. Then,
an 
entire department will be able to view the data with their own keys, and
you

could also encrypt the data to a "master" key used by HR in case
passwords 
get forgotten. There are APIs that allow a front-end developer to easily

accomplish this.

This way, the data can be joined on using keys, etc. However queries
against

encrypted data will not be possible without retrieving the entire data
set 
to the client, decrypting and then performing the work. For example
queries 
like, show me employees paid over 100K that take 5 or more days sick a
year 
would be network, db and client intensive. Indeed, the client machines
may 
not even be able to cope with this kind of question if the dataset is
large.

I don't know how much data you have, but this would need to be thought 
through, including scalability. How much will the data grow over the
next n 
years?

The other solution is to not encrypt the data, but secure the db server
and 
trust your DBAs. I worked in a large law firm (the world's largest, in
fact)

and had access to all employee data because the HR dept trusted the DBA 
team. However there were restrictions put in place such as:
a) The SQL Server was behind a firewall
b) The DBA and HR workstations were filtered by the firewall, everyone
else 
was denied access through port 1433
c) Logins inside SQL Server were only given to DBAs and HR

I prefer the latter approach as encryption can be messy and labour
intensive

when used in a DB. I think encryption is great for things like email and

documents, but searching and indexing this information becomes
difficult.

Mark.

On 10/05/05, Francisco Tapia <fhtapia at gmail.com> wrote:
> 
> I'm forwarding this message on to this list because I think the author
> of
> the original post would receive a better response from this group... I
am 
> also curious how a dba could encrypt a whole table (or set of tables)
and 
> lock themselves out of it.. :|
> 
> 
> ---------- Forwarded message ----------
> From: Roz Clarke < roz.clarke at donnslaw.co.uk>
> Date: May 10, 2005 2:04 AM
> Subject: Security & encryption
> To: 
> Hi all
> 
> This may or may not be slightly OT... We have been asked by our HR
> department whether it's possible for us to build a storage facility 
> for confidential data (such as salary information), that is encrypted 
> and that
> 
> neither we nor the network administrators could get into once it's
> gone live. Ideally it would be integrated with their current 
> application which is Access 2002 FE / SQL Server 7.0 BE.
> 
> How do I build an encrypted database that I can then lock myself out
> of
> completely?! Without locking everyone else out too (that I've done 
> before).
> 
> Management are willing to spend some money if necessary.
> 
> TIA
> 
> Roz
> 

-- 
-Francisco
http://pcthis.blogspot.com |PC news with out the jargon!
http://sqlthis.blogspot.com | Tsql and More...
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



More information about the dba-SQLServer mailing list