SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Protecting the Encryption Keys


Protecting the Encryption Keys

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (248K reputation)SSC Guru (248K reputation)SSC Guru (248K reputation)SSC Guru (248K reputation)SSC Guru (248K reputation)SSC Guru (248K reputation)SSC Guru (248K reputation)SSC Guru (248K reputation)

Group: Administrators
Points: 248674 Visits: 19807
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
My Blog: www.voiceofthedba.com
IceDread
IceDread
SSCommitted
SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)

Group: General Forum Members
Points: 1521 Visits: 1145
I wonder how many uses the bank as the secondary storage place to safeguard their keys. Do you?
JohnMagnabosco
JohnMagnabosco
SSC Journeyman
SSC Journeyman (90 reputation)SSC Journeyman (90 reputation)SSC Journeyman (90 reputation)SSC Journeyman (90 reputation)SSC Journeyman (90 reputation)SSC Journeyman (90 reputation)SSC Journeyman (90 reputation)SSC Journeyman (90 reputation)

Group: General Forum Members
Points: 90 Visits: 36
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.
notquitexena
notquitexena
Ten Centuries
Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)

Group: General Forum Members
Points: 1309 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.
Damon Falconi-345992
Damon Falconi-345992
SSC-Enthusiastic
SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)

Group: General Forum Members
Points: 153 Visits: 277
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.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum







































































































































































SQLServerCentral


Search