安全观察部署 EFS：第 2 部分

John Morello

可以认为任何加密文件系统 (EFS) 部署实质上都可以分为两个部分：侧重于证书管理和恢复代理的后端设计部分，以及面向用户的 EFS 部署部分。上个月，我谈完了后端部分，并且论述了数据和密钥恢复选项

以及用于为客户端置备证书的选项。在此，我将着重谈谈最终用户将会看到的那些部署方面，例如对 Windows® 资源管理器的增强、选择哪些文件系统位置进行加密以及如何使用组策略管理加密选项。

确定 EFS 是否已在使用

一旦您已决定部署 EFS，第一步就要确定 EFS 当前在贵组织内的使用状态。回想一下，EFS 可在独立模式下使用，在该模式下，最终用户独自负责创建和备份其加密密钥。在贵组织中可能已有高级用户以这种方式使用过 EFS，所以，为了确保平稳过渡到管理更好的部署，确定这些用户具体是哪些人非常重要。

任何给定用户在计算机上首次运用 EFS 时，Windows 均会在 HKEY_CURRENT_USER 中创建以下注册表条目：

HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash 

可使用 Microsoft® Systems Management Server (SMS)、Active Directory 登录脚本或其他工具检查整个企业范围的计算机上是否存在此条目。如果对于某位用户存在此注册表值，则表明该用户曾在某时使用过 EFS。然而，此值不一定表示某人当前正在使用 EFS 或是已对该人的任何数据进行了加密。因此，在发现某计算机存在此注册表项时，应更仔细地对其进行检查以确定是否有任何文件当前已加密。

使用 cipher.exe 并传递 /U 和 /N 开关将指示密码器报告计算机上文件和目录的加密状态。例如，如果要确定系统上是否有任何数据已加密，可运行以下命令：

cipher /U /N

可将注册表检查和密码器报告合并到一个脚本中，以检查是否存在此注册表值，如果存在，便在计算机上生成当前加密文件的报告。一旦生成这些报告，您就会知道哪些用户有哪些文件进行了加密，并且随时可以将其迁移到集中管理的设计。

为了在部署期间控制组策略的应用程序，可在域中创建两个安全组，将正在使用 EFS 的计算机与未在使用 EFS 的计算机分开，这样做很有用。例如，“SG-ComputersUsingEFS”组将包含已在使用 EFS 的那些计算机的计算机帐户，而“SG-ComputersNotUsingEFS”组将包含其他所有当前未在使用 EFS 的计算机。

通过组策略控制 EFS 的使用

知道了何人正在使用 EFS、何人未在使用 EFS 后，客户端部署的下一步就是禁止当前未在使用 EFS 的任何人独立使用 EFS。这一步在部署过程中很重要，因为与迁移正在使用自签名证书的用户相比，首次正确地启用和配置 EFS 要更加容易。只有在确定了哪些用户已在使用 EFS 之后，才能执行这一步，因为通过组策略禁用 EFS 后，用户将不能再访问任何当前加密的文件。可在组策略对象编辑器中的“计算机配置\Windows 设置\安全设置\公钥策略\加密文件系统”下找到此策略。

如前所述，只应在当前未在使用 EFS 的计算机上启用此值，以免干扰已在使用 EFS 的任何用户的工作。因此，在我给出的示例中，禁用了 EFS 的组策略对象 (GPO) 上的访问控制列表 (ACL) 只允许“SG-ComputersNotUsingEFS”组应用组策略。

加密还是不加密

确定了哪些系统当前正在使用 EFS 并在您管理的部署之前在其他所有计算机都禁用了 EFS 后，下一步就要确定将要在该被管部署中对哪些项进行加密。根据客户端系统的管理方式，此过程可能很简单，也可能相当复杂。

在考虑要对哪些文件进行加密时，首先要考虑用户在他们的系统上是否为管理员。如果用户是本地管理员，您其实只能指导并鼓励他们加密敏感数据，但不能以管理的方式真正对其进行控制。其原因很简单：本地管理员可在文件系统的任意位置创建文件和目录。因此，尽管您可以对诸如 My Documents 之类的公共位置进行加密，但如果用户在另一位置创建新的目录并将敏感信息保存在该处，便很难确保此数据也受到保护。当最终用户不是本地管理员时，除了其他所有的安全受益之外，还会使得 EFS 更加易于管理和安全。

