了解 AppLocker 策略设计决策
本文介绍在使用 AppLocker 规划应用程序控制策略部署时，AppLocker 设计问题、可能答案和其他注意事项。
开始设计和规划过程时，应考虑设计选择的效果。 生成的决策会影响策略部署方案和后续应用程序控制策略维护。
如果以下所有条件均成立，应考虑将 AppLocker 用作组织的应用程序控制策略的一部分：
- 你正在运行组织中受支持的 Windows 版本。 有关特定的操作系统版本要求，请参阅 使用 AppLocker 的要求。
- 需要改进对组织应用程序的访问的控制。
- 组织中应用程序的数量已知且可管理。
- 你有资源来根据组织的要求测试策略。
- 你有资源来让技术支持参与，或者为最终用户应用程序访问问题构建自助流程。
以下是在部署应用程序控制策略时应考虑的一些问题， (适合目标环境) 。
你需要在组织中控制哪些应用？
你可能需要控制有限数量的应用程序，因为它们访问敏感数据，或者你只想允许批准用于业务用途的应用。 可能有某些业务组需要严格控制，而另一些业务组则促进独立应用程序使用。
| 可能的答案 | 设计注意事项 |
|---|---|
| 控制所有应用 | AppLocker 策略通过按文件类型创建允许的应用程序列表来控制应用程序。 也可能有异常。 AppLocker 策略只能应用于运行其中一个受支持的 Windows 版本的计算机上安装的应用程序。 |
| 控制特定应用 | 创建 AppLocker 规则时，将创建允许的应用列表。 允许该列表上的所有应用程序运行 (例外列表) 上的应用程序除外。 列表中未显示的应用程序被阻止运行。 AppLocker 策略只能应用于在运行任何受支持的 Windows 版本的计算机上安装的应用。 |
| 仅控制经典 Windows 应用程序，仅控制打包应用，或同时控制两者 | AppLocker 策略通过按文件类型创建允许的应用列表来控制应用。 由于打包的应用按发布服务器条件分类，因此经典 Windows 应用程序和打包的应用可以一起控制。 当前对经典 Windows 应用程序的规则可以保留，并且可以为打包应用创建新的规则。 有关经典 Windows 应用程序和打包应用的比较，请参阅本文中的 比较经典 Windows 应用程序和适用于 AppLocker 的打包应用策略设计决策 。 |
| 按业务组和用户控制应用 | AppLocker 策略可以通过组策略对象 (GPO) 应用于组织单位中的计算机对象 (OU) 。 单个 AppLocker 规则可以应用于单个用户或用户组。 |
| 按计算机而不是用户控制应用 | AppLocker 是基于计算机的策略实现。 如果域或站点组织结构不基于逻辑用户结构（如 OU），则可能需要在开始 AppLocker 规划之前设置该结构。 否则，必须确定用户、其计算机及其应用访问要求。 |
| 了解应用使用情况，但无需控制任何应用 | 可以将 AppLocker 策略设置为审核应用使用情况，以帮助跟踪组织中使用了哪些应用。 然后，可以使用 AppLocker 事件日志创建 AppLocker 策略。 |
注意
AppLocker 规则允许或阻止应用或二进制文件启动。 AppLocker 不会控制应用在启动后的行为。 有关详细信息，请参阅 AppLocker 的安全注意事项。
比较经典 Windows 应用程序和适用于 AppLocker 策略设计决策的打包应用
打包应用的 AppLocker 策略只能应用于在运行支持 Microsoft 应用商店应用的 Windows 操作系统的计算机上安装的应用。 但是，除了支持打包应用的计算机外，经典 Windows 应用程序还可以在 Windows Server 2008 R2 和 Windows 7 中控制。 经典 Windows 应用程序和打包应用的规则可以一起强制执行。 对于打包应用，应考虑的区别包括：
- Standard用户可以安装打包的应用，而许多经典 Windows 应用程序需要管理凭据才能安装。 因此，在大多数用户都是标准用户的环境中，你可能不需要大量的 exe 规则，但你可能希望对打包的应用使用更明确的策略。
- 如果经典 Windows 应用程序使用管理凭据运行，则可以编写这些应用程序来更改系统状态。 大多数打包的应用无法更改系统状态，因为它们以有限的权限运行。 设计 AppLocker 策略时，请务必了解所允许的应用是否可以进行系统范围的更改。
- 可以通过应用商店获取打包的应用，也可以使用 Windows PowerShell cmdlet 进行旁加载。 如果使用 Windows PowerShell cmdlet，则需要特殊的企业许可证才能获取打包的应用。 经典 Windows 应用程序可以通过传统方式获取，例如通过软件供应商或零售分发。
AppLocker 使用不同的规则集合控制打包的应用和经典 Windows 应用程序。 可以选择控制打包的应用和/或经典 Windows 应用程序。
有关详细信息，请参阅 AppLocker 中的打包应用和打包的应用安装程序规则。
使用 AppLocker 控制脚本
AppLocker 脚本强制实施涉及启发式脚本主机（如 PowerShell）和 AppLocker 之间的握手。 但是，脚本主机会处理实际强制行为。 大多数脚本主机首先询问 AppLocker 是否应根据当前处于活动状态的 AppLocker 策略来运行脚本。 然后，脚本主机会阻止、允许或更改脚本的运行 方式 ，以最好地保护用户和设备。
AppLocker 对所有脚本强制事件使用 AppLocker - MSI 和脚本 事件日志。 每当脚本主机询问 AppLocker 是否应允许脚本时，都会记录事件，其中包含返回给脚本主机的 AppLocker 答案。
注意
当策略不允许的脚本运行时，AppLocker 会引发一个事件，指示脚本已被“阻止”。但是，实际的脚本强制行为由脚本主机处理，实际上可能不会完全阻止文件运行。
AppLocker 脚本强制实施只能控制 VBScript、JScript、.bat 文件、.cmd文件和Windows PowerShell脚本。 它不会控制在主机进程中运行的所有解释代码，例如 Perl 脚本和宏。 解释代码是在主机进程中运行的可执行代码的一种形式。 例如，Windows 批处理文件 (*.bat) 在 Windows 命令主机 (cmd.exe) 的上下文中运行。 若要使用 AppLocker 控制解释代码，主机进程必须在运行解释代码之前调用 AppLocker，然后强制执行 AppLocker 的决策。 并非所有主机进程都会调用 AppLocker。 因此，AppLocker 无法控制任何类型的解释代码，例如Microsoft Office 宏。
重要提示
如果必须允许这些主机进程运行，则应配置相应的安全设置。 例如，在 Microsoft Office 中配置安全设置，以确保仅加载已签名和受信任的宏。
当前如何控制组织中的应用使用情况？
大多数组织会随着时间的推移而改进其应用控制策略和方法。 AppLocker 在管理良好的应用程序部署和审批流程的组织中是最佳选择。
| 可能的答案 | 设计注意事项 |
|---|---|
| (本地设置或通过组策略) 设置的安全策略 | 使用 AppLocker 需要加大规划创建正确策略的工作量，但此策略创建会产生更简单的分发方法。 |
| 非Microsoft应用控制软件 | 使用 AppLocker 需要完整的应用控制策略评估和实现。 |
| 按组或 OU 的托管使用情况 | 使用 AppLocker 需要完整的应用控制策略评估和实现。 |
| 授权管理器或其他基于角色的访问技术 | 使用 AppLocker 需要完整的应用控制策略评估和实现。 |
| Other | 使用 AppLocker 需要完整的应用控制策略评估和实现。 |
组织中是否有需要自定义应用程序控制策略的特定组？
大多数业务组或部门都有与数据访问和用于访问该数据的应用程序相关的特定安全要求。 在为整个组织部署应用程序控制策略之前，应考虑每个组的项目范围和组的优先级。
| 可能的答案 | 设计注意事项 |
|---|---|
| 是 | 对于每个组，需要创建一个包含其应用程序控制要求的列表。 尽管此注意事项可能会增加规划时间，但通常会使部署更加有效。 如果 GPO 结构与组织组不匹配，则可以将 AppLocker 规则应用于特定用户组。 |
| 否 | AppLocker 策略可以全局应用于已安装的应用程序。 根据需要控制的应用数量，管理所有规则和例外可能具有挑战性。 |
IT 部门是否具有资源来分析应用程序使用情况以及设计和管理策略？
可用于执行研究和分析的时间和资源可能会影响计划的详细信息和流程，以便持续策略管理和维护。
| 可能的答案 | 设计注意事项 |
|---|---|
| 是 | 投入时间分析组织的应用程序控制要求，并规划使用尽可能构建的规则的完整部署。 |
| 否 | 使用一些规则，考虑针对特定组进行重点分阶段部署。 将控件应用于特定组中的应用程序时，请从该部署中学习，以规划下一个部署。 |
你的组织是否具有技术支持支持？
阻止用户访问应用程序时，至少最初会导致最终用户支持增加。 必须解决组织中的各种支持问题，以便遵循安全策略，并且不会妨碍业务工作流。
| 可能的答案 | 设计注意事项 |
|---|---|
| 是 | 在规划阶段的早期让支持部门参与进来，因为用户可能会被阻止使用其应用程序，或者他们可能会寻求例外来使用特定应用程序。 |
| 否 | 在部署之前投入时间开发联机支持流程和文档。 |
你知道哪些应用程序需要限制性策略吗？
任何成功的应用程序控制策略实现都基于你对组织或业务组中应用使用情况的了解和理解。 此外，应用程序控制设计还取决于数据的安全要求以及访问该数据的应用。
| 可能的答案 | 设计注意事项 |
|---|---|
| 是 | 应确定业务组的应用程序控制优先级，然后尝试为其应用程序控制策略设计最简单的方案。 |
| 否 | 必须执行审核和要求收集项目才能发现应用程序使用情况。 AppLocker 提供在 “仅审核 ”模式下部署策略的方法，以及用于查看事件日志的工具。 |
如何在组织中部署或批准 (升级或新) 的应用程序？
成功实施应用程序控制策略取决于你对组织或业务组中应用程序使用情况的了解和理解。 此外，应用程序控制设计取决于数据的安全要求以及访问该数据的应用程序。 了解升级和部署策略有助于构建应用程序控制策略。
| 可能的答案 | 设计注意事项 |
|---|---|
| 意外 | 需要从每个组收集要求。 某些组可能需要不受限制的访问或安装，而其他组可能需要严格的控制。 |
| 要遵循的严格书面策略或指南 | 你需要开发反映这些策略的 AppLocker 规则，然后测试和维护这些规则。 |
| 无进程到位 | 需要确定是否有资源来开发应用程序控制策略，以及针对哪些组。 |
实施应用程序控制策略时，组织的优先级是什么？
一些组织受益于应用程序控制策略，例如生产力或一致性的提高，而另一些组织在履行职责时受到阻碍。 为每个组确定这些方面的优先级，以便评估 AppLocker 的有效性。
| 可能的答案 | 设计注意事项 |
|---|---|
| 工作效率：组织确保工具正常工作，并且可以安装所需的应用程序。 | 为了实现创新和生产力目标，某些群体需要能够安装和运行来自不同源的各种软件，包括他们开发的软件。 因此，如果创新和生产力是重中之重，则通过允许列表管理应用程序控制策略可能非常耗时，并阻碍进度。 |
| 管理：组织了解并控制它支持的应用程序。 | 在某些业务组中，可以从中心控制点管理应用程序使用情况。 AppLocker 策略可以内置到 GPO 中以实现此目的。 |
| 安全性：组织必须通过确保仅使用已批准的应用来部分保护数据。 | AppLocker 可以通过允许一组定义的用户访问数据的应用来帮助保护数据。 如果安全性是重中之重，应用程序控制策略可能会更加严格。 |
当前如何在组织中访问应用？
AppLocker 对于具有管理良好应用程序管理且应用程序控制策略目标简单的组织有效。 例如，AppLocker 可以有利于一个环境，在该环境中，无一人有权访问连接到组织网络的计算机，例如学校或图书馆。
| 可能的答案 | 设计注意事项 |
|---|---|
| 用户无需管理权限即可运行。 | 使用安装部署技术安装应用。 |
| AppLocker 可帮助降低通常使用有限应用集的业务组（例如人力资源和财务部门）的总拥有成本。 同时，这些部门访问高度敏感的信息，其中大部分包含机密和专有信息。 通过使用 AppLocker 为允许运行的特定应用创建规则，可以帮助限制未经授权的应用程序访问此信息。 注意： AppLocker 还可以有效地帮助在用户以管理员身份运行的组织中创建标准化桌面。 但是，请务必注意，具有管理凭据的用户可将新规则添加到本地 AppLocker 策略。 |
用户必须能够根据需要安装应用程序。 |
| 用户当前具有管理员访问权限，因此很难更改此权限。 | 强制执行 AppLocker 规则不适用于必须能够根据需要安装应用且未经 IT 部门批准的业务组。 如果组织中的一个或多个 OU 具有此要求，则可以选择不使用 AppLocker 在这些 OU 中强制实施应用程序规则，或者通过 AppLocker 实现 “仅审核” 强制设置。 |
Active Directory 域服务中的结构是否基于组织的层次结构？
基于已内置于 Active Directory 域服务 (AD DS) 中的组织结构设计应用程序控制策略比将现有结构转换为组织结构更容易。 由于应用程序控制策略的有效性取决于更新策略的能力，因此请考虑在部署开始之前需要完成的组织工作。
| 可能的答案 | 设计注意事项 |
|---|---|
| 是 | 可以根据 AD DS 结构通过组策略开发和实现 AppLocker 规则。 |
| 否 | IT 部门必须创建一个方案，以确定如何将应用程序控制策略应用于正确的用户或计算机。 |
记录你的发现
此过程的下一步是记录和分析上述问题的答案。 如果 AppLocker 是实现目标的正确解决方案，则可以设置应用程序控制策略目标并规划 AppLocker 规则。 此过程最终会创建规划文档。