了解 AppLocker 策略设计决策

本主题面向 IT 专业人员列出了在 Windows 操作系统环境中通过使用 AppLocker 规划应用程序控制策略部署时遇到的设计问题、可能的解答以及决策的后果。

当开始设计和规划流程时，应考虑设计选择带来的后果。最终产生的决策将会影响你的策略部署方案以及后续的应用程序控制策略维护。

如果满足以下所有条件，则应考虑将 AppLocker 用作组织的应用程序控制策略的一部分：

• 已在组织中部署或计划部署受支持版本的 Windows。有关特定操作系统版本的要求，请参阅使用 AppLocker 的要求。

• 需要加强控制对组织应用程序的访问权限和用户访问的数据。

• 组织中的应用程序数量已知且易于管理。

• 拥有针对组织要求测试策略的资源。

• 拥有涉及技术支持或针对最终用户应用程序访问问题生成自助流程的资源。

• 小组对工作效率、可管理性以及安全性的要求可由限制策略控制。

以下问题未按优先级或先后顺序进行排序。在部署应用程序控制策略时应考虑这些问题（根据目标环境的需要）。

在组织中需要控制哪些应用？

你可能需要控制有限数量的应用，因为它们会访问敏感数据，你也可能需要排除所有应用程序（那些被认可用于商业目的的应用程序除外）。可能某些业务组要求进行严格控制，而其他组推广独立使用应用程序。

可能的解答	设计时的注意事项
控制所有应用	AppLocker 策略通过按文件类型创建一个允许的应用程序列表来控制应用程序。也可能存在例外。AppLocker 策略仅可应用于在运行受支持的 Windows 版本之一的计算机上安装的应用程序。有关特定操作系统版本的要求，请参阅使用 AppLocker 的要求。
控制特定应用	在你创建 AppLocker 规则的同时，也会创建一个允许的应用列表。该列表中的所有应用都允许运行（例外列表中的应用程序除外）。不在该列表中的应用将阻止运行。AppLocker 策略仅可应用于在运行任何受支持的 Windows 版本的计算机上安装的应用。有关特定操作系统版本的要求，请参阅使用 AppLocker 的要求。
只可以控制经典 Windows 应用程序和/或通用 Windows 应用	AppLocker 策略通过按文件类型创建一个允许的应用列表来控制应用。因为通用 Windows 应用归类到发布者条件下，所以可以一起控制经典 Windows 应用程序和通用 Windows 应用。适用于通用 Windows 应用的 AppLocker 策略只能应用于在支持 Windows 应用商店的电脑上安装的应用，而经典 Windows 应用程序可通过所有受支持版本的 Windows 中的 AppLocker 进行控制。当前已为经典 Windows 应用程序配置的规则可以保留，并且还可以为通用 Windows 应用创建新的规则。 有关经典 Windows 应用程序和通用 Windows 应用的比较，请参阅本主题中的针对 AppLocker 策略设计决策比较经典 Windows 应用程序和通用 Windows 应用。
按业务组和用户控制应用	AppLocker 策略可通过组策略对象 (GPO) 应用到组织单位 (OU) 中的计算机对象。单个 AppLocker 规则可应用于单个用户或用户组。
按计算机（而非用户）控制应用	AppLocker 是一种基于计算机的策略实现。如果域或站点组织结构不是建立在逻辑用户结构之上（例如 OU），则在开始 AppLocker 计划之前，你可能需要建立该结构。否则，你将需要标识用户、其计算机及其应用访问要求。
了解应用使用情况，但尚无必要控制任何应用。	可将 AppLocker 策略设置为审核应用使用情况来帮助你跟踪组织中使用了哪些应用。然后可使用 AppLocker 事件日志创建 AppLocker 策略。

 

要点  

以下列表包含了 AppLocker 无法管理的文件或文件类型。

• AppLocker 不会防止在 NT Virtual DOS Machine (NTVDM) 中运行 16 位 DOS 二进制文件。如果另一个操作系统已运行和控制 Intel 80386 或更高版本，此技术将允许在使用该硬件的计算机上运行旧版 DOS 和 16 位 Windows 程序。因此，当 AppLocker 已配置为以其他方式阻止二进制文件和库时，16 位二进制文件仍可运行在 Windows Server 2008 R2 和 Windows 7 上。如果要求阻止 16 位应用程序运行，则必须在可执行规则集合中为 NTVDM.exe 配置拒绝规则。

• 你无法使用 AppLocker 阻止代码在 Win32 子系统外部运行。尤其应用于 Windows NT 中的 (POSIX) 子系统。如果要求阻止应用程序在 POSIX 子系统中运行，则必须禁用该子系统。