关于 EFS 需要记住的下一条关键信息是，它是按用户加密的。换句话说，由给定用户加密的任何项只能由同一用户进行解密，而其他用户都做不到，包括 SYSTEM 帐户（当然也有例外，那就是数据恢复代理，亦称 DRA）。这意味着，如果使用某位用户的密钥对某个可执行文件或 DLL 进行了加密，而系统上的另一位主体尝试对其访问，则该主体会收到拒绝访问错误。因此，如果文件或目录包含系统上多个主体可能需要访问的可执行代码，一般不应对其进行加密。Windows 将阻止对 %SystemRoot% 中的文件或具有 SYSTEM 属性的文件进行加密，但软件供应商为 SYSTEM 帐户可能运行的服务将二进制文件安装到 %ProgramFiles% 中的情况也并不罕见。例如，便携机供应商在安装作为服务运行的电源和设备管理软件时，就常常会这样做。

考虑到这两个事实，那么实现 EFS 加密目标的最佳实践是什么呢？答案要回到正常情况下是如何对用户的系统进行配置的。在具有标准化操作系统映像的管理完善的环境中，您很可能会基于映像中预定的数据存储位置自动为用户执行加密过程。例如，如果用户只能在 %userprofile%\My Documents 中保存数据，您可能仅需加密该目录。（注意：如果使用文件夹重定向，则在加密 My Documents 时要小心。如果将 My Documents 重定向到某个服务器，该服务器需为“已为委派信任”并且具有访问用户配置文件的权限。在这种情况下，只对“脱机文件”缓存加密通常更加容易，我们以后将在本专栏对此进行讨论。）

在管理较差的环境中（用户可能在文件系统上写入许多位置），不妨采取这样的做法，先对少数几个公共存储位置自动进行加密，然后教会用户如何自行加密其他位置。无论环境如何，都务必要在目录级而不是文件级进行加密。这样做可确保该目录中创建的所有文件（包括临时文件）始终都会被加密。

推荐的加密位置

一般而言，通常应对这些位置进行加密：%userprofile%\My Documents、%userprofile%\Application Data\Microsoft\Outlook（假定您使用 Microsoft Office Outlook® 作为消息传送客户端）和 %userprofile%\Desktop。对 My Documents 加密会保护 Windows XP 中保存文件的默认位置。保护 Outlook 目录可确保本地缓存的敏感电子邮件也会被加密；这对于在 Outlook 2003 默认的“缓存模式”下运行的用户尤为重要。最后，桌面常被用作某种临时目录，用户可能会在此放置他们当前处理的文档或频繁讲述的演示文稿。当然，在贵组织中，您可能已修改了其中某些目录的默认位置，因此，无论在贵组织中通常都使用什么位置，在您做出 EFS 加密选择时都应将其反映出来。

除了这些一般性的最佳实践外，还应确定是否有应用程序可能在备选位置保存敏感信息。例如，一些应用程序会在 %ProgramFiles%\AppName 中而不是在用户的配置文件中保存用户信息。确定您的客户端系统上是否存在这样的应用程序很重要，这样才能正确地保护它们所利用的一切数据。在最好的情况下，可将应用程序配置成在另一个用户配置文件特定的路径中保存更改（例如 My Documents），此时，无需再进一步做任何 EFS 更改。在最坏的情况下，如果应用程序要求将数据存储在它的 Program Files 目录中，可使用 EFS 仅对 Program Files 的那个特定子目录进行加密。

最后，如果您打算加密临时目录（%TMP% 和 %TEMP%），请小心从事。许多应用程序安装程序都使用此目录来展开安装软件包的内容，然后对展开的文件执行文件移动操作，以便将它们放置到 %ProgramFiles% 中的适当路径中。由于在同一个卷上移动的文件会保留其原始属性，所以在将该文件放置到 %ProgramFiles% 中之后，它将继续被加密。如果尝试使用此文件的用户不是运行安装程序的那位用户，则会拒绝该用户对其进行访问。通常，此类问题不会以明确的应用程序错误消息表明自身的根本原因。因此，我一般建议仅在管理完善的环境下（最终用户不自行安装应用程序）才对 %TMP% 加密。

保护脱机文件

“脱机文件”是 Windows 2000 及更高版本中的一个功能，借此用户可以为文件服务器上存储的数据建立本地副本。然后，利用“脱机文件”，用户可在与服务器断开连接的情况下处理此数据，并在下次连接后通过同步操作将更改返回给服务器。然而，“脱机文件”并不只是一个包含服务器中文件副本的简单目录。相反，它是一个在系统范围内共享并在 SYSTEM 帐户的环境中运行的数据库。在 Windows XP 中，可使用 EFS 保护此数据库。根据前面对 EFS 按用户加密的讨论，想一想这意味着什么。特定于用户的 EFS 怎么能对多个安全主体使用的数据库进行加密呢？

当运行 Windows XP 的用户在 Windows 资源管理器中选择加密脱机文件的选项时，所利用的加密例程与该用户可能启动的其他加密操作所使用的例程是不同的。不是利用用户个人的 EFS 密钥对来执行该过程（这会阻止 SYSTEM 访问这些文件），而是由 SYSTEM 帐户自己生成用于 EFS 的密钥对，并使用该密钥对加密客户端缓存。这就产生了一个非常严重的安全隐患，如果有人随后得到代码以 SYSTEM 身份执行，他便可以解密缓存中的数据。如果某台便携机被盗，攻击者轻而易举就可以重置管理员密码并以管理员身份登录。一旦以管理员身份运行，强制代码以 SYSTEM 身份运行然后访问缓存，也同样简单。（请注意，这种行为在 Windows Vista™ 中有所改变。Windows Vista 现在使用单个用户的密钥来加密用户特定的脱机文件。）

为防止此类攻击，可将便携机配置成脱机存储安全帐户管理 (SAM) 数据库的加密密钥，既可在引导时将其作为密码输入（模式 2），亦可在引导过程中使用软盘（模式 3）。两种方法可能都不令人满意，因为它们需要在引导过程中与计算机进行不可自动化的交互，从而造成系统自动化管理方面的潜在问题。然而，如果要在具有脱机文件的计算机上使用 EFS，使用这些选项之一保护缓存中的数据至关重要。通常，我建议使用引导时密码（请参见图 1）。原因是，如果某位用户的便携机包被盗，那么极有可能软盘已插在便携机中，即便不是如此，软盘也几乎肯定会和便携机一起放在包中。

Figure 1** Automate EFS operations **

启用 EFS

确定了要在您的客户端上对什么进行加密后，下一步就要执行实际的加密操作了。可通过登录脚本或其他进程完成此过程，它们将在客户端上执行某个脚本以调用 cipher.exe 来执行加密操作。如在前面的示例中所讨论的，如果在您的环境中存在独立的 EFS 用户，建议首先迁移这些用户。

如在本专栏 2007 年 2 月的分期连载中所讨论的 (microsoft.com/technet/technetmag/issues/2007/02/SecurityWatch)，要迁移这些独立用户，第一步就要为客户端系统置备被管证书。在所有系统都为这些被管证书登记注册后，就应使用 /U 开关运行密码器，以新的加密和恢复代理密钥更新所有现有文件。此时，SG-ComputersUsingEFS 组中的所有系统都会以管理的方式利用 EFS，包括集中颁发（并且可能已存档）的密钥以及集中管理的恢复代理。

要为当前没有使用 EFS 的用户部署 EFS，必须首先删除阻止使用 EFS 的组策略。在完成该操作并且用户为被管证书登记注册后，便可运行登录脚本来加密先前讨论的密钥路径。以下是一个简化的脚本示例：

cipher /e /s /a "%userprofile%\My Documents"

cipher /e /s /a "%userprofile%\Application Data\Microsoft\Outlook"

cipher /e /s /a "%userprofile%\Desktop"

在所需目录上启用 EFS 后，应考虑设置另外两个选项来提高 EFS 部署的安全性，这两个选项都与从内存中页式调度到磁盘的数据有关。请注意，对于其中每一种方案，恶意方可能恢复的数据量都仅限于在合法使用期间加载到内存中或页式调度到磁盘上的数据量。换句话说，如果用户的机器上有受 EFS 保护的敏感数据且用户未曾查看过这些数据（因而未加载到内存中），则此数据便不会受到这些攻击病媒的威胁。

页面文件被 Windows 用作虚拟内存（在其他操作系统中常称作交换空间），其中包含内存中以明文写入硬盘的原始数据片段。这会将受 EFS 保护的系统上的敏感数据置于危险境地，因为如果攻击者能够恢复页面文件，他们就有可能利用辨析工具从此文件中提取合用的数据。由于在 Windows XP 中无法对页面文件本身进行加密（请注意，在 Windows Vista 中可以对其加密），所以最佳选择就是强制 Windows 在关闭时将其清除。这可以通过组策略来实现，如图 2 所示。

Figure 2** Setting group policy **(单击该图像获得较大视图)

此设置的缺点是大大增加了关机所需的时间，尤其是对于具有大量内存的机器。（默认情况下，页面文件的大小与计算机中的物理内存量直接相关。）这是因为 Windows 必须在关闭前在磁盘上物理写入每一页，方可清除页面文件。

当电源管理模式设置为启用休眠时，Windows 中的休眠文件包含机器物理内存的转储。休眠发生时，Windows 会将物理内存的完整内容写入磁盘中的休眠文件，从而当用户准备要继续工作时，可将计算机还原到与休眠前完全相同的状态。与页面文件一样，在 Windows XP 中也无法对休眠文件进行加密。然而，与页面文件不同的是，不能直接通过 GPO 禁用休眠。而是应该使用脚本调用带有 /HIBERNATE 开关的 powercfg.exe 来禁用（或重新启用）休眠。

