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

#1 楼

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

通常，在生产服务器上执行任何操作都是个坏主意，除非确实有必要

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

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

#2 楼

否。

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



可用性和性能：对数据库并非无害。写得不好的查询可能会：


锁定表，阻止其他关键进程。
破坏数据缓存，迫使其他进程从磁盘重新读取数据。
给您的存储层增加负担，影响共享该存储的其他服务。



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


密码散列
计费信息
其他个人身份信息

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

原因很明显。开发人员的开发工作要经过很多工作才能投入使用。如何阻止具有直接生产访问权限的恶意开发人员窃取您的生产数据或使实时数据库崩溃？

“但是DBA也是如此！他们可以做到！”究竟。您想要尽可能少地负责任的超级用户。


是的。

开发人员应该可以使用生产系统。

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




开发人员，他们设计和编写数据库的架构和代码。他们无权访问生产中的数据库。但是，他们有时会与管理员或支持人员一起坐下来，帮助他们实时查看事物。

管理员，他们负责部署，监视和管理生产环境中的数据库。

支持人员，他们调查时间敏感的生产问题并向开发人员提供反馈，以便他们可以开发修复程序。

商业智能人员，他们使用定期刷新的数据库副本或仔细地从生产数据库中提取数据书面和质量检查摘要（通常由管理员设计）。

如果您在其他组中有某些缺陷，则应授予开发人员生产访问权限。

例如：



您没有支持团队。谁会知道该去哪里调试该时间敏感的生产问题？您的开发人员。授予他们“打破常规”的访问权限。

您没有BI团队。您的管理员没有任何报告或摘录，或与它无关。谁来对您的主管每天早上看到的报告进行故障排除？您的开发人员。授予他们有限的权限来调试这些报告和摘录。

您没有管理团队。您在一家很小的公司或新兴公司中，所以向“偶然的DBA”问好。您的开发人员是管理员的两倍，因此需要完全访问生产。

#3 楼

性能可能是一个很大的原因。
仅仅因为它们无法更改数据并不意味着它们不会影响服务器。编写不当的查询可能会导致生产环境崩溃，并可能导致其他问题（例如tempdb溢出）：

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

这是灾难的根源。请注意，这是一个有序的笛卡尔乘积，这意味着它将在tempDB中排序。

#4 楼

原则是“最低特权”和“需要知道”：开发人员是否通过了此测试？特别是当Auditor或Sarbannes-Oxley敲门时。因此，如果他们确实需要三线支持，那么谁又需要呢？ Web猴子通常不支持，但是如果希望它们支持数据库类型，则为是。

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

我看到开发人员针对生产进行测试或运行查询，并由于以下原因而将其删除无知。这样说来，开发人员应该对自己的行为负责：如果他们确实关闭了服务器，那么他们应该遭受相应的损失。我在一次事件发生后被降职了...

这些当然当然是一家规模合理的商店。人们戴着的帽子越多，您可以承担的职责分离就越少

此外，是否存在开发人员可以针对最新数据运行查询的环境？在我的最后一家商店中，每天晚上都会将产品还原到测试服务器以提供此功能。

#5 楼

我认为答案是，就像许多IT一样，“取决于”。

具有大量敏感公司和客户信息的海量ERP数据库？可能不是（出于安全和性能方面的原因）。

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

当然，第一个示例比第二个示例更常见，但是如果您有这些差异，则应注意负责制定此类政策决策。但另一方面，令人惊讶的是，一个5 MB的“甜甜圈和披萨基金”数据库如何迅速将其范围扩大到50 GB的部件号/客户信用卡号/ who-knows-what-其他数据库（如果您允许的话）。

#6 楼

在通常的24/7 OLTP环境中，不应在生产中使用普通的开发人员。期！如果不时出现特定原因，则可以应要求授予权限。但是通常，没有。

我已经看到了很多原因：



从一个大表中选择*导致：


性能问题（笛卡尔产品）；
阻止问题最终使该站点屈服；
阻止复制的链接链； >订购填充TempDB驱动器的大数据集..猜测是什么？导致完全的疯狂：-)！
那天晚上负责生产的DBA血压高；


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

我确定还有更多原因。

评论

---

如果您的数据库中清楚地包含了信用卡信息，那么您将拥有..dev访问权限与否。

–рüффп
12月8日12:39

---

#7 楼

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

#8 楼

要考虑的几个项目


数据敏感吗？
程序员是核心受信任团队还是某些离岸团队的成员？
规模是多少？正在查询影响性能的数据？
项目的规模或涉及的资金是多少？
正常运行时间有多重要？

更少的美元需要更少的流程，更快开发流程。

更大的钱需要更多的过程，需要更严格的开发实践标准。

使实践适应您的工作。

#9 楼

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


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

性能是一个问题。我们确实发生过开发人员造成速度下降的情况。但是，这些是孤立的实例，我们的SQL受性能驱动，以至于很少有开发人员不了解其查询的影响。

#10 楼

对于这个问题，必须假定他们当前没有访问权限。如果某人的组织正在开发软件，而这是为了解决客户问题，而客户提供了数据库副本，则为“是”。否则，我会提倡开发人员停止生产，并为他们的研究需要创建替代环境。一旦将牙膏从管中取出，就很难将其重新放入。

