AppLocker和Device Guard是Windows Server中两套核心的应用程序控制与代码完整性防护机制，它们不是二选一的关系，而是可以协同工作、互为补充的安全防线。AppLocker负责基于规则控制哪些程序能运行、哪些不能运行，而Device Guard（在新版Windows中已演进为Windows Defender Application Control，简称WDAC）则从代码签名和内核层面锁定可执行文件的信任链。简单说，AppLocker管"谁能跑"，Device Guard管"什么能跑"，两者叠加使用可以构建从用户态到内核态的纵深防护体系，有效阻止恶意软件、未授权脚本和勒索病毒在服务器上执行。

一、AppLocker的核心原理与部署要点

AppLocker是Windows Server 2008 R2及后续版本内置的应用程序白名单控制功能，它通过组策略（Group Policy）下发规则，限定用户或用户组可以运行哪些可执行文件、脚本、安装程序和DLL。它的工作逻辑非常直接：默认允许管理员组不受限制，其他用户只能运行符合规则的程序。AppLocker支持五种规则类型——可执行文件规则、Windows Installer规则、脚本规则、打包应用规则和DLL规则，管理员可以针对每种类型单独配置。

部署AppLocker的第一步是启用Application Identity服务（AppIDSvc），这个服务必须设为自动启动，否则所有规则都不会生效。第二步是在组策略中找到"应用程序控制策略"节点，创建相应的规则。建议先开启"审核模式"运行一段时间，收集所有被拦截的程序日志，确认无误后再切换到"强制执行"模式。很多运维人员跳过审核阶段直接强制执行，结果导致正常业务程序被误杀，这是最常见的部署失误。

AppLocker的规则可以基于发布者（Publisher）、路径（Path）和文件哈希（File Hash）三种条件来创建。其中基于发布者的规则最灵活也最推荐，因为它依赖数字签名，程序更新后只要签名不变就不需要重新配置规则。基于路径的规则最简单但最脆弱，路径一旦变化规则就失效。基于哈希的规则最严格但维护成本最高，任何文件变动都要重新计算哈希值。实际生产环境中，建议以发布者规则为主，路径规则为辅，哈希规则仅用于高敏感场景。

二、Device Guard（WDAC）的核心原理与部署要点

Device Guard最初在Windows 10企业版和Windows Server 2016中引入，其设计目标是从操作系统启动链开始就锁定信任关系。它基于代码完整性策略（Code Integrity Policy，简称CI策略），只允许运行被明确信任的代码——包括内核驱动、系统DLL和用户态应用。与AppLocker不同，Device Guard的策略是以XML文件形式存在的，通过组策略或MDM（移动设备管理）下发，策略文件一旦加载，系统会在内核层面强制执行，绕过难度极高。

部署Device Guard需要满足几个前置条件：UEFI安全启动（Secure Boot）必须启用、系统必须支持虚拟化扩展（用于内核隔离）、TPM 2.0芯片建议配置。在Windows Server 2019及之后的版本中，Device Guard的功能已整合进Windows Defender Application Control（WDAC），管理方式更统一。WDAC策略可以通过Microsoft Defender Application Control策略向导（WDAC Wizard）生成，也可以手动编写XML策略文件。对于大多数企业，建议使用向导生成初始策略，再根据业务需求微调。

WDAC策略的核心是定义"允许"和"拒绝"两类规则。允许规则指定哪些签名的代码可以运行，拒绝规则则明确禁止特定签名的恶意代码。策略还可以指定规则的适用范围——是仅针对内核代码还是同时覆盖用户态代码。一个典型的生产环境WDAC策略会包含Microsoft签名的系统文件、企业自签的业务应用、以及第三方供应商签名的工具，同时拒绝已知恶意软件的签名。

三、AppLocker与Device Guard协同防护的具体方案

单独使用AppLocker或Device Guard都有各自的盲区。AppLocker工作在用户态，无法控制内核驱动加载，也无法阻止通过PowerShell直接调用内存中的恶意代码。Device Guard虽然在内核层面设防，但策略管理相对复杂，对临时脚本和开发测试场景不够灵活。两者协同使用，可以实现"内核锁信任链 + 用户态控执行权限"的双重防护。

具体协同方案如下：第一层，启用Device Guard/WDAC，锁定内核驱动和系统DLL的信任链，确保只有经过签名的内核模块可以加载。第二层，在Device Guard允许的基础上，叠加AppLocker规则，进一步限制用户态应用的执行权限。例如，Device Guard允许某个签名的应用程序运行，但AppLocker可以限制只有特定用户组才能启动它，或者限制它只能从特定路径启动。这样即使攻击者绕过了Device Guard的内核防护（理论上极难），也会被AppLocker挡在用户态执行环节。

