开发人员应具有多少数据库访问权限？[关闭]

因此，我曾在许多不同的工作场所担任过开发人员，而我对数据库的访问级别也有所不同。我通常没有生产数据库访问权限。

大多数情况下，我可以访问测试数据库，但是它有所不同。有时我可以随意更改数据库和数据，但是通常还有其他安排。就像我可能只对数据具有读取权限。

我在一个由DBA团队管理数据库的地方工作，除非我们提交了带有sql脚本的表格以供他们“检查”，否则我们根本无法进行任何更改。他们通常与项目本身没有多大关系，因此在大多数情况下，只是按F5键即可。

老实说，我可以理解为什么需要锁定prod，但是我更喜欢在开发和测试环境中具有尽可能多的数据库访问权限。我认为大多数开发人员都有能力了解数据库周围的情况。但是我想听听意见吗？开发人员应具有多少数据库访问权限？我们可以信任不破坏任何东西吗？

开发人员需要对包括prod在内的所有数据库具有读取权限。有时问题出在Prod上的数据不是他们期望的，并且他们需要查看导致问题的数据，因为他们无法在dev上重现该数据。

开发人员不应具有生产数据写权限或创建对象的权限。没有正式发行的内容将不被推崇。很多时候，人们都会对无法使用的产品进行快速修复，从而导致产品变得更加糟糕或无法工作，但他们却忘记了将代码放入开发/ QA /登台服务器中，甚至将其放入源代码中控制存储库，大约一个月后，下一个正式版本中的代码将被覆盖。

我更喜欢开发人员具有完整的数据库QA权限，因为部署到另一台服务器可以帮助他们查看部署过程中是否存在任何差距（哎呀，我忘记了更改该表的目的，以此类推，哎呀，我忘记了我做了此更改）使用GUI而不是在源代码管理的脚本中使用，这是需要进行任何数据库结构更改的方式）。

当您有一个新的企业类型客户端（将拥有自己的服务器集）时，在启用之前，可能会放宽权限。这是因为发生了如此多的需求，而能够在产品上实现它的少数人被积压，有时甚至需要抽出时间。特别是从另一个系统导入数据的人员，如果数据加载将花费很长时间，则可能会被要求在启动之前将其置于产品上。这些人往往是数据专家，与普通应用程序开发人员相比，允许他们暂时访问产品的舒适度更高。使用已经投入使用的生产服务器时，这并不是奢侈。

将生产权限限制为数据库的最关键的事情之一是，开发人员随后需要确保其工作处于可以被其他人部署的形式。这往往会提高工作质量，因为他们没有尝试动态修复，因为他们忘记了某些东西，或者某些东西没有用，因为他们仅在依赖内存时对产品的处理与对设备的处理不同。当prod部署仅使用整体运行而不是像在devs开发时通常一次使用一个脚本的脚本时，您也会丢失那些“哎呀，我因为意外忘记删除了where子句而意外删除了整个用户表”的类型在产品上运行。对生产数据库具有有限权限的团队也更有可能在源代码管理中存储数据库更改。

正如杰夫·阿特伍德（Jeff Atwood）所说的，这确实是一个“吸血鬼（程序员）与狼人（系统管理员）”的问题。

通常（这意味着可以设置一个完整的环境），开发人员可以访问：

• 生产服务器
  • 无（SA / PM将适用于模式设置，最终用户将提供初始化数据）
• UAT服务器
  • 无（SA / PM将适用于架构设置和样本数据播种）
• 测试/质量检查服务器
  • 通常，开发人员会将架构设置脚本发送给质量检查小组，然后由质量检查创建表
  • 开发人员可以完全访问数据库，但很少更改数据库
  • 开发人员可以帮助质量检查小组的同事播种/修补/删除一些数据
• 开发服务器/本地主机
  • 完全访问

开发人员不应接触生产服务器的主要原因是：发生任何错误时，操作团队应负责，但开发人员不负责。

您需要完成工作的绝对最小值。

如果所有开发人员都具有完全的数据库访问权限，那么一个人生气（或喝醉，极度疲劳或...）并遭受严重破坏的机会就比他们只能从数据库读取数据的机会高得多。

