Device Guard 部署指南

Microsoft Device Guard 是由硬件和软件系统完整性强化功能组成的功能集，这些功能彻底革新了 Windows 操作系统的安全性。Windows 10 使用 Device Guard 以及代码完整性和高级硬件功能（例如 CPU 虚拟化扩展、受信任的平台模块和二级地址转换），为其用户提供全面现代安全性。此指南探索 Device Guard 中的个别功能以及如何计划、配置和部署它们。

Device Guard 简介

如今的安全威胁环境比以往更高效。现代恶意攻击集中于创收、知识产权窃盗，以及导致财务损失的目标系统性能降低。大多数现代攻击者背后的资助方都是国家，它们动机不明且具有大型的网络恐怖主义预算。这些威胁可通过电子邮件等简单的渠道进入公司，并且可以永久地伤害公司保护其软件资源的信誉，同时产生严重的财务影响。Windows 10 引入了多个新的安全功能，可帮助缓解当今绝大部分的已知威胁。

据估计，每天发现的新恶意软件变体超过 300,000 个。遗憾的是，当前公司使用古老的方法来发现此感染软件并防止其使用。事实上，当前电脑信任在恶意软件签名确定是否存在威胁前运行的所有内容；往往在注意到恶意软件的影响后，反恶意软件才会尝试清理电脑。此基于签名的系统专注于对感染做出反应并确保该特定感染不会再次发生。在此模型中，驱动恶意软件检测的系统依赖于恶意软件的发现；只有这样，它才会将签名提供给客户端以进行补救，这意味着计算机必须先感染。检测恶意软件与向客户端发送签名之间的时间意味着丢失数据与保持安全之间有区别。

除反恶意软件解决方案外，还提供了一些“允许列表”技术，包括 AppLocker。这些技术将针对正在运行的应用程序执行单实例或覆盖层的 Allow 或 Deny 规则。尽管这比基于签名的检测更具保护性，但它需要大量的持续维护。在 Windows 10 中，这些应用程序在与 Microsoft Device Guard 一起部署时最有效。

Device Guard 打破了当前先检测后阻止这一模型，它仅允许受信任的应用程序在当前运行。此方法与移动电话安全性成功的预防策略一致。借助 Device Guard，Microsoft 更改了 Windows 操作系统处理不受信任的应用程序的方式，这使得恶意软件难以侵入系统的防御体系。此新防病毒检测模型针对现代威胁为 Windows 客户端提供必要的安全保护，从该模型实现的第一天起就使如今的大部分威胁都完全过时。

Device Guard 的功能通过充分利用新的基于虚拟化的安全 (VBS) 选项和无信任移动设备操作系统模型彻底改变了Windows 操作系统的安全性，这使得恶意软件更难以侵入系统的防御体系。通过使用可配置的代码完整性策略，组织可以具体选择允许哪些应用程序在其环境中运行。可配置的代码完整性不限于 Windows 应用商店应用程序，并且可与现有未签名或已签名的 Win32 应用程序一起使用，而无需重新打包应用程序。此外，如果组织没有 Device Guard 的所需硬件，则可配置的代码完整性可以部署为单个功能。除了代码完整性，Windows 10 还利用 CPU 虚拟化扩展、输入/输出内存管理单元 (IOMMU)、受信任的平台模块 (TPM) 和二级地址转换 (SLAT) 等高级硬件功能来为其用户提供全面的现代安全性。与可配置的代码完整性和凭据保护一起部署的 Device Guard 将是如今组织可以实现的最有影响的客户端安全部署之一。 在本指南中，你了解了 Device Guard 中找到的个别功能以及如何计划、配置和部署它们。带有可配置的代码完整性的 Device Guard 旨在与其他威胁缓解 Windows 功能（如凭据保护和 AppLocker）一起部署。

Device Guard 概述

Device Guard 是由硬件和软件系统完整性强化功能组成的功能集。这些功能通过充分利用新的基于虚拟化的安全选项和无信任移动设备操作系统模型彻底改变了 Windows 操作系统的安全性。本模型中的主要功能称为可配置的代码完整性，这允许你的组织精确选择允许哪些软件或受信任的软件发布者在你的客户端计算机上运行代码，这正是移动电话安全性如此成功的原因。此外，Device Guard 为组织提供一种对现有业务线 (LOB) 应用程序进行签名的方式，以便它们可以信任自己的代码，而无需重新打包应用程序。此外，此相同的签名方法为组织提供了信任个别第三方应用程序的方式。带有可配置的代码完整性、凭据保护和 AppLocker 的 Device Guard 是任何 Microsoft 产品所能为 Windows 客户端提供的最完整的安全防护。

高级硬件功能（如 CPU 虚拟化扩展、IOMMU 和 SLAT）推动着这些新客户端安全产品/服务的发展。通过将这些硬件功能进一步集成到核心操作系统中，Windows 10 采用新的方式来利用它们。例如，用于在 Microsoft Hyper-V 中运行虚拟机的同一类型 1 虚拟机监控程序技术可用于将核心 Windows 服务隔离成一个基于虚拟化的受保护容器。这只是 Windows 10 为了向其用户提供全面的现代安全性而将高级硬件功能更深入地集成到操作系统的一个示例。这些硬件功能现在在消费者和企业电脑市场中提供，并在硬件注意事项部分中进行详细讨论。

除了这些新功能，Device Guard 的一些组件也是已随附在此策略性安全产品/服务中的现有工具或技术，用于向客户提供最安全的 Windows 操作系统。Device Guard 旨在作为一组与 Windows 操作系统中提供的其他防威胁功能结合使用的客户端安全性功能，本指南中提及了其中的一些功能。除了每个功能的概述，本指南还向你演练它们的配置和部署。

可配置的代码完整性

Windows 操作系统由以下两个操作模式组成：用户模式和内核模式。操作系统的基础部分在内核模式中运行，在该模式中 Windows 操作系统直接与硬件资源交互。用户模式主要负责运行应用程序，以及针对硬件资源请求通过内核模式传递信息。例如，当在用户模式下运行的应用程序需要额外的内存时，用户模式进程必须从内核模式请求资源，而不是直接从 RAM 请求资源。

代码完整性是 Windows 操作系统的组件，可验证 Windows 正在运行的代码是否受信任且是否安全。和操作系统一样，Windows 代码完整性还包含两个主要组件：内核模式代码完整性 (KMCI) 和用户模式代码完整性 (UMCI)。KMCI 已应用于最新版本的 Windows 操作系统中，以阻止内核模式运行未签名的驱动程序。尽管该组件有效，但驱动程序并非恶意软件侵入操作系统的内核模式空间的唯一途径。在 Windows 10 中，Microsoft 提高了全新的内核模式代码，并向企业提供了设置其自己的 UMCI 和 KMCI 标准的方法。从代码完整性服务本身开始一直到 Windows 客户端用于验证某一应用程序是否允许运行的相关策略，Microsoft 使 Windows 10 比先前的任何 Windows 版本都要安全的多。过去，UMCI 仅在 Windows RT 和 Windows 手机版设备上可用，这使这些设备难以感染病毒和恶意软件。在 Windows 10 中，提供这些相同的成功 UMCI 标准。

过去，大多数恶意软件都未经签名。只需通过部署代码完整性策略，组织就可以立即保护它们自己免遭未签名的恶意软件攻击，预计能够抵御当前超过 95% 的攻击。通过使用代码完整性策略，企业可以精确选择允许哪些二进制文件同时在用户模式和内核模式中运行，从签名者到哈希级别均可。完全强制执行后，它可以让 Windows 中的用户模式像移动电话一样运行，方法是仅允许信任和运行特定应用程序或特定签名。从根本上讲，此功能仅更改了企业中的安全性。此额外的安全性既不限于 Windows 应用，也不需要重写应用程序，即可与未签名的现有应用程序兼容。你可以在不启用 Device Guard 的情况下实现可配置的代码完整性，但是它旨在有受支持的硬件可用时与 Device Guard 结合使用。有关如何配置、部署和管理代码完整性策略的详细信息，请参阅代码完整性策略部分。

硬件安全功能和基于虚拟化的安全性

Device Guard 核心功能和保护从硬件级别开始。带有配备了 SLAT 技术和虚拟化扩展的处理器的设备（例如 Intel 虚拟化技术 (VT-x) 和 AMD-V）将能够充分利用基于虚拟化的安全 (VBS) 功能，这些功能可以增强 Windows 安全性。Device Guard 利用 VBS 隔离对操作系统的安全性和完整性至关重要的核心 Windows 服务。此隔离使这些服务在用户和内核模式下不再易受攻击，并针对当今使用的大部分恶意软件充当无法逾越的屏障。其中一个隔离服务（称为 Windows 核心完整性服务）驱动 Device Guard 内核模式可配置的代码完整性功能。这将阻止已侵入内核模式操作的代码危害代码完整性服务。

另一个利用 VBS 的 Windows 10 功能是凭据保护。凭据保护提供对 Active Directory 域用户的额外保护，方法是将域凭据存储在虚拟化容器内，该容器承载 Windows 安全服务（例如代码完整性）。通过将这些域凭据与活动用户模式和内核模式隔离，它们被盗的风险将大幅降低。有关凭据保护如何补充 Device Guard 的详细信息，请参阅带有凭据保护的 Device Guard 部分。有关如何启用凭据保护的信息，请参阅启用凭据保护部分。

带有 AppLocker 的 Device Guard

尽管 AppLocker 不被视为一项全新的 Device Guard 功能，但在强制执行的代码完整性不能完全实现或其功能不能在每一个所需方案中运行时，它将补充 Device Guard 功能。有许多将代码完整性策略与 AppLocker 规则结合使用的方案。作为最佳实践，应在你的组织中尽可能遵从最严格的级别来强制执行代码完整性策略，然后可以使用 AppLocker 将限制级别微调到一个更低的级别。

注意  Device Guard 功能需要 AppLocker 补充的一个示例是 当你的组织希望限制通用应用程序时。通用应用程序已由 Microsoft 验证为能可靠运行，但组织可能不想要允许特定的通用 应用程序在其环境中运行。你可以通过使用 AppLocker 规则实现此强制执行。

 

AppLocker 和 Device Guard 应在你的组织中并行运行，这不仅可以让这两个安全功能在同一时间达到最佳效果，还可以为尽可能多的设备提供最全面的安全性保护。除了这些功能，Microsoft 还建议你继续维护企业防病毒解决方案，以实现全面的企业安全项目组合。

带有凭据保护的 Device Guard

虽然凭据保护并不是 Device Guard 内的某项功能，但是许多组织希望将凭据保护与 Device Guard 一同部署，以针对凭据盗窃提供附加保护。与内核模式代码完整性的基于虚拟化的保护类似，凭据保护利用虚拟机监控程序技术保护域凭据。此缓解措施的目标是阻止哈希传递和票证传递技术的使用。通过利用多因素身份验证与凭据保护，组织可以获得针对此类威胁的额外保护。有关如何将凭据保护部署到 Windows 10 企业版客户端的信息，请参阅启用凭据保护部分。除了 凭据保护的客户端启用，组织还可以在 CA 和域控制器级别上部署缓解措施以帮助防止凭据盗窃。Microsoft 将在将来发布有关这些其他缓解措施的详细信息。

统一可管理性