第三层是日志联动。AppLocker的事件日志记录在"Applications and Services Logs/Microsoft/Windows/AppLocker"下，Device Guard/WDAC的事件记录在"Applications and Services Logs/Microsoft/Windows/CodeIntegrity"下。建议将两套日志统一接入SIEM系统（如Microsoft Sentinel或其他安全信息与事件管理平台），实现关联分析。当AppLocker检测到大量路径规则被触发，同时Device Guard检测到未签名驱动加载尝试时，可以判定为高级持续性威胁（APT）攻击并自动触发告警。

四、协同防护的常见坑与实战建议

协同部署最大的坑在于策略冲突。AppLocker和WDAC都是白名单机制，如果配置不当，两者可能互相"打架"——WDAC允许的程序被AppLocker拒绝，或者反过来。解决办法是先部署WDAC策略并验证所有合法程序都能正常运行，然后再在WDAC允许的范围内配置AppLocker规则。永远记住：WDAC是底层，AppLocker是上层，上层规则不能突破底层允许的范围。

另一个常见问题是PowerShell脚本的管控。AppLocker可以控制PowerShell脚本执行，但如果攻击者使用无文件攻击（Fileless Attack）直接在内存中执行代码，AppLocker的脚本规则可能无法捕获。这时候需要配合Windows Defender Exploit Guard中的"攻击面减少规则"（ASR）来限制PowerShell的异常行为。同时，WDAC策略中可以明确禁止未签名的脚本解释器加载，形成更深的防线。

关于策略维护，建议建立一套标准化流程：任何新程序上线前，必须经过签名验证和策略审批；程序更新时，检查签名是否变化，如果变化则更新发布者规则；定期（建议每月）审计AppLocker和WDAC的事件日志，清理过期规则。对于开发测试环境，可以创建单独的OU（组织单位），应用较宽松的策略，避免影响生产环境。

以下是一个典型的AppLocker发布者规则示例，用于允许特定签名的应用程序运行：

<AppLockerPolicy Version="1">
  <RuleCollection Type="Exe" EnforcementMode="Enabled">
    <FilePathRule Id="92112112-1234-4567-89ab-cdef12345678"
                  Name="允许企业ERP系统"
                  Description="允许ERP系统主程序运行"
                  UserOrGroupSid="S-1-5-21-xxxx-xxxx-xxxx-513"
                  Action="Allow">
      <Conditions>
        <FilePathCondition Path="C:\Program Files\ERP\*" />
      </Conditions>
      <PublisherCondition Type="Publisher">
        <PublisherName Name="CN=YourCompany, O=YourOrg, L=City, S=State, C=CN" />
        <ProductName Name="*" />
        <BinaryName Name="ERP.exe" />
      </PublisherCondition>
    </FilePathRule>
  </RuleCollection>
</AppLockerPolicy>

五、适用场景与效果评估

AppLocker与Device Guard协同防护最适合以下场景：承载关键业务的Windows Server（如域控制器、数据库服务器、文件服务器）、需要满足等保2.0或ISO 27001合规要求的企业、以及遭受过勒索病毒攻击后需要加固的环境。根据微软官方数据和行业实践反馈，正确部署这套协同方案后，服务器端恶意代码执行事件可以降低80%以上，尤其对利用未签名工具和脚本的横向移动攻击效果显著。

需要注意的是，这套方案不是银弹。它无法防御已签名的合法软件被滥用（供应链攻击），也无法阻止社会工程学导致的用户主动执行恶意操作。因此，协同防护必须配合其他安全措施——包括端点检测与响应（EDR）、网络分段、最小权限原则和定期安全培训——才能构成完整的安全体系。安全从来不是单一技术能解决的问题，而是多层防御、持续运营的过程。

六、总结与行动建议

AppLocker和Device Guard/WDAC的协同使用，本质上是在Windows Server上构建"零信任执行环境"的实践。Device Guard从内核层面建立信任根基，AppLocker在用户态精细管控执行权限，两者叠加形成纵深防御。对于正在规划Windows Server安全加固的运维团队，建议按以下步骤推进：先评估现有环境的兼容性，再在测试环境中部署WDAC策略并验证，然后叠加AppLocker规则，最后统一接入日志监控平台。不要试图一步到位，分阶段推进、持续调优才是正确路径。