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

John Morello

到目前为止，相信很多人都听说过类似报道，即由于便携式计算机的被盗或遗失而导致个人数据或敏感数据的丢失。便携式计算机定期丢失数据。由于身份盗用越来越严重，而规定符合性相比以往也日益重要，则对移动计算系统中所有数据的全面保护也就成为重中之重。

一种实现方案是使用加密文件系统 (EFS)，Windows 2000 之后的 Windows® 中皆包含此系统，可提供基于磁盘的内置高性能加密方式。EFS 与 Windows Explorer 无缝集成，因此最终用户经常不知道他们所使用的文件何时被加密。此外，EFS 同样适用于本机 Windows 身份验证和访问控制技术，因此用户无需记住各个密码来访问数据。最后，EFS 提供可管理的选项，能够在用户丢失其加密密钥的访问权限时（如用户配置文件删除或损坏，或是其智能卡丢失）恢复数据。

EFS 使用 Windows 内置加密技术生成、存储和部署强加密密钥，以保护数据。在 Windows XP Service Pack 1 (SP1) 及其更高版本中，EFS 利用 256 位密钥的高级加密标准 (AES) 算法对磁盘上的数据进行加密。然后，使用非对称 (RSA) 密钥对来保护这些对称密钥。EFS 使用 AES 密钥为每个文件进行加密，之后通过用户的 RSA 密钥对该密钥进行加密并将结果存储在文件中。有关 EFS 加密的详细信息，请参阅“EFS 资源”边栏。现在，我将略过 EFS 的技术支持，将重点集中在如何部署 EFS 并使其在您的环境中可用。由此，本文假设读者已经预先了解 EFS 加密概念的相关知识。

EFS 安全性注意事项

一些应用程序宣称能够破解 EFS 加密技术。请注意，这些应用程序实际上是通过解密 AES（或是数据加密标准，DES；又或是扩展数据加密标准，DESX）加密密文，而非强行破解用户密码来获取用户 EFS 私钥访问权限的。需要记住，有关 EFS 加密最重要的一点，私钥是利用数据保护 API (DPAPI) 来生成和保护加密数据的。DPAPI 使用用户登录凭据派生来保护数据，最终结果是使用 EFS 保护数据与使用用户密码保护数据的效果一样好。如果使用的是 Windows Vista™，现在即可将 EFS 加密证书存储在智能卡上，这将更改此范例，并且极大地提高 EFS 所保护数据的相关安全性。

多长的密码才能抵抗这些攻击？鉴于如今的硬件功能和现代密码攻击算法，推荐使用 11 个字符或更长的密码（更准确地说是密码短语）。11 个字符或更长的密码短语可更好地抵抗如今大多数的高级攻击方法，其中包括预先计算的哈希攻击（如 Rainbow Table；有关详细信息，请参阅“资源”边栏中列出的博客文章《Why you shouldn't be using passwords of any kind on your Windows networks》（不应在 Windows 网络上使用任何种类密码的原因））。

是否使用 PKI？

对于 EFS，最常见误解之一是 EFS 需要使用公钥基础结构 (PKI) 工作。尽管 EFS 可以轻松地与 PKI 集成并且对其加以利用（贵公司应该已经拥有 PKI），但这绝对不是必需的。也就是说，关于是否在 EFS 部署中使用 PKI 的决定将会影响到日后的众多部署决策，最好是三思而后行。

将 PKI 和 EFS 结合使用的主要优势在于能够执行密钥存档和密钥恢复。仅使用 EFS 时即允许管理员执行数据恢复操作，而自动密钥恢复仅在运行 PKI 时可用，甚至是仅在将 Windows Server® 2003 Enterprise Edition 作为证书颁发机构 (CA) 时可用。用户在丢失对加密密钥的访问权限后，向指定管理员，也称为数据恢复代理 (DRA)，提供其加密数据，然后该管理员可解密此数据并将其返回到用户，或者将此数据重新进行加密以通过一个新的私钥来使用，这一过程就叫做数据恢复。DRA 就像用户加密流程的影子，即用户使用密钥加密任何内容都会使用 DRA 密钥副本重复相同的操作。因此，用户丢失密钥之后，可通过 DRA 来获取密文数据，再将 DRA 密钥应用到其中进行解密（或重新加密），最后将数据返回到用户。DRA 方法的工作效果非常好，但是，如果用户拥有大量加密数据或者没有本地 IT 人员承担 DRA 职责，其管理工作就会比较困难。

