维护更安全的环境

项目
05/26/2023

适用范围：Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012

为关键业务资产创建可管理的安全环境后，重点应转移到确保安全维护上。尽管你已获得特定的技术控制来提高 AD DS 安装的安全性，但是如果 IT 部门不与业务部门合作来维护一个安全、可用的基础结构，单靠技术并不能保护环境。本部分中的概要建议旨在用作指南，使用这些指南，你不仅可以开发有效的安全性，还可以开发有效的生命周期管理。

在某些情况下，IT 组织可能已经与业务部门有着密切的工作关系，这将简化这些建议的实施。在 IT 部门和业务部门关系不密切的组织中，可能需要首先获得管理层的支持，以便在 IT 部门和业务部门之间建立更紧密的关系。执行摘要旨在用作执行评审的独立文档，可将其分发给组织中的决策者。

为 Active Directory 创建以业务为中心的安全做法

过去，许多组织中的信息技术被视为一种支持结构和成本中心。 IT 部门通常在很大程度上与业务用户分离，交互仅限于请求-响应模型，在这种模型中，业务请求资源，IT 做出响应。

随着技术的发展和激增,“每个桌面上都有一台计算机”的愿景在世界大部分地区已经成为现实，甚至被当今各种易于访问的技术所掩盖。信息技术不再是一个支持功能，而是一个核心业务功能。如果组织无法在所有 IT 服务都不可用的情况下继续运营，则组织的业务至少在一定程度上是信息技术。

若要创建有效的入侵恢复计划，IT 服务必须与组织中的业务部门密切合作，不仅要确定 IT 环境中最关键的组件，还要确定业务所需的关键功能。通过从整体上确定什么对组织是重要的，可以专注于保护具有最大价值的组件。这并不是建议回避低价值系统和数据的安全性。而就像为系统运行时间定义服务级别一样，应考虑根据资产的关键性定义安全控制和监视的级别。

投资创建一个当前的、安全的、可管理的环境时，可以将重点转移到有效管理上，并确保拥有有效的生命周期管理流程，这些流程由 IT 部门和业务部门共同决定。要实现此目的，不仅需要与业务部门合作，还需要投资于业务部门对 Active Directory 中的数据和系统的“所有权”。

在没有指定所有者、业务所有者和 IT 所有者的情况下将数据和系统引入 Active Directory 时，对于预配、管理、监视、更新和最终停用系统，没有明确的责任链。这会导致基础结构中的系统使组织面临风险，但由于所有权不明确而无法停用。若要有效地管理由 Active Directory 安装管理的用户、数据、应用程序和系统的生命周期，应遵循本部分所述的原则。

为 Active Directory 数据分配业务所有者

Active Directory 中的数据应具有已确定的业务所有者，即指定部门或用户，该部门或用户是决定资产生命周期的联系人。在某些情况下，Active Directory 组件的业务所有者将是 IT 部门或用户。域控制器、DHCP 和 DNS 服务器以及 Active Directory 等基础结构组件很可能由 IT 部门“拥有”。对于添加到 AD DS 以支持业务的数据（例如新员工、新应用程序和新信息存储库），应将指定的业务部门或用户与数据相关联。

无论是使用 Active Directory 来记录目录中数据的所有权，还是实现单独的数据库来跟踪 IT 资产，在没有指定的记录所有者的情况下，都不应创建用户帐户，不应安装服务器或工作站，也不应部署任何应用程序。在将系统部署到生产环境中之后，尝试建立系统的所有权是一件非常具有挑战性的事情，在某些情况下甚至是不可能的。因此，应在将数据引入 Active Directory 时建立所有权。

实现业务驱动的生命周期管理

应对 Active Directory 中的所有数据实现生命周期管理。例如，在 Active Directory 域中引入新应用程序时，应用程序的业务所有者应定期证明该应用程序的继续使用情况。当应用程序的新版本发布时，应用程序的业务所有者应获得通知，并决定是否以及何时实现新版本。

如果业务所有者选择不批准部署新版本的应用程序，则该业务所有者还应获知当前版本不再受支持的日期，并应负责确定应用程序是停用还是替换。不应选择让旧版应用程序保持运行但不受支持。

在 Active Directory 中创建用户帐户时，其记录管理员应在创建对象时收到通知，并需要定期证明帐户的有效性。通过实施业务驱动的生命周期和数据有效性的定期证明，最有能力识别数据异常的人员就是查看数据的人员。

