Francisco Tapia
fhtapia at gmail.com
Wed May 11 09:59:36 CDT 2005
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...