September 3, 2009 at 9:29 pm
Comments posted to this topic are about the item Protecting the Encryption Keys
September 4, 2009 at 1:46 am
I wonder how many uses the bank as the secondary storage place to safeguard their keys. Do you?
September 4, 2009 at 4:48 am
In the entire discussion in response to my editorial I saw two reoccurring concerns:
1. Key backup location/complexity
Yes, indeed, you must store the key backups in a different location than the database backups. If they were stored on the same media or on a different media but kept in the same physical location (thrown in the desk drawer with the wind-up chattering teeth) they can be stolen together resulting in the keys and database being restored elsewhere and the sensitive data would be gleaned.
The backups of the keys are not something that must occur on a daily basis, unless you are changing your keys on a daily basis (which is a bit over the top). Does it increase the complexity of your backup strategy? It does; but not to an overbearing degree. You are implementing a new feature to your database. In doing so it does add to considerations and actions when it comes to recovery.
2. Key life cycle Management
Maintaining the strength of a key requires maintenance. Given an indefinite period of time a hacker can crack any key. Limit the time and it makes that potential much less of a possibility. Also, changing the key periodically will reduce the data that is protected by a given key which reduces the volume of data that could be compromised if the key is hacked. Key life cycle management can be challenging. There is no native functionality within SQL Server (nor should there be within the database) to provide key life cycle management other than offering Extensible Key Management (in SS2008). EKM allows you to use third party providers or devices for keys and key management.
Also, there was a lot of discussion regarding the password that protects the key and concern over "backing up" the password. Consider taking advantage of the full key hierarchy and take a look at the service master key as a means to protect your database master keys instead of a password.
September 4, 2009 at 11:37 am
JohnMagnabosco (9/4/2009)
In the entire discussion in response to my editorial I saw two reoccurring concerns:1. Key backup location/complexity
Yes, indeed, you must store the key backups in a different location than the database backups. If they were stored on the same media or on a different media but kept in the same physical location (thrown in the desk drawer with the wind-up chattering teeth) they can be stolen together resulting in the keys and database being restored elsewhere and the sensitive data would be gleaned.
The backups of the keys are not something that must occur on a daily basis, unless you are changing your keys on a daily basis (which is a bit over the top). Does it increase the complexity of your backup strategy? It does; but not to an overbearing degree. You are implementing a new feature to your database. In doing so it does add to considerations and actions when it comes to recovery.
2. Key life cycle Management
Maintaining the strength of a key requires maintenance. Given an indefinite period of time a hacker can crack any key. Limit the time and it makes that potential much less of a possibility. Also, changing the key periodically will reduce the data that is protected by a given key which reduces the volume of data that could be compromised if the key is hacked. Key life cycle management can be challenging. There is no native functionality within SQL Server (nor should there be within the database) to provide key life cycle management other than offering Extensible Key Management (in SS2008). EKM allows you to use third party providers or devices for keys and key management.
Also, there was a lot of discussion regarding the password that protects the key and concern over "backing up" the password. Consider taking advantage of the full key hierarchy and take a look at the service master key as a means to protect your database master keys instead of a password.
Another thing to consider is transference of keys to new media. In my career I have seen "safe" storage go from mylar tape backups to 9" disk platters to 5 1/4" floppies and magnetic tape backups and now to thumb drives. What will be next? It will mean recopying your data to the new media or risk losing the data because it cannot be retrieved.
October 7, 2009 at 3:00 pm
I'm a complete novice on encryption and confused by the statement:
Also, there was a lot of discussion regarding the password that protects the key and concern over "backing up" the password. Consider taking advantage of the full key hierarchy and take a look at the service master key as a means to protect your database master keys instead of a password.
I assume you could ALTER the master key to DROP the "password" encryption and retain only the SMK encryption of the master key. And then you could CREATE a CERTIFICATE based on the master key... But don't you still have to specify a password when you do the backup for the master key and private key of the certificate?
I guess what I'm saying is, I don't see that you've gotten away from the issue of storing passwords for the back up of the encrypted keys.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply