Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQLServerCentral.com
»
Editorials
»
Encryption in Production
15 posts, Page 1 of 2
1
2
»»
Encryption in Production
Rate Topic
Display Mode
Topic Options
Author
Message
Steve Jones - SSC Editor
Steve Jones - SSC Editor
Posted Thursday, February 09, 2012 9:13 PM
SSC-Dedicated
Group: Administrators
Last Login: Today @ 5:09 AM
Points: 31,526,
Visits: 13,864
Comments posted to this topic are about the item
Encryption in Production
Follow me on Twitter:
@way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
Post #1250055
Gary Varga
Gary Varga
Posted Friday, February 10, 2012 1:56 AM
Hall of Fame
Group: General Forum Members
Last Login: Today @ 1:39 PM
Points: 3,619,
Visits: 1,230
As a developer, I often attempt to follow best practices for developing against/using databases, however, it is rarely within my remit to configure or maintain a database. In fact usually I have restricted or no access to database servers. (I can hear the DBAs cheer as do I. I usually have enough on my plate and am aware I do not have the expertise of a DBA so how on earth am I supposed to perform the duties of a DBA to the standards I demand of myself and would expect my clients to demand!!!)
That said, I cannot remember one instance of the application of TDE or the use of any other encryption beyond the encrypting of passwords.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1250098
william-683424
william-683424
Posted Friday, February 10, 2012 3:17 AM
Forum Newbie
Group: General Forum Members
Last Login: Monday, April 29, 2013 7:43 AM
Points: 1,
Visits: 39
I am busy investigating the pros and cons of encrypting the data at a database level with TDE or at a code level before it even reaches the database. I am very interested in what some of the more experienced developers and DBAs have to say on this topic.
Post #1250133
Jo Pattyn
Jo Pattyn
Posted Friday, February 10, 2012 4:13 AM
Ten Centuries
Group: General Forum Members
Last Login: Today @ 3:57 PM
Points: 1,333,
Visits: 4,418
Only when it is worked out and tested in detail.
From what I've read you have to be careful when changing/clearing keys (remnants in transactionlog?)
Post #1250165
Tobar
Tobar
Posted Friday, February 10, 2012 7:43 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Yesterday @ 1:15 PM
Points: 172,
Visits: 560
The identity information at this site has very limited access (it is only on the old mainframe), but it is freetext. Of course there was the report about one person who had access who was inadvertently leaving copies of that data in a public folder.
Recently I was called upon to create a database/application on SQL Server that would have indentity information. I am using native AES_256 encryption.
<><
Livin' down on the cube farm. Left, left, then a right.
Post #1250311
Richard Sisk
Richard Sisk
Posted Friday, February 10, 2012 7:48 AM
SSCommitted
Group: General Forum Members
Last Login: Friday, June 07, 2013 11:04 PM
Points: 1,894,
Visits: 206
I designed and developed commercial business software using SQL Server encryption to protect credit card data. The card data is encrypted with a symmetric key, the key is protected with an asymmetric key which itself is protected by a server level key so if the database is removed from the server, nothing can be read unless the keys are backed up from the server and restored on the new server.
It works quite well, we have key change procedures that are used to regularly update the keys. If a backup is stolen, it's no good unless they also know to steal the key backups which are stored protected on another device. It has passed several PA-DSS audits.
Using SQL encryption is so much easier than attempting this with third party encryption tools, which I have done in the past with prior implementations of credit card functionality.
Post #1250316
jkuemerle
jkuemerle
Posted Friday, February 10, 2012 7:59 AM
Forum Newbie
Group: General Forum Members
Last Login: Thursday, February 16, 2012 11:08 AM
Points: 3,
Visits: 32
Not to toot my own horn too much but since security is a huge interest of mine I do give presentations on using the built in encryption capabilities in SQL Server for doing things like encrypting personally identifiable information and correctly implementing password hashing. I have posted all of my demo code (as well as some simple applications that access the data) to CodePlex here: http://sqlcrypto.codeplex.com .
I'd be happy to answer any questions about the code. As for key management the two greatest things about encryption in SQL Server is how the keys (mostly) travel along with the database (including in backups) and how easy it is to change encryption keys as SQL will automatically decrypt/reencrypt the data with the appropriate keys when you update them.
Post #1250327
Jack Corbett
Jack Corbett
Posted Friday, February 10, 2012 8:16 AM
SSChampion
Group: General Forum Members
Last Login: Today @ 3:07 PM
Points: 10,613,
Visits: 11,959
I haven't used TDE or really any encryption in SQL Server. I prefer to have column level encryption done at the application level. I like the fact that the database is just storing the encrypted information and not responsible for encrypting/decrypting it. I really consider that something to e done in the business layer.
I would consider using TDE because it does protect your data at rest, so a stolen backup would not compromise your data, unless they get the keys as well.
Jack Corbett
Applications Developer
Don't let the good be the enemy of the best. --
Paul Fleming
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Post #1250344
TravisDBA
TravisDBA
Posted Friday, February 10, 2012 8:17 AM
Ten Centuries
Group: General Forum Members
Last Login: Wednesday, June 12, 2013 10:46 AM
Points: 1,290,
Visits: 3,001
Just make doubly sure you backup the Certs and all Master Keys in a very safe place(s) that you used to originally encrypt the data and restore those certs across your DEV,QA, and prod environments so your backups will restore and move across those environments with ease and without issue. Otherwise, you are up the creek without a paddle. Safe storage of all your Certs and Master keys are the "key" to encryption. Your job will depend on it, trust me. Also, test,test,test.
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...
"
Post #1250348
cfradenburg
cfradenburg
Posted Friday, February 10, 2012 9:47 AM
SSCommitted
Group: General Forum Members
Last Login: Wednesday, June 12, 2013 10:51 AM
Points: 1,562,
Visits: 1,932
Jack Corbett (2/10/2012)
I haven't used TDE or really any encryption in SQL Server. I prefer to have column level encryption done at the application level. I like the fact that the database is just storing the encrypted information and not responsible for encrypting/decrypting it. I really consider that something to e done in the business layer.
The other benefit to this is that if a SQL account is compromised they still don't have access to the encrypted data.
We've started looking into both TDE and third party tools for backups that support compression but haven't implemented it yet. Right now my focus is on selecting a tool that can encrypt backups (in addition to help with other backup management) since we don't have Enterprise on all machines and I'm expecting at least some of our vendors to push back on using TDE making it harder to actually implement than it should be.
Post #1250427
« Prev Topic
|
Next Topic »
15 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.