另一方面，密钥恢复需要 CA 在密钥创建过程中对用户的加密密钥进行备份，并安全地将该密钥副本存储到 CA 的数据库中。然后，当用户丢失加密文件的访问权限后，CA 管理员仅需进入此数据库并检索用户的密钥。这样的话，无需使用 DRA 进行恢复操作，用户便能立即重新获取对数据的访问权限。按照此方法可以更加快速高效地恢复密钥。但是请注意，最佳实践是始终设置 DRA，即使在使用密钥恢复时也是如此，用来为密钥丢失事件提供备份机制。还支持大型组织采用分布式恢复系统，本地 IT 管理员无需加入到 PKI 管理员组即可恢复用户数据。

将 PKI 和 EFS 结合使用可能带来的另一个优势是更易于共享加密文件。注意，EFS 不仅仅限于便携式计算机系统；它在任何不能保证计算机的物理安全性的情况下一样非常有用。在这些情况下，可能存在多个用户需要访问同一加密数据的情况。虽然 Windows 仅允许共享单个文件，而非目录，也因此对共享加密文件的支持会受到一些限制，但还不失为一个有用的工具。要简化 EFS 文件的共享，则正在共享文件的用户就必须具有访问与之共享文件的用户公钥的权限（如果这些用户具有向 Active Directory® 中的帐户发布的有效 EFS 证书，这将非常简单）。虽然能够手动执行发布，但使用安装在 Enterprise（与 Active Directory 集成）模式中的 Windows CA 可将整个过程完全自动化。

EFS 密钥管理

如果您使用的是基于 Windows Server 2003 的 PKI，则用户 EFS 证书生成会是一个非常简单的过程。Windows Server 2003 CA 带有一组默认的证书模版，其中包括 Basic EFS。然而，此模版属于版本 1 模版，不支持密钥存档。因此，使其可在 CA 上使用之前，您需要复制模版，以创建新的版本 2 模版（例如，可以称其为带有密钥存档的 EFS，如图 1 所示）。在这个新模版上，请转至“处理请求”选项卡，然后选中可存档用户加密密钥的选项。请注意，在启用此选项之前，您需要在 CA 上正确配置密钥存档。资源部分包括此过程的最佳演练。您还应该使用此模版来替换 Basic EFS 模版，以确保客户端能够使用到此新版本（参见图 2）。

图 1** 带有密钥存档的 EFS **(单击该图像获得较大视图)

图 2** 替换 Basic EFS 模版 **(单击该图像获得较大视图)

接下来，您需要在此模版上设置适当的权限，以允许指定的用户组具有相应的注册访问权限。由于在第一次使用 EFS 时，Windows 中的 EFS 组件会自动请求证书，所以通常情况下，无需让用户针对 EFS 模版进行自动注册。事实上，除非确定所有自动注册的用户都使用 EFS，否则建议您不要启用 EFS 证书的自动注册。图 3 显示了 EFS 注册设置。通过向可能从未使用过 EFS 的用户颁发证书，您能够扩大 CA 数据库的规模，但这样做却毫无益处。尽管 CA 数据库在规模上未受到限制，但如果证书的颁发数量不断增多的话，数据库的管理工作会越发困难（采用 Microsoft 管理控制台 (MMC) 的情况下尤为明显）。

图 3** 设置 EFS 用户权限 **(单击该图像获得较大视图)

最后，如果需要支持加密文件的共享，最好是让 CA 自动向 Active Directory 发布用户证书。

一旦您在 CA 上对模版进行了正确的配置，用户在第一次通过 EFS 加密文件时，将会从您的 CA 处获取证书，同时 CA 也将自动对其私钥进行存档。

DRA 密钥管理

如果使用了 PKI，那么下一个需要考虑的问题就是：是否使用 CA 生成的 DRA 证书。为什么不想使用来自 PKI 的 DRA 证书呢？请考虑这种情况，即颁发 CA 的证书有效期相当短（两年甚至更短）。该 CA 不能颁发任何有效寿命比其自身有效期更长的证书，这意味着您的 DRA 证书最多只能有两年的使用期限。这就造成了极其复杂的数据恢复局面。下面对这个假定示例进行说明。

