AppLocker、App Control for Business（WDAC）与业务应用分发——在被“执行控制”拦截之前

“装到客户的电脑上以后，应用启动不了。双击也没有任何反应”——在业务应用的分发中，原因不只是应用自身的缺陷，也可能是客户环境的应用程序执行控制。有时 exe 能启动，只有随附的 DLL 或脚本被拦了下来。

这种时候，不要一上来就改签名或安装位置，而要先定位出是哪个机制、以什么为依据、拦下了哪个文件。

本文从制作并分发应用的一方的视角梳理 Windows 的执行控制。先厘清 AppLocker、App Control for Business（原名 WDAC = Windows Defender Application Control）、Smart App Control 与 SmartScreen 的区别，再进入典型的拦截情形、事件日志的读法和分发前的对策。最后还会汇总面向信息系统部门、在自家电脑上引入执行控制的步骤。

1. 先说结论

• 先区分四种机制，再用日志确定对象。SmartScreen 的警告、AppLocker 按用户和组进行的控制、App Control 针对整台机器的控制、Smart App Control 面向个人电脑的保护，并不是同一回事。AppLocker 的 exe/DLL 看 8004，App Control 看 3077 和签名信息 3089，这是调查的核心。脚本与 MSI 还要查看另外的日志。¹²
• 分发方要把应用做成更新之后允许规则依然匹配的样子。核心在于不只给 exe 签名，而是对 DLL、安装程序、随附脚本都做一致的签名。发行者信息、文件属性、安装位置、自动更新的流程也要一并理顺。即使是不在企业管理之下的电脑，未签名的应用也可能被 Smart App Control 拦下。³⁴
• 引入方要先在审核模式下让业务跑满一轮，再转入强制执行。条件允许时选择 App Control，需要按用户区分控制等场合才用 AppLocker。不能认为“客户的电脑是 Pro 版，所以与自己无关”。装了 KB 5024351 的 Windows 10 2004 及更高版本和 Windows 11 上，强制执行 AppLocker 不再要求特定版本，App Control 也支持全部客户端版本。³⁵

按目的选择读法

PowerShell 有时不会被完全拦截，而是以约束语言模式运行，只有部分处理失败。这一差别也在第 4 章说明。²

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 36 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. 区分四种机制

名称相近的这几种产品，按“作用对象”“生效方式”“由谁管理”来区分。首先要分辨出：需要处理的是警告，还是需要与管理员的允许规则进行比对。

2.1. SmartScreen——唯一用“警告”拦人的机制

SmartScreen 是根据文件信誉发出警告的机制。即使没有管理员编写规则，它也默认生效，通常用户可以越过警告继续执行。

不过，只要应用了禁止跳过警告的管理策略，SmartScreen 实际上也等同于拦截。这并不意味着“既然是警告，就一定能执行”。

分发方的对策，要和请客户编写 AppLocker 等允许规则分开考虑。SmartScreen 这边的核心是签名与信誉的积累。详情在“Windows SmartScreen 与代码签名”中讨论。接下来的 2.2 到 2.4，是拦截执行而非发出警告的机制。

2.2. AppLocker——可以按用户控制的老资格

以什么为依据、控制谁的执行

AppLocker 在 Windows 7 中引入。规则的依据是代码签名证书的属性（发行者）、来自签名元数据的文件属性（原始文件名、版本）、哈希值，以及文件的路径。策略不仅可以应用于整台计算机，也可以应用于特定的用户和组。³

把“能创建规则”和“能强制执行”分开看

把这两件事分开，版本要求就好理解了。自 KB 5024351 起，在 Windows 10 版本 2004 及更高版本以及所有 Windows 11 上，强制执行 AppLocker 策略不需要特定版本。⁵

另一方面，在较旧的 Windows 上，分发方式带来的差异依然存在。包含早于 2004 的 Windows 10 和 Windows Server 2019 的环境，仍适用原先的条件：通过组策略分发的策略只有 Enterprise 和 Server 版本能强制执行，通过 MDM 分发则全部版本都可以。⁵

Pro 版同样可以创建规则。以前的限制主要在于能否强制执行，而通过 MDM 分发的话，当时的 Pro 版也能强制执行。可执行文件、Windows Installer、脚本、DLL、打包应用这几类规则种类，也不随版本而变。⁵

