applocker白名单需域环境支撑，要求终端加域、启用application identity服务、策略置于计算机配置路径；默认规则起步，优先发布者规则，分三阶段灰度上线。

在域环境中强制推行applocker软件白名单，本质是通过组策略集中下发、application identity服务强制执行、分阶段验证落地的一整套管控流程。它不是简单配几条规则就生效，而是依赖域架构的底层支撑和严谨的运维节奏。

必须满足的域环境基础条件

AppLocker无法在工作组或本地策略中真正生效。以下三项缺一不可：

• 所有目标终端（Windows 10 1607+/Windows 11/Server 2012+）必须已加入域，且运行版本为专业版、企业版或教育版
• 域内所有客户端需启用并运行Application Identity服务（启动类型设为“自动”，状态为“正在运行”）
• 策略必须配置在计算机配置 → 策略 → Windows 设置 → 安全设置 → 应用程序控制策略 → AppLocker路径下，不能放在用户配置分支

从默认规则起步，构建可信基线

手动逐条写规则极易遗漏系统关键路径。推荐直接启用官方默认规则作为起点：

• 在“可执行规则”节点右键 → “创建默认规则”，自动生成三条发布者规则：放行%WINDIR%\*、%PROGRAMFILES%\*、%PROGRAMFILES(X86)%\*下由可信签名签发的程序
• 同样为“Windows Installer规则”“脚本规则”“DLL规则”分别创建默认规则（注意：DLL规则默认禁用，需手动勾选“已配置”）
• 检查生成规则是否覆盖你的真实环境——比如内部软件装在C:\Apps\，就得额外添加对应路径或发布者规则

优先使用发布者规则，谨慎补充路径与哈希

规则类型决定长期可维护性：

• 发布者规则最可靠：只要开发者证书有效、签名未被吊销，无论程序放在桌面还是U盘都受控；适合微软官方软件、主流商业软件
• 路径规则最易配但防护弱：如C:\MyTool\*.exe，一旦软件升级改名或用户复制到其他目录即失效；通配符慎用，避免误放恶意文件
• 哈希规则最严格但最僵化：适用于无签名的内部工具（如PyInstaller打包的EXE），但每次更新都需重新生成哈希

分阶段灰度上线，靠日志驱动决策

跳过审核直接强制执行，极可能引发登录失败、服务中断或办公瘫痪：

• 第一阶段：在测试OU启用审核模式（Audit only），持续收集3–5个工作日的AppLocker日志（事件查看器 → 应用程序和服务日志 → Microsoft → Windows → AppLocker）
• 重点分析Event ID 8004（被拦截的EXE）、8006（被拦截的脚本），识别杀毒软件更新组件、OA插件、打印机驱动、PowerShell调用等真实执行需求
• 第二阶段：在小范围生产OU（如IT部门）切换为强制执行（Enforced），验证日常办公流无异常
• 第三阶段：全量推送后48小时内紧盯反馈，准备快速回退方案（如临时禁用GPO链接或切回审核模式）