我在一个有 10 名开发人员的团队中工作。我们设置了执行备份、自动构建软件、自动部署等的服务器。其中一些服务器包含有意义的材料，例如生产系统的登录详细信息（这是自动化部署所必需的）。
我们希望限制谁可以访问这些机器，以降低密码意外泄露的风险。为此，我们在 Active Directory 中创建了一个包含 4 个人的组，这些人被允许访问包含敏感材料的服务器，并确保只有这 4 个用户可以登录。
其中一些服务器运行计划任务和 Windows 服务来执行备份/部署。这些任务/服务在特定的“共享”用户帐户下运行，我们称之为“buildacc”。这样做的原因是任务需要访问网络中的共享资源才能执行构建/部署。所以我们也给了这个用户访问服务器的权限。
为了能够在 Windows 中修改计划任务，所有 4 名开发人员都需要访问这个“buildacc”帐户，这意味着他们都必须知道共享密码并在更改时通知对方，我们不喜欢这个想法的。
我们考虑过使用个人帐户来运行计划任务，例如用于构建的脚本。我们看到的缺点是团队中的任何成员都可以更改构建脚本并使其在配置实际计划任务的用户帐户下执行新操作。
有没有关于如何处理这种情况的最佳实践？
总体而言，您前面所做的一切都很好。一个专用的“服务”样式帐户，设置了所需的权限并用于运行计划任务。
此时，您真正需要做的就是：
buildacc在这一点上，这实际上只是一个内部政策问题。您应该设置计划任务，以便它们不会真正改变。这意味着如果它正在运行“test.exe”，那么让开发人员修改该 exe 文件，而不是计划任务本身。如果所有 4 名开发人员都真正需要访问权限来更改计划任务，那么您将被困在原地...
编辑：我还要提醒您不要对
buildacc跨服务和服务器的帐户过于自由。最好严格保留它以用于“构建”，并在他们自己的专用帐户下运行备份和其他服务。假设您使用的是 Windows 2008R2 系统和 2008R2 AD，您可以为此使用托管服务帐户。
这篇 technet 博客文章对如何使用托管服务帐户进行了很好的总结，但以下是基本原则：
托管服务帐户是与计算机紧密关联的 AD 帐户，并具有自动管理的密码。您无需创建密码，也没有人需要知道它，但由于它是一个 AD 帐户，您可以将它用于网络 ACL，这使其非常适合您的场景。
但是，将 MSA 用于计划任务将要求您使用命令行来创建任务（有关更多详细信息，请参阅此线程和此线程）。
我看到几个答案提到 MSA 作为用于运行计划任务的帐户的解决方案，但正如本文作者所提到的，他们使用 Windows Server 2008 R2，根据我的研究，此操作系统上的 MSA 不能用于运行计划任务。
但是，对于 Windows Server 2012，gMSA（组托管服务帐户）可用于运行计划任务，如本文所述。