如何防止意外劫持生产数据库？

Question

就在最近，我让一位开发人员意外地尝试将数据库恢复到生产环境，而他本应恢复到临时副本。这很容易做到，因为数据库名称相似，即 CustomerName_Staging 与 CustomerName_Production。

理想情况下，我会将这些放在完全独立的盒子上，但这成本太高，而且，严格来说，如果用户连接到错误的盒子，它不会阻止同样的事情发生。

这本身并不是一个安全问题——它是使用临时数据库的正确用户，如果在生产数据库上有工作要做，那也是他。我很想有一个部署官来解决这些问题，但团队不够大。

我很想听听关于如何防止这种情况的实践、配置和控制方面的一些建议。

Answer 1

我不同意问题中的假设——这就是安全——但我也不同意自动化会自己挽救局面。我将从问题开始：

您不应该意外地对生产做任何事情！

这包括意外地做自动化的事情。

您将系统安全与“允许谁做什么”这样的概念混淆了。您的开发帐户应该只能写入他们的副本、版本控制服务器和开发数据库。如果他们可以读/写生产，他们可能会被黑客攻击和利用来窃取客户数据，或者（如您所展示的）可能会被错误处理而丢失客户数据。

您需要首先整理您的工作流程。

• 您的开发人员帐户应该能够写入他们自己的副本、版本控制，并且可能从版本控制中提取到测试环境中。

• 备份用户应该只能从生产中读取并写入您的备份存储（应该受到适当的保护）。

• 在生产中进行任何其他读/写操作都需要特殊且不方便的身份验证。您不应该能够溜进去或忘记您已登录。物理访问控制在这里很有用。智能卡、用于“武装”帐户的翻转开关、同时转动双键访问。

  访问生产不应该是您每天都需要做的事情。大多数工作应该在您的测试平台上进行，并在经过仔细审查后进行生产。一点不便不会杀死你。

自动化是解决方案的一部分。

我并没有忽视这样一个事实，即完整的周转（上传到 VCS、检查覆盖率、拉到测试服务器、运行自动化测试、重新验证、创建备份、从 VCS 中提取）是一个漫长的过程。

根据 Ben 的回答，这就是自动化可以提供帮助的地方。有许多不同的脚本语言可以使运行某些任务变得更加容易。只要确保你不要让做愚蠢的事情变得太容易。您的重新身份验证步骤仍然应该是明显的（如果有危险），它们应该不方便且难以不假思索地进行。

但仅此而已，自动化比无用更糟糕。它只会帮助您以更少的思考犯更大的错误。

适合各种规模的团队。

我注意到你指出了你团队的规模。我是一个人，我让自己经历了这一切，因为发生事故只需要一个人。有一个开销，但它是值得的。您最终会拥有一个更安全、更安全的开发和生产环境。

Answer 2

如果这是您经常看到自己做的事情，请将其自动化。而且由于你们都是开发人员，编写一些代码应该是你的驾驶室。:) 说真的……通过自动化，您可以执行以下操作：

• 验证您正在正确的服务器上进行恢复（即没有开发 -> 生产恢复）
• 验证它是正确的数据库“类型”（在您的情况下，“暂存”和“生产”）
• 通过查看 msdb 中的备份表，找出要自动恢复的备份

等等。你只受限于你的想象力。

Answer 3

我的一位同事对此有一个有趣的方法。他用于生产的终端配色方案是模糊的。灰色和粉红色且难以阅读，理论上应该确保他写的任何内容都是他真正打算写的。

你的里程可能会有所不同......我可能不必说它本身就很难防弹。:)