 TechNet Magazine June 2007

TechNet Magazine June 2007

安全性: 深入了解 Windows Vista 用户帐户控制

用户帐户控制 (UAC) 是 Windows Vista 中最令人误解的新功能之一。但是它的目标 — 使用户能够以标准用户权限运行 — 可以解决许多安全问题。下面我们将深入了解 UAC 旨在解决的问题，以及这一新功能的具体工作方式。

Mark Russinovich 安全性: 使用 BitLocker 驱动器加密以保护数据的密钥

BitLocker 起着两个相当重要的作用：它同时提供了整卷数据加密，以及在 Windows Vista 启动之前验证早期启动组件完整性的方法。大致了解 BitLocker 的工作原理，并了解它如何帮助您保护您的组织。

Byron Hynes 安全性: Windows 防火墙探究

移动性已经改变了计算机所受到的威胁以及用来保护它们的技术。当便携式计算机游离到外围网络之外、又回到网络之后，您需要更好的方式来保护您的系统。了解如何使用 Windows 防火墙保护您的计算机 — 在 Internet 和在您自己的内部网络中。

Steve Riley 安全性: 新 ACL 改进 Windows Vista 的安全性

虽然 ACL 未发生重大变革，其中仍有许多重要变化，您在 Windows Vista 环境中管理 ACL 时需要对其加以了解。发现 30 个 ACL 如何得到改进而提高安全性，了解它们将如何影响您的组织，以及学会如何管理在基础结构中发生的这些变化。

Jesper Johansson 安全性: 通过组策略管理硬件限制

拇指 U 盘和其他可移动设备可使您的个人生活更方便，但会给工作环境带来隐患。为提高安全性，您需要通过某种方式控制用户在其工作系统中安装的硬件设备。现在，您可以使用组策略来控制用户可以使用以及不可以使用的设备。

Jeremy Moskowitz 安全性: 每个 IT 组织都必须具备的 4 项安全技术

大多数企业都面临类似的安全问题。在今天的互联世界里，通常有四种类型的安全工具是每个组织都必须具备的。我们来看看它们是哪些工具，以及如何在未来将所涉及的这些技术融合在一起以创建理想的安全解决方案。

Matt Clapham and Todd Thompson 安全性: 用于证书管理的强大新工具

证书是基础结构中的关键组件 — 当证书过期时，生产力便会停止。如果您依赖于 Microsoft PKI 环境，则全新的 Identity Lifecycle Manager Certificate Management (ILM-CM) 解决方案能够帮助您保持一切顺利运行。您将了解此工具如何帮助您改进身份验证过程，并降低证书管理成本。

Kevin Dallmann 编辑视角: 安全问题

Joshua Trupin 工具箱: 面向 IT 专业人员的新产品

Greg Steen SQL 问题解答: 64 位安装、分配群集内存及其他

Edited by Nancy Michell 实用工具特别推荐: Windows Vista 的脚本提升 PowerToy

尽管用户帐户控制在安全性方面提供了重要改进，但能够提升权限对于执行特定管理任务和功能也变得至关重要。下面是若干提升 PowerToys，可使提升行为更加灵活和强大。

Michael Murgolo 网络专家: 安全套接字隧道协议

Windows XP 和 Windows Server 2003 中的 VPN 协议不适用于某些配置。深入探讨各种问题，并了解 Windows Server“Longhorn”和带有 Service Pack 1 的 Windows Vista 如何使用“安全套接字隧道协议”解决这些问题。

Joseph Davies Windows Powershell: 使用 Active Directory

Windows PowerShell 并未提供一个 Get-ADSIObject cmdlet，但这并不妨碍它提供强大的 ADSI 支持。本文简单介绍了类型适配器，并阐述了如何使用 Windows PowerShell 来处理目录对象。

Don Jones 您好，脚本专家！: 用脚本消除不正确标记的红线

您是否期待有一种更为简单的方法向 Microsoft Word 词典添加词条，而不必一一手动输入？有谁不想呢？本月，脚本专家将向您展示如何在 Microsoft Word 中创建自定义词典，以及如何以编程方式配置 Word 来使用这些词典。

The Microsoft Scripting Guys 桌面文件: 如何做到不丢失数据

重要数据丢失的频率简直令人吃惊。但事实上，信息之所以丢失是因为人们没有保护好它。本文将探讨为保证组织数据的安全，您能够且必须要采取的重要步骤。

Wes Miller 领域备注: 与开发人员交谈

让开发人员构建更易于管理的应用程序要比想象中简单。一切从沟通开始。开发人员看软件的角度与管理员不同。但是通过与开发人员交谈，管理员可以解释对他们来说重要的是什么，由此开发人员可以相应地将代码的设计工作做得更好。

David Aiken Windows 机密: 新用户在“开始”菜单中看到的内容

想象一下，买了新电脑，装上 Windows，单击“开始”按钮，看到一个空菜单。之所以“开始”菜单在您开始使用之前，在最常用的位置包含了应用程序，目的是为了提供一个良好的初次使用体验。了解这些应用程序是如何被选中的。

Raymond Chen 读者来信: 有问必答


 安全性: 深入了解 Windows Vista 用户帐户控制
安全性 Mark Russinovich

深入了解 Windows Vista 用户帐户控制
概览:
  • 作为标准用户运行
  • 文件和注册表虚拟化
  • 提升帐户状态

Windows Vista 中的用户帐户控制 (UAC) 通常令人感到误解。我在《TechNet 杂志》上就 Windows Vista 的内核变化发表了三篇系列文章（请参阅 technetmagazine.com），但其中未涉及 UAC，因为我觉得应当为其单独写一篇文章。
在本文中，我将探讨 UAC 解决的问题，并说明其组件技术的体系结构和实施。这些技术包括对以前要求管理权限的操作进行重构、可帮助程序在没有管理权限的情况下正确运行的轻型虚拟化、使程序显式请求管理权限的能力，以及将在同一用户桌面上运行的管理流程与非管理流程相隔离。

UAC 的目标
UAC 旨在使用户能够使用标准用户权限（而不是管理权限）运行。管理权限使用户能够读取和修改操作系统的任何部份，包括其他用户的代码和数据 — 甚至是 Windows® 本身。如果没有管理权限，用户不会意外（或有意）修改系统设置，恶意软件无法改变系统安全设置或禁用防病毒软件，用户也不会危及共享计算机上其他用户敏感信息的安全。因此，使用标准用户权限运行可以减少企业环境中紧急咨询台呼叫的次数，减轻恶意软件的影响，使家庭计算机的运行更顺畅，并保护共享计算机上的敏感数据。
要使通过标准用户帐户运行切实可行，UAC 必须要解决几个问题。首先，在 Windows Vista™ 之前，Windows 使用模型一直是某种假定的管理权限。软件开发人员假定他们的程序可以访问和修改任何文件、注册表或操作系统设置。甚至当 Windows NT® 引入了安全性并区分了授予管理用户帐户和标准用户帐户的权限后，仍指导用户完成一个设置过程，使他们能够使用内置的 Administrator 帐户或 Administrators 组的成员帐户。
UAC 必须解决的第二个问题是用户有时需要管理权限来执行某些操作，如安装软件、更改系统时间以及在防火墙中打开端口。
UAC 针对这些问题的解决方案是使用标准用户权限运行大多数应用程序，始终避免对管理员权限的需要，并鼓励软件开发人员创建使用标准用户权限运行的应用程序。UAC 通过以下方式来实现这些方面：减少对管理权限的需求频率，使旧应用程序能够使用标准用户权限运行，使标准用户在需要时能够方便地访问管理权限，甚至使管理用户像标准用户那样运行。

作为标准用户运行
在 Windows Vista 的开发过程中，通过对所有管理操作的全面审核，确定了许多可以为标准用户启用而不会有损系统安全性的操作。例如，即使是为其 Windows XP 桌面系统采用了标准用户帐户的企业也无法从 Administrators 组中删除其移动用户，唯一的原因是 Windows XP 并不区分更改时区与更改系统时间之间的差别。如果便携式计算机用户希望配置本地时区以便旅行时能够在其日历中正确显示预约时间，他们必须具有“更改系统时间”特权（在内部称为 SeSystemTimePrivilege），在默认情况下该特权仅授予管理员。
安全协议（如 Kerberos）中通常会使用时间，但是时区仅影响时间的显示方式，因此 Windows Vista 添加了一个新特权“更改时区”(SeTimeZonePrivilege)，并将其分配给 Users 组，如图 1 所示。这样许多企业便有可能使其便携式计算机用户在标准用户帐户下运行。
图 1 “更改时区”特权
图 1 “更改时区”特权
Windows Vista 还允许标准用户在连接到无线网络时配置 WEP 设置、创建 VPN 连接、更改电源管理设置以及安装重要 Windows 更新。此外，它还引入了“组策略”设置，使标准用户能够安装 IT 管理员批准的打印机和其他设备驱动程序，以及从管理员批准的站点安装 ActiveX® 控件。
对于不能以标准用户帐户正确运行的客户和业务线 (LOB) 应用程序该如何处理？虽然某些软件确实需要管理权限，但许多程序都毫无必要地将用户数据存储在系统全局位置。Microsoft 建议希望使用管理权限来运行的全局应用程序安装程序在 %ProgramFiles% 目录下创建一个目录来存储应用程序的可执行文件和辅助数据，并在 HKEY_LOCAL_MACHINE\Software 下为其应用程序设置创建一个注册表项。当执行某个应用程序时，它可以使用不同的用户帐户运行，因此它应当在针对每个用户的 %AppData% 目录中存储用户特定数据，并在 HKEY_CURRENT_USER\ Software 下的用户注册表配置文件中保存每个用户的设置。标准用户帐户不具备 %ProgramFiles% 目录或 HKEY_LOCAL_MACHINE\Software 的写访问权限，但是因为多数 Windows 系统都是单用户的，并且在 Windows Vista 之前多数用户都是管理员，所以错误地将用户数据和设置保存到这些位置的应用程序仍能工作。
通过文件系统和注册表命名空间虚拟化的帮助，Windows Vista 使这些旧应用程序能够在标准用户帐户下运行。当应用程序修改文件系统或注册表中的系统全局位置并且该操作由于访问被拒绝而失败时，Windows 会将该操作重定向到特定于用户的区域；当应用程序从某个系统全局位置读取时，Windows 将首先检查每个用户区域中的数据，如果数据不存在，则允许从该全局位置进行读取尝试。
针对此虚拟化目的，如果某个进程是 32 位的（与 64 位相对）、不是使用管理权限运行，并且没有指令清单文件表明它是为 Windows Vista 编写的，那么 Windows Vista 会将其视为旧进程。根据此定义，对于任何操作（包括网络文件共享访问），如果它不是源于分类为旧进程的进程，则不会将其虚拟化。进程的虚拟化状态存储为其令牌中的一个标志，它是跟踪进程安全环境的内核数据结构，包括其用户帐户、组成员身份和特权。
您可以通过向“任务管理器”的“进程”页添加“虚拟化”栏来查看进程的虚拟化状态。图 2 显示大多数 Windows Vista 组件（包括桌面窗口管理器 (Dwm .exe)、客户端服务器运行时子系统 (Csrss.exe) 和资源管理器）或者因为它们有 Windows Vista 指令清单而禁用了虚拟化，或者是使用管理权限运行而因此不允许虚拟化。Internet Explorer® (iexplore.exe) 启用了虚拟化，因为它可以承载多个 ActiveX 控件和脚本，并且必须假定它们没有编写为使用标准用户权限即可正确操作。
图 2 “任务管理器”显示虚拟化状态
图 2 “任务管理器”显示虚拟化状态
为旧进程虚拟化的文件系统位置为 %ProgramFiles%、%ProgramData% 和 %SystemRoot%，其中不包括某些特定子目录。但是，任何具有可执行文件扩展名的文件（包括 .exe、.bat、.scr、.vbs 等等）都将从虚拟化中排除。这意味着，使用标准用户帐户进行自我更新的程序将失败，而不会创建对于运行全局更新程序的管理员不可见的专有可执行文件版本。要向排除列表中添加其他扩展名，请在以下注册表项中输入它们并重新启动：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
使用一种多字符串类型来分隔多个扩展名，并且不要在扩展名中包含前导点。
旧进程对虚拟化目录的修改将重定向到用户的虚拟根目录 %LocalAppData%\VirtualStore。例如，如果我的系统上运行的某个虚拟化进程要创建 C:\Windows\Application.ini，那么它实际创建的文件为 C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini。该路径的本地部分表明这样一个事实，即当帐户具有漫游配置文件时，虚拟化文件不会随配置文件的其余部分漫游。
如果在资源管理器中导航到一个包含虚拟化文件的目录，资源管理器将在其工具栏中显示一个标记为“兼容性文件”的按钮，如图 3 所示。单击该按钮可导航至对应的 VirtualStore 子目录以显示虚拟化文件。
图 3 “兼容性文件”按钮指明了附近的虚拟化文件
图 3 “兼容性文件”按钮指明了附近的虚拟化文件
图 4 显示 UAC 文件虚拟化筛选器驱动程序 (%SystemRoot%\System32\Drivers\Luafv.sys) 如何实施文件系统虚拟化。因为它是文件系统筛选器驱动程序，所以它会看到所有文件系统操作，但是仅为来自旧进程的操作实施功能。您可以看到它为在系统全局位置创建文件的旧进程更改了目标文件路径，但是没有为以标准用户权限运行 Windows Vista 应用程序的进程进行此更改。当它确实在用户具有完全访问权限的位置创建了文件时，旧进程便认为操作成功，但在 \Windows 目录上的默认权限会拒绝对为 Windows Vista 编写的应用程序的访问。
图 4 文件系统虚拟化
图 4 文件系统虚拟化
注册表虚拟化的实施与文件系统虚拟化略有不同。虚拟化的注册表项包括 HKEY_LOCAL_MACHINE\Software 分支的大部分，但有许多例外项，例如以下项：
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
只有通常由旧应用程序修改，但不会带来兼容性或互操作性问题的项才能虚拟化。Windows 将旧应用程序对虚拟化项的修改重定向到位于 HKEY_ CURRENT_USER\Software\Classes\VirtualStore 的用户注册表虚拟根目录。该项位于用户的 Classes 配置单元 %LocalAppData%\Microsoft\Windows\UsrClass.dat 中，与任何其他虚拟化文件数据一样，它并不随漫游用户配置文件漫游。
与 Windows 为文件系统维护一个固定虚拟化位置列表不同，注册表项的虚拟化状态作为一个标志 REG_ KEY_DONT_VIRTUALIZE 存储在该项自身。Reg.exe 实用工具可以显示该标志以及另外两个虚拟化相关标志：REG_KEY_ DONT_SILENT_FAIL 和 REG_KEY_ RECURSE_FLAG，如图 5 所示。当设置了 REG_KEY_DONT_SILENT_FAIL 并且该项未虚拟化（已设置 REG_KEY_DONT_VIRTUALIZE）时，除了应用程序请求的访问外，原本被拒绝对该项执行操作访问的旧应用程序还将被授予用户对该项所拥有的任何访问权限。REG_KEY_RECURSE_FLAG 表明新的子项是否继承父项的虚拟化标志，而不仅仅是默认标志。
图 5 Reg 实用工具显示虚拟化标志
图 5 Reg 实用工具显示虚拟化标志
图 6 显示了配置管理器如何实施注册表虚拟化，该管理器管理操作系统内核 Ntoskrnl.exe 中的注册表。对于文件系统虚拟化，创建虚拟化项的子项的旧进程将被重定向到用户的注册表虚拟根，但默认权限会拒绝 Windows Vista 进程的访问。
除了文件系统和注册表虚拟化以外，某些应用程序还需要其他帮助才能在标准用户权限下正确运行。例如，对于测试其正在运行的帐户是否是 Administrators 组成员的应用程序，如果是该组成员，则会正常运行，如果不是，则不能正常运行。因此，Windows Vista 定义了许多应用程序兼容性填充，以使这类应用程序无论如何都能够运行。最常应用于旧应用程序以使其在标准权限下操作的填充如图 7 所示。企业 IT 专业人员可以使用诸如应用程序兼容性工具包（ACT，可从 technet.microsoft .com/windowsvista/aa905066.aspx 获得），及其标准用户分析程序 (SUA) 实用工具，或 Aaron Margosis 的 LUA Buglight 等工具来确认其 LOB 应用程序的填充要求。他们使用 Compatibility Administrator（也是 ACT 的一部分）将填充分配给应用程序，然后将得到的兼容性数据库（.sdb 文件）通过组策略部署到桌面。请注意，如果需要，可以对使用全局安全策略设置的系统完全禁用虚拟化。
Figure 7 常见用户填充 (Close Figure 7)

填充 | 用途
ElevateCreateProcess | 通过调用应用程序信息服务以提示进行提升，将 CreateProcess 更改为处理 ERROR_ELEVATION_REQUIRED 错误。
ForceAdminAccess | 欺骗性地查询管理员组成员关系。
VirtualizeDeleteFile | 欺骗性地删除全局文件和目录。
LocalMappedObject | 强制全局区域对象进入用户的命名空间。
VirtualizeHKCRLite，VirtualizeRegisterTypeLib | 将 COM 对象的全局注册重定向到特定于用户的位置。
虚拟化的效果
在“任务管理器”中右键单击某个进程并从上下文菜单中选择“虚拟化”，即可更改进程的虚拟化状态。图 A 显示了当其虚拟化状态更改时命令提示符的行为。开始时虚拟化是禁用的，因为它有一个 Windows Vista 指令清单。因为它使用标准用户权限运行，所以无法在 \Windows 目录中创建文件，但是在使用任务管理器将其虚拟化后，它似乎能够成功创建该文件。当其虚拟化返回禁用状态时，它将找不到该文件，该文件实际位于用户的虚拟存储中。
图 A 虚拟化状态更改
图 A 虚拟化状态更改

管理员批准模式
即使用户只运行与标准用户权限兼容的程序，某些操作仍要求管理权限。绝大多数软件安装都要求使用管理权限，以便在系统全局位置创建目录或注册表项，或者安装服务或设备驱动程序。修改系统全局 Windows 设置和应用程序设置也要求使用管理权限，Windows Vista 家长控制功能便是如此。通过切换到专用管理帐户可以执行大多数这些操作，但是这样很不方便，导致多数用户仍然会使用管理帐户来执行其日常任务。
因此，Windows Vista 提供了一个增强的“运行身份”功能，以使标准用户能够方便地以管理权限启动进程。此功能要求为应用程序提供一种方式来标识系统可为之获得管理权限（代表该应用程序）的操作，我将对此进行简要说明。
此外，Windows Vista 还引入了一个管理员批准模式 (AAM)，这样，作为系统管理员的用户便可以使用标准用户权限来运行，而不必在每次希望获得管理权限时输入用户名和密码。此功能在登录时为用户创建两个身份：一个具有标准用户权限，另一个具有管理权限。由于 Windows Vista 系统上的每个用户要么是标准用户，要么多数情况下作为 AAM 中的标准用户来运行，因而开发人员必须假定所有 Windows 用户都是标准用户，这将导致有更多的程序使用不带有虚拟化或填充的标准用户权限来运行。
为进程授予管理权限称为提升。由标准用户帐户执行此过程时，称为“当面式”(OTS) 提升，因为它要求输入某个管理员组的成员帐户的凭据，这通常由另一个用户当着该标准用户的面完成。由 AAM 用户执行的提升称为“同意”提升，因为用户只需批准其管理权限的分配即可。
如果用户是图 8 中所列任意管理员类型组的成员，Windows Vista 就会将该用户视为管理员。所列的许多组都只用于加入域的系统，并且不直接赋予用户本地管理权限，但是允许他们修改域范围内的设置。如果用户是其中任何组的成员，而不是实际的管理员组的成员，该用户将通过 OTS 提升而不是“同意”提升来获得其管理权限。
Figure 8 管理组 (Close Figure 8)

内置管理员
证书管理员
域管理员
企业管理员
策略管理员
架构管理员
域控制器
企业只读域控制器
只读域控制器
帐户操作员
备份操作员
加密操作员
网络配置操作员
打印操作员
系统操作员
RAS 服务器
高级用户
Windows 2000 以前版本兼容访问
当属于所列的某个组的用户登录时，Windows Vista 将创建一个令牌，代表该用户的管理身份的标准用户版本。新令牌解除了分配给该用户的所有特权，只保留了图 9 中所列的那些特权，它们是默认标准用户特权。此外，任何管理员类型组在该新令牌中都带有 USE_FOR_DENY_ONLY 标志。图 10 显示了 Sysinternals Process Explorer（一种进程管理工具，可从 microsoft .com/technet/sysinternals 下载），其左侧显示了使用管理权限运行的进程的组成员关系和特权，右侧显示了不具备管理员权限的情况。（为防止意外错误使用，Windows 安全模型要求先启用带有禁用标志的特权，然后才能使用它。）
Figure 9 标准用户特权 (Close Figure 9)

友好名称 | 内部名称
绕过遍历检查 | SeChangeNotifyPrivilege
关闭系统 | SeShutdownPrivilege
从扩展坞移除计算机 | SeUndockPrivilege
增加进程工作集 | SeIncreaseWorkingSetPrivilege
更改时区 | SeTimeZonePrivilege
图 10 AAM 管理员和标准用户令牌
图 10 AAM 管理员和标准用户令牌
具有“仅拒绝”标志的组只能用于拒绝（而不能允许）用户对某个资源的访问，这样就消除了当该组被整个删除时所产生的安全漏洞。例如，如果某个文件的访问控制列表 (ACL) 拒绝了 Administrators 组的所有访问，但为该用户所属的另一个组授予某些访问权限，那么如果令牌中没有管理员组，则会为用户授予访问权限，从而为该用户身份的标准用户版本赋予比管理员身份更多的权限。
独立系统（通常是家用计算机）和加入域的系统对来自远程用户的 AAM 访问的处理不同，因为连接了域的计算机可以在其资源权限内使用域管理组。当用户访问独立计算机的文件共享时，Windows 将请求该远程用户的标准用户身份，但在加入域的系统上，Windows 将通过请求该用户的管理身份来支持其所有域组成员。

方便地获得管理权限
系统和应用程序可以通过多种方式标识对管理权限的需求。其中一个是显示在资源管理器 UI 中的“以管理员身份运行”上下文菜单项和快捷方式选项。这些项目包含一个彩色盾牌图标，它应放在任何按钮或菜单项上，当选中它时会导致权限的提升。选择“以管理员身份运行”菜单项将使资源管理器使用动词“runas”调用 ShellExecute API。
绝大多数安装程序都要求使用管理权限，因此，映像加载程序（用于触发可执行文件的启动）包含了安装程序检测代码以发现可能的旧安装程序。它使用的某些启发方式很简单，只需检测该映像在其文件名或内部版本信息中是否具有设置 (setup)、安装 (install) 或更新 (update) 字样；较为复杂的启发方式则涉及扫描可执行文件中的字节序列，第三方安装包装实用工具大多为这种情况。
映像加载器还会调用应用程序兼容性 (appcompat) 库，以查看目标可执行文件是否要求使用管理员权限。该库将查询应用程序兼容性数据库，以查看该可执行文件是否关联了 RequireAdministrator 或 RunAsInvoker 兼容性标志。
可执行文件请求得到管理权限的最常用方式是在其应用程序指令清单文件中包含一个 requestedElevationLevel 令牌。指令清单是 XML 文件，其中包含有关某个映像的补充信息。它们是在 Windows XP 中引入的，作为标识与并列 DLL 和 Microsoft .NET Framework 程序集的依赖关系的一种方式。指令清单中出现的 trustInfo 元素（可在下面的 Firewallsettings.exe 字符串转储摘录中看到）表明这是一个为 Windows Vista 编写的可执行文件，并且其中嵌套了 requestedElevationLevel 元素。该元素的 level 属性可具有以下三个值之一：asInvoker、highestAvailable 和 requireAdministrator。
<trustInfo
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>
不需要管理权限的可执行文件（如 Notepad.exe）指定 asInvoker 值。某些可执行文件预期管理员始终希望具有最大访问权限，因此他们使用 highestAvailable 值。如果某用户运行具有该值的可执行文件，那么仅当他在 AAM 中运行或被视为管理员（根据早先定义的规测）且必须提升以获得其管理权限时，才会要求提升他的权限。例如，Regedit.exe、Mmc.exe 和 Eventvwr.exe 都是使用 highestAvailable 的应用程序。最后，requireAdministrator 始终会导致提升请求，任何没有管理权限就无法操作的可执行文件需要使用该值。
可访问性应用程序为 uiAccess 属性指定“true”，以便驱动所提升进程的窗口输入，并且它们还必须带有签名并位于多个安全位置（包括 %SystemRoot% 和 %ProgramFiles%）之一以获取该能力。
确定可执行文件所指定值的一种简单方法是使用 Sysinternals Sigcheck 实用工具查看其指令清单，如下所示：
sigcheck –m <executable>
执行一个请求管理权限的映像将导致在服务主机进程 (%SystemRoot%\System32\Svchost .exe) 中运行的应用程序信息服务（也称为 AIS，它包含在 %SystemRoot%\System32\Appinfo.dll 中）启动 Consent.exe (%SystemRoot%\System32\Consent.exe)。Consent 将捕获屏幕的位图、向其应用一个淡入淡出效果、切换到只能由本地系统帐户访问的桌面、将该位图作为背景、并显示一个提升对话框，其中包含有关该可执行文件的信息。在单独的桌面上显示可防止用户帐户中的任何恶意软件修改对话框的外观。
图 11 OTS 提升对话框
图 11 OTS 提升对话框
如果映像是由 Microsoft 数字签名的 Windows 组件，并且位于 Windows 系统目录中，则对话框顶部将显示一条蓝带，如图 11 顶部所示。灰带（对话框中间）表明映像由 Microsoft 以外的组织数字签名，橙色带（对话框底部）表明映像未经签名。提升对话框显示了映像的图标、描述以及数字签名映像的发布者，但对于未签名的映像只有一个通用的图标、文件名和“未能识别的发布程序”。这样就使恶意软件更难以模仿合法软件的外观。对话框底部的“详细信息”按钮展开后将显示当可执行文件启动时要传递给它的命令行。图 12 所示的“AAM 同意”对话框与此类似，但它不会提示提供管理员凭据，而是包含了“继续”和“取消”按钮。
图 12 AAM 提升对话框
图 12 AAM 提升对话框
如果用户拒绝提升，Windows 将向激发该启动过程的进程返回一个拒绝访问错误。当用户通过输入管理员凭据或单击“继续”同意提升时，AIS 将调用 CreateProcessAsUser 以使用适当的管理身份启动进程。虽然从技术上讲 AIS 是所提升进程的父项，但 AIS 使用了 CreateProcessAsUser API 中的新支持，后者将该进程的父进程 ID 设为最初启动它的进程的 ID（请参阅图 13）。这就是在显示进程树的工具（如 Process Explorer）中，已提升进程没有显示为 AIS Service Hosting 进程的子项的原因。
图 13 提升流程
图 13 提升流程
即使提升对话框显示在单独的安全桌面上，默认情况下，用户也无法验证他们查看的是合法对话框，而不是由恶意软件提供的对话框。这并不是 AAM 的问题，因为恶意软件虽无法使用假的“同意”对话框获取管理权限，但它可以等待标准用户的 OTS 提升，截获它，并使用特洛伊木马对话框捕获管理员凭据。使用那些凭据，它们可以获得对管理员帐户的访问权限并感染它。
因此，强烈建议不要在企业环境中使用 OTS 提升。要禁用 OTS 提升（并减少咨询台呼叫），请运行本地安全策略编辑器 (Secpol.msc) 并将“用户帐户控制：标准用户的提升提示行为”配置为“自动拒绝提升请求”。
注重安全的家庭用户应当将 OTS 提升配置为要求使用一个恶意软件无法截获或模拟的安全注意序列 (SAS)。要配置 SAS，请运行组策略编辑器 (Gpedit.msc)，导航到“计算机配置”|“管理模板”|“Windows 组件”|“凭据用户界面”，并启用“要求输入凭据的受信任路径”。完成上述步骤后，会要求您输入 Ctrl+Alt+Delete 以访问提升对话框。