• AppLocker 仅可以控制 VBScript、JScript、.bat 文件、.cmd 文件以及 Windows PowerShell 脚本。它不会控制运行在主机进程中的所有已解释代码，例如 Perl 脚本和宏。已解释代码是一种运行在主机进程中的可执行代码形式。例如，Windows 批处理文件 (*.bat) 在 Windows 命令主机 (cmd.exe) 的上下文中运行。若要使用 AppLocker 控制已解释代码，则主机进程必须在运行已解释代码之前调用 AppLocker，然后强制执行 AppLocker 返回的决策。并非所有主机进程都会调用 AppLocker。因此，AppLocker 无法控制每一种类型的已解释代码，例如 Microsoft Office 宏。

  要点  

  如果必须允许这些主机进程运行，你应为其配置适合的安全设置。例如，在 Microsoft Office 中配置安全设置，以确保仅加载已签名和受信任的宏。

   

• AppLocker 规则可允许或阻止应用启动。AppLocker 不会控制应用启动之后的行为。应用程序可能包含一些传递到函数的标志，这些标志会向 AppLocker 发出信号来避开这些规则并允许加载另一个 .exe 或 .dll 文件。实际上，AppLocker 所允许的应用可能使用这些标志来绕过 AppLocker 规则并启动子进程。在允许每个应用使用 AppLocker 规则运行之前，必须遵循最适合你的需求的过程以彻底审查它们。

  有关详细信息，请参阅 AppLocker 的安全注意事项。

 

针对 AppLocker 策略设计决策比较经典 Windows 应用程序和通用 Windows 应用。

面向通用 Windows 应用的 AppLocker 策略只能应用于在运行支持 Windows 应用商店应用的 Windows 操作系统的计算机上安装的应用。但是，除了支持通用 Windows 应用的那些计算机以外，经典 Windows 应用程序还可以在 Windows Server 2008 R2 和 Windows 7 中接受控制。经典 Windows 应用程序和通用 Windows 应用的规则可以一起强制执行。对于通用 Windows 应用，应考虑以下不同点：

• 所有通用 Windows 应用都可由标准用户安装，而许多经典 Windows 应用程序需要管理凭据才能安装。因此，在大部分用户都为标准用户的情况下，你可能不需要大量的例外规则，但是你可能需要为封装应用明确制定较多策略。

• 当经典 Windows 应用程序使用管理凭据运行时，可对其进行写入操作以更改系统状态。由于在有限的权限下运行，因此大部分通用 Windows 应用都无法更改系统状态。当你设计自己的 AppLocker 策略时，请务必了解你要允许的应用是否能够进行系统范围的更改。

• 通用 Windows 应用可通过应用商店获取，也可通过使用 Windows PowerShell cmdlet 进行旁加载。如果你使用 Windows PowerShell cmdlet，则需要使用特殊的企业版许可证才能获取通用 Windows 应用。经典 Windows 应用程序可以通过传统方式获取，例如通过软件供应商或零售分销。

AppLocker 使用不同的规则集合控制通用 Windows 应用和经典 Windows 应用程序。你可以选择仅控制通用 Windows 应用、经典 Windows 应用程序，或者两者都控制。

有关详细信息，请参阅 AppLocker 中的封装应用和封装应用安装程序规则。

你当前如何在组织中控制应用使用情况？

大部分的组织在经过一段时间后都已逐步制定出应用控制策略和方法。由于对安全问题的重视，以及对桌面使用施以更为严格的 IT 控制方面的重点关注，你的组织可能会决定巩固应用控制措施或设计一个综合的应用程序控制方案。AppLocker 对体系结构中的 SRP 以及应用程序控制策略的管理进行了改进。

可能的解答	设计注意事项
安全策略（本地进行设置或通过组策略进行设置）	使用 AppLocker 需要增大规划的工作量以创建正确的策略，但这会产生较为简单的分发方法。
非 Microsoft 应用控制软件	使用 AppLocker 需要完整的应用控制策略评估和实现。
按组或 OU 管理使用情况	使用 AppLocker 需要完整的应用控制策略评估和实现。
授权管理器或其他基于角色的访问技术	使用 AppLocker 需要完整的应用控制策略评估和实现。
其他	使用 AppLocker 需要完整的应用控制策略评估和实现。

 

你的组织中运行了哪些 Windows 桌面和服务器操作系统？

