开发人员应该能够查询生产数据库吗？

Question

是否应该授予开发人员查询（SELECT/只读）生产数据库的权限？我之前工作的地方，开发团队有这个db_datareader角色；我现在工作的地方开发团队甚至无法连接到生产实例。

其中一个测试实例是每周一次从生产备份中恢复的生产副本，因此开发人员实际查看数据没有任何问题。

不允许开发人员查询生产（除了根本不希望他们有权读取敏感数据）有什么好的理由？

Answer 1

这实际上取决于开发人员是否有任何支持责任。如果他们需要第三线支持，那么他们可能需要查看生产数据库来执行此操作。

一般来说，在生产服务器上做任何事情都是一个坏主意，除非真的有必要在那里做。

对于大多数开发目的，生产数据库的镜像或快照就足够了，并且可能比实时生产数据库更好。如果您正在做任何涉及集成的事情，那么您将需要稳定的数据库环境，您可以在其中控制其中的内容。任何涉及和解的事情也需要能够及时查看受控时间点。

如果问题是您没有生产镜像环境或任何方式为您的开发人员放置生产数据的副本，那么这是一个有点不同的问题。在那种情况下，您的开发人员确实需要至少一个镜像环境。如果您看不到数据中的问题，则很难对其进行故障排除。

Answer 2

不。

由于以下原因，开发人员不应访问生产数据库系统：

1. 可用性和性能：拥有对数据库的只读权限并非无害。写得不好的查询可以：

   1. 锁定表，阻塞其他关键进程。
   2. 垃圾数据缓存，迫使其他进程从磁盘重新读取数据。
   3. 对您的存储层征税，影响共享该存储的其他服务。

2. 安全性：您的生产数据库可能包含敏感信息，例如：

   • 密码哈希
   • 账单信息
   • 其他个人身份信息

   只有那些绝对需要访问此信息的人才能拥有它。在组织良好的公司中，开发人员不在这些人之列。此外，如果您的公司的开发人员可以使用这些数据访问生产系统，那么您的公司将无法遵守 PCI 和 SOX。

   其原因是显而易见的。开发人员的开发工作在上线之前要经过很多人的手。如何阻止具有直接生产访问权限的恶意开发人员窃取您的生产数据或使您的实时数据库瘫痪？

   “但这也适用于 DBA！他们可以做到！” 确切地。您需要尽可能少的超级用户。

是的。

开发人员应该可以访问生产系统。

在我的公司，我们有四个团队负责处理生产数据库。他们是：

1. 开发人员，为数据库设计和编写架构和代码。他们无法访问生产中的数据库。不过，他们有时会与管理员或支持人员坐在一起，帮助他们查看实时内容。
2. 管理员，在生产中部署、监视和管理数据库。
3. 支持那些调查时间敏感的生产问题并向开发人员提供反馈以便他们开发修复程序的人员。
4. 商业智能人员，他们使用这些数据库的定期刷新副本或精心编写和 QA 的摘录（通常由管理员设计）从生产数据库中提取数据。

当您在这些其他组中存在某些缺陷时，授予您的开发人员生产访问权限是合适的。

例如：

• 您没有支持团队。谁会知道去哪里调试那个对时间敏感的生产问题？您的开发人员。授予他们“打破玻璃”的权限。
• 您没有 BI 团队。您的管理员没有或不想与报告或摘录有任何关系。谁来解决你的高管每天早上看到的报告？您的开发人员。授予他们有限的访问权限来调试这些报告和摘录。
• 您没有管理团队。你在一家非常小的公司或初创公司，所以向“偶然的 DBA”问好。您的开发人员兼任您的管理员，因此需要完全访问生产。

Answer 3

性能将是一个重要原因。

仅仅因为他们不能改变数据并不意味着他们不能影响服务器。写得不好的查询可能会使生产环境瘫痪，并可能导致其他问题（如 tempdb 溢出）：

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

这是灾难的秘诀。请注意，这是一个带有 order by 的笛卡尔积，这意味着它将在 tempDB 中排序。

Answer 4

原则是“最小权限”和“需要知道”：开发者通过这个测试吗？
尤其是当审计师或萨班斯-奥克斯利法案来敲门时。

然后，我的下一个假设：开发人员是愚蠢的。因此，如果他们确实需要第三线支持的话，那么谁需要它？网络猴子通常不会但数据库类型是的，如果他们希望支持它的话。

那么，是否需要永久访问？他们可以使用需要注销的 SQL 登录名或备用 Windows 帐户进行“打破玻璃”访问。在我们的案例中，是数据所有者（希望是一些精通技术的业务人员）和 IT 经理批准它。

我已经看到开发人员对测试或生产运行查询和把它记下来，因为无知。话虽如此，开发人员应该为自己的行为负责：如果他们确实关闭了服务器，他们应该遭受相应的损失。我在一次事件后降级了一个人...