隔离已提升的进程
Windows Vista 在已提升进程周围设置了一道屏障，以保护它们免受在同一桌面上使用标准用户权限运行的恶意软件的侵扰。如果没有这道屏障，恶意软件可能会通过窗口消息发送合成的鼠标和窗口输入，从而驱动某个管理应用程序。虽然标准 Windows 安全模型可防止使用标准用户权限在进程中运行的恶意软件破坏作为不同用户运行的已提升进程，但它不会禁止作为某个管理用户的标准权限版本运行的恶意软件打开该用户的已提升进程、向其中插入代码并启动其中的线程以执行插入的代码。
Windows Vista 为窗口消息提供的防护称为用户界面特权隔离 (UIPI)。它基于新的 Windows 完整性机制，Windows Vista 同样使用该机制作为已提升进程周围的屏障。在此新安全模型中，所有进程和对象都具有完整性级别，并且对象的完整性策略可以限制访问权限，否则，这些访问权限将由 Windows 随机访问控制 (DAC) 安全模型授予某个进程。
完整性级别 (IL) 由安全标识符 (SID) 表示，后者还表示用户和组；而级别则编码在 SID 的相对标识符 (RID) 中。图 14 显示了四个主要 IL 的显示名称、SID 和 SID 的 RID 的十六进制版本。十六进制数字揭示了每个级别间的 0x1000 的间隔，以便提供由 UI 可访问性应用程序使用的中间级别并考虑未来增长需要。
Figure 14 主要完整性级别 (Close Figure 14)

名称 | SID | RID
低强制性级别 | S-1-16-4096 | 0x1000
中等强制性级别 | S-1-16-8192 | 0x2000
高强制性级别 | S-1-16-12288 | 0x3000
系统强制性级别 | S-1-16-16384 | 0x4000
图 15 列出了对象 IL 策略以及它们所限制的访问类型，这些访问类型与为对象定义的通用访问权限相对应。例如，No-Write-Up 将禁止低 IL 进程获取任何由 GENERIC_WRITE 访问权限表示的访问权限。大多数对象（包括文件和注册表项）的默认策略都是 No-Write-Up，这将禁止进程从具有比它更高的 IL 的对象获取写访问权限，即使该对象的随机访问控制列表 (DACL) 授予用户这种访问权限也是如此。仅有的具有不同策略的对象是进程对象和线程对象。它们的策略（No-Write-Up 加上 No-Read-Up）会禁止在低 IL 上运行的进程向具有较高 IL 的进程插入代码或从中读取数据（如密码）。
Figure 15 完整性级别策略 (Close Figure 15)

策略 | 效果
No-Write-Up | 较低 IL 进程无法修改较高 IL 对象
No-Read-Up | 较低 IL 进程无法从较高 IL 对象读取
No-Execute-Up | 较低 IL 进程无法执行较高 IL 对象
Windows 为每个进程分配一个 IL，该 IL 放在进程令牌中组 SID 的旁边，这些组是运行该进程的用户所属的组。图 16 列出了分配给不同 IL 的进程示例。进程通常继承其父项的 IL，但进程也可以在其他 IL 上启动进程，与 AIS 启动已提升进程时的操作相同。您可以通过指定 /all 选项使用内置的 Whoami 实用工具、Sysinternals Process Explorer 或 AccessChk 来查看进程完整性级别。Process Explorer 可以在附加的“完整性级别”列中显示进程 IL。
Figure 16 进程完整性级别分配示例 (Close Figure 16)

完整性级别 | 示例进程
低强制性级别 | 保护模式 Internet Explorer 和由保护模式 Internet Explorer 启动的进程
中等强制性级别 | 标准用户和非提升的 AAM 进程
高强制性级别 | 使用管理权限运行的进程
系统强制性级别 | 本地系统、本地服务和网络服务进程
每个安全对象都有一个显式或隐式的 IL。进程、线程和令牌对象始终具有一个显式分配的 IL，它通常与对应进程令牌中存储的 IL 相同。多数对象都没有显式 IL，因此都默认为某个中等 IL。使用中等以外的 IL 创建的仅有对象是由在低 IL 上运行的进程创建的对象，它们因此而具有一个低 IL。您可以使用内置的 iCacls 工具 (%SystemRoot%\System32\iCacls.exe) 查看文件的 IL，并使用 Sysinternals AccessChk 实用工具查看文件、注册表项、服务和进程的 IL。图 17 显示需要通过保护模式 Internet Explorer 才能访问的目录的 IL 为“低”。
图 17 显示用户收藏夹目录 IL 的 AccessChk
图 17 显示用户收藏夹目录 IL 的 AccessChk
如果对象具有显式 IL，则它存储在 Windows Vista 中新引入的一种访问控制项 (ACE) 类型中（即 Label ACE），该 ACE 位于对象安全描述符的系统访问控制列表 (SACL) 中（请参阅图 18）。ACE 中的 SID 对应于对象的 IL，ACE 的标志为对象的完整性策略进行了编码。在 Windows Vista 之前，SACL 只存储审核 ACE，这需要“管理审核和安全日志”特权 (SeSecurityPrivilege)，但读取 Label ACE 只需要“读取权限”(READ_CONTROL) 访问权限。如果进程要修改对象的 IL，它必须具有该对象的“更改所有者”(WRITE_OWNER) 访问权限以及一个与该对象相同或更高的 IL，并且该进程只能将 IL 设置为自己的 IL 或更低的 IL。新的“修改对象标签”(SeRelabelPrivilege) 特权使进程能够更改它可以访问的任何对象的 IL，甚至将 IL 提高到超过进程自己的 IL，但默认情况下，该特权未分配给任何帐户。
图 18 对象的 Label ACE
图 18 对象的 Label ACE
当进程尝试打开某个对象时，内核的 SeAccessCheck 功能中将先进行完整性检查，然后再进行标准的 Windows DACL 检查。在默认完整性策略下，仅当进程的 IL 等于或高于对象的 IL，且 DACL 也为该进程授予了它所需要的权限时，该进程才能打开此对象进行写访问。例如，低 IL 进程不能打开中等 IL 进程进行写访问，即使 DACL 为该进程授予了写访问权限。
在默认完整性策略下，进程可以打开任何对象（进程和线程对象除外）进行读取访问，只要对象的 DACL 为它们授予了读取权限即可。这意味着，在低 IL 上运行的进程可以打开任何其运行所在的用户帐户可以访问的文件。保护模式 Internet Explorer 使用 IL 来帮助防止感染它的恶意软件修改用户帐户设置，但是它不能禁止恶意软件读取用户的文档。
上述情况不适用于进程和线程对象，因为它们的完整性策略还包括 No-Read-Up。这意味着，进程的 IL 必须等于或高于它要打开的进程或线程的 IL，且 DACL 必须授予它成功打开所需的访问权限。假设 DACL 允许授予所需的权限，图 19 显示了在中等和低 IL 上运行的进程针对其他进程和对象所拥有的访问权限。
图 19 对象和进程访问权限
图 19 对象和进程访问权限
Windows 消息传递子系统还支持完整性级别通过以下方式实施 UIPI：禁止进程向具有较高 IL 的进程所拥有的窗口发送除信息性窗口消息以外的任何消息。这将不允许标准用户进程向已提升进程的窗口进行输入，或不允许通过向其发送可触发内部缓冲区溢出的格式不正确的消息来破坏已提升进程。进程可以通过调用 ChangeWindowMessageFilter API 选择允许其他消息通过这层防范。UIPI 还会防止窗口挂接影响较高 IL 进程的窗口，这样，例如标准用户进程便无法记录用户在管理应用程序中的键击情况。

提升和安全边界
UAC 提升是一种方便性，而不是安全边界，清楚这一点很重要。安全边界要求安全策略指明能够通过该边界的内容。用户帐户就是 Windows 中安全边界的一个示例，因为如果没有另一个用户的许可，某个用户就无法访问属于另一个用户的数据。
因为提升不是安全边界，所以无法保证使用标准用户权限在系统上运行的恶意软件不会侵扰已提升进程以获取管理权限。例如，提升对话框只标识了即将提升的可执行文件；其中没有提供执行时将如何操作的任何信息。可执行文件将处理命令行参数、加载 DLL、打开数据文件并与其他进程通信。可以想象，上述任何操作都可能允许恶意软件侵扰已提升进程，进而获取管理权限。
低 IL 沙盒中的游戏
保护模式 Internet Explorer 在低 IL 上运行，以便在可能感染其进程的恶意软件周围筑起一道围墙。这将防止恶意软件更改用户帐户设置并将自己安装在一个自动启动位置。您可以使用 Sysinternals PsExec 实用工具和 -l 开关，在低 IL 上启动任意进程以探究沙盒的秘密。图 B 显示了在低 IL 上运行的命令提示符如何无法在用户的临时目录（具有中等 IL）中创建文件，却能够在具有低 IL 的 Internet Explorer 临时目录中创建该文件。
图 B命令提示符只能在相似的 IL 中创建文件

已提升的 AAM 进程尤其易受侵扰，因为它们在与 AAM 用户的标准权限进程相同的用户帐户下运行，并共享用户的配置文件。许多应用程序读取在用户配置文件中注册的设置并加载在其中注册的扩展，这为恶意软件的提升提供了机会。例如，常用控制对话框会加载在用户的注册表项（位于 HKEY_CURRENT_USER 下）中配置的外壳扩展，因此恶意软件可以将其自身作为一项扩展添加进去，以加载到使用那些对话框的任何已提升进程中。
即使是从标准用户帐户提升的进程也必定会因共享状态而受到侵扰。在某个登录会话中运行的所有进程将共享 Windows 用来存储对象（如事件、mutex、信号和共享内存）的内部命名空间。如果恶意软件知道某个已提升进程将在进程启动时尝试打开并读取特定共享内存对象，它可以创建该对象，而其内容将触发缓冲区溢出以便将代码插入到已提升进程中。这种攻击类型比较复杂，但其存在的可能性使得 OTS 提升无法成为一种安全边界。
我们的底线是引入提升以提供方便，从而鼓励要获得管理权限的用户在默认情况下使用标准用户权限运行。希望安全边界有保障的用户可以用方便性换取这种保障，此时，可以为日常任务使用标准用户帐户，同时使用快速用户切换 (FUS) 切换到专用管理员帐户来执行管理操作。另一方面，希望用安全性换取方便性的用户可以在“控制面板”的“用户帐户”对话框中禁用系统上的 UAC，但是必须清楚，这同时也会禁用 Internet Explorer 的保护模式。

结束语
以标准用户身份运行有许多好处，其中包括有助于保护系统免受无意或有意的损害，以及防止共享系统的用户的数据和完整性受到未经授权的访问。UAC 的各种变化和技术将导致 Windows 使用模型发生重要改变。在 Windows Vista 中，Windows 用户第一次能够使用标准用户权限执行大多数日常任务并运行大多数软件，现在，许多企业都能够部署标准用户帐户。

Mark Russinovich是 Microsoft 平台和服务部门的一名技术人员。他是“Microsoft Windows Internals”（Microsoft Windows 内核）(Microsoft Press, 2004) 的合著者之一，并经常在 IT 和开发人员会议上发表演讲。在 Microsoft 最近收购了 Mark Russinovich 与其他人创办的 Winternals Software 之后，Mark Russinovich 也随之加入了 Microsoft。他还创建了 Sysinternals，在这里他发布了 Process Explorer、Filemon 和 Regmon 实用工具。
© 2007 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.


 安全性: 使用 BitLocker 驱动器加密以保护数据的密钥
安全性 Byron Hynes

使用 BitLocker 驱动器加密以保护数据的密钥
概览:
  • 整卷加密
  • BitLocker 密钥
  • 设置 BitLocker

Windows BitLocker 驱动器加密毫无疑问是 Windows Vista 中谈论最多的功能之一。但是，大多数人尚没有太多机会来测试 BitLocker，以亲身体验
它的作用和工作原理 — 尤其不在具备受信任的平台模块 (TPM) 的计算机上。在本文中，我将向您介绍 BitLocker™ 的基础知识，以便您评估其潜力，并将其纳入您的升级规划。我会从一些背景和概念性信息开始讲起，然后介绍启用 BitLocker、数据恢复、管理，以及 BitLocker 如何在计算机生命末期发挥作用。要更好地理解本文中的术语，请查看侧栏“磁盘和卷”。
磁盘和卷
围绕磁盘和卷的术语往往会使人混淆。下面是一个简要术语表，供您参考。
分区：分区是物理硬盘的一部分，它是磁盘上存储的分区表中定义的逻辑结构。
卷：卷是 Windows 中由一个或多个分区组成的逻辑结构，由称为“卷管理器”的 Windows 组件所定义。除了卷管理器和启动组件，其余的操作系统组件和应用程序均使用卷，而非分区。在 Windows 客户端操作系统环境下，包括 Windows Vista 在内，分区和卷通常具有一对一的关系。而在服务器中，一个卷通常由多个分区组成，比如典型的 RAID 配置。
活动分区：一次只能将一个分区标为活动分区。此分区包括了用于启动操作系统的引导扇区。活动分区有时称为系统分区或系统卷，但是，请不要将这些术语和 Windows 操作系统卷混淆。
Windows 操作系统卷：此卷包含 Windows 安装，其中包括 System 文件夹和 System32 文件夹。Windows Vista 发布之前，用到了（并且仍在经常使用）术语“引导分区”。术语“Windows 操作系统卷”较为清楚，可避免引导分区和系统分区之间不断的混淆。在过去，培训师有时会让学生这样记忆：“从系统分区启动，在引导分区上查找系统文件”。
在 Windows Vista 之前，Windows 操作系统卷（也称为引导分区）和活动分区（也称为系统分区）是同一回事，因为大多数客户端计算机上的硬盘都配置为单独一个大分区。在图 A 中，您会看到分配给 Windows Vista 的“磁盘管理”控制台中每个分区或卷的功能。
图 A 分区功能
图 A 分区功能

BitLocker 真正起到了两个既互补而又截然不同的作用。首先，BitLocker 为 Windows® 操作系统卷提供了整卷加密。其次，在具备兼容的 TPM 的计算机上，BitLocker 提供了在允许 Windows Vista™ 启动之前验证早期启动组件完整性的方法。
若要使用 BitLocker 的所有功能，您的计算机必须具备兼容的 TPM 微芯片和 BIOS。兼容要求 1.2 版的 TPM，以及满足以下条件的 BIOS：支持 TPM 和由可信赖运算组织 (TCG) 定义的 Static Root of Trust Measurement。但是，没有兼容的 TPM 和 BIOS 的计算机仍可使用 BitLocker 加密。

整卷加密
BitLocker 提供了整卷加密，确保对写入 Windows 操作系统卷的所有数据都能进行加密。这是保护存储于组织的计算机（尤其是便携式计算机或移动计算机）中机密信息的关键。
移动计算机丢失或被盗事件每天都会发生。具备了提高的便携式计算能力和移动性日益增强的工作团队，一名办公人员便能携带几百 GB 的组织商业机密、机密文档或客户个人身份信息 (PII)。只要随意进行新闻搜索，便会发现太多数据丢失之类的事件。（隐私权交流中心宣称，自 2005 年以来，已有超过 1.04 亿包含个人信息的记录发生丢失或泄漏。)
大多数组织已经在按照法律和公司要求保护多类隐私信息，并且，即使法律上并未要求，您很可能也会因为业务利益而必须如此去做。

为什么要加密整个卷？
如果您是位经验丰富的 Windows 管理员，您可能已经熟悉了基于 Windows 的加密选项，比如加密文件系统 (EFS)，或者由权限管理服务 (RMS) 提供的加密和保护。BitLocker 最大的不同之处在于，它在启用后是自动、透明的，并包括整个卷。
例如，使用 EFS，您必须明确指明要保护哪些文件和文件夹。在 Windows Vista 中，有一些新选项可使 EFS 更加灵活，并使 EFS 和 RMS 能分别处理 BitLocker 无法处理的某些情况。但是，EFS 和 RMS 都需要管理员进行大量配置，并且不是为保护卷上存储的所有资料而专门设计的。
与之相反，BitLocker 会对写入 BitLocker 保护卷上的所有资料进行加密，包括操作系统本身、注册表、休眠文件和分页文件、应用程序以及应用程序使用的数据。
以下三项不会被加密：引导扇区、标为不可读的坏扇区和卷元数据。卷元数据由用于管理 BitLocker 的三个冗余副本数据组成，包括关于卷的统计信息，以及一些解密密钥的受保护副本。这些项不需要加密，因为它们并不是唯一的、有价值的，或者可辨认个人身份。
整卷加密可防止离线攻击 — 一种通过试图绕过操作系统而发动的攻击。例如，常见的离线攻击是窃取计算机、拆除硬盘并将其安装为其他计算机（运行 Windows 不同副本或不同操作系统）上的第二个驱动器，从而消除 NTFS 权限和用户密码。然而，使用这种攻击却无法读取 BitLocker 保护的卷。

BitLocker 如何加密数据
BitLocker 使用 128 位密钥的高级加密标准 (AES) 算法。要获得更好的保护，可使用“组策略”或 BitLocker Windows Management Instrumentation (WMI) 提供程序将密钥增至 256 位。
卷中的每个扇区都单独进行加密，加密密钥的一部分是从扇区编号本身派生而来。这意味着，包含完全相同的未加密数据的两个扇区也会以不同的加密字节写入磁盘，这使得通过创建和加密已知部分信息的方法来尝试发现密钥的难度大大增加。
使用 AES 加密数据前，BitLocker 还会使用一种称为“扩散器”的算法。无需深入说明其加密技术，对扩散器的简单描述就是，它可以确保即使是对明文的细微更改都会导致整个扇区的加密密文发生变化。这也使得攻击者发现密钥或数据的难度大大增加。
如果您对 BitLocker 加密算法的详细信息感兴趣，则可以阅读 Neil Ferguson 的相关文章“AES-CBC + Elephant 扩散器： 用于 Windows Vista 的磁盘加密算法”。

BitLocker 密钥
无论何时处理加密，您都需要了解密钥，BitLocker 也不例外。BitLocker 使用明确但有些复杂的密钥体系结构。
这些扇区本身使用称为“整卷加密密钥”(FVEK) 的密钥加密。然而，FVEK 不会由用户使用，而且用户也无法进行访问。FVEK 又会使用称为“卷主密钥”(VMK) 的密钥加密。此程度的抽象性带来了独一无二的好处，但也使得整个过程较难理解。FVEK 作为严密保护的秘密来保存，因为一旦泄漏，所有的扇区都需要重新加密。因为这是一个费时的操作，所以应当尽量避免。实际上，系统使用 VMK 代之。
FVEK（使用 VMK 加密）存储于磁盘本身，作为卷元数据的一部分。虽然 FVEK 在本地存储，但从不写入未加密的磁盘。
VMK 也进行加密或“保护”，但使用的是一个或多个可能的密钥保护程序。默认的密钥保护程序是 TPM。TPM 的使用会在以下完整性检查部分进行介绍。此外还会创建恢复密码作为密钥保护程序，用于紧急情况。恢复也会在稍后进行介绍。
您可以将 TPM 与数字 PIN 或存储在 USB 驱动器上的部分密钥组合使用，从而获得更高的安全性。上述每种方法都是某种形式的双因素身份验证。如果您的计算机没有兼容的 TPM 芯片和 BIOS，BitLocker 可配置为将密钥保护程序完全存储在 USB 驱动器上。这称为“启动密钥”。
BitLocker 无需解密数据便可禁用，在此情况下，VMK 仅由未加密存储的新密钥保护程序进行保护。请注意，此透明密钥允许系统访问驱动器，好像该驱动器未受保护一样。
启动时，系统会通过查询 TPM，检查 USB 端口或者在必要情况下提示用户（称为恢复），来搜寻适当的密钥保护程序。查找密钥保护程序会让 Windows 解密 VMK，这会解密 FVEK，而这又会解密存储在磁盘上的数据。图 1 显示了这一过程。
图 1 BitLocker 默认启动过程
图 1 BitLocker 默认启动过程

完整性检查
由于启动过程最初阶段的组件必须是未加密可用的，以便计算机能够启动，而攻击者可能会趁机更改早期启动组件中的代码（想一想 rootkit），从而能够访问计算机，即使磁盘中的数据已被加密。
通过这种攻击，入侵者很有可能获得机密信息的访问权，比如 BitLocker 密钥或用户密码，并利用该信息避开其他安全保护措施。
防止这种攻击是该程序和团队创建 BitLocker 的最初目标之一。在某些方面，加密几乎是达到目的的一种手段。整卷加密允许 BitLocker 保护系统的完整性，并防止在早期启动组件被更改的情况下启动 Windows。
在具备兼容的 TPM 的计算机上，每次计算机启动时，每个早期启动组件（比如 BIOS、主引导记录 (MBR)、引导扇区和启动管理器代码）都会检查要运行的代码，计算哈希值，并将该值存储于 TPM 中的特定注册表，它称为平台配置注册表 (PCR)。一旦将值存储到 PCR，除非系统重新启动，否则就不能替换或清除该值。BitLocker 使用 TPM 和存储在 PCR 中的值来保护 VMK。
TPM 可创建绑定到特定 PCR 值的密钥。创建这类密钥时，TPM 会加密该密钥，且只有特定的 TPM 才能对其解密。可是，除此之外，仅当当前 PCR 值与创建密钥时指定的值匹配的情况下，TPM 才会解密该密钥。这称为将密钥封装到 TPM。
默认情况下，BitLocker 将密钥封装到 Core Root of Trust Measurement (CRTM)、BIOS 和任意平台扩展、选项 ROM 代码、MBR 代码、NTFS 引导扇区以及启动管理器的测量结果。如果其中任一项被意外更改，BitLocker 都会锁定驱动器，以防其被访问或解密。
默认情况下，BitLocker 配置为查找并使用 TPM。您可以使用“组策略”或本地策略设置，使 BitLocker 在没有 TPM 的情况下工作，并将密钥存储于外部 USB 闪存驱动器，但是没有 TPM，BitLocker 将无法验证系统完整性。

第一次启用 BitLocker
Windows Vista Enterprise 和 Windows Vista Ultimate 中提供了 BitLocker。（BitLocker 还将作为可选组件包含在下一版本的 Windows Server® 中，代号为“Longhorn”。）
以下讨论假设您已有具备兼容的 TPM 的计算机可供测试。如果您要在没有 TPM 的计算机上启用 BitLocker，请遵循侧栏“在没有 TPM 的情况下使用 BitLocker”中所列的步骤。
在没有 TPM 的情况下使用 BitLocker
BitLocker 默认配置为使用 TPM，如果您没有 TPM，现成的 Windows 将不允许您启用 BitLocker。但是，来自“Windows BitLocker 驱动器加密逐步指南”的以下步骤，能够让您在没有 TPM 的情况下使用 BitLocker。
要执行这些步骤，您必须以管理员身份登录。即使没有 TPM，您的计算机也必须支持在启动过程期间从 USB 闪存驱动器读取数据。此外，启用 BitLocker 及每次重新启动计算机时，您都必须具有 USB 闪存驱动器。
请按照下列步骤，在没有兼容的 TPM 的计算机上启用 BitLocker 驱动器加密：
  1. 单击“开始”，在“开始搜索”框中键入“gpedit.msc”，然后按 Enter。
  2. 如果出现“用户帐户控制”对话框，请确认建议操作正是您请求的操作，然后单击“继续”。
  3. 在“组策略对象编辑器”控制台树中，依次单击“本地计算机策略”、“管理模板”、“Windows 组件”，然后再双击“BitLocker 驱动器加密”。
  4. 双击设置“控制面板设置: 启用高级启动选项”。“控制面板设置: 启用高级启动选项”对话框将会出现。
  5. 选择“已启用”选项，选中“没有兼容的 TPM 时允许 BitLocker”复选框，然后单击“确定”。您已经更改策略设置，现在便可使用启动密钥代替 TPM。
  6. 关闭“组策略对象编辑器”。
  7. 要强制“组策略”立即应用，您可以单击“开始”，在“开始搜索”框中键入“gpupdate.exe /force”，然后按 Enter。等待该过程完成。

启用 BitLocker 的重要一点是确保正确配置了您的卷。BitLocker 要求活动分区处于未加密状态，以便能够读取引导扇区、启动管理器和 Windows 加载程序（这些组件由先前所述的系统完整性步骤所保护）。由于其他 Windows 组件可能需要临时用到活动分区，因此 Microsoft 建议活动分区至少为 1.5GB。配置 NTFS 权限也不失为一个好办法，这样用户便不会意外地将数据写入该卷。
Windows 本身将被安装到第二个较大的卷上，该卷可以加密。如果您要将 Windows 安装在新系统上，则可以按照 Windows BitLocker 驱动器加密逐步指南中的说明，手动配置卷。
您可以使用 BitLocker Drive Preparation Tool 来协助设置系统，以便使用 BitLocker。此工具摆脱了配置驱动器的辛苦工作，并作为 Windows Vista Ultimate Extra 提供，或提供给部署 Windows Vista Enterprise 的客户。有关 BitLocker Drive Preparation Tool 的详细说明，请访问 support.microsoft.com/kb/930063。
BitLocker Drive Preparation Tool 会自动收缩卷（如果您只有一个卷）、创建第二个分区、使其成为活动分区、执行所有必需的配置更改，并将启动文件移到适当的位置。
配置卷后，启用 BitLocker 非常简单。在“控制面板”的“安全”部分，单击“BitLocker 驱动器加密”图标。在确认 UAC 同意提示后，将会出现类似于图 2 的屏幕。
图 2 启用 BitLocker
图 2 启用 BitLocker
后续操作的确切顺序会因计算机上的 TPM 芯片状态而各异。如果 TPM 芯片未初始化，则会运行“TPM 初始化向导”。请按照提示来初始化 TPM，包括重新启动计算机。
初始化 TPM 后，会显示“保存恢复密码”页面，如图 3 所示。当发生 TPM 故障或其他问题时，为了能够恢复数据，您需要一个恢复密码。此页面可让您将恢复密码保存到 USB 闪存驱动器、本地硬盘或网络硬盘，或者打印出来妥善保存。您必须至少选择上述其中一项，并且您可以选择保存多份恢复密码。保存恢复密码后，便会启用“下一步”按钮。单击该按钮。
图 3 保存恢复密码
图 3 保存恢复密码
“加密选定的磁盘卷”页面将会出现，您可以选择是否要在开始加密之前运行系统检查。该系统检查会要求重新启动计算机，但这是确保您的 TPM、BIOS 及 USB 端口能够与 BitLocker 一起正常运行的最佳方法。重新启动后，如果检测到任何问题，您会看到错误消息。否则会显示“加密进行中”的状态栏。
就是这样。加密会在后台完成，您可以继续使用计算机。初始加密完成后，会出现消息通知您。您还可通过在屏幕底部工具栏中的“BitLocker 驱动器加密”图标上拖动光标，从而监视磁盘卷加密的现行完成状态。有关详细信息，您可参阅先前提到的“逐步指南”。
一些用户惊讶地发现，BitLocker 在计算机启动时不会提示用户或出现其他任何明显中断。这是因为，在默认配置中，BitLocker 在解除对卷的锁定之前依赖 TPM 来确认系统完整性。这是自动执行的，并且对用户透明。
您可以将 BitLocker 配置为启动时需要输入 PIN 或者有密钥存储在 USB 闪存驱动器上。这会加强安全，如果加强安全的重要性超过了输入 PIN 的不便，则建议采用这种方法。在我看来，安全性始终是应予最优先考虑的事。（换句话说，我的台式计算机要求 PIN，而我的便携式计算机要求 USB 密钥。）

BitLocker 恢复
处理加密时，尤其是在企业环境中，要有办法让授权用户即使在无法使用正常访问方法或没有密钥的情况下，都能够找回他们的数据，这是至关重要的。BitLocker 称之为“恢复”。
如果早期启动组件出现了一些意外更改，或者您丢失了 USB 启动密钥，或是用户忘记了自己的 PIN，则 BitLocker 便不能完成正常的启动过程。BitLocker 会使卷保持锁定状态，并且 Windows 也无法启动。取而代之，启动管理器中的 BitLocker 代码会显示一个文本屏幕。如果恢复密码（有时称为恢复密钥）已保存到 USB 闪存驱动器，则会出现类似于图 4 的屏幕。
图 4 查找恢复密钥
图 4 查找恢复密钥
要让 BitLocker 读取 USB 闪存驱动器，则必须在启动时就连接上。如果您有带恢复密码的 USB 闪存驱动器，请插上并按 Esc。如果没有这样的驱动器，按 Enter 即可看到图 5 所示的屏幕。如果从未有恢复密码保存到 USB 驱动器，那么也会显示此屏幕。
图 5 输入 BitLocker 密码
图 5 输入 BitLocker 密码
BitLocker 现在将会查找一个 48 位的数字密码，可解除对驱动器的锁定。如果您选择打印恢复密码，则会在页面上显示该数字，如果您已将恢复密码保存到一个文件夹，则它会存储在文件中。
企业中管理恢复密码最简单的方法就是将它们自动存储在 Active Directory® 中。若要获取有关这一过程的具体操作信息，请访问 go.microsoft.com/fwlink/?LinkId=87067。
在后续文章中，我将详细描述 BitLocker 的可管理性，但是作为本概述的一部分，您必须了解 BitLocker 附带了完整的 WMI 提供程序，允许通过任一 WMI 兼容的基于 Web 的企业管理 (WBEM) 系统来管理 BitLocker（和 TPM）。这意味着能使用可访问 WMI 对象的任意脚本语言，比如 VBScript 或 Windows PowerShell™，来为 BitLocker 编写脚本。
BitLocker 还附带了一个名为 manage-bde.wsf 的命令行工具，可使用 WMI 提供程序让您在本机或远程计算机上管理 BitLocker。有关详细信息，请启动提升的命令提示，并键入“manage-bde.wsf /?”。

安全取消配置
需要考虑到这一点，每台计算机都需要取消配置。企业经常花费大量财力和精力来确保在放弃磁盘驱动器之前能够完全摧毁其中的资料。大多数过程是删除磁盘驱动器中的机密数据，这既费时又耗费成本，甚至会对硬件造成永久性损坏。BitLocker 提供了更经济高效的其他可选方法。
BitLocker 可确保一开始就不会以冒险的方式将机密数据存储在磁盘上，因而无需担心事后删除数据。由于写入磁盘的数据都是加密的，因此销毁加密密钥的所有副本后，这些数据会永久变为完全无法访问。硬盘本身完全没有损伤，并且可以重复使用。
您可以在取消卷（受 BitLocker 保护）配置的多种方法中进行选择。您可以选择删除卷元数据中的所有密钥副本，同时将它们存档在安全的中心站点。这使系统能够安全传输，或在长期处于无人看管状态时临时取消配置。它确保了授权用户仍然能够访问数据，但未授权的用户（例如设备的新所有者）则不能访问。
您还可以选择删除卷元数据或任意存档中的所有密钥副本，比如 Active Directory（通过创建新密钥而不存储即可）。由于不再存在任何解密密钥，因此任何人都无法发现或检索数据。
上述任一情形中，删除和破坏卷中包含的密钥几乎是瞬间完成，并可由一个管理员在多个系统间执行。这只需要投入极少量的时间和精力，但却会换来高级别的永久性保护。Windows Vista 中的格式化实用工具已经更新，以便格式化命令能删除卷元数据并覆盖这些扇区，从而安全地删除所有 BitLocker 密钥。

最后几点
BitLocker 是旨在防范特定威胁的强大工具，而且表现相当优异。然而，如果认为 BitLocker 能够防范所有威胁，那就错了。绝对重要的是，您还需要使用适当的防范及控制措施，如强密码。
您需要了解，BitLocker 是针对离线攻击而设计的。这表示，如果正在运行 Windows，则 BitLocker 已解除了对卷的锁定。换言之，BitLocker 对运行中的系统不提供保护。诸如 EFS 和 RMS 之类的技术通过在操作系统运行时保护信息，为 BitLocker 提供了补充。
有关 BitLocker 的更多信息，请访问 Microsoft 网站，网址为 technet.microsoft.com/windowsvista/aa905065.aspx。有关 TPM 规范和 TCG 的更多信息，请访问 TCG 网站的“TPM 规范”部分，网址为 go.microsoft.com/fwlink/?LinkId=72757。

Byron Hynes任职于 Microsoft 的 Windows Server 用户协助组。之前，他曾担任顾问兼培训师。您可以发送电子邮件至 bhynes@microsoft.com 与其联系。


 安全性: Windows 防火墙探究
安全性 Steve Riley

Windows 防火墙探究
概览:
  • 入站和出站保护
  • Windows 筛选平台
  • 高级安全界面
  • 网络配置文件

如果回到过去的计算时代，没有人会考虑在单独的计算机上安装防火墙。谁需要这么做呢？很少有人听说过 Internet，TCP/IP 并不存在，LAN 协议不会在您的房子或校园上方传送。重要的数据都保存在
大型机或文件服务器 — 人们保留在他们台式计算机上的信息很少会是关键性的，计算机自身的重量也一定程度上确保了相当的物理安全性。如果存在到 Internet 的连接，那么中间很可能有一些协议转换器，在网络边缘还可能有数据包筛选路由器（即“防火墙”），而且很可能配置了太多的规则和异常处理。
现代的计算环境和这样的过去年代差别很大。每个设备都连接到 Internet（而且现在都用 TCP/IP 通信），并且便携式设备是当前的标准。您的雇主很可能给您配了一台便携式计算机，这并不是因为他们关心您，而是因为他们希望您多做点贡献 — 他们非常希望您一旦有了五分钟的空闲，就可以随时随地通过 Wi-Fi 连接工作。便携式计算机也许比台式计算机昂贵，但是通过生产力的提高，这笔投资肯定得到了回报。您看，便携性是如此诱人 — 无论是对您还是对您的对手都是如此。
回想一下：在您的便携式计算机开机并连接到某个网络的总时间里，有多大比例是连接到您公司的网络？如果您的情况和我类似，也许最多是百分之二十。也就是说，只有百分之二十的时间里，我的便携式计算机安全地处在 Microsoft 的公司网络之内，受到网络外围防护的保护，以免遭到外部攻击。但是在百分之八十的时间里，我的便携式计算机因各种实际需要而直接连接到 Internet，这会怎么样？（而且，我相当频繁地连接到世界上最危险的网络：计算机安全会议所在旅馆的 LAN！）当我在那些场合连接到公司网络时，该环境内的其他计算机又会给我带来什么样的威胁？
安全控制不断发展以应对威胁，但有时候远远落在后面。病毒曾经是客户端的问题，原因是人们相互交换软盘，所以防病毒程序首先出现在客户端。此后，随着电子邮件得到广泛使用以及恶意软件逐渐演变为依靠电子邮件传播的蠕虫，反恶意软件的程序开始发展并出现在电子邮件网关上。随着 Web 的兴起，恶意软件逐渐演变为木马，反恶意软件工具随之出现在 Internet 访问代理服务器上。这是一个广为了解的发展过程，没有人对此有异议。
现在让我们把同样的逻辑用到防火墙上。虽然您网络边缘的防火墙足以抵御原先的威胁，但现在的威胁已不同以往，它们更加复杂，更加普遍。更不用说现在的设备和工作方式都与过去大相径庭。许多计算机在本地保存敏感的信息，而且在大量的时间里它们都处在公司网络之外（也就是说，在防护边缘之外）。因此，防火墙必须演化成单个客户端的保护机制。没错：客户端防火墙不再是可有可无的。为了在公司网络和 Internet 中保护您的计算机，客户端防火墙是必需的。

客户端防火墙和安全性表演
许多人没有意识到最初发布的 Windows® XP 包括一个客户端防火墙。这并不让人意外，因为默认情况下该防火墙是关闭的，而且需要很多操作才能打开。这个防火墙的登台多少有点遮遮掩掩，没有任何对真正用途的说明或者使用指导。但是它的确有效。如果您开启了该防火墙，它可能已经使您免受 Nimda 、Slammer、Blaster、Sasser 以及网络端口上未经请求的通信之害。在认识到保护客户端的重要性之后，Windows XP Service Pack 2 (SP2) 在默认情况下启动了防火墙，创建了两个配置文件（Internet 和公司网），并允许启用组策略。
遗憾的是，采用 Windows XP SP2 防火墙有两个障碍：关于应用程序的顾虑和安全性表演。许多人担心防火墙会使他们的应用程序无法正常工作。但这种情况很少出现，原因在于防火墙的设计。防火墙允许所有出站通信离开您的计算机，但是阻止所有不属于对先前出站请求进行应答的入站通信。此设计唯一给客户端应用程序造成麻烦的情形是，应用程序创建了一个侦听的套接字并期待接收入站请求。Windows XP 防火墙允许为程序或端口进行简单的异常情况配置（但遗憾的是，这不是通过组策略）。
更大的阻碍是其他客户端防火墙生产商所做的安全性表演。有些人相信 Windows XP 防火墙的设计（即允许所有的出站通信不受阻碍地离开）对于客户端防火墙来说功能上是不够的。这种观点认为，一个能够胜任的客户端防火墙应该阻止所有未经用户专门许可的通信，不论是入站还是出站。
现在，让我们认真考虑一下这种观点。现在出现了两种情形：
  • 如果您以本地管理员身份运行，而又感染了恶意软件，该恶意软件将直接使防火墙失效。您将彻底被打垮。
  • 如果您不是以本地管理员身份运行，而您感染了恶意软件，恶意软件将导致一个第三方防火墙引发一个对话框，其中充满了有关端口和 IP 地址的怪异文字，以及一个非常严肃的问题：“您要允许这些通过么？”当然，唯一的答案就是：“是的，您这个愚蠢的计算机，不要再骚扰我了！”一旦该对话框消失，您的安全性也就荡然无存。或者，更常见的情况是，恶意软件直接劫持了您已经授权的现有程序会话，您甚至都无法看到该对话框。您再次被彻底打垮。
您必须了解一个关于安全性的重要原则。保护措施针对的是您希望保护的资产，而不是您希望防备的东西。正确的方法是在您的企业内每台计算机上运行精益但有效的 Windows 防火墙，以保护每一台计算机免受世界上任何其他计算机的威胁。如果您试图阻止一台已经被攻击的计算机的出站连接，那么如何确保该计算机真的在按您的指示工作？答案是：您不能。出站保护是安全性表演 — 这是一个花招，只给您一个改善安全性的印象，但却不做任何提高安全性的实质工作。这就是为什么 Windows XP 防火墙中没有出站保护，也是它为什么不存在于 Windows Vista™ 防火墙中的原因。（稍后我将进一步探讨有关 Windows Vista 中的出站控制。）

Windows Vista 中有哪些新增功能?
Windows 筛选平台作为新网络堆栈的一部分，是 Windows Vista 防火墙的根基。与 Windows XP 类似，Windows Vista 在默认情况下阻止入站通信。根据您的计算机运行的配置文件的不同，有可能存在网络服务的默认异常情况（稍后我将讨论配置文件）。如果愿意，您可以编写允许入站连接的规则。仍然与 Windows XP 类似，Windows Vista 在默认情况下允许来自所有交互式进程的出站通信，但对参与服务限制的服务采取出站通信限制。同样，如果愿意，您可以编写阻止额外出站连接的规则。
Windows XP 和 Windows Vista 之间的最大区别是新的高级安全界面和对配置及规则的完全组策略支持（请参阅图 1）。原有的“控制面板”用户界面依然存在，除了登录和 Internet 控制消息协议 (ICMP) 设置之外（现在位于新用户界面中），它基本上没有变化。这个新的用户界面（高级安全 MMC 管理单元）提供了所有全新的功能和灵活性。netsh 命令有了新的环境，即 netsh advfirewall，通过它您可以编写添加和删除规则的脚本，设置和显示全局及逐个配置文件策略，以及显示防火墙的活动状态。对开发人员而言，用 FirewallAPI.dll 和 Netfw.h 可对防火墙的所有设置进行编程式控制。
图 1 具有高级安全性的 Windows 防火墙
图 1 具有高级安全性的 Windows 防火墙
高级安全 MMC 是向导驱动的。创建规则时，您可以选择四种类型之一：程序、端口、预定义或者自定义。图 2 提供了相关说明。
Figure 2 规则的四种类型 (Close Figure 2)

类型 | 用途
程序 | 用于允许或阻止特定程序的通信。
端口 | 用于允许或阻止在特定的 TCP 或 UDP 端口上通信。
预定义 | 使用预先存在的规则组启用网络上的 Windows 功能（例如文件和打印机共享或远程协助）。
自定义 | 公开所有细节，以便您尽可以具体地配置规则。
在编写规则时可以引用许多元素，它们都适用于本地规则和通过组策略应用的规则。其中包括：Active Directory® 用户和计算机帐户及组、源和目标 IP 地址、源和目标 TCP 及 UDP 端口、IP 协议号、程序和服务、接口类型（有线、无线和远程访问）以及 ICMP 类型和代码。
配置之后，防火墙将按如下顺序处理规则：
服务限制 Windows Vista 中的某些服务对自身进行限制，以降低受到另一个 Blaster 类型攻击的可能性。其中一项限制是服务需要的端口列表。防火墙将强制实施此限制，防止服务使用（或者被引导使用）任何其他端口。
连接安全性规则 高级安全 MMC 包括了 IPsec 以及防火墙。所有包括 IPsec 策略的规则都将随后得到处理。
身份验证绕行 允许通过指定身份验证的计算机绕过其他规则。
阻止规则 明确阻止指定的传入或传出通信。
允许规则 明确允许指定的传入或传出通信。
防火墙规则存储在注册表中，但是我不准备告诉您具体的位置。噢，好吧，您可以在以下位置找到它们：
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
但请不要直接在注册表中编辑这些规则。如果您这么做，我们会找到您，然后把您的宠物拿到 eBay 上卖掉！好吧，也许不卖也行，不过唯一一种受到支持的规则编辑方法就是使用高级安全 MMC。

网络配置文件
Windows Vista 定义了三种网络配置文件：域、专用和公共。如果计算机已加入域并已成功登入域，计算机将自动应用域配置文件 — 您没有机会自己作选择。如果计算机连接到一个没有域的内部网络（例如一个家庭或小型办公室网络），您（或管理员）应当应用专用配置文件。最后，如果计算机直接连接到 Internet，您应当应用公共配置文件。
Windows Vista 如何决定在何处放置您的计算机呢？一旦出现网络变动时（例如，它收到了新的 IP 地址或发现了新的默认网关，或者得到了新的接口），一个名为网络位置感知 (NLA) 的服务将会检测到该变动。它构建一个网络配置文件（其中包括有关现有接口的信息、计算机是否已通过某域控制器的身份验证，网关的 MAC 地址等），并给它分配一个 GUID。NLA 随后通知防火墙，然后防火墙应用相应的策略（这三个配置文件都各自定义了策略）。
如果这是计算机以前从未见过的新接口，而且 NLA 也没有选择域配置文件，那么您将看到一个对话框，要求您指出将要连接到什么类型的网络。不可思议的是，这里有三种选择：“Home”（家庭）、“Work”（工作）和“Public”（公共）。您可能会认为“Work”（工作）意味着域配置文件，但实际上并不是这样。请记住，您永远不会看到域配置文件，因为在计算机登录到某个域时，NLA 会自动选择它。事实上，“Home”（家庭）和“Work”（工作）都对应于专用配置文件。功能上它们是等同的，只有图标不同。（注意：您必须是本地管理员，或能够提升到本地管理员，才能够选择该专用配置文件。)如您所料，公共对应于公共配置文件。
在 Windows Vista 中，网络配置文件应用于计算机中的所有接口。以下是一个 NLA 决策树的概况：
  1. 检查所有连接的网络。
  2. 有无任何接口连接到分类为公共的网络？如果有，将计算机的配置文件设置为公共，然后退出。
  3. 有无任何接口连接到分类为专用的网络？如果有，将计算机的配置文件设置为专用，然后退出。
  4. 是否所有接口都看到了域控制器，计算机是否已成功登录？如果是，将计算机的配置文件设置为域，然后退出。
  5. 否则，将计算机的配置文件设置为公共。
目标是尽可能选择最具限制性的配置文件。但是，这里有两个明显的副作用。首先，如果您计算机的以太网端口已连接到公司网，而无线 NIC 连接到楼下的星巴克，那么计算机将选用公共配置文件而非域配置文件。其次，如果您的计算机直接连接到 Internet（应用公共配置文件），或连接到您的家庭 LAN（应用专用配置文件），并且您通过 VPN 连接到您的公司网，那么您的计算机将继续应用公共或专用配置文件。
这可能意味着什么？防火墙的域配置文件策略包括有关远程协助、远程管理、文件和打印机共享等内容。如果您依靠这些规则连接远程客户端，而客户端又选择了其他配置文件，那么您将无法与客户端连接。不必绝望，您可以编写防火墙规则，允许您需要的任何入站连接，然后将规则仅应用于 VPN 连接。现在，即使您的客户端没有应用域配置文件，您仍然可以通过 VPN 管理它们。

控制出站连接
我曾说过，客户端防火墙中出站保护的典型形式仅仅是安全性表演。然而，有一种形式的出站控制却十分有用：以管理员身份对您不希望许可的通信类型进行控制。对于服务限制，Windows Vista 防火墙已经采取了这种措施。防火墙只允许服务与其声称需要的端口进行通信，而阻止服务试图进行的任何其他活动。在此基础上，为了符合您组织的安全策略，您可以编写其他规则来允许或阻止特定通信（请参阅图 3）。
图 3 新建入站规则向导
图 3 新建入站规则向导
例如，您希望禁止用户运行一种特定的即时消息客户端。您可以创建一个规则（当然是在“组策略”中），阻止该客户端连接到登录服务器。
不过，此方法有实际的局限性。例如，Windows Live™ Messenger（您可能仍然称之为 MSN® Messenger）有多个可以登录的服务器，而且服务器列表一直在变化。此外，如果默认端口 1863/tcp 被阻止，它会回退到端口 80/tcp。一个阻止 Windows Live Messenger 连接到登录服务器的规则将会过于复杂，而且处于不断变化之中。我提到这些是为了说明管理出站控制是有用的，但如果您需要对允许用户安装和运行的软件保持严格控制，它不能代替软件限制策略。

保护您的计算机
外围防护已经消失。现在每个计算机必须承担起自我保护的责任。正如同反恶意软件已从客户端移向边缘，防火墙必须从边缘移向客户端。您可以立即采取行动，即启用已经安装好的防火墙。
不管您的系统正在运行 Windows XP，还是已经转换到了 Windows Vista，Windows 防火墙可供您所有的客户端使用，并且提供在组织内提高安全性所需的保护，即使您的移动员工距办公室几千英里之遥也是如此。

更多详细内容
  • Windows Vista TechCenter：具有高级安全性的 Windows 防火墙入门
  • Windows Vista TechCenter：具有高级安全性的 Windows 防火墙 — 诊断和故障排除
  • Steve Riley 的 TechEd Europe 演讲：Windows Vista 防火墙和 IPSec 增强功能
  • 网络专家：Windows Vista 和 Windows Server“Longhorn”中的新 Windows 防火墙
  • Windows Vista 防火墙虚拟实验室

Steve Riley是 Microsoft Trustworthy Computing Group 高级安全策略规划师和《TechNet 杂志》的特邀编辑。他穿梭于全球各种会议发表演讲，并致力于帮助客户获得并保持安全性。他最新的著作是“Protect Your Windows Network”（保护您的 Windows 网络）（Addison-Wesley，2005）。您可以通过电子邮件 steve.riley@microsoft.com 与他联系。


 安全性: 新 ACL 改进 Windows Vista 的安全性
安全性 Jesper Johansson

新 ACL 改进 Windows Vista 的安全性
概览:
  • ACL 的新功能
  • 更严格的管理员控制
  • 可信的安装程序权限
  • 经过修改的用户和组

访问控制列表 (ACL) 的基本结构并未针对 Windows Vista 做出多大变化，但您需要对许多细小却重要的变动加以注意。某些变动
是必要的，因为在 Windows® XP 中，ACL 牵涉到了若干问题。首先，大多数 Windows XP 用户都是以管理员身份运行的。也就是说，他们使用的帐户是内置 Administrators 组的成员。对家庭用户来说，这几乎是铁定的，因为在安装过程中创建的所有帐户都会成为管理员。因此，这类用户执行的任何程序也会在执行时享有管理特权，从而可以自由访问操作系统。当然，如果这些程序属于不怀好意的软件，那么问题将尤其严重。
第二个需要解决的问题是，Windows 早期版本中的默认 ACL 令许多人感到不安，因为它们包括了针对 Everyone、Power User 等的 ACL 项 (ACE)。例如，位于 Windows XP 引导卷根目录（通常为 C:\）的默认 ACL 给予 Everyone 读取权限，而且为 Users 组成员授予创建文件夹的权限。最后，Windows XP 对可通过 ACL 进行的操作设定了限制。例如，在 Windows XP 中，绝对无法向某个对象的当前所有者分配权限。您可以将权限授予所有者，但一旦所有者发生变化，那些权限不会随之转移。同样，无论所有者分配到有关对象的何种权限，他们对于该对象始终拥有隐式权限。
在 Windows Vista™ 中，Microsoft 启动了一个新的项目来解决许多这类问题，并启用了对其他功能的支持，比如用户帐户控制 (UAC)。本文着重讲述与 Windows Vista 中的访问控制有关的主要变动。下个月，我将继续探讨您可以用来访问控制的工具上。

新的和经过修改的用户和组
Windows Vista 中有些用户和组是全新的，而有些 Windows XP 中的老面孔已被删除了。此外，有些用户和组的工作方式也得到了修改。每一种变动都对您管理服务控制的方式有所影响。
Administrator — 默认情况下禁用 内置 Administrator 帐户 — 相对标识符 (RID) 为 500 — 现在在大多数情况下为默认禁用。Administrator 的初衷为一种应急帐户，在其他所有办法失败时用以抢救计算机。不过，在过去很多情况下，它作为标准管理帐户被加以使用，并因此违反了安全性的多条原则。这些违规中最值得注意的一条是责任性，它意味着您无法跟踪更改您系统的人。因此，该帐户被部分弃用。最终，Microsoft 可能会彻底弃用该帐户，但现在它在默认情况下是禁用的。如果您在 Administrators 组中没有其他的本地帐户，RID 500 在恢复控制台和安全模式中仍可用，但在其他情况下，您无法，而且也不应使用它。
请注意，内置 Administrator 帐户与 Administrators 组的其他帐户有一个区别。我们通常将“Administrator”的首字母大写以专指具有 RID 500 的帐户，从而将其同“管理员”区分开来，后者是作为内置 Administrators 组一员的任意帐户。组名也以类似的方式进行了首字母大写。
在 Windows XP 中，内置 Administrator 帐户拥有其他管理员所不具备的许多特殊权限和特权。在 Windows Vista 中已经删除了其中许多权限和特权，但有两个值得注意的例外：第一，如果没有其他本地管理员，已禁用的 Administrator 帐户可以在恢复控制台中使用。第二，该 Administrator 不受 UAC 约束，并将一直具有完全管理令牌。同样，域管理员（域中的 RID 500）也是如此。
Power Users 权限已删除 从所有实际用途的角度来考虑，Power Users 组已被废除。该组仍然存在，但授予其的大部分权限已被删除。在过去，Power Users 的成员实际上就是管理员，只是尚未把自己提升为管理员而已 — 这几乎不是个秘密。我曾经在一台安装了所有修补程序，并且运行 Windows XP Service Pack 2 (SP2) 的计算机上，花了不到 45 分钟时间给自己授予了管理特权，从而获得了对该计算机的控制。整个过程包括初步考察、用 C++ 写一个小程序、注销，然后再登录以完成对机器的控制，这一切的实现都因为我是 Power Users 的成员。
许多组织都向 Power Users 组授予复杂的权限，并将其用户加入该组，所以在 Windows Vista 中删除该组是不可行的。但是，Microsoft 很可能在 Windows 的下一版本中彻底删除 Power Users。所以，强烈建议您着手计划从 Power Users 中迁移出去。
可信的安装程序 可信的安装程序实际上是一种服务，而不是用户，即使您会发现，在整个文件系统中，它获得了许多授权。服务加强允许将每个服务视为一个完整的安全主体，可以像对待其他任何用户一样向其分配权限。关于此功能的概述，请参阅《TechNet 杂志》 2007 年一月期刊。“Windows Vista Security”（Windows Vista 安全性）（Grimes 和 Johansson，Wiley Press，2007）一书详细探讨了服务加强，包括其他功能（如防火墙和 IPsec）如何对它加以利用。
Service SID 不由我们曾经看到的机构（如 NT AUTHORITY 或域）发放。TrustedInstaller 虚拟帐户的全名是 NT SERVICE\TrustedInstaller，它的 SID 是：
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
如图 1 所示，通过运行 sc showsid 命令，您可以查看任何服务的 SID，甚至是那些并不存在的服务。
图 1 sc showsid 会显示任何服务的 SID，包括那些尚不存在的服务
图 1 sc showsid 会显示任何服务的 SID，包括那些尚不存在的服务
此 SID 以 S-1-5-80 开头。请注意，此处的首个子颁发机构是 80，代表 SECURITY_SERVICE_ID_BASE_RID，意味着此 SID 是由 NT SERVICE 子颁发机构发放给某个服务的。任何服务均是如此。剩余的子颁发机构和 RID 以服务名称本身为基础。这使得开发人员可以为其服务授权而无需先真正构建并安装该服务，因为服务名称是确定的，不会随计算机而变化。
万一您无法在服务管理器中找到 TrustedInstaller 服务，它的显示名为“Windows 模块安装程序”。
Help 和 Support 帐户已删除 在全新安装的 Windows Vista 中，Support_xxxxxx 和 HelpAssistant 帐户均已删除；但是如果从先前版本的 Windows 进行升级，它们将被保留。Support_xxxxxx 帐户曾用于从支持中心运行脚本。有些自己提供帮助内容的 OEM 可能也提供了自己的支持帐户。OEM 帐户未来如何尚不确定，但 OEM 很可能将干脆停止创建它们。严格说来，它们不再是必需的了。实际上，从安全性的角度看，允许用户作为另一个用户从帮助中心执行脚本毕竟不是什么好主意，所以让这些帐户消失是最好不过的。Windows Vista 有一个新的机制来完成此任务。
HelpAssistant 帐户曾在远程帮助中得以使用。就像帮助中心一样，远程帮助功能已经过重新设计，以避免对 HelpAssistant 帐户的需求，该帐户也因此被删除。
新的网络位置 SID 基于 Windows NT® 的操作系统一直都有一些基于网络位置的 SID，比如 NETWORK 和 INTERACTIVE，表示从网络登录以及交互登录的用户。还有一个 REMOTE INTERACTIVE LOGON SID，分配给通过终端服务登录的用户。（注：终端服务用户在其令牌中既有 REMOTE INTERACTIVE LOGON，又有 INTERACTIVE LOGON。）在 Windows Vista 中又添加了另外两个：DIALUP 和 INTERNET。添加一个表示拨号登录的帐户的具体原因还不太明确（尤其是，如果可用的网络只是电话线，不会有越来越多的用户上网的），但此帐户确实存在。INTERNET 显然是指从局域网之外登录的任何用户。但是，NETWORK 仍然是指从网络（包括 Internet）登录的任何用户。
OWNER RIGHTS 和所有者权限 现在有一个 SID 是针对 OWNER RIGHTS 的，它适用于访问某文件而又恰好拥有该文件的任何人。它主要用于限制用户可对该文件进行的操作。与 Windows XP 相比，所有者权限的运作方式有两个显著的变化。第一，如果您是对象的所有者，但对象上有一个适用于您的 ACE，那么该 ACE 中的权限将取代您是所有者这一事实。这是一个重要变动，而且将在很大程度上影响系统管理的某些方面，因为我们都习惯了所有者拥有隐式权限。第二，OWNER RIGHTS SID 能用来进一步限制用户可对对象进行的操作。
假设有一个文件夹，所有者是用户 Jesper，其 ACL 如图 2 中所示。虽然用户 Jesper 是所有者，但他对该文件夹只有读取权限。如果他试图将一个文件复制到该文件夹中，复制将失败，因为他没有该文件夹的写入权限。不过，这一点在错误消息中体现得并不十分直观。如果您试图将一个文件复制到您拥有的某文件夹中，但不具有使用 Windows Explorer® 时的写入权限，则将发生下列情况：首先，Explorer 提示您需要提升权限才能复制该文件，并要求您进行提升，但文件复制失败的原因是您无权将任何文件复制到此文件夹中。您将收到一条错误消息，内容是“您需要权限才能执行此操作”，还有“重试”（好像这能起什么作用似的）和“取消”两个按钮。尽管您是所有者，这种情况照样发生。
图 2 只有“本地系统”和另一个用户才能够访问此文件夹
图 2 只有“本地系统”和另一个用户才能够访问此文件夹
如果 Jesper 试图更改文件上的 ACL，系统将提示他提升令牌以进行该操作。由于他是文件所有者，所以他可以这样做。所有者保有隐式读取并更改 ACL（READ_CONTROL 和 WRITE_DAC）的权限，除非某 OWNER RIGHTS 的 ACE 对其另有规定。
要了解 OWNER RIGHTS SID 的效果，让我们将其加入上面的 ACL 中。我们现在拥有的权限如图 3 中所示。
图 3 向文件夹中添加 OWNER RIGHTS 权限改变了 Jesper 的权限
图 3 向文件夹中添加 OWNER RIGHTS 权限改变了 Jesper 的权限
拥有这些权限后，如果 Jesper 帐户试图往文件夹中复制一些东西，该操作会立刻成功，因为 Jesper 是所有者而且拥有适当的权限。但是，如果 Jesper 试图更改对象上的 ACL，该操作会失败！OWNER RIGHTS 的 ACE 指定所有者仅有修改权限，而无法修改自由访问控制列表 (DACL)。因此，OWNER RIGHTS 主要用以删除所有者的 WRITE_DAC，即修改安全描述符的能力。
如果管理员更改了对象的所有者，OWNER RIGHTS 权限不会自动转移到新的所有者。在这种情况下，OWNER RIGHTS ACE 被禁用，它将标记为仅继承但不应用于容器或对象 — 换句话说，根本不将其应用到任何地方。这样做是为了确保管理员不会完全被该对象拒于门外。要使 OWNER RIGHTS ACE 重新发挥作用，Administrator 必须介入并手动重新启用 ACE。为此，您根据需要将其标记为应用于此文件夹、子文件夹和文件。
OWNER RIGHTS SID 可以在几个有意思的情况下发挥作用，比如当管理员希望用户能在文件服务器上创建文件和文件夹，但又不希望他们能更改这些文件夹上的 ACL 时。另一个可能的情形是用户曾经是某组的成员并创建了一些对象，但后来可能出于商业原因，他们从此组中被删除了。这时，他们应无法修改这些对象上的设置。
OWNER RIGHTS 在服务加强中使用的相当广泛。如果某服务在运行时创建一个临时对象，该对象的创建者是服务进程的主 SID，通常为 LocalSystem，NetworkService 或 LocalService，而不是服务本身的 SID。这意味着，在同一进程环境中运行的其他任何服务都能修改该对象 — 这当然不是人们想要的。通过在这些对象上设置一个 OWNER RIGHTS SID，操作系统能防止其他服务访问它们。

默认 ACL
Windows XP 中的默认 ACL 其实相当不错。除了一些小问题（比如允许用户将文件放在引导卷的根目录下），它们总体来说是有实际意义的。但是，一些 OEM 显然认为他们更清楚合理的安全性由什么构成。图 4 中的屏幕显示了某计算机 Windows 目录上的 ACL 图片，该计算机运行来自一家主要 OEM 的 Windows XP Media Center Edition。该 OEM 实质上禁用了文件系统安全性。
图 4 一个经 OEM 配置的 ACL
图 4 一个经 OEM 配置的 ACL
Microsoft 在 Windows Vista 中对 ACL 进行了一些调整。首先，如果您熟悉 Windows XP，您会知道所有的操作系统文件均由 Administrators 组所有，而且管理员对这些文件拥有完全控制。作为该组的一员，您可以不受限制地访问这些文件。在 Windows Vista 中则不然。
可信的安装程序 在 Windows Vista 中，大多数操作系统文件由 TrustedInstaller SID 所有，而且只有该 SID 才对这些文件具有完全控制。这是加入 Windows Vista 的系统完整性工程的一部分，其目的专门在于防止作为管理员或“本地系统”运行的进程自动替换这些文件。因此，要删除操作系统文件，您需要获得该文件的所有权，然后对其添加一个允许您删除它的 ACE。这提供了一种保护薄层，以防范作为 LocalSystem 运行并拥有 System 完整性标签的进程；具有较低完整性的进程不应具有提升自己以更改所有权的能力。例如，有些服务虽然作为“本地系统”运行，但它们运行时的完整性却为中级。此类服务无法替换系统文件，所以试图接管某个系统文件的操作将无法替换操作系统文件，这稍微增加了在系统上安装 rootkit 或其他恶意软件的难度。同样，如果系统管理员对某些系统二进制文件的存在感到不愉快，要删除这些二进制文件，难度也增加了。
Deny ACE 您会发现，文件系统中的许多对象都有针对 Everyone 的 Deny ACE，这使许多管理员感到惊愕。如果您打开“显示隐藏文件选项”，您会看到熟悉的“Documents and Settings”目录。但如果您单击它，则会收到“拒绝访问”错误。要了解“Documents and Settings”发生了什么，请查看图 5 中的目录列表。
图 5 “Documents and Settings”是一个交接点，而非目录
图 5 “Documents and Settings”是一个交接点，而非目录
“Documents and Settings”实际上根本不是目录 — 它是一个交接点！请记住，交接点类似于符号链接，只是将访问重定向到别处。在本例中，交接点指向名为 C:\Users 的目录。Microsoft 在 Windows Vista 中大幅修改了文件系统命名空间，用户数据现在已移至 C:\Users。位于旧“C:\Documents and Settings\<Username>”命名空间之下的其他元素都已迁移。例如，“C:\Documents and Settings\<Username>\Application Data”已移至 C:\Users\<username>\appdata\roaming。如果您转至命令行并使用 dir /a 命令（就像我在图 5 中所做的），您可以清楚地看到这些变化。命名空间发生如此巨大变化的原因是为了使它对于用户更加直观，并更清晰地分隔文档和数据。开发人员现在可以在用户配置文件下创建自己的文件夹（而不用将所有数据文件存储在“我的文档”文件夹中），然后用户会在那里看到它们。所有用户的应用程序数据现在进入了名为 %systemroot%\ProgramData 的隐藏文件夹，而不再位于 Documents and Settings\All Users\Application Data 下。
Microsoft 未删除“C:\Documents and Settings”命名空间，因为早期的应用程序可能已经硬编码为使用该名称，而不是首选的环境变量，比如 %USERPROFILE%。如果“C:\Documents and Settings”消失，这些应用程序将崩溃。作为一种替代方法，它们现在以交接点或符号链接的形式出现，以实现向后兼容。对这些路径进行硬编码的应用程序可能仍会崩溃，这取决于它们访问数据的方式，不过这些应用程序在非英语版本的 Windows 上已经错误百出。这是相当关键的。如果对 Windows（如 Windows XP SP2 或 Windows Vista）更新使第三方程序崩溃，这通常几乎都是因为这些程序的开发人员进行了无效的假设或以不恰当的方式使用了 Windows。
例如，如果您试图通过键入“C:\Documents and Settings\<Username>\My Documents\foo.txt”打开文件（假设您在该位置拥有一个名为 foo.txt 的文件），该文件将被打开。但是，如果您试图浏览至“C:\Documents and Settings\<Username>\My Documents”，您会收到“拒绝访问”的错误消息。要了解发生的具体情况，请查看图 6 中的 ACL。
图 6 “Documents and Settings”上有一个拒绝 ACE
图 6 “Documents and Settings”上有一个拒绝 ACE
请看列表中的第一个 ACE。这是一个针对 Everyone 列出文件夹内容的 Deny ACE。由于 Everyone 具有“绕过遍历检查”特权（也称为 SeChangeNotifyPrivilege），因此程序可以遍历交接点并通过绝对路径打开文档。由于拒绝 ACE 的存在，用户或进程将无法枚举交接点代表的目录。这就是为什么您无法查看 C:\Documents and Settings 的内容而且也无法删除“目录”的原因。将 Deny ACE 放置于此的主要目的就是防止用户删除交接点和破坏早期的应用程序。它同时还提醒开发人员不要使用旧的命名空间来对应用程序编码，而应开始使用环境变量或注册字符串以防止应用程序受未来变化和语言差异的影响。
请注意，所有这些交接点在默认情况下都是隐藏的，因此绝大多数用户永远不会看到它们。为了防止那些能看到交接点的用户将其删除，Microsoft 放入了一个针对“列出文件夹”的 Deny ACE。
绕过遍历检查 用户能够访问其无权访问的文件夹（或交接点）中有权访问的文件，原因在于每个人都有“绕过遍历检查”特权。绕过遍历检查，或 SeChangeNotifyPrivilege，实际上是 Windows 中最基本的特权，它被授予其他所有特权均已删除的进程，除非该进程也特别要求删除该特权。如果您在 Windows Vista 中使用 runas /trustlevel:0x10000 < 命令行来启动一个进程，就会发生这种情况。<command> 中指定的程序将使用一个受限的令牌运行，除了 SeChangeNotifyPrivilege 之外的所有特权都将从该进程令牌中去除。
有趣的一点是，trustlevel 0x20000 给予您具有一组正常 SID 却去除了特权的令牌。而 0x40000 可给予您完全正常的令牌。

默认权限
Windows Vista 文件系统上的默认权限相对于 Windows XP 稍有变化。如果您查看 Windows XP 或 Windows Server® 2003 中 %systemdrive%（通常为 C: 驱动器，即引导卷）上的 ACL，您会看到这些变化（或者与 Windows XP 早期版本上类似的一些内容）：
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
这是 Windows Vista 中同一目录上的同一 ACL：
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
有许多差异值得注意。首先，现在有两个针对 BA (BUILTIN\Administrators) 的 ACE，而不仅仅是一个。但是其实际效果是相同的。在 Windows Vista 中，一个 ACE 是非继承的，并授予对根目录的完全访问权限，另一个 ACE 是 IO（仅继承）ACE，由容器和对象继承，并授予 GA（Generic All 或完全控制）权限。如果用 Windows Vista 中的两个 ACE 来替代一个 SY (LocalSystem) 的 ACE，情况也会如此。在 Windows XP 中，单个 ACE 已被授予完全访问权限，并由对象和容器继承。同样，此处没有什么实际变化。ACL 发生变动的主要原因是为了将特权加以明确和中断，从而使 ACL 更易于管理，甚至还可能更易于恢复。
更有意思的是，针对 CO（创建者/所有者）的 ACE 消失了。这意味着，如果用户在文件系统的根目录创建一个对象，创建者则会因此不再获得特殊权限。
您也会发现，针对 WD (Everyone) 的 ACE 也被删除了。虽然许多曾对安全性感兴趣的人可能不完全了解自己的操作有什么含义，但他们却对该 ACE 都表示了高度的关心。Microsoft 曾花多年时间试图说明，Everyone 在功能上与内置 Users 完全一样，却没有成功；看来，他们最终放弃了尝试并彻底删除了该 ACE。由于存在同样针对 BU (BUILTIN\Users) 的 ACE，而且也被容器和对象继承，所以其实际效果未发生任何变化。
此外，两个针对 BU（内置 Users）的 ACE 已由针对 AU (Authenticated Users) 的 ACE 所取代。原因在于，Guest 帐户是内置 Users 的成员（由于 INTERACTIVE 是内置 Users 的成员），但 Guest 不是 Authenticated Users 的成员。为了允许 Guest 帐户能读取并执行文件，0x1200a9（实际为读取和执行）ACE 将继续授予给 BU。但是，授权创建文件和文件夹的 ACE 却授予了 Authenticated Users。这是与 Windows XP 的差异。在 Windows XP 中，Guest 可在根目录中创建文件。在 Windows Vista 中，Guest 无法创建这样的文件。但是请记住，除非启用 Guest 帐户，而且游客能设法访问引导卷的根目录，否则这些都没有实际意义。默认情况下，Guest 帐户是禁用的。
最好的在后面，在上面的两个列表中有一些非常有意思却看似麻烦的 ACE。在 Windows XP 中，有一个可以由容器继承的 ACE，为内置 Users 指定了 0x100004。由于该 ACE 由容器继承，因此它授权 Users 可以创建子文件夹、子子文件夹等等。还有一个仅继承 ACE，由 0x100002 的子文件夹继承。该 ACE 授权用户可以在其于根目录下创建的文件夹中创建文件和子文件夹。换句话说，这两个 ACE 允许用户，包括 Guest，在根目录下创建文件和文件夹，就像我之前所提到的那样。
在 Windows Vista 中，对应的 ACE 是一个仅继承 ACE，由容器和文件继承，授予 GR（一般性读）、GX（一般性执行）和附带 SD（读取安全描述符）的 GW（一般性写），以及一个仅适用于授予 LC 权限的根目录本身的 ACE。LC 实际上是一个属于 Active Directory® 中 ACE 的快捷方式术语。在 Active Directory 中，它表示用户可以列出子对象。但是，LC 的十六进制值是 0x4。对于目录来说，0x4 代表 FILE_ ADD_SUBDIRECTORY，它在功能上与 0x100004 相同，因为我们已经具有了来自 0x1200a9 ACE 的 0x100000（使用对象以实现同步的能力）。换句话说，它提供了与 Windows XP 中一样的效果，即用户可以在根目录下创建子目录。
十六进制值来自何处？十六进制值最初是什么？正如您已经注意到的，访问控制充满了十六进制（基数为 16）数字，比如 0x1200a9。这些实际上是对设置为“开启”的访问掩码中比特的比特掩码表示，代表它们在此特定的 ACE 中使用。当您使用工具（如 icacls、sc 或 secedit）来列出 ACL 时，如果存在 1:1 匹配，那么比特掩码由更加友好的文本字符串表示。
因此，要确定 LC 的意义，您所要做的就是访问 MSDN® 网站，查找字符串 LC，并在访问权限值栏中查找 ADS_RIGHT_ACTRL_DS_LIST。如果您随后打开 Iads.h 头文件并查找该字符串，您会发现它与 0x4 对应。对于非 Active Directory 字符串（不以“ADS_RIGHT”开头的），您通常会在 AccCtrl.h 中找到该十六进制值。一旦您有了该十六进制值，要在 WinNt.h 或 AccCtrl.h 的访问掩码中查询它的真正含义就变得简单了。
如果您在这方面需要一些帮助，您可能需要一本书，书名为“Protect Your Windows Network”（保护您的 Windows 网络）（作者：Jesper Johansson 和 Steve Riley，Addison-Wesley，2005）。书中的第 17 章深入探讨了如何分析安全性描述定义语言 (SDDL) 字符串和 ACE。
授予这些子目录的权限完全由 Windows Vista 中的 (A;OICIIO;SDGXGWGR;;;AU) ACE 控制，这是 Windows Vista 和 Windows XP 之间的最大差异。Windows Vista 将修改特权授予通过身份验证的用户，而不是像在 Windows XP 中那样，将完全控制授予子目录的创建者。
这个新 ACL 的实际结果是，对象的创建者不再拥有任何特殊权限，情况也变得较为清晰。可能最大的变化在于 Authenticated Users 甚至对管理员创建的子文件夹有了修改权限，这与 Windows XP 非常不同。在 Windows XP 中，Users 和 Authenticated Users 对管理员在根目录下创建的对象不拥有权限。但是，总的说来，虽然这些 ACE 可能看起来有些麻烦，但其实际结果与 Windows XP 的差异并不十分巨大。
总而言之，在 Windows Vista 中，所有人（包括 Guest 用户）都能读取和执行根目录下的文件。只有通过身份验证的用户才能创建新文件和文件夹，而且他们创建新文件和文件夹的同时会获得这些文件和文件夹的修改权限。换句话说，尽管在默认情况下禁用 Guest 帐户值得注意，但 Windows Vista 上的权限严格性比 Windows XP 高不了多少。

令牌的变化
在 Windows XP 中，当属于 Administrators 组成员的某个用户登录时，他的令牌包括 Administrators 组 SID，而且他可以执行任何 Administrator 组可执行的操作。另一方面，在 Windows Vista 中，情况由于用户帐户控制而发生了变化。Administrator SID 仍然存在于令牌中，但已设置为仅拒绝，如图 7 的 Process Explorer 屏幕快照所示。
图 7 在 UAC 下，除非您提升权限，否则 Administrators SID 仅用于拒绝访问
图 7 在 UAC 下，除非您提升权限，否则 Administrators SID 仅用于拒绝访问
当执行访问控制时，令牌中的这一项仅用于拒绝访问，也就是说，用于匹配 DENY ACE。任何针对该 SID 的允许 ACE 都被忽略。这意味着即使您以管理员身份登录，您也不一定一直是真正的管理员。

完整性级别
Windows 现在支持用完整性级别标记进程和对象。这些完整性级别实际上也由 ACE 体现，但不在 DACL 中。相反，它们是系统访问控制列表 (SACL) 的一部分，具有一些特殊标志。例如，标志 NW 用于表示阻止较低完整性级别的进程写入较高完整性级别的对象 (SDDL_NO_WRITE_UP)。在本期《TechNet 杂志》中，Mark Russinovich 在其文章“Inside Windows Vista User Account Control”（深入了解 Windows Vista 用户帐户控制）中详细阐述了这一内容。

总结
虽然在 Windows Vista 中对于访问控制的修改不像 Windows 2000 中那样翻天覆地，小的改动却有很多。单个看来，它们好像不是很重要，但作为整体考虑时，它们意味着您在管理系统时需要重新思考许多操作。此外，这些变化支持许多其他首创功能，特别是 UAC 和服务加强。有些管理员在刚开始使用 Windows Vista 时可能会感到很沮丧。我已经看到一些评论，说“专横的操作系统”限制了删除操作系统组件的能力 — 这些组件出于这样或那样的原因令人感到不快。但是，所有这些变化的出现都有充足的理由，而且，如果您花些时间分析变化的内容，就会理解其中的原因。

Jesper Johansson是一家大型电子商务公司的安全架构师，专门负责涵盖所有属性和服务种类的应用程序安全策略。他在安全性领域工作了 20 年，撰写了许多关于安全性的文章并出版了两本著作。在信息安全工作领域之外，他是名潜水教练。


 安全性: 通过组策略管理硬件限制
安全性 Jeremy Moskowitz

通过组策略管理硬件限制
概览:
  • 限制硬件安装
  • 限制特定设备
  • 限制各类设备

事实的确如此：这些拇指 U 盘和各种可爱的可移动媒体能为您的个人生活带来方便，但会给工作环境带来隐患。您需要一种方式来控制
哪些硬件设备可以安装，哪些不可以安装。幸运的是，使用 Windows Vista™ 以及下一版 Windows Server®（代号为“Longhorn”）中的组策略，您可以选择允许安装 USB 鼠标，但不允许安装 U 盘；允许安装 CD-ROM 读取器，但不允许安装 DVD 写入器，或者允许安装蓝牙，但不允许安装 PCMCIA 卡。
组策略中有两个部分可帮助您保护硬件安全：“计算机配置”|“管理模板”|“系统”|“可移动存储访问”（请参阅图 1）和“计算机配置”|“管理模板”|“系统”|“设备安装”|“设备安装限制”（请参阅图 2）。
图 1 组策略中的预定义硬件限制
图 1 组策略中的预定义硬件限制
图 2 自定义要限制的硬件种类
图 2 自定义要限制的硬件种类
第一组（可移动存储访问）很容易理解：如果为该类可移动存储设备（CD/DVD、软盘等）启用某一策略设置，则可以在需要时限制对所有这种类型设备的读取和/或写入。但是，它的限制功能没有“设备安装限制”强大。
在“可移动存储访问”中，包含名为“自定义类别：拒绝读取权限”和“自定义类别：拒绝写入权限”的策略设置组。这听起来不错，但可移动存储访问策略实际上并不禁止安装驱动程序 — 当检测到硬件时，表示已经安装了该类硬件的驱动程序。该策略只能禁止对设备的读取或写入。在下一部分中说明“设备安装限制”策略设置时，我将彻底禁止驱动程序本身的使用。

掌握类别和 ID
我们首先要明确的是：希望进行哪些限制。您可以考虑得较为宽泛，也可以较为具体。也就是说，可以限制特定的某“类”设备，也可以具体到单一硬件类型。或者，您还可以反过来，只允许使用特定设备类别，如 USB 鼠标。不过，棘手的是以下部分：要切实起到限制作用，您需要圈定要限制的硬件。
因此，如果希望“不允许安装游戏杆驱动程序”而“只允许安装 USB 鼠标”，则需要获取游戏杆和鼠标的信息。有一种方法是使用 Internet 搜寻硬件 ID、兼容 ID 或设备类别。不过，如果手头有这样一件设备，则会更简单。这时，可以将该设备接入计算机并查看其硬件 ID、兼容 ID 或设备类别。了解这些信息后，也就清楚该如何禁用它（或使之可用）。
在下面的示例中，我将禁用特定的声卡系列：Creative AutoPCI ES1371/ES1373。如果您希望禁用其他设备（如特定 USB 设备、USB 端口等），只需遵循下面的步骤并替换为相应设备。
在已经安装相应硬件项的计算机上启动“设备管理器”。找到设备后，右键单击并选择“属性”，然后选择“详细信息”选项卡。默认情况下，您会看到一个“设备描述”。尽管这会令人感兴趣，却没有多大用处。选择“属性”下拉列表，并选择“硬件 ID”，如图 3 所示。
图 3 设备的“详细信息”选项卡
图 3 设备的“详细信息”选项卡
“硬件 ID”页从上到下显示了从最特定到最宽泛的设备 ID。如果仔细查看“硬件 ID”值列表中的第一项，您会发现此声卡为第 2 版的 ES1371 声卡。这是一个非常具体的 ID。沿列表向下，设备描述逐渐变得宽泛，一直到包含整个系列。
此外，您还可以将“属性”更改为“兼容 ID”。它们同样描述了硬件，但没有“硬件 ID”描述那样具体。您可以选择使用“兼容 ID”中的信息，尝试将更多类似硬件圈入您的禁用列表 — 因为它的定义更为宽泛，可网罗更多结果。当然，不利的一面是可能会限制某些不希望限制的项。
最后，从“属性”下拉列表中选择“设备类别”可获得最宽泛的设备类别。在我的举例中，声卡仅显示为“媒体”。但是，许多东西都可以视为媒体，因此，描述越宽泛，越应当谨慎。
确定要使用的值后，右键单击它并选择“复制”，然后将其粘贴到记事本中妥善保管。直接原样复制是很重要的，因为在接下来的步骤中，必须精确输入该值。值中所有大小写字母必须精确保留。
如果您热衷于使用命令行而不是设备管理器来捕获硬件 ID 或设备类别，请查看 support.microsoft.com/kb/311272 上有关 Devcon 命令行实用工具的论述。另外请注意，Microsoft 为常用类别提供了许多标识符，这在您不能实际获得设备时很有帮助；请参阅 go.microsoft.com/fwlink/?LinkId=52665 上的信息。

通过组策略实现硬件访问控制
虽然我们将说明“计算机配置”|“管理模板”|“系统”|“设备安装”|“设备安装限制”（如图 2 所示）中的所有策略设置，但实际只需要其中一项来完成本例。
首先创建一个组策略对象 (GPO) 并将其链接至一个包含运行要控制的 Windows Vista 的计算机的 OU（或域，等等）。现在编辑该 GPO 并深入到“计算机配置”|“管理模板”|“系统”|“设备安装”|“设备安装限制”|“禁止安装与下列任何设备 ID 相匹配的设备”。在策略设置中选择“启用”，单击“显示”（也在策略设置中），并在“显示内容”对话框中选择“添加”。然后在“添加项目”对话框中，粘贴您之前保存的设备信息，如图 4 所示。
图 4 粘贴设备 ID 以精确捕获描述
图 4 粘贴设备 ID 以精确捕获描述
现在有个问题要注意。如果计算机已经安装了设备，它不会魔术般地自行卸载它和限制对它的访问。因此，如果您要限制硬件，应在开始部署 Windows Vista 时即执行此操作。不过，需要注意的是，任何时候删除已安装的设备然后重新安装它，Windows Vista 都将再次进行检查。因此，像拇指 U 盘那样的设备（删除后又重新安装）最符合这种情况。由于 Windows Vista 仅在重新接入设备时才进行重新检查，因此那时会对设备实施限制（即使计算机上最初已经加载了设备驱动程序）。更大的难题来自计算机附带的设备，它们没有删除后再重新接入的过程。对于这些设备，目前还没有明显有效的解决方案。
当您打开之前从未识别到硬件设备的计算机时，Windows 将尝试安装驱动程序，并在安装过程中提供状态信息。如果已经为这类设备设置限制策略，将会看到如图 5 所示的结果。
图 5 禁止安装设备
图 5 禁止安装设备

更多硬件限制
在上例中，我们只限制了一个设备。如果您希望可以走一条相反的路径，即默认限制所有硬件，然后设定允许的设备，又该怎么做呢？同样，您可以在图 2 中看到这些策略设置的列表，图中显示了组策略的“计算机配置”|“管理模板”|“设备安装”|“设备安装限制”分支部分。您可以从多个可用设置中选择。
第一项是“允许管理员忽略设备安装限制”。默认情况下，Windows Vista 上的本地管理员必须接受已设置的限制。如果您启用此设置，本地管理员可以忽略该限制并安装任意硬件。
下一项是“允许使用与下列设备安装程序类相匹配的驱动程序安装设备”。通过在此策略设置中输入设备描述，您可以明确允许在系统上安装哪些硬件设备。请注意，此策略设置仅支持安装程序类，不支持设备 ID（如示例中使用的那些项）。
要取得相反效果，您可以设置“阻止使用与下列设备安装程序类相匹配的驱动程序安装设备”。
另外两项设置“当策略阻止安装时显示自定义信息 [气球文本]”和“当策略阻止安装时显示自定义信息 [气球标题]”，可帮助您自定义该信息，如图 5 所示。
如前面所述，基于硬件类别可以指定较为宽泛的硬件描述。应当注意的是，策略设置“允许安装与下列设备 ID 相匹配的设备”不支持类别 ID 描述。若要使用类别 ID 描述，请使用“允许使用与下列设备安装程序类相匹配的驱动程序安装设备”或“阻止使用与下列设备安装程序类相匹配的驱动程序安装设备”。后者最适合与设置“禁止安装未由其他策略设置描述的设备”一起使用。通过禁止安装任何设备（默认情况），然后使用此设置，您可以精确指定要允许安装的设备。
在本例中，我使用了策略“阻止安装与下列任何设备 ID 相匹配的设备”，以基于设备 ID 来限制特定硬件类型。如果您希望使用设备类别来实施限制，必须利用其他特定策略设置，如“允许使用与下列设备安装程序类相匹配的驱动程序安装设备”或“阻止使用与下列设备安装程序类相匹配的驱动程序安装设备”。
“禁止安装可移动设备”是一种快捷的通用限制方式，可限制任何将自身描述为可移动设备的硬件设备，包括 USB 设备。此设置非常宽泛，因此最好不要频繁使用它，而应使用前面所述技术获取要限制的适当设备 ID，并具体锁定。
最后，“禁止安装未由其他策略设置描述的设备”是一项包罗甚广的策略设置，基本上限制了所有硬件，除非明确指明可以安装的设备。此策略与各种“允许”策略（如“允许安装与下列设备 ID 相匹配的设备”配合使用可生成强大的工具，只允许在您的环境中安装所希望的设备。

结束语
Windows Vista 中的组策略新增了许多强大功能，非常适于只允许在您环境中安装所希望设备的情形。您只需在部署的早期阶段实施相应策略设置，即可在网络中将不希望接入的设备永远拒之门外。
与 Microsoft 组策略首席项目经理 Michael Dennis 先生的访谈
我最近有幸拜访了 Microsoft 组策略项目的缔造者和领航员 Michael Dennis 先生。Michael 正准备离开组策略团队，在 Microsoft 内寻求其他发展机遇。我与 Michael 就过去九年内组策略的发展、现状及其未来方向进行了回顾与反思。

Jeremy Moskowitz Michael，我想许多人都想知道，您认为您在领导 Microsoft 组策略团队这段时间内所取得的最大成就是什么。

Michael Dennis 最大的成就应追溯到很久以前，那时我们正全力开发后来称为组策略的项目。我们已经在 Windows NT® 4.0 上有了系统策略，因此我们开始对这方面以及所存在的问题予以关注。因为当时正处于 Active Directory® 开发期间，所以我们着眼于需要更好地解决客户端和服务器的可管理性方面。
当时即构想以层次结构来构建组策略，这种构想之前从未实施过，这对我们是一个巨大挑战。因此，我们开始专注于核心基础结构、客户端进程以及与 Active Directory 的集成。
我们所取得的最大成就的副产物同时也是我们的最大失误所在。那是因为我们在 Windows 2000 中提供的 GUI 出现了许多问题。人们需要一个组策略专家才能有效使用它，因为管理员需要了解所有的一切是如何运作的。真希望当时就能够创建并提供组策略管理控制台 (GPMC) 和策略的结果集 (RSoP)（尽管当时的设计规范包含了这些内容）。

JM 您希望能在组策略中包含哪些内容？

MD 值得高兴的是，我希望在 Windows 2000 版本后能够包含的内容如今都已在 Windows Vista 中实现 — 例如 RSoP、GPMC，以及增加的各种设置等。真希望我们能够早些完成所有这一切。
此外，我还希望合作伙伴们能够更方便地对组策略基础结构进行扩展。我们的服务器端/客户端扩展模型要求开发人员进行大量工作。不过，也许有人会说我们的 ADM/ADMX 模板结构已经能够提供一个方便的可扩展框架。但是，如果该系统部分能够允许人们扩展更多类型的设置，那再好不过了。
我还希望 GPMC 报告功能对于合作伙伴和第三方开发人员具有更好的可扩展性。这是第三方工具供应商一直迫切希望的。

JM 人们对于组策略团队尚有哪些不了解的方面？

MD 有时人们并不清楚组策略团队在整个体系中所处的位置。人们普遍认为我们负责构建基础结构、传输以及服务器端和客户端部分。但是仅在 Windows Vista 中，我们就与 Microsoft 的 120 个不同团队展开合作，以使各项新设置在此版本中准备就绪。
读者应当清楚，组策略不应为启动或登录时的系统运行缓慢问题负责。如果出现运行缓慢的情况，应当是组策略负载的原因。如果您让组策略执行某个重量级任务，它只是按照指示执行。例如，如果让它在每台计算机上安装 Microsoft Office，那就等着吧。但是要清楚它只是在执行您的指示，它将安装所有 Office，之后才会给出登录提示。这属于运行缓慢吗？您当然会如此认为，但是作为部署它的管理员，这只是您希望系统做的。

JM 您一般喜欢使用组策略展示哪些得意之处？

MD 最近，我一直喜欢展示 Windows Vista 中所含的某些新设置。可移动设备设置（用于限制诸如 USB 记忆棒等）是人们一直以来所期盼的。Windows Vista 提供了大约 2,400 项设置，这大大提升了管理员的控制能力。我喜欢询问客户需要进行哪些控制，然后为他们展示如何实现。

JM 您为什么从 ADM 转为使用 ADMX 文件？

MD 从技术角度讲，我们不需要那样做也能在 Windows Vista 中实现新的中心存储功能。转为 ADMX 的一个重要推动因素是这使我们能够相应支持多语言。
过去，在多语言环境中，您经常会遇到无法用另一种语言充分写出 GPO 中的 ADM 文件内容的情况。由于历史原因，我们借用了 Windows NT 4.0 的 ADM 格式，它又是借用自 Windows 98，而后者又借用自 Windows 95。如果那时就有了 XML，我们的文件格式会有一个更好的选择。
但是现在，因为有了 XML，多语言支持变得更简单，并且将来还有机会针对我们目前架构化的语言进行注册表和设置增强。

JM 在 GP 团队的工作过程中，您必须克服的最大内部困难是什么？

MD 团队所面临的最大也是一直存在的问题是试图使 Windows 的其他组件能够通过策略启用其功能。
某个团队可能会说“我们刚刚构建了这一伟大的新功能。怎么会有人想要关闭它呢？”。对此我们可以理解。但是我们确实经历了许多这类问题。
此外还有与通过策略启用某些功能相关的技术难题，新推出的高级安全 Windows 防火墙 (Windows Firewall with Advanced Security, WFAS) 就是一例。WFAS 是一块难啃的骨头，很难直接通过策略正确启用它。WFAS 团队为 Windows Vista 创建的接口很好，但正确处理它却是难上加难。
在 Windows Vista 之前的 Windows 版本中，产品团队自身并不总是考虑通过策略启用他们的组件。但是，在 Windows Vista 的开发过程中，许多团队都来询问我们如何这样做。那真的令人望而生畏！
JM 您下一步准备做些什么？

MD 我正准备调到“移动信息工作者”团队，该团队负责 Smartphone、Pocket PC 等项目。我的任务会是将 Windows Server System 中的管理技术扩展到 Windows Mobile® 设备中。
我会将我对可管理性的憧憬和热情倾注到这一新领域。与此同时，我已经将组策略团队提升到一个重要地位，即使我不在，他们也能够不断向前发展。

JM 您还想对我们的读者说些什么？

MD 在组策略的整个发展过程中，一项重要措施就是面对客户，切实了解他们要做些什么。如果客户已经有了一个良好的方案结构构思，他们会希望组策略能够包容他们的想法；如果他们有了一个执行某项任务的业务案例，他们需要将情况反馈给我们。
我们有一套良好的信息反馈机制，任何人都可以通过 WindowsServerFeedback.com 向我们反馈信息。找到其中的“组策略”按钮即可。
如果大家能够明确说明“这是我的问题，这是我的业务案例，我需要系统能够完成这项任务，这是原因所在”，那么这类信息对我们来说是非常非常有价值的。那些决定实施组策略的人们应认真阅读其中提供的每个条目。
同样，如果您希望通过实施组策略获得实效，也请告诉我们您的需要。但是，请不要只是告诉我们说“我们需要一个完成某任务的策略设置”，而不告诉我们原因。“如何实现”是我们的工作要解决的，但组策略团队真正需要了解的是“为什么”。
JM 非常感谢您抽出时间和我们分享您在 Microsoft 组策略团队的经历。祝您一切都好！
MD 谢谢您，Jeremy。

Jeremy Moskowitz是 MCSE 和组策略方面的 MVP，他管理着 GPanswers.com，这是一个关于组策略的社区论坛。他负责一系列有关组策略的深入培训研讨会。他的最新著作是“Group Policy:Management, Troubleshooting and Security”（组策略：管理、疑难解答与安全性）(Sybex, 2007)。您可通过 www.GPanswers.com 与 Jeremy 联系。


 安全性: 每个 IT 组织都必须具备的 4 项安全技术
安全性 Matt Clapham and Todd Thompson

每个 IT 组织都必须具备的 4 项安全技术
概览:
  • 风险管理仪表盘
  • 反恶意软件
  • 网络异常检测

谈到 IT 安全，大多数企业确实都面临基本相同的问题。Microsoft 也不例外。我们在
Microsoft® 托管解决方案 (MMS) 的风险管理与遵从性团队工作了两年（有关 MMS 的详细信息，请参阅“Microsoft 为 Energizer 的 IT 部门充电”）。
风险管理与遵从性团队负责定义、监控和修正所有 MMS 环境的风险状况（针对面向客户的服务和基础结构协调）。早些时候，我们的经理 Arjuna Shunn 认识到我们需要一种技术解决方案，能够提供所需的控制并以集中且紧密结合的方式进行监控。下面将要讨论的技术就是这些早期想法的直接结果，也是我们两年来在自己的操作中使用各种 Microsoft 及第三方产品的经验所得。
首先，我们需要的安全技术应涵盖三种基本控制类型，即预防、检测和修正，并能提供审计和报告功能。我们发现这一工具集合可划分为四个类别：风险管理仪表盘、反恶意软件、网络异常检测以及所需的配置管理。我们尝试过在自己的风险管理操作中针对每个类别至少包含一个代表。结果我们发现，通过利用所有这四个方面的技术，IT 安全团队可以在成本与成效之间达到合理的平衡。
我们的两项主要风险管理操作 — 安全事件响应和遵从性管理 — 从这种方法中获益匪浅，但是要在这些工具中实现最终所希望的协调，仍有很长的路要走。一组结合紧密的技术可大大提高工作效率，但遗憾的是整个行业还没有这样一个集成系统。
幸运的是，IT 安全团队并非毫无希望；四个系统间更具效力的协同工作和互操作只是一个时间问题。一旦这些系统实现协同工作，它们将不仅能够主动监控系统安全状况，在审计或其他例行 IT 操作过程中也能提供很大方便。本文将描述每个系统的理想功能，并会穿插一些我们在运行时使用的示例。

风险管理仪表盘
在我们看来，风险管理仪表盘 (RMD) 是绝对必不可少的。它是 IT 安全团队运作中最为重要的技术。企业中的保密性、完整性、可用性和责任性 (CIA2) 风险经常由多个系统和过程分散监控，没有用于数据聚合、关联和风险修正的单一界面。此外，相关法规所要求的企业数据透明性的实施难度越来越大，目前没有一个优化的系统能够跟踪从创建策略到企业执行策略的过程。企业在数据采集、关联、评估、修正和遵从方面所存在的普遍困难就是证明。（图 1 所示的 System Center Operations Manager 2007 虽然不是像这里所描述的那种完整的 RMD 解决方案，但它确实为监控多个资源和收集相关警报提供了一个单一界面。）
图 1 System Center Operations Manager 2007 为跨网络查看警报和管理资源提供了单一界面
图 1 System Center Operations Manager 2007 为跨网络查看警报和管理资源提供了单一界面
数据采集因无法聚合和规范化来自分散源的数据而受到束缚。数据聚合本身就是一项挑战，因为它要求摆脱所有过于粗放的数据收集和报告方法。即使能够完成数据聚合，接下来的规范化又将带来另一个更大的挑战，因为建立支持数据规范化所需的通用框架非常困难。缺少这种规范化，将无法以一种有意义的方式比较来自不同系统的安全和运行状况相关事件。
要执行所需的自动化，风险管理仪表盘必须能够从此处所述安全技术之外的来源访问数据馈送。许多非安全性数据可用来确定总体风险状况。诸如路由器日志、资产跟踪、修补程序状态、当前登录的用户、性能报告和更改管理数据等信息都可以为事件调查员提供相关信息。因此，整个系统需要能够访问所有这些数据。我们知道，即使是最以 Microsoft 为中心的企业基础结构也会包含非 Microsoft 技术，因此，RMD 需要通过某种通用接口接受来自非 Microsoft 技术的馈送。
如果可以获得数据并将其规范化，那么下一步就是关联它。我们的目标是将一系列事件（如网络异常事件、防病毒报告事件和所需配置变化事件）关联在一起，形成一块可操作的风险相关数据。这需要大量手动工作来构建关联逻辑，该逻辑最终将产生有意义且基于风险的警报。基于当前的可用技术，要想获得这种关联逻辑的确有些困难。
评估数据同样需要大量手动工作。如果关联已完成，分析人员还必须检查关联数据以确定其效力。关联数据的效力只与它所基于的规则相当。结果是我们仍然需要人工对关联数据进行分析，以评估 IT 环境所面临的风险。此时，一个清晰且系统化的风险管理框架将有助于减少达到某一分类级别所需的人工干预工作量。缺少这种框架，要想在一个给定的实施中开发一套实际可操作的关联规则会很困难。
假设系统已到达风险评估点，下一步就是自动修正。目前，这只在企业中才能做到，即便如此，也只能是针对一组有限的技术，如修补程序管理或防病毒。以 RMD 系统为前导的自动修正功能将赋予 IT 管理员强大的能力，将 IT 风险保持在一个可接受的水平。当同时识别出多项风险时，关联逻辑应当能够基于资产分类数据帮助确定事件响应的优先级。
最后，提供遵从各种法规要求的证据也是 IT 部门面临的一个巨大难题，并且如我们所提到的，此系统应当支持这类功能。与策略相联系的集中式风险管理系统在生成报告和提供遵从性证据方面极具价值。但是策略需要解决的不仅仅是问题所在和原因。要协助自动修正，还需要将策略转换为一组可由仪表盘监控、强制实施并为其提供反馈的标准。
因此，我们可以将理想的风险管理仪表盘概括为一种为企业运行状况评估、法规和策略遵从以及风险管理过程提供统一界面的方式。实现它的方法是将来自分散的安全和运行状况相关产品以及来源的信息合并为一个与风险相关的综合显示。一个优秀的 RMD 解决方案需要能够完成以下工作：
  • 聚合、规范化和关联来自分散源的数据
  • 提供自动化信息收集和风险评估
  • 将法规要求映射到策略并支持审计和报告
  • 提供可进行修改以适应企业需要的统一框架
仪表盘应允许以有意义的方式来组织和显示数据，例如，按类型或源系统来显示首要事件、待定事件、已解决的事件等。它还应允许您深入每个报告行项以了解更多详情。在考察一个事件时，用户应当能够轻松访问任何以及所有相关数据。这将改善决策过程并加快决策速度。
我们应当指出，RMD 对于安全团队以外的管理员也很有用。由于仪表盘包含了环境的整体视图，因此 RMD 可以充当一个中心点，供所有人员查看当前状态。例如，仪表盘可以向消息团队发出有关 SMTP 网关处的拒绝服务攻击警报。虽然这是风险管理团队的安全事件，但消息团队会将其视为一个可用性事件。尽管消息团队可能并不负责调查和解决此类事件，但他们至少希望能够了解此类会影响该团队所管理资产的事件。

反恶意软件技术
一个综合性的反恶意软件系统非常重要，可以保护您的基础结构不受无法预料的威胁（隐藏在代码和用户操作中）影响。目前，一般有两种不同类型的工具可用来防范恶意软件：防病毒和防间谍软件。（例如，图 2 所示的 Windows® Defender 就属于后一类。）这两类工具都能有效防止、检测和修正不同类型的感染。但是，将这两种防护类型统一到单一解决方案中只是一个时间问题，届时系统上将只有一套反恶意软件。
图 2 Windows Defender 帮助客户端防范间谍软件
图 2 Windows Defender 帮助客户端防范间谍软件
一个彻底的反恶意软件解决方案需要进行实时监控和定期扫描。它应当基于典型的危险行为集中报告已知恶意软件（包括病毒、间谍程序和 rootkit）和未知恶意软件。强大的反恶意软件技术通过与操作系统和应用程序的紧密集成来监视所有典型的入侵点（包括文件系统、注册表、外壳、浏览器、电子邮件和连接的应用程序）。
此外，反恶意软件解决方案不仅需要涵盖主机安全性。还需要监视受感染文件通常会经其传输的常见消息和协作服务，如 SharePoint® 和即时消息。它还需要通过停止操作（已知和可疑的）以及仔细扫描用户数据以删除诸如宏病毒（隐藏在用户文档中但尚未感染系统）等内容来提供自动防护。
当然，不加以更新的反恶意软件工具是没有用的。系统必须保持其签名和删除系统处于最新状态，以提前防范最新的威胁。如果出现新的威胁，供应商应在下一个“零天”威胁爆发之前将附加保护措施准备就绪。一个易于管理的反恶意软件解决方案还应当是可集中配置和更新的。
当然，这种保护不能以损失性能为代价。如果性能有损失，那么生产力也会降低。用户甚至可能尝试禁用反恶意软件解决方案，结果是完全没有任何防范。
最后，请不要忽略为反恶意软件系统提供协助的辅助技术的重要性。防火墙、限制用户特权以及其他策略也会改善对恶意代码和用户操作的防范。

网络异常检测
反恶意软件工具用于监视系统，而网络异常检测 (NAD) 工具用于监控常见通道，监视可疑行为的已知线索并将此信息报告给 RMD 以进行修正。（例如，图 3 所示的防火墙就属于此类。）可疑行为可以是已知的攻击通信（如蠕虫或拒绝服务攻击）或通过电子邮件发送、且符合某种模式（如美国社会安全号）的数据。
图 3 防火墙是网络异常检测解决方案的重要组成部分
图 3 防火墙是网络异常检测解决方案的重要组成部分
尽管在 IT 管理方面付出了巨大努力，但任何大型企业网络无疑还会遇到偶发的恶意软件事件。NAD 可提供一种早期警告系统，有助于加速修正。此外，对于涉及数据泄漏和法规遵从性的环境，NAD 的数据监控功能以及识别和防止泄漏敏感信息的功能为保护其中的信息提供了便捷的工具。
与反恶意软件技术相同，NAD 也必须不断适应最新的威胁和敏感数据类型，否则其价值将大打折扣。此外，一个优秀的 NAD 系统还应当掌握有关真实异常的足够信息以尽可能减少误报。否则，管理员可能会忽略来自 NAD 的报告，并假设这只是又一个误发警报。
经过一定的调试和培训后，NAD 系统应当了解典型的通信使用模式并对其进行监控。这一点很重要，因为新型的恶意软件和其他攻击可能会通过改变其使用模式以新的面孔出现。网络设备在整个 NAD 系统中具有重要作用，因为解决方案必须处理来自路由器、交换机和防火墙的数据。然后，NAD 警报可由 RMD 中的关联引擎来处理。
这里，一种有趣的可能性是将网络异常检测器内置到主机反恶意软件系统或防火墙中，从而撒下一个保护网，其中所有包括在内的计算机都会帮助监视攻击威胁并可能在其扩散之前阻止这些攻击。