另外还有一个与版本无关的前提。如果 Application Identity 服务（AppIDSvc）没有运行，规则就不会被评估。这一点连同审核的准备工作放在第 6 章确认。

作为安全功能的定位

微软明确写明，AppLocker 不满足 MSRC 对安全功能的服务标准（servicing criteria）。也就是说，即使发现了绕过手法，仅凭这一事实也不会被当作安全漏洞来处理。在这一点上，它和下面的 App Control 也不同。³

2.3. App Control for Business——作为安全功能的正选

对整台机器生效的机制

App Control for Business 是这一机制的现用名称：它在 Windows 10 中曾作为 Device Guard 的一部分，被称为“可配置的代码完整性”，长期以来又被叫作 WDAC。策略对整台机器生效，影响该设备上的全部用户。它是按 MSRC 服务标准所定义的安全功能来设计的。³

规则的依据可以整理如下。³

使用条件与分发方式

策略可以在 Windows 10/11 的任意客户端版本，或 Windows Server 2016 及更高版本上创建并应用。分发可以使用 Intune 等 MDM、Configuration Manager 和 PowerShell。组策略也能用，但要注意仅限于在 Windows Server 2016/2019 上运行的单策略格式。³

与 AppLocker 如何取舍

微软建议，只要能用 App Control 实现，就使用 App Control。App Control 在持续改进，而 AppLocker 虽然仍会收到安全修复，却不再增加新功能。³

适合用 AppLocker 的场景是：想把同一份策略下发到包含旧版 Windows 的混合环境；想在共享电脑上按用户和组分别设置规则。也可以把它作为 App Control 的补充，追加按用户区分的限制。³

2.4. Smart App Control——“不请自来”装在个人电脑上的执行控制

Smart App Control 是 Windows 11 面向个人用户的保护功能。它在执行时确认云端安全服务对安全性的预测，以及应用是否带有有效签名，拦截被判定为具有恶意的应用，以及没有有效签名、无法确认可信度的应用。⁴

新电脑上会从评估模式开始，由 Windows 判断它是否适合该用户，从而决定启用还是禁用。对于开发者这类可能频繁遇到拦截的用户，它会自动关闭。⁴

分发方要记住的一点是，即使是信息系统部门没有编写过策略的电脑，执行控制照样起作用。小微企业和个体经营者这类客户同样跑不掉。未签名的应用可能被拦下，微软也向开发者建议用有效证书为应用签名。证书的选择方法在第 5 章整理。⁴

3. 你的应用被拦截的典型模式

要确认的不只是“主程序能不能启动”，还包括安装、DLL 的加载、脚本、插件和自动更新。在受托开发和打包分发中容易出问题的模式如下。

共同的原因是允许规则的依据不稳定

表中各项的共同点在于：允许一方所需要的依据（签名、路径、哈希），分发方没有稳定地提供出来。

例如只给 exe 签名的话，未签名的 DLL 就套不上同一条发行者规则。即使用单独的哈希规则放行，更新后二进制文件一变，规则也要跟着更新。看上去像是客户的控制措施导致的，实际上常常是分发件或更新方式让规则变得容易失效。

根据症状缩小范围之后，用下面的日志确定实际被拦下的文件。考虑对策是在这之后的事。

4. 用日志确定到底发生了什么

看事件日志时，要把“被拦下这一事实”和“该修什么”分开读。入口有 AppLocker 之下和 CodeIntegrity 两套，但要点在于即使日志名叫 AppLocker，其中也会记录 App Control 的事件。²

4.1. AppLocker 的事件

打开日志，选择对象的种类

事件查看器可以在开始菜单中搜索“事件查看器”打开，或者在“运行”对话框中输入 eventvwr.msc 打开。¹

事件查看器 > 应用程序和服务日志 > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

英文环境中是 Applications and Services Logs > Microsoft > Windows > AppLocker。

用 PowerShell 获取时，以管理员身份打开并执行下面的命令。这个例子只取出最近 24 小时内 exe/DLL 的审核与拦截记录，脚本和 MSI 不在范围内。

