如何防止意外插入生产数据库？

31

就在最近，我有一个开发人员不小心尝试将数据库还原到生产环境，而那时他本来应该还原到临时副本。鉴于数据库名称是相似的，因此很容易做到，即CustomerName_Staging与CustomerName_Production。

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

从本质上讲，这不是一个安全问题-这是使用登台数据库的正确用户，如果在生产数据库上有工作要做，那么也应该是他。我很想请一名部署人员来解决这些问题，但是团队还不够大。

我很想听听一些有关如何防止这种情况的做法，配置和控制方面的建议。

sql-server best-practices

— 克里斯·贝伦斯
source

25

开发人员不应具有对生产数据库的写访问权，最好也不应具有任何访问权。

— 迈克尔·汉普顿

12

@MichaelHampton-是我和他。我也是一名开发人员。你有什么建议？

— 克里斯·贝伦斯

10

每个角色都有单独的用户帐户（开发人员与操作人员/ DBA）。和大量的谨慎。

— 迈克尔·汉普顿

2

我强烈建议您将生产环境放在单独的盒子中。否则，登台和生产必须共享资源（磁盘，cpu等），并且如果登台独占资源，则生产环境可能会受到影响。

— 托尔比约恩Ravn的安德森

1

只需为这些数据库使用单独的用户/密码即可。

— neutrinus

32

如果您发现自己经常这样做，请使其自动化。而且由于您都是开发人员，因此编写代码应该在您的掌舵权之内。:)认真地...通过使其自动化，您可以执行以下操作：

确认您要在正确的服务器上还原（即，没有dev-> prod restore）
验证它是正确的数据库“类型”（在您的情况下为“登台”和“生产”）
通过查看msdb中的备份表来找出要自动还原的备份

等等。您仅受您的想象力限制。

— 本图尔
source

1

这是一个有趣的想法...我们已经有了管理数据库还原的代码（用于自动测试）。我们可以在仅指向登台的中间放置一个抽象层，以便恢复到生产是一个完全不同的过程……

— Chris B. Behrens

11

现在，您正在考虑门户。:)

— Ben Thul 2015年

4

对于影响生产的自动化作业，我喜欢添加一个手动步骤，该步骤要求用户键入“生产”一词，以减少他们认为自己正在看的临时产品等可能性。

— Joe Lee-Moyet

2

我投下反对票，因为默认情况下没有人可以访问生产。您必须有一个特殊的过程来检索产品密码。这很不方便，但实际上是最小的。

— 奥利弗

1

@BenThul为我的产品添加另一个帐户以进行产品访问，并使其又不方便，这仍然是我的正确解决方案。业务需求不是让DEV节省2分钟，而是还原可以完美移动到产品帐户的数据库。

— OliverS 2015年

32

我不同意问题中的假设-这就是安全性-但我也不同意自动化将自己节省一天的时间。我将从问题开始：

您不应无意间对生产进行任何操作！

这包括意外地进行自动化操作。

您会将系统安全性与“允许谁执行操作”之类的概念混淆。您的开发帐户应该只能写入其副本，版本控制服务器和开发数据库。如果他们可以读写产品，那么它们可能会遭到黑客攻击并被利用来窃取客户数据，或者（如您所展示的）可能会被误处理以丢失客户数据。

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

您的开发人员帐户应能够写入其自己的副本，版本控制，并且可能从版本控制进入测试环境。
备份用户只能从生产中读取和写入备份存储（应受到适当保护）。
在生产环境中进行任何其他读/写操作都需要特殊且不便的身份验证。您不应该溜进去或者忘记登录。这里的物理访问控制很有用。智能卡，通过翻转开关可以“布防”帐户，同时开启双键访问。

不必每天都访问生产。大部分工作应在您的测试平台上，并在仔细检查后在工作中进行离线部署。不便之处不会杀死您。

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

我对整个周转过程（上载到VCS，检查覆盖范围，拉到测试服务器，运行自动测试，重新认证，创建备份，从VCS提取）的整个周转时间并不感到困惑。

根据Ben的回答，这就是自动化可以提供帮助的地方。有许多不同的脚本语言使运行某些任务变得非常容易。只要确保您不会太容易做愚蠢的事情即可。您的重新认证步骤仍然应该宣告（如果有危险），它们应该很不方便并且很难做到。

但是，仅凭自动化，总比没有用要糟。它只会帮助您以更少的思路犯下更大的错误。

适合各种规模的团队。

我注意到您指出了您的团队规模。我是一个人，所以我自己经历了这个过程，因为只需要一个人就能发生事故。有开销，但值得。您最终将获得更安全，更安全的开发和生产环境。

— 奥利
source

2

另外，我想做的一件事是每个用户使用两个命名帐户。一个用于普通用户的登录，操作，日常工作等，而第二个帐户（通常带有某种后缀，例如+或下划线）具有用户所需的prod和dev的完整权限。这样，用户必须做出积极的决定以推向生产而不是开发。这类似于上述第3条，但不需要大量的额外基础结构或费用即可证明其价值。

— user24313

3

避免养成在产品帐户中进行产品维护以外的任何习惯也很重要。为此，确保督促无法看到源代码，也不能启动IDE等

