Last week we began a series of blogs with questions from our recent webinar titled “Encryption Key Management with Microsoft SQL Server 2008”. If you missed part one, you can view it now. We talked about the performance impacts of TDE (Transparent Data Encryption) on Microsoft SQL Server 2008. This time we will talk about how often you need to rotate your encryption keys on your SQL Server and whether your database gets locked during Cell Level or Column Level encryption during the re-encryption process. Additionally, we will touch on how we can help users that have both Microsoft SQL and Oracle environments. Without further delay, here are the questions:
How often do keys need to be changed? During Cell Level or Column Level encryption, will the database be locked during the re-encryption process?
With Cell Level encryption you can roll keys without bringing down your database. When you establish a symmetric key in Alliance Key Manager, our encryption key management appliance, you can establish how frequently you want that key to be rolled over, rotated, or changed (which all mean generate a new key) for use by the database. Alliance Key Manager implements support for both automated and manual key rollover, and if you are using Cell Level encryption in Microsoft SQL Server, you can take advantage of that. The broader question about how often you should change keys in your database is a really interesting one. There is no simple answer to that. If you are familiar with PCI DSS you know that particular question got a little more complicated in version 2.0. Basically, you have to establish a crypto-period for your keys. I think NIST would say two years is probably the maximum for the usage period of a key. Five years on the outside for a key to be used, even for the decryption of previously protected data. The bottom line is you have to establish a crypto-period for your keys and then implement that as policy. We support that process by letting you define how frequently keys should be changed and then managing that process for you automatically.
With TDE, the answer is a little bit different. TDE requires some manual steps to roll keys, but we fully support multiple keys and rolling keys with our encryption key management appliance.
Does your Alliance Key Manager Enterprise Edition serve keys to Oracle databases as well?
Yes. We provide encryption keys across a wide set of databases, applications, and servers. We have customers today who are protecting Oracle databases using our Alliance Key Manager to store encryption keys. We provide sample code that shows how to do that - same thing with MySQL, DB2 from IBM, and almost every standard database that you might run into. We also make it easy for customers who are using a variety of development languages to implement encryption.
If you are using SQL Server EKM, you really get a big win because it doesn’t take any programming at all to implement TDE. So that is the “easy button” in terms of encryption. Additionally, if you have written applications in Java that use SQL Server, Oracle, or MySQL, we provide Java examples - full applications in fact - on how to use them. If you programmed in C#, VBNET, Perl, Python, or PHP, we have sample code that really helps customers get up and running very quickly with our key management solution.
Stay tuned for our next post on encryption key management in High Availability (HA) and disaster recovery scenarios. In the meantime, you can view a recording of “Encryption Key Management with Microsoft SQL Server 2008”