摘要
Ivanti Application Control 使用可信所有权，这是一种基于来源的模型，它根据软件如何进入系统来控制执行，而不是管理允许或阻止文件的列表。
可信所有权方法通过将同样的基于来源的执行控制应用于完整执行链，为可执行文件、DLL、脚本和 MSI 包提供广泛覆盖，并默认阻止用户引入的内容。
与 AppLocker 等传统允许列表方法相比，可信所有权可降低运营开销，同时针对在不当上下文中使用合法工具的现代攻击提供更出色的保护。
应用程序控制是一个安全主题，许多人仍持有旧有认知。传统允许列表看似安全，但很快会成为维护负担。阻止列表则显得被动且不完整。尽管 Microsoft AppLocker 等工具让许多人认为严格的允许列表是黄金标准，但现代攻击已经证明并非如此。攻击者越来越多地依赖合法且经过签名的工具——在错误的上下文中使用——从而完全绕过基于列表的控制。
因此，当组织评估Ivanti Application Control或Ivanti Neurons for App Control并接触到可信所有权时，它最初可能会因为支持显式阻止而看起来像阻止列表。实际上，可信所有权是一种范围更广、运营负担更轻的来源驱动执行模型，它根据来源而不仅仅是身份来控制执行。
它不需要管理不断扩展的列表，而是基于是谁将软件放置到系统上来实施安全控制，并与现代软件分发实践和零信任原则高度契合。它最好不要被理解为另一种列表机制，而应被视为一种来源驱动的执行模型：根据来源而不仅仅是身份来控制执行。
这种思维转变引出了现代应用程序控制中更关键的问题：不仅要关注文件是什么，还要关注它是如何进入系统的。
超越列表：为什么来源控制如今至关重要
文件如何进入系统，是来源控制的核心问题。来源控制不会仅依据发布者、路径或哈希来信任文件，而是评估引入这些文件的来源和流程。是谁将文件写入磁盘？通过什么机制？安装是否遵循了受控的 IT 工作流？这种评估将应用程序控制从对象信任转向流程信任，从而建立更强的安全边界。
在 Ivanti Application Control 中，来源控制通过可信所有权来实现。由可信所有者放置的任何文件都会被允许；由用户引入的任何内容默认都会被拒绝。这一机制一致适用于可执行文件、DLL、安装程序和脚本。由于 SYSTEM、TrustedInstaller 和 Administrators 等身份默认受信任，通过 MS Intune、MECM、Ivanti Endpoint Manager (EPM) 或其他企业工具等标准部署渠道交付的软件可立即运行，无需维护规则或创建例外。
这与传统允许列表形成了根本区别。AppLocker 规则的成败取决于精确的发布者、路径或哈希定义。它不会评估安装来源，也不会自动信任您的部署机制。通过 Intune 交付的软件仍需要预先存在的允许规则，通常依赖宽泛的默认设置来允许 Program Files 或 Windows 目录。
这一区别非常重要，因为现代攻击越来越多地在不恰当的上下文中武器化合法工具。来源控制通过对软件如何进入系统，而不只是对它是什么建立信任，来消除其中大部分风险。它符合零信任原则，降低供应链暴露面，并默认大幅减少利用系统自带工具（Living off the Land，LotL）进行滥用的机会。
一旦理解了来源的重要性，下一个问题就是：如何大规模实施？
答案是：在软件执行和交付的所有方式中一致应用来源控制。
超越阻止列表：面向现代软件部署构建的广泛覆盖
来源控制将应用程序安全从管理无穷无尽的列表，转向验证软件进入系统的流程。一旦采用这一视角，就会很清楚：可信所有权并不是一种阻止列表方法。它是基于来源的信任边界，其运行方式与传统允许列表截然不同。
一个常见误解是，可信所有权类似于阻止列表，因为管理员有时会为知名 Windows 工具添加有针对性的拒绝规则。实际上，这些拒绝规则是用于防御利用系统自带工具技术的强化措施。任何严肃的应用程序控制方法都会使用此类定向限制。可信所有权的核心恰恰与阻止列表相反：通过受控且可信流程交付的软件默认允许，而用户引入的内容默认拒绝。
更重要的差异在于覆盖范围。许多依赖传统允许列表的组织最终几乎只关注可执行文件。他们往往避免将同样的执行控制应用于 DLL、脚本和 MSI 包，因为这些文件类型会使规则维护复杂得多。这就形成了现代攻击者经常利用的缺口。
可信所有权通过将同样的基于来源的执行控制应用于完整执行链来避免这些缺口。可执行文件、DLL、脚本、MSI 安装程序和相关组件都通过同一信任模型进行评估。由于信任取决于是谁引入了文件，您不需要为每种文件类型制定单独策略。位于 Downloads 文件夹中的脚本、在临时构建目录中创建的 DLL，或从用户配置文件执行的 EXE，只要其来源不属于受控安装流程，就都会受到相同的默认拒绝处理。
这一信任模型也与现代端点管理平台交付软件的方式自然契合。Intune、MECM、Ivanti Neurons for MDM、Ivanti Endpoint Manager等解决方案以及类似系统通常使用 SYSTEM 身份或其他可信服务帐户来安装应用程序。
由于这些身份已经是可信所有者，通过这些渠道部署的软件无需创建允许规则、维护文件路径或更新策略即可立即运行。只有在您有意使用替代安装帐户时，例如自定义 DevOps 代理或在用户上下文中执行的脚本安装，才需要将该身份标识为可信所有者。
最终形成的是一种能够广泛且一致覆盖所有相关文件类型的模型。它可与现代软件分发无缝配合，并避免了以可执行文件为主要关注点的传统允许列表所带来的运营开销。
可信所有权信任的不是单个对象，而是软件交付所经过的受控流程，从而打造出更具可扩展性且更安全的应用程序控制方法。
WDAC（App Control for Business）的定位
Microsoft 维护着两项应用程序控制技术：AppLocker 和 App Control for Business（原 WDAC）。尽管两者仍然存在，但 Microsoft 已明确其各自角色。AppLocker 可帮助阻止用户运行未经批准的应用程序，但它不符合现代安全功能的服务标准，因此被归类为一种纵深防御机制，而非战略性安全控制。
Microsoft 在应用程序控制方面的前进方向是 App Control for Business，并明确表示 AppLocker 已功能完备，除必要的安全更新外，不再处于积极开发状态。这意味着所有新功能只会交付到 WDAC，而不会交付到 AppLocker。
App Control for Business 引入了托管安装程序概念。这使 Windows 能够自动信任通过 Intune 或 MECM 等指定部署平台安装的应用程序。信任来源于分发渠道，而不是单个文件，从而显著减少规则维护工作。
这与 Ivanti Application Control 的可信所有权模型高度一致。两种方法都基于安装软件的受控流程来信任软件，而不是基于离散的文件属性。不过，可信所有权以更简单、更易于运营落地的方式应用这一概念。Ivanti 信任 SYSTEM 和指定服务帐户等身份，而不需要复杂的策略层、XML 定义或深入的 WDAC 专业知识。
Ivanti 从许多组织了解到，他们在 WDAC 的运营落地方面面临挑战。WDAC 策略需要谨慎设计、在审核模式下进行长时间测试、管理驱动程序和内核例外，并持续维护多个策略集。这常常导致组织将 WDAC 与 AppLocker 结合使用，以同时覆盖低级别执行控制和日常用户空间控制，最终带来管理开销。
Ivanti Application Control 提供了一种统一的替代方案。通过可信所有权、可信供应商和数字签名验证，它交付了一种基于来源的默认拒绝模型，并在可执行文件、DLL、脚本和 MSI 包之间提供一致覆盖。
组织无需维护两个范围不同的 Microsoft 控制平面，而是管理一项精简的单一策略，根据软件进入系统的方式来实施信任。这能够实现客户尝试通过 WDAC 与 AppLocker 组合部署所达成的许多实际目标，同时降低运营复杂性，并提供一个统一的信任模型。
LOLBins 与参数级控制
在建立广泛覆盖之后，接下来的问题就是如何处理每台计算机上已存在、且攻击者喜欢滥用的合法工具。
现代攻击者通常会避免使用传统恶意软件，而是依赖每台 Windows 设备上已经存在的工具。这些利用系统自带工具（LOLBins）是合法的，也是正常运行所必需的，因此很难在不影响生产力的情况下阻止它们。传统允许列表在这里面临困境：宽泛阻止会破坏工作流，而宽泛允许又会留下危险缺口。
像可信所有权这样的基于来源的模型改变了这一局面。即使攻击者试图使用内置工具，他们尝试运行的内容通常也并非来自可信安装流程。由于 Ivanti 会评估该内容的来源，大多数滥用尝试会自动失败。工具本身可能是合法的，但它被要求运行的内容并不可信，可信所有权会在其执行前将其阻止。
同样重要的是，不仅要了解哪些工具在运行，还要了解它们被要求执行什么操作。许多解释器和运行时，例如 PowerShell、Python 或 Java，在一种上下文中可能完全安全，在另一种上下文中则可能存在风险。业务应用程序可能依赖 Java 启动特定且已获批准的流程，而用户下载的 JAR 文件则是完全不同的场景。
Ivanti 通过分层方法处理这一问题。首先使用可信所有权评估 JAR 文件；如果它是由用户引入，而不是通过受控部署流程引入的，就会立即被阻止。在此基础上，管理员可以创建简单的允许规则，精确指定哪些 Java 命令可以运行，确保只有合法的基于 Java 的应用程序能够运行，同时悄然拒绝启动未经批准的 JAR 文件的尝试。
同样的原则也适用于其他工具。策略可以批准组织所需的精确行为，同时阻止超出这些边界的活动。这避免了宽泛而脆弱的规则，并确保日常工作顺畅运行。
其结果是一种平衡且现代的方法。可信所有权默认阻止不可信内容。有针对性的强化措施符合政府和社区关于减少利用系统自带工具滥用的最佳实践，而具备意图感知能力的控制可确保合法流程持续运行，同时不会为攻击者打开通道。
这种方法与当前社区和政府关于缓解利用系统自带工具技术的指南高度一致。CISA、NSA、FBI 以及澳大利亚网络安全中心等机构强调，应通过控制内置工具的使用方式，并限制其处理的不可信内容，来减少攻击者利用这些工具的机会。其联合指南指出，LOTL 攻击依赖于滥用原生工具，并强调需要通过控制措施限制这种滥用，同时不阻止合法的系统进程。
Ivanti 的模型体现了这一指南。可信所有权会自动阻止攻击者所依赖的不可信内容，同时通过少量有针对性的限制来处理少数需要额外关注的工具。
可信所有权实践：真实场景
以下是几个运营示例，展示 Ivanti Application Control 和可信所有权在实践中的工作方式。
- 便携式应用程序被复制到用户配置文件中。Ivanti 会阻止它，因为它归用户所有。AppLocker 只有在存在匹配规则时才会阻止。如果没有正确的路径或发布者规则，行为可能会有所不同。
- 电子邮件附件从 Downloads 文件夹启动 PowerShell 脚本。Ivanti 会因用户所有权而拒绝该操作。AppLocker 依赖脚本规则，并且在发生阻止事件时会强制 PowerShell 进入受限语言模式，但该脚本仍会运行。
- 滥用 rundll32 或 mshta 等操作系统工具。两种模型都需要有针对性的拒绝强化。Ivanti 将其与来源控制相结合，通常可以减少所需例外的数量。AppLocker 依赖精选的拒绝集，并需要定期调优。
- 供应商更新交付新的已签名文件。当更新通过可信部署渠道到达时，Ivanti 会因可信所有权而允许该更新。AppLocker 可以通过发布者规则适配这一情况，但签名在多个产品之间复用或安装路径异常，往往会导致额外维护，并带来超出预期的更宽泛信任。
- 用户下载 JAR 并尝试使用 Java 运行。Ivanti 会阻止该尝试，因为该 JAR 是由用户引入的，未通过可信所有权验证。如有需要，管理员可以通过匹配完整命令行，仅允许精确的已批准调用。AppLocker 无法匹配参数，只能依赖发布者、路径或哈希规则。
结论
来源控制将应用程序控制从管理问题转变为信任模型。它信任的不是单个文件，而是软件进入系统所经过的流程，从而让安全既可扩展又可运营。
可信所有权正是这一方法的体现。它既不是阻止列表，也不是传统允许列表，而是一种模型：通过受控 IT 流程进入的软件默认允许，而该流程之外的一切内容默认拒绝。通过基于来源和所有权而非临时文件实施控制，Ivanti Application Control和Ivanti Neurons for App Control能够更好地应对现代攻击技术，并契合当今的软件分发方式。
如果您继续将应用程序控制视为列表管理工作，就会感受到管理负担。如果将其视为信任边界，就能获得可扩展性、安全性和运营可行性。
常见问题解答
什么是 Ivanti Application Control？
Ivanti Application Control 将动态允许和拒绝列表与权限管理相结合，可防止未经授权的代码执行，同时无需 IT 手动管理大量列表，也不会限制用户。
什么是来源控制？
来源控制是一种安全方法，它通过检查引入文件的来源和流程来评估文件如何进入系统，而不是仅根据发布者、路径或哈希来信任文件。这种方法将应用程序控制从对象信任转向流程信任，从而建立更强的安全边界。
什么是应用程序允许列表？
应用程序允许列表是一种传统安全方法，它根据精确的发布者、路径或哈希定义来控制哪些应用程序可以运行。与基于来源的方法不同，传统允许列表不会评估安装来源，也不会自动信任企业部署机制。
什么是可信所有权？
可信所有权是 Ivanti Application Control 对来源控制的实现方式：由可信所有者（例如 SYSTEM、TrustedInstaller 或 Administrators）放置的任何文件都会被自动允许，而由用户引入的任何内容默认都会被拒绝。这一信任模型一致适用于所有文件类型，包括可执行文件、DLL、安装程序和脚本，使通过标准企业部署渠道交付的软件能够立即运行，无需维护规则。
