锁定开发人员机器是否比其价值更多？[关闭]

大多数开发人员都精通技术并且知道他们在做什么。他们通常需要安装许多专业应用程序，必须获得许可才能执行此操作，并让 IT 下来并添加它，这对双方来说都是非常令人沮丧的，尤其是在大公司中。

我发现最有效的方法是允许他们在他们的机器上安装软件时做他们想做的事，但如果他们遇到我们不支持的问题，那么他们就只能靠自己了。大多数开发人员对此感到满意，并且更喜欢能够照看自己的机器。

将某人锁定为仅使用 IE 和打开 word 很好，但是如果您的开发人员需要安装 4 种不同类型的浏览器并且需要快速安装应用程序来解决问题，那可能会很烦人。

我的经验是，拥有大量技术知识的公司，例如开发商店、IT 供应商等，信任他们的员工并让他们决定他们想要安装的东西，他们会更快乐并且更少打扰 IT

有关锁定开发人员机器的优点的激烈辩论，请参阅此 Stackoverflow 帖子。（免责声明：我写了接受的答案）。

从系统管理员的角度来看，对生产系统的访问是敏感的，您应该将此类访问限制为需要它来完成工作的人（这可能包括对应用程序负有第 3 层支持责任的开发人员）。开发 PC 或开发服务器的本地管理员权限不会显着损害生产系统的安全性。

如有必要，制作可用于重建机器的映像。手动安装 SQL Server 开发版、Visual Studio、Cygwin 和 MikTex 以及一堆其他应用程序非常耗时。如果您必须对机器进行大量重新映像，则安装了这些大型应用程序的映像将相当有价值。

从开发的角度来看，我发现我可以解决机器的大多数问题，并且通常只在极少数情况下需要网络支持人员的帮助。过度限制的环境往往会产生虚假的开发支持流量来完成开发人员完全有能力自己完成的工作。

开发人员往往需要完成大量管理工作的另一个地方是托管开发环境的数据库服务器。大多数开发人员能够轻松地学习日常 DBA 任务，并且无论如何都应该获得这方面的工作知识（原则上恕我直言）。开发服务器上过于严格的管理员访问策略可能会在许多方面受到影响。

如果可以安排一个临时开发网络是一个很好的主意 - 如果需要，您可以将其从生产服务器中设置为防火墙。

• 当开发人员可以轻松地复制生产环境的结构时，它会促进部署测试的文化，在这种文化中，可以合成集成测试而无需跳过障碍。这将倾向于提高生产发布和部署的质量。

• 能够模拟生产环境还可以提高对生产部署和支持问题的认识。它鼓励开发人员考虑如何在生产中支持应用程序，这可能会鼓励以此为基础构建的架构。

• 如果此网络有域控制器，您可以建立信任关系，以便它信任您的主域控制器及其帐户。这种信任关系不必是互惠的，因此不会损害生产网络基础设施的安全性。这可以让您拥有一个不受信任的开发网络，但仍允许开发人员访问经过域验证的资源，例如 Exchange 帐户或文件服务器。

• 您希望开发人员拥有合理的实验范围，而不必费劲。在这项工作的道路上设置政治障碍倾向于鼓励粘贴石膏解决方案，这些解决方案在政治上是权宜之计，但会产生长期（并且通常是未被承认的）技术债务。作为系统管理员或支持分析师，猜猜谁来收拾残局……

我要补充一点，这在 unix 或 linux 环境中的问题要小得多。用户可以从他们的.profile. /home/bloggsj/bin您可以根据自己的喜好在自己的目录下编译和安装东西。“本地管理员权限”主要是 Windows 问题，尽管在 Unix 下仍有一些需要 root 访问权限的东西。

不锁定开发人员机器的最大问题是他们开发的任何软件都需要完全的管理员权限才能运行。开发人员的访问权限应该与他们需要运行的环境相同。如果他们需要“自我支持”或“自我安装”，那么给他们另一个管理员帐户，例如 Bruce.admin，他们在进行管理时需要使用该帐户东西，但不是每天都用。

就像没有一个称职的 UNIX 管理员会在日常非管理员工作中使用 root 帐户一样。

我见过的最明智的选择（双方都存在 - 现在仍然 - ）只是解锁的东西并且也不受支持。给他们自由，如果他们搞砸了，他们所能得到的只是一个标准形象的重演…… 在这种情况下，我发现将它们放在某种形式的“不受信任”网络上是一个很好的计划。

