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

测试实例之一是每周一次从生产备份还原的生产副本，因此开发人员实际看到数据没有任何问题。

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

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

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

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

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

没有。

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

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

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

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

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

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

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

   “但是DBA也是如此！他们可以做到！” 究竟。您需要尽可能少地拥有超级用户。

是。

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

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

1. 开发人员，负责设计和编写数据库的架构和代码。他们无权访问生产中的数据库。但是，他们有时会与管理员或支持人员一起坐下来，帮助他们实时查看事物。
2. 管理员，他们在生产中部署，监视和管理数据库。
3. 支持人员，他们调查对时间敏感的生产问题并向开发人员提供反馈，以便他们可以开发修复程序。
4. 商业情报人员，他们使用生产数据库的定期刷新副本或精心编写且经过质量检查的摘录（通常由管理员设计）从生产数据库中提取数据。

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

例如：

• 您没有支持团队。谁会知道该去哪里调试该时间敏感的生产问题？您的开发人员。授予他们“ 破杯 ”的权限。
• 您没有BI团队。您的管理员没有任何报告或摘录，也不想做任何事。谁来对您的高管每天早上看到的报告进行故障排除？您的开发人员。授予他们有限的权限来调试这些报告和摘录。
• 您没有管理团队。您在一家很小的公司或新兴公司中，所以向“偶然的DBA”问好。您的开发人员是管理员的两倍，因此需要完全访问生产。

性能将是一个很大的原因。

仅仅因为他们无法更改数据并不意味着它们不会影响服务器。写得不好的查询可能会使生产环境崩溃，并可能引起其他问题（例如tempdb溢出）：

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

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

原则是“最低特权”和“需要知道”：开发人员是否通过此测试？
特别是当审计员或萨班斯·奥克斯利法案敲门时。

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

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

我已经看到开发人员针对生产进行测试或运行查询，并且由于无知而将其删除。话虽如此，开发人员应该为自己的行为负责：如果他们确实关闭了服务器，则会遭受相应的损失。一件事后我被降级了...

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

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

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

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

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

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

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

我已经看到了许多原因：

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

  • 性能问题（笛卡尔产品）；
  • 阻止最终使该站点屈服的问题；
  • 使复制挂起的阻塞链；
  • 订购填充TempDB驱动器的大数据集..猜测是什么？造成彻底的疯狂:-)！
  • 负责当晚生产的DBA血压高；

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

我敢肯定还有更多原因。

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

需要考虑的几个项目

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

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

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

使您的做法适应您的工作。

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

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

性能是一个问题。我们确实发生过导致速度下降的开发人员事件。但是，这些都是孤立的实例，而我们的SQL是性能驱动的，因此很少有我们的开发人员不了解他们的查询的影响。

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

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

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

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

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

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

希望这可以帮助。

编辑：只需添加一下，在我工作过的较大环境中，我就可以访问完整的备份数据，对于财务系统而言，这些数据通常从几天到几个月不等。这一直以来对我的工作，唯一的时候，它已经坏了足够好的已经在金融球员需要用新的数据来检验，因此他们可能对阵生产的能力。

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

开发人员从不真正需要访问生产环境，从开发人员的角度来看，如果不能重现一个棘手的错误，这将变得更加容易。

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

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

根据您所谓的生产环境中使用的数据库软件，开发人员可能需要一个新的许可证才能访问数据库，这对于仅具有读取访问权来说是一笔巨大的费用。

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

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

性能可能是原因之一。

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

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

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

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

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

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

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

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

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

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

没有永不！！

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

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

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

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

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

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