如果你的组织支持多个 Windows 操作系统，则应用控制策略规划将会变得更为复杂。你的初始设计决策应考虑安装在每个操作系统版本中的应用程序的安全和管理优先级。

可能的解答	设计注意事项
组织的计算机运行的是以下操作系统的组合： Windows 10 Windows 8 Windows 7 Windows Vista Windows XP Windows Server 2012 Windows Server 2008 R2 Windows Server 2008 Windows Server 2003	AppLocker 规则仅应用于运行受支持的 Windows 版本的计算机，而 SRP 规则可应用于从 Windows XP 和 Windows Server 2003 开始的所有 Windows 版本。有关特定操作系统版本的要求，请参阅使用 AppLocker 的要求。 注意   如果你要使用如 SRP 中所分配的基本用户安全级别，则运行支持 AppLocker 的操作系统的计算机将不支持这些权限。   通过 GPO 应用的 AppLocker 策略优先于相同的或链接的 GPO 中的 SRP 策略。可采用相同的方式创建和维护 SRP 策略。
组织的计算机仅运行以下操作系统： Windows 10 Windows 8.1 Windows 8 Windows 7 Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2	使用 AppLocker 创建你的应用程序控制策略。

 

你的组织中是否具有需要自定义的应用程序控制策略的特定组？

大多数业务组或部门都具有特定的安全要求，这些要求与数据访问权限以及用于访问这些数据的应用程序有关。在为整个组织部署应用程序控制策略之前，应考虑针对每个组的项目范围以及组的优先级。

可能的解答	设计注意事项
是	对于每个组，你需要创建一个包含其应用程序控制要求的列表。尽管这可能会增加规划时间，但非常有可能因此产生更高效的部署。 如果你的 GPO 结构当前尚未配置，因此可以将不同策略应用于特定组，你可以选择将 GPO 中的 AppLocker 规则应用于特定用户组。
否	AppLocker 策略可全局应用于在运行受支持的 Windows 版本（如使用 AppLocker 的要求中所列）的电脑上安装的应用程序。管理所有规则和例外可能富有挑战性，这取决于你需要控制的应用数量。

 

你的 IT 部门是否具有用于分析应用程序使用情况以及设计并管理策略的资源？

可供你进行研究与分析的时间和资源可能会影响针对后续策略管理以及维护的计划和流程细节。

可能的解答	设计注意事项
是	投入一些时间来分析组织的应用程序控制要求，并规划一个完整的部署，使用尽可能简单构造的规则。
否	通过使用少量的规则为特定组考虑进行目标明确的阶段性部署。为特定组中的应用程序应用控制时，从该部署中汲取经验以规划下一个部署。

 

你的组织是否具有技术支持？

阻止你的用户访问已知的、已部署的或个人应用程序最初会导致最终用户支持有所增加。解决组织中的各种支持问题非常有必要，以便安全策略得以遵循并且业务工作流不会因此而受阻。

可能的解答	设计注意事项
是	由于可能会无意中阻止你的用户使用其应用程序，或者他们可能会寻找例外来使用特定应用程序，因此请在计划阶段早期让支持部门参与进来。
否	在进行部署之前，投入一些时间开发联机支持进程和文档。

 

你是否了解哪些应用程序需要限制策略？

任何成功的应用程序控制策略实现都基于你对组织或业务组中的应用使用情况的认识与了解。此外，应用程序控制设计依赖于对数据和访问该数据的应用的安全要求。

可能的解答	设计注意事项
是	你首先应当确定业务组的应用程序控制优先级，然后尝试为他们的应用程序控制策略设计最简单的方案。
否	你将需要执行审核和要求收集项目来了解应用程序使用情况。AppLocker 提供了在“仅审核”模式中部署策略的方法，以及查看事件日志的工具。

 

你如何在组织中部署或认可（已升级或全新的）应用程序？

实现成功的应用程序控制策略基于你对组织或业务组中的应用程序使用情况的认识与了解。此外，应用程序控制设计依赖于对数据和访问该数据的应用程序的安全要求。了解升级和部署策略有助于塑造应用程序控制策略的构造。

可能的解答	设计注意事项
临时	你需要收集来自每个组的要求。有些组可能需要无限制的访问或安装，而其他组可能需要严格的控制。
要遵循的严格书面策略或准则	你需要开发可以反映这些策略的 AppLocker 规则，然后测试并维护这些规则。
无任何过程就位	你需要确定是否具有用于开发应用程序控制策略的资源，以及所针对的组。

 

你的组织是否已部署 SRP？

尽管 SRP 和 AppLocker 具有相同的目标，但 AppLocker 是 SRP 的主要修订版。

