了解适用于业务的应用控制策略规则和文件规则

注意

适用于企业的 App Control 的某些功能仅适用于特定 Windows 版本。 详细了解 应用控制功能可用性。

企业应用控制可以通过设置指定驱动程序或应用程序是否受信任的策略来控制在 Windows 设备上运行的内容。 策略包括用于控制选项（如审核模式） 的策略规则 ，以及文件 规则 (或 文件规则级别) 指定如何标识组织信任的应用程序。

适用于业务的应用控制策略规则

若要修改现有应用控制策略 XML 的策略规则选项，请使用 应用控制策略向导 或 Set-RuleOption PowerShell cmdlet。

可以在应用控制策略中设置多个规则选项。 表 1 介绍了每个规则选项，以及补充策略是否可以设置它们。 某些规则选项保留用于将来的工作或不受支持。

注意

建议最初使用 Enabled：Audit Mode ，因为它允许在强制实施新的应用控制策略之前对其进行测试。 使用审核模式时，应用程序会正常运行，但每当文件运行策略不允许时，应用控制会记录事件。 若要允许这些文件，可以从事件日志中捕获策略信息，然后将该信息合并到现有策略中。 删除 Enabled：Audit 模式 后，策略将在强制模式下运行。

即使策略处于审核模式，某些应用的行为也可能有所不同。 当某个选项可能在审核模式下更改行为时，表 1 中已记录这一点。 在将重大更新部署到应用控制策略时，应始终全面测试应用。

表 1. 适用于业务的应用控制策略 - 策略规则选项

规则选项 描述 有效的补充选项
0 已启用：UMCI 应用控制策略限制内核模式和用户模式二进制文件。 默认情况下，仅限制内核模式二进制文件。 启用此规则选项可验证用户模式可执行文件和脚本。 否
1 已启用：启动菜单保护 目前不支持此选项。 否
2 必需：WHQL 默认情况下，允许运行不是 Windows 硬件质量实验室 (WHQL) 签名的内核驱动程序。 启用此规则要求每个驱动程序都经过 WHQL 签名，并删除旧版驱动程序支持。 为Windows 10构建的内核驱动程序应经过 WHQL 认证。 否
3 已启用：审核模式（默认） 指示应用控制记录有关应用程序、二进制文件和脚本的信息，如果强制实施策略，则会阻止这些应用程序、二进制文件和脚本。 可以使用此选项来确定应用控制策略的潜在影响，并使用审核事件在强制实施之前优化策略。 若要强制实施应用控制策略，请删除此选项。 否
4 已禁用：外部测试版签名 如果启用，则不信任 Windows 预览体验成员内部版本的二进制文件。 对于只想运行已发布的二进制文件而不是预发行版的组织，此选项非常有用。 否
5 已启用：继承默认策略 此选项保留供将来使用，目前不起作用。 是
6 已启用：未签名的系统完整性策略（默认） 允许策略保持未签名状态。 删除此选项后，必须对策略进行签名，并且还必须对任何补充策略进行签名。 必须在 UpdatePolicySigners 部分中标识受信任的证书，以便将来的策略更新。 必须在 SupplementalPolicySigners 部分中标识信任补充策略的证书。 是
7 已允许：调试策略增强 目前不支持此选项。 是
8 必需：EV 签名者 目前不支持此选项。 否
9 已启用：高级启动选项菜单 默认情况下，对所有应用控制策略禁用 F8 预启动菜单。 设置此规则选项可使 F8 菜单显示给实际存在的用户。 否
10 已启用：在失败时启动审核 在应用控制策略处于强制模式时使用。 当启动关键驱动程序在启动期间失败时，应用控制策略将置于审核模式，以便 Windows 加载。 管理员可以在 CodeIntegrity 事件日志中验证失败的原因。 否
11 已禁用：脚本强制 此选项禁用脚本强制选项，包括 PowerShell、基于 Windows 的脚本主机 (wscript.exe) 、基于 Windows 控制台的脚本主机 (cscript.exe) 、在 Microsoft HTML 应用程序主机 (mshta.exe) 和 MSXML 中运行的 HTA 文件。 即使策略处于审核模式，某些脚本主机的行为也可能有所不同。 有关脚本强制实施的详细信息，请参阅 使用应用控件执行脚本。
注意：Windows Server 2016或 Windows 10 1607 LTSB 不支持此选项，不应在这些操作系统上使用。		 否
12 必需：强制执行 Store 应用程序 如果启用此规则选项，应用控制策略也适用于通用 Windows 应用程序。 否
13 已启用：托管安装程序 使用此选项可自动允许托管安装程序安装应用程序。 有关详细信息，请参阅 授权使用应用控制托管安装程序部署的应用 是
14 已启用：Intelligent Security Graph 授权 使用此选项可自动允许Microsoft的 Intelligent Security Graph (ISG) 定义的具有“已知良好”信誉的应用程序。 是
15 已启用：重新启动时使 EA 失效 当使用 Intelligent Security Graph 选项 (14) 时，应用控制设置一个扩展文件属性，该属性指示该文件已获授权运行。 此选项会导致应用控制定期重新验证以前由 ISG 授权的文件的信誉。 否
16 已启用：更新策略但不重新启动 使用此选项可允许应用未来的应用控制策略更新，而无需重新启动系统。
注意：仅Windows 10版本 1709 及更高版本或 Windows Server 2019 及更高版本支持此选项。		 否
17 已启用：允许补充策略 在基础策略上使用此选项，以允许补充策略扩展它。
注意：此选项仅在 Windows 10、版本 1903 及更高版本或 Windows Server 2022 及更高版本上受支持。		 否
18 Disabled：Runtime FilePath 规则保护 此选项禁用默认运行时检查，该检查仅允许仅由管理员可写的路径的 FilePath 规则。
注意：此选项仅在 Windows 10、版本 1903 及更高版本或 Windows Server 2022 及更高版本上受支持。		 是
19 已启用：动态代码安全性 为 .NET 应用程序和动态加载的库启用策略强制实施。
注意：此选项仅在 Windows 10、版本 1803 及更高版本或 Windows Server 2019 及更高版本上受支持。
注意：如果 任何 应用控制 UMCI 策略启用此选项，则始终强制实施此选项。 .NET 动态代码安全强化没有审核模式。		 否
20 Enabled：Revoked Expired As unsigned 使用此选项可将使用吊销证书签名的二进制文件或签名上具有生存期签名 EKU 的过期证书视为企业签名方案下用户模式进程/组件的“未签名二进制文件”。 否
Enabled：开发人员模式动态代码信任 使用此选项可以信任 在 Visual Studio 中调试 或在系统上启用开发人员模式时通过设备门户部署的 UWP 应用。 否

