这与通常询问此问题的方式略有不同 - 我使用以下方法创建数据库主密钥，证书和对称密钥：
以下是我创建证书/密钥的方法（显然是使用真实密码）：
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;
然后，我使用该密钥加密了一些数据，备份了数据库，并将其恢复到另一个框。
我的期望是，在我第一次从旧框中迁移服务主密钥之前，我无法解密数据，但实际上我可以在恢复后立即执行此操作，而无需提供单个证书或密码。
我推断这种情况正在发生，因为我使用的是Amazon EC2图像来创建框，所以我假设从该图像创建的每个框都有相同的服务主密钥。
为了尝试强制更改服务密钥，我跑了：
alter service master key regenerate
。
我重新开始使用新数据库，新密钥/证书等，这次，当我将备份移动到新框时，我无法自动读取数据，但我必须先提供密码对于我创建的数据库主密钥。一旦我这样做，我就能得到数据。
从我阅读的所有内容中，我认为如果不首先移动服务主密钥，我将无法解密主密钥。
我担心不需要服务主密钥仍然是由于我的测试环境奇怪，而且当我尝试真正做到这一点时，我可能会被搞砸一年。
任何人都可以了解这里发生的事情吗？ SQL中有什么变化导致不必移动服务主密钥，或者我是否以不必要的方式创建数据库主密钥？或者我是否会收回可能错误的结果？
答案 0 :(得分：0)
Matt Bowler在数据库加密方面非常出色article。问题可能是服务器主密钥加密的方式。您的实例是否可能由同一服务帐户运行？
服务主密钥：密钥层次结构的顶部是服务主密钥。每个SQL Server实例有一个，它是一个对称密钥，它存储在master数据库中。用于加密数据库主密钥，链接服务器密码和凭据，它是在第一次SQL Server启动时生成的。
没有与此密钥关联的用户可配置密码 - 它由SQL Server服务帐户和本地计算机密钥加密。在启动时，SQL Server可以使用这些解密之一打开服务主密钥。如果其中一个失败 - SQL Server将使用另一个并“修复”失败的解密（如果两者都失败 - SQL Server将出错）。这是为了解决故障转移后本地计算机密钥不同的群集等情况。这也是使用SQL Server配置管理器更改服务帐户的一个原因 - 因为这样可以正确地重新生成服务主密钥加密。