如果您的工作大部分都可以在没有DB写访问权限的情况下完成（并且通常，我的意思是每周最多只有几个更改请求），那么您确实不需要写访问权限。

在所有工作环境中，都有两个相互竞争的愿望。

• 渴望让人们能够自己解决问题的途径。这使他们可以快速自助。
• 限制和控制访问以防止损坏，停机或数据丢失（有意或其他）的愿望。

影响（或无论如何）达到平衡的部分原因是对开发人员的期望。在我从事的每项工作中，开发人员都可以使用他们期望限制自己的一切。仅在知道自己在做什么时才能访问系统。这意味着您从开发人员和sysadmin的角度都知道自己在做什么。如果您不确定在这两个领域中的哪一个，没有人陪伴您就无法访问系统。

总结一下，如果您不知道，除了可以轻松重建的dev系统之外，您不应该访问任何系统。如果您确实知道，那么除了您可以轻松重建的dev系统之外，您应该不访问任何系统。

开发人员应具有对开发数据库的完全访问权限（理想情况下，他们应在本地服务器上运行，但这并不总是可能的）。他们应该有权访问build / QA数据库，但只能访问数据（必须获得许可/提交票证才能更改结构）。开发人员永远不应随意访问生产数据库（除非这是一家小公司/项目，并且开发人员也提供生产支持）。

我认为这里的关键是开发人员的责任级别。在拥有大量开发人员的大型组织中，他们可能只有只读访问QA / Test的权限才能进行开发。

但是，开发团队中应该有可以完全访问所有环境的人员。通常这是负责进行修复等的人员。虽然这有些冒险，但要在您对开发人员的信任程度，修复问题的速度以及在弄乱系统或泄露系统中涉及的风险之间进行权衡。

我在一家大型IT商店工作过，对于大多数人来说，我们的确拥有读取生产的权限。作为首席开发人员，我也有权访问生产数据库。在流程和文书工作方面，我仍然必须遵循与sysadmins和DBA相同的准则，但是如果需要，我也可以进行紧急修复。

我们大多数人都忘记了一个相关的问题-我们可能不是唯一使用数据库的人！我们倾向于认为这是理所当然的，但不应该这样做。即使是小型站点，业务人员也可能针对数据库运行第三方工具来生成报告。企业站点几乎总是有数据库表的多个用户，您的“小”更改可能会破坏其应用程序，反之亦然。

因此，这必须是第一个问题。第二个必须是有可用的人员-我曾在拥有系统管理员的站点上工作，这些系统管理员可以保护自己的地盘，但实际上并不是那么好。（这也许就是为什么他们如此地域化-他们知道如果有人环顾四周，他们会感到很热。）有时候，您必须拥有比您想要的更多的访问权限。

但是在理想世界中，我同意其他人的观点。坦率地说，我不想访问实时数据，因为我不想承担责任。考虑一下-如果我具有操作权限并且存在违规行为，那么我将不得不花费大量时间证明我与它没有任何关系。我可能不得不证明我没有出于个人原因而对数据进行封杀。很多网站都非常重视隐私，尤其是。政府网站。

我什至不希望对测试组的系统具有写/管理员访问权限。如果我不能在生产系统上做某事，那么我就不想在测试系统上做某事。读取访问是一个例外，因为有必要帮助弄清发生了什么。

个人和部门的开发系统都不同。但是，即使在这里，实际上，通常最好还是通过点名人员来运行所有数据库更改，而不是让每个人都做自己的事情。

我完全同意所有的回答，并说“生产者数据库上的开发人员应至少享有特权”。但是说实话，如果他们想要获得数据库，谁可以拒绝开发人员访问数据库。只要有足够的意愿（无论是犯罪还是永远），他们都将获得所需的访问权限。

谁可以通过将简单的SQL编辑器放入应用程序来阻止它们？这样，他们可以使用具有应用程序特权的数据库。在大多数情况下，这就是所需要的。安全配置数据库后，它们可能没有创建或删除对象的特权，但是它们至少具有对数据的读写访问权限。

我已经在这里操作人员哭了。但是老实说，除非您自己编写（甚至不考虑库），否则您无法完全控制生产环境中部署的应用程序。正如Erin所说，对于所有开发人员，您还应对生产环境负责，而不仅仅是操作人员。因此，请明智地使用您的特权。