# 取出最近 24 小时内 AppLocker 的拦截（8004）与审核（8003）记录
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

是命中了拒绝规则，还是缺少允许规则

事件中会记录目标文件的路径、允许还是拦截的结果、规则种类（路径、哈希、发行者）、规则名称，以及用户和组的 SID。¹

不过，在白名单式的运维中，没有命中任何允许规则的“隐式拒绝”会占多数。

8004 虽然能说明拦截的事实和对象，但在隐式拒绝的情况下，仅凭规则名称无法定位原因。光看事件还不够，必须和正在生效的策略比对。

4.2. App Control for Business（WDAC）的事件

exe、DLL、驱动程序与脚本类的日志是分开的

对 exe、DLL、驱动程序的控制，查看下面的 CodeIntegrity 日志。对 MSI、脚本、COM 的控制，则记录在前面那个 AppLocker - MSI and Script 日志中。²

事件查看器 > 应用程序和服务日志 > Microsoft > Windows > CodeIntegrity > Operational（英文环境中是 Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational）

# 一并查看 App Control 的拦截（3077）、审核（3076）以及对应的签名信息（3089）
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

这条命令取得的是 CodeIntegrity 的 3076、3077、3089。调查 MSI、脚本、COM 时，请按下表另外查看 AppLocker - MSI and Script。在还不清楚是哪套机制的阶段，就把 AppLocker 之下和 CodeIntegrity 按同一时间范围对照着看。

用 3089 确认实际被评估的签名

3089 按文件的每个签名各生成 1 条。未签名的文件会出现 1 条签名数为 0 的事件。它与 3076、3077 等之间，通过关联 Activity ID 建立对应。²

“明明签过名却被当成未签名”“旧证书的签名还留着”这类问题，都可以用这份签名信息确认。请把分发方核对过的文件，与客户侧被评估的文件状态比对。

即使出现 8029，PowerShell 也未必完全停止

8029 表示脚本被拦截，但实际的强制行为交由脚本宿主决定。PowerShell 不会完全停止策略未允许的脚本，而是以约束语言模式（Constrained Language Mode）执行。²

在这一模式下，.NET 对象的创建受到大范围限制。因此症状会表现为“脚本已经开始运行，但中间某一行失败了”。排查随附脚本时，不要只凭是否启动成功来判断。签名的具体做法请参阅“PowerShell 的执行策略与脚本签名”。

另外，Windows Server Core 版本中没有 AppLocker - MSI and Script 日志。调查服务器上的应用时，还要注意日志本身是否存在。²

5. 分发方的对策——做成让规则“容易编写”的应用

目标是在客户的信息系统部门能写出稳定允许规则的状态下进行分发。签名是核心对策，但这并不意味着只要签了名，就能不受客户策略影响地运行。要备齐的东西分成 6 项。

这些准备对 Smart App Control 同样有效。已签名并积累了信誉的二进制文件，也不容易被个人电脑上的自动拦截挡住。⁴

5.1. 第一次申请代码签名证书时

选择受信任证书颁发机构的 RSA 证书

以面向外部客户分发为前提时，要选择公共证书颁发机构（商用 CA）签发的、基于 RSA 的代码签名证书。自签名证书或企业内部 CA 签发的证书，在不信任该 CA 的客户电脑上无法验证，Smart App Control 也不支持。⁶

算法也要确认。Smart App Control 的签名检查不支持 ECC（椭圆曲线）签名。即使用 ECC 签了名，在个人电脑上也可能被当成未签名来对待。⁶

App Control 这边同样，基于签名者的规则只支持 RSA（最长 4096 位）。想用发行者规则放行 ECDSA 签名时，对应的 3089 中会记录 VerificationError = 23。仅凭“ECC 更新更强”这一条理由来选，就会在与执行控制的兼容性上遇到麻烦。⁷

从发行者规则的角度看，OV 和 EV 都能用

公共 CA 的证书分为进行企业实体验证的 OV 和审核更严格的 EV。AppLocker 和 App Control 的发行者规则，用哪种证书都能创建。

App Control 有一个名为 Required:EV Signers 的规则选项，但官方文档写明目前尚不支持。因此，为了本文讨论的这些执行控制而选择 EV 并没有理由。与 SmartScreen 的关系，在“Windows SmartScreen 与代码签名”中另行整理。⁷