#11 楼

我同意，理据的负担应由那些需要获取证据的人承担。通常，在我咨询过的环境中，我可以访问生产系统，而这是一个很小的环境，我是支持人员。我可以访问支持支持的备份等，也可以间接访问（通过专门的支持开发人员）生产数据。

重要的是：当您需要时，需要此访问权限为了确保一切顺利进行，您必须回答财务人员关于某些不起作用的问题。在那种情况下，即使是一天的数据，也无法始终使用。另一方面，访问越多越糟。通常，作为顾问，除非需要，我倾向于避免获得这种访问权限。由于我正在研究财务数据库，因此我最后要做的就是被指控输入我自己的发票：-D。

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

我这方面的大问题与写访问权限有关。如果开发人员没有访问权限，那么当然，该开发人员也没有写访问权限。如果要验证书籍的完整性，则希望保持对尽可能少的人的写权限。如果开发人员无权访问，则审计追踪要容易得多。如果开发人员具有读取访问权限，那么对于是否存在一些可以授予写入访问权限的特权升级附加程序（也许是存储过程SQL注入？），您总是会有疑问。当我有权访问登台环境时，我通常具有对客户账单信息的完全访问权限。如果有一个可行的暂存环境，我通常会主动要求除非有必要，否则不要访问生产。

因此，这当然不是完美的。开发人员仍然可以在应用程序中构建后门，这种后门可能不容易被检测到，但是考虑到备份数据可以从前一天获得，这一事实在我看来，这是他们所担心的，因此这种方法是一种合理的方法。

希望这会有所帮助。

编辑：仅在我工作过的较大环境中，我就可以访问完整的备份数据，这些数据通常从几天到几个月的财务系统。这对我的工作一直足够好，并且只有在财务人员需要具有使用较新数据进行测试的能力时才能将其破坏的功能，这样才能与生产相匹配。

#12 楼

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

开发人员从不真正需要访问生产环境，如果无法复制棘手的bug，从开发人员的角度来看这将更加容易。 。

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

如果确实需要将数据归入测试环境，则通常需要某种处理来清理数据，这会产生额外的工作。

根据您所谓的生产环境中使用的数据库软件，开发人员可能需要新的许可才能访问数据库，而仅具有读取访问权就需要大量费用。

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

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

#13 楼

性能可能是原因之一。

开发人员查询通常效率低下，导致过度锁定或占用资源，直到对其进行适当调整为止。

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

#14 楼

这取决于DBA以及他或她对开发人员的信心。通常，开发人员会获得对生产数据库的查询（读取）特权。根据经验，开发人员只能使用测试/开发数据库。

#15 楼

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

使用SQL登录名仅授予他们对表的只读访问权限是很棒的。但是，是什么阻止他们创建具有20个联接的查询或从具有数百万条记录的表中进行SELECT *呢？这些查询可能会意外地破坏数据库和存储的性能。

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

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

#16 楼

是。在某些情况下，允许某些用户子集（包括开发人员）对查询生产数据具有某种级别的访问权限是有意义的。但是，由于两个原因，必须设置适当的限制。首先，作为DBA，您必须尽最大努力确保所有用户所需的服务水平。此外，您还想防止意外的不良查询，例如大规模删除或违反业务规则。不言而喻，必须有适当的安全控制。

无论出于什么原因不允许直接对数据库表进行临时查询，都可能会出现允许对视图进行查询的情况。和存储过程。使用数据库权限，可以防止SELECT直接查询表，甚至限制给定用户可以访问的视图和存储过程。如果正确实施，此方法不仅可以为您的用户提供灵活性，还可以保护您的数据完整性和可实现性。

#17 楼

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

#18 楼

No..Never !!

这就是我们拥有开发/测试/ UAT服务器的原因。生产中的数据可以复制到测试环境中，开发人员可以继续进行测试。在生产环境中，选择查询也可能非常有害。它增加了负载，在高峰时间会降低整体性能。

他们需要的任何信息都应通过DBA进行查询，该DBA可以运行他们想要的内容（选择）并向其发送结果。这就是我们在环境中所做的事情。

#19 楼

我不确定为什么每个人都认为开发人员是愚蠢的，什么都不知道。我得到了很多不同角色的样本，他们被弄得一团糟，不应该“投入生产”。我有DBA，系统管理员，网络管理员，开发人员等...都搞砸了。

没有人（开发人员，dba，sa）可以访问任何环境中的任何服务器或数据库正常的网络登录。它们都有必须使用的特定“管理员”帐户。是的，通常dba和sa会更频繁地使用它们，但即使它们也应轻踩。我已经被每个人辛苦了。

因此，在美好的一天，没有IT角色需要访问。但是，该死的打击了风扇，全力以赴，我们需要合适的人员来解决问题。通常由了解应用程序并指导dba和sa到特定点的开发人员领导。只是不必要的延迟或请求和批准。

此外，无论如何都不会在批准之后进行任何类型的审核，因此批准毫无意义。