规划 AppLocker 策略管理
本文介绍建立管理和维护 AppLocker 策略的过程时需要做出的决策。
策略管理
在开始部署过程之前,请考虑随时间推移管理 AppLocker 规则。 开发用于管理 AppLocker 规则的流程有助于确保 AppLocker 继续有效地控制允许应用程序在组织中运行的方式。
应用程序和用户支持策略
开发用于管理 AppLocker 规则的流程有助于确保 AppLocker 继续有效地控制允许应用程序在组织中运行的方式。 注意事项包括:
- 为被阻止的应用程序提供哪种类型的最终用户支持?
- 如何将新规则添加到策略?
- 如何更新现有规则?
- 是否转发事件以供审阅?
技术支持支持
如果组织已建立技术支持支持部门,请在部署 AppLocker 策略时考虑以下几点:
- 支持部门需要哪些文档来部署新策略?
- 每个业务组中受应用程序控制策略影响的关键流程是什么?它们如何影响支持部门的工作负荷?
- 谁是支持部门的联系人?
- 如何为最终用户解决应用程序控制问题?
最终用户支持
由于 AppLocker 阻止未经批准的应用运行,因此组织必须仔细规划如何提供最终用户支持。 注意事项包括:
- 是否要使用 Intranet 站点作为对遇到阻止应用的用户的支持第一线?
- 你希望如何支持策略的例外?
使用 Intranet 站点
可以将 AppLocker 配置为显示默认阻止消息,但使用自定义 URL。 可以使用此 URL 将用户重定向到支持站点,该网站包含有关用户收到错误的原因以及允许哪些应用程序的信息。 如果在阻止应用时未显示消息的自定义 URL,则使用默认 URL。
下图显示了被阻止应用的错误消息示例。 可以使用 “设置支持 Web 链接” 策略设置来自定义 “详细信息” 链接。
有关显示消息自定义 URL 的步骤,请参阅 当用户尝试运行被阻止的应用时显示自定义 URL 消息。
AppLocker 事件管理
每次尝试运行进程时,AppLocker 都会在 AppLocker 事件日志中创建一个事件。 该事件包括有关尝试运行的文件、发起该文件的用户以及阻止或允许该文件的 AppLocker 规则 GUID 的信息。 AppLocker 事件日志位于以下路径中: 应用程序和服务日志\Microsoft\Windows\AppLocker。 AppLocker 日志包括三个日志:
- EXE 和 DLL。 包含受可执行文件和 DLL 规则集合影响的所有文件的事件, (.exe、.com、.dll 和 .ocx) 。
- MSI 和脚本。 包含受 Windows Installer 和脚本规则集合影响的所有文件的事件, (.msi、.msp、.ps1、.bat、.cmd、.vbs 和 .js) 。
- 打包的应用部署 或 打包的应用执行包含受打包应用和打包应用安装程序规则集合影响的所有通用 Windows 应用的事件 (.appx) 。
在中心位置收集这些事件有助于维护 AppLocker 策略并排查规则配置问题。
策略维护
部署、更新或停用应用时,需要使策略规则保持最新状态。
可以通过添加、更改或删除规则来编辑 AppLocker 策略。 但是,无法通过导入更多规则来指定策略的版本。 若要确保在修改 AppLocker 策略时进行版本控制,请使用组策略管理软件,以便创建组策略对象的版本 (GPO) 。 此类软件的一个示例是Microsoft桌面优化包中的高级组策略管理功能。 有关详细信息,请参阅高级组策略管理概述。
重要提示
在 组策略 中强制实施 AppLocker 规则集合时,不应对其进行编辑。 由于 AppLocker 控制允许运行的文件,因此对实时策略进行更改可能会造成意外行为。
受支持应用的新版本
在组织中部署应用的新版本时,需要确定是否继续支持该应用的以前版本。 若要添加新版本,可能只需为与应用关联的每个文件创建一个新规则。 如果使用发布者条件并且未指定版本,则现有规则可能足以允许运行更新的文件。 但是,对于更改或添加新文件的文件名,必须检查。 如果是这样,则必须修改现有规则或创建新规则。 对于数字签名发生更改的文件,可能需要更新基于发布者的规则。
若要确定文件在应用更新期间是否更改,请查看随更新包提供的发布者版本详细信息。 还可以查看发布者的网页以检索此信息。 还可以检查每个文件以确定版本。
对于使用文件哈希条件允许或拒绝的文件,必须检索新的文件哈希并确保规则包含该新哈希。
对于具有路径条件的文件,应验证安装路径是否相同。 如果路径已更改,则需要在安装新版本的应用之前为新路径添加规则。
最近部署的应用
若要支持新应用,必须将一个或多个规则添加到现有 AppLocker 策略。
不再支持应用
如果组织不再支持具有关联的 AppLocker 规则的应用程序,则可以删除阻止该应用的规则。
应用已阻止,但应允许
由于以下三个原因,可能会阻止文件:
- 最常见的原因是不存在允许应用运行的规则。
- 可能存在为文件创建限制过大的现有规则。
- 无法重写的拒绝规则正在显式阻止文件。
在编辑规则集合之前,请先确定阻止文件运行的规则。 可以使用 Test-AppLockerPolicy Windows PowerShell cmdlet 来排查此问题。 有关对 AppLocker 策略进行故障排除的详细信息,请参阅 测试和更新 AppLocker 策略。
记录你的发现
若要完成此 AppLocker 规划文档,应首先完成以下步骤:
要确定的 AppLocker 策略管理的三个关键方面是:
支持策略
记录处理尝试运行被阻止应用的用户的呼叫的过程,并确保支持人员知道策略的建议故障排除步骤和升级点。
事件处理
记录收集事件的位置、存档事件的频率以及事件处理方式以供分析。
策略维护
详细说明策略维护和生命周期计划。
下表包含添加的示例数据是在确定如何维护和管理 AppLocker 策略时收集的。
业务组 | 组织单位 | 实现 AppLocker? | 应用 | 安装路径 | 使用默认规则或定义新规则条件 | 允许或拒绝 | GPO 名称 | 支持策略 |
---|---|---|---|---|---|---|---|---|
银行出纳员 | Teller-East 和 Teller-West | 是 | 出纳软件 | C:\Program Files\Woodgrove\Teller.exe | 文件已签名;创建发布者条件 | 允许 | Tellers-AppLockerTellerRules | Web 帮助 |
Windows 文件 | C:\Windows | 创建默认规则的路径例外以排除 \Windows\Temp | 允许 | 服务台 | ||||
人力资源 | HR-All | 是 | 查看付款 | C:\Program Files\Woodgrove\HR\Checkcut.exe | 文件已签名;创建发布者条件 | 允许 | HR-AppLockerHRRules | Web 帮助 |
时间表管理器 | C:\Program Files\Woodgrove\HR\Timesheet.exe | 文件未签名;创建文件哈希条件 | 允许 | Web 帮助 | ||||
Internet Explorer 7 | C:\Program Files\Internet Explorer | 文件已签名;创建发布者条件 | 拒绝 | Web 帮助 | ||||
Windows 文件 | C:\Windows | 对 Windows 路径使用默认规则 | 允许 | 服务台 |
以下两个表演示了记录维护和管理 AppLocker 策略的注意事项的示例。
事件处理策略
应用使用情况的一种发现方法是将 AppLocker 强制模式设置为 “仅审核”。 此强制模式将事件写入 AppLocker 日志,这些日志可以像其他 Windows 日志一样进行管理和分析。 确定应用后,可以开始制定有关处理和访问 AppLocker 事件的策略。
下表是需要考虑和记录的内容的示例。
业务组 | AppLocker 事件集合位置 | 存档策略 | 分析? | 安全策略 |
---|---|---|---|---|
银行出纳员 | 转发到:srvBT093 上的 AppLocker 存储库 | Standard | 无 | Standard |
人力资源 | 请勿转发。 srvHR004 | 60 个月 | 是,每月向经理报告摘要 | Standard |
策略维护策略
开始记录你打算如何更新应用程序控制策略。
下表是需要考虑和记录的内容的示例。
业务组 | 规则更新策略 | 应用程序解除授权策略 | 应用程序版本策略 | 应用程序部署策略 |
---|---|---|---|---|
银行出纳员 | 计划:每月通过业务办公室会审 紧急:通过技术支持请求 |
通过业务办公室会审 需要 30 天通知 |
常规策略:将过去版本保留 12 个月 列出每个应用程序的策略 |
通过业务办公室协调 需要 30 天通知 |
人力资源 | 计划:每月到 HR 会审 紧急:通过技术支持请求 |
通过 HR 会审 需要 30 天通知 |
常规策略:将过去版本保留 60 个月 列出每个应用程序的策略 |
通过 HR 协调 需要 30 天通知 |