适用于企业的应用控制文件规则级别

文件规则级别允许管理员指定他们希望信任其应用程序的级别。 此信任级别可以像每个二进制文件的哈希一样细化，也可以像 CA 证书一样一般。 使用应用控件向导或应用控件 PowerShell cmdlet 创建和修改策略时，可以指定文件规则级别。

每个文件规则级别各有优缺点。 使用表 2 为可用的管理资源和应用控制部署方案选择适当的保护级别。

注意

基于应用控制签名者的规则仅适用于最大密钥长度为 4096 位的 RSA 加密。 不支持 ECC 算法，例如 ECDSA。 如果尝试允许基于 ECC 签名的签名文件，则会在相应的 3089 签名信息事件中看到 VerificationError = 23。 如果文件也使用 RSA 签名，则可以改为通过哈希或文件属性规则或其他签名者规则来允许文件。

表 2. 适用于业务的应用控制策略 - 文件规则级别

规则级别 说明
哈希 为每个发现的二进制文件指定单独的 Authenticode/PE 图像哈希值 。 此级别是最具体的级别，需要付出更多努力来维护当前产品版本的哈希值。 每次更新二进制文件时，哈希值都会更改，因此需要策略更新。
FileName 指定每个二进制文件的原始文件名。 尽管在更新时会修改应用程序的哈希值，但通常不会修改文件名。 此级别提供的安全性不如哈希级别更具体，但在修改任何二进制文件时，它通常不需要更新策略。 默认情况下，此级别使用文件的资源标头的 OriginalFileName 属性。 使用 -SpecificFileNameLevel 选择备用属性，例如 ProductName。
FilePath 从 Windows 10 版本 1903 开始，此级别允许从特定文件路径位置运行二进制文件。 FilePath 规则仅适用于用户模式二进制文件，不能用于允许内核模式驱动程序。 有关 FilePath 级别规则的详细信息，请参阅本文的后面部分。
SignedVersion 此级别将发布者规则与版本号组合在一起。 它允许从指定发布服务器运行任何版本，其版本高于指定版本号。
发布者 此级别将 PcaCertificate 级别 (通常是根) 以下的一个证书和叶证书的公用名称 (CN) 组合在一起。 可以使用此规则级别信任由特定 CA 颁发的证书，该证书颁发给你信任的特定公司， (如 Intel，用于设备驱动程序) 。
FilePublisher 此级别将已签名文件的“FileName”属性加上“Publisher” (PCA 证书与叶) 的 CN 以及最小版本号组合在一起。 此选项允许来自特定发布者的任何内容（其文件版本等于或高于指定的版本号）运行。 默认情况下，此级别使用文件的资源标头的 OriginalFileName 属性。 使用 -SpecificFileNameLevel 选择备用属性，例如 ProductName。
LeafCertificate 在各个签名证书级别上添加受信任的签名者。 与单个哈希级别相比，使用此级别的好处是，新版本的产品具有不同的哈希值，但通常具有相同的签名证书。 使用此级别时，无需更新策略即可运行应用程序的新版本。 但是，叶证书的有效期通常比其他证书级别短，因此每当这些证书发生更改时，都必须更新应用控制策略。
PcaCertificate 将所提供的证书链中最高级别的可用证书添加到签名者。 此级别通常是根证书以下的一个证书，因为扫描不会通过本地根存储或联机检查解析完整的证书链。
RootCertificate 不支持。
WHQL 仅信任提交到 Microsoft 并由 Windows 硬件资格实验室 (WHQL) 签名的二进制文件。 此级别主要用于内核二进制文件。
WHQLPublisher 此级别将 WHQL 级别和叶证书上的 CN 组合在一起，主要用于内核二进制文件。
WHQLFilePublisher 此级别将签名文件的“FileName”属性加上“WHQLPublisher”以及最小版本号组合在一起。 此级别主要用于内核二进制文件。 默认情况下，此级别使用文件的资源标头的 OriginalFileName 属性。 使用 -SpecificFileNameLevel 选择备用属性，例如 ProductName。

