0

这与通常问这个问题的方式有点相反——我使用以下内容来创建数据库主密钥、证书和对称密钥：

这是我创建证书/密钥的方式（显然是使用真实密码）：

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 中是否发生了一些变化，使得不需要移动服务主密钥，或者我是否以不需要移动它的方式创建了数据库主密钥？还是我得到了潜在的错误结果？

4

1 回答 1

0

Matt Bowler 有一篇关于数据库加密的优秀文章。问题可能是服务器主密钥的加密方式。您的实例是否有可能由同一个服务帐户运行？

服务主密钥：密钥层次结构的顶部是服务主密钥。每个 SQL Server 实例都有一个，它是一个对称密钥，存储在主数据库中。用于加密在第一次 SQL Server 启动时生成的数据库主密钥、链接服务器密码和凭据。

没有与此密钥关联的用户可配置密码 -它由 SQL Server 服务帐户和本地计算机密钥加密。在启动时，SQL Server 可以使用这些解密中的任何一个打开服务主密钥。如果其中一个失败 - SQL Server 将使用另一个并“修复”失败的解密（如果两者都失败 - SQL Server 将出错）。这是为了解决故障转移后本地机器密钥不同的集群等情况。这也是应该使用 SQL Server 配置管理器更改服务帐户的原因之一——因为这样服务主密钥加密会正确重新生成。

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

于 2015-01-03T22:47:40.997 回答