除了证书费用，还要把私钥保管与签名运维算进预算

费用因 CA 和有效期而异。做预算时，除了证书本身，还要确认令牌、HSM，或 CA 提供的云签名服务的使用费。

对于 2023 年 6 月 1 日之后签发的证书，按照 CA/Browser Forum 的基准，无论 OV 还是 EV，都必须在相当于 FIPS 140-2 第 2 级以上的硬件（HSM 或 USB 令牌）中生成并保管私钥。⁸

如果要在 CI/CD 中自动签名，云签名服务有时比物理令牌更容易配置。在购买证书之前，把从构建到签名的运维方式也一并商量清楚，才符合实务。

给所有二进制文件签名并加上时间戳

Authenticode 签名不能只覆盖 exe，还要覆盖自己构建的 DLL、安装程序（MSI／安装用 exe）和随附脚本。只要有签名元数据，客户就能写出“这个发行者的这个产品，不论版本一律允许”这类经得起更新的规则。³

加时间戳是为了在证书过期之后仍保持签名有效。使用 Windows SDK 的 signtool 的最小示例如下。

:: 签名（用 SHA-256 计算哈希，并加上 RFC 3161 时间戳）
signtool sign /fd sha256 /tr <时间戳服务器的URL> /td sha256 /a MyApp.exe

:: 验证签名（按 Authenticode 策略校验并显示详情）
signtool verify /pa /v MyApp.exe

时间戳服务器使用购买方 CA 给出的 URL。使用令牌或 HSM 中的密钥时，还要按 CA 的操作手册确认 CSP/KSP 的指定方式。DLL 和安装程序都可以用同一条命令签名，所以把签名与验证统一放在构建的最后一步执行。

5.2. 把证书与文件属性的变更当成客户的规则变更来处理

即使签名保持一致，只要规则用于比对的对象变了，更新版照样会被拦下。要确认的不只是证书的主题和证书链。产品名称、原始文件名和版本并非来自证书，而是来自各文件的版本资源（程序集信息）。

App Control 的 Publisher 是“PCA 证书（通常是根证书下一级）+ 叶证书的 CN”，FilePublisher 在此基础上再组合已签名文件的 FileName 属性（默认为 OriginalFileName）和最低版本号。⁷

这类变更在客户看来就是“升级之后，只有这个环境启动不了了”。要变更公司名称写法、CA 或产品与文件属性时，请在发行说明中并列写出新旧签名信息（主题、签发 CA），并提前通知。这样客户的信息系统部门才能追加或更新允许规则。

5.3. 稳定安装位置与自动更新的流程

可执行文件放在 Program Files 之下等位置，避免运行时把 exe/DLL 解压到 %TEMP% 或 %APPDATA% 再启动的设计。因为在用户可写的位置执行的设计，与路径规则型的环境天然不合。

自动更新时，更新程序本身也要签名，形成用已签名的二进制文件替换已签名的二进制文件的流程。安全设计的细节请参阅“自动更新的安全设计”。

通过 Intune 或 Configuration Manager 分发时，只要客户把分发代理配置成了托管安装程序，就可以采用允许经由该途径进入的二进制文件的运维方式。并不是用 Intune 分发就会自动放行，前提是管理员做了明确的配置。准备一个支持静默安装的 MSI，就能把这个选项交到客户手里。

5.4. 在部署手册中备齐创建规则所需的信息

交给客户的部署手册中要写明签名的主题、运行所需的二进制文件清单、安装目标路径。这些是信息系统部门创建允许规则的依据。

遇到拦截时，要能直接指明第 4 章的日志名称和事件 ID，请对方协助确认。这样可以减少只说“启动不了”的来回沟通，让目标文件与签名信息可以马上比对。

6. 引入方（信息系统部门）的要点

引入方的基本顺序是：选择技术 → 用审核确认影响 → 整理好允许规则再强制执行 → 持续管理例外。关键是不要一上来就在全部终端上开始拦截。

6.1. 按用途选择技术，并备齐审核的前提条件