1. 用户在 2006 年 1 月加密了一个文件；通过组策略向其计算机颁发的 DRA 证书的有效期为两年（于 2008 年 1 月过期）。
2. 用户继续使用 EFS 加密新文件。
3. 在 2008 年 1 月 DRA 证书过期后，管理员通过组策略颁发新的证书。
4. 从现在起，将使用新 DRA 证书完成所有的加密操作（包括打开那些通过原有 DRA 证书加密的所有文件，在保存时会使用新的 DRA 进行加密），但是用户没有动过的文件仍然是受到原有 DRA 的保护。
5. 如果用户无意中破坏了配置文件并需要进行数据恢复。
6. 则 IT 管理员就必须要提供两组 DRA 证书：步骤 3 之后改动过的文件使用新 DRA 证书，而未改动过的文件使用原有的 DRA 证书。

虽然 IT 管理员在步骤 3 之后能够通过运行脚本，使用新的 DRA 来更新全部文件（使用 cipher.exe /u），但是这一过程却要耗费大量时间。而更确切地说，尽管在恢复策略中包含过期 DRA 证书的情况下，EFS 组件将不允许任何新的加密操作，DRA 密钥对在过期之后也不是全无用处。毫无疑问，由过期 DRA 密钥对加密的旧文件仍可以由它们来恢复。因此，即使 DRA 密钥对已经过期也不要丢弃它们，说不定日后还会用到。

因此我建议，证书使用期限较短的 CA 所处的环境中应采用拥有较长使用期限的自签名 DRA 证书。密码实用程序包括一个可自动创建具有 100 年使用期限 EFS 恢复代理密钥对的开关（参见图 4）。之后，此密钥对中的证书可附加到组策略对象 (GPO)，并作为整个组织的 DRA 加以使用。由于 EFS 组件不会检查 DRA 证书的信任链，所以，无需在系统上对受信任根证书颁发机构的列表进行改动，即可使用这些自签名证书。无论组织的 CA 的使用期限有多长，始终推荐至少创建一个使用寿命较长的 DRA 证书并将其附加到域范围 GPO 中。这是在所有其他选项都不可用的情况下所使用的备用数据恢复选项。缺少 CA 密钥存档的情况下使用 CA 生成的 DRA 密钥尤为重要。如果 DRA 证书已经受损，则可以通过新的证书来更新 GPO，并使用上述的 cipher.exe /u 来更新文件。

图 4** 运行 Ciquer /R **(单击该图像获得较大视图)

EFS 资源

可以访问以下站点来获取更多有关 EFS 细节和最佳实践的详细信息。

• Why you shouldn’t be using passwords of any kind on your Windows networks（英文）
• Implementing Key Archival Walkthrough（英文）
• Encrypting File System in Windows XP and Windows Server 2003（英文）

部署 KRA 和 DRA

密钥存档支持 CA 管理员代表用户恢复托管加密密钥。很明显，这是一种既敏感又强大的能力，因为它允许 CA 管理员对组织中任何使用由 CA 签名的密钥的数据进行解密。因此，应谨慎对待密钥存档和恢复，并且仅向少数受信任的安全人员授予权限。鉴于密钥恢复的敏感性质，如果您想要将其作为重新获取 EFS 加密数据访问权限的主要机制，明确定义要发送到 CA 管理员团队的恢复请求升级进程十分重要。仅在对请求进行全面检查后才能启动恢复过程。之后，一旦密钥被实际恢复，应该通过一种安全的方式（换言之，就是不要使用电子邮件）将其提供给用户，因为恢复的密钥提供了对用户所有受 EFS 保护数据进行访问的权限。

密钥恢复代理（或 KRA 密钥）由 CA 管理员生成和保管，并且不会通过组策略进行通告。事实上，EFS 自身不能确定其所使用的密钥是否已存档；它只是和往常一样执行加密操作。另外，在 CA 上创建的 KRA 密钥不以任何方式特定于 EFS。使用密钥存档的 CA 将在 CA 级使无限多个 KRA 密钥附加到其上，可用来保护由 CA 存档的全部密钥。这些密钥包括与 EFS、安全电子邮件或任何其他包括加密的证书用途一同使用的密钥。应由专用的密钥恢复代理安全地存储 KRA 密钥，并且至少要有两个 KRA 以备发生密钥丢失现象。

