applocker白名单在域内强制推行核心是建机制而非加规则：须域控制器统一策略下发、客户端application identity服务运行、规则部署于计算机配置路径、分阶段灰度上线并验证日志，缺一不可。
applocker白名单在域内强制推行，核心不是“加规则”，而是“建机制”：必须依赖域控制器统一策略下发、客户端服务就绪、规则逻辑闭环、上线节奏可控。本地配置或单点启用基本无效。
前提条件必须全部满足
缺一不可，否则策略形同虚设：
- 所有目标终端（Windows 10/11 Pro/Enterprise/Education 或 Windows Server 2012+）已加入域，且组策略可正常刷新
- 每台终端上“Application Identity”服务启动类型设为“自动”，并实际处于“正在运行”状态（仅靠组策略启动不等于已运行）
- 策略必须部署在计算机配置 → 策略 → Windows 设置 → 安全设置 → 应用程序控制策略 → AppLocker路径下，不能放在用户配置分支
- 域控制器需运行 Windows Server 2012 或更高版本，且 GPMC 可用；客户端系统版本不低于 Win10 1607
默认规则是起点，不是终点
右键“可执行规则”→“创建默认规则”会生成三条基础路径+签名规则，覆盖 %WINDIR%、%PROGRAMFILES% 和 %PROGRAMFILES(X86)% 下的微软签名程序。但这只是基线，必须手动操作：
- 进入每类规则（可执行、脚本、安装程序、DLL）的属性页，勾选“配置规则强制执行”，再单独启用对应规则集
- DLL 规则默认禁用，如需控制（例如防DLL侧加载），必须手动开启并配置
- 检查默认规则是否遗漏业务关键路径（如 C:\Apps\、D:\ERP\Bin\），及时补充发布者或路径规则
- 明确启用“默认拒绝所有用户运行未明确允许的应用”——这是白名单生效的底层开关
规则类型选择有优先级
不是所有规则都适合强制执行，应按可信度与维护成本排序使用：
- 首选发布者规则：基于数字签名（发行者、产品名、证书链），软件升级后仍有效；适用于 Microsoft、Adobe、Oracle 等正规厂商软件
- 次选路径规则：限定安装目录（如 C:\Program Files\Zoom\*.exe），见效快但易被拖放桌面、解压即用型工具绕过；避免滥用通配符（如 C:\*\*.exe）
- 兜底用哈希规则：对无签名的内部工具、PyInstaller 打包程序、PowerShell 脚本，右键→“自动生成规则”可快速锁定 SHA256 哈希；但每次更新必须重生成
- 脚本（.ps1、.bat、.vbs）、安装包（.msi）、DLL 必须单独配置规则，AppLocker 不跨类型继承
灰度上线与日志验证不可跳过
直接全量强制执行极易导致登录失败、OA 插件崩溃、打印异常等生产事故：
- 先在测试 OU 启用“审核模式”（Audit only），持续采集 3–5 个工作日日志（事件查看器 → Applications and Services Logs → Microsoft → Windows → AppLocker）
- 重点筛查 Event ID 8004（被允许）、8006（被阻止）事件，识别真实运行需求：杀毒软件更新模块、远程桌面组件、打印机驱动、PowerShell 调用路径、计划任务触发的 EXE
- 小范围生产 OU（如 IT 部门）开启强制执行，验证日常办公流完整可用
- 全量推送后 48 小时内安排专人盯守事件日志和一线反馈，准备快速回退方案（如临时禁用 GPO 链接或切回审核模式）
