July 16, 2014 at 5:04 am
The Dixie Flatline (7/15/2014)
Sometimes I think MVPs are a real pain in the ***. Present company excepted.
I agree
July 16, 2014 at 5:05 am
GilaMonster (7/16/2014)
Jeff Moden (7/15/2014)
To be honest, I'm glad this person is taking such caution and has such FUD about it.I would be, if he were worrying in the right area, but he's not. The technical aspect of encryption is the easy part. The key management, the who are you protecting the data against, the what risks are you trying to mitigate, etc, that's the hard part of encryption.
Completely agree with Gail. Key management is hard.
July 16, 2014 at 7:35 am
Lynn Pettis (7/11/2014)
Sean Lange (7/11/2014)
I am about to head of here for the week. Then Sunday starts 3 days at Webelos camp with my oldest. I will be outside fending off the heat and mosquitoes. See you all next Wednesday.Have much fun!!
Thanks Lynn. We had a blast. Kind of a bummer to come back to reality and my desk today but at least it is with a refreshed mind after spending the last 3 days outside at an awesome camp.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
July 16, 2014 at 7:49 am
The Dixie Flatline (7/15/2014)
Sometimes I think MVPs are a real pain in the ***. Present company excepted.
I agree
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 16, 2014 at 7:50 am
Sean Lange (7/16/2014)
Lynn Pettis (7/11/2014)
Sean Lange (7/11/2014)
I am about to head of here for the week. Then Sunday starts 3 days at Webelos camp with my oldest. I will be outside fending off the heat and mosquitoes. See you all next Wednesday.Have much fun!!
Thanks Lynn. We had a blast. Kind of a bummer to come back to reality and my desk today but at least it is with a refreshed mind after spending the last 3 days outside at an awesome camp.
Sean, I know exactly what you mean. I just had a week's vacation when my wife was between jobs, I'm back for 2 weeks and I'm off for another week next week. It was nice, but hard to come back. I really do enjoy my job a lot, but it sure is nice to not have to worry about most things for a whole week.
July 16, 2014 at 8:06 am
I am glad to see others jumping to help WC. I thought there was an article on SSC that actually covered this as well but my Google-fu isn't working well on this site to find it.
July 16, 2014 at 8:48 am
Steve Jones - SSC Editor (7/16/2014)
GilaMonster (7/16/2014)
Jeff Moden (7/15/2014)
To be honest, I'm glad this person is taking such caution and has such FUD about it.I would be, if he were worrying in the right area, but he's not. The technical aspect of encryption is the easy part. The key management, the who are you protecting the data against, the what risks are you trying to mitigate, etc, that's the hard part of encryption.
Completely agree with Gail. Key management is hard.
I think encryption should be done in the app, not the database. I think Jeff mentioned it in that thread, that if encryption is happening in the database it means everything is being passed over the wire in clear text. Just something I'd rather see not happen. The only issue is if you do reporting using another tool and have to work out decrypting those values in the reporting tool (SSRS even).
Jack Corbett
Consultant - Straight Path Solutions
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
July 16, 2014 at 8:49 am
SQLRNNR (7/16/2014)
The Dixie Flatline (7/15/2014)
Sometimes I think MVPs are a real pain in the ***. Present company excepted.I agree
I wouldn't except present company all the time.
Jack Corbett
Consultant - Straight Path Solutions
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
July 16, 2014 at 8:51 am
Jack Corbett (7/16/2014)
SQLRNNR (7/16/2014)
The Dixie Flatline (7/15/2014)
Sometimes I think MVPs are a real pain in the ***. Present company excepted.I agree
I wouldn't except present company all the time.
I didn't say which part I agreed with. :hehe::-D;-)
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 16, 2014 at 8:59 am
Steve Jones - SSC Editor (7/16/2014)
GilaMonster (7/16/2014)
Jeff Moden (7/15/2014)
To be honest, I'm glad this person is taking such caution and has such FUD about it.I would be, if he were worrying in the right area, but he's not. The technical aspect of encryption is the easy part. The key management, the who are you protecting the data against, the what risks are you trying to mitigate, etc, that's the hard part of encryption.
Completely agree with Gail. Key management is hard.
Yes, me too. And I think this one will be in trouble when his certificate expires - he hasn't asked about expiry dates or how to deal with changing keys at all yet, so key management hasn't occurred to him yet.
Actually I don't think key management is particularly hard; it's a real pain in the neck, and an operational nightmare, but it's all pretty simple in principle and the technical side of it is not abstruse or esoteric. But deciding who you are protecting against and what risks you want to mitigate and what levels of risk are acceptable is very hard indeed.
Tom
July 16, 2014 at 9:27 am
TomThomson (7/16/2014)
Steve Jones - SSC Editor (7/16/2014)
GilaMonster (7/16/2014)
Jeff Moden (7/15/2014)
To be honest, I'm glad this person is taking such caution and has such FUD about it.I would be, if he were worrying in the right area, but he's not. The technical aspect of encryption is the easy part. The key management, the who are you protecting the data against, the what risks are you trying to mitigate, etc, that's the hard part of encryption.
Completely agree with Gail. Key management is hard.
Yes, me too. And I think this one will be in trouble when his certificate expires - he hasn't asked about expiry dates or how to deal with changing keys at all yet, so key management hasn't occurred to him yet.
Actually I don't think key management is particularly hard; it's a real pain in the neck, and an operational nightmare, but it's all pretty simple in principle and the technical side of it is not abstruse or esoteric. But deciding who you are protecting against and what risks you want to mitigate and what levels of risk are acceptable is very hard indeed.
It shouldn't be hard at all to decide about the specific instance he's talking about. He wants to encrypt Social Security Numbers and there are laws governing this that are very strict. He should be able to just look up required policy and follow that.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
July 16, 2014 at 9:38 am
Jack Corbett (7/16/2014)
Steve Jones - SSC Editor (7/16/2014)
GilaMonster (7/16/2014)
Jeff Moden (7/15/2014)
To be honest, I'm glad this person is taking such caution and has such FUD about it.I would be, if he were worrying in the right area, but he's not. The technical aspect of encryption is the easy part. The key management, the who are you protecting the data against, the what risks are you trying to mitigate, etc, that's the hard part of encryption.
Completely agree with Gail. Key management is hard.
I think encryption should be done in the app, not the database. I think Jeff mentioned it in that thread, that if encryption is happening in the database it means everything is being passed over the wire in clear text. Just something I'd rather see not happen. The only issue is if you do reporting using another tool and have to work out decrypting those values in the reporting tool (SSRS even).
Doing decryption in the database doesn't necessarily mean that stuff on the wire is in plaintext. In a lot of systems (including some outdated versions of Windows) it's possible to have an encryption layer in the comms stack immediately above transport, so that everything on the wire - even stuff not encrypted in storage - is encrypted. I don't know whether current versions of windows support this, but I imagine they do. A lot of people believe that the risk of data bing intercepted on the wire is much higher than the risk of someone gaining access to data on storage media and insist on everything being encrypted on the wire whether it's encrypted in strorage or not. And third party apps are often a nightmare from the point of view of encryption in the app. I guess encryption in the app is sometimes better than encryption in teh db, but not very often.
Tom
July 16, 2014 at 9:47 am
Stefan Krzywicki (7/16/2014)
TomThomson (7/16/2014)
Steve Jones - SSC Editor (7/16/2014)
GilaMonster (7/16/2014)
Jeff Moden (7/15/2014)
To be honest, I'm glad this person is taking such caution and has such FUD about it.I would be, if he were worrying in the right area, but he's not. The technical aspect of encryption is the easy part. The key management, the who are you protecting the data against, the what risks are you trying to mitigate, etc, that's the hard part of encryption.
Completely agree with Gail. Key management is hard.
Yes, me too. And I think this one will be in trouble when his certificate expires - he hasn't asked about expiry dates or how to deal with changing keys at all yet, so key management hasn't occurred to him yet.
Actually I don't think key management is particularly hard; it's a real pain in the neck, and an operational nightmare, but it's all pretty simple in principle and the technical side of it is not abstruse or esoteric. But deciding who you are protecting against and what risks you want to mitigate and what levels of risk are acceptable is very hard indeed.
It shouldn't be hard at all to decide about the specific instance he's talking about. He wants to encrypt Social Security Numbers and there are laws governing this that are very strict. He should be able to just look up required policy and follow that.
True enough, he ought to be able to look that stuff up - - just as he ought to be able to look up the four BoL pages he needs to understand to do the encryption. If looking up those very straightforward pages with lots of nice examples was too much I'm sure looking up the SSN stuff will be too - especially given that the precedents do not indicate that many US corporations find it easy to understand the rules for use of SSNs.
Tom
July 16, 2014 at 10:19 am
TomThomson (7/16/2014)
Jack Corbett (7/16/2014)
Steve Jones - SSC Editor (7/16/2014)
GilaMonster (7/16/2014)
Jeff Moden (7/15/2014)
To be honest, I'm glad this person is taking such caution and has such FUD about it.I would be, if he were worrying in the right area, but he's not. The technical aspect of encryption is the easy part. The key management, the who are you protecting the data against, the what risks are you trying to mitigate, etc, that's the hard part of encryption.
Completely agree with Gail. Key management is hard.
I think encryption should be done in the app, not the database. I think Jeff mentioned it in that thread, that if encryption is happening in the database it means everything is being passed over the wire in clear text. Just something I'd rather see not happen. The only issue is if you do reporting using another tool and have to work out decrypting those values in the reporting tool (SSRS even).
Doing decryption in the database doesn't necessarily mean that stuff on the wire is in plaintext. In a lot of systems (including some outdated versions of Windows) it's possible to have an encryption layer in the comms stack immediately above transport, so that everything on the wire - even stuff not encrypted in storage - is encrypted. I don't know whether current versions of windows support this, but I imagine they do. A lot of people believe that the risk of data bing intercepted on the wire is much higher than the risk of someone gaining access to data on storage media and insist on everything being encrypted on the wire whether it's encrypted in strorage or not. And third party apps are often a nightmare from the point of view of encryption in the app. I guess encryption in the app is sometimes better than encryption in teh db, but not very often.
Wham-o, course change in midstream. Now we are suddenly talking SSIS in the same thread with little info to start.
July 16, 2014 at 10:26 am
Steve Jones - SSC Editor (7/16/2014)
GilaMonster (7/16/2014)
Jeff Moden (7/15/2014)
To be honest, I'm glad this person is taking such caution and has such FUD about it.I would be, if he were worrying in the right area, but he's not. The technical aspect of encryption is the easy part. The key management, the who are you protecting the data against, the what risks are you trying to mitigate, etc, that's the hard part of encryption.
Completely agree with Gail. Key management is hard.
There are two really hard things in programming: naming things, cache invalidation, and off-by-one errors.
Jason Wolfkill
Viewing 15 posts - 44,641 through 44,655 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply