Does the certificate matter for TDE? Apparently not as I found a number of people discussing the fact that the expiration date for certificates is not checked for TDE restores. So if your certificate expires, you can still restore the TDE backup.
However the documentation doesn’t mention this, and I think it ought to be clarified, so I submitted this Connect item. Feel free to vote if you agree:
We have to learn to use better encryption than this.
SQL Server has become a very complicated product, with so many subsystems and features that I don’t know anyone that is an expert in all of them. There are lots of people that become somewhat familiar with many features, and learn to understand enough to use them competently. However there is one area that seems to confuse many people, but is one area that is also quite important to a secure SQL Server: encryption.
It seems that the idea of encryption is easy, but once we get into the actual practice of managing keys, indexing encrypted columns, and dealing with disaster recovery techniques, encryption quickly becomes complex. If the technical people managing servers struggle to deal with encryption, what hope does the average user have to implement encryption? Likely little to no hope of doing it well, which is a problem as many end users will have data on their machines. TDE is supposed to make this easy, but it solves only certain problems and isn’t available in all editions.
I ran across a very interesting article in the Economist on what a general understanding of what encryption means in a practical sense. The article is somewhat based on the Dropbox issues I wrote about recently, but also speaks to the general misunderstanding many people have about what encryption actually means.
I’ve always been hesitant to implement encryption widely, mostly because of the problems of managing keys. Keeping track of them, ensuring they are safe, in multiple places, and easily deployed in a DR situation, is a complex task, and making a mistake can have permanent consequences.
I don’t know how to both maintain security, and also implement enough safety to ensure access to encrypted data is available, but I do know that this is a task data professionals need to learn to accomplish.
It surprises me how often I see people posting questions about what type of encryption to implement for credit card data. If you are processing credit cards yourself, and storing the data, you need to comply with the PIC regulations that exist. Here’s a good place to get started: https://www.pcisecuritystandards.org/. Actually the place you need to start is with your bank or processing company. They should be able to guide you in what requirements need to be met for safe data storage. However if you’re running some service and perhaps trying to store a credit card for a customer to make it easy to charge them over and over, that doesn’t mean you don’t need to comply. You are holding financial information about a customer and if something happens to the data, you’re at fault. Your company could be liable, and possibly even you personally if you make the recommendation to build something yourself. Good security isn’t magical, and it isn’t secret. It involves you using well known algorithms, protecting the keys, and following best practices. There are some great encryption technologies in SQL Server 2005/SQL Server 2008, but don’t just implement them without learning a few things about what best practices are and how these technologies work.
Encryption is a tough subject, but it’s one that’s fascinated me for years. I downloaded PGP when it came out nearly two decades ago, and learned about the intricacies of symmetric and asymmetric keys. I thought it was fun, even when I couldn’t convince many people to consider using it.
Last year at PASS I ran into Michael Coles, who I’ve known for a few years and had just finished tech reviewing a book for. He was planning on a new book and asked me if I’d be interested in doing another one, this one on encryption. I jumped at the chance, and sometime this past spring started getting chapters.
I knew a lot, but had to learn a lot as well. I spent a lot of time Googling various terms and double checking historical references as well as algorithms and terms. I think I did a good job, and Michael and his co-author, Rodney Landrum, did a fantastic job.
I found a package on my desk this morning, and opened it to find my copy of the book. It’s now out, and available in bookstores, including Amazon.
So check it out, and learn a bit about this very important topic for DBAs. Not a lot of companies use encryption, but the ease of administration has grown with SQL Server 2008 and more companies are using it every day. I expect to see it start coming up in interviews soon.
Voice of the DBA 