注意

使用 New-CIPolicy 创建应用控制策略时，可以通过包括 -Level 参数来指定主文件规则级别。 对于所发现的基于主要文件规则条件无法信任的二进制文件，请使用 –Fallback 参数。 例如，如果主文件规则级别为 PCACertificate，但你也希望信任未签名的应用程序，则使用哈希规则级别作为回退将添加没有签名证书的二进制文件的哈希值。

注意

如果适用，文件规则中的最小和最大版本号在策略 XML 中分别引用为 MinimumFileVersion 和 MaximumFileVersion。

  • 同时指定 MinimumFileVersion 和 MaximumFileVersion：对于允许规则，允许版本 大于或等于 MinimumFileVersion 且 小于或等于 MaximumFileVersion 的文件。 对于拒绝规则，将拒绝版本 大于或等于 MinimumFileVersion 且 小于或等于 MaximumFileVersion 的文件。
  • 指定了不带 MaximumFileVersion 的 MinimumFileVersion：对于“允许”规则，允许运行版本 大于或等于 指定版本的文件。 对于拒绝规则，将阻止版本 小于或等于 指定版本的文件。
  • 指定了不带 MinimumFileVersion 的 MaximumFileVersion：对于“允许”规则，允许运行版本 小于或等于 指定版本的文件。 对于“拒绝规则”，将阻止版本 大于或等于 指定版本的文件。

使用的文件规则级别示例

例如，假设某个部门运行多个服务器的 IT 专业人员。 他们只想运行由提供其硬件、操作系统、防病毒和其他重要软件的公司签名的软件。 他们知道其服务器也运行内部编写的应用程序，该应用程序未签名，但很少更新。 他们希望允许此应用程序运行。