通过使用 IT 专业人员日常使用的熟悉企业和客户端管理工具，你可以轻松管理 Device Guard 功能。使用以下管理工具来启用和管理 Device Guard：

• 组策略。Windows 10 提供了一个管理模板，可用于为你的组织配置和部署可配置的代码完整性策略。借助此模板，你还可以指定希望启用和部署的基于硬件的安全功能。你可以管理这些设置以及你的现有组策略对象 (GPO)，以便于实现 Device Guard 功能。除了这些代码完整性和基于硬件的安全功能，你还可以使用组策略来帮助管理你的目录文件。有关目录文件的详细信息，请参阅目录文件部分。

• Microsoft System Center Configuration Manager。 你可以使用 System Center Configuration Manager 简化目录文件、代码完整性策略和基于硬件的安全功能的部署和管理，也可以提供版本控制。有关如何使用 System Center Configuration Manager 部署目录文件的详细信息，请参阅使用 System Center Configuration Manager 部署目录文件部分。

• Microsoft Intune。在 Microsoft Intune 的将来发布中，组织将能够利用 Intune 部署和管理代码完整性策略和目录文件。

• Windows PowerShell。Windows PowerShell 主要用于创建代码完整性策略和为其提供服务。这些策略代表 Device Guard 的功能最强大的组件。有关如何创建、审核、强制执行和部署代码完整性策略以及为其提供服务的分步演练，请参阅代码完整性策略部分。

这些选项可提供你用于管理现有企业管理解决方案的相同体验。有关如何在组织中管理和部署 Device Guard 硬件和代码完整性功能的详细信息，请参阅 Device Guard 部署部分。

计划 Device Guard

在本部分中，你将了解以下主题：

• 企业代码完整性部署方法。组织中的 Device Guard 部署需要使用计划的方法。在此部分中，你将获得有关如何实现组织中的企业代码完整性部署方法的高级建议。

• Device Guard 部署方案。当你计划 Device Guard 部署时，Microsoft 建议你将组织中的每台设备分类为部署方案。这些方案将为你的 Device Guard 部署提供路线图。

• 代码签名采用。代码签名对 Device Guard 提供的安全性很重要。本部分概述了代码签名的选项和每个方法的优势和劣势。

• 硬件注意事项。多个 Device Guard 功能需要高级硬件。本部分概述了其中每个功能的要求以及在下一次硬件刷新时应注意的事项。

企业代码完整性部署方法

要考虑使用 Device Guard 的企业不应期待一下子部署到他们的整个组织。Device Guard 实现需要你同时为对最终用户和 IT 专业人员的影响进行规划。此外，将 Device Guard 功能部署到企业需要计划的且分阶段的方法，以确保最终用户系统完全支持，并且可随时强制执行这些新安全限制。执行以下高级任务来实现将 Device Guard 部署到企业的方法：

1. 将设备分组为类似的函数。将计算机分类为 Device Guard 部署方案部分中所述的组。这将开始 Device Guard 部署的路线图，并提供较简单和较困难实现的组。从此处，评估必要的 Device Guard 策略的数量。最简单的解决方案是锁定整个企业，但它可能不符合你的各个部门的需求。

   若要为你的组织发现相应数量的策略，请尝试将已定义的组分离为部门或角色。然后询问一些问题：每个部门或角色需要何种软件来完成工作？他们是否能够安装和运行其他部门的软件？我们是否需要创建一个符合应用程序目录的基本代码完整性策略？用户应能够安装任何应用程序还是仅选择“允许”列表中的应用程序？我们是否允许用户使用其自己的外围设备？这些问题将帮助你发现你的组织的必要策略的数量。最后，请尝试专注于哪些人员或部门将需要额外级别的权限。例如，部门 x 是否应能够安装和运行应用程序 xyz，即使其他部门都不能执行此操作？如果答案是“是”并且合乎情理，则该组将需要一个辅助完整性策略。如果不是，则你可能可以合并多个策略以简化管理。有关可配置的代码完整性策略的详细信息，请参阅代码完整性策略部分。

2. 从“黄金”电脑创建代码完整性策略。创建设备组后，你可以创建代码完整性策略以符合这些组，类似于你管理公司映像的方法。当你分隔这些组并设置模拟这些个别组所需的软件和硬件的黄金电脑时，请从每一台电脑创建代码完整性策略。创建这些策略后，你可以合并这些代码完整性策略以创建一个主策略，或者可以单独管理和部署它们。有关如何创建代码完整性策略的分步说明，请参阅从黄金电脑创建代码完整性策略部分。

3. 审核和合并代码完整性策略。Microsoft 建议你在强制执行代码完整性策略之前，在审核模式下测试这些策略。审核模式允许管理员在系统上运行代码完整性策略，但实际上不会阻止任何操作。记录事件以及策略的每个例外，而不是允许应用程序运行。这样一来，你便可以轻松地突出显示在初始扫描期间未发现的任何问题。你可以使用审核事件创建其他代码完整性策略，然后将它们合并到现有策略中。有关如何审核代码完整性策略的详细信息，请参阅审核代码完整性策略部分。

4. 评估当前未签名的 LOB 应用程序，并为它们创建目录文件。目录文件允许组织对当前没有经过数字签名的二进制文件的应用程序或客户希望为其添加辅助签名的应用程序进行签名。这些 应用程序可以是内部应用程序或来自第三方的应用程序，并且此过程不需要任何重新打包应用程序的操作。当你在高于哈希值的规则级别上创建代码完整性策略时，你不会发现未签名的应用程序。若要将这些应用程序包含在你的代码完整性策略中，只需创建、登录和部署目录文件。有关目录文件的信息，请参阅目录文件部分。

5. 启用所需的硬件安全功能。Device Guard 部署方案部分中发现的每种类型的设备充分利用不同的软件和硬件完整性配置。你应该独立于代码完整性策略评估基于硬件的安全功能，因为它们提供补充性功能。有关如何配置 Device Guard 基于硬件的安全功能的信息，请参阅配置基于硬件的安全功能部分。

6. 部署代码完整性策略和目录文件。在你创建和签名必要的目录文件并创建和审核代码完整性策略后，你可以随时分阶段部署它们。Microsoft 强烈建议你将这些组件部署到用户的测试组，即使在你的 IT 组织已测试并审查它们后也是如此。这在你更广泛地部署目录文件和策略前提供了最终质量控制验证。有关如何使用组策略部署目录文件的信息，请参阅使用组策略部署目录文件部分。有关如何部署代码完整性策略的其他信息，请参阅使用组策略部署代码完整性策略部分。

Device Guard 部署方案

若要帮助简化将 Device Guard 部署到组织的操作，Microsoft 建议你将设备分组为此部分中所述的部署方案。Device Guard 不是组织可以简单地“打开”的功能；相反，它通常需要分阶段的实现方式。若要查看这些方案在哪些方面适合整体 Device Guard 部署方法，请参阅企业代码完整性部署方法部分。

固定工作负载设备

固定工作负载设备上的批准应用程序列表很少更改，因为它们日复一日地执行相同的任务。此类设备的示例包括网亭、销售点系统和调用中心电脑。这些设备可以轻松地利用 Device Guard 的完整功能，并且只需进行很少的管理或策略修改。这些设备的 Device Guard 实现非常轻松，只需要很少的持续管理。完全实现 Device Guard 后，用户将只能运行 IT 部门安装、管理和信任的应用程序。

适用于固定工作负载设备的 Device Guard 组件包括：

• KMCI VBS 保护

• 强制 UMCI 策略

完全托管设备

完全托管设备具有以下特征：IT 部门限制在其上安装和运行的软件，但允许用户请求安装其他软件或在应用程序目录中提供批准软件的列表。此类设备的示例包括锁定的、公司拥有的台式机和笔记本电脑。使用这些设备，建立初始基线代码完整性策略并强制执行代码 完整性策略。IT 部门管理这些策略并在 System Center Configuration Manager 目录中批准或提供新应用程序时更新设备。

适用于完全托管设备的 Device Guard 组件包括：

• KMCI VBS 保护

• 强制 UMCI 策略

在此方案中，将提供并信任应用程序，并在用户请求新应用程序时不断地重新评估信任策略。当在所有这些设备上信任应用程序时，对该应用程序的新用户请求不需要策略更新（符合应用程序目录）。此外，你可以将此操作与新应用程序（应添加到中心应用程序目录）的上架过程结合。Device Guard 到完全托管设备的初始实现很简单，但需要更多的管理开销来管理新请求和批准的应用程序的受信任签名。

轻托管设备

轻托管设备是用户拥有完全控制权的公司所有的计算机，并且包括安装在其上的内容。这些设备运行组织的防病毒解决方案和客户端管理工具，但不受软件请求或合规性策略的限制。

适用于轻托管设备的 Device Guard 组件包括：

• KMCI VBS 保护

• 审核模式下的 UMCI 策略

自带设备办公

Device Guard 不是在自带设备办公 (BYOD) 模型中管理设备的好方法。当允许员工自带设备办公时，在这些设备上管理用户模式应用程序可能会使用户在工作之外难以使用他们自己的设备。此外，从管理角度来看，难以维护 Device Guard 功能。对于此组中的设备，可使用基于 MDM 的条件访问解决方案（如 Microsoft Intune）探索备用的强化和安全功能。

代码签名采用

代码签名对可配置的代码完整性策略的成功实现至关重要。这些策略可以信任来自独立软件供应商和客户的签名证书。在 Windows 10 中，将对所有 Windows 应用商店应用程序进行签名。此外，你还可以通过将签名证书添加到代码完整性策略来轻松信任任何其他已签名的应用程序。

对于未签名的应用程序，客户有多个对其进行签名的选项，以便代码完整性策略可以信任它们。第一个选项是传统嵌入式代码签名。具有内部开发团队的组织可以将二进制代码签名合并到他们的应用程序开发过程中，然后只需将签名证书添加到他们的代码完整性策略。第二个对未签名的应用程序进行签名的选项是使用目录文件。在 Windows 10 中，客户可以在监视应用程序的安装和初始运行时创建目录文件。有关对现有未签名的 LOB 应用程序或第三方应用程序进行签名的详细信息，请参阅现有业务线应用程序部分。

现有业务线应用程序

到目前为止，如果现有 LOB 应用程序由 Windows 应用商店以外的源签名或完全未签名，则难以信任它们。在 Windows 10 中，简化了对你的现有 LOB 和第三方未签名应用程序进行签名的操作。此新签名方法不需要以任何方式重新打包应用程序。使用目录文件，管理员只需监视安装和初始启动即可对这些未签名的应用程序进行签名。通过使用此监视信息，管理员可以生成目录文件。目录文件只是已发现的二进制文件的安全哈希算法 2 (SHA2) 哈希列表。每次更新应用程序都将更新这些二进制文件的哈希值，因此需要更新的目录文件。为了简化管理，请考虑将嵌入式代码签名合并到应用程序开发过程中。有关如何生成目录文件的详细信息，请参阅目录文件部分。

注意  

目录文件是单独二进制文件的哈希值的列表。如果更新已扫描的应用程序，你将需要创建新的 目录文件。也就是说，对于任何将来的应用程序，仍然强烈建议使用二进制文件签名， 以便不需要目录文件。

 

在创建目录文件时，必须通过使用企业公钥基础结构 (PKI) 或已购买的代码签名证书对其进行签名。完成签名后，代码完整性策略可以信任签名者或这些文件的签名证书。有关目录文件签名的详细信息，请参阅目录文件部分。

