关于 TDE 和 AlwaysOn 可用性组的困惑答案

【问题标题】：Confusion about TDE and AlwaysOn Availability Groups关于 TDE 和 AlwaysOn 可用性组的困惑
【发布时间】：2016-03-29 16:52:12
【问题描述】：

这是我的第一篇文章，所以我会很简短。我有两台 SQL 2014 Enterprise 服务器；一个主副本和一个辅助副本。这是一个多租户部署，每个租户都有单独的数据库。（没有共享数据库或共享模式）。我目前有一个 AlwaysOn 可用性组启动并运行（更多后续）。我有 TDE 要求。我有我们的 CA 颁发的 SSL 证书。它安装在麻烦的 SQL 服务器上。我已将其转换为 .PVK 格式。我已准备好在两台服务器上使用相同的 .PVK 实现数据库加密

混淆的地方：

我是否必须像在正常的基于仲裁的故障转移集群中那样将 SSL 证书缩略图导出到辅助服务器注册表？
我必须先在主 SQL 服务器上创建一个主密钥，然后才能从文件创建新的 TDE 证书。我不明白辅助副本服务器如何影响这种情况。我需要在辅助服务器上可以访问加密的数据库。由于我正在处理不同的主数据库，我是否必须在辅助服务器上创建另一个主密钥？我仍然可以在辅助服务器上为 TDE 使用相同的 .PVK 证书吗？

如果有任何见解或指导，我将不胜感激。非常感谢。直流

【问题讨论】：

标签： sql-server ssl encryption tde

【解决方案1】：

因此，了解 TDE 发生了什么以及所有移动部件的位置会有所帮助。让我们从底部开始，逐步向上。

数据库加密密钥位于用户数据库中。当 AG 移动到另一个节点时，它将使用数据库进行故障转移。
加密密钥由位于 master 数据库中的服务器证书加密。为了在故障转移后对其进行解密，保护它的证书需要在任何尝试解密它的节点上可用。
证书通常受数据库主密钥 (DMK) 保护。由于 master 只是另一个数据库（尽管是一个特殊的），它只需要一个 DMK 来保护证书。
虽然与本讨论无关，但 DMK 受服务主密钥 (SMK) 保护。 SMK 在安装实例时为您生成。如果您曾经遇到过需要在创建数据库的服务器之外的其他地方解密的 DMK，请确保您手边有该 SMK。我最近做的一件事是确保 SMK 在 AG 中的所有节点上匹配（使用 backup service master key 和 restore service master key）。这样，当节点之间的用户数据库发生故障时，DMK 可以由新节点上的 SMK 自动解密（因为它是同一个 SMK）。至于为什么它与本次讨论无关，您的主数据库不会在节点之间发生故障。

就需要将证书导入注册表而言，根据我的经验，我不必这样做。

【讨论】：

感谢您富有洞察力的 cmets。对此，我真的非常感激。您描述的加密链非常有用。我不了解所涉及的所有机制。
如果这回答了您的问题，请勾选我的答案旁边的复选标记。这让其他人知道这解决了你的问题，我得到了一些亮点。 :)

【解决方案2】：

我无法回答第一部分，但第二部分的答案基本上就是你已经猜到的了。使用与主服务器相同的规范在辅助服务器上创建一个新的主密钥，然后使用相同的证书。我找到了一个可能对您有所帮助的 Microsoft 支持博客：https://blogs.msdn.microsoft.com/sqlserverfaq/2013/11/22/how-to-configure-always-on-for-a-tde-database/

【讨论】：

感谢您的链接！这很有帮助。