— 埃里克·劳埃德

我从哪里可以得到那些同时转动的双键装置之一，它是否带有USB？

— Lilienthal 2015年

可能有其他帮助的是在登台和开发中完全自动化（一两次单击）过程，而不是完全自动化生产部署。正如您所建议的，必须手动将机器移到包装盒中才能对生产进行任何操作，而对其他环境则无济于事。（您仍然可以列出所有步骤的脚本，并在所有环境中使用该脚本；我的意思是，您必须手动触发执行所述脚本以进行生产。）当然，除了身份验证类型之外，还可以执行此操作。您推荐的程序。

— jpmc26 2015年

1

@Lilienthal这是高安全性剧院的一个比喻，但是您可以模仿便宜地攻击每个开发人员的USB记忆棒，然后在运行危险物品时让您的自动化程序检查至少两个序列号。然后，在更大的团队中，您可以登录查看谁在干扰生产，并在所有出现问题时让合适的人员负责。

— 奥利2015年

12

我的一位同事对此有一种有趣的方法。他生产的终端配色方案很笨拙。灰色和粉红色且难以阅读，从理论上讲，这应该确保他无论写什么，都确实打算写。

您的行驶里程可能会有所不同……而且我可能不必说它本身并不是很难做到的。:)

— 罗伯
source

2

我还在与生产服务器的终端/数据库连接上使用大红色背景色，以及在PC上为管理员使用明亮的红色墙纸...

— Falco

是的，我当时在想。让生产消防车变红……

— 克里斯·贝伦斯

颜色编码有帮助。就像在IDE中一样。

— 托尔比约恩Ravn的安德森

1

开发人员不应该知道生产数据库的密码。产品密码应该是随机的，并且不容易记住-类似于键盘混搭（Z^kC83N*(#$Hx）的结果。您的开发人员密码可以是$YourDog'sName或correct horse battery staple或其他。

当然，通过查看客户端应用程序的配置文件，您可以找出密码是什么，特别是如果您是一个小团队的话。那是产品密码应该存在的唯一地方。这样可以确保您必须努力获取产品密码。

（与往常一样，您应该为生产数据库提供时间点备份。例如，对于MySQL，将二进制日志归档为增量备份。对于PostgreSQL，则归档预写日志。这是您的最后保护措施任何形式的灾难，无论是自残还是其他原因。）

— 200_成功
source

我不能完全同意这一点，因为在任何现实的大型环境中，都有相当经常的实例，其中开发人员/管理员需要访问生产数据库。当然在一个完美的系统，这是不可能发生的一个完美的世界，但我知道你有解决手工生产的一些关键数据。所以我与奥利奇是，生产的登录应该是不方便，但最可行的系统

— 法尔科

1

@Falco这正是我的建议。不方便但可行。

— 200_success

您的方法的问题仅在于，如果出现紧急情况并且生产中断，那么时间就很重要。因此，您的开发人员应该知道在哪里可以找到密码并快速获得密码。如果他们需要询问，请搜索存储库和配置文件，然后尝试解决，您正在浪费宝贵的时间=金钱。因此，我宁愿将密码保存在每个人都知道该看哪里的地方，但这仍然不方便，但是如果需要的话可以很快

— Falco 2015年

2

@Falco因为产品环境应该紧密地反映开发环境，所以配置文件在产品服务器上的位置与在开发机器上的位置类似。任何有能力的开发人员都应该知道在哪里看，如果他们不知道在哪里看，那么您就需要延迟-正是为了防止问题中所述类型的损坏。

— 200_success，2015年

不知道密码不会阻止事故。恰恰相反，它激发了只进行一次密码查找的动机，此后，开发人员可能会开始使用bash历史记录，甚至可能创建别名来连接数据库。然后，事故更有可能发生。

— k0pernikus 2015年

0

简短的答案是RBAC-基于角色的访问控制。

您对所有环境的权限都必须不同-并且像UAC之类的东西一样令人讨厌，您需要它们：尤其是对于PROD环境。

有从未有原因的开发者和得提醒直达-无论组织/团队是多么小。您的“ Dev”可能还戴着“ Stage”和“ Prod”帽子，但是他需要具有不同的凭据和流程才能适应不同的环境。

烦人吗？绝对。但这是否[有助于]防止环境破坏？绝对。

— 沃伦
source

0

一个快速而简单的解决方案：使用两个不同的用户帐户，一个用于您的正常开发工作，该用户只能访问开发数据库，另一个用于实际在生产数据库上进行操作并具有完全访问权限。这样，您将必须主动更改正在使用的帐户，然后才能进行生产中的任何更改，这应该足以防止意外错误。

如果您有两个网站，两个服务器或两个完整的环境，则可以使用相同的方法：一个用户用于开发而没有对生产的访问权限（或至少没有写访问权限），另一个用户用于在生产系统上工作（ s）。

这与系统管理员具有相同的方法，该系统管理员具有用于日常工作的标准非管理员帐户（阅读电子邮件，网上冲浪，跟踪故障单，归档时间表，编写文档等），以及在实际操作时使用的独特的完全管理员帐户在服务器和/或Active Directory上。

— 马西莫
source