为了创建应用控制策略，他们在标准硬件上生成一个引用服务器，并安装其服务器已知可运行的所有软件。 然后，他们运行 New-CIPolicy 与 -Level Publisher（允许来自其软件提供商（即“发布者”）的软件）以及 -Fallback Hash（允许内部未签名的应用程序）。 他们在审核模式下部署策略，以确定强制执行策略的潜在影响。 在审核数据的帮助下，他们更新其应用控制策略，以包括要运行的任何其他软件。 然后，在强制模式下为其服务器启用应用控制策略。

作为正常操作的一部分，他们最终将安装软件更新，或者可能添加来自同一软件提供商的软件。 由于“发布者”在这些更新和软件上保持不变，因此它们不需要更新其应用控制策略。 如果更新了未签名的内部应用程序，则它们还必须更新应用控制策略以允许新版本。

文件规则优先顺序

应用控件具有可转换为优先顺序的内置文件规则冲突逻辑。 它首先处理找到的所有显式拒绝规则。 然后，它会处理任何显式允许规则。 如果不存在拒绝或允许规则，应用控制会检查 托管安装程序声明 （如果策略允许）。 最后，如果策略允许，应用控制会回退到 ISG 。

注意

为了更轻松地对应用控制策略进行推理，我们建议在支持 多个应用控制策略的 Windows 版本上维护单独的 ALLOW 和 DENY 策略。

将 -SpecificFileNameLevel 与 FileName、FilePublisher 或 WHQLFilePublisher 级别规则配合使用

默认情况下，FileName、FilePublisher 和 WHQLFilePublisher 规则级别使用文件的资源标头中的 OriginalFileName 属性。 可以通过设置 -SpecificFileNameLevel 为规则使用备用资源标头属性。 例如，软件开发人员可能会对属于应用的所有二进制文件使用相同的 ProductName。 使用 -SpecificFileNameLevel，可以创建一个规则来涵盖策略中的所有二进制文件，而不是每个文件的单个规则。

表 3 介绍了可以使用 -SpecificFileNameLevel 设置的可用资源标头属性选项。

表 3. -SpecificFileNameLevel 选项

SpecificFileNameLevel 值 描述
FileDescription 指定二进制文件的开发人员提供的文件说明。
InternalName 指定二进制文件的内部名称。
OriginalFileName 指定二进制文件的原始文件名或首次创建文件时使用的名称。
PackageFamilyName 指定二进制文件的包系列名称。 包系列名称由两部分组成：文件名和发布者 ID。
ProductName 指定二进制文件随附的产品的名称。
Filepath 指定二进制文件的文件路径。

有关文件路径规则的详细信息

文件路径规则不提供与显式签名者规则相同的安全保证，因为它们基于可变访问权限。 文件路径规则最适合大多数用户以标准而不是管理员身份运行的环境。路径规则最适合允许希望保持管理员可写性的路径。 你可能想要避免标准用户可以修改文件夹上的 ACL 的目录的路径规则。

用户可写文件路径

默认情况下，应用控制在运行时执行用户可写性检查，确保对指定文件路径的当前权限仅允许管理员用户的写入访问权限。

应用控制可识别为管理员的已定义 SID 列表。 如果文件路径允许不在此列表中的任何 SID 的写入权限，则即使 SID 与自定义管理员用户关联，文件路径也被视为用户可写。 若要处理这些特殊情况，可以使用前面所述的 Disabled：Runtime FilePath 规则保护选项替代应用控件的运行时管理员可写检查。

应用控件的已知管理员 SID 列表包括：

S-1-3-0;S-1-5-18;S-1-5-19;S-1-5-20;S-1-5-32-544;S-1-5-32-549;S-1-5-32-550;S-1-5-32-551;S-1-5-32-577;S-1-5-32-559;S-1-5-32-568;S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394;S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523。

使用 New-CIPolicy 生成文件路径规则时，将针对扫描路径 () 发现的每个文件生成唯一的完全限定路径规则。 若要创建允许指定文件夹路径下的所有文件的规则，请使用 New-CIPolicyRule ，使用 -FilePathRules 开关定义包含通配符的规则。

在应用控件文件路径规则中使用通配符

可以在应用控制文件路径规则中使用以下通配符：

通配符 含义 支持的操作系统
* 匹配零个或多个字符。 Windows 11、Windows 10和 Windows Server 2022
? 匹配单个字符。 仅限Windows 11

