Roz Clarke
roz.clarke at donnslaw.co.uk
Wed May 11 10:31:01 CDT 2005
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...