应用程序开发

尽管在使用目录文件打包后可以对内部应用程序进行签名，但 Microsoft 强烈建议将嵌入式代码签名合并到应用程序开发过程中。在对应用程序进行签名时，只需将用于对应用程序进行签名的代码签名证书添加到代码完整性策略。这可确保代码完整性策略将信任任何将来使用该证书签名的应用程序。在你实现代码完整性策略时，将代码签名嵌入到内部应用程序开发过程有益于 IT 组织。

硬件注意事项

仔细考虑你要在下一次硬件刷新期间购买哪些硬件供应商和特定模型对于组织的 Device Guard 实现工作的成功至关重要。为了符合你的当前硬件生命周期，在确定组织中的硬件替换的相应顺序时，请考虑企业代码完整性部署方法部分中所讨论的过程。Device Guard 应分阶段部署；因此，你有时间有条不紊地计划其实现。

实现 Device Guard 的各种功能需要不同的硬件功能。将可能存在一些个别功能可使用当前硬件启用，而另一些则不能。但是，对于要完整实现 Device Guard 的组织，将需要多个高级硬件功能。有关 Device Guard 组件所需的硬件功能的其他详细信息，请参阅下表。

要求	介绍
Windows 10 企业版	电脑必须运行 Windows 10 企业版。
UEFI 固件版本 2.3.1 或更高版本以及安全启动	若要验证固件是否在使用 UEFI 版本 2.3.1 或更高版本以及安全启动，你可以根据 System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby Windows 硬件兼容性计划要求对此进行验证。
虚拟化扩展	若要支持基于虚拟化的安全性，则需要以下虚拟化扩展： Intel VT-x 或 AMD-V 二级地址转换
固件锁定	应锁定固件设置以防止其他操作系统启动和防止对 UEFI 设置的更改。你还应禁用除了从硬盘驱动器启动以外的启动方式。
x64 体系结构	基于虚拟化的安全性在 Windows 虚拟机监控程序中使用的功能仅可在 64 位的电脑上运行。
VT-d 或 AMD-Vi IOMMU（输入/输出内存管理单元）	在 Windows 10 中，IOMMU 增强了系统应对内存攻击的复原能力。¹
安全固件更新过程	若要验证固件是否符合安全固件更新过程，你可以根据 System.Fundamentals.Firmware.UEFISecureBoot Windows 硬件兼容性计划要求对此进行验证。

 

Device Guard 部署

在本部分中，你将了解以下主题：

• 基于配置硬件的安全功能。本部分说明如何在 Device Guard 中启用基于硬件的安全功能。此外，你还验证这些功能是否通过使用 Windows Management Infrastructure (WMI) 和 Msinfo32.exe 启用。

• 目录文件。在本部分中，创建、签名和部署目录文件。你通过使用组策略和 System Center Configuration Manager 部署目录 文件。此外，你还可以出于报告目的使用 System Center Configuration Manager 清点已部署的目录文件。

• 代码完整性策略。此部分提供有关如何创建、审核、维护、合并、部署和删除已签名和未签名的可配置代码完整性策略的信息。

配置基于硬件的安全功能

基于硬件的安全功能构成了大部分的 Device Guard 安全产品/服务。VBS 增强 Device Guard 最重要的功能：可配置的代码完整性。在 Device Guard 中配置基于硬件的安全功能有三个步骤：

1. 验证是否满足并且已启用硬件要求。验证你的客户端计算机是否拥有必要的硬件来运行这些功能。基于硬件的安全功能的硬件要求列表可在硬件注意事项部分中找到。此外，如果你要寻找新硬件，请考虑 Device Guard 就绪的设备部分中讨论的设备。

2. 启用必要的 Windows 功能。启用基于硬件的安全性所需的 Windows 功能有多种方法。有关需要哪些 Windows 功能的详细信息，请参阅基于虚拟化的安全性的 Windows 功能要求部分。

3. 启用所需的功能。当已启用必要的硬件和 Windows 功能时，你可以随时启用所需的基于硬件的安全功能。有关 UEFI 安全启动，请参阅启用 UEFI 安全启动部分。有关如何启用 KMCI 服务的 VBS 保护的信息，请参阅启用内核模式代码完整性的基于虚拟化的保护部分。最后，有关如何启用凭据保护的信息，请参阅启用凭据保护部分。

基于虚拟化的安全性的 Windows 功能要求

除了硬件注意事项部分中找到的硬件要求，你必须先启用某些操作系统功能，然后才可以启用 VBS：Microsoft Hyper-V 和隔离的用户模式（如图 1 所示）。

注意  

你可以使用 Windows PowerShell 或部署映像服务和 管理手动配置这些功能。有关这些功能的特定信息，请参考凭据保护文档。

 

图 1.为 VBS 启用操作系统功能

启用这些功能后，你可以根据需要配置任何基于硬件的安全功能。有关如何启用内核模式代码完整性的基于虚拟化的保护的信息，请参阅启用内核模式代码完整性的基于虚拟化的保护部分。有关如何启用 UEFI 安全启动的信息，请参阅启用统一可扩展固件接口安全启动部分。最后，有关如何启用凭据保护的其他信息，请参阅启用凭据保护部分。

启用统一可扩展固件接口安全启动

在你开始此过程前，请验证目标设备是否满足硬件注意事项部分中所列的 UEFI 安全启动的硬件要求。配置 UEFI 安全启动有两个选项：手动配置相应的注册表项和组策略部署。完成以下步骤以在运行 Windows 10 的计算机上手动配置 UEFI 安全启动：

注意  

安全启动有两个平台安全级别：独立安全启动和带有 DMA 保护的安全启动。DMA 保护提供额外的内存保护，但仅在处理器包含 DMA 保护 (IOMMU) 技术的系统上启用。如果不存在 IOMMU 且禁用 DMA 保护，则客户将失去针对基于驱动程序的攻击的保护。

 

1. 导航到“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard”注册表子项。

2. 将“EnableVirtualizationBasedSecurity DWORD”****值设置为“1”。

3. 根据情况设置“RequirePlatformSecurityFeatures DWORD”****值：

   • 将此值设置为“1”以启用“安全启动”****选项。

   • 将此值设置为“2”以启用“带有 DMA 保护的安全启动”****选项。

4. 重新启动客户端计算机。

遗憾的是，在企业中的每台受保护的计算机上手动执行这些步骤会非常耗时。组策略针对向组织部署 UEFI 安全启动提供了更简单的方法。此示例创建一个测试组织单元 (OU)，称为 DG Enabled PCs。如果你首选将该策略链接到现有 OU，然后使用相应名称的计算机安全组来设置 GPO 范围，你当然可以这样做。

注意  

Microsoft 建议你先在一组测试计算机上测试启用此功能，然后再将其部署到当前向用户部署的计算机上。

 

使用组策略部署安全启动

1. 若要创建新 GPO，请右键单击要将 GPO 链接到的 OU，然后单击“在此域中创建 GPO，并将其链接到此处”。

   

   图 2.创建新的已链接 OU 的 GPO

2. 将新的 GPO 命名为“Contoso 安全启动 GPO 测试”****。 此示例使用 Contoso Secure Boot GPO Test 作为 GPO 的名称。你可以为此示例选择任何名称。理想情况下，名称将与现有 GPO 命名约定保持一致。

3. 若要打开组策略管理编辑器，请右键单击新 GPO，然后单击“编辑”。

4. 在所选的 GPO 内，导航到“计算机配置”\“管理模板”\“系统”\“Device Guard”。然后，右键单击“打开基于虚拟化的安全性”****，然后单击“编辑”。

   

   图 3.启用 VBS

5. 选择“启用”选项，然后从“选择平台安全级别”列表中选择“安全启动和 DMA 保护”。

   

   图 4.启用安全启动

   注意  

   当与 DMA 保护组合时，将最大化 Device Guard 安全启动。如果你的硬件包含 DMA 保护所需的 IOMMU，请确保选择“安全启动和 DMA 保护”平台安全级别。如果你的硬件不包含 IOMMU，则有几个通过利用不带有 DMA 保护的安全启动所提供的减缓措施。

    

6. 关闭组策略管理编辑器，然后重新启动 Windows 10 测试计算机。 在你配置此设置后，将在重新启动时启用 UEFI 安全启动。

7. 在测试计算机的事件日志中检查 Device Guard GPO。

   已处理的 Device Guard 策略将记录在位于 Application and Services Logs\Microsoft\Windows\DeviceGuard-GPEXT\Operational 的事件查看器中。当成功处理“打开基于虚拟化的安全性”****策略时，将记录事件 ID 7000，其中包含策略内的所选设置。

启用内核模式代码完整性的基于虚拟化的安全性

在开始此过程前，请验证所需的计算机是否满足硬件注意事项部分中所找到的 VBS 的硬件要求，并启用基于虚拟化的安全 Windows 功能要求部分中所讨论的 Windows 功能。完成验证后，你可以使用以下两种方法之一启用 KMCI 的基于虚拟化的保护：手动配置相应的注册表子项和组策略部署。

注意  

系统上的所有驱动程序都必须与代码完整性的基于虚拟化的保护兼容；否则，你的系统可能失败。Microsoft 建议你先在一组测试计算机上启用此功能，然后在已部署的计算机上启用它。

 

若要手动配置 KMCI 的基于虚拟化的保护：

1. 导航到“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard”注册表子项。

2. 将“HypervisorEnforcedCodeIntegrity DWORD”****值设置为“1”。

3. 重新启动客户端计算机。

在企业中的每台受保护的计算机上手动执行这些步骤会非常耗时。相反，使用组策略来部署 KMCI 的基于虚拟化的保护。此示例创建一个称为 DG Enabled PCs 的测试 OU，你将使用它来链接 GPO。如果你首选将该策略链接到现有 OU 而不是创建一个测试 OU，然后使用相应命名的计算机安全组来设置策略范围，这便是另一个选项。

注意  

Microsoft 建议你先在一组测试计算机上测试启用此功能，然后再将其部署到当前向用户部署的计算机上。如果未经测试，此功能可能会导致系统不稳定并最终导致客户端操作系统失败。

 

若要使用组策略来配置 KMCI 的 VBS：

1. 创建新的 GPO：右键单击你希望将 GPO 链接到的 OU，然后单击“在此域中创建 GPO，并将其链接到此处”。

   

   图 5.创建新的已链接 OU 的 GPO

2. 将新的 GPO 命名为“Contoso VBS CI 保护 GPO 测试”****。

   此示例使用 Contoso VBS CI Protection GPO Test 作为 GPO 的名称。你可以为此示例选择任何你偏好的名称。理想情况下，此名称将与现有 GPO 命名约定保持一致。

3. 打开组策略管理编辑器：右键单击新 GPO，然后单击“编辑”。

4. 在所选的 GPO 内，导航到“计算机配置”\“管理模板”\“系统”\“Device Guard”。然后，右键单击“打开基于虚拟化的安全性”****，然后单击“编辑”。

   

   图 6.启用 VBS

5. 选择“启用”****选项，然后选中“启用代码完整性的基于虚拟化的保护”复选框。

   

   图 7.启用 KMCI 的 VBS

6. 关闭组策略管理编辑器，然后重新启动 Windows 10 测试计算机。 配置此设置后，KMCI 的 VBS 将在重新启动后生效。

7. 检查 Device Guard GPO 的测试客户端事件日志。

   已处理的 Device Guard 策略将记录在位于 Application and Services Logs\Microsoft\Windows\DeviceGuard-GPEXT\Operational 下的事件查看器中。当成功处理“打开基于虚拟化的安全性”****策略时，将记录事件 ID 7000，其中包含策略内的所选设置。

启用凭据保护

凭据保护专门为域用户提供一层额外的凭据保护，方法是将凭据存储在虚拟化容器中，远离内核和用户模式操作系统。这使受害的系统更加难以获得凭据的访问权限。除了凭据保护的客户端启用之外，你还可以在证书颁发机构和域控制器级别部署其他缓解措施来防止凭据盗窃。Microsoft 将在将来发布有关这些其他缓解措施的详细信息。

在开始此过程前，请验证所需的系统是否满足硬件注意事项部分中所找到的 VBS 的硬件要求，以及是否已启用基于虚拟化的安全 Windows 功能要求部分中所列的 Windows 功能。完成验证后，你可以通过配置相应的注册表子项或通过组策略部署来手动启用凭据保护。

若要手动配置凭据保护的 VBS：

1. 导航到“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa”注册表子项。

2. 将“LsaCfgFlags DWORD”****值设置为“1”。

3. 重新启动客户端计算机。

若要避免在手动部署中花费不必要的时间，请使用组策略将凭据保护部署到组织。此示例将创建一个称为 DG Enabled PCs 的测试 OU。若要启用凭据保护，你可以链接到任何 OU，然后使用安全组设置 GPO 的应用程序的范围。

注意  

Microsoft 建议你先启用凭据保护，然后再将计算机加入域，以确保所有凭据都受到妥善保护。在映像处理期间设置相应的注册表子项对于实现此保护将是理想的。

 

若要使用组策略启用凭据保护：

1. 创建新的 GPO：右键单击你希望将 GPO 链接到的 OU，然后单击“在此域中创建 GPO，并将其链接到此处”。

   

   图 8.创建新的已链接 OU 的 GPO

2. 将新的 GPO 命名为“Contoso 凭据保护 GPO 测试”****。

   此示例使用 Contoso Credential Guard GPO Test 作为 GPO 的名称。你可以为此示例选择任何你偏好的名称。理想情况下，此名称将与现有 GPO 命名约定保持一致。

3. 打开组策略管理编辑器：右键单击新 GPO，然后单击“编辑”。

4. 在所选的 GPO 内，导航到“计算机配置”\“管理模板”\“系统”\“Device Guard”。右键单击“打开基于虚拟化的安全性”****，然后单击“编辑”。

   

   图 9.启用 VBS

5. 选择“启用”****选项，然后选中“启用凭据保护”复选框。

   

   图 10.启用凭据保护

6. 关闭组策略管理编辑器，然后重新启动 Windows 10 测试计算机。

   注意  

   默认平台安全级别为“安全启动”。如果 IOMMU 在受保护的计算机内可用，则建议你选中“安全启动和 DMA 保护”****来最大程度提高凭据保护所提供的缓解措施。

    

7. 检查 Device Guard GPO 的测试客户端事件日志。

注意  

所有已处理的 Device Guard 策略都将记录在位于 Services Logs\Microsoft\Windows\DeviceGuard-GPEXT\Operational 下的事件查看器中。

 

有关凭据保护如何工作以及其他配置选项的其他信息，请参阅凭据保护文档。

验证已启用的 Device Guard 基于硬件的安全功能

Windows 10 和 Windows Server 2016 及更高版本具有一个 WMI 类，用于与 Device Guard 相关的属性和功能：Win32_DeviceGuard。此类可使用以下命令从提升的 Windows PowerShell 会话查询：

Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard

注意  

Win32_DeviceGuard WMI 类仅在 Windows 10 企业版上可用。

此命令的输出提供基于可用硬件的安全功能以及当前已启用的功能的详细信息。有关每个属性的意义的详细信息，请参考表 1。

 

表 1.Win32_DeviceGuard 属性

属性	描述	有效值
AvailableSecurityProperties	此字段有助于枚举和报告 Device Guard 的相关安全属性的状态。	0. 如果存在，则设备上不存在相关属性。 1.如果存在，则虚拟机监控程序可用。 2.如果存在，则安全启动可用。 3.如果存在，则 DMA 保护可用。
InstanceIdentifier	特定于特定设备的字符串。	由 WMI 确定。
RequiredSecurityProperties	此字段描述启用基于虚拟化的安全性所需的安全属性。	0. 无需任何属性。 1.如果存在，则需要安全启动。 2.如果存在，则需要 DMA 保护。 3.如果存在，则需要安全启动和 DMA 保护。
SecurityServicesConfigured	此字段指示已配置凭据保护还是 HVCI 服务。	0. 未配置任何服务。 1. 如果存在，则配置凭据保护。 2.如果存在，则配置 HVCI。
SecurityServicesRunning	此字段指示运行的是凭据保护还是 HVCI 服务。	0.没有运行任何服务。 1.如果存在，则运行凭据保护。 2.如果存在，则运行 HVCI。
Version	此字段列出了此 WMI 类的版本。	现在，唯一有效的值是 1.0。
VirtualizationBasedSecurityStatus	此字段指示 VBS 已启用还是正在运行。	0. VBS 未启用。 1. VBS 已启用但尚未运行。 2. VBS 已启用且正在运行。
PSComputerName	此字段列出了计算机名称。	计算机名称的所有有效值。

 

确定可用和已启用的 Device Guard 功能的另一个方法是从提升的 PowerShell 会话运行 msinfo32.exe。当你运行此程序时，将在“系统摘要”部分底部显示 Device Guard 属性，如图 11 所示。

图 11.系统摘要中的 Device Guard 属性

目录文件

在系统上强制执行 Device Guard 要求每个受信任的应用程序都有签名或者其二进制文件哈希已添加到代码完整性策略。对于许多组织，在考虑未签名的 LOB 应用程序时，这可能是一个问题。为了避免组织为这些应用程序重新打包和签名的要求，Windows 10 包含了一个称为程序包检查器的工具，可监视任何已部署和已执行的二进制文件的安装过程。如果该工具发现此类文件，它会在目录文件中详细列出它们。这些目录文件为你提供了信任现有未签名应用程序的方法（无论它在内部开发还是由第三方开发），以及信任已签名应用程序的方法（对于这些应用程序，你不希望信任签名者而只信任特定的应用程序）。完成创建后，将对这些文件进行签名，签名证书会添加到你的现有代码完整性策略，并且目录文件本身将分发到客户端。

注意  

创建和使用目录文件需要 Windows 10 企业版或 Windows Server 2016。

 

创建目录文件

将未签名的应用程序添加到代码完整性策略的第一步是创建目录文件。若要创建目录文件，请将以下每个命令复制到提升的 Windows PowerShell 会话中，然后完成以下步骤：

注意  

当你建立命名约定时，它会使将来检测到已部署的目录文件更容易。在本指南中，你将使用 *-Contoso.cat 作为命名约定。有关为何此做法对清点或检测目录文件有帮助的详细信息，请参阅使用 System Center Configuration Manager 清点目录文件部分。

 

1. 请确保代码完整性策略当前正在审核模式下运行。

   程序包检查器不会始终检测到已在安装过程期间从计算机中删除的安装文件。若要确保还信任这些二进制文件，则在审核模式下，将你在从黄金电脑创建代码完整性策略和审核代码完整性策略部分中创建和审核的代码完整性策略部署到你正在运行程序包检查器的系统。

   注意  

   不应在运行强制的 Device Guard 策略（仅有一个策略在审核模式下运行）的系统上执行此过程。如果当前正在强制执行某个策略，则你将无法安装和运行应用程序。

    

2. 启动程序包检查器，然后扫描驱动器 C:

   PackageInspector.exe Start C:

   注意  

   程序包检查器可以在任何本地驱动器上监视安装。在此示例中，我们在驱动器 C 上安装应用程序，但可以使用任何其他驱动器。

    

3. 将安装媒体复制到驱动器 C。

   通过将安装媒体复制到驱动器 C，你确保程序包检查器检测到并编录实际的安装程序。如果你跳过此步骤，则进一步的代码完整性策略可能信任应用程序运行，但不信任安装。

4. 安装并启动应用程序。

   将应用程序安装到驱动器 C。当完成安装时，启动该应用程序并确保已安装所有产品更新，并在扫描期间捕获了所有可下载的内容。完成后，请关闭并再次重新打开该应用程序一次，以确保扫描已捕获所有二进制文件。

   注意  

   在程序包检查器运行时运行的每个二进制文件都将在目录中捕获。因此，请确保不要在扫描期间运行其他安装或更新，以最大程度降低信任不正确的二进制文件的风险。或者，如果你希望将多个应用程序添加到单个目录文件，只需在当前扫描运行时重复安装并运行进程。

    

5. 停止扫描，然后生成定义和目录文件。 当完成应用程序安装和初始设置时，停止程序包检查器扫描，并使用以下命令在桌面上生成目录和定义文件：

   $ExamplePath=$env:userprofile+"\Desktop"

   $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"

   $CatDefName=$ExamplePath+"\LOBApp.cdf"

   PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName

注意  

此扫描将为每个发现的二进制文件编录哈希值。如果更新已扫描的应用程序，请再次完成此过程以信任新的二进制文件的哈希值。

 

完成后，这些文件将保存到你的桌面。若要在代码完整性策略内信任此目录文件，必须先对该目录进行签名。然后，签名证书可以包含在代码完整性策略中，并且目录文件可以分发给个别客户端计算机。可以使用证书和 SignTool.exe（Windows SDK 中提供的免费工具）对目录文件进行签名。有关使用 SignTool.exe 对目录文件进行签名的详细信息，请参阅使用 SignTool.exe 的目录签名部分。

使用 SignTool.exe 的目录签名

Device Guard 使组织可以轻松地签名和信任未签名的现有 LOB 应用程序。在此部分中，你可以使用 PackageInspector.exe 对你在前面部分中生成的目录文件进行签名。有关如何创建目录文件的信息，请参阅创建目录文件部分。在此示例中，你需要以下内容：

• SignTool.exe，位于 Windows 软件开发工具包（SDK - Windows 7 或更高版本）中

• 你在创建目录文件部分中生成的目录文件，或你已创建的另一个目录文件

• 内部证书颁发机构 (CA) 代码签名证书或已购买的代码签名证书

如果你没有代码签名证书，请参阅创建 Device Guard 代码签名证书部分以获取有关如何创建该证书的演练。除了使用你在创建 Device Guard 代码签名证书部分中创建的证书，此示例还对你在创建目录文件部分中创建的目录文件进行签名。如果你要使用备用证书或目录文件，请使用相应的变量和证书更新以下步骤。若要对现有目录文件进行签名，请将以下每个命令复制到提升的 Windows PowerShell 会话中：

1. 初始化将使用的变量：

   $ExamplePath=$env:userprofile+"\Desktop"
   
   $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
   

   注意  

   在此示例中，你使用在创建目录文件部分中创建的目录文件。如果你要对另一个目录文件进行签名，请确保使用正确的信息更新 $ExamplePath 和 $CatFileName 变量。

    