至于锁定开发人员桌面的（非）意义：我很确定所有的锁定无论如何只会阻碍生产力，此外，任何相当熟练的开发人员都会很容易找到漏洞......。

答案是真的：没有简单的是或否的答案。但对于您的开发用户而言，安全性至少与其他任何人一样重要。

一方面，是的，开发人员往往在技术上更精通。另一方面，他们的工作通常压力很大，他们的开发里程碑可能优先于维护自己的系统作为安全环境所需的额外注意。这不是对开发人员的批评；这是对开发人员的批评。这是对他们日常职责的直率考虑。

如果您要让开发人员完全、不受限制地访问他们的系统，那么您真的应该考虑以下额外措施：

• 提供另一个系统，锁定与普通用户系统一样多，用于正常的非开发人员使用。
  • 他们将他们完全访问的开发机器放入一个特殊的 VLAN 中，只能访问开发资源。
• 询问是否有任何东西可以防止受感染的系统危及代码库。安装后门的机器能否检查恶意代码，或者清除恶意黑客手中的代码库？采取适当的措施来降低这种风险。
• 同样，询问是否有任何东西可以保护开发人员可以访问的系统中保存的业务数据。
• 定期对开发系统进行软件盘点和安全审计。
  • 了解他们正在运行什么，并使用这些信息来构建您的开发系统重新部署映像。
  • 迟早你会有一个粗心大意的开发人员安装明显危险或完全与工作无关的东西。通过在发生这种情况时快速发送警告，您将让开发社区知道是的，有人在监视，他们确实有责任保持在合理的标准内。
• 您是否定期进行恶意软件扫描？在某些情况下，开发人员会正确地抱怨按访问 AV 系统征收的性能税（那些始终打开的 AV 系统，总是在每次文件访问时扫描）。最好采用夜间扫描策略，和/或为您的按访问扫描创建文件/文件夹排除项。不过，请确保以其他方式扫描排除的文件。
  • 您启用管理员的开发人员可以关闭所有 AV 扫描吗？您将如何检测和修复此问题？

如果你要锁定开发系统，那么你应该考虑以下几点：

• 您是否有能力快速回答他们的支持请求？考虑您的开发人员的平均工资率，并询问他们是否应该获得更快的响应时间 SLA。在您处理来自每年 6 万美元员工的支持请求时，让您的 12 万美元开发人员（数百万美元项目的关键）等待可能没有意义。
• 对于您将为开发人员提供和不提供哪些支持请求，您是否有明确而明确的政策？如果他们开始觉得支持是任意的，你最终会感到痛苦。

无论哪种方式，您都需要承认开发人员是一个特例，他们确实需要某种额外的支持。如果你没有为此做预算，问题可能现在正在恶化……或者将来会出现。

作为旁注，我已经看到系统管理员发生了非常相似的争论。在至少两个不同的工作中，当有人建议他们自己应该锁定系统或至少使用两个登录名（一个具有 root/admin privs；一个没有）时，我看到系统管理员非常激烈地争论。许多系统管理员认为他们不应该以任何方式被锁定，并极力反对这种措施。迟早，一些厌恶锁定的管理员会发生安全事件，这个例子会对我们所有人产生教育影响。

我曾经是那些一直使用管理员权限运行的系统管理员之一。当我更改为双账户并且只在需要时提升时，我承认在最初的几个月里这非常令人沮丧。但云中的一线希望是，当我的普通帐户受到我对用户施加的相同限制时，我对我正在管理的系统的安全性有了更多了解。它让我成为了一个更好的管理员！我怀疑开发人员也是如此。幸运的是，在 Windows 世界中，我们现在拥有 UAC，这使得作为受限用户更容易运行并且仅在需要时提升。

就我个人而言，我不认为任何人都应该超越某种形式的安全实践。每个人（包括系统管理员、开发人员、高层管理人员）都应该受到足够的安全程序和监督，以保持他们的警觉。否则就是说公司系统和数据不值得努力保护。

让我们换一种说法。如果 Mark Russinovich 可以被rootkit 感染，那么任何人都可以！

如果你有几个开发人员，给他们开发服务器的方法是可能的，但是如果你有一整层的开发人员，那么我非常反对给他们任何管理员权限。

