Windows 管理

Windows Vista 中的 ActiveX 安装程序服务

Rob Campbell and Joel Yoker

概览:

• ActiveX 控件的常见难题
• 如何安装 ActiveX 控件
• 危险的权限
• Windows Vista 中更安全的处理

道理总是相同的。要想大幅度增强安全性，就必须放弃某些自由度或灵活性。如果您的环境与多数组织机构类似，就会有努力强化桌面操作系统的强烈愿望，以便

为您的最终用户提供更加安全的计算环境。IT 管理员执行保护台式计算机的任务通常依靠综合运用安全策略设置、用户权限、文件和注册表访问控制列表 (ACL) 以及系统服务限制。

部署安全台式机环境的一个常见障碍是，如何缓解恶意 ActiveX® 控件相关的威胁，同时仍在您的环境中提供适当级别的应用程序兼容性。这是一个困扰桌面操作系统多年的难题。幸运的是，Windows Vista™ 中新的 ActiveX 控件安装程序服务 (AxIS) 消除了公司环境中管理 ActiveX 控件的顾虑。AxIS 为标准用户提供了一种简单可控的方式，从经许可的网站安装 ActiveX 控件，通常情况下这些用户是不允许安装 ActiveX 控件的。AxIS 上的组策略控制允许 IT 管理员决定用户可安装哪些控件，而不管用户具有哪些权限。

在本文中，我们将了解围绕 ActiveX 控件的管理难题、这些难题在以前版本的 Windows® 中是如何解决的，以及 Windows Vista 中的 AxIS 如何提供独特而有效的方式来管理 ActiveX 控件的安装。

什么是 ActiveX 控件？

ActiveX 控件是用户通过 Internet Explorer® 安装和调用的一小段可执行代码（通常是打包在压缩文件内的 OCX 文件）。Web 开发人员创建 ActiveX 控件是为了向他们的 Web 应用程序中添加功能，而这些功能用标准的 HTML 或简单的脚本是无法轻易实现的。

ActiveX 控件的一个主要特性是其简单的“下载并执行”部署模型。ActiveX 控件通过 HTML object 标记完成安装和调用，该标记有一个名为 CODEBASE 的属性，如果用户的计算机上尚未安装此控件，该属性会通知 Internet Explorer（用 URL）到哪里获得此控件。在这种情况下，Internet Explorer 下载相关的安装程序包，执行对象的信任验证，并通过 Internet Explorer 信息栏提示用户所需的安装权限（如图 1 所示）。安装过程中，控件通过呈现页面进行注册和调用。安装后，任何标准用户都可调用此控件。这种简单的分发和执行机制意味着开发人员可以用一种便捷的方式向他们的 Web 应用程序用户分发其组件。这种分发方法的问题是标准用户不能直接安装 ActiveX 控件，因为必须具有管理权限才能完成安装。

图 1** ActiveX 控件安装信息栏 **

当 ActiveX 控件在 Internet Explorer 4.0 中首次引入时，Internet 似乎还是一个非常友好的环境。如今，通过 Web 分发的可执行代码可能代表严重的威胁，所以 Windows 只允许具有本地管理员权限的用户安装 ActiveX 控件，而且安装还必须按照策略设置获得批准。在管理员安装了 ActiveX 控件后，系统中任何用户都可以调用此控件。这种行为通过 Windows 中的一组文件和注册表 ACL 来协助实现。虽然这种方法可阻止标准用户安装 ActiveX 控件，但并没有减轻安装这些控件的本地管理员和标准用户（具有已修改的默认权限）的风险。

Windows 中的默认保护只允许具有管理权限的用户执行安装，在个人层面上解决了 ActiveX 控件问题，但它没有解决如何在整个大型组织机构内管理这些控件的问题。公司环境中的一个常见难题是如何准许使用 IT 机构信任的 ActiveX 控件，同时缓解外部不受信任的控件所带来的潜在威胁。最后，安装某个特定 ActiveX 控件的决定权通常留给了个人用户，这取决于用户的权限，而与控件的好坏无关。为了消除威胁，一些组织机构阻止所有的 ActiveX 控件，另一些组织机构虽允许最终用户安装，但试图控制任何安装的恶意软件。

阻止安装不良控件的另一种方法是对标准用户实施受限制的权限，让 IT 管理员在台式机平台上预先安装所有必需的控件。如果当前所用的 ActiveX 控件具有相对静态的特性，使用与台式机更新相结合的预定发布过程进行修改，或者使用系统管理服务器等软件分发机制，那么这种方法会十分有效。然而，持续管理、内部应用程序开发人员随时更改需求和对外部控件的依赖将继续成为这些方法的障碍。

在用户具有管理权限的情况下，问题就不同了；它涉及阻止这些用户安装未经许可的控件。在这种情况下，因为用户具有管理权限，因此假定最终用户具有安装 ActiveX 控件的权限。（注意，让最终用户担当本地管理员对组织机构意味着高风险，对于多数公司环境来说，不推荐这种做法。）

一个解决方案是，让一台内部 Internet 组件下载服务器承载经批准的控件。该解决方案需要修改客户端注册表中的 CodeBaseSearchPath 字符串。正常情况下，当请求的 HTML 页面中发现含有 CODEBASE 属性的对象标记时，Windows 客户端会指向 CodeBaseSearchPath 数据中指定的位置。默认情况下，该注册表字符串包含 CODEBASE 关键字和 ActiveX 控件库的 Internet URL。要实施 Internet 组件下载服务器，您需要将 CodeBaseSearchPath 中的默认数据替换为内部服务器的 URL，您的组织机构批准的控件将驻留在这台内部服务器上。与前面的方法相似，该解决方案需要持续管理，并需承担 ActiveX 控件的内部服务器的承载成本和复杂性。

还有其他的解决方案，比如修改 Internet Explorer 的 URLActions 区域、通过组策略指定管理员批准的控件，以及通过防火墙规则在外围阻止安装所有控件。但是，正如您看到的那样，所有这些方法都存在自身的问题，许多方法由于缺乏灵活性而最终被放弃。更糟的是，这些解决方案中有些依然要求用户具有管理权限。最后，这些修改试图解决部分问题，如控制（或阻止）ActiveX 控件的来源位置、调用位置等；但是，这些解决方案并未缓解没有管理员权限的用户不能安装 ActiveX 控件的基本问题。

AxIS 能为您做什么？

Windows Vista 中的 AxIS 允许公司管理员采用默认的文件系统设置让用户担当标准用户，在维持强健的安全状态的同时对 ActiveX 控件进行管理。AxIS 提供配置 ActiveX 控件受信任来源的组策略选项，以及代表标准用户从那些受信任来源安装控件的代理进程。主要好处是，您可以在用户工作站上保持一种非管理的安全状态，并且享有集中的管理控制。AxIS 依靠 IT 管理员确定 ActiveX 控件的受信任来源（通常为 Internet 或 intranet URL）。当一个对象标记指示 Internet Explorer 调用一个控件时，AxIS 采取下列步骤：

1. 检查控件是否已安装。如果未安装，则必须先安装后才能使用。
2. 检查 AxIS 策略设置，验证控件是否来自受信任的来源。这项特定的检查用策略中指定的受信任位置与对象标记的 CODEBASE 属性中指定的 URL 的主机名进行比照。
3. 代表用户下载和安装控件。

如果源 URL 的主机名未在 AxIS 策略设置中列出，就会激活常规用户帐户控制 (UAC) 提示，要求管理权限才能完成安装。此外，AxIS 还会在应用程序事件日志中用 ID 4097 记录一个来源 AxInstallService 的事件，描述未成功的 ActiveX 控件安装，以及控件特定的下载路径。4097 事件的一个示例如图 2 所示。公司管理员可使用该事件日志条目中的数据修改组策略，允许此后访问该网站时 AxIS 安装该控件。