2. 导入代码签名证书。 将用于对目录文件进行签名的代码签名证书导入到签名用户的个人存储中。在此示例中，你使用在创建 Device Guard 代码签名证书部分中创建的证书。

3. 使用 Signtool.exe 对目录文件进行签名：

   <Path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName
   

   注意  

   <Path to signtool.exe> 变量应是 Signtool.exe 实用工具的完整路径。ContosoDGSigningCert 是将用于对目录文件进行签名的证书的使用者名称。此证书应导入到你要尝试对目录文件进行签名的计算机上的个人证书存储中。

    

   注意  

   有关 Signtool.exe 和所有其他开关的其他信息，请访问 MSDN 签名工具页面。

    

4. 验证目录文件数字签名。 右键单击目录文件，然后单击“属性”。在“数字签名”****选项卡上，使用“sha256”算法验证你的签名证书是否存在，如图 12 所示。

   

   图 12.验证签名证书是否存在

5. 将目录文件复制到 C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}。

   出于测试目的，你可以手动将已签名的目录文件复制到它们预期的文件夹。对于大规模实现，Microsoft 建议你使用组策略文件首选项，将相应的目录文件复制到所有所需的计算机或企业系统管理产品，例如 System Center Configuration Manager。执行此操作还可简化目录版本的管理。

使用组策略部署目录文件

若要简化目录文件的管理，你可以使用组策略首选项将目录文件部署到组织中相应的电脑。以下过程向你演练使用名为“Contoso DG 目录文件 GPO 测试”的 GPO 将名为 LOBApp-Contoso.cat 的已签名目录文件部署到名为“启用 DG 的电脑”的测试 OU 的过程。

注意  

本演练需要你有之前创建的已签名目录文件，并拥有用于测试组策略部署的 Windows 10 客户端电脑。有关如何创建目录文件并对其进行签名的详细信息，请参阅目录文件部分。

 

若要使用组策略部署目录文件：

1. 从已安装远程服务器管理工具 (RSAT) 的域控制器或客户端电脑中，通过运行“GPMC.MSC”或搜索“组策略管理”来打开组策略管理控制台 (GPMC)。

2. 创建新的 GPO：右键单击“启用 DG 的电脑”OU，然后单击“在此域中创建 GPO，然后将其链接到此处”****，如图 13 所示。

   注意  

   “启用 DG 的电脑”OU 只是你在此部分中创建的测试 GPO 所链接到的位置示例。你可以使用任何 OU 名称。此外，安全组筛选是你在基于企业代码完整性部署方法部分中所讨论的策略考虑策略分区选项时的一个选项。

    

   

   图 13.创建新 GPO

3. 将新 GPO 命名为“Contoso DG 目录文件 GPO 测试”。

   此示例使用 Contoso DG Catalog File GPO Test 作为 GPO 的名称。你可以为此示例选择任何你偏好的名称。

4. 打开组策略管理编辑器：右键单击新 GPO，然后单击“编辑”****。

5. 在所选的 GPO 内，导航到“计算机配置”\“首选项”\“Windows 设置”\“文件”。右键单击“文件”、指向“新建”****，然后单击“文件”，如图 14 所示。

   

   图 14.创建新文件

6. 配置目录文件共享。

   若要使用此设置来提供 LOBApp-Contoso.cat 的一致部署，则源文件应在每个已部署计算机的计算机帐户可访问的共享上。此示例使用 Windows 10 客户端计算机上的共享，称为 \\Contoso-Win10\Share。将要部署的目录文件复制到此共享。

7. 若要使版本保持一致，在“新文件属性”对话框（图 15）中，从“操作”列表中选择“替换”，以便始终使用最新的版本。

   

   图 15.设置新文件属性

8. 在“源文件”框中，键入你的可访问共享的名称，其中包含目录文件名称（例如，\\Contoso-Win10\share\LOBApp-Contoso.cat）。

9. 在“目标文件”****框中，键入“C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\LOBApp-Contoso.cat”。

   注意  

   LOBApp-Contoso.cat 不是所需的目录名称：创建目录文件部分中使用了此名称，因此此处也使用它。

    

10. 在“新文件属性”框的“通用”****选项卡上，选择“当不再应用此项目时，删除此项目”选项。 执行此操作可确保从每个系统中删除目录文件，以防你需要停止信任此应用程序。

11. 单击“确定”****完成文件创建。

12. 关闭组策略管理编辑器，然后通过运行 GPUpdate.exe 更新测试 Windows 10 计算机上的策略。当已更新策略时，请验证目录文件是否存在于 Windows 10 计算机上的 C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} 中。

使用 System Center Configuration Manager 部署目录文件

作为组策略的替代方法，你可以使用 System Center Configuration Manager 将目录文件部署到环境中的托管计算机。此方法可以简化多个目录文件的部署和管理，以及提供有关每个客户端或集合已部署的目录的报告。除了这些文件的部署之外，System Center Configuration Manager 还可用于为报告和合规性目的清点当前已部署的目录文件。完成以下步骤来为目录文件创建新的部署包：

注意  

以下示例使用名为 \\Shares\CatalogShare 的网络共享作为目录文件的源。如果你有特定于集合的目录文件，或首选单独部署它们，请使用最适合组织的任何文件夹结构。

 

1. 打开配置管理器控制台，然后选择“软件库”工作区。

2. 导航到“概述”\“应用程序管理”、右键单击“程序包”，然后单击“创建程序包”****。

3. 为该程序包命名、将你的组织设置为制造商，然后选择相应的版本号（图 16）。

   

   图 16.指定有关新程序包的信息

4. 单击“下一步”，然后选择“标准程序”****作为程序类型。

5. 在“标准程序”页上，选择一个名称，然后将“命令行”****属性设置为“XCopy \\Shares\CatalogShare C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y”。

6. 在“标准程序”页上，选择以下选项（图 17）：

   • 在“名称”****中，键入“Contoso 目录文件复制程序”。

   • 在“命令行”****中，浏览到程序位置。

   • 在“启动文件夹”中，键入“C:\Windows\System32”****。

   • 从“运行”列表中，选择“隐藏”****。

   • 从“程序可以运行”列表中，选择“用户是否已登录”****。

   • 从“驱动器模式”列表中，选择“使用 UNC 名称运行”****。

   

   图 17.指定有关标准程序的信息

7. 接受向导其余部分的默认值，然后关闭向导。

创建部署程包后，将其部署到集合，以便使客户端收到目录文件。在此示例中，你可以将刚刚创建的程序包部署到测试集合：

1. 在“软件库”工作区中，导航到“概述”\“应用程序管理”\“程序包”、右键单击目录文件包，然后单击“部署”。

2. 在“常规”****页上，选择目录文件将部署到的测试集合，然后单击“下一步”。

3. 在“内容”页上，单击“添加”以选择将内容提供到所选位置的分发点，然后单击“下一步”。

4. 在“部署设置”页上，在“用途”****框中选择“必需”。

5. 在“计划”****页上，单击“新建”。

6. 在“分配计划”对话框中，选择“此事件后立即分配”、将值设置为“尽快”，然后单击“确定”。

7. 在“计划”****页上，单击“下一步”。

8. 在“用户体验”****页（图 18）上，设置以下选项，然后单击“下一步”：

   • 选中“软件安装”****复选框。

   • 选中“在截止日期或在维护时段期间提交更改(需要重新启动)”复选框。

   

   图 18.指定用户体验

9. 在“分发点”页上的“部署选项”框中，选择“从分发点运行程序”，然后单击“下一步”。

10. 在“摘要”****页上，查看选定内容，然后单击“下一步”。

11. 关闭向导。

使用 System Center Configuration Manager 清点目录文件

当目录文件已部署到你的环境内的计算机时，无论是通过使用组策略还是 System Center Configuration Manager，你都可以使用 System Center Configuration Manager 的软件清单功能清点它们。以下过程向你演练通过创建和部署新客户端设置策略启用软件清单以在托管系统上发现目录文件的过程。

注意  

你的目录文件的标准命名约定将大大简化目录文件软件清单过程。在此示例中，-Contoso 已添加到所有目录文件名称。

 

1. 打开配置管理器控制台，然后选择“管理”工作区。

2. 导航到“概述”\“客户端设置”、右键单击“客户端设置”****，然后单击“创建自定义客户端设备设置”。

3. 为新策略命名，然后从“选择和随后配置客户端设备的自定义设置”****列表中选中“软件清单”复选框，如图 19 所示。

   

   图 19.选择自定义设置

4. 在导航窗格中，单击“软件清单”****，然后单击“设置类型”，如图 20 所示。

   

   图 20.设置软件清单

5. 在“配置客户端设置”对话框中，单击“开始”按钮以打开“清点文件属性对话框。

6. 在“名称”框中，键入“*Contoso.cat”****，然后单击“设置”。

   注意  

   “*Contoso.cat”是本示例中使用的命名约定。这应该模拟你用于目录文件的命名约定。

    

7. 在“路径属性”对话框中，选择“变量或路径名称”，然后在框中键入“C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}”，如图 21 所示。

   

   图 21.设置路径属性

8. 单击“确定”。

9. 现在你已创建客户端设置策略，请右键单击该新策略、单击“部署”****，然后选择你希望在其上清点目录文件的集合。

在下一次软件清单循环时，当目标客户端收到新的客户端设置策略时，你将可以在内置的 System Center Configuration Manager 报告或资源管理器中查看清点的文件。若要在资源管理器内查看客户端上的清点文件，请完成以下步骤：

1. 打开配置管理器控制台，然后选择“资源和合规性”工作区。

2. 导航到“概述”\“设备”，然后搜索你希望查看清点文件的设备。

3. 右键单击该计算机、指向“开始”，然后单击“资源管理器”****。

4. 在资源管理器中，导航到“软件”\“文件详细信息”以查看清点的目录文件。

注意  

如果此视图中未显示任何内容，则在资源管理器中导航到“软件”\“上次软件扫描”，以验证客户端最近是否完成了一次软件清单扫描。

 

代码完整性策略

代码完整性策略维持运行 Windows 10 的计算机确定应用程序是否值得信任并且可以运行的标准。有关代码完整性的概述，请参阅可配置的代码完整性部分。

如今的 IT 组织中的常用系统映像处理做法是建立一个“黄金”映像作为理想系统应有的外观的参考，然后使用该映像克隆其他公司资源。代码完整性策略遵循类似方法，从建立黄金电脑开始。与进行映像处理时一样，你可以根据模型、部门、应用程序集等拥有多台黄金电脑。尽管有关创建代码完整性策略的思维过程类似于映像处理，但应独立维护这些策略。根据应允许为谁安装和运行哪些内容来评估其他代码完整性策略的必要性。

注意  

每台计算机一次只能有“一个”代码完整性策略。无论你使用哪种方法部署此策略，建议将其重命名为 SIPolicy.p7b 并复制到 C:\Windows\System32\CodeIntegrity。当你创建代码完整性策略时，请记住这一点。

 

代码完整性策略可以选择与软件目录以及任何 IT 部门批准的应用程序保持一致。实现代码完整性策略的一种简单方法是，使用现有映像创建一个主代码完整性策略。执行此操作的方法是从每个映像创建一个代码完整性策略，然后合并这些策略。这样一来，如果应用程序基于不同映像安装在计算机上，将允许运行在所有这些映像上安装的内容。此外，你可以选择创建一个基本应用程序策略，然后根据计算机的角色或部门添加策略。组织可以选择如何创建、合并或服务以及管理他们的策略。