原则上选 App Control for Business。共享电脑上需要按用户控制，或者混有旧版操作系统时，再并用 AppLocker。³ 信息亭这类用途固定的电脑，先用 shell 限制把用途收窄，规则就会简单很多。也请参阅“信息亭模式与分配的访问权限”。

审核阶段要在不中断业务的前提下，收集“若处于强制执行状态本会被拦截的内容”。AppLocker 以 AppIDSvc 处于运行状态为前提，服务停着的话连审核事件都不会产生。要先在目标终端上配置好自动启动再开始。

先收集到业务跑满一轮再转入强制执行，这个思路与 SMB 签名和 NTLM 限制是一样的。包括月度、年度批处理在内，不要只用日常操作就结束确认。

6.2. AppLocker 分三步从审核走向强制执行

1. 启用审核模式。在组策略管理编辑器（本地则用 secpol.msc）中打开 计算机配置 > 策略 > Windows 设置 > 安全设置 > 应用程序控制策略 > AppLocker。右键单击 AppLocker 打开属性，对每个规则集合（可执行文件、Windows Installer、脚本、打包应用）选择“已配置”，并设为“仅审核”。为各集合创建默认规则，同时配置 AppIDSvc 的自动启动。

2. 从与对象相符的日志中收集事件。exe/DLL 看 EXE and DLL 的 8003，脚本与 MSI 看 MSI and Script 的 8006。4.1 节的命令只查 EXE and DLL，因此取不到 8006。要同时查看两者，可以像下面这样分开取日志。¹

    # 在审核模式下，从两个日志中收集“若强制执行本会被拦截的内容”
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   在没有相应事件的日志上 Get-WinEvent 会返回错误，所以这个例子加了 -ErrorAction SilentlyContinue。即使没有输出，也要确认服务是否运行、目标日志是否正确、取值期间是否合适。如果打包应用也在范围内，就按同样的写法追加 Packaged app-Deployment / Packaged app-Execution，并一直确认到月度、年度批处理。

3. 整理好允许规则之后再切换到强制执行。确认 8003、8006 中出现的业务必需文件，把它们纳入允许规则。之后在同一个属性界面改为“强制规则”。切换之后，监视 8004（exe/DLL）和 8007（脚本与 MSI）的拦截记录。

6.3. App Control 通过去掉审核选项转入强制执行

在策略 XML 中加入规则选项 3（Enabled:Audit Mode）后再分发。设置时使用 App Control Policy Wizard，或者 Set-RuleOption cmdlet。⁷

用 3076 和 8028 确认对业务的影响，整理好允许规则之后删除审核选项，就进入强制模式。微软也建议新策略先用审核模式确认。⁷

6.4. 把未签名的例外与资产管理挂钩

对仍然以未签名状态继续使用的老旧业务应用，用哈希规则登记为例外来管理。这份清单同时也是今后需要更新换代的资产清单。不要建完例外就算完事，要与资产管理关联起来，每年复查一次。

7. 小结

应对执行控制，可以归纳为三件事：分辨清楚是哪个机制、用日志确定事实、做出能让允许规则保持稳定的分发件。

SmartScreen 基本上只是警告，但在禁止跳过的策略之下就变成了拦截。它与 AppLocker、App Control、Smart App Control 的应对方式要分开考虑。AppLocker 的版本限制已经放宽，App Control 在全部客户端版本上都能使用。Smart App Control 连个人电脑也会生效，因此不能以“因为是 Pro 版”“因为没有信息系统部门”为由认为与自己无关。⁵³⁴

应用启动不了时，以 AppLocker 的 8004、App Control 的 3077 与 3089 为入口，同时比对脚本与 MSI 的日志。如果只有部分功能失败，还要确认 PowerShell 的约束语言模式。¹²

分发方要备齐：对所有二进制文件的一致签名、时间戳、稳定的发行者信息与文件属性、标准的存放位置、已签名的自动更新，以及部署手册。基本原则是把应用做成让客户容易编写允许规则、更新之后也容易维持的样子。

引入方则要用 AppLocker 的 8003、8006 和 App Control 的 3076、8028 让业务跑满一轮，再转入强制执行。把分发与运维两侧都理顺，就能减少“只在客户环境跑不起来”的情况。