可能的解答	设计注意事项
是	你无法使用 AppLocker 来管理 SRP 设置，但你可以使用 SRP 在运行于任何受支持的操作系统（如使用 AppLocker 的要求中所列）中的计算机上管理应用程序控制策略。此外，如果在相同的 GPO 中配置 AppLocker 和 SRP 设置，则运行这些受支持的操作系统的计算机将仅强制执行 AppLocker 设置。 注意   如果你要使用如 SRP 中所分配的基本用户安全级别，则运行受支持的操作系统的计算机将不支持这些权限。
否	为 AppLocker 配置的策略只能应用于运行受支持的操作系统的计算机，但 SRP 也适用于这些操作系统。

 

你的组织实现应用程序控制策略的优先级是什么？

某些组织将会得益于应用程序控制策略（如提高工作效率或一致性所展现），而其他的组织将会在履行其职责时受阻。为每个组的这些方面设置优先级可让你评估 AppLocker 的有效性。

可能的解答	设计注意事项
工作效率：组织将确保工具可正常工作并且所需应用程序可以进行安装。	为了实现创新和工作效率目标，有些组需要能够安装和运行不同来源的各种软件，包括他们开发的软件。因此，如果创新和工作效率具有较高的优先级，则通过允许的列表管理应用程序控制策略可能比较耗时，并且可能阻碍前进。
管理：组织将了解并控制其支持的应用。	在某些业务组中，可以从控件的中心点管理应用程序使用情况。出于此目的，AppLocker 策略可内置于 GPO 中。这会将应用访问权限的任务转移到 IT 部门，不过这也为控制可运行的应用数量以及控制这些应用版本带来便利。
安全：组织必须通过确保仅使用批准的应用以便在一定程度上保护数据。	通过允许一组定义的用户对访问数据的应用进行访问，AppLocker 可以帮助保护该数据。如果安全性具有最高优先级，应用程序控制策略将最具限制性。

 

当前如何在你的组织中访问应用？

对于具有应用程序限制要求的组织而言，如果他们的环境具有简单的拓扑结构并且应用程序控制策略目标非常简单，则 AppLocker 将非常有效。例如，以下环境将受益于 AppLocker：其中非员工有权访问连接到组织网络的计算机（例如学校或图书馆）。当目标是在台式计算机（具有相对少量的应用程序要进行管理）上实现详细级别的控制时，或者当使用少量的规则管理应用程序时，大型组织也会从 AppLocker 策略部署中受益。

可能的解答	设计注意事项
用户运行无需管理权限。 通过使用安装部署技术安装应用。	AppLocker 可以帮助减少业务组的总持有成本，这些组（例如人力资源和财务部分）通常使用一组有限的应用。同时，这些部门会访问高度敏感的信息，其中大部分都包含了机密信息和专有信息。通过使用 AppLocker 为允许运行的特定应用创建规则，你可以帮助防止未经授权的应用程序访问此信息。 注意   AppLocker 也可以有效地帮助在用户以管理员身份运行的组织中创建标准化的桌面。但是，请务必注意拥有管理员凭据的用户可以将新的规则添加到本地 AppLocker 策略。
用户必须能够根据需要安装应用程序。 用户当前拥有管理员访问权限，而且很难对此进行更改。	不适合对必须能够根据需要安装应用的和没有得到 IT 部门批准的业务组强制执行 AppLocker 规则。如果你组织中的一个或多个 OU 有此要求，你可以通过使用 AppLocker 选择不在这些 OU 中强制实施应用程序规则或通过 AppLocker 实现“仅审核”强制设置。

 

Active Directory 域服务中的结构是否基于组织的层次结构之上？

设计基于已内置于 Active Directory 域服务 (AD DS) 的组织结构的应用程序控制策略要比将现有的结构转换为组织结构容易。由于应用程序控制策略的有效性依赖于更新策略的能力，请考虑哪些组织工作需要在部署开始之前完成。

可能的解答	设计注意事项
是	基于 AD DS 结构，可通过组策略开发和实现 AppLocker 规则。
否	IT 部门必须创建一个方案来确定如何将应用程序控制策略应用于正确的用户或计算机。

 

记录你的发现

过程的下一步是记录和分析前面问题的解答。如果 AppLocker 是适合你的目标的解决方案，则可以设置应用程序控制策略目标并规划 AppLocker 规则。此过程在创建规划文档时结束。

• 有关设置策略目标的信息，请参阅确定你的应用程序控制目标。

• 有关创建规划文档的信息，请参阅创建你的 AppLocker 规划文档。