注意  

以下部分假设你将部署代码完整性策略作为 Device Guard 部署的一部分。此外，可配置的代码完整性在不启用 Device Guard 的情况下可用。

 

代码完整性策略规则

代码完整性策略由多个组件组成。可配置的两个主要组件分别称为策略规则和文件规则。代码完整性策略规则是代码完整性策略创建者可在策略上指定的选项。这些选项包括审核模式、UMCI 等的启用。你可以在新的或现有代码完整性策略中修改这些选项。文件规则是代码完整性策略扫描关联每个二进制文件信任的级别。例如，哈希级别将在生成的代码完整性策略内列出系统上每个已发现的哈希。这样一来，当二进制文件可供运行时，代码完整性服务将根据代码完整性策略中所发现的受信任哈希验证其哈希值。基于该结果，将允许或不允许二进制文件运行。

若要修改现有代码完整性策略的策略规则选项，请使用“Set-RuleOption”Windows PowerShell cmdlet。请注意以下有关如何使用此 cmdlet 在现有代码完整性策略上添加和删除规则选项的示例：

• 若要启用 UMCI，请通过运行以下命令将规则选项 0 添加到现有策略：

  Set-RuleOption -Option 0 -FilePath <Path to policy>

• 若要在现有代码完整性策略上禁用 UMCI，请通过运行以下命令删除规则选项 0：

  Set-RuleOption -Option 0 -FilePath <Path to policy> -Delete

你可以在代码完整性策略内设置多个规则选项。表 2 列出了每个规则及其高级意义。

表 2.代码完整性策略 - 策略规则选项

规则选项	描述
0 已启用：UMCI	代码完整性策略限制内核模式和用户模式二进制文件。默认情况下，仅限制内核模式二进制文件。启用此规则选项可验证用户模式可执行文件和脚本。
1 已启用：启动菜单保护	此选项当前不受支持。
2 必需：WHQL	默认情况下，允许执行未经 Windows 硬件质量实验室 (WHQL) 签名的旧驱动程序。启用此规则需要每个已执行的驱动程序都经过 WHQL 签名，并删除旧的驱动程序支持。接下来，每个新的 Windows 10 兼容驱动程序都必须经 WHQL 认证。
3 已启用：审核模式（默认）	在代码完整性策略之外启用二进制文件执行，但在 CodeIntegrity 事件日志中记录每次发生，该日志可用于在强制执行前更新现有策略。若要强制执行代码完整性策略，请删除此选项。
4 已禁用：外部测试签名	如果已启用，代码完整性策略将不会信任外部测试根签名的二进制文件。这将用于组织仅希望运行已发布的二进制文件而非外部测试版的方案。
5 已启用：固有默认策略	此选项当前不受支持。
6 已启用：未签名的系统完整性策略（默认）	允许策略保持未签名状态。当删除此选项时，该策略必须已签名并且已将 UpdatePolicySigners 添加到策略以支持将来的策略修改。
7 已允许：调试策略增强	此选项当前不受支持。
8 必需：EV 签名者	除了经 WHQL 签名，此规则还要求驱动程序必须已由具有扩展验证 (EV) 证书的合作伙伴提交。所有将来的 Windows 10 和更高版本驱动程序都将满足此要求。
9 已启用：高级启动选项菜单	默认情况下，为所有代码完整性策略禁用 F8 预启动菜单。设置此规则选项可使 F8 菜单显示给实际存在的用户。
10 已启用：在失败时启动审核	当代码完整性策略处于强制模式时使用。当驱动程序在启动期间失败时，代码完整性策略将置于审核模式下，以便 Windows 加载。管理员可以在 CodeIntegrity 事件日志中验证失败的原因。

 

文件规则级别允许管理员指定他们希望信任其应用程序的级别。此信任级别最低为每个二进制文件的哈希，最高为 PCA 证书。在以下两种情况下指定文件规则级别：当你从扫描创建新代码完整性策略时和当你从审核事件创建策略时。此外，若要结合在多个策略中找到的规则级别，你可以合并这些策略。当合并时，代码完整性策略将结合其文件规则。每个文件规则级别都有优点和缺点。使用表 3 来为你的可用管理资源和 Device Guard 部署方案选择相应的保护级别。

表 3.代码完整性策略 - 文件规则级别

规则级别	说明
哈希	为每个所发现的二进制文件指定个别哈希值。尽管此级别是特定的，它仍然可能导致额外的管理开销用于维护当前产品版本的哈希值。每次更新二进制文件时，哈希值都会更改，因此需要策略更新。
FileName	指定个别二进制文件名称。尽管在更新时会修改应用程序的哈希值，但通常不会修改文件名。与哈希级别相比，这提供更少的特定安全性，但在修改任何二进制文件时通常不需要策略更新。
SignedVersion	这将发布者规则与文件版本号组合起来。此选项允许来自特定发布者的任何内容（其文件版本等于或高于指定的版本号）运行。
Publisher	这是 PCA 证书和分支证书上的公用名 (CN) 的组合。在使用 PCA 证书对多个公司的应用程序（如 VeriSign）进行签名的情况下，此规则级别允许组织信任该 PCA 证书，但仅限于分支证书上包含其名称的公司（例如，用于设备驱动程序的 Intel）。此级别以较长的有效期信任证书，但仅限于在与受信任的分支证书组合时。
FilePublisher	这是发布者文件规则级别和 SignedVersion 规则级别的组合。信任任何来自指定版本或更新版本的受信任发布者的已签名文件。
LeafCertificate	在各个签名证书级别上添加受信任的签名者。使用此级别与单个哈希级别的优点是，产品的新版本将有不同的哈希值，但通常有相同的签名证书。通过使用此级别，不需要任何策略更新即可运行应用程序的新版本。但是，分支证书的有效期比 PCA 证书短，因此当这些证书到期时，更新代码完整性策略会产生额外的管理开销。
PcaCertificate	将所提供的证书链中的最高级别的证书添加到签名者。这通常是根证书下面的一个证书，因为扫描不会通过联机或检查本地根存储来验证位于已显示签名上方的任何内容。
RootCertificate	当前不支持。
WHQL	如果二进制文件已由 WHQL 验证并签名，则信任二进制文件。这主要用于内核二进制文件。
WHQLPublisher	这是 WHQL 和分支证书上的 CN 的组合，并且主要用于内核二进制文件。
WHQLFilePublisher	指定二进制文件已由 WHQL 验证和签名，其中发布者为特定发布者 (WHQLPublisher)，且该二进制文件为指定的版本或更新版本。这主要用于内核二进制文件。

 

注意  

当你使用“New-CIPolicy”cmdlet 创建代码完整性策略时，你可以通过包含“–Level”****参数来指定主要文件规则级别。对于所发现的基于主要文件规则条件无法信任的二进制文件，请使用“–Fallback”参数。例如，如果主要文件级别是 PCACertificate，但你希望也信任未签名的应用程序，则将哈希规则级别用作后备方案可添加没有签名证书的二进制文件的哈希值。

 

从黄金电脑创建代码完整性策略

从参考系统创建黄金代码完整性策略的过程很简单。本部分概述使用 Windows PowerShell 成功创建代码完整性策略所需的过程。首先，针对此示例，你必须启动要在创建过程期间使用的变量。你只需在命令中使用完整文件路径，而不是使用变量。接下来，你通过扫描系统中的已安装应用程序来创建代码完整性策略。完成创建后，该策略文件转换为二进制文件格式，以便 Windows 可以使用其内容。

注意  

在开始此过程前，请确保参考电脑不含有任何病毒或恶意软件。在创建此策略前，应验证每个已安装软件的部分是否值得信任。此外，在创建代码完整性策略前，请确保你希望扫描的任何软件都已安装在系统上。

 

若要创建代码完整性策略，请将以下每个命令都复制到提升的 Windows PowerShell 会话中，以便：

1. 初始化你将使用的变量：

   $CIPolicyPath=$env:userprofile+"\Desktop\"

   $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

   $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

2. 通过扫描系统中的已安装应用程序来创建新的代码完整性策略：

   New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt

   注意  

   通过指定 –UserPEs 参数，规则选项“0 已启用：UMCI”自动添加到代码完整性策略。如果你未指定此参数，请使用以下命令来启用 UMCI：

   Set-RuleOption -Option 0 -FilePath $InitialCIPolicy

    

   注意  

   你可以添加 –Fallback 参数，以捕获未使用 –Level 参数指定的主要文件规则级别发现的任何应用程序。有关文件规则级别选项的详细信息，请参阅代码完整性策略规则部分。

    

   注意  

   如果你希望指定代码完整性策略扫描来仅查看特定的驱动器，你可以使用 –ScanPath 参数执行此操作。如果没有此参数，如示例中所示，将扫描整个系统。

    

3. 将代码完整性策略转换为二进制文件格式：

   ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

完成这些步骤后，Device Guard 二进制文件 (DeviceGuardPolicy.bin) 和原始 .xml 文件 (IntialScan.xml) 将在桌面上可用。你可以将二进制文件版本用作代码完整性策略或对其进行签名以提高安全性。

注意  

Microsoft 建议你保留该策略的原始 .xml 文件，以供在你需要将代码完整性策略与其他策略合并或更新其规则选项时使用。或者，你将必须从新扫描创建新策略以进行维护。有关如何合并代码完整性策略的详细信息，请参阅合并代码完整性策略部分。

 

Microsoft 建议在强制执行每个代码完整性策略之前，在审核模式下运行这些策略。执行此操作可允许管理员发现任何策略问题，而不会收到错误消息对话框。有关如何审核代码完整性策略的信息，请参阅审核代码完整性策略部分。

审核代码完整性策略

当在审核模式下运行代码完整性策略时，它使管理员可以发现在初始策略扫描期间错过的所有应用程序，并标识在创建原始策略后安装和运行的所有新应用程序。当代码完整性策略在审核模式下运行时，任何运行且在强制执行该策略时被拒绝的二进制文件记录在 Applications and Services Logs\Microsoft\CodeIntegrity\Operational 事件日志中。验证这些记录的二进制文件时，可以轻松地将它们添加到新的代码完整性策略。当创建新的异常策略时，你可以将其与现有代码完整性策略合并。

注意  

在你开始此过程前，你需要创建一个代码完整性策略二进制文件。如果你尚未执行此操作，请参阅创建代码完整性策略部分，以获取创建代码完整性策略并将其转换为二进制文件格式的过程的分步演练。

 

若要使用本地策略审核代码完整性策略：

1. 将在从黄金电脑创建代码完整性策略部分中创建的 DeviceGuardPolicy.bin 文件复制到 C:\Windows\System32\CodeIntegrity。

2. 在要在审核模式下运行的系统上，通过运行“GPEdit.msc”打开本地组策略编辑器。