所需配置管理
在大型企业中，IT 部门所面临的最大挑战之一就是保持系统的正确配置。人们在维护系统配置时会出于多种考虑，例如，易于管理、简化可伸缩性、确保遵从性、防范各种形式的入侵以及提高生产力等。许多这些原因都将安全性纳入考虑范围。
在大多数企业中，鉴于其复杂性和启动成本，所需配置管理还是一个未有更多涉足的领域。但研究表明，从长远来看，对系统进行维护可节约成本并提高可靠性。所需配置监控 (DCM) 解决方案对此会有所帮助。
一个优秀的 DCM 系统应当能够自动扫描网络以确保新系统的部署如预期设想，同时还要验证所建立的系统一直满足遵从性要求。不管是在确保部署了最新修补程序方面，还是在最小化拥有域特权的用户数方面，一个完整的 DCM 解决方案必须对系统进行配置和分析，并报告每个配置趋近于理想的程度。修正过程可以很简单（例如在网络上部署新系统时为其安装修补程序），也可以是强制性的（例如为用户强制实施电子邮件客户端设置）。关键是要将它们与组织的策略和法规要求相关联。（DCM 还可以协助进行恶意软件感染识别和删除，因为在扫描结果中可以轻易找出一些简单的类型。）
DCM 是针对 RMD 的关联引擎的主要数据报告程序之一，并且 DCM 可就相关主机偏离正常状况的程度提供重要详情。数据适时与否会使安全事件的意义迥然不同，因此我们需要按照与其价值成比例的频率对资产进行扫描；例如，低敏感度的资产可能只需每月扫描一次，而中等敏感的资产每周扫描一次，高度敏感的资产至少每天检查一次。
DCM 设置也是一个优秀的网络访问保护 (NAP) 机制的基本组成部分。这样，系统便可以确认所有连接的系统都已得到正确配置，并在验证之前阻止新的或未知的系统。此外，DCM 应搜寻配置的薄弱环节（例如有关某个共享的较弱的访问控制列表），以便管理员能够采取适当措施。
不要假定 DCM 仅适用于客户端或服务器之类的主机。网络设备和核心目录本身也可以成为 DCM 所涵盖的对象。如果有一个清晰、合理的网络设计，那么由理想的 DCM 系统为关联设备强制实施相关标准就顺利成章。请考虑这种可能性！DCM 可以处理相应实施，而不必手动调节路由器配置。或者，假设一组标准组策略设置与一组特定服务器或客户端相关联。DCM 应当监控它们并在域设置更改时发送警报。
DCM 收集的数据在用于 IT 审计方面应足够可靠。优秀的 DCM 必须与变动管理和法规遵从性控制机制相关联，以便能够以及时、几乎不间断的方式解决审计事项。例如，我们的一项例行控制检查就是确定 MMS 服务器上的本地管理员成员关系没有更改。此规则的强制实施就是 DCM 的用途所在！
即使您的 IT 部门尚未准备好采用自我修正式的 DCM 系统，仍然可以部署一种替代方案（也就是需要的配置监控），并能够取得很好的效果。同样，它也可以提供有关配置问题的报告和警报，但由于修正在很大程度上需要手动完成，因此可能无法获得相同的规模效应。但重要的是，我们可以获得 RMD 所需的通知和数据以进行关联。
虽然如此，我还有一点警告。无论是我上面描述的哪种形式的 DCM，其作用范围都必须仅限于重要性最低的配置项和标准资产集合数据。否则，它将有损 IT 团队所需的灵活性。如果 DCM 配置指南已过时，DCM 将迅速变成一种操作负担，而不是有用的工具。因此，不断更新对最佳资产配置方式的认识是非常重要的。此外，根据相关资产或应用程序的最佳实践，我们建议 DCM 系统应包括对其配置指南进行定期更新。

结束语
不管是自行开发还是从知名供应商那里购买，仪表盘都是必不可少的，它是您的团队对事件作出响应的主要工具。反恶意软件也是必要的，它可以帮助防范每天都在成倍增加的各种威胁。网络异常检测处于从单纯的恶意软件签名和主机入侵检测向包含数据泄漏发现功能转变的边缘 — 这最后一项功能可帮助防止出现下一个路人皆知的网络侵害。所需配置管理虽属新生事物，但必将很快成为监控和维护配置的主流。不管由谁提供这些工具，针对这四个类别中的每一类您都必须至少具备一个工具！
就目前而言，没有一家供应商（包括 Microsoft）能够提供解决所有这四个方面问题的全面解决方案。您需要自己选择适合您特定需要的产品。本文只希望针对您需要考虑的问题、要达到的目标和理想解决方案的功能提供一些见解。

Matt Clapham 是 Microsoft IT 事业部基础结构与安全小组的安全工程师。在此之前，他在 Microsoft 托管解决方案风险管理与遵从性团队工作了两年。
Todd Thompson 是 Microsoft IT 事业部基础结构与安全小组的安全工程师。在此之前，他在 Microsoft 托管解决方案风险管理与遵从性团队工作了两年。


 安全性: 用于证书管理的强大新工具
安全性 Kevin Dallmann

用于证书管理的强大新工具
概览:
  • ILM-CM 体系结构
  • 管理和模板
  • 创建工作流

这是工作中平静的一天，突然，您接到咨询台支持团队的电话，告知您的生产系统上的一个证书已过期。现在系统已停机，在续订证书之前，贵公司会一直损失生产力（和金钱）。
如果您负责管理公钥基础结构 (PKI) 环境，相信您一定会为证书的意外过期而感到惊讶。而平静的日子，现在也成了一个梦想。
当 Microsoft 在 Windows® 2000 和 Windows Server® 2003 中添加了 PKI 服务之后，各公司实施自己的内部 PKI 环境便是一种成本低廉的好方法。遗憾的是，Microsoft® PKI 服务无法管理所生成的证书的生命周期。然而，Microsoft 最近获得一款证书管理产品，随后发布了 Identity Lifecycle Manager (ILM)，该软件结合了证书管理以及 Microsoft® Identity Integration Server (MIIS) 的身份置备和控制功能。本文将论述 ILM 如何帮助您的组织管理证书和智能卡。

ILM-CM 体系结构
ILM Certificate Management (ILM-CM) 体系结构的核心是 ILM-CM 服务器及其相关组件（请参阅图 1）。ILM-CM 服务器可安装在设置为与一个或多个证书颁发机构 (CA) 对接的单一服务器上。ILM-CM 需要 SQL Server™，后者存储了用于管理证书环境的证书信息、策略及其他相关数据。为了管理用户和安全权限，ILM-CM 服务器还需要 Active Directory®。请参阅图 2，以了解所需的组件和版本。
Figure 2 支持 ILM-CM 基础结构 (Close Figure 2)

组件 | 版本
Active Directory | Windows Server 2003
数据库服务器 | SQL Server 2000 SP3 或更高版本，或 SQL Server 2005
证书颁发机构 | Windows Server 2003 Enterprise Edition 或 Data Center Edition
SMTP | SMTP 服务器
图 1 ILM-CM 体系结构
图 1 ILM-CM 体系结构
完全安装 ILM-CM 环境后，所有的证书请求会与 ILM-CM 服务器进行通信。ILM-CM 服务器负责将证书相关的所有信息存储到 SQL Server 数据库，该数据库可用于进一步的证书报告、警报及维护工作流环境。
ILM-CM 软件体系结构主要由ILM-CM 服务器、CA 插件和客户端组件三个高级组件组成。该服务器软件可在 CA 或主要用于 ILM-CM 的服务器上安装和运行。然后，ILM-CM 服务器再与 CA、SQL Server 数据库及 Active Directory 进行通信。该服务器还提供了一个 Web 门户，供证书管理器用于配置证书策略和工作流，证书订阅者则用它来请求和续订软件证书。
为使 CA 与 ILM-CM 服务器通信，必须在您要管理的每个 CA 上安装并配置 ILM-CM 策略和退出模块。这两个模块用来将证书信息记录到数据库中。当 CA 发行证书时，退出模块负责将该信息发送到 ILM-CM 服务器，然后 ILM-CM 服务器再进一步将证书信息记录到数据库中。
如果您计划管理您所处环境中的智能卡，则需要安装 ILM-CM 智能卡客户端软件。在必须与 ILM-CM 服务器交互的所有客户端计算机上，都需要该软件。

ILM-CM 安装
安装 ILM-CM 服务器实际上非常简单 — 向导会引导您逐步完成该过程。但是，在实际运行向导之前，您需要注意一些预安装功能。
ILM-CM 首先需要的是 Active Directory 和一个 ILM-CM 架构扩展。该架构扩展添加了一些额外的 Microsoft .NET Framework 安全属性，而这些属性正是 ILM-CM 实施配置文件模板所需的。
您还需要安装 .NET Framework 2.0，而且还必须要有先前提到的组件 — SQL Server、CA 和 SMTP 服务器。如果要在不同于 CA 的单独一台服务器上安装 ILM-CM，则您必须在 CA 上安装 ILM-CM 模块，这可通过在 CA 上运行 ILM-CM 安装向导来完成。安装完成后，通过将浏览器指向 http://hostname/CLM，您便能够连接 ILM-CM 门户。
若要启用证书过期/续订通知，您需要在 ILM-CM 服务器上配置 ILM-CM 服务。首先，请在 Active Directory 中创建适当的帐户。进入 ILM-CM 服务，将该帐户添加为登录帐户。然后使用组策略，将该用户添加到 ILM-CM 服务器内的本地管理员和 IIS_WPG 组，以及“Act as part of Operating System, Generate security Audits, and Replace a process level token”（作为操作系统的一部分，生成安全审查，并替换进程级令牌）。设置 ILM-CM 服务之后，ILM-CM 服务器便能够扫描 SQL Server 数据库中的过期证书，并向证书所有者或管理器发送电子邮件通知。

ILM-CM 管理
ILM-CM 通过 Web 界面来管理，该界面划分为与用户、证书及智能卡管理任务相关的若干功能区。使用适当的管理特权连接到 ILM-CM 门户时，该门户会显示用于管理 ILM-CM 环境的多个管理任务（请参阅图 3）。“常规任务”部分提供了管理选项，包括为一套新证书或智能卡注册用户。您还可以管理和批准请求。
图 3 ILM-CM 管理门户任务
图 3 ILM-CM 管理门户任务
如果您需要查找用户或证书，请使用“管理用户和证书”任务区。这些任务让您能够查找、恢复、吊销或续订证书。另外，您还可以查找吊销列表。
如果您的组织使用智能卡，则“管理用户智能卡”部分可为您提供便利。例如，如果用户锁定了自己的卡，则证书管理器可以在此解除该卡的锁定。您还可以在本地读卡器中搜索和查看智能卡。
界面的“请求”区域允许证书管理器查看和批准用户证书请求。例如，您可以查看未决状态请求中包含的所有证书。“管理”区域可让您创建和管理配置文件模板。最后，正如您所料，“报告”区域用于开发和创建与用户及证书相关的报告。
当对 ILM-CM 门户进行身份验证时，如果您的帐户没有管理权限，则会出现一个订阅者页面，为证书用户提供自助管理功能（请参阅图 4）。通过此门户，用户可依据其具体策略配置，查看和管理其证书和智能卡。常规任务的示例包括请求证书或智能卡、查看现有证书及更改智能卡 PIN。
图 4 订阅者 用户门户页 自我管理
图 4 订阅者 用户门户页 自我管理
为发行、续订、替换和吊销证书或智能卡提供高质量、委派的工作流进程，这在任何组织中都是一个难题。而使用 ILM-CM，您现在能够委派这些任务，从而提供更高的安全保障。假设您有个用户忘记了其智能卡 PIN。使用委派工作流模式，该用户可致电咨询台支持电话，支持人员便会询问他一些验证问题。如果问题回答正确，则支持人员会为该用户将智能卡解锁。委派工作流的另一个示例是：如果发生意外删除或便携式计算机丢失事件，它能够恢复用户的加密文件系统 (EFS) 证书。

配置文件模板
配置文件模板是基础组件，可为 ILM-CM 启用完整的工作流管理过程。配置文件模板被认为是包含一个或多个证书模板的单一管理对象。配置文件模板是为管理工作流进程在证书环境中的运作方式而创建并配置的。配置文件模板的关键方面在于它能够包含多个证书模板，这些模板可作为单个项目来管理，这意味着，用户可由一个能够追踪记录证书整个生命周期过程的模板来管理。
配置文件模板可配置为将证书存储在计算机（基于软件）或智能卡（基于硬件）上。您可通过从 ILM-CM 管理门户复制一个样本来创建这些模板。在配置文件模板内，您可定义若干不同的管理策略组件（请参阅图 5）。
图 5 配置文件模板
图 5 配置文件模板
许多策略组件均适用于软件和智能卡配置文件（请参阅图 6），其中某些组件需要特别说明。在证书注册过程中，您可使用注册策略组件来定义有关您希望注册过程如何进行的特定条件。例如，您可以设置数据收集，这意味着用户需要输入诸如部门代码、电子邮件地址和管理器等信息。您还可以创建用户注册证书后便自动打印正式文档的定义。
Figure 6 软件配置文件策略 (Close Figure 6)

组件 | 说明
配置文件详细信息 | 提供配置文件模板的一般详细信息。在这里，您可以将一个或多个证书模板添加到配置文件模板。
复制策略 | 定义现有证书的工作流实体。
注册策略 | 定义注册工作流程。
在线更新策略 | 类似于续订策略，不同的是，它可以更新过期证书、证书内容、模板和智能卡小程序。
代表恢复策略 | 恢复用户的私钥或证书。
续订策略 | 定义证书过期时的续订工作流。
复效策略 | 定义复效证书的过程。
恢复策略 | 定义恢复用户证书的工作流（当存储在计算机上的用户证书被删除，或计算机被重建或被盗时）。
吊销策略 | 定义吊销配置文件内所有证书的工作流。
在线更新策略会对您的组织非常有用。它类似于续订策略，不同的是，它可以更新证书内容、证书模板、智能卡上的小程序，还可以在证书将要过期时更新证书本身。要全面使用此策略，您必须启用 ILM-CM 服务和 web.config 文件，以允许访问 Active Directory 中的多值属性。此外，您还需要在客户端计算机上安装在线更新服务。
如果贵公司使用 EFS 加密，则代表恢复策略将为您提供便利。假设某人意外删除了他的加密证书，您可使用此策略组件来设置咨询台安全团队请求用户私钥的工作流。然后，通过接收包含由 ILM-CM 服务器生成的密码的电子邮件，该用户可重新获得私钥。最后，该用户可进入 ILM-CM 服务器上的一个秘密 Web 链接，使用其相关私钥来重新获得证书。在员工离开公司，但因存档、法规或其他目的而需要恢复其数据时，代表恢复策略也会特别有用。
为提供更安全的续订过程，续订策略允许您设置加密密钥用户续订证书时所需的一次性密码和通过电子邮件发送该密码。如果您吊销了证书，之后要将其复效并从证书吊销列表 (CRL) 中删除，您可以使用复效策略定义该工作流进程。
恢复策略和吊销策略是两个独特的策略组件，它们只与软件证书策略关联，而与智能卡无关。如果存储在计算机上的用户证书被删除，或者计算机本身被重建或被盗，则恢复策略可定义还原证书或密钥（如果在 CA 上存档）的过程。管理员可使用吊销策略设置静态吊销原因，或允许执行吊销请求的人员在吊销时指定原因。
此外，还有五个专门用于智能卡配置文件模板的管理策略，如图 7 所示。
Figure 7 智能卡配置文件策略 (Close Figure 7)

组件 | 说明
替换策略 | 定义用户智能卡丢失或被盗时的配置文件。
禁用策略 | 定义在智能卡上的证书过期之前禁用证书的过程。
退废策略 | 定义吊销智能卡上所有证书的过程。
解锁策略 | 定义可以对智能卡的用户 PIN 进行解锁的人员。
临时卡策略 | 定义一个短期的替换智能卡。用户会收到新签名证书，但在获得现有配置文件加密证书之后，便能将其数据解密。
您可为退废策略定义若干不同操作，如擦除智能卡上的用户数据、锁定用户和管理 PIN，以及重设管理 PIN。如果用户忘记了自己的 PIN，或新卡已附带由 ILM-CM 分配的 PIN，则通常会使用解锁策略。然后，该用户会请求为智能卡解锁。
对于任何管理产品而言，报告都是一项非常有用的功能。捕获您的证书或智能卡环境的快照这一功能对于任何组织来说都非常重要。ILM-CM 带有若干内置报告，包括智能卡清单、请求摘要、证书使用和过期以及许多其他内容。对于其他报告系统，如果您需要其他报告，则可以编写自定义查询，因为所有数据都存储在 SQL Server 数据库中。

开发工作流
现在让我们看一下 ILM-CM 如何帮助定义高效的工作流进程。假设您有若干系统管理员负责管理和维护其系统的 SSL 证书。要问的第一个问题是：该过程的关键方面是什么？
根据系统类型，该过程可能需要不同的方法来创建证书请求文件。因此，首要的任务就是开发一个 Intranet 页面，详细说明如何创建所有系统的证书请求。
管理员创建请求文件后，便可以将它提交到 ILM-CM 用户门户进行证书审批。使用 ILM-CM 工作流进程，管理员可以定义若干需要确认和批准证书请求的审批者。证书经批准后，用户便可从 ILM-CM 取回证书。由于 ILM-CM 将证书信息放在 SQL Server 数据库中，因此管理员能够检索历史信息。
一年之后，当证书快要过期时，ILM-CM 会向请求者发送电子邮件通知，告知其证书即将过期，必须立即续订。恰当处理此工作流进程有助于防止证书意外过期，避免给您带来麻烦。

总结
如果贵公司使用 Microsoft PKI 环境，ILM-CM 可以帮助您管理该环境。ILM-CM 可使组织改进安全身份验证过程，并降低数字证书和智能卡管理的成本与复杂性。同时，ILM-CM 还是开发证书和智能卡工作流进程的基础，而这正是目前许多公司所缺乏的。
Microsoft 还实现了对 ILM-CM 的外部 API 支持。如果贵组织使用自定义应用程序，您可以对接这些应用程序，以便充分利用 ILM-CM API 支持。
有关 ILM-CM 的详细信息，请参阅 microsoft.com/technet/clm。同时还提供了快速入门指南 (go.microsoft.com/fwlink/?LinkId=87336)。

Kevin Dallmann 是 Accenture 的高级系统工程师顾问，主要负责支持大型企业环境的 Active Directory 和 PKI 环境。Kevin 持有 MCSE 和 MCT 证书，并在讲授 Microsoft 课程。


 编辑视角: 安全问题
编辑视角
安全问题
Joshua Trupin

您是否注意到， 安全问题近来变得更易于管理了？的确，我们希望因它而在《TechNet 杂志》获得所有好评，但其实还有其他一些因素在起作用。其中最主要的两点是意识和稳定性。
“意识”简单地说就是做好防范潜在威胁和社交工程恶作剧的准备工作，并随时掌握保护已安装软件的定期补丁和更新动态。“稳定性”则是硬币的另一面，即想方设法将软件构建得更加安全，并通过默认设置关闭一些暴露的功能，尽量减少受攻击面。
对了，还有另外一点 — 定期阅读《TechNet 杂志》。别忘记哦！您现在手握的这期杂志就是我们小有名气的“Security”（安全）专刊，它包含了不下七篇文章，这些文章可帮助您成为公司中更加令人刮目相看的安全分析师及行业专家。Mark Russinovich 从介绍 UAC 内部信息开始，而 Steve Riley 深入探讨 Windows 防火墙，Jesper Johansson 则探究 Windows Vista 中的 ACL 更改。我们还让 Jeremy Moskowitz 介绍了“组策略”和硬件锁定，Michael Murgolo 提供了脚本评估 PowerToys，以及其他内容。毋庸置疑，您现在手握的这期专刊可谓一份绝无仅有的好杂志。
在您保持高度警惕的同时，您还应了解 Microsoft 提供的最新安全产品。Microsoft Forefront 代表“稳定性”要素，它是一套企业安全产品，可在客户端操作系统、应用程序服务器和网络边缘这三个方面提供保护。它不仅包括用于 Exchange Server 和 SharePoint 的安全工具，而且还包括用于网络通信的 ISA Server 和智能应用程序网关 (Intelligent Application Gateway)。Microsoft System Center 体现了难题中的“意识”部分，它可以让您搜集关于系统的知识、简化操作和管理、生成报告以及加强服务交付。除其他工具以外，它还包含了下一代配置管理和操作监视技术。
若要了解 Forefront 和 System Center 的更多信息，请访问 Microsoft 基础架构网站，网址为 Microsoft.com/infrastructure。若要为您的安全难题获取顶级解决方案，请阅读《TechNet 杂志》来保持意识性和稳定性。
—Joshua Trupin

谨向以下 Microsoft 技术专家致以衷心感谢：Conrad Bayer、David Cross、Michael Dennis、Shon Eizenhoefer、Jason Garms、Russ Humphries、Jesper Johansson、John Lambert、Eric Perlin、Mark Russinovich、Jon Schwartz、David Solomon、Greg Stemp、John Stephens、Kevin Sullivan、Jim Truher 和 Buck Woody。


 工具箱: 面向 IT 专业人员的新产品
工具箱 面向 IT 专业人员的新产品 and Greg Steen
myLittleAdmin 具有可换肤的界面
基于 Web 的 UI 支持大多数数据库操作，包括创建新数据库、管理现有数据库及其内容以及处理快照和架构。编辑现有数据库对象的属性很简单，myLittleAdmin 具有一个非常精致的可编辑数据网格，可用于修改表中的各行。该应用程序的树视图界面与 SQL Server Management Studio 中的树视图界面非常类似，因此无需专门进行学习。唯一不便的是某些熟悉的右键单击操作不会弹出预期的上下文菜单。
您还可以使用 myLittleAdmin 来编辑登录信息、服务器角色以及您的 SQL 实例的凭据。它甚至允许您创建和编辑备份设备和链接的服务器 — 这些都是能够从远程位置执行的很有用的任务。
myLittleAdmin 还允许您执行诸如即席查询、连接和分离数据库、备份和恢复、导入 CSV 数据以及压缩数据库等任务。您甚至可以浏览到错误日志和活动监视器以执行故障排除。
价格：单服务器许可证为 590 美元。作为客户虚拟主机工具集的一部分，单服务器许可证为 990 美元。


 SQL 问题解答: 64 位安装、分配群集内存及其他
SQL 问题解答 64 位安装、分配群集内存及其他 and 编辑：Nancy Michell
图 1Windows Live 中的 SQL Server 联机丛书搜索
但是，假设 SQL Server 拥有服务器上的所有 RAM，并且启动了一个新的 SQL Server 实例。此时原始 SQL Server 实例的内存会发生什么情况？我似乎应当为最坏的情况做打算 — 即只有一个节点在运行，且所有 SQL Server 实例在该节点上都结束运行。
回答：一般认为，最好将最大服务器内存设置为少于计算机中可用内存总量的某个值。不过，对于您的情况，内存总量的三分之一是否为最佳配置值得商榷。
您担心的是群集中四台服务器中有三台可能同时停机，并且三个 SQL Server 实例将在第四个节点上都结束运行。但是，这种情况不大可能出现。
在大多数情况下，您最好将每个实例都配置为使用每个节点所能提供的大部分内存。假设每个节点具有 32GB 的 RAM，那么将每个实例的最大服务器内存设置为 28GB 是比较合理的。
现在，在节点出现故障时，该节点上运行的实例将转移至被动节点，并且可能会获得对 28GB 内存的访问。其他两个实例将不受影响；它们仍在该群集内的另外两个节点上运行。
您描述了一个四节点的故障转移群集，并具有五个 SQL Server 实例和一个 Analysis Services 实例。如果您运行带有地址窗口化扩展插件 (AWE) 的 SQL Server 2000，则为关系引擎实例设置的内存容量须经仔细选择，因为这些实例不会放弃所得到的内存。对于更为灵活的 SQL Server 2005 和 64 位实例（能够在有或没有 AWE 的情况下访问较大的地址空间），情况又有所不同；即使您在此情形下使用了 AWE，它也是动态的，并会在收到请求时释放内存。因此，对于原始 SQL Server 实例所发生的情况以及在故障转移情况下（其中在该服务器上启动了一个新实例）它所获得的内存，取决于您运行的是 SQL Server 2000 还是 SQL Server 2005，以及您是否使用了 AWE。
为最坏的情况做打算原则上是可取的，但在实践中，除非您的系统确实进行了超工程设计，否则不大可能出现这种情况，即在运行五个 SQL Server 关系引擎实例和一个 Analysis Services 实例的群集中，当四个节点中的三个都失败时仍能继续工作。余下的节点将没有足够的 CPU 资源为原始实例提供相当性能水平的服务。鉴于这种情况，您最好将该解决方案设计为在丧失一个节点时能够维护最佳性能，但在丧失多个节点时可能需要一些手动干预。这可能会在提供高可用性 (HA) 支持的同时，还能获得宝贵资源的有效利用，从而达到两者的完美结合。
最后，对于 SQL Server 2005，最终用户可以将群集扩展到八个节点。在 SQL Server 2000 中，最有可能出现四个节点的群集。

