Applocker

定义

AppLocker 是 Windows 中用于应用程序控制的执行控制机制，管理员可以用一组允许或拒绝规则，决定特定用户、用户组能在受支持的 Windows 设备上启动哪些代码。它管理的对象按规则集合分为可执行文件、脚本、Windows 安装程序文件、动态链接库（DLL）、打包应用以及打包应用安装程序。

该功能自身不区分是否放行，判断依据由规则条件给出：代码签名证书对应的发布者、签名元数据中的原始文件名与版本、文件哈希，以及文件在磁盘或网络上的路径。未命中任何允许规则的代码会被拒绝运行，因此策略通常以白名单方式组织^[1]。

原理

AppLocker 依赖 Application Identity 服务（AppIDSvc）与内核模式驱动 AppId.sys 完成判定。服务监视规则所在的注册表位置，规则变化后由用户模式任务把 XML 描述的策略转换为二进制访问控制项与安全描述符，再写入注册表，供用户态与内核态组件共同读取^[2]。服务停止运行时，规则不会被评估，策略也就不再生效^[3]。

驱动注册进程创建回调，在进程真正建立前取得其标识属性，写入进程访问令牌，再调用访问检查例程与规则中的条件式访问控制项比对；判定不通过时，内核直接把创建操作置为失败，形成可见的阻止行为^[2]。DLL 的检查发生在映像加载阶段，需要对每个加载的模块逐一校验，开销较大，因此 DLL 规则集合默认不启用^[2]。

脚本的强制执行方式与可执行文件不同。脚本主机在运行脚本前向 AppLocker 询问策略结果，再由主机决定放行、拦截或改变运行方式，所以脚本控制实际取决于 PowerShell 等主机的行为^[1]。

flowchart LR

A[管理员写入规则 XML] --> B[Application Identity 服务]

B --> C[转换为 ACE 与 SDDL]

C --> D[注册表策略存储]

D --> E[AppId 内核驱动]

E --> F{进程或 DLL 发起加载}

F --> G[访问检查]

G -->|命中允许规则| H[放行]

G -->|未命中或被拒绝| I[阻止启动]

发展历程

AppLocker 随 Windows 7 与 Windows Server 2008 R2 一同出现，用于取代更早的软件限制策略，并提供规则集合、仅审核模式、策略导入导出和 PowerShell 管理方式^[4]。在最初的版本中，策略只能在 Windows 7 旗舰版、企业版以及 Windows Server 2008 R2 的各版本上强制执行；专业版可以创建规则，但规则不会在该版本上生效^[5]。

此后支持范围随 Windows 版本扩展。Windows 8 与 Windows Server 2012 被纳入可用平台列表，Windows 10、Windows 11 与 Windows Server 2016 及更高版本还增加了打包应用与打包应用安装程序两类规则集合^[5]。

版本限制在较晚的更新中被解除。自知识库更新 KB 5024351 起，Windows 10 版本 2004 及更新版本与所有 Windows 11 版本在强制执行 AppLocker 策略时不再要求特定版本；更早的系统仍保留旧规则，通过组策略分发时仅限企业版与服务器版，通过移动设备管理分发则不受版本限制。

应用

在企业终端管理中，AppLocker 常被用于实现软件标准化，只允许受支持的应用程序在业务组计算机上运行；也用于许可合规，阻止未授权软件启动并把已授权软件限定给指定用户。当某个应用不再受支持、许可证被吊销或过期，或新版本部署后需要停用旧版本时，同样可以用规则统一拦截。

共享计算机场景是它的另一处用途。策略既能作用于整台计算机，也能只作用于特定用户或用户组，因此可以为同一台设备上的不同使用者配置不同的软件集合。部署时通常先在仅审核模式下运行，收集事件日志了解实际会被拦截的对象，再切换到强制执行。

策略的编写与下发方式包括本地安全策略编辑器、组策略管理控制台以及移动设备管理通道，规则还可先用 PowerShell 命令批量生成、测试与合并。适用企业的应用控制的部分功能也复用 AppLocker 的规则机制，例如托管安装程序。

审计与排查依赖事件日志。仅审核模式下的预期拦截记录在事件 8003 一类条目中，强制执行后的实际拦截则记录在事件 8004 一类条目中，管理员据此核对哪条规则生效或缺失。

局限

微软把 AppLocker 定位为纵深防御措施，而非可独立依靠的 Windows 安全功能，理由是其存在设计上的边界，无法单独抵御针对性威胁；需要更强防护时应改用适用于企业的应用控制。该功能的官方说明也提到它不再获得新功能改进，只继续接收安全修补程序。

规则只管启动环节。AppLocker 决定某个应用或二进制文件能否启动，但不约束其启动后的行为，因此已放行的程序在运行中做什么并不在控制范围内^[1]。默认情况下，策略仅适用于在用户上下文启动的代码，非用户进程需要额外的规则集合扩展才能覆盖。

按路径建立的规则存在先天弱点：若允许范围的目录对普通用户可写，用户就能把文件放入其中绕过限制；本地管理员账户默认也不受规则约束，完全强制需借助其他机制^[3]。脚本控制的效果取决于脚本主机的配合，运行方式可能被改变而非直接终止^[1]。

启用 DLL 规则会带来明显的性能负担，因为每个模块加载都要经过策略检查；此外，承载脚本与安装程序日志的日志通道在某些服务器核心安装版本上并不存在，审计信息可能缺失^[2]。

参见

• 软件限制策略 —— AppLocker 所取代的早期 Windows 应用程序控制机制。

• 组策略 —— 部署与下发 AppLocker 策略的主要管理框架。

• Windows Defender 应用程序控制 —— 微软推荐优先使用的整机级应用控制技术。

• 用户账户控制 —— 与 AppLocker 配合区分用户权限上下文的安全机制。

• PowerShell —— 可批量创建、测试与合并 AppLocker 规则的脚本环境，也是受脚本规则约束的脚本主机。