当确切的音量可能有所不同时，还可以使用以下宏： %OSDRIVE%、 %WINDIR%、 %SYSTEM32%。 这些宏可与上述通配符结合使用。

注意

在Windows 11，可以在文件路径规则中的任何位置使用一个或多个通配符。

在所有其他 Windows 和 Windows Server 版本上，每个路径规则 只允许一个 通配符 ，并且该通配符必须位于路径规则的开头或末尾。

使用通配符的示例文件路径规则

示例 描述 支持的操作系统
C：\Windows\*
D：\EnterpriseApps\MyApp\*
%OSDRIVE%\Windows\*		 放置在路径末尾的通配符以递归方式授权直接路径及其子目录中的所有文件。 Windows 11、Windows 10和 Windows Server 2022
*\bar.exe 放置在路径开头的通配符允许在任何位置使用确切的指定文件名。 Windows 11、Windows 10和 Windows Server 2022
C：\*\CCMCACHE\*\7z????-x64.exe
%OSDRIVE%\*\CCMCACHE\*\7z????-x64.exe		 路径中间使用的通配符允许与该模式匹配的所有文件。 请仔细考虑所有可能的匹配项，尤其是在策略使用 Disabled：Runtime FilePath 规则保护选项禁用管理员可写检查时。 在此示例中，这两个假设路径将匹配：
C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe
C:\USERS\AppControlUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe		 仅限Windows 11

如果没有通配符，文件路径规则仅允许特定文件 (例如。 C:\foo\bar.exe) 。

注意

使用 Configuration Manager 创作应用控制策略时，可以选择为指定的文件和文件夹创建规则。 这些规则 不是 应用控制文件路径规则。 相反，Configuration Manager对指定的文件和文件夹执行一次性扫描，并为扫描时在这些位置找到的任何二进制文件生成规则。 除非重新应用Configuration Manager策略，否则不允许在该扫描之后对指定的文件和文件夹进行文件更改。

有关哈希的详细信息

应用控件在计算文件的哈希时使用 Authenticode/PE 图像哈希算法 。 与更常见的 平面文件哈希不同，Authenticode 哈希计算省略了文件的校验和、证书表和属性证书表。 因此，当更改文件的签名和时间戳或从文件中删除数字签名时，文件的 Authenticode 哈希不会更改。 在 Authenticode 哈希的帮助下，应用控制增加了安全性，减少了管理开销，因此在更新文件时，客户无需修改策略哈希规则。

可以计算数字签名和未签名文件的 Authenticode/PE 图像哈希。

为什么扫描为每个 XML 文件创建四个哈希规则？

PowerShell cmdlet 生成 Authenticode Sha1 哈希、Sha256 哈希、Sha1 页哈希、Sha256 页哈希。 在验证期间，应用控制根据文件的签名方式和使用该文件的方案选择计算的哈希。 例如，如果文件是页哈希签名的，则应用控件会验证文件的每一页，并避免将整个文件加载到内存中以计算完整的 sha256 验证码哈希。

在 cmdlet 中，我们预先计算并使用第一页) (sha1/sha2 验证码和 sha1/sha2 的四个哈希，而不是尝试预测将使用哪些哈希。 此方法还可以对文件签名方式的更改进行复原，因为应用控制策略已有多个可用于该文件的哈希。

为什么扫描会为某些文件创建八个哈希规则？

为 UMCI 和 KMCI 创建单独的规则。 如果 cmdlet 无法确定文件是否仅在用户模式或内核中运行，则会为这两种签名方案创建规则，这是出于大量谨慎。 如果知道特定文件仅在用户模式或内核中加载，则可以安全地删除额外的规则。

应用控件何时使用平面文件哈希值？

在极少数情况下，文件的格式不符合 Authenticode 规范，因此应用控制会回退到使用平面文件哈希。 出现此行为的原因有很多，例如在运行时对文件的内存中版本进行了更改。 在这种情况下，你将看到相关 3089 签名信息事件中显示的哈希与 3076/3077 块事件中的平面文件哈希匹配。 若要为格式无效的文件创建规则，可以使用应用控制向导或直接编辑策略 XML，将哈希规则添加到平面文件哈希的策略。