Francisco Tapia
fhtapia at gmail.com
Thu May 12 11:14:42 CDT 2005
I found some additional information on encrypting tables and data for that matter, One article suggested to follow suit in the Label security that Oracle has laid out... http://www.oracle.com/technology//index.html Additionally this thread had some useful hints.. (duplicating relevant post) *Armstrong <http://www.sqlservercentral.com/forums/userinfo.aspx?id=30902>* *RE: Encryption with XP Crypt* Posted 2/11/2004 9:52:00 AM <http://www.sqlservercentral.com/forums/post.aspx?forumid=6&messageid=99857&edit=1> ** We are using xp_crypt to encrypt certain fields in our database. If you use this product and you want to "encrypt a particular table", you would do that by encrypting each field in the table separately. Because encryption and decryption take cpu time, I would suggest you encrypt only what is necessary. xp_crypt provides you with a .dll that provides you with some extended stored proceudres you can call from T-SQL. The parts of the product that I have used work as advertised. Technical support is by e-mail but is quite prompt. One of the issues that you will want to address early on is where to store your encryption keys. As you know, there are two basic types of encryption: *private key *and *public key*. Private key encryption uses the same key to both encrypt and decrypt. This makes it imperative that the key be kept secret, because anybody who has a copy of the key will be able to read your data. Because neither people nor computers are all that good at keeping secrets, some organizations even go so far as to place their private keys in hardware devices. The hardware device is designed to never reveal the key; rather you give it a string of data and the device does the encryption/decryption internally. This approach can provide very good security. One company which sells this kind of device is Rainbow Technologies (www.rainbow.com <http://www.rainbow.com/>). The devices work well but the implementation effort can be steep! (xp_crypt is MUCH simpler to use) Public key encryption uses a published key for encryption (the public key), and a different key for decryption (the private key). Public key encryption works well, is computationally intensive, and its encrypted data tends to take up a lot of space. We use it because it fits what we do: lots of people here need to encrypt data (order entry with credit card information), but only a few people need to decrypt (sending credit card info to the clearing house for payment). In other words, many people use a public key, but only a few use a private key so the key management is bearable. To sum up, we are using xp_crypt in a software-only solution because it was straightforward, not expensive, and was much better than storing sensitive information in the clear. However, hardware devices do provide better key management which helps security. Which one you choose would depend on your requirements and your budget. And of course more links re: rainbow http://www.safenet-inc.com/solutions/ent/HiSpeedEnc.asp?WT.MC_id=sol-hse00018 It also occured to me that there really are situations where data should remain encrypted such as banking info etc. Those databases SHOULD really be encrypted so that if they were hacked, the critical information would still remain safe. On 5/11/05, Charlotte Foust <cfoust at infostatsystems.com> wrote: > > Certainly, but that ability to render the data meaningless or deny > access ALWAYS exists in the dba, regardless of whether the data is > encrypted. If you can't trust a dba or you won't trust one to protect > your interests and your data, then you should be keeping your data > someplace other than in a database. > > Charlotte Foust > > > -----Original Message----- > From: nicholas van [mailto:nick at frasiervan.com] > Sent: Wednesday, May 11, 2005 11:00 AM > To: dba-sqlserver at databaseadvisors.com > Subject: RE: [dba-SQLServer] Fwd: Security & encryption > > 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. :( > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More...