作为开发人员并为开发团队提供IT管理/支持后，我遇到了许多不同类型的环境，从完全锁定到完全非锁定。根据我有限的支持经验，我认为使用较少锁定的机器支持的工作较少，我当然觉得这很容易，但是当然这可能会产生偏差。我想从IT支持的角度了解这种观点，难道要真正支持那些没有锁定机器的开发人员吗？
Answers:
不锁定开发人员计算机的最大问题是，他们开发的任何软件都将需要完整的管理员特权才能运行。开发人员的访问权限应与他们将在其中运行的环境相同。如果他们需要“可自我支持”或“可自行安装”，请给他们另一个管理员帐户（例如Bruce.admin），以便在执行管理时使用东西，但不是日常使用。
就像没有一个值得称职的UNIX管理员一样，他们会在日常非管理员工作中使用根帐户。
大多数开发人员在技术上都很精通，并且知道自己在做什么。他们通常需要安装许多专业应用程序，必须获得许可才能执行此操作，并降低IT并添加它，这对双方都非常令人沮丧，尤其是在大型公司中。
我发现最有效的方法就是允许他们在计算机上安装软件方面做自己想做的事情，但是如果他们遇到我们不支持的问题，那他们就该靠自己了。大多数开发人员对此感到满意，并且宁愿能够照看自己的机器。
将某人锁定为仅使用IE和开放单词是可以的，但是如果您的开发人员需要安装4种不同类型的浏览器并且需要快速安装应用程序来解决问题，那么这可能会很烦人。
我的经验是，拥有大量技术知识的公司，因此信任他们的员工并让他们决定要安装的产品的开发车间，IT供应商等，会快乐得多，而对IT的困扰则更少
有关锁定开发人员机器的优点的一些生动讨论，请参见此Stackoverflow发布。（免责声明：我写了接受的答案）。
从系统管理员的角度来看，对生产系统的访问是敏感的，您应该将此类访问限制为需要其才能完成工作的人员（其中可能包括对应用程序具有三级支持职责的开发人员）。对开发PC或开发服务器的本地管理员权限不会显着损害生产系统的安全性。
如有必要，制作一张可用于重建机器的映像。手动安装SQL Server开发版，Visual Studio，Cygwin和MikTex以及许多其他应用程序非常耗时。如果您需要对计算机进行大量重新映像，则安装了这些大型应用程序的映像将具有相当的价值。
从开发角度来看，我发现我可以解决机器上的大多数问题，并且通常只在极少数情况下需要网络支持人员的帮助。过于严格的环境往往会产生虚假的开发支持流量，以完成开发人员完全有能力自己做的工作。
开发人员往往需要完成大量管理工作的另一个地方是托管开发环境的数据库服务器。大多数开发人员都能够轻松地学习日常的DBA任务，并且无论如何都应该获得有关此方面的工作知识（原则上为恕我直言）。开发服务器上过于严格的管理员访问策略可能会以多种方式出现。
如果可以安排临时开发网络，则是个好主意-如有必要，您可以从生产服务器对它进行防火墙。
当开发人员可以轻松地复制生产环境的结构时，它会促进部署测试的文化，在这种环境中可以集成集成测试而不会遇到麻烦。这将倾向于提高产品发布和部署的质量。
能够模拟生产环境还可以提高对生产部署和支持问题的认识。它鼓励开发人员考虑如何在生产中支持应用程序，这可能会鼓励在此基础上构建体系结构。
如果此网络具有域控制器，则可以建立信任关系，以便它信任您的主域控制器及其帐户。此信任关系不必是互惠的，因此不会损害生产网络基础结构的安全性。这可以使您拥有不受信任的开发网络，但仍允许开发人员访问经过域身份验证的资源，例如Exchange帐户或文件服务器。
您希望开发人员具有合理数量的试验范围，而不必跳过难题。在这项工作的道路上放置政治障碍有一种趋势，就是鼓励在政治上权宜之计，但会产生长期的（通常是无法识别的）技术债务，采用石膏解决方案。作为系统管理员或支持分析师，请猜猜谁有能力...
我将补充说，这在Unix或Linux环境中几乎没有问题；用户可以从他们的电脑大量定制自己的环境.profile。您可以将文件编译并安装在自己的/home/bloggsj/bin目录下，以使您满意。“本地管理员权限”主要是Windows的问题，尽管在Unix下仍有一些需要root访问的权限。
我见过的最明智的选择（一直都是-仍然是-）只是解锁的东西，也不受支持。给他们自由，如果他们搞砸了，他们所能得到的只是带有标准形象的休息。在这种情况下，我发现将它们放置在某种形式的“不可信”网络中是一个不错的计划。
至于锁定开发人员桌面的（无意义）：我很确定所有锁定都只会阻碍生产力，而且，任何精通技术的开发人员都将很容易发现漏洞。
答案确实是：没有简单的是或否答案。但是安全至少对您的开发用户和其他用户同样重要。
一方面，是的，开发人员在技术上往往更精通。另一方面，他们的工作通常很繁重，他们的开发里程碑很可能会优先考虑将自己的系统维护为安全环境所需的额外照顾。这是他们日常工作的直接考虑。
如果要为开发人员提供不受限制的完整访问权限，那么您应该真正考虑以下其他措施：
如果要锁定开发系统，则应考虑以下事项：
无论哪种方式，您都需要承认开发人员是特例，并且他们确实需要某种形式的额外支持。如果您没有为此做预算，那么问题可能会立即恶化……或者将来会恶化。
附带说明一下，我已经看到sysadmins发生了非常类似的争论。当有人建议系统管理员应该自己锁定系统或至少使用两个登录名（一个具有root / admin privs；一个不具有root身份）时，我至少在两次不同的工作中遇到过系统管理员激烈的争论。许多系统管理员认为他们不应以任何方式受到限制，并强烈反对这种措施。某些厌恶锁定的管理员迟早会发生安全事件，并且该示例会对我们所有人产生影响。
我曾经是一直与admin privs一起运行的那些系统管理员之一。当我更改为双重帐户并且仅在需要时才进行更改时，我承认在最初的几个月中这非常令人沮丧。但是，当我的普通帐户处于对用户施加的相同限制下时，我在云管理中的一线希望是，我了解了很多有关所管理系统的安全性的知识。它使我成为更好的管理员！我怀疑开发人员也是如此。幸运的是，在Windows世界中，我们现在有了UAC，这使得以受限用户的身份运行并仅在需要时提升权限变得更加容易。
我个人认为任何人都不应超越某种形式的安全实践。每个人（包括系统管理员，开发人员，高层管理人员）都应受到足够的安全性程序和监督，以使他们始终保持警惕。换句话说，就是公司的系统和数据不值得保护。
让我们换一种说法。如果Mark Russinovich可以被rootkit接受，那么任何人都可以！
如果您有几个开发人员，则可以为他们提供开发服务器的方法，但是如果您有整个开发人员，那么我非常反对给他们任何管理员权限。
问题在于，您最终将需要一整层开发人员，每个开发人员都在做他们所做的事情，通常大多数人甚至都不了解安全性，只希望他们的应用能够正常工作。然后，您会遇到以下要求-“我们已经完成了开发阶段，请将我们的开发环境复制到测试，预生产和生产中”。
他们还习惯于安装随机的垃圾邮件（包装不良的软件），然后委派您将其安装在其他层的十几台服务器上。
我使政策非常简单：
su或访问sudo应用程序用户-这将被锁定为没有外壳程序访问权限。（这是用于会计/审计）。sudoers文件中。
上面的内容将使他们思考何时将项目移至测试及以上服务器上时将允许和不允许的事情。
锁定开发人员的计算机所付出的努力超过了其价值。它严重损害了生产力，因为没有管理权限您几乎无法做任何事情。当然，最终系统将变得混乱不堪，但是您的IT部门肯定不会为开发中使用的所有那些第三方工具提供支持吗？
因此，正如Vincent De Baere所建议的那样，最好的措施就是从映像还原系统，当然，此后必须恢复环境，但这不应该是IT的问题。如果发生了N次，您可以将某人列入“黑名单”，是的，可以暂时放弃其管理权限。
无论哪种方式，都应该以某种方式设置环境，以确保受感染（或以其他方式弄乱）的计算机完全不会影响任何其他计算机，或者例如不会发送垃圾邮件或其他东西（好的，现在我只是说明显的话，对不起）。
嗯，这可能部分取决于您所运行的环境（例如，Linux与Windows）。但是，在Windows环境下，通常麻烦多于其价值，这仅仅是因为那里的某些开发软件要求您具有提升的工作权限。例如，众所周知，Visual Studio需要管理员权限，因此，我看不出让某人跳入箍圈以完成其工作的必要部分的好处。
但是，如果公司要求锁定一切，那么您最好的选择可能是让他们的系统上的所有开发人员都能沉迷于虚拟机。尽管有些人可能对此不太喜欢，但是这可能会给您带来最好的收益。世界（例如限制性的普通桌面和完全可自定义的环境）。
更新 -在Windows方面，还有一点需要注意，显然要求管理员权限的Visual Studio有点陈旧，现在有明确的方法来设置所需的权限（PDF文件）。但是，我认为这不会改变我的选择，因为我认识的大多数开发人员（包括我自己）倾向于使用除Visual Studio之外的其他工具，并且很难理解他们在权限方面的全部需求。
我（作为开发人员本人）更希望完全控制我的机器，这意味着：在需要时以管理员身份运行。
您可以在允许开发人员完全访问他们的计算机之前为他们提供特殊的培训。为他们设置一些规则，也许您可以每一次进行一次审核，以了解它们遵循最佳实践。
通常，他们需要从IT管理员/ IT支持的角度，与安全性相关的内容以及为什么不以提升的权限进行开发的方面更多地了解IT基础架构。（以及如何确保您不会...）
“不要盲目地信任我们，当我们告诉你，我们都知道，我们需要了解电脑” ;-)
您仍然必须通过网络，域和帐户资料，非开发工具的软件安装等来支持它们。
我的经验是，仅需要锁定机器的用户和需要管理员访问权限的其他人（开发人员，科学家）几乎平均分配给用户。他们的高端人员使用了很多不同的软件，有些是内部使用的，有些不是内部使用的，但是许多软件需要管理员来运行，而他们的工作要求他们使用很多软件包，因此让人们去做最有意义它自己。
我们完成了以下过程：
我们本来希望将所有具有管理员访问权限的人放在“不受信任的” vlan上，但我们从来没有做到过。