镜像限制
问题：在研究 SQL Server 2005 数据库镜像时，我发现了一个限制，即数据库镜像只能支持每个服务器实例最多 10 个数据库。我的要求是有两个独立的 SQL Server 实例，具备单独的存储、两个实例间的自动故障转移和数据冗余功能。
我计划使用对等 (P2P) SQL Server 2005 事务复制和 Microsoft® Cluster Server (MSCS)，其中我要有一个以两个节点之一为源的群集 IP，这样所有插入、更新、删除和读取通信都转至该群集中的一个节点。我想将第二个节点作为被动节点，但是会向其复制事务。在出现故障时，MSCS 会将该 IP 转移到另一个节点，并且因为它配置为 P2P 且是双向的，所以这里没有（在备份后）开始将事务发布到另一个节点的手动过程。我在 MSCS 内使用多数节点集 (MNS) 配置来缓解对用于仲裁的共享磁盘资源的需要。
仍然选择使用镜像，我们将每个 SQL Server 群集的数据库数从 1000 降到 100。同样，我是否应当将该类型的资源负载放在系统上？
回答：有关 SQL Server 镜像的信息或指南，请访问 BOL 或 SQL Server 技术中心，网址分别为 microsoft.com/technet/prodtechnol/sql 和 msdn2.microsoft.com/sql。
您的问题引发了许多讨论。经过整理后，下面是有关您的情况的最佳响应：
第一个响应是对于给定实例中可镜像的数据库数没有强制性限制。我猜想您是参考了一篇文章，其中提到一个最佳实践是每个实例不超过 10 个数据库镜像，但那只是一个近似值，实际上没有任何特定的强制性限制；这完全取决于给定系统上的可用资源。
可以选择使用镜像，但是 1,000 个数据库无疑会带来巨大压力，除非您有一个非常强大的服务器。如果您不希望使用共享存储，并且希望使用内置 SQL Server 技术，则可以尝试使用镜像、日志传送或复制。每个功能的利弊各有不同。
第二个响应是如果您具有大量数据库而没有使用共享存储，并且希望使用 Microsoft 提供的灾难恢复解决方案，则应考虑日志传送，它使用一组自定义的小帮助器程序来缓解管理开销。程序可以按顺序备份和恢复每个数据库，因此您不必运行多个日志传送代理。请注意，这有可能会丢失数据。没有既不需要共享存储也不需要 DBMS 就能确保不丢失数据的内置解决方案。
当然，这里存在 MSCS 如何进行检测和故障转移的问题。群集中的 MNS 配置通常不会消除对共享存储的需要，它们只会消除为仲裁提供专用共享 LUN 的必要性。使该计划可行的唯一方式是将群集配置为只管理 IP 和网络名称。如果没有共享存储，则不能对 SQL Server 进行群集，因此您不能群集 SQL 服务，这意味着群集将无法检测和监控典型配置中的 SQL Server 服务。
您可以将 SQL Server 服务作为要监控的一般服务进行添加，以此来群集 SQL Server 服务，但在故障转移时会出现问题：假设要群集该服务，MSCS 将尝试使该服务在故障转移时在被动节点上联机，但某个 SQL 服务可能已经在那里运行。当然，您可以使用它来只群集 IP 和网络名称，然后在需要时手动进行故障转移。您可以使用网络负载平衡 (NLB) 来完成相同的任务，NLB 是在别处完成的。有关详细信息，请参阅 microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx 上的文章。
对于给定的要支持的数据库数量，日志传送解决方案可能更适合。当然，您需要使用数据转换服务/SQL Server 集成服务 (DTS/SSIS) 程序包来自动执行该过程，否则可能耗时过长，以至无法在故障转移过程中手动备份、移动和应用主动日志。

衷心谢谢以下 Microsoft IT 专家，感谢他们与我们分享了技术与专业知识：Boris Baryshnikov、Chad Boyd、Alan Doby、Patrick Gallucci、Cindy Gross、Chuck Ladd、Pat Martin、Vipul Shah、Nelson Taggart、Kartik Tamhane、Ken Tanner、Chuck Timon、George Walters、Kevin Warren，尤其要感谢 Buck Woody。


 实用工具特别推荐: Windows Vista 的脚本提升 PowerToy
实用工具特别推荐 Windows Vista 的脚本提升 PowerToy and Michael Murgolo
下载这篇文章的代码: Utility2007_06.exe (159KB)
尽管用户帐户控制在安全性方面提供了重要改进，但能够提升权限对于执行特定管理任务和功能也变得至关重要。下面是若干提升 PowerToys，可使提升行为更加灵活和强大。
在 Windows Vista 引进的诸多安全性功能中，用户帐户控制 (UAC) 是最重要的功能之一。使用用户帐户控制，即便是管理员用户也使用标准特权来运行大多数应用程序，但是针对特定管理任务和应用程序功能具有
“提升权限的可能”。在使用 Windows Vista™ 一段较长的时间后，根据需要来提升任务和应用程序的权限已渐成自然。不过，在 Windows Vista 中尝试提升某些类型的任务时，我也遇到许多不便之处，令人感到沮丧。
因此，本着以前的 Windows® PowerToys 的精神，我创建了一些脚本提升 PowerToy 来克服这些限制。您可以在位于 technetmagazine .com/code07.aspx 的代码下载中找到我将要讨论的所有 PowerToy。您还可以参阅 2006 年 11 月 Alex Heaton 的文章“用‘用户帐户控制’实现非管理员操作之梦”，了解 UAC 是如何工作的（请参阅“更多资源”侧栏）。

提升命令 PowerToy
第一件令人不快的事情是无法从命令行或“运行”对话框提升应用程序。因此在 Microsoft 内部进行了广泛咨询后，我从 John Stephens（Microsoft 的软件设计工程师）那里得到了一个示例脚本，提供了我所需要的信息。事实上，如果您将动词“runas”传递给 ShellExecute API 或其 COM 等效项（Shell.Application 的 ShellExecute 方法），所启动的应用程序将提示进行提升（有关详细信息，请参阅侧栏）。这就允许我创建了第一个提升 PowerToy — 提升命令 PowerToy。
此工具（由 ElevateCommand.inf、elevate.cmd 和 elevate.vbs 文件组成）将向您的系统添加一个 elevate 命令。这允许您从命令行、脚本或“运行”对话框中启动提示进行提升的应用程序。例如，以下命令将用记事本打开 Win.ini（在提示进行提升之后）：
elevate notepad c:\Windows\Win.ini
在 Windows Script Host (WSH)、Windows PowerShell™ 或其他脚本中使用 elevate 命令时，需要将脚本宿主可执行文件（如 wscript、cscript 或 powershell）指定为该应用程序。例如，要运行 vbs，您需要使用如下代码：
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
图 2带有提升特权的提示符

安装和实施
要安装这些 PowerToy，请右键单击相应的 INF 文件，选择“安装”，并批准提升。要将其卸载，请使用“控制面板”中的“程序和功能”选项。
如果您深入到 INF 文件之内并想了解为什么这三个 PowerToy 将 elevate.cmd 和 elevate.vbs 安装到不同的位置，我会加以解释。多数 PowerToy 都是通过在注册表中向相应对象类型的 HKEY_CLASSES_ROOT\objecttype\Shell 项添加一个 runas 子项来实现的。
但是，对于某些 PowerToy，我希望某些对象类型能有两个上下文菜单项来引起提升（对于 Drive 和 Directory 对象类型，为“以管理员身份在此处打开命令提示符”和“以管理员身份在此处打开 PowerShell 提示符”；对于所有 WSH 对象类型，为“以管理员身份运行”和“使用命令提示符以管理员身份运行”）。由于每个对象类型只能有一个 runas 项，因此我不得不通过调用 elevate 命令来实现第二个操作。但是，由于我希望每个 INF 能够独立安装和卸载，所以必须将关联的 elevate.cmd 和 elevate.vbs 副本放在不同的位置。（您不能根据原始 INF 文件递增文件的使用计数。诚然，MSI 安装程序会更好些，但我需要的是能够使用文本编辑器创建和修改的安装程序。）这种处理的一个不利方面是只有使用 runas 项实现的上下文菜单项才会在菜单中显示一行。

总结
我希望您发现这些工具很有用，并能改善您的 UAC 体验。或许它们还会激发您创建自己的 PowerToy 的兴趣。（对于那些在 Windows Vista 上使用其他脚本语言（如 Perl 或 Python）的人们，为那些语言创建“提升脚本”PowerToy 也应当不难。）对于所有 PowerToy 工具，我们不提供相应支持，一切风险自负。不过无论如何，希望您在提升中找到乐趣！
更多资源
  • 用“用户帐户控制”实现非管理员操作之梦
  • 用户帐户控制概述
  • 通过 ShellExecute 提升
  • ShellExecute 方法
  • 动词和文件关联
  • 旧的 PowerToy 重获新生


 网络专家: 安全套接字隧道协议
网络专家 安全套接字隧道协议 and Joseph Davies
本期专栏基于 Windows Server 的一款预发布版本，其代号为“Longhorn”。文中的所有信息可能会有所变动。
Windows XP 和 Windows Server 2003 中的 VPN 协议不适用于某些配置。深入探讨各种问题，并了解 Windows Server“Longhorn”和带有 Service Pack 1 的 Windows Vista 如何使用“安全套接字隧道协议”解决这些问题。
Windows XP 和 Windows Server 2003 支持虚拟专用网络 (VPN)，可让您通过 Internet 连接到您的专用 Intranet，就像计算机插入了本地以太网端口一样。但是，Windows XP 和 Windows Server 2003 中的 VPN 协议不适用于某些防火墙配置
以及某些间接配置，例如当您的计算机在网络地址转换 (NAT) 或 Web 代理服务器之后时，VPN 连接的通信在其中会被阻断。为解决这些难题，下一版本的 Windows Server®（代号为“Longhorn”）和带有 Service Pack 1 的 Windows Vista™（两者均在进行 Beta 测试）将能够支持这一新的“安全套接字隧道协议”(SSTP)。

VPN 访问问题
在 Windows® XP 和 Windows Server 2003 中，在 Internet 上实现 Intranet 远程访问连接的 VPN 协议便是“点对点隧道协议”(PPTP) 和“基于 Internet 协议安全性的第二层隧道协议”(L2TP/IPsec)。它们会对在远程访问客户端以及与其连接的 Intranet 之间发送的数据包进行封装。
基于 PPTP 的 VPN 通信由两部分组成：连接到 VPN 服务器上 TCP 端口 1723 以执行隧道维护工作的 TCP 连接，以及 VPN 数据的“基本路由封装”(GRE) 封装数据包。但 PPTP 通信与防火墙、NAT 和 Web 代理之间存在问题。要防止这些问题发生，必须将防火墙配置为允许 TCP 连接和 GRE 封装数据。虽然 GRE 是封装 IP 数据包的标准方法，但许多 Internet 服务提供商 (ISP) 却丢弃了这些数据包，因而造成数据丢失。此外，旅店和咖啡馆中的连接通常配置为用于普通的 Web 和电子邮件通信，可能不允许 PPTP 通信。而且，如果您的计算机在 NAT 后，则该 NAT 必须能够转换 GRE 通信。如果不能转换，您将仍然能够建立 TCP 连接，但却无法发送或接收任何 GRE 封装数据。最后，PPTP 通信也无法通过 Web 代理。
Windows XP 和 Windows Server 2003 中运作的另一个 VPN 协议 L2TP/IPsec 使用“Internet 密钥交换”(IKE) 来协商对 VPN 通信的 IPsec 封装式安全措施负载 (ESP) 保护，并且它也可能存在防火墙、NAT 和 Web 代理问题。
在此设置中，需要将防火墙配置为同时允许 IKE 通信和 ESP 封装数据。如果您的 VPN 客户端计算机位于 NAT 之后，则 VPN 客户端和 VPN 服务器都必须支持 IPsec NAT 遍历 (NAT-T)。但是，请注意，VPN 服务器不能位于 NAT 之后，并且该 L2TP/IPsec 通信不能流过 Web 代理。

新的 VPN 解决方案
如您所见，围绕 Windows XP 和 Windows Server 2003 中的 VPN 协议操作存在诸多问题。好消息是，带有 Service Pack 1 的 Windows Vista 和 Windows Server“Longhorn”中的 SSTP 通过使用 HTTP over SSL（SSL 即安全套接字层）解决了这些 VPN 连接问题。SSL 也称为“传输层安全性”(TLS)。TCP 端口 443 上 SSL 上的 HTTP 是在 Web 上使用了一段时间、用来收集信用卡号和其他私有数据的协议。每次连接到以 https: 开头的 Web 地址时，您都在使用 HTTP over SSL。
使用 HTTP over SSL 可解决诸多 VPN 协议连接性问题 — 防火墙、NAT 和 Web 代理通常允许此类通信，因为它使用非常广泛。
SSTP 在 VPN 客户端和服务器之间使用 HTTP-over-SSL 会话来交换封装的 IPv4 或 IPv6 数据包。请注意，基于 HTTP-over-SSL 的远程访问 VPN 连接与使用 HTTP over SSL 的应用程序所执行的连接是不同的。例如，Outlook® Web Access (OWA) 可让您通过 Internet 在企业中访问您的 Microsoft Exchange 电子邮件。OWA 使用了 HTTP over SSL 加密会话，但这与远程访问连接是不同的。虽然您可以使用 OWA 查看您的电子邮件，但您不能访问嵌入 Exchange 电子邮件中的 Intranet URL 的位置。
（SSTP 不支持通过验证的 Web 代理配置，其中该代理在 HTTP 连接请求期间会要求某种形式的身份验证。）
在 Windows 中实施 HTTP-over-SSL 能够大幅度降低远程访问解决方案的维护成本。例如，HTTP over SSL 能够减少咨询台的支持问题，并消除位于 NAT 之后的 VPN 服务器相关问题。并且，SSTP 能在任意地点运作，因此用户会更满意且更高效。
由于 SSTP 内置于 Windows 中，因此您无需考虑在客户端计算机上安装和管理第三方 VPN 客户端软件，或在 VPN 服务器上安装额外软件。此外，SSTP 能够通过可用的 SSL 负载平衡器来提供更好的 VPN 连接负载平衡。
SSTP 新增功能
  • SSTP 集成了对网络访问保护 (NAP) 的支持，而 NAP 可通过强制符合系统运行状况要求来更好地保护网络资产。有关 NAP 的详细信息，请访问 microsoft.com/nap。
  • 此外，SSTP 还支持 SSTP 隧道内发送的本地 IPv6 通信和 IPv6 Internet 上基于 IPv6 的 SSTP 连接。
  • 而且，SSTP 建立了从 SSTP 客户端到 SSTP 服务器的单个 HTTP over SSL 会话。基于 SSL 的其他第三方 VPN 解决方案则使用两个 HTTP over SSL 会话。使用单个 HTTP over SSL 会话能够降低网络负荷，并改善负载平衡。
  • 最后，SSTP 完全集成到带有 Service Pack 1 的 Windows Vista 和 Windows Server“Longhorn”的 VPN 客户端组件，以及 Windows Server“Longhorn”中的“路由和远程访问”。SSTP 是另一个 VPN 协议，可使用所有用于基于 PPTP 或 L2TP/IPsec 连接的相同身份验证协议和配置方法，例如“网络连接”(Network Connections) 文件夹和“连接管理器”(Connection Manager)。
与 Windows XP 和 Windows Server 2003 中的 PPTP 和 L2TP/IPsec 协议不同，SSTP 不支持站点对站点的 VPN 连接。

Windows 中的 SSTP
运行 Windows Server“Longhorn”及“路由和远程访问”的计算机是基于 SSTP 的 VPN 服务器。您无需安装 IIS，因为“路由和远程访问”会侦听特定统一资源标识符 (URI) /sra_{BA195980-CD49-458b-9E23- C84EE0ADCD75}/ 上的传入连接。然而，“路由和远程访问”与 IIS 能够在同一服务器上共存。
运行 Windows Vista（含增强功能，计划随同 Service Pack 1 一同推出，目前预计在今年晚些时候发行）或 Windows Server“Longhorn”的计算机是基于 SSTP 的 VPN 客户端，能够将 SSTP 初始化连接至基于 SSTP 的 VPN 服务器。SSTP 服务器必须安装具有“服务器身份验证”或通用“增强型密钥用法”(EKU) 属性的计算机证书。SSTP 客户端将使用此计算机证书，以便在建立 SSL 会话时对 SSTP 服务器进行身份验证。SSTP 客户端会验证 SSTP 服务器的计算机证书。若要信任该计算机证书，则必须在 SSTP 客户端上安装由 SSTP 服务器计算机证书发行 CA（证书颁发机构）提供的根 CA。
图 1 对 Windows Server“Longhorn”和包含 Service Pack 1 的 Windows Vista 中不同 VPN 协议的属性进行了比较。侧栏“SSTP 新增功能”介绍了 SSTP 的功能。
Figure 1 比较不同的 VPN 协议 (Close Figure 1)
图 2SSTP 数据包的结构
首先使用 PPP 标头和 SSTP 标头封装 IPv4 或 IPv6 数据包。由 SSL 会话加密 IPv4 或 IPv6 数据包的组合、PPP 标头和 SSTP 标头。添加 TCP 标头和 IPv4 标头（用于 IPv4 Internet 上的 SSTP 连接）或 IPv6 标头（用于 IPv6 Internet 上的 SSTP 连接），以完成数据包。
有关 SSTP 的详细信息，请参阅“路由和远程访问博客”，网址为 blogs.technet.com/rrasblog。


 Windows Powershell: 使用 Active Directory
Windows Powershell 使用 Active Directory and Don Jones Windows PowerShell 并未提供一个 Get-ADSIObject cmdlet，但这并不妨碍它提供强大的 ADSI 支持。本文简单介绍了类型适配器，并阐述了如何使用 Windows PowerShell 来处理目录对象。
如果您曾经玩过 Windows PowerShell，那么您一定尝试过 Get-WMIObject cmdlet — 也称为 gwmi，这是它更为方便的别名。如我在上个月的专栏中所述，此 cmdlet 展示了 Windows PowerShell 相对于以前的脚本语言和命令行外壳的一项重要改进
（请参阅 technetmagazine.com/issues/2007/05/PowerShell）。通过 Gwmi 可以快速、方便地访问 Windows® Management Instrumentation (WMI)，从而可以完成许多令人难以置信的工作，而无需编写复杂的脚本。
Get-WMIObject 就是尽显 Windows PowerShell™ 能力的一个最佳例证，每当我在课堂上展示它时，学生们总是能够将它的功能拓展到 Windows 管理的其他方面。但是，通常人们提出的第一个问题总是围绕着“存在 Get-ADSIObject cmdlet 吗？”。

Windows PowerShell 中的 ADSI 支持
ADSI 是 Active Directory® 服务接口的缩写。尽管其名称如此，但实际上 ADSI 并不是特定于 Active Directory 的。该名称更为精确的解读应该是“Active（停顿）Directory Services Interface”（活动的目录服务接口），因为 ADSI 可以连接到各种目录服务，其中包括 Windows NT® 样式的目录 — 注意，不仅仅是 Windows NT 域，还可以连接到独立的或成员计算机上的本地安全帐户管理器 (SAM)。凭借这种灵活性，Get-ADSIObject cmdlet 无疑用途广泛。但遗憾的是，Windows PowerShell 团队未能在其第一版中纳入该 cmdlet。
但这并不是说 Windows PowerShell 缺乏 ADSI 支持。事实上，Windows PowerShell 中的 ADSI 支持是如此优秀，您甚至不会注意到 Get-ADSIObject cmdlet 的缺失！
这一切始于 [ADSI] 类型适配器。我们需要对类型适配器稍加解释。我们知道 Windows PowerShell 是在 Microsoft® .NET Framework（具体而言，是 2.0 或更高版本）上构建的。因此，Windows PowerShell 中的几乎所有内容 — 从 WMI 对象到文件和文件夹 — 都表示为该 Framework 中的对象。但是，Windows PowerShell 团队并不喜欢只将原始的 Framework 对象呈现给 Windows 管理员。例如，许多 Framework 对象的使用都有一定的不一致性，而一致性是 Windows PowerShell 的一个主要设计目标。另一个原因是某些 Framework 对象在涉及 Windows 管理时有些多余，而简洁性也是 Windows PowerShell 设计思想的一个主要方面。这样就诞生了类型适配器。
顾名思义，类型适配器将 .NET Framework 对象类型“适配”为一种更一致、有时也是更简单的格式。例如，假设您创建一个如下所示的新字符串变量：
[string]$var = “Hello”
您使用了一个由 .NET 适配器处理的 System.String 类型的实例。[ADSI] 类型适配器连接至 .NET Framework DirectoryServices 类，其中包括 DirectoryEntry 类型。

从目录中检索对象
连接到目录对象比较直接。例如，要连接到 Contoso.com 域的 IT 组织单位 (OU) 中名为 Don 的用户，可使用如下代码：
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”
如果您在 VBScript 或其他语言中使用过 ADSI，对此应当并不陌生。它是一个标准轻型目录访问协议 (LDAP) 查询字符串，是访问 Active Directory 的本机方式。您无需指定域控制器 (DC) 名称或任何其他详细信息；此完全限定域名 (FQDN) 已包含足够信息来定位 DC 和检索对象（当然，假设您具有相应权限）。
本地安全帐户的处理过程基本相同，只是这时要使用 WinNT 提供程序，而不是 LDAP 提供程序：
$user = [ADSI]”WinNT://don-pc/don”
图 1检索对象属性列表
检索对象主要是为了了解如何构造查询字符串。WinNT 提供程序的使用非常简单。只需指定一个计算机名或域名、一条斜线，再加上一个对象名即可。此技术非常适合 Active Directory 域（毕竟这些域与 Windows NT 域向后兼容）。事实上，有时使用 WinNT 提供程序从 Active Directory 中检索对象是最简单的方式，因为 WinNT 提供程序提供了一个域的平面视图。这意味着，您无需知道对象位于哪个 OU 中，因为 WinNT 提供程序看不到这些 OU。
LDAP 对象的检索要求更为精确些。首先要尽可能提供最精确的信息，如对象的规范名称 (cn) 或 OU 的名称。然后，应提供对象的完整路径，从其父容器开始，直至域本身。例如，检索位于 Sales OU（位于 Contoso.com 域的 West OU 中）中的用户 Don 应如下所示：
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com
此格式需要一点点的实践并要求您知道对象所在位置。图 2 汇总了 FQDN 的各种组件。
Figure 2 FQDN 组件 (Close Figure 2)

组件 | 用途 | 示例
cn | 对象的规范名称。也用于非 OU 容器，如 Users 和 Computers。 | cn=Don
ou | 组织单位。 | ou=Sales
dc | 域名组件。DNS 域名的每个组件获取其自己的“dc=”组件。 | dc=domain, dc=com

来自朋友的一些帮助
创建和删除对象通常要求首先连接到对象的容器（如 OU），然后请求容器创建或删除该对象。我总不记得正确的语法，幸运的是，Microsoft 脚本专家可以通过 ADSI Scriptomatic 助我们一臂之力。
虽然 ADSI Scriptomatic 最初是为 VBScript 创建的，但它仍是 Windows PowerShell 的一个非常有用的指南，因为实际的 ADSI 语法是相同的。例如，在下载该工具后，我选择了创建新用户的选项。我忽略了该工具生成的所有脚本代码，直至“End connect to a container”代码之后，如下所示：
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
转换到 Windows PowerShell 很简单。首先，我连接到要在其中创建用户的容器。为与 Scriptomatic 代码保持一致，我将使用变量 $objContainer 来表示 OU。我还要创建一个变量 $strName，用于存储新用户的名称：
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”
接下来，我复制所有 Scriptomatic 代码，删除任何 VBScript Set 语句的所有痕迹，并向变量名添加 $：
$objUser = $objContainer.Create(“user”,
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
这就是所需的全部工作 — 一个新用户在 Contoso .com 域的 Test OU 中创建完毕。

修改目录对象
连接到对象后 — 例如一个用户或组 — 您可以修改它。使用 WinNT 提供程序，您可以直接修改许多属性，如图 1 中所示的那些属性。例如，要显示然后更改用户的 Description 属性，可以编写如下代码：
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
有一点必须牢记，属性更改在本地属性缓存中进行，这是 ADSI 在计算机上维护的一个临时存储区域。调用 SetInfo 方法会将缓存写回您从中检索对象的计算机或域，其实质是将您的更改保存回目录。
对于多数对象属性，Active Directory 对象并不直接提供属性。实际上，您应当使用 Get 和 Put 方法：
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
WinNT 对象倾向于简洁化，因为 Windows NT 目录服务没有存储有关对象（如用户和组）的许多信息。相反，Active Directory 存储了众多信息，要找出正确的属性名称会有些难度。例如，如果要更改用户的姓氏，则必须更改 Sn 属性。为什么必须更改 Sn 呢？因为它代表姓氏。
幸运的是，Microsoft 提供了一个很好的交叉引用，您可以通过 msdn2.microsoft.com/ms677286.aspx 在线获得该引用。该引用显示了“Active Directory Users & Computers”（Active Directory 用户和计算机）控制台每个主要区域的属性名称，因此如果您知道要在控制台中进行哪些更改，则可以找出基础属性名称。请注意，Cade Fassett 所著的“ADSI Scripting:TFM”（ADSI 脚本：TFM）(SAPIEN Press, 2007) 一书中提供了更完整的控制台至属性交叉引用。

不能完成的任务
遗憾的是，Windows PowerShell 中的 ADSI 支持不像对其他技术（如 WMI）的支持那样强。例如，枚举本地计算机的组成员就有些困难。在处理 Active Directory 时，同样会遇到一些困难情况。根据我的经验，基本的对象检索、创建和删除比较容易。修改对象属性也相对简单，虽然有些属性不可访问。最大的难度来自通过 WinNT 提供程序对本地对象和组的处理。
这并不是说没有一点办法，只是有些事情要更困难一些，或者不那么直观。请看下面的例子：
$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”)
$group.psbase.CommitChanges()
该示例将名为 User1 的用户添加到 Techs 组中。它非常明了。它使用 FQDN 来检索该组，然后使用该组的 Member 集合 — 具体而言，是该集合的 Add 方法 — 来添加所需用户的 FQDN。但是，最后一步并不那么显而易见。它调用隐藏的 PSBase 类的 CommitChanges 方法来保存更改。
PSBase 是一个特殊类，直接代表基本的 .NET Framework 对象。在本例中，没有直接在 Windows PowerShell 中公开 CommitChanges（实际上，ADSI 适配器没有公开任何方法），因此您必须转向基础类。尽管这不是不可能的，但显然不够直观。这也表明目录服务功能尚未完全适合 Windows PowerShell。
这有许多原因。首先，在整个开发周期中，Windows PowerShell 团队向外壳添加当前 ADSI 支持的时机有些晚。就像外壳架构师 Jeffrey Snover 经常说的“提供就是选择”。该团队用来开发和交付外壳的时间是固定的，他们必须做出决定要为下一版本保存哪些内容。如果不是这样，他们可以轻易地花上几年时间来添加新功能，而永远不会实际发布一款支持的产品。
不过，还有一个原因就是基础 .NET Framework。它的 DirectoryServices 类非常复杂，使那种复杂性与 Windows PowerShell 相配需要大量时间和认真规划。在我看来，Framework 类也有些侧重于 Active Directory，并且没有为 WinNT 提供程序提供有力支持 — 当然，Windows PowerShell 会从 Framework 继承任何这类局限性。
我预计 Windows PowerShell 会逐渐拥有广泛的目录服务支持 — 甚至是可以不通过 ADSI 层，而是通过 .NET Framework 中的基本改进获得的支持。同时，Windows PowerShell 中的 ADSI 支持还允许您执行绝大部分管理任务，如创建用户、修改通用用户属性等。
请不要忘记，许多目录服务任务可通过 WMI 完成。请查阅 microsoft.com/technet/scriptcenter/scripts 中提供的某些优秀脚本示例，它们使用 WMI 提供有关本地组的更多信息，比 ADSI 本身提供的信息还要广泛。


 您好，脚本专家！: 用脚本消除不正确标记的红线
