为什么不应该让开发人员接近 root 密码？

Question

我刚刚发现服务器机房里有东西在燃烧；我怎样才能快速识别它是什么？. 在评论中，我发现了以下引用：

you don't let a developer anywhere near your root passwords

作为一名开发人员，同时也是对系统管理员非常感兴趣的人，我想知道这个短语是否不仅仅是每个人的标准——也就是说，不要泄露密码？评论者说这好像在系统管理员社区中是相当普遍的知识。是吗？

Answer 1

由于生产系统的操作职责通常属于系统管理员，因此只有系统管理员应该对系统具有完全的管理访问权限 - 就这么简单。

现在，您可能会说：“好吧，有时我们会更改需要重新配置系统的代码，难道我们不应该有权相应地重新配置系统吗？”

不

如果您的代码更改需要重新配置系统，您应该能够向系统管理员解释您有什么要求。这样，系统管理员可以审查您的变更要求，并在变更可能具有您（作为开发人员）未预见到的操作影响时停止变更。

在回应@NathanLong 时，我意识到在小型企业中有时会出现这种情况。在这些情况下，管理员和开发人员是相同的用户，另一种方法是在多人之间划分系统所有权，并确保没有人 - 我的意思是没有人 - 推动他们自己的配置更改。让另一个开发人员审查您的更改，让第三个开发人员进行重新配置。

每当出现疑问时，从变更计划和审查开始——其他任何事情都会构成可怕的变更管理

Answer 2

我并不是说系统管理员是完美的，但是有大量开发人员的例子甚至不应该是开发人员。更不用说被允许对具有关键任务数据的系统进行 root 访问。

但无论如何，它主要是对所做的更改负责。对于许多系统管理员来说，似乎开发人员会在服务器上做事，然后他们不对他们所做的事情负责。开发人员通常只专注于获得他们正在进行的单个程序/任务，而不会花时间考虑他们所接触的系统的全局或长期状态。他们还没有学会如何安全地做出改变的习惯。

并非所有开发人员都如此，当然有一些优秀的开发人员可以很好地维护系统。似乎这些在 95% 的情况下都是正确的。

像这样的习惯：

• 不要在没有先在开发系统上测试的情况下对系统进行更改
• 不要做你不理解的改变（盲目谷歌，做你不理解的事情）
• 不要在没有确认您知道备份系统正在工作以及如何回滚您所做的任何事情之前进行更改。
• 不要进行会使系统更难以长期维护的更改。（即，不要增加任何技术债务）
• 不要损害系统的安全性
• 不要以会增加潜在监管风险的方式更改系统（请参阅 PCI-DSS、HIPPA、FERPA 等）

Answer 3

我会试着用一个比喻来解释（我是一名开发人员，偶尔会做系统管理员的事情。）

画家和室内设计师

假设开发人员是一位画家，并创作了许多奇妙的画作。好吧，也许它们并不出色，但他做了雇主要求他做的东西。他很擅长这个，所以所有的画都很好。

现在这些画需要放置在各自的建筑物内。画家知道关于油漆的一切，但不知道如何正确地将某物安装在墙上。如果画家决定无论如何都要尝试（因为他可以），那么几周后室内设计师（系统管理员）可能会像这样回答：“这里发生了什么……？” “一切都歪了，这个..这个必须挂在天花板上！这他妈的怎么粘在wa上..那是胶水！？”

不用说，室内设计师本可以做得更好。他知道把什么放在哪里，以及如何安装它。他一贯使用相同的螺钉和偶尔使用的电线。他以前做过一千次，几乎可以闭上眼睛。

长话短说：系统管理员知道如何比开发人员更好地处理他的设备（至少他应该这样做）。他将保持他的系统干净和有条理，并且知道整个事情是如何运作的。此外，许多开发人员习惯于做系统管理员的工作（例如在家里），如果可以，他们会尝试自己做，因为这样可以节省他们的时间。

当然也有一个人同时做两个的情况，但他们很可能是在相对简单的环境或经理没有看到他实际上需要两个人的地方。

Answer 4

我建议转过身来，把自己放在对方的位置上。

所以，在这种情况下：

为什么系统管理员不应该拥有修改源代码的完全访问权限？

对我来说，总而言之，开发人员不应该拥有 root 访问权限，因为从系统管理的角度来看，他们不一定知道自己在做什么，并且不需要（或不应该）需要它，因此授予 root 权限实质上是增加了导致问题的风险，而没有任何好处。管理系统是别人的工作。

出于同样的原因，就像系统管理员不应该更改代码一样。