管理员首次在新创建的域中登录域控制器时，将使用存储在 DC 管理员配置文件中的自签名证书和密钥对，在域级别创建默认恢复策略。此 DRA 证书具有三年的有效使用期限。推荐方法是删除此默认证书，并代以使用期限更长的自签名证书或 PKI 颁发的证书。如果未删除此默认自签名证书，则三年后，由它创建的 EFS 将在整个域内停止对新文件进行加密。这是因为证书已过期，如果 EFS 恢复策略中包含过期 DRA 证书的话，EFS 将会阻止对任何的数据进行加密。虽然在不具有恢复代理策略的情况也可以操作 Windows XP 及更高版本的系统，但是强烈建议不要如此。这样做就意味着，如果用户出于某种原因丢失了对其加密密钥的访问权限，而且不能恢复密钥的话，则该用户的所有数据将无法挽回。

正如之前所说，DRA 密钥可以是自签名，也可以由 CA 颁发。在大多数情况下，将二者混合使用最佳，在企业范围内使用至少两个长寿命的自签名 DRA 作为恢复代理的最后选项。由于 DRA 证书是通过组策略对象部署，因此具有与其他 GPO 相同的继承功能。换句话说，用于控制其他 GPO 设置应用程序的标准本机、站点、域、组织单位 (OU) GPO 累积和应用算法同样适用于 DRA。因此，对于 DRA，组织可以轻松地实现分层方法，中央 IT 组拥有访问企业每个部分的权限，但是本地 IT 组也保留了对其所负责特定区域的访问权限。这对于大型且地理位置分散的组织来说是一项极有助益的资产，因为它可缓解通过 WAN 链接进行大量加密数据传输的需要，有助于数据恢复。图 5 说明了一个典型的多层式 DRA 部署。

图 5** 多层 DRA 部署 **

在这种情况下，Baton Rouge OU 中的用户将最终得到每个加密文件的六个 DRA：两个来自本地管理员，两个来自北美 IT 组，两个来自域级别。因此，如果用户丢失了对加密数据的访问权限，可以通过 Baton Rouge 中的本地 DRA 或北美 IT 组进行恢复。作为最后的备用，如果这四个 DRA 都不可用或都已丢失，也可以通过域级别的 DRA 恢复数据。无论哪个 DRA 执行恢复操作，其过程基本上相同。用户首先使数据对 DRA 可用。DRA 采取必要的步骤来确定请求是合法的，而且来自数据的真正所有者，这点非常重要。这一步完成后，DRA 将加载 DRA 证书，并解密（最好是重新加密）数据，然后将数据返回到最终用户。一些组织还选择执行本地恢复，DRA 将物理访问发生问题的用户，将其 DRA 密钥对加载到配置文件中，然后解密数据并删除该密钥对。之后，用户将以明文形式获取对数据的访问权限，并可以使用新的密钥重新进行加密。应该注意的是，此方法的安全性较低，因为 DRA 密钥对被复制到本地计算机上（即使是暂时的），但是这种方法可以节省时间，尤其是在必须恢复大量数据的情况下。

请注意，如果通过密钥的存档和恢复为用户提供恢复，则处理恢复请求的方法将完全不同于上述过程。完全不使用 DRA，用户的密钥恢复请求将转到 CA 管理员，管理员在检查请求之后，再转到存档中并检索用户的私钥。之后，他们让用户能够安全地使用此私钥，如将其放在一个安全的网站上，以供下载。（如果用户使用智能卡存储其 EFS 密钥，并且在 Windows Vista 上可用，那么该密钥也应该重新发布。）用户将此密钥加载到配置文件中，就可即时访问所有的加密数据。

由于 DRA 和 KRA 密钥对都可以用于解密敏感数据，因此，它们应受到适当的保护，这一点很重要。DRA 和 KRA 密钥对不应存储在管理员的常规桌面配置文件（即管理员为完成每天任务所要用到的配置文件）中。而是将这些密钥对安全地脱机存储到软盘、光盘或闪存等媒体，并将这些媒体保存在物理安全的位置。然后，在需要恢复时，恢复代理能够将密钥对从媒体加载到恢复工作站，执行恢复操作，最后删除密钥对。在某些安全性极其敏感的组织内，可指定专用的工作站进行恢复，以进一步提高这些密钥对的安全性，但不是所有组织都需如此。

下期内容

既然已对密钥管理、数据恢复和 Active Directory 方面的 EFS 规划进行了介绍，在该主题的第二部分中，我将着重说明客户端部署方面的问题，敬请关注。届时将涉及到诸如通过组策略控制 EFS 的使用、选择要加密的内容、通过登录脚本自动加密数据，以及改进 Windows Explorer 客户端以更简便地使用 EFS 保护的数据等方面的内容。

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

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