迁移后是否不需要还原SQL服务主密钥即可解密数据？

Question

This is a bit of the opposite of how this question is usually asked-- I used the following to create a database master key, a certificate, and a symmetric key:

Here's how I created the certs/keys (obviously with real passwords):

CREATE MASTER KEY ENCRYPTION
BY PASSWORD = '123456'

CREATE CERTIFICATE EncryptionCert
WITH SUBJECT = 'EncryptionCert'

CREATE SYMMETRIC KEY SymmetricKey
WITH ALGORITHM = AES_256
ENCRYPTION BY CERTIFICATE EncryptionCert;

I then encrypted some data using that key, backed up the database, and restored it to a different box.

My expectation was that I wouldn't be able decrypt the data until I first migrated the service master key from the old box, but I actually was able to do that immediately after restoring without providing a single cert or password.

I deduced that this was happening because I was using an Amazon EC2 image to create the box, so I'm assuming that EVERY box created from that image had the same service master key.

To try to force the service key to change, I ran:

alter service master key regenerate

on both boxes.

I started over with a new database, new keys/certs etc, and this time, when I moved the backup to the new box, I wasn't able to automatically read the data, but I had to first provide the password for the database master key that I created. Once I did that, I was able to get to the data.

From everything I read, I would have thought that I wouldn't be able to decrypt the master key without moving the service master key first.

I'm concerned that the service master key not being required is still due to an oddity of my test environment, and that I might get screwed in a year when I try to do this for real.

Can anyone shed light on what's happening here? Did something change in SQL that made it unnecessary to move the service master key, or did I create the database master key in a way that made moving it unnecessary? Or am I getting back potentially false results?

Answer 1

Matt Bowler has en excellent article on database encryption. The issue may be the way the Server Master Key is encrypted. Is it possible that your instances are run by the same service account?

Service Master Key: At the top of the key hierarchy is the Service Master Key. There is one per SQL Server instance, it is a symmetric key, and it is stored in the master database. Used to encrypt Database Master Keys, Linked Server passwords and Credentials it is generated at first SQL Server startup.

There are no user configurable passwords associated with this key – it is encrypted by the SQL Server service account and the local machine key. On startup SQL Server can open the Service Master Key with either of these decryptions. If one of them fails – SQL Server will use the other one and 'fix' the failed decryption (if both fail – SQL Server will error). This is to account for situations like clusters where the local machine key will be different after a failover. This is also one reason why service accounts should be changed using SQL Server Configuration Manager – because then the Service Master Key encryption is regenerated correctly.

http://mattsql.wordpress.com/2012/11/13/migrating-sql-server-databases-that-use-database-master-keys/