图 2** 4097 AxInstallService 事件 **

AxIS 是 Windows Vista Business、Enterprise 和 Ultimate SKU 附带的可选组件，可通过无人参与选项或通过“控制面板”对话框（“程序”|“程序和功能”|“打开或关闭 Windows 功能”）启用，如图 3 所示。一旦启用，AxIS 就会在每次 Internet Explorer 请求控件时执行上述步骤。

图 3** 在控制面板中启用 AxIS **

Windows Vista 中向事件附加任务的功能为管理员提供了一种从 AxIS 服务接收通知的简便方式，比如，当安装某一 ActiveX 控件被阻止时。特别要注意的是，不能假定安装 ActiveX 控件的 URL 主机名永远与最终用户从其网站访问的主机名相同。因此，AxInstallService 4097（未遂安装）事件提供的信息对于确定试图安装的控件所来自的主机显得极为有用。

使用从该事件中获得的信息，您可以在组策略中配置受信任的位置。本地或组策略中的 AxIS 设置位于“计算机配置”设置中（如图 4 所示）。您可以在“ActiveX 控件的批准安装站点”策略设置中指定受信任位置的主机 URL（参见图 5）。已批准站点设置需要两项信息，即安装 ActiveX 控件的来源位置和安装行为。

图 4** “组策略对象编辑器”中的设置 **

图 5** AxIS 批准的安装站点 **

首先，如前面所述，需要一个主机 URL 来表明控件的受信任位置。与前面解决方案不同的是，前面的办法需要知道控件的 CLSID（当开发人员修订控件时常常发生变化），而 AxIS 允许从受信任的位置安装任何控件，从而减少总体管理负担。第二项信息是一串用逗号分隔的四个值，分别规定了 ActiveX 控件下载过程中的行为。这些值指定了四个属性：TPSSignedControl、SignedControl、UnsignedControl 和 ServerCertificatePolicy。前两个属性（TPSSignedControl 和 SignedControl）可从以下三个值中任取其一：0、1 或 2。这些值类似于 URLAction 设置中的值。值 0 阻止安装控件，值 1 的作用是提示用户安装所需的权限，值 2 的作用是以静默方式代表用户安装控件。未签名的控件不能以静默方式安装，因此 UnsignedControl 的值只能为 0 或 1。注意：如果未指定策略，将使用默认值 2、1 和 0。

最后一个属性根据已签名设置控件的证书设置来指定安装行为。与多数 SSL 站点类似，证书必须通过一系列安全测试才能确认其有效性。无效的证书属性在实际实施已签名 ActiveX 控件的过程中有时确实存在。通过其配置，AxIS 允许管理员根据具体的 URL 忽略证书中有时出现的无效信息。最后一个属性表示为位掩码的值组合形式，如图 6 所示。

Figure 6 ServerCertificatePolicy

默认设置为 0，表示 AxIS 完成安装前必须通过所有的安全检查。主机设置和这四个值的组合均在策略设置中指定，如图 7 所示。

图 7** 经批准的 AxIS 主机 URL **

结束语

AxIS 允许您配置组策略，以控制用户能够安装的 ActiveX 控件，而无需管理权限或复杂的配置。在早期版本的 Windows 中，此级别的控制颇具挑战性，以前采取的解决方案通常具有严格的限制或增加了管理开销。AxIS 为各组织机构提供了另一类工具，采取一种台式机系统上最终用户权限的最小权限法，从而实现了最终用户不需要管理权限的标准用户模型。Windows Vista 使 IT 管理员可以选择公司环境中受信任的 ActiveX 控件，这种选择是由组织机构而非最终用户决定的，从而把控制权重新交回 IT 管理员手中。

Rob Campbell是 Microsoft Federal 团队的高级技术专家。Rob 专注于为美国联邦政府客户开发和部署安全解决方案。

Joel Yoker是 Microsoft Federal 团队的高级顾问。Joel 专注于为美国联邦政府客户开发和部署安全解决方案。

© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.