当然，这些假设是一个合理规模的商店。人们戴的帽子越多，您的职责分离就越少

另外，是否有开发人员可以对最近的数据运行查询的环境？在我的最后一家商店，每晚都会将 prod 恢复到测试服务器以提供此功能。

Answer 5

我认为答案是，就像 IT 的许多事情一样，“视情况而定”。

包含大量敏感公司和客户信息的庞大 ERP 数据库？可能不是（出于安全和性能原因）。

一个带有 Access 前端的部门 5 MB 数据库，用于跟踪对甜甜圈和比萨基金的捐款？不会有很大的不同，至少对于只读访问。

诚然，第一个示例比第二个示例更常见，但是如果您负责制定这些类型的政策决策，您应该注意这些差异。但另一方面，令人惊讶的是，一个 5 MB 的甜甜圈和比萨基金数据库可以迅速扩展到 50 GB 的部件号/客户信用卡号/谁知道什么-如果你允许的话，其他数据库。

Answer 6

在通常的 24/7 OLTP 环境中，不应允许普通开发人员参与生产。时期！如果不时出现特定原因，则可以根据请求授予权限。但通常不会。

我已经看到了很多原因：

• SELECT * 从一个大表导致：

  • 性能问题（笛卡尔积）；
  • 阻止最终使网站屈服的问题；
  • 使复制挂起的阻塞链；
  • 订购填充 TempDB 驱动器的大数据集，你猜怎么着？导致完全疯狂:-)！
  • 当晚负责生产的 DBA 血压高；

• 读取敏感数据（开发人员不应访问信用卡信息……或任何用户个人详细信息）；

我相信还有更多的原因。

Answer 7

• 安全性：可能会有敏感信息在提供给开发人员时被清理。
• 偏执狂：有些人可能认为您仍然可以通过选择访问来弄乱数据。
• 性能：查询需要一些资源来执行，你不能告诉我你的开发人员在编写代码时是完美的。

Answer 8

需要考虑的几个项目

• 数据敏感吗？
• 程序员是核心信任团队的一部分还是某个离岸团队的一部分？
• 就影响性能而言，所查询的数据规模是多少？
• 所涉及的项目或资金规模是多少？
• 正常运行时间有多重要？

更小的资金需要更少的流程需要更快的开发流程。

更大的资金需要更多的流程，需要更严格的开发实践标准。

根据你正在做的事情调整你的做法。

Answer 9

我在一家非常大的公司担任开发人员。我们所有将提供任何类型支持的开发人员（基本上都是他们）都可以访问相关的生产数据库。我只能代表我的特定团队发言，但我会告诉您为什么我们可以访问。

1. 我们需要实时访问以密切关注我们的日常处理。（虽然我们有一个仪表板，但我们需要能够深入观察事物。虽然在我们的仪表板上有这个功能会很好，但我们发现这是不切实际的。）
2. 我们需要实时访问来调查任何生产故障，因为延迟会产生巨大的影响。（我不打算在这里讨论我们的失败。它们有各种各样的）
3. 我们经常需要为业务用户做自定义报告，并且这些信息需要是最新的。（dba 没有时间这样做，我们也没有时间等待他们。当然，这并不理想。）
4. 我们需要对生产 DDL/DML 部署/补丁进行验证。（DBA部署它们，但只有我们知道它应该如何构建。我们比DBA更了解我们的数据库结构。我们可能在这里很奇怪，但由于我们的业务非常复杂，因此数据库非常复杂。）

性能是一个问题。我们确实有开发人员导致速度减慢的情况。然而，这些都是孤立的实例，我们的 SQL 是由性能驱动的，以至于我们的开发人员很少不了解他们查询的影响。

Answer 10

要问这个问题，必须假设他们目前没有访问权限。如果一个组织正在开发软件并且这是为了解决客户问题并且客户提供了他们的数据库的副本，那么“是”。否则，我会主张让开发人员停止生产，并为他们的研究需求创建替代环境。一旦牙膏从管中出来，就很难再把它放回去。

Answer 11

我同意证明的责任应该由需要访问的人承担。通常在我咨询过的环境中，我可以访问生产系统，那里是一个小环境，我是支持人员。我可以访问备份等，我支持支持，并间接访问（通过专门的支持开发人员）生产数据。

重要的是：当您陷入困境以保持一切顺利运行时，您需要此访问权限，并且您必须回答财务人员关于某些不工作的问题。在这种情况下，即使是一天前的数据也不能总是工作。另一方面，访问越多，情况就越糟。通常，作为顾问，除非需要，否则我倾向于避免获得此类访问权限。由于我正在研究金融数据库，我最不想做的就是被指控输入我自己的发票:-D。