3. 导航到“计算机配置”\“管理模板”\“系统”\“Device Guard”，然后选择“部署代码完整性策略”****。通过使用文件路径 C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin 来启用此设置，如图 22 所示。

   注意  

   DeviceGuardPolicy.bin 不是必需的策略名称。此名称仅在从黄金电脑创建代码完整性策略部分中使用，因此也在此处使用。此外，此策略文件不需要复制到每个系统。或者，你可以将代码完整性策略复制到所有计算机帐户都有权访问的文件共享中。

    

   注意  

   你在此处选择的所有策略都将转换为 SIPolicy.p7b，前提是它已部署到个别计算机。

    

   

   图 22.部署代码完整性策略

   注意  

   你可能已经注意到 GPO 设置引用 .p7b 文件并且此策略使用 .bin 文件。无论你部署何种策略类型（.bin、.p7b 或 .p7），当将其放置到 Windows 10 计算机上时，它们都转换为 SIPolicy.p7b。Microsoft 建议你使代码完整性策略变得友好，并允许系统为你转换策略名称。通过执行此操作，它确保当在共享或任何其他中央存储库中查看策略时，可以轻松地区分这些策略。

    

4. 重新启动参考系统以使代码完整性策略生效。

5. 监视 CodeIntegrity 事件日志。 当处于审核模式下时，已部署代码完整性策略的所有异常都将记录在 Applications and Services Logs\Microsoft\CodeIntegrity\Operational 事件日子中，如图 23 所示。

   

   图 23.已部署代码完整性策略的异常

6. 验证任何代码完整性策略异常。

   在审核模式下运行代码完整性策略后，Microsoft 建议研究和验证每个记录的异常。除了发现哪个应用程序导致异常并确保它应添加到代码完整性策略外，请确保检查应使用哪个文件级别来信任每个应用程序。尽管哈希文件规则级别将捕获所有这些异常，但它可能不是信任所有异常的最佳方法。有关文件规则级别及其作用的信息，请参阅代码完整性策略规则部分。

7. 从审核事件创建代码完整性策略。

   有关如何从审核事件创建代码完整性策略的信息，请参阅从黄金电脑创建代码完整性策略部分。

注意  

测试策略的一个替代方法是将测试文件重命名为 SIPolicy.p7b，并将其放置在 C:\Windows\System32\CodeIntegrity 中，而不是使用本地计算机策略部署它。

 

创建审核代码完整性策略

当你在审核模式下运行代码完整性策略时，请验证任何异常，并确定是否需要将它们添加到要审核的代码完整性策略。像往常一样使用系统以确保记录所有使用异常。当你准备好从审核事件创建代码完整性策略时，请在提升的 Windows PowerShell 会话中完成以下步骤：

1. 初始化将使用的变量：

   $CIPolicyPath=$env:userprofile+"\Desktop\"

   $CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

2. 分析审核结果。

   从审核事件创建代码完整性策略之前，Microsoft 建议对每个异常进行分析，如审核代码完整性策略部分中的步骤 5 和步骤 6 所述。

3. 从记录的审核事件生成新的代码完整性策略：

   New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt

注意  

当你从审核事件创建策略时，你应仔细考虑你选择信任的文件规则级别。在此示例中，你使用哈希规则级别，此级别应用作最后的方法。

 

完成这些步骤后，Device Guard 审核策略 .xml 文件 (DeviceGuardAuditPolicy.xml) 将在桌面上可用。你现在可以使用此文件，通过合并两个策略来更新你在审核模式下运行的现有代码完整性策略。有关如何将此审核策略与现有代码完整性策略合并的说明，请参阅合并代码完整性策略部分。

注意  

你可能已经注意到，你未按照从黄金电脑创建代码完整性策略部分中所述生成此策略的二进制文件版本。这是因为从审核日志创建的代码完整性策略不是用于作为独立策略运行，而是用于更新现有代码完整性策略。

 

合并代码完整性策略

在你开发代码完整性策略时，你将偶尔需要合并两个策略。一个常见示例是当初始创建和审核代码完整性策略时。另一个示例是当你使用之前从黄金电脑创建的多个代码完整性策略创建单个主策略时。由于每台 Windows 10 计算机都只能有一个代码完整性策略，因此请务必正确维护这些策略。在此示例中，审核事件已保存到辅助代码完整性策略中，然后你将该策略与初始代码完整性策略合并。

注意  

以下示例使用你在从黄金电脑创建代码完整性策略和审核代码完整性策略部分中创建的代码完整性策略 .xml 文件。但是，对于你希望组合的两个代码完整性策略，你可以遵循此过程。

 

若要合并两个代码完整性策略，请在提升的 Windows PowerShell 会话中完成以下步骤：

1. 初始化将使用的变量：

   $CIPolicyPath=$env:userprofile+"\Desktop\"

   $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

   $AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

   $MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"

   $CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"

   注意  

   此部分中的变量专门用于查找桌面上名为 InitialScan.xml 的初始策略和名为 DeviceGuardAuditPolicy.xml 的审核代码完整性策略。如果你希望合并其他代码完整性策略，请相应地更新这些变量。

    

2. 合并两个策略以创建一个新的代码完整性策略：

   Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy

3. 将合并的代码完整性策略转换为二进制文件格式：

   ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin

现在你已创建了一个名为 NewDeviceGuardPolicy.bin 的新代码完整性策略，你可以手动或者使用组策略或 Microsoft 客户端管理解决方案将该策略部署到系统。有关如何使用组策略部署此新策略的信息，请参阅使用组策略部署和管理代码完整性策略部分。

强制执行代码完整性策略

在启用审核模式的情况下创建每个代码完整性策略。在成功在审核模式下部署和测试代码完整性策略并准备好在强制模式下测试该策略后，请在提升的 Windows PowerShell 会话中完成以下步骤：

注意  

应先在审核模式下测试每个代码完整性策略。有关如何审核代码完整性策略的信息，请参阅审核代码完整性策略部分。

 

1. 初始化将使用的变量：

   $CIPolicyPath=$env:userprofile+"\Desktop\"

   $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

   $EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"

   $CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"

   注意  

   本部分引用的初始代码完整性策略在从黄金电脑创建代码完整性策略部分中创建。如果你要使用不同的代码完整性策略，请更新“CIPolicyPath”和“InitialCIPolicy”****变量。

    

2. 复制初始文件以维护原始副本：

   cp $InitialCIPolicy $EnforcedCIPolicy

3. 删除审核模式规则选项：

   Set-RuleOption -Option 3 -FilePath $EnforcedCIPolicy -Delete

   注意  

   如果不存在“已启用审核模式”选项，则将隐式强制执行代码完整性策略，而不是添加“强制执行”****选项。

    

4. 将新的代码完整性策略转换为二进制文件格式：

   ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin

   注意  

   Microsoft 强烈建议你在第一次运行任何强制策略前，启用规则选项 9 和 10。如果已经在策略中存在，请不要删除它。如果代码完整性策略阻止内核模式驱动程序运行并为管理员提供预启动命令提示符，则这样做可以允许 Windows 启动。当为企业部署准备就绪时，你可以删除这些选项。

    

现在已强制执行此策略，你可以将其部署到测试计算机。将该策略重命名为 SIPolicy.p7b 并将其复制到 C:\Windows\System32\CodeIntegrity 以供测试，或按照使用组策略部署和管理代码完整性策略部分中的说明来通过组策略部署策略，或按照“使用 Microsoft 客户端管理解决方案部署和管理代码完整性策略”部分中的说明来通过客户端管理软件部署策略。

使用 SignTool.exe 对代码完整性策略进行签名

已签名的代码完整性策略可为组织提供 Windows 10 中可用的最高级别的恶意软件防护。除了其强制策略规则外，计算机上的用户或管理员无法修改或删除已签名的策略。这些策略旨在防止管理篡改和内核模式攻击访问。请记住，删除已签名的代码完整性策略比删除未签名的策略困难得多。在你对代码完整性策略进行签名和部署已签名的代码完整性策略前，Microsoft 建议你审核该策略以发现任何应允许运行但被阻止的应用程序。有关如何审核代码完整性策略的详细信息，请参阅审核代码完整性策略部分。

使用内部 CA 生成的证书或购买的代码签名证书来对代码完整性策略进行签名很简单。如果你当前没有以 .pfx 格式导出的代码签名证书（包含私钥、扩展和根证书），请参阅创建 Device Guard 代码签名证书来使用内部 CA 创建一个代码签名证书。在首次对代码完整性策略进行签名前，请确保启用规则选项 9 和 10 来使疑难解答选项对测试管理员可用。当经过验证并为企业部署准备就绪时，你可以删除这些选项。有关如何添加规则选项的信息，请参阅代码完整性策略规则部分。

注意  

代码完整性部署的最后一步是对代码完整性策略进行签名。删除已签名的代码完整性策略比删除未签名的策略困难得多。在将已签名的代码完整性策略部署到已部署的客户端计算机前，请确保测试它在计算机子集上的效果。

若要使用 SignTool.exe 对代码完整性策略进行签名，你需要以下组件：

• SignTool.exe，在 Windows SDK（Windows 7 或更高版本）中提供

• 你在从黄金电脑创建代码完整性策略部分中生成的代码完整性策略或已创建的其他代码完整性策略的二进制文件格式。

• 内部 CA 代码签名证书或购买的代码签名证书

 

如果你没有代码签名证书，请参阅创建 Device Guard 代码签名证书部分，以获取有关如何创建代码签名证书的说明。如果你使用备用证书或代码完整性策略，请确保使用相应的变量和证书更新以下步骤，以便命令可以正常运行。若要对现有代码完整性策略进行签名，请将以下每个命令都复制到提升的 Windows PowerShell 会话中：

1. 初始化将使用的变量：

   $CIPolicyPath=$env:userprofile+"\Desktop\" $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

   注意  

   此示例使用你在从黄金电脑创建代码完整性策略部分中创建的代码完整性策略。如果你要对另一个策略进行签名，请确保使用正确的信息更新“$CIPolicyPath”和“$CIPolicyBin”****变量。

    

2. 导入 .pfx 代码签名证书。 将用于对代码完整性策略进行签名的代码签名证书导入到将执行签名的计算机上的签名用户个人存储中。在此示例中，你使用在创建 Device Guard 代码签名证书部分中创建的证书。

3. 导出 .pfx 代码签名证书。 在导入代码签名证书后，将 .cer 版本导出到桌面。此版本将添加到策略，以便可以在以后更新它。

4. 导航到作为工作目录的桌面：

   cd $env:USERPROFILE\Desktop

5. 将更新签名者证书添加到代码完整性策略：

   Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update

   注意  

   <Path to exported .cer certificate> 应是你在步骤 3 中导出的证书的完整路径。

    

   注意  

   添加更新签名者对能够在将来修改或禁用此策略至关重要。有关如何禁用已签名的代码完整性策略的详细信息，请参阅在 Windows 内禁用已签名的代码完整性策略部分。

    

6. 删除未签名的策略规则选项：

   Set-RuleOption -Option 6 -FilePath $InitialCIPolicy -Delete

7. 将策略转换为二进制文件格式：

   ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

8. 使用 SignTool.exe 对代码完整性策略进行签名：

   <Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin

   注意  

   <Path to signtool.exe> 变量应是 SignTool.exe 实用工具的完整路径。“ContosoDGSigningCert”是将用于对代码完整性策略进行签名的证书的使用者名称。你应将此证书导入你用于对策略进行签名的计算机上的个人存储。

    

9. 验证已签名的文件。 完成后，这些命令应将一个名为 DeviceGuardPolicy.bin.p7 的已签名策略文件输出到桌面。你可以以你部署强制或非强制策略的相同方式部署此文件。有关如何部署代码完整性策略的信息，请参阅使用组策略部署和管理代码完整性策略部分。

