[dba-SQLServer] Fwd: Security & encryption

Gareth Alexander gareth.alexander at donnslaw.co.uk
Wed May 11 10:58:11 CDT 2005


No, we can't trust her

HR

-----Original Message-----
From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] 
Sent: 11-May-2005 16:31
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
-------------- next part --------------

The contents of this message and any attachments are the property of Donns Solicitors 
and are intended for the confidential use of the named recipient only.  They may be legally
 privileged and should not be communicated to, or relied upon, by any other party without 
our written consent.  If you are not the addressee, please notify us immediately so that we 
can make arrangements for its return.  You should not show this e-mail to any person or
 take copies as you may be committing a criminal or civil offence for which you may be
 liable.  The statement and opinions expressed in this e-mail message are those of the 
writer, and do not necessarily represent that of Donns Solicitors.  Although any files attached
 to this e-mail will have been checked with virus protection software prior to transmission, 
you should carry out your own virus check before opening any attachment.  
Donns Solicitors does not accept any liability for any damage or loss which may be caused 
by software viruses...


More information about the dba-SQLServer mailing list