Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Protecting the Encryption Keys Expand / Collapse
Author
Message
Posted Thursday, September 3, 2009 9:29 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 6:20 PM
Points: 33,078, Visits: 15,192
Comments posted to this topic are about the item Protecting the Encryption Keys






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #782701
Posted Friday, September 4, 2009 1:46 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, June 3, 2014 8:16 AM
Points: 295, Visits: 1,011
I wonder how many uses the bank as the secondary storage place to safeguard their keys. Do you?
Post #782757
Posted Friday, September 4, 2009 4:48 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, March 14, 2013 7:50 PM
Points: 8, Visits: 35
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.
Post #782812
Posted Friday, September 4, 2009 11:37 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, November 2, 2009 8:46 AM
Points: 875, Visits: 313
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.
Post #783113
Posted Wednesday, October 7, 2009 3:00 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, May 19, 2014 10:09 AM
Points: 35, Visits: 257
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.
Post #799548
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse