概述
1.1 为什么需要AppLocker
在企业域管理环境中，用户自行安装未经授权的软件、运行来源不明的可执行文件，是IT管理面临的最常见风险之一。这类行为不仅可能引入恶意软件和安全漏洞，还会导致软件环境混乱、合规性失控以及技术支持成本上升。
AppLocker（应用程序控制策略）是微软自Windows 7起引入的内置企业级安全功能，它通过组策略（Group Policy）实现对企业环境中程序、脚本及安装文件执行权限的集中管理。与传统的软件限制策略（SRP）相比，AppLocker在可管理性上有显著提升——支持策略导入导出、自动生成规则、仅审核模式部署以及Windows PowerShell cmdlet等现代化管理能力。
AppLocker的核心价值在于：它不是一个仅仅阻止“坏软件”的工具，而是一个只允许“好软件”运行的白名单机制。通过AppLocker，可以有效地防止最终用户在其计算机上运行未经批准的软件。
1.2 系统要求与版本支持
AppLocker策略仅能在Windows操作系统的受支持版本上配置并应用。最初AppLocker仅适用于Windows企业版和旗舰版，但从Windows 10版本2004以及所有Windows 11版本开始，版本限制被移除，Pro版本同样可以应用AppLocker策略。
在域环境下部署时，目标客户端需加入域，并启用Application Identity服务（启动类型设为“自动”且保持运行中）。策略必须发布到“计算机配置”分支，而非“用户配置”分支。
1.3 使用AppLocker可以做什么
通过AppLocker，可以实现以下应用场景：
- 基于多种条件定义规则：根据发布者信息（从数字签名中获得）、文件路径或文件哈希值来定义允许或拒绝的规则。
- 差异化权限分配：向不同的安全组或单个用户分配不同的规则，实现精细化的应用控制。
- 支持例外规则：为规则创建例外。例如，允许所有用户运行除注册表编辑器之外的所有Windows二进制文件。
- 逐步部署策略：使用“仅审核”模式先行部署，在事件日志中观察效果，确认无误后再正式强制执行。
- 跨环境策略迁移：在测试环境中创建规则，导出为XML文件，再导入到生产环境的组策略对象中。
二、AppLocker工作原理与技术架构
2.1 核心架构
AppLocker策略通过组策略进行维护和分发，只有GPO的管理员可以更新该策略。在底层，AppLocker依赖内核驱动appid.sys实现进程创建的实时拦截，属于“白名单+黑名单”结合的应用管控方案。
组策略不会覆盖或替换链接的GPO中已存在的规则，而是将所有策略中的规则合并起来，形成有效的规则集合。
2.2 规则集合类型
AppLocker策略组织在五个规则集合中，每个集合对应不同类型的文件：
| 规则集合 | 关联的文件格式 | 适用场景 |
|---|---|---|
| 可执行文件 | .exe、.com（以及所有可移植可执行文件PE） | 控制主程序运行 |
| 脚本 | .ps1、.bat、.cmd、.vbs、.js | 控制脚本执行权限 |
| Windows Installer | .msi、.msp、.mst | 控制软件安装和更新 |
| 打包应用 | .appx、.msix | 控制Microsoft Store应用 |
| DLL文件 | .dll、.ocx | 控制动态链接库（默认不启用） |
特别说明：
如果启用DLL规则，必须为所有允许的应用所使用的每个DLL创建允许规则，否则可能导致应用无法正常运行。同时，启用DLL规则后AppLocker会检查应用程序加载的每个DLL，可能带来一定的性能影响，但在正常配置下通常难以察觉。
2.3 规则条件类型
AppLocker提供三种规则条件，各有优劣与适用场景：
发布者条件：基于文件的数字签名信息（发布者、产品名称、文件名和版本等）来标识应用。这是最推荐的方式，因为它在应用程序更新时通常无需修改规则（只要发布者不变），比哈希条件更易维护，比路径条件更安全。发布者条件的先决条件是文件必须经过数字签名。
路径条件：基于文件在文件系统或网络上的位置来标识应用。配置简单直观，但存在安全风险——如果用户可以写入受信任路径（如Temp文件夹），就可能绕过限制。路径规则生效时，该规则会应用于指定路径及其所有子目录（除非明确免除）。
文件哈希条件：基于文件的加密哈希值来唯一标识。这种方式最精确，但每次文件版本更新时哈希值都会改变，规则必须同步更新，维护成本最高，仅适用于静态的、极少更新的文件。
2.4 规则处理优先级
当规则集合中存在多个规则时，AppLocker按以下顺序处理：
- 显式拒绝：管理员明确创建了拒绝文件的规则，优先级最高。
- 显式允许：管理员明确创建了允许文件的规则。
- 隐式拒绝：如果文件没有被任何允许规则覆盖，则被阻止运行。
这意味着AppLocker本质上是一个白名单系统——只允许显式批准的应用程序运行，其他一切都会被拒绝。
三、通过GPO部署AppLocker策略
3.1 使用GPO统一启用Application Identity服务
AppLocker依赖Application Identity服务（AppIDSvc）来验证应用程序。该服务在Windows默认安装中通常设置为“手动”启动，需要将其改为“自动”。
配置路径为：计算机配置 → 策略 → Windows设置 → 安全设置 → 系统服务 → Application Identity，将启动类型设置为“自动”。
3.2 创建默认规则
在组策略管理编辑器中，依次展开：
计算机配置 → 策略 → Windows设置 → 安全设置 → 应用程序控制策略 → AppLocker
需要为每个规则集合生成默认规则是最佳的起点。右键点击任意规则集合（如“可执行规则”），选择“创建默认规则。
可执行规则
默认规则主要包含以下三条：
- 允许Everyone组运行Program Files文件夹中的应用程序
- 允许Everyone组运行Windows文件夹中的应用程序
- 允许本地管理员组成员运行所有应用程序
这些默认规则旨在确保Windows系统文件以及Program Files目录下的程序能够正常运行，作为初学者的起始策略。但在生产环境中，应根据实际安全需求进行审查和调整，因为Windows文件夹中的Temp子目录可能被普通用户利用来执行非授权程序。
Windows 安装程序规则
脚本规则
封装应用规则
3.3 客户端策略确认
执行gpupdate /force命令，同步GPO
服务正常执行。
策略正常应用。
执行未包含在内的应用软件时，会提示已经拒绝访问。
3.4 创建自定义规则
在默认规则的基础上，可以创建自定义规则来满足特定的业务需求。创建规则时通常需要决定以下参数：
- 允许还是拒绝：决定该规则是允许还是阻止文件运行。
- 适用的用户或组：可以选择应用到特定AD用户或安全组（如“Everyone”“Domain Users”等），实现差异化控制。
- 规则条件：从发布者、路径或文件哈希中选择一种。
- 规则的具体值：根据所选条件类型填写对应的发布者信息、路径或文件哈希值。
当需要允许非管理员用户运行特定应用程序时，为可执行文件添加发布者条件的允许规则是最佳实践。
3.4.1 根据发布者允许规则
当软件有发布者时，优先使用发布者规则是为最佳实践。
如下图所示：
3.4.1.1 根据文件版本进行限制
3.4.1.2 客户端验证
客户端准备了同一个发布者发布的两个程序包，更新GPO后，13.2.0版本可以正常打开，而12.15.0版本是无法打开的。
3.4.1.3 思考
如果将文件版本设置为一个低版本，是否可以打开所有的高版本文件？
结论是当然可以！！
3.4.2 根据文件哈希设置规则
并不是所有的软件都有会发布者，退而求其次的选择那就是哈希规则了。
此处可以选择单个文件，也可以选择一个文件夹。
3.4.3 根据文件路径设置规则
最后的最后，哈希规则只能针对不会更新，不会改变的程序设置。而针对经常更新的，但是安装路径相对固定的程序，可以采用文件路径设置规则。设置此规则。
四、场景分析
4.1 黑名单模式
因为默认情况下是白名单的模式，而有时我们会因为已存在软件安装的杂乱性，导致无法规划性的梳理。此时就可以通过曲线救国的方式，设置一个近似黑名单的模式。
通过路径方式，将所有的路径进行放行，然后再建立相应的拒绝规则。
具体如下所示：
创建拒绝的发布者规则
4.2 多规则并行
在步骤三中，只是使用安装程序进行示例。而当软件安装在非标准安装路径后，打开软件运行时，会出现软件调用非发布者程序时，无法打开，导致程序无法正常运行。此时就需要使用哈希规则、或者路径规则进行排除。从而保障软件的正常运行，具体只能根据自己的实际情况进行调整优化了。
五、结语
规则是死的，人是活的。
评论区