通过

规划 AppLocker 策略管理

  • 项目

本主题介绍建立用于管理和维护 AppLocker 策略的过程需要做出的决策。

策略管理

在开始部署过程前，请考虑如何管理 AppLocker 规则。开发管理 AppLocker 规则的过程有助于确保 AppLocker 继续有效控制允许应用程序在组织中运行的方式。

应用程序和用户支持策略

开发管理 AppLocker 规则的过程有助于确保 AppLocker 继续有效控制允许应用程序在组织中运行的方式。注意事项包括：

  • 为阻止的应用程序提供哪种类型的最终用户支持？

  • 如何将新规则添加到策略？

  • 如何更新现有规则？

  • 是否转发事件以供查看？

技术人员支持

如果你的组织已就地建立了技术人员支持部门，请在部署 AppLocker 策略时考虑以下内容：

  • 支持部门需要哪些针对新策略部署的文档？

  • 在应用程序控制策略影响的工作流和计时中，每个业务组中有哪些关键过程，并且它们如何影响支持部门的工作负载？

  • 支持部门中的联系人员是谁？

  • 支持部门将如何解决最终用户与 AppLocker 规则维护人员之间的应用程序控制问题？

最终用户支持

由于 AppLocker 会阻止未经批准的应用运行，你的组织务必要仔细规划如何提供最终用户支持。注意事项包括：

  • 针对尝试运行阻止的应用的用户，你是否想要将 Intranet 站点作为首要支持？

  • 你想要如何支持策略的例外？你是否允许用户运行脚本以暂时允许访问阻止的应用？

使用 Intranet 站点

AppLocker 可配置为显示默认消息，但使用自定义 URL。你可以使用此 URL 将用户重定向至某个支持站点，该站点包含有关用户接收到错误消息的原因以及允许使用哪些应用程序的信息。如果在阻止应用时没有为消息显示自定义 URL，则使用默认 URL。

下图显示了阻止的应用的错误消息示例。你可以使用“设置支持 Web 链接”策略设置自定义“详细信息”****链接。

AppLocker 阻止的应用程序错误消息

有关为消息显示自定义 URL 的步骤，请参阅当用户尝试运行阻止的应用时显示自定义 URL 消息。

AppLocker 事件管理

每当进程请求运行权限时，AppLocker 都会在 AppLocker 事件日志中创建事件。该事件将详细介绍尝试运行的文件、该文件的属性、发起请求的用户以及用于做出 AppLocker 执行决策的规则 GUID。AppLocker 事件日志位于以下路径中：Applications and Services Logs\Microsoft\Windows\AppLocker。AppLocker 日志包括三份日志：

  1. EXE 和 DLL。包含受可执行文件和 DLL 规则集合（.exe、.com、.dll 和 .ocx）影响的所有文件事件。

  2. MSI 和脚本。包含受 Windows Installer 和脚本规则集合（.msi、.msp、.ps1、.bat、.cmd、.vbs 和 .js）影响的所有文件事件。

  3. 封装应用部署或封装应用执行，包含受封装应用和封装应用安装程序规则集合 (.appx) 影响的所有通用 Windows 应用事件。

在某个中心位置收集这些事件可有助于维护 AppLocker 策略并针对规则配置问题进行故障排除。事件收集技术（例如在 Windows 中提供的技术）允许管理员订阅特定事件频道，并使源计算机事件聚合到 Windows Server 操作系统收集器上转发的事件日志中。有关设置事件订阅的详细信息，请参阅为计算机配置收集和转发事件。

策略维护

在软件发布者部署新应用或更新现有应用时，你将需要修订规则集合以确保策略保持当前状态。

你可以通过添加、更改或删除规则来编辑 AppLocker 策略。但是，你无法通过导入其他规则来指定策略版本。若要在修改 AppLocker 策略时确保版本控制，请使用允许你创建组策略对象 (GPO) 版本的组策略管理软件。此类软件的示例是 Microsoft Desktop Optimization Pack 的高级组策略管理功能。有关高级组策略管理的详细信息，请参阅高级组策略管理概述 (https://go.microsoft.com/fwlink/?LinkId=145013)。

小心  

在组策略中强制执行 AppLocker 规则集合时，你不应对其进行编辑。由于 AppLocker 控制允许运行的文件，对实时策略进行更改可能会导致意外行为。

 

受支持的新版应用

在组织中部署新版本的应用时，你需要确定是否继续支持以前版本的应用。若要添加新版本，你可能只需要为每一个与应用关联的文件创建新规则。如果你使用的是发布者条件并且未指定版本，则现有规则可能足以允许更新的文件运行。但必须确保更新的应用未更改文件名或添加支持新功能的文件。如果不是这样，则必须修改现有规则或创建新规则。若要继续重复使用缺少特定文件版本的基于发布者的规则，你还必须确保文件的数字签名与之前的版本仍保持一致，即发布者、产品名和文件名（如规则中已配置）必须全部匹配才能正确应用规则。

若要确定文件是否已在应用更新期间进行修改，请查看更新程序包随附的发布者版本详细信息。你还可以查看发布者的 Web 页面以检索此信息。还可以检查每个文件以确定版本。

对于文件哈希条件允许或拒绝的文件，必须检索新文件哈希。若要添加对新版本的支持并维持对旧版本的支持，你可以创建用于新版本的新文件哈希规则，或编辑现有规则并将新文件哈希添加到条件列表。

对于具有路径条件的文件，应验证安装路径是否与规则中所述内容保持一致。如果路径已更改，你需要在安装新版本的应用之前更新规则。

最近部署的应用

若要支持新应用，必须向现有 AppLocker 策略添加一个或多个规则。

不再支持应用

如果你的组织已确定不再支持与 AppLocker 规则关联的应用程序，则阻止用户运行该应用的最简单方法就是删除这些规则。

应用已阻止，但应允许运行

文件可能由于以下三个原因而被阻止：

  • 最常见的原因是不存在允许应用运行的规则。

  • 为文件创建的现有规则过于严格。

  • 无法重写的拒绝规则显式阻止文件。

在编辑规则集合前，请首先确定阻止文件运行的规则。你可以使用 Test-AppLockerPolicy Windows PowerShell cmdlet 解决此问题。有关针对 AppLocker 策略进行故障排除的详细信息，请参阅测试和更新 AppLocker 策略 (https://go.microsoft.com/fwlink/?LinkId=160269)。

后续步骤

在决定你的组织将如何管理 AppLocker 策略后，请记录你的调查结果。

  • **最终用户支持策略。**记录用于处理尝试运行阻止的应用的用户呼叫的过程，并确保支持人员具有清晰的升级步骤以便管理员在必要时可以更新 AppLocker 策略。

  • **事件处理。**记录事件是否会收集在名为存储的中心位置、该存储将如何存档，以及事件是否会进行处理以供分析。

  • **策略维护。**详细介绍如何将规则添加到策略以及在哪个 GPO 中定义规则。

有关如何记录过程的信息和步骤，请参阅记录你的应用程序控制管理过程。