另一方面，如果您不需要访问权限，则不应拥有它。我并没有真正购买敏感数据参数，因为开发人员可能需要确保正确处理此问题（并且在错误报告出现时，如果不查看实际存储的内容，则很难进行验证）。如果您不相信开发人员会查看开发人员的应用程序存储的数据，则不应聘请开发人员编写应用程序。开发人员有太多方法可以混淆数据并将其通过电子邮件发送出去，而您永远无法确定。MAC 控制在这里有所帮助，但实施起来仍然非常复杂。

我这边的大问题与写访问有关。如果开发人员没有访问权限，那么更重要的是，开发人员没有写访问权限。如果您想验证书籍的完整性，您希望尽可能少的人保持写入权限。如果开发人员没有访问权限，审计跟踪就更容易验证。如果开发人员具有读访问权限，那么您总是有一些疑问，即是否存在某些可以授予写访问权限的权限提升附加（可能是存储过程 SQL 注入？）。当我可以访问临时环境时，我经常可以完全访问客户帐单信息。如果有一个可行的临时环境，我通常会主动要求不要访问生产，除非有必要。

所以这当然不是完美的。开发人员仍然可以在应用程序中构建后门，这些后门可能不容易被检测到，但这种方法是一种合理的方法，因为备份数据从前一天开始可用，在我看来，这正是他们所关心的问题。

希望这可以帮助。

编辑：只是在我工作过的更大环境中补充一点，我可以访问财务系统的完整备份数据，通常从几天到几个月不等。这一直足够好我的工作，唯一的时候，它已经坏了一直当财务家伙需要一个能力测试与较新的数据，因此他们可能对阵生产。

Answer 12

没有访问权限是一件好事，也是一种保护开发人员和其他人不会意外损坏数据或查看数据的方法。这也可以保护公司免于违法（即违反 Hipaa 和隐私问题）

开发人员永远不需要访问生产环境，如果无法重现严重的错误，从开发人员的角度来看，它会更容易。

但是，开发人员可以放入小型转储或日志文件并使用 PDB 符号文件来重新创建错误。

如果确实需要将数据放到测试环境中，那么通常需要某种过程来清理数据，这会产生额外的工作。

根据您所说的生产中使用的数据库软件，开发人员可能需要新的许可证才能访问数据库，这对于简单的读取访问来说是一笔很大的费用。

如果您的公司没有为您提供调试或研究生产问题的工具，这并不是因为您无权访问生产数据。

数据是大多数应用程序中最有价值的部分！

Answer 13

性能可能是原因之一。

开发人员查询通常效率低下，在适当调整之前会导致过度锁定或资源使用。

生产系统不适合开发人员进行试验。

Answer 14

这取决于 DBA 以及他或她对开发人员的信心。通常，开发人员被授予对生产数据库的查询（读取）权限。根据经验，开发人员应该只使用测试/开发数据库。

Answer 15

挑战在于大多数软件应用程序都是数据驱动的。因此，当您尝试修复应用程序中的问题时，您确实需要查看驱动它的数据。所以开发人员真的需要某种形式的访问。

使用 SQL 登录只授予他们对表的只读访问权限非常好。但是，是什么阻止他们创建具有 20 个连接的查询或从具有数百万条记录的表中执行 SELECT * ？这些查询可能会意外降低数据库和存储的性能。

我的公司 Stackify 想出了一个聪明的方法来解决这个问题。开发人员可以通过我们的软件运行查询，我们使用查询计划来确保它只是一个 SELECT 语句，并且查询的估计成本很低，并且只会返回几条记录。这样他们就不会造成太大的伤害。我们还审计他们运行的所有查询。

这只是我们提供的其中一项。在http://www.Stackify.com上查看我们以了解有关我们的DevOps 支持解决方案的更多信息。

Answer 16

是的。在某些情况下，允许某些用户子集（包括开发人员）对查询生产数据进行一定级别的访问是有意义的。但是，出于两个原因，必须实施适当的限制。首先，作为 DBA，您必须尽最大努力确保所有用户所需的服务水平。此外，您还希望防止无意的错误查询，例如批量删除或违反业务规则。不用说，适当的安全控制必须到位。

无论您出于何种原因不允许直接对数据库表进行即席查询，都可能存在允许对视图和存储过程进行查询的情况。使用数据库权限，您可以防止直接对表进行 SELECT 查询，甚至可以限制给定用户可以访问的视图和存储过程。这种方法不仅为您的用户群提供了灵活性，而且在正确实施时还可以保护您的数据完整性和可靠性。

Answer 17

在我们公司，我们维护生产服务不依赖的生产数据库的只读从库。我们授予开发人员访问生产数据的权限。如果有敏感数据（客户信息、付款信息等），我们会限制这些表的复制并在从服务器上维护一个示例数据表。