例如，攻击者可能会根据组织的命名约定和对象放置创建看似为有效帐户的用户帐户。若要检测这些帐户创建情况，可以实现一个日常任务，该任务返回所有没有指定业务所有者的用户对象，以便你可以调查帐户。如果攻击者创建帐户并分配业务所有者，则通过实现向指定业务所有者报告新对象创建的任务，业务所有者可快速确定该帐户是否合法。

应该对安全和通讯组实施类似的方法。尽管某些组可能是 IT 创建的功能组，但通过创建每个具有指定所有者的组，可以检索指定用户拥有的所有组，并要求用户证明其成员身份的有效性。与创建用户帐户时采用的方法类似，可以触发对指定业务所有者的报告组修改。如果业务所有者证明 Active Directory 中数据的有效性或无效性的做法变得越来越例行，则你越有能力识别可能指示进程失败或存在实际入侵的异常。

对所有 Active Directory 数据进行分类

除了在将 Active Directory 数据添加到目录时记录所有 Active Directory 数据的企业所有者之外，还应要求业务所有者提供数据的分类。例如，如果某个应用程序存储业务关键数据，则业务所有者应根据组织的分类基础结构将该应用程序标记为此类数据。

一些组织实现数据分类策略，根据数据被盗或暴露时数据暴露可能造成的损害来标记数据。其他组织实现按关键性、访问要求和保留来标记数据的数据分类。无论组织中使用何种数据分类模型，你都应确保能够将分类应用于 Active Directory 数据，而不仅仅是对“文件”数据应用分类。如果用户的帐户是 VIP 帐户，则应在资产分类数据库中标识该帐户（无论是通过使用 AD DS 中对象的属性来实现这一点，还是部署单独的资产分类数据库）。

在数据分类模型中，应包括对 AD DS 数据的分类，如下所示。

系统

你不仅应该对数据进行分类，还应该对其服务器群进行分类。对于每台服务器，你应该知道安装的操作系统、服务器提供的常规角色、服务器上正在运行的应用程序、记录的 IT 所有者和记录的业务所有者（如适用）。对于服务器上正在运行的所有数据或应用程序，你应要求分类，并且应根据服务器支持的工作负载的要求以及应用于系统和数据的分类来保护服务器。还可按工作负载分类对服务器进行分组，这使你可以快速识别应受到最密切监视且配置最严格的服务器。

应用程序

应按照功能（它们做什么）、用户群（谁使用应用程序）以及运行应用程序的操作系统对应用程序进行分类。应维护包含版本信息、修补程序状态和任何其他相关信息的记录。还应按应用程序处理的数据类型对应用程序进行分类，如前所述。

用户

无论你将其称为“VIP”用户、关键帐户还是使用不同的标签，都应该标记和监视 Active Directory 安装中最有可能成为攻击者目标的帐户。在大多数组织中，监视所有用户的所有活动是不可行的。但是，如果能够识别 Active Directory 安装中的关键帐户，则可以监视这些帐户的更改，如本文档前面所述。

在审核帐户时，你还可以开始为这些帐户生成“预期行为”数据库。例如，如果你发现给定的主管使用其安全工作站从其办公室和家中访问业务关键数据，但很少从其他位置访问，则当你注意到有人尝试使用其帐户从未经授权的计算机或地球另一端的某个位置（你知道该主管目前不在该位置）访问数据时，便可以更快地识别和调查此异常行为。

通过将业务信息与基础结构集成，可以使用该业务信息来帮助识别误报。例如，如果在负责监视环境的 IT 人员可以访问的日历中记录了高管处于差旅中，则可以将连接尝试与管理人员的已知位置相关联。

假设高管 A 通常位于芝加哥，使用安全的工作站从其办公桌上访问业务关键数据，而从位于亚特兰大的不安全工作站访问数据的失败尝试触发了一个事件。如果能够确认主管当前在亚特兰大，则可以通过联系主管或其助理来确定访问失败是否是因主管忘记使用安全工作站来访问数据而导致的，从而解决该事件。通过构建一个使用入侵规划中所述方法的程序，可以开始为 Active Directory 安装中最“重要”的帐户生成一个预期行为数据库，这可能有助于你更快地发现和应对攻击。