问题是你最终会得到一整层的开发人员，每个人都在做他们所做的事情，通常大多数人甚至没有安全意识，只是希望他们的应用程序能够工作。然后你会收到一个请求——“我们已经完成了开发阶段，请将我们的开发环境复制到测试、预产品和产品中”。

他们还养成了安装随机垃圾（包装不良的软件）的习惯，然后委托您将其安装在其他层的十几台服务器上。

我使策略非常简单：

• 开发人员永远不会获得开发环境的 root 访问权限。
• 开发人员确实获得了对预开发 VMware 服务器的 root 访问权限，但没有支持。
• 开发人员必须提供属于其应用程序将在其上运行的 OS 发行版的 RPM 包，或者提供符合 FHS 和 LSB 的 RPM 包。
• 他们的应用程序在任何情况下都不能以 root 身份运行
• 将无权访问su或访问sudo应用程序用户 - 这将被锁定为没有 shell 访问权限。（这是用于会计/审计）。
• 他们需要以特权访问权限运行的任何命令都必须被明确请求和批准——此时它将被添加到sudoers文件中。
  • 这些命令/脚本都不能被它们写入。
  • 这些命令的任何脚本（直接或间接）引用都不能被它们写入。

最重要的是，让他们思考在将项目转移到测试和以上服务器时允许和不允许什么。

锁定开发人员的机器需要付出更多的努力。它严重损害了生产力，因为如果没有管理权限，您几乎无法做任何事情。当然，最终系统会变得一团糟，但您的 IT 部门肯定没有为开发中使用的所有第三方工具提供支持吗？

因此，正如 Vincent De Baere 所建议的那样，最好的做法是从映像中恢复系统，当然，之后必须恢复环境，但这不应该是 IT 的问题。如果这种情况发生 N 次，您可以将某个人列入某种“黑名单”，并且，是的，暂时放弃他的管理权限。

无论哪种方式，环境都应该以某种方式设置，以确保受感染（或以其他方式混乱）的机器根本不会影响任何其他机器，或者说，不会发送垃圾邮件或其他东西（好的，现在我只是说一些显而易见的事情，对不起）。

嗯，它可能部分取决于您运行的环境（例如 Linux 与 Windows）；然而，假设一个 Windows 环境，它通常比它值得的麻烦更多，因为那里的一些开发软件需要你有更高的权限才能工作。例如，众所周知，Visual Studio 需要管理员权限，因此，我看不出让某人跳过箍以完成其工作所需的部分的好处。

但是，如果公司要求将事情锁定，您最好的选择可能是为所有开发人员提供他们系统上的虚拟机，让他们在其中发疯。虽然有些人可能不太喜欢这样，但它可能会为您提供两者中最好的世界（例如限制性的普通桌面和完全可定制的环境）。

更新- 在 Windows 方面还有一点值得注意，显然需要管理员权限的 Visual Studio 有点过时了，现在有明确的方法来设置所需的权限（PDF 文件）。但是，我认为这并没有太大改变我的选择，因为我认识的大多数开发人员，包括我自己在内，都倾向于使用除 Visual Studio 之外的其他工具，并且很难预测他们所有人在权限方面需要什么。

我同意在受限桌面上使用虚拟机的想法——

除非另有必要，否则我觉得最好的设置是一个受限的 linux 桌面，顶部有一个免费的 vm。Linux 为我减少了开销，一个 vm 不仅可以是他们想要的任何操作系统，还可以恢复到快照或备份，而且当没有大量不同的设置需要时，世界看起来会更明亮一些支持。

我（作为开发人员自己）更喜欢完全控制我的机器，意思是；需要时以管理员身份运行。

在允许开发人员完全访问他们的计算机之前，您可以为他们提供特殊培训。为他们制定一些规则，也许你可以每隔一段时间进行一次审核，看看他们是否遵循最佳实践。

大多数情况下，他们需要从 IT 管理员/IT 支持的角度了解更多关于 IT 基础架构的信息、与安全相关的内容，以及为什么不使用提升的权限进行开发。（以及如何确保您不...）

“当我们告诉您我们知道所有关于计算机的知识时，不要盲目相信我们”;-)

您仍然需要通过网络、域和帐户内容、非开发工具的软件安装等来支持他们。