关于非生产数据库刷新和 TDE 的最佳实践

Question

假设我们有一个生产系统，其中有几个使用 TDE 加密的数据库和一个自生成的证书。

我们经常需要使用这个数据库并更新我们的非生产系统。此过程涉及备份源数据库、将其恢复到预生产状态、混淆个人数据和许多其他项目。

这里的关键事实是预生产系统具有生产的加密证书副本

我正在寻找使此过程更安全的方法 - 我对预生产环境中的证书不满意。有没有另一种方法可以：

Answer 1

在完美的世界中，如果您在生产中存储个人身份数据，则永远不会将数据库恢复到开发环境。

你不能仅仅依靠混淆。例如，迟早会有人制作生产中表的备份副本。他们将在对其进行更改之前将 dbo.Customers 表选择到一个新表中以进行妥善保管，并且他们将忘记删除它。您的混淆代码不会期待带有个人身份数据的新随机表，因此在混淆过程之后，数据仍然存在。

相反，当您需要开发数据时，从头开始生成它。

（请记住：您要求的是最佳实践，而不是妥协。如果您的回答是“但我们需要开发中的生产数据”，那么您已经错过了最佳实践。）

Answer 2

正如 Brent 指出的那样：真实数据（即使是其中最小的部分是敏感的）根本不应该出现在开发/测试^[1]系统上，即使是暂时的。

如果您确实将真实数据去个性化以用于测试环境，那么我们在这样做时会采取一些预防措施：

再次强调：真实数据根本不应该存在于开发/测试系统上，即使是暂时的也不应该存在。使用所暗示的完整安全措施在已签署的生产环境中恢复副本并取消个性化，然后将修改后的数据移动到其他环境。您可能不希望主生产设置^[2]承受这种额外负载，在这种情况下，在该环境中需要有一个单独的数据库服务器专门用于此任务^[3]。
确保您的流程安全失败并且失败严重，即使这意味着它经常失败。如果存在任何新表或列，则让它翻倒，直到您给它一个新的预期列表，以缓解 Brent 讨论的临时架构更改问题。还要确保任何失败的步骤都会停止整个过程，以便任何更改数据的错误都会阻止生产。

最佳实践^[4]是根据生产中看到的模式生成测试数据，而不是在不改变数据中任何模式的情况下尝试使其无法识别。除了消除由于流程错误而意外使用真实数据的风险之外，您还可以在测试数据中包含生产中尚未发生的（您知道的）边缘情况。

即使你的去个性化起作用了，你可能会发现，任何有一点决心的人都可以部分地撤销它，如果他们对你的客户的组织有一点了解的话。

预生产系统具有生产中的加密证书的副本

这是你的危险信号。如果您对将生产数据远离非生产环境的额外费用和/或麻烦提出疑问，请向您上方的任何人挥手。不必要的密钥副本会极大地扩大您的攻击面。

^{[1] 有些人可能会建议 UAT 服务例外，但无论如何我都会考虑这种生产。}

^{[2] 除非您服务于一组相当特定的时区，例如您的所有客户及其绝大多数用户都在美国，因此在夜间有一个大窗口，在此期间性能影响并不重要}

^{[3] 它不一定需要昂贵的“生产级”套件（高性能驱动器、企业许可的 SQL 和操作系统，...），只需足以让此过程足够快，因为您不会看到并发最终用户活动，但当然仍然会涉及成本}

^{[4] 我们已经转向所有最近和未来的开发 - 我们只在某些即将退役的遗留服务上使用像这样的生产数据的修改，在它们完全过时之前不值得重新装备。}