相关文章

• Windows 出现“Windows 已保护你的电脑”提示的原因
• 自动更新的安全设计——为什么仅靠 HTTPS 还不够
• Windows 应用发布方式怎么选 - MSI / MSIX / ClickOnce / xcopy / 自定义 updater 判断指南
• PowerShell 的执行策略与脚本签名——从“用 Bypass 蒙混过关”的运维方式毕业的实务指南
• 当自研 Windows 应用被 Microsoft Defender 判定为病毒——误报处理与性能影响应对指南
• 用信息亭模式固化业务终端——Assigned Access、Shell Launcher 的选择方法与运维设计
• Windows 10 停止支持后的现实解决方案——ESU、LTSC、更换设备的判断表

相关咨询领域

小村软件有限公司承接在执行控制环境（AppLocker / App Control for Business）下运行的业务应用的开发与改造、集成代码签名的分发与自动更新设计，以及客户环境中应用启动不了这类问题的调查。

• Windows 应用程序开发
• 现有 Windows 软件的改造与维护
• 故障排查与原因分析
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

AppLocker 在 Pro 版本上不是用不了吗？

这个常识已经该更新了。自 KB 5024351 起，在 Windows 10 版本 2004 及更高版本以及所有 Windows 11 上，强制执行 AppLocker 策略不再需要特定版本。过去那条“只有 Enterprise 和 Server 版本才支持通过组策略分发进行强制执行”的限制，只适用于早于版本 2004 的 Windows 10 以及 Windows Server 2019 及更早版本（即便如此，通过 MDM 分发时全部版本都能用）。在以中小企业 Pro 版终端为主的环境中，如今 AppLocker 也进入了可选范围。

代码签名证书应该买 EV 的吗？

从 AppLocker 和 App Control for Business 的发行者规则这个角度看，OV（企业实体验证）证书和 EV 证书都能用来创建基于签名者信息的规则。另外，“用 EV 签名后 SmartScreen 从第一次起就不会警告”这种理解已经过时，现在即使是用 EV 签名的文件，也要和 OV 一样以信誉积累为前提来考虑（这一论点在另一篇文章“Windows SmartScreen 与代码签名”中整理）。比证书种类更重要的是：不只对 exe，还要把 DLL 和安装程序在内的全部二进制文件用一致的主题签名，加上时间戳，并在证书更新时保持发行者信息稳定。发行者规则正是依赖这些签名者信息写出来的，每次发布签名状态都变来变去的话，客户侧的规则就会失效。

客户环境中我方应用好像被拦下了，但日志里什么都找不到。应该看哪里？

原因多半是该看的日志分成了两套。AppLocker 对 exe/DLL 的拦截出现在“AppLocker - EXE and DLL”日志的事件 8004（审核模式下为 8003），脚本和 MSI 出现在“AppLocker - MSI and Script”日志的 8007（审核模式下为 8006）。另一方面，App Control for Business（WDAC）的拦截出现在“CodeIntegrity - Operational”日志的事件 3077（审核模式下为 3076），对应的签名信息记录在 3089 中。此外，脚本、MSI、COM 被 App Control 拦下时，会出现在“AppLocker - MSI and Script”日志的 8029、8036、8040 中。在还不清楚是哪套机制在起作用的阶段排查时，请把 CodeIntegrity - Operational 和 AppLocker 之下的日志按时间对照着看。

要让我方应用不被 Smart App Control 拦下，需要做什么？

实质上就是代码签名。Smart App Control 在应用执行时会确认云端安全服务对其安全性的预测，以及应用是否带有有效签名，并拦截被判定为具有恶意的应用，以及没有有效签名、无法确认可信度的应用。微软在面向开发者的说明中，也提到了用有效证书为应用签名。但要注意签名算法：Smart App Control 的签名检查不支持椭圆曲线密码（ECC）签名，只有用基于 RSA 的证书签名的应用才会被允许执行。Smart App Control 不是企业管理功能，而是面向 Windows 11 个人用户的保护机制，其启用与禁用由评估模式自动决定，因此从分发方来看，按“未签名的可执行文件在个人电脑上有可能跑不起来”这个前提来处理才稳妥。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。