您好，脚本专家！ 用脚本消除不正确标记的红线 and Microsoft 脚本专家
下载这篇文章的代码: HeyScriptingGuy2007_06.exe (151KB)
您是否期待有一种更为简单的方法向 Microsoft Word 词典添加词条，而不必一一手动输入？有谁不想呢？本月，脚本专家将向您展示如何在 Microsoft Word 中创建自定义词典，以及如何以编程方式配置 Word 来使用这些词典。
图 1显示拼写错误的 Word 中的文档
注意到任何特别之处了吗？没错：Word 在 Msgbox 之类的脚本术语下面画了歪歪扭扭的线。这是为什么？因为 Word 不能识别这些术语。不能识别这些术语？别开玩笑了，Word；毕竟在过去几年，脚本专家已经将这个术语 Msgbox 输入了数百万次。而且他们运行拼写查错功能何止数百万次，每次您都会被告知 Msgbox 拼写正确。尽管如此，您还是将 Msgbox、StrReverse 和 LTrim 标记为拼写错误？这是怎么回事？
现在，在您冲向 Word 的这一防线之前，是的，我们知道可以手动向 Microsoft Word 词典添加这些术语。但是，别弄错了，我们是脚本专家；我们可不会干那种体力活！况且至少可以这样说，手动添加 VBScript 函数、Windows® Management Instrumentation (WMI) 类名称和 Active Directory® Security Interfaces (ADSI) 对象属性会比较乏味。如果我们要在所有计算机上都这样做，那该怎么办？如果我们要将这些正确拼写与我们的忠实读者共享又该如何呢？如果...，当然，您明白我的意思。
这里面的关键是：必须找到一种更简单的方法向 Microsoft Word 词典添加脚本术语（或所需的任何术语），而不必一一手动输入。
结果我们发现，这是不可能的。下个月见！
嘿，不，我们只是在开玩笑。当然有更简单的方法向词典添加术语。我们一会儿就为您展示如何做到这一点。但是，首先让我们先用几分钟来聊聊词典。
谈到词典，有一个有趣的现象。为什么美国人拼写 color 时不带 u（color，而不是 colour）？为什么美国人不将 center 拼写为 centre？我们知道答案：这是 Noah Webster 造成的，他编撰了第一部美语词典，并且与英语的拼写规则有所不同，因此有些独断地更改了许多单词的拼写。
好吧，打住，这个故事似乎不那么吸引人，但从中我们了解了有关词典的一个有趣的事实。
除了应用程序中内置的标准词典外，Microsoft Word 还允许您创建任意数量的自定义词典。默认情况下，Word 会附带一个名为 Custom.dic 的自定义词典，它通常位于您的“用户配置文件”文件夹（在 Windows XP 中默认为 \Documents and Settings\用户名）中的 Application Data\Microsoft\Proof 文件夹下。如果右键单击拼错的单词并选择“添加到词典”，即可将该单词添加到 Custom.dic 中。
实际上，Custom.dic 只是一个早已存在的纯文本文件。在记事本中打开它，您会看到类似如下所示的单词列表：
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
这就是我们可以通过编程向 Microsoft Word 中的词典添加脚本术语的方式。我们所要做的就是创建一个包含那些术语的文本文件，然后将 Word 配置为使用该文件作为自定义词典。那会很难吗？考虑到脚本专家将乐于自己完成这一切，显然没有什么难度可言。
但是，请等一下：在动手之前，我们需要先到另一处转转。在 Microsoft Word 对象模型中，有关自定义词典的信息存储在 CustomDictionaries 集合中。因此，可通过引用 Word.Application 对象和 CustomDictionaries 属性以编程方式访问该集合。例如，图 2 显示的脚本将返回有关与您的 Microsoft Word 相关联的所有自定义词典的信息。
Figure 2 检索自定义词典信息的脚本 (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
  Wscript.Echo “Name: “ & objDictionary.Name
  Wscript.Echo “Language ID: “ & objDictionary.LanguageID
  Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
  Wscript.Echo “Location: “ & objDictionary.Path
  Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
  intType = objDictionary.Type
  Select Case intType
    Case 0 Wscript.Echo “Type: Spelling”
    Case 1 Wscript.Echo “Type: Grammar”
    Case 2 Wscript.Echo “Type: Thesaurus”
    Case 3 Wscript.Echo “Type: Hyphenation”
    Case 4 Wscript.Echo “Type: Spelling (complete)”
    Case 5 Wscript.Echo “Type: Spelling (custom)”
    Case 6 Wscript.Echo “Type: Spelling (legal)”
    Case 7 Wscript.Echo “Type: Spelling (medical)”
    Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
    Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
  End Select
  Wscript.Echo
Next

objWord.Quit
运行图 2 中的脚本，您将获得类似如下所示的信息：
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
很巧妙吧？
当然，获取有关现有词典的信息与创建新的自定义词典并不是一回事；这有点像阅读有关某个百万富翁的信息与成为一名百万富翁之间的差异。因此，我们来看看能否找出在 Word 中创建新的自定义词典的方法。
首先，我们要将所有 VBScript 函数添加到一个名为 Scripting.dic 的新词典中。之所以从 VBScript 函数开始，是因为我们必须在这里做些工作。然后，我们将展示如何不费吹灰之力便将 WMI 类、ADSI 属性和 Windows PowerShell™ cmdlet 添加到词典中。（当然，当我们说几乎不费吹灰之力时，我们这些脚本专家知道自己在说些什么。）
首先在 Microsoft Word 中创建一个自定义词典，就像下面这样简单：
Set objWord = CreateObject _
  (“Word.Application”)

Set colDictionaries = _
  objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
如您所见，我们先是创建一个 Word.Application 对象的实例。您可能注意到了，这里未将 Visible 属性设置为 True，因此不会在屏幕上显示 Word。为什么呢？这只是因为此脚本只需 1 秒钟左右即运行完毕。因此，没有必要让 Word 在屏幕上闪烁一下后随即消失。但是，如果您希望让 Word 的实例闪烁一下（如果只是为了想知道该脚本确实在运行），只需在脚本中的第二行添加以下代码：
objWord.Visible = True
创建 Word.Application 对象后，接下来我们使用此行代码创建针对 CustomDictionaries 集合的对象引用：
Set colDictionaries = _
  objWord.CustomDictionaries
然后，我们调用 Add 方法添加该自定义词典。请注意，此文件不必一定存在；如果 Word 找不到名为 Scripting.dic 的文件，它会使用该名称新建一个空白文件。下面是添加自定义词典的代码：
colDictionaries.Add “Scripting.dic”
您可能也注意到了，我们在添加新词典时没有指定路径，而只是将文件名 (Scripting.dic) 传递给 Add 方法。这就可以了。在这种情况下，系统会在存储词典或其他校对工具的默认文件夹（例如，C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof）中创建该 Scripting.dic 文件。
如果我们希望词典位于其他位置该如何做呢？没关系。下面的命令会在 C:\Scripts 文件夹中创建 Scripting.dic：
colDictionaries.Add _
  “C:\Scripts\Scripting.dic”
如果我们以后想要删除该自定义词典，又该如何做呢？这同样好办。此时，我们只需绑定到相关词典并使用 Delete 方法将其删除：
Set objWord = CreateObject _
  (“Word.Application”)
Set objDictionary = _
  objWord.CustomDictionaries _
  (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
图 3添加自定义词典后 Word 中的文档
至少在我们看来，这会带来很多方便，尤其是您可以将该 Scripting.dic 以及您的自定义词典创建脚本与所希望的任何人共享。这样，他们的 Word 版本也会立即将 Msgbox 视为正确的拼写。事实是，如果我们这些脚本专家想偷懒的话，我们可以就此结束本月的专栏，您仍然有所得。但是常言道，好戏还在后头！
注意：实际上，我们确实比较懒惰。但是考虑到我们必须要填满本期专栏中的多余空间，所以决定附赠一、两个脚本来充数。
您或许知道，VBScript 和 Windows Script Host 都比较羞涩；它们不太喜欢谈论自己的情况。但是，WMI、ADSI 或 Windows PowerShell 就不是这样。您只需询问这些技术，它们就会告知有关自己的类、属性和方法等的所有信息 — 几乎涵盖您想知道的一切。
以 ADSI 为例。图 4 显示了一个绑定到 Active Directory 架构的脚本，它将检索用户帐户对象的所有属性。然后，它将这些属性写入到 C:\Scripts\Scripting.dic 文件中。
Figure 4 向自定义词典添加 ADSI 属性名称 (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
  objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
  objFile.WriteLine strAttribute
Next

objFile.Close
知道这有多酷了吧？只需数行代码，我们就创建了一个包含 Active Directory 用户对象所有属性的词典。将此代码与您负责编写脚本的同事共享，从此不必再担心诸如 streetAddress 或 givenName 等属性名被标记为拼错的单词。当然，这是可以无限扩展的。想要添加计算机类的属性吗？只需替换下面这行代码：
Set objSchemaComputer = _
  GetObject(“LDAP://schema/computer”)
那么对于 WMI 类呢？图 5 显示的脚本将检索在 root\cimV2 命名空间中找到的所有 WMI 类的列表，并将该信息写入 C:\Scripts\Scripting.dic。
Figure 5 向自定义词典添加 WMI 类名称 (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
  objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
还有我们的 Windows PowerShell 用户呢？放心吧，脚本专家永远都惦记着他们。不过坦白地讲，我们确实把他们给忘了。但是，我们还是记得给出了下面一行脚本，它可以返回所有 cmdlet 名称，然后将其写入 C:\Scripts\Scripting.dic：
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
本月的专栏表现不错，我们都学到了一些东西。您学会了如何在 Microsoft Word 中创建自定义词典以及如何以编程方式配置 Word 来使用那些自定义词典。我们这些脚本专家从中发现了：如果您想做些什么事，最好尝试让别人替您完成。但是如果他们都失败了，您总能自己将它搞定。


 桌面文件: 如何做到不丢失数据
桌面文件 如何做到不丢失数据 and Wes Miller 重要数据丢失的频率简直令人吃惊。但事实上，信息之所以丢失是因为人们没有保护好它。本文将探讨为保证组织数据的安全，您能够且必须要采取的重要步骤。
信息向往自由。无论您将信息托付给谁保管，也无论您为锁定那些 0 和 1 付出了多少努力，它们都始终会在信息堆中找到漏洞。每天都有新闻在报道大大小小的数据丢失事件。如此频繁地丢失重要数据
图 2选择的密码不好，即使您爱您的母亲
密码完整性和本地身份验证很关键，但是本地系统上的数据只有获得物理安全或加密之后才是能承受破坏的数据。只有密码并不能完全解决问题。用户密码仅仅是一个工具，对于想破坏对系统的直接交互式访问而又不愿意引进工具的攻击者，可以确保不让他们得逞。

物理安全
关键数据不能置于会遭到物理破坏或移出办公室的系统上。如果有人启动进入 Windows PE 并取得数据时，您担心系统可能遭到破坏，那么您还有其他问题；Windows PE 不是罪魁祸首。事实上，以下情况有一项或多项属实。您的系统没有正确保证物理安全。系统是安全的，但是您不相信对其进行访问的用户，您的数据放在没有（或无法）保证物理安全的系统上，或者系统无法保证物理安全，并且您未使用卷加密工具，如 Windows Vista 中的 BitLocker™ 功能，从而减少物理破坏。（有关 BitLocker 的更多信息，请参阅《TechNet 杂志》上 Byron Hynes 的相关文章。）
考虑您系统的哪部分面临风险。您可以保证它们的物理安全吗？为什么不将它们放在数据中心或访问受限的其他区域呢？如果不能，或者如果是移动系统，您是否使用卷加密软件？如果您不能采取上述任何一个步骤，请将数据移到能够保证安全的系统上，或者将数据加密。在上面提到的失窃便携式计算机事件中，如果已使用安全的卷加密工具对卷进行了加密，那么数据几乎算是十分安全的，不会遭破坏。
数据中心内的系统并不意味着就是安全的；如果您有一堆的 T1 流到 Internet，那么您仍然面临风险。Internet 访问使居心叵测者向物理访问更近了一步，因此要认真考虑您的系统所面临的威胁。考虑将它们移到您网络中的单独区域，这样您至少可以在 Internet 和被分析的系统之间获得另一层网络保护。

数据风险缓解
您还可以采用另一项安全措施，通过将数据隔离到物理安全服务器的应用程序或瘦客户端工具，让用户进行访问。这可能需要通过 VPN 提供访问权，以便非现场用户也能获得访问权。您不能让用户的物理约束来规定应如何对待数据。这只是因为用户需要访问权，并且他所处位置的带宽或其他高速访问不可用，这并不表示您应该将数据移到用户机器上的本地实例。如果您确实无法移动系统，而必须将它放在不安全的位置，那么再说一次，使用卷加密来保证数据安全。

系统内安全
您应为以下可能情况做好准备：无论您怎样努力，还是有人通过拆除硬盘并将它装入可以重置 NTFS ACL 的其他 Windows 系统来侵入您的系统。
要预防这种侵入方法，请使用 Windows Vista 中包含的卷加密。对于大多数其他版本的 Windows，有许多第三方工具可供使用。它们的使用难易程度有所不同，执行加密文件系统 (EFS) 允许的整卷加密和/或加密单个文件或目录的能力也各异。如果卷已经加密，那么数据可以免受所有窃贼攻击（最高超的窃贼除外）。

存档安全
备份数据也必须保证安全。大多数人出于两个原因而不对系统进行安全备份：对备份进行加密所需时间过长并且/或者他们的备份软件不支持加密。
然而，如果您要备份系统，尤其要按照最佳实践在现场之外执行备份，那么您必须保证即将备份的数据的安全。如果有 EFS，可以用它来加密数据，或使用其他卷加密软件（如 Windows Vista 中的 BitLocker 功能或其他第三方软件），或购买包括加密功能且执行过程合乎要求的备份软件。其原因就是，数据在备份磁带上有点打乱，或在基于磁带的备份解决方案中切碎，都不会使数据变得安全。假设传输机制本身会遭到破坏。

传输安全
您必须保证通过缆线传输的数据的安全。只使用安全协议来访问远程系统。使用加密版本的通信协议，并且总是假设可能有中间人 (MITM) 攻击。不要使用脆弱加密或未加密的协议，如果使用加密，则不要使用脆弱的加密长度或算法。您或组织中的某个人需要了解所有的通信协议，以及基础结构中系统内部使用的加密算法。

安全删除
我们都听过这样的事：在 eBay 或当地跳蚤市场购买的硬盘或其他存储设备，使用取证软件甚至是普通的复原删除程序都可将其数据恢复，因此泄漏了幕后秘密 — 这些数据本应在驱动器出售之前完全清除干净。
如果您在组织中有 UFD，则需要考虑强制的加密实用程序。包含高风险数据的磁盘应该加密。和流行的想法相反，我认为在处置之前简单加密卷不是处置磁盘的安全方法。还记得我前面提到过的医疗垃圾比喻吗？将这些系统上的数据当作危险废物，并采用安全的数据删除实用程序进行处理。将您的磁盘和系统向外界再销售时，或即使在组织内移动之前，请先使用实施 DoD 5220.22-M 规范的数据删除工具，就像 Mark Russinovich 所讲的 SDelete。否则，下一个用户会知道前一个用户的所有数据。

审核
最后但并不容忽视的一点是，数据安全的另一个关键部分是审核您组织中数据的生命周期，甚至可对其构建威胁模型）。了解您数据泄漏的脆弱点，并仔细监视这些点。Windows 提供了若干内置审核工具。然而，使用审核，您很容易陷入数据溢出。请确保您在监视正确的区域，并且数据没有超限。监视脆弱点，并采取良好的适当缓解措施 — 不要随意填塞该数据屏障。同时确保向您的用户正确讲解如何对待数据。他们是您组织内多级别中的关键一环。在“其他资源”侧栏中您会看到更多指南。不要忘了遵循本文介绍的所有建议；这样做的话，您就会安枕无忧了。
“其他资源”
“The Core Infrastructure Optimization Implementer Resource Guide—Basic to Standardized”（核心基础结构优化实施人员资源指南 — 基本至标准化）将向您介绍如何将您的 IT 基础结构从高度手动和反应式基本级别转移到具有更多自动化、强制配置标准和改进操作的标准化级别。可从 go.microsoft.com/?linkid=5795711 下载该指南。“其他基础结构优化实施人员资源指南”可在 microsoft.com/io 中找到。此外，请参阅“安全性的十个永恒定律”文章，以了解更多安全提示。


 领域备注: 与开发人员交谈
领域备注 与开发人员交谈 and David Aiken 让开发人员构建更易于管理的应用程序要比想象中简单。一切从沟通开始。开发人员看软件的角度与管理员不同。但是通过与开发人员交谈，管理员可以解释对他们来说重要的是什么，由此开发人员可以相应地将代码的设计工作做得更好。
很奇怪，但开发人员看软件的角度确实与管理员不同。开发人员与代码、跟踪、XML 配置文件、GUID 和程序集打交道。管理员则与脚本和 Microsoft® 管理控制台 (MMC) 管理单元打交道（至少他们愿意）。
实际上，让我们回过头来考虑。某些时候在我看来，似乎整个软件开发过程出了问题。我们花费大量资源寻找最终用户想要的是什么。我们构建原型、开展可用性研究、访谈以及其他工作，但是到了提供简单而一致的管理体验时，我们却没有达到目标。我们远远没有达到目标。
我曾经认为，Xcopy、Regedit 和记事本是安装软件的最好方法。但是现在我了解到，Microsoft Installer (MSI) 可用来自定义、安装和卸载。我知道，期望管理员使用记事本来编辑 XML 从而配置 Web 服务，这可能不是最明智的主意，而 MMC 管理单元（或 Windows PowerShell™ 脚本）目前会是更好的选择。我知道，传达问题的根本原因和可能的解决方案时，堆栈跟踪对于用户和管理员毫无帮助，在应用程序日志中提供编写严谨的事件更有意义。我知道，为了构建可由管理员管理和操作的软件，我需要将他们当成用户来对待。
将管理员当成用户，我可以定义使用案例、构建原型、开展可用性研究等。这让我能够向管理员提供可能的最佳体验。换言之，它将帮助管理员安装、配置、监视、排除故障和修复软件，而无需来叫我。如果我使用内置于他们熟悉的操作系统的管理功能，便可以大大降低运行应用程序的成本（上报的问题减少），改进客户满意度（应用程序故障频率减少，并且他们可以快速修复问题），并增加购买更多我方而非他人软件的机会（搭上顺风船）。
诚然，这船不过是梦想罢了。但是，让开发人员构建更易于管理的应用程序却不只是梦想，而是可以实现的目标。您也可以出一份力。下次出现问题时，请不要只是转发电子邮件，并低声叫开发人员的名字，而是可以建议他们将事件写入应用程序日志，或者提供性能计数器或问题的其他指示。若能建议可能的原因和解决方案则会更好。要求开发人员为您构建 Windows PowerShell 脚本或 MMC 控制台，以便配置应用程序。问题在于，开发人员并不总是知道您的存在，更不用说您的需要了。请告诉他们吧！


 Windows 机密: 新用户在“开始”菜单中看到的内容
Windows 机密 新用户在“开始”菜单中看到的内容 and Raymond Chen 想象一下，买了新电脑，装上 Windows，单击“开始”按钮，看到一个空菜单。之所以“开始”菜单在您开始使用之前，在最常用的位置包含了应用程序，目的是为了提供一个良好的初次使用体验。了解这些应用程序是如何被选中的。
我们曾设想在最初空白的“开始”菜单中填充文本。比如“您好，虽然这个区域现在是空白的，但请相信一旦您运行程序，它们将会显示在此处。”这个区域看上去不再愚蠢。而是又愚蠢又丑陋。
我们花了更多一点时间进行试验，但我们最终决定将它变成现在您在 Windows XP 中看到的样子。上个月您看到，常用程序列表基于一个评分系统 — 具有最高分数的程序显示在此动态列表中。对于全新用户，我们为各种程序设定了一些人工分数。因此，最初的“开始”菜单呈现出一个有趣程序的样本，让用户大致了解他们能做些什么。
人工分数的数值是经过仔细斟酌才选定的，因此我们想要的程序能够得到足够的分数以显示在常用程序列表中，但分数不会高到超过用户通过启动应用程序所得到的实际分数。
不过，如果用户是从 Windows 2000 升级而来的，就不会有这些人工分数。这种情况下，Windows 2000“开始”菜单用于 Intellimenus 的分数将用作 Windows XP 评分系统的最初分值。通过这种方式，一个升级得来的 Windows XP 的“开始”菜单立刻反映了用户在 Windows 2000 里最常运行的程序。
在最初发行的 Windows XP 版本中，人工分数的分配方式是：最常用程序六个位置中的前三个由 Windows 选择，后三个则由计算机制造商选择。如果您购买了零售而不是预装的 Windows XP，那么 Windows 会填充三个位置中的两个，将最后一个保留为空。通过这种方式，您运行的第一个程序将立即显示在“开始”菜单中。
在 Windows XP Service Pack 1 中，这六个位置经历了一些变化。两个位置由 Windows 选择，一个由美国司法部选择，后三个则由计算机制造商选择。和过去一样，如果您从零售商处购买了 Windows XP，那么计算机制造商的两个位置由 Windows 分配，而最后一个则保留为空。
“开始”菜单是 Windows 用户界面最醒目的部分，正如您所看到的，我们做了很多尝试工作以使让其感觉自然直观。


 读者来信: 有问必答
读者来信 有问必答
Windows PE 入门
在阅读了 Wes Miller 的文章“Windows PE 入门”（《TechNet 杂志》2006 年 9 月期）后，我用基于 HTML for Applications (HTA) 的向导创建了一个菜单。我有几个与在 Windows® PE 2.0 中使用该菜单有关的问题。
—Andy

下面是您的问题和我们的答复：

我怎样才能知道 ISO 文件中的可选软件组件 HTA 和 Windows Script Host (WSH) 是否正在运行？
如果您根据文档中提供的说明在您的 ISO 文件中安装了可选组件，它们应当能够正常运行。但我听说在两种常见情况下它们不能运行：如果您没有运行 peimg /prep 来准备映像，或者如果您没有为 ImageX 使用 /commit 参数以便在卸载时切实将更改提交至 Windows PE 映像。

我需要安装 Windows Management Instrumentation (WMI) 吗？文章中的向导文件显示一个 Internet Explorer® 错误。
只要安装了 HTA，向导文件就应当可以工作；它们是非常初级的向导文件。它们并不需要 WMI，实际上，我是先写了这些向导，然后才说明如何向 Windows PE 添加 WMI。

我应当如何在 startnet.cmd 文件中包含 OC.bat？
如果您使用 Windows PE 2.0，则根本无需使用 OC.bat — 只有 1.x 版本才需要它。Windows PE 2.0 允许您直接添加组件，而无需使用 OC.bat 提供的填充。

在所有问题都解决之后，我能否在我的菜单中使用 Wes 的某些代码？
您可以根据需要随意获取并重复使用任何代码示例，但是不能将其作为某个示例代码程序包的一部分出售或再次发布。有关详细信息，请参阅《TechNet 杂志》网站上的许可协议。

从哪里可以获得 Windows PE？
我在哪里能够找到 Windows PE 构建工具？可以免费下载吗？还是必须对其购买？
—Franklin
Windows Vista™ 的 Windows PE 构建工具是 Windows 自动安装工具包 (WAIK) 的一部分。您可以在 go.microsoft.com/fwlink/?LinkId=85377 下载。
该 WAIK 仅适用于 Windows Vista 操作系统系列。对于 Windows XP 部署，商用台式机部署解决方案加速器中提供了许多类似工具。不过，Windows Vista 的 Windows PE 许可已有所变化。以前（对于 Windows XP），Windows PE 只能通过软件保证许可获得（有关详细信息，请参阅 microsoft.com/licensing/sa/benefits/winpe.mspx）。

文件服务器资源管理器
Microsoft 是否会提供文件服务器资源管理器程序包的公开下载以便用于最初的 Windows Server® 2003 版本？或者，此程序包是否只与 R2 版本兼容？
—Dan
文件服务器资源管理器是 Windows Server 2003 R2 的一项功能。由于它与该版本的相关性，目前尚无计划提供它以用于以前的版本。

深入了解内核
在阅读了 Mark Russinovich 的文章“深入了解 Windows Vista 内核：第 3 部分”后，我有两个问题。第一个问题是，我注意到 Process Explorer 显示了 exe 或 DLL 文件随机位于每个引导会话中。是否有可能恶意软件也使用相同的机制来确定它要搜寻的代码的位置？第二个问题是，如果随机化有 256 个起始位置（如果我对文章的理解正确），那么如果目标代码针对该会话保持静态，应如何防止恶意软件进行“强制”探寻？
—Joe

Mark 可以回答您的所有问题：

Process Explorer 展示了一个先有鸡还是先有蛋的情形：恶意软件无法判断 DLL 的所在，因为它无法找出返回该信息的 API 的位置。恶意软件的“强制”探寻并不是一种可靠的入侵方法，因为如果恶意软件猜错，很有可能会使它试图感染的应用程序崩溃。至少，随机化会减缓病毒的传播速度。最好的情形是，它会禁止恶意软件感染系统。

联系我们
您有问题要问吗？请不必不好意思！我们会很高兴收到读者的反馈。请通过以下电子邮件与我们联系：tnmag@microsoft.com。