锁定开发人员的机器是否比其价值更努力？

Question

作为开发人员和开发团队的 IT 管理员/支持人员，我遇到了许多不同类型的环境，从完全锁定到完全没有。在我有限的支持经验中，我认为使用锁定较少的机器支持较少的努力，我当然觉得这更容易，但这当然可能是偏见。我想知道从 IT 支持的角度是什么观点，支持没有锁定机器的开发人员真的更难吗？

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

答案是真的：没有简单的是或否答案。但安全性对您的开发用户和其他任何人来说至少同样重要。

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

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

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

如果您要锁定开发系统，则应考虑以下事项：

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

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

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

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

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

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