禁用未签名的代码完整性策略

管理员有时可能希望禁用代码完整性策略。对于未签名的代码完整性策略，此过程很简单。根据代码完整性策略的部署方式，可以使用两种方法之一禁用未签名的策略。如果手动启用代码完整性策略并将其复制到代码完整性文件夹位置，只需删除该文件并重新启动计算机。以下位置可以包含正在执行的代码完整性策略：

• <EFI System Partition>\Microsoft\Boot\

• <OS Volume>\Windows\System32\CodeIntegrity\

如果使用组策略部署代码完整性策略，则当前要启用和部署策略的 GPO 必须设置为禁用状态。然后，将在下一次计算机重新启动时禁用代码完整性策略。

在 Windows 内禁用已签名的代码完整性策略

已签名的策略可保护 Windows 免受管理操纵以及已获取系统管理级访问权限的恶意软件的威胁。出于此原因，已签名的代码完整性策略有意比未签名的策略更难删除。它们在本质上可保护自己免受修改或删除，因此甚至连管理员都很难成功删除它们。如果手动启用已签名的代码完整性策略并将其复制到 CodeIntegrity 文件夹，若要删除该策略，你必须完成以下步骤：

注意  

出于参考目的，应从以下位置替换并删除已签名的代码完整性策略：

• <EFI System Partition>\Microsoft\Boot\

• <OS Volume>\Windows\System32\CodeIntegrity\

 

1. 将现有策略替换为启用了“6 已启用：未签名的系统完整性策略”规则选项的另一个已签名策略。

   注意  

   若要生效，必须使用之前添加到要替换的原始已签名策略的“UpdatePolicySigners”部分的证书来对此策略进行签名。

    

2. 重新启动客户端计算机。

3. 验证新的已签名策略是否存在于客户端上。

   注意  

   如果未在客户端上处理包含规则选项 6 的已签名策略，则添加未签名的策略可能导致启动失败。

    

4. 删除新策略。

5. 重新启动客户端计算机。

如果已使用组策略部署已签名的代码完整性策略，则你必须完成以下步骤：

1. 将 GPO 中的现有策略替换为启用了“6 已启用：未签名的系统完整性策略”规则选项的另一个已签名策略。

   注意  

   若要生效，必须使用之前添加到要替换的原始已签名策略的“UpdatePolicySigners”部分的证书来对此策略进行签名。

    

2. 重新启动客户端计算机。

3. 验证新的已签名策略是否存在于客户端上。

   注意  

   如果未在客户端上处理包含规则选项 6 的已签名策略，则添加未签名的策略可能导致启动失败。

    

4. 将 GPO 设置为禁用。

5. 删除新策略。

6. 重新启动客户端计算机。

在 BIOS 内禁用已签名的代码完整性策略

已签名的代码完整性策略有时可能会导致启动失败。由于代码完整性策略强制执行内核模式驱动程序，因此在强制执行和签名前在每个软件和硬件配置上彻底测试它们很重要。使用安全启动在预启动序列中验证已签名的代码完整性策略。当你在 BIOS 中禁用安全启动功能，然后从操作系统磁盘上的以下位置删除文件时，它允许系统启动到 Windows 中：

• <EFI System Partition>\Microsoft\Boot\

• <OS Volume>\Windows\System32\CodeIntegrity\

使用组策略部署和管理代码完整性策略

可以使用组策略轻松地部署和管理代码完整性策略。Windows Server 2016 中将提供 Device Guard 管理模板，可允许你简化 Device Guard 基于硬件的安全功能和代码完整性策略的部署。以下过程向你演练如何使用名为“Contoso GPO 测试”的 GPO 将名为“DeviceGuardPolicy.bin”****的代码完整性策略部署到名为 DG Enabled PCs 的测试 OU 的过程。

注意  

本演练需要你有之前创建的代码完整性策略，并拥有用于测试组策略部署的 Windows 10 客户端电脑。有关如何创建代码完整性策略的详细信息，请参阅从黄金电脑创建代码完整性策略部分。

 

注意  

已签名的代码完整性策略在部署时可能会导致启动失败。Microsoft 建议在企业部署前在每个硬件平台上对已签名的代码完整性策略进行彻底测试。

 

若要使用组策略部署和管理代码完整性策略：

1. 在安装了 RSAT 的客户端计算机的域控制器上，通过运行“GPMC.MSC”或在 Windows Search 中搜索“组策略管理”来打开 GPMC。

2. 创建新的 GPO：右键单击“启用 DG 的电脑”OU，然后单击“在此域中创建 GPO，然后将其链接到此处”****，如图 24 所示。

   注意  

   “启用 DG 的电脑”OU 只是你在此部分中创建的测试 GPO 所链接到的位置示例。可以使用任何 OU 名称。此外，安全组筛选是你在基于企业代码完整性部署方法部分中所讨论的策略考虑策略分区选项时的一个选项。

    

   

   图 24.创建 GPO

3. 将新的 GPO 命名为“Contoso GPO 测试”。 此示例使用 Contoso GPO 测试作为 GPO 的名称。你可以为此示例选择任何你偏好的名称。

4. 打开组策略管理编辑器：右键单击新 GPO，然后单击“编辑”****。

5. 在所选的 GPO 中，导航到“计算机配置”\“管理模板”\“系统”\“Device Guard”。然后，右键单击“部署代码完整性策略”，然后单击“编辑”****。

   

   图 25.编辑代码集成策略

6. 在“显示代码完整性策略”对话框中，选择“启用”****选项，然后指定代码完整性策略部署路径。

   在此策略设置中，你指定策略将在客户端计算机上存在的本地路径或客户端计算机将查看以检索该策略的最新版本的通用命名约定 (UNC)。此示例已将 DeviceGuardPolicy.bin 文件复制到测试计算机上，并且将启用此设置并使用文件路径 C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin，如图 26 所示。

   注意  

   DeviceGuardPolicy.bin 不是必需的策略名称：它仅在从黄金电脑创建代码完整性策略部分中使用，因此也在此处使用。此外，此策略文件不需要复制到每台计算机。或者，你可以将代码完整性策略复制到计算机帐户有权访问的文件共享中。你在此处选择的所有策略都将转换为 SIPolicy.p7b，前提是它已部署到个别客户端计算机。

    

   

   图 26.启用代码完整性策略

   注意  

   你可能已经注意到 GPO 设置引用 .p7b 文件，并且此示例针对策略使用 .bin 文件。无论你部署何种策略类型（.bin、.p7b 或 .p7），当将其放置到 Windows 10 客户端计算机上时，它们都转换为 SIPolicy.p7b。使你的代码完整性策略友好，并允许系统为你转换策略名称，以确保在共享或任何其他中央存储库中查看策略时可以轻松地区分这些策略。

    

7. 关闭组策略管理编辑器，然后重新启动 Windows 10 测试计算机。 重新启动客户端计算机将更新代码完整性策略。有关如何审核代码完整性策略的信息，请参阅审核代码完整性策略部分。

创建 Device Guard 代码签名证书

若要在内部对目录文件或代码完整性策略进行签名，你将需要公开颁发的代码签名证书或内部 CA。如果你已购买代码签名证书，则可以跳过这些步骤，并继续概述对目录文件和代码完整性策略进行签名的步骤的部分。如果你未购买证书，但有内部 CA，请完成以下步骤来创建代码签名证书：

1. 打开证书颁发机构 Microsoft 管理控制台 (MMC) 管理单元，然后选择你的颁发 CA。

2. 当连接时，右键单击“证书模板”，然后单击“管理”****以打开证书模板控制台。

   

   图 27.管理证书模板

3. 在导航窗格中，右键单击代码签名证书，然后单击“复制模板”。

4. 在“兼容性”****选项卡上，清除“显示生成的更改”复选框。从“证书颁发机构”****列表中选择“Windows Server 2012”，然后从“证书收件人”****列表中选择“Windows 8 / Windows Server 2012”。

5. 在“常规”选项卡上，指定“模板显示名称”和“模板名称”。 此示例使用“DG 目录签名证书”。

6. 在“请求处理”****选项卡上，选中“允许导出私钥”复选框。

7. 在“扩展”选项卡上，选中“基本约束”复选框，然后单击“编辑”。

8. 在“编辑基本约束扩展”对话框中，选中“启用扩展”****复选框，如图 28 所示。

   

   图 28.在新模板上启用约束

9. 如果证书管理器需要批准任何已颁发的证书，请在“颁发要求”选项卡上，选择“CA 证书管理器批准”****。

10. 在“使用者名称”选项卡上，选择“在请求中提供”****。

11. 在“安全”选项卡上，验证将用于请求证书的任何帐户是否都有权注册证书。

12. 单击“确定”****创建模板，然后关闭证书模板控制台。

创建此证书模板后，必须将其发布到 CA 已发布模板存储中。若要执行此操作，请完成以下步骤：

1. 在证书颁发机构 MMC 管理单元中，右键单击“证书模板”、指向“新建”****，然后单击“要颁发的证书模板”，如图 29 所示。

   将显示要颁发的可用模板列表，其中包括你刚刚创建的模板。

   

   图 29.选择要颁发的新证书模板

2. 选择 DG 目录签名证书，然后单击“确定”****。

现在该模板可供颁发，你必须从你用于创建和签名目录文件的 Windows 10 计算机请求一个模板。若要开始，打开 MMC，然后完成以下步骤：

1. 在 MMC 中，从“文件”菜单中，单击“添加/删除管理单元”。双击“证书”，然后选择“我的用户帐户”。

2. 在证书管理单元中，右键单击个人存储文件夹、指向“所有任务”，然后单击“请求新证书”****。

3. 单击“下一步”两次以转到证书选择列表。

4. 在“请求证书”****列表中，选择你新创建的代码签名证书，然后选择请求其他信息的蓝色文本，如图 30 所示。

   

   图 30.获取有关你的代码签名证书的详细信息

5. 在“证书属性”对话框中，对于“类型”，请选择“公用名”。对于“值”，请选择“ContosoDGSigningCert”，然后单击“添加”****。添加后，请单击“确定”。

6. 注册和完成。

注意  

如果证书管理器需要批准任何已颁发的证书，并且你已选择在模板上要求管理批准，则将需要在将其颁发给客户端前在 CA 中批准该请求。

 

此证书必须安装在将对目录文件和代码完整性策略进行签名的计算机上的用户个人存储中。如果签名将发生在你刚刚请求证书的计算机上，则不需要将该证书导出到 .pfx 文件，因为它已经存在于你的个人存储中。如果你要在另一台计算机上进行签名，你将需要使用必要的密钥和属性来导出 .pfx 证书。若要执行此操作，请完成以下步骤：

1. 右键单击该证书、指向“所有任务”，然后单击“导出”****。

2. 单击“下一步”，然后选择“是，导出私钥”****。

3. 选择默认设置，然后选择“导出所有扩展属性”。

4. 设置密码、选择导出路径，然后选择“DGCatSigningCert.pfx”****作为文件名。

当证书已导出时，将其导入到将在特定计算机（将进行签名）上对目录文件或代码完整性策略进行签名的用户的个人存储中。

相关主题

AppLocker 概述

代码完整性

凭据保护

Device Guard 认证和合规性

Windows 10 中与 Device Guard 的驱动程序兼容性

使用 Windows 10 的 Device Guard 打击恶意软件威胁