我们应该使用哪个用户帐户来执行包含敏感材料的服务器上的计划任务?

我们应该使用哪个用户帐户来执行包含敏感材料的服务器上的计划任务?

我所在的团队有 10 名开发人员。我们设置了服务器,用于执行备份、软件自动构建、自动部署等操作。其中一些服务器包含敏感信息,例如生产系统的登录详细信息(这是自动部署所必需的)。

我们希望限制谁有权访问这些机器,以降低密码意外泄露的风险。为此,我们在 Active Directory 中创建了一个组,其中包含 4 个人,他们被允许访问包含敏感材料的服务器,并确保只有这 4 个用户可以登录。

其中一些服务器运行计划任务和 Windows 服务来执行备份/部署。这些任务/服务在特定的“共享”用户帐户下运行,我们称之为“buildacc”。原因是这些任务需要访问网络中的共享资源才能执行构建/部署。所以我们也授予此用户访问服务器的权限。

为了能够修改 Windows 中的计划任务,所有 4 位开发人员都需要访问这个“buildacc”帐户,这意味着他们都必须知道共享密码并在密码更改时互相通知,但我们不喜欢这个想法。

我们考虑过使用个人帐户来运行计划任务,例如构建脚本。我们发现的缺点是团队中的任何成员都可以更改构建脚本,并使其在配置实际计划任务的用户帐户下执行新操作。

是否有任何关于如何处理这种情况的最佳做法?

答案1

假设您正在使用 Windows 2008R2 系统和 2008R2 AD,您可以为此使用托管服务帐户。

此 Technet 博客文章对如何使用托管服务帐户进行了很好的总结,但基本原则如下:

托管服务帐户是与计算机紧密绑定且具有自动管理密码的 AD 帐户。您无需创建密码,而且没有人需要知道它,但由于它是 AD 帐户,因此您可以将其用于网络 ACL,这使其非常适合您的场景。

但是,使用 MSA 执行计划任务需要您使用命令行来创建任务(请参阅线程以了解更多详细信息)。

答案2

总体而言,您之前所做的一切都很好。一个专用的“服务”式帐户,设置了所需的权限,用于运行计划任务。

此时,您真正需要做的是:

  1. 将密码更改为buildacc
  2. 不要让 4 位开发人员知道密码
  3. 在开发人员更改其代码后,指派某人负责更改脚本/任务(即更改控制策略)。

目前这实际上只是一个内部政策问题。您应该设置计划任务,以便它们不会真正改变。这意味着如果它正在运行“test.exe”,那么让开发人员修改该 exe 文件,但不要修改计划任务本身。如果所有 4 名开发人员确实需要访问权限来更改计划任务,那么您就只能停留在原地了……

编辑:我还想提醒您,不要buildacc在服务和服务器上过度使用您的帐户。最好将其严格用于“构建”,并让备份和其他服务在其自己的专用帐户下运行。

答案3

我看到几个答案提到 MSA 是用于运行计划任务的帐户的解决方案,但正如本文作者所提到的,他们使用的是 Windows Server 2008 R2,根据我的研究,此操作系统上的 MSA 无法用于运行计划任务

但是,在 Windows Server 2012 中,可以使用 gMSA(组托管服务帐户)来运行计划任务,如本文所述文章

相关内容