完成初始加密和配置任务后，在部署中应考虑擦除磁盘上的闲散空间。此过程可能非常耗时且具有破坏性，但在高安全性环境中具有安全上的好处。闲散空间是一个磁盘区域，其中虽未存放系统上当前活动的数据，但由于硬盘的操作方式，其中可能包含先前使用过的文件中的敏感信息片段。换句话说，由于文件删除操作实际上并不覆写文件在磁盘上占据的所有扇区（仅会从文件表中删除相应的指针），所以被删除的数据可能继续存在于磁盘上。在这种情况下，便可能通过可以读取此闲散空间并从中重新组装文件的辨析工具来恢复该数据。要安全地擦除这些残留数据，请运行带有 /W 开关的密码器。这样可以强制密码器反复覆写磁盘上标记为可用的所有扇区。只要将来针对敏感数据的所有文件操作都在受 EFS 保护的目录中进行，便无需定期运行此命令。

为 EFS 增强 Windows 资源管理器

默认情况下，文件和目录的加密和解密选项兴许埋藏在 Windows 资源管理器的高级属性菜单中。可以选择通过将“加密”和“解密”置于 Windows 资源管理器的上下文菜单（右键单击时出现）来增强对 EFS 的最终用户体验。此外，还可对 Windows 资源管理器进行配置，使其以与其他文件不同的颜色（绿色）显示受 EFS 保护的文件和目录。这可能对用户很有帮助，他们不必深入到高级属性菜单中即可知道某个文件或目录是否已加密。最后，您可能想要添加一个选项来定义哪些用户有权访问该文件或目录。要启用这些选项，请通过调用 reg.exe 的脚本在注册表中进行以下更改：

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"EncryptionContextMenu"=dword:00000001

"ShowCompColor"=dword:00000001

[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]  
@="rundll32 efsadu.dll,AddUserToObject %1"

Windows Vista 中的 EFS

在 Windows Vista 中对 EFS 进行了许多重要的增强，这使其变得更加易于部署和管理，同时也增加了安全性。这些增强中最主要的就是完全支持在智能卡上存储 EFS 密钥。对于已在利用智能卡登录的组织来说，此功能尤其有价值，因为也能使用同一个卡来存储用户的 EFS 密钥。对智能卡的这一支持也扩展到了恢复代理证书，这样就可以将敏感的 DRA 证书也存储在卡上。

Windows Vista 还支持对以前在 Windows XP 中不可能或不易做到的项进行加密。Windows Vista 可以加密页面文件，无需再设置“清理虚拟内存页面文件”选项。在 Windows Vista 中，对脱机文件的整个设计进行了重新整改。除大大提高了性能和稳定性（以及界面通常对用户更加友好）以外，客户端缓存现在是按用户进行的，也就是说可在不使用 SYSKEY 模式 2 或 3 的情况下安全地加密缓存。这两项改进消除了现今基于 Windows XP 的环境所存在的主要部署障碍。

最后，在 Windows Vista 中，管理员不必利用单独的脚本即可通过组策略直接配置 Documents 文件夹的加密。图 3 说明了 Windows Vista 中通过 GPO 提供的新 EFS 属性。

Figure 3** EFS properties in Windows Vista **(单击该图像获得较大视图)

总结

EFS 为 Windows 管理员提供了一个用于保护移动数据的高度安全的选项。EFS 可伸缩且易于管理，并且提供了灵活的数据恢复机制。在 Windows Vista 中进一步对 EFS 进行了改进，使其功能得到了增强，不仅更加易于管理和部署，而且支持基于智能卡的密钥存储。对于要保护数据的组织来说，即使对于计算机真正丢失的情况，EFS 也提供了一个强大的解决方案，它已成为您现有 Windows 平台的一个组成部分。

何处去找更多信息

有关本专栏所讨论主题的详细信息，请参阅以下资源：

• 2007 年 2 月的安全观察专栏
• Encrypting File System in Windows XP and Windows Server 2003（英文）
• 如何使用 SysKey 实用程序来保护 Windows 安全帐户管理器数据库

John Morello 以最优异的学业成绩毕业于 LSU，在 Microsoft 的六年工作期间担任过许多不同的职务。作为高级顾问，他曾经为财富 100 强企业以及联邦民用和国防客户设计安全性解决方案。目前，他是 Windows Server 组的项目经理，负责安全性和远程访问技术方面的工作。

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