通过

控制 Windows 设备的运行状况

本文详细介绍了一个端到端解决方案，它通过强制实施、控制和报告 Windows 设备的运行状况来帮助保护高价值资产。

简介

对于“自带设备 (BYOD) 方案”，用户带来了商业上可用的设备来访问与工作相关的资源及其个人数据。 用户希望使用自己选择的设备访问组织的应用程序、数据和资源，不仅要从内部网络，而且从任何位置访问。 这种现象也称为 IT 消费化。

用户在从其设备访问公司应用程序和处理组织数据时，希望获得最佳的工作效率体验。 这意味着他们不能容忍每次访问应用程序或文件服务器时都提示他们输入其工作凭据。 从安全角度来看，这也意味着用户在非托管设备上操作公司凭据和企业数据。

随着 BYOD 的使用增加，访问公司服务、内部资源和云应用时，将有更多的非托管和潜在不正常的系统。

即使是受管理的设备也可能会遭到入侵并变得有害。 组织需要检测安全性何时遭到破坏，并尽早做出反应，以保护高价值资产。

随着Microsoft的推进，安全投资越来越注重安全防范以及检测和响应功能。

Windows 是端到端安全解决方案的一个重要组件，它不仅侧重于安全预防性防御的实现，而且还将设备运行状况证明功能添加到整体安全策略。

可靠的端到端安全解决方案说明

当今的计算威胁形势正以前所未有的速度增长。 犯罪攻击越来越复杂，毫无疑问，恶意软件现在面向所有行业的消费者和专业人士。

近年来，一种特定类别的威胁变得普遍：高级持续性威胁 (ACT) 。 APT 一词通常用于描述任何似乎持续针对单个组织的攻击。 事实上，这种类型的攻击通常涉及确定的攻击者，他们可以使用任何必要的方法或技术。

对于 BYOD 现象，维护不佳的设备表示所选目标。 对于攻击者来说，这是一种破坏安全网络外围、获取访问权限，然后窃取高价值资产的简单方法。

攻击者以个人为目标，不是因为他们是谁，而是因为他们为谁工作。 受感染的设备会将恶意软件引入组织，即使组织已经强化了网络外围或投资了防御态势。 防御策略不足以应对这些威胁。

不同的方法

有效的安全策略假定确定的攻击者将成功突破任何防御措施，而不是传统的注重防止入侵。 这意味着有必要将重点从预防性安全控制转移到检测和响应安全问题。 因此，风险管理策略的实施平衡了在预防、检测和响应方面的投资。

由于移动设备越来越多地用于访问公司信息，因此需要某种方法来评估设备安全性或运行状况。 本部分介绍如何预配设备运行状况评估，以便保护高价值资产免受运行不正常的设备。

必须信任用于访问公司资源的设备。 有效的端到端安全方法能够在授予对高价值资产的访问权限时评估设备运行状况并使用当前安全状态。

图 1.

可靠的设计需要建立用户标识，根据需要加强身份验证方法，并了解用户定期连接的网络位置等行为。 此外，新式方法必须能够发布敏感内容，前提是用户设备被确定为正常且安全。

下图显示了为从云中评估设备运行状况而构建的解决方案。 设备通过与云中标识提供者的连接对用户进行身份验证。 如果托管资产包含高度机密的信息，则标识提供者的条件访问引擎可以选择在授予访问权限之前验证移动设备的安全合规性。 用户的设备能够证明其运行状况状态，可随时或在移动设备管理 (MDM) 请求时发送。

图 2.

通过使用低级别硬件技术（例如统一可扩展固件接口 (UEFI) 安全启动），可以保护 Windows 设备免受低级别 rootkit 和引导工具包的防护。

安全启动是一个固件验证过程，可帮助防止 rootkit 攻击;它是 UEFI 规范的一部分。 UEFI 的意图是定义操作系统与新式硬件通信的标准方式，新式硬件比旧式软件中断驱动 BIOS 系统执行更快、更高效的输入/输出 (I/O) 功能。

设备运行状况证明模块可以将受受信任的平台模块 (TPM) 保护的测量启动数据传送到远程服务。 设备成功启动后，启动过程度量数据将发送到受信任的云服务 (运行状况证明服务，) 使用更安全且防篡改的信道。

远程运行状况证明服务对度量执行一系列检查。 它验证与安全相关的数据点，包括启动状态 (安全启动、调试模式等) ，以及管理 bitLocker、Device Guard 等) 安全 (组件的状态。 然后，它通过将运行状况加密的 Blob 发送回设备来传达设备的运行状况状态。

MDM 解决方案通常应用配置策略并将软件部署到设备。 MDM 定义安全基线，并通过定期检查了解设备的符合性级别，以查看安装了哪些软件以及强制执行了哪些配置，并确定设备的运行状况状态。

MDM 解决方案要求设备发送设备运行状况信息，并将运行状况加密的 Blob 转发到远程运行状况证明服务。 远程运行状况证明服务验证设备运行状况数据，检查 MDM 是否正在与同一设备通信，然后将设备运行状况报告发回 MDM 解决方案。

MDM 解决方案评估运行状况断言，并且根据属于组织的运行状况规则，可以确定设备是否正常运行。 如果设备正常运行且合规，则 MDM 会将该信息传递给标识提供者，以便可以调用组织的访问控制策略来授予访问权限。

然后，无论运行状况和其他条件元素指示什么，对内容的访问权限都会被授权为适当的信任级别。

根据托管资产的要求和敏感度，在处理访问请求时，可以将设备运行状况与用户标识信息组合在一起。 然后，将访问内容授权为适当的信任级别。 条件访问引擎的结构可以允许根据托管资产的敏感度进行更多的验证。 例如，如果请求访问高价值数据，可能需要通过在授予访问权限之前查询用户接听电话来建立进一步的安全身份验证。

Microsoft在 Windows 中的安全投资

在 Windows 中，投资有三大支柱：

  • 保护标识。 Microsoft是 FIDO 联盟的一部分，旨在通过在本地系统以及本地资源和云资源等服务上不使用密码进行身份验证来提供可互操作的安全身份验证方法。
  • 信息保护。 Microsoft正在进行投资，使组织能够更好地控制谁有权访问重要数据，以及他们可以对这些数据执行哪些操作。 借助 Windows，组织可以利用策略来指定哪些应用程序被视为公司应用程序，并且可以信任哪些应用程序可以访问安全数据。
  • 威胁抵抗。 Microsoft通过使用依赖于硬件的安全防御，帮助组织更好地保护企业资产免受恶意软件和攻击的威胁。

保护、控制和报告基于 Windows 的设备的安全状态

本部分概述端到端安全解决方案的不同部分，可帮助保护高价值资产和信息免受攻击者和恶意软件的侵害。

图 3.

数字 解决方案的一部分 描述
1 基于 Windows 的设备 首次打开基于 Windows 的设备时，将显示 (OOBE) 屏幕的现成体验。 在设置过程中，设备可以自动注册到Microsoft Entra ID 并在 MDM 中注册。
使用 TPM 的基于 Windows 的设备可以使用所有受支持的 Windows 版本提供的运行状况证明服务随时报告运行状况状态。
2 标识提供者 Microsoft Entra ID 包含组织租户的用户、已注册设备和已注册的应用程序。 一个设备始终属于一个用户，一个用户可以拥有多个设备。 设备表示为具有不同属性的对象，例如设备的符合性状态。 受信任的 MDM 可以更新符合性状态。
Microsoft Entra ID 不止是存储库。 Microsoft Entra ID 能够对用户和设备进行身份验证，还可以授权访问托管资源。 Microsoft Entra ID 具有条件访问控制引擎，该引擎在做出受信任的访问决策时使用用户的标识、设备的位置以及设备的符合性状态。
3 移动设备管理 Windows 提供 MDM 支持，使设备无需部署任何代理即可进行现装管理。
MDM 可以是 Microsoft Intune 或任何与 Windows 兼容的第三方 MDM 解决方案。
4 远程运行状况证明 运行状况证明服务是由Microsoft运营的受信任的云服务，它执行一系列运行状况检查，并向 MDM 报告设备上启用了哪些 Windows 安全功能。
安全验证包括启动状态 (WinPE、安全模式、调试/测试模式) 以及管理 BitLocker、Device Guard) 运行时操作安全性和完整性 (的组件。
5 企业托管资产 企业托管资产是要保护的资源。
例如，资产可以是 Office 365、其他云应用、Microsoft Entra ID 发布的本地 Web 资源，甚至是 VPN 访问。

基于 Windows 的设备、标识提供者、MDM 和远程运行状况证明的组合可创建一个可靠的端到端解决方案，用于验证访问高价值资产的设备运行状况和合规性。

保护设备和企业凭据免受威胁

本部分介绍 Windows 在安全防御方面提供的功能，以及可以度量和报告哪些控制措施。

基于 Windows 硬件的安全防御

最具攻击性的恶意软件会尝试尽早将自身插入启动过程，以便尽早控制操作系统，并防止保护机制和反恶意软件正常工作。 这种类型的恶意代码通常称为 rootkit 或 bootkit。 避免处理低级恶意软件的最佳方法是保护启动过程，以便从一开始就保护设备。 Windows 支持多层启动保护。 仅当安装了特定类型的硬件时，其中某些功能才可用。 有关详细信息，请参阅 硬件要求 部分。

图 4.

Windows 支持的功能可帮助防止在启动过程中加载复杂的低级恶意软件（如 rootkit 和 bootkit）：

  • 受信任的平台模块。 TPM) (受信任的平台模块是提供独特安全功能的硬件组件。

    Windows 使用 TPM 的安全特征来测量启动完整性序列 (，并基于此特征自动解锁受 BitLocker 保护的驱动器) 、保护凭据或运行状况证明。

    TPM 实现满足受信任的计算组 (TCG) 所述的规范的控件。 撰写本文时，TCG 生成的 TPM 规范有两个版本彼此不兼容：

    • 第一个 TPM 规范版本 1.2 由 TCG 于 2005 年 2 月发布，根据 ISO/IEC 11889 标准进行了标准化。
    • 最新的 TPM 规范（称为 TPM 2.0）于 2014 年 4 月发布，并已由 ISO/IEC 联合技术委员会 (JTC) 批准为 ISO/IEC 11889：2015。

    Windows 使用 TPM 作为运行状况证明的一部分进行加密计算，并保护 BitLocker、Windows Hello、虚拟智能卡和其他公钥证书的密钥。 有关详细信息，请参阅 Windows 中的 TPM 要求。

    Windows 识别 TCG 生成的版本 1.2 和 2.0 TPM 规范。 对于最新的新式安全功能，Windows 仅支持 TPM 2.0。

    TPM 2.0 对 TPM 1.2 上的功能进行了主要修订：

    • 更新加密强度以满足新式安全需求

      • 对 PCR 的 SHA-256 的支持
      • 支持 HMAC 命令

    • 支持政府需求的加密算法的灵活性

      • TPM 1.2 在可以支持的算法方面受到严格限制
      • TPM 2.0 可以支持任意算法，对 TCG 规范文档进行了细微更新

    • 实现之间的一致性

      • TPM 1.2 规范允许供应商在选择实现详细信息时大范围自由
      • TPM 2.0 标准化了大部分此行为

  • 安全启动。 可以将具有 UEFI 固件的设备配置为仅加载受信任的操作系统引导加载程序。 安全启动不需要 TPM。

    最基本的保护是安全启动功能，它是 UEFI 2.2+ 体系结构的标准部分。 在具有传统 BIOS 的电脑上，任何能够控制启动过程的人都可以使用备用 OS 加载程序启动，并可能获得对系统资源的访问权限。 启用安全启动后，只能使用使用 UEFI 安全启动数据库中存储的证书签名的 OS 加载程序启动。 当然，用于对 Windows OS 加载程序进行数字签名的Microsoft证书位于该存储区中，这允许 UEFI 在其安全策略中验证证书。 默认情况下，必须在通过 Windows 硬件兼容性计划认证的 Windows 的所有计算机上启用安全启动。

    安全启动是基于 UEFI 固件的功能，允许在启动时对关键启动文件和驱动程序进行签名和验证。 安全启动会在启动时检查 Windows 启动管理器、BCD 存储、Windows OS 加载程序文件和其他启动关键 DLL 的签名值，然后系统才能使用 OEM 在生成时定义的策略完全启动到可用操作系统。 安全启动可防止针对 Windows 平台的多种类型的基于启动的 rootkit、恶意软件和其他与安全相关的攻击。 无论是从本地硬盘、USB、PXE 或 DVD 启动，还是从整个 Windows 或 Windows 恢复环境启动， (RE) ，安全启动都保护操作系统启动过程。 安全启动通过验证关键启动组件的签名来保护 Windows 安装的启动环境，以确认恶意活动不会危及这些组件。 安全启动保护在 Windows 内核文件 (ntoskrnl.exe) 加载后结束。

    注意

    安全启动会保护平台，直到加载 Windows 内核。 然后，ELAM 等保护将接管。

  • 安全启动配置策略。 将安全启动功能扩展到关键的 Windows 配置。

    受保护的配置信息的示例包括保护禁用执行位 (NX 选项) ，或确保无法启用测试签名策略 (代码完整性) 。 此保护操作可确保在启动过程完成后可以信任计算机的二进制文件和配置。 安全启动配置策略使用 UEFI 策略执行此保护操作。 这些策略的签名的签名方式与操作系统二进制文件的签名方式相同，以便与安全启动一起使用。

    安全启动配置策略必须由私钥签名，该私钥对应于密钥交换密钥 (KEK) 列表中存储的公钥之一。 Microsoft证书颁发机构 (CA) 将出现在所有 Windows 认证安全启动系统的 KEK 列表中。 默认情况下，由Microsoft KEK 签名的策略应适用于所有安全启动系统。 在应用已签名的策略之前，BootMgr 必须针对 KEK 列表验证签名。 使用 Windows 时，默认的安全启动配置策略嵌入在 bootmgr 中。

    启动加载程序将先验证 Windows 内核的数字签名，然后再加载它。 Windows 内核反过来验证 Windows 启动过程的其他每个组件，包括启动驱动程序、启动文件和 ELAM 组件。 此步骤非常重要，它通过验证所有 Windows 启动组件是否完整且可受信任来保护启动过程的其余部分。

  • 开机初期启动的反恶意软件 (ELAM)。 ELAM 先测试所有驱动程序然后再进行加载，并且会阻止加载未经批准的驱动程序。

    传统的反恶意软件应用直到加载启动驱动程序后才会启动，这为伪装成驱动程序的 rootkit 提供了工作机会。 ELAM 是以前版本的 Windows 中引入的一种 Windows 机制，它允许反恶意软件在启动序列中尽早运行。 因此，反恶意软件组件是第一个运行和控制其他启动驱动程序的初始化的第三方组件，直到 Windows 操作系统正常运行。 当系统以完整的运行时环境 (网络访问、存储等) 启动时，将加载功能齐全的反恶意软件。

    ELAM 可以在所有非Microsoft启动驱动程序和应用程序之前加载Microsoft或非Microsoft反恶意软件驱动程序，从而继续由安全启动和受信任启动建立的信任链。 由于操作系统尚未启动，并且 Windows 需要尽快启动，因此 ELAM 有一个简单的任务：检查每个启动驱动程序，并确定它是否在受信任的驱动程序列表中。 如果它不受信任，则 Windows 将无法加载它。

    注意

    Windows Defender Microsoft默认包含在 Windows 中的反恶意软件支持 ELAM;它可以替换为与第三方反恶意软件兼容的解决方案。 Windows Defender ELAM 驱动程序的名称 WdBoot.sys。 Windows Defender 使用其 ELAM 驱动程序在下次重新启动时回滚对 Windows Defender 驱动程序所做的任何恶意更改。 这可以防止内核模式恶意软件在关闭或重新启动之前对 Windows Defender 的微型筛选器驱动程序进行持久更改。

    ELAM 签名的驱动程序在任何其他第三方驱动程序或应用程序之前加载，这允许反恶意软件通过尝试加载未签名或不受信任的代码来检测和阻止任何篡改启动过程的尝试。

    ELAM 驱动程序是具有小型策略数据库的小型驱动程序，其范围很窄，侧重于在系统启动时早期加载的驱动程序。 策略数据库存储在注册表配置单元中，该配置单元也以 TPM 进行度量，以记录 ELAM 驱动程序的操作参数。 ELAM 驱动程序必须由 Microsoft 签名，关联的证书必须包含补充 EKU (1.3.6.1.4.1.311.61.4.1) 。

  • 基于虚拟化的安全性 (Hyper-V + 安全内核) 。 基于虚拟化的安全性是一种新的强制安全边界，可用于保护 Windows 的关键部分。

    基于虚拟化的安全性将内核模式代码完整性或敏感公司域凭据等敏感代码与 Windows 操作系统的其余部分隔离开来。 有关详细信息，请参阅 基于虚拟化的安全性 部分。

  • 受虚拟机监控程序保护的代码完整性 (HVCI) 。 虚拟机监控程序保护的代码完整性是 Device Guard 的一项功能，可确保仅允许运行符合 Device Guard 代码完整性策略的驱动程序、可执行文件和 DLL。

    启用和配置后，Windows 可以启动基于 Hyper-V 虚拟化的安全服务。 HVCI 通过防止恶意软件在启动过程的早期或启动后运行，帮助保护系统核心 (内核) 、特权驱动程序和系统防御（如反恶意软件解决方案）。

    HVCI 使用基于虚拟化的安全性来隔离代码完整性，内核内存成为可执行的唯一方法是通过代码完整性验证。 这种对验证的依赖关系意味着内核内存页永远不可写，可执行文件 (W+X) 和可执行代码不能直接修改。

    注意

    使用基于虚拟化的安全性运行内核模式代码完整性的 Device Guard 设备必须具有兼容的驱动程序。 有关其他信息，请阅读 Windows 中的驱动程序与 Device Guard 的兼容性 博客文章。

    Device Guard 代码完整性功能使组织可以控制哪些代码可以运行到 Windows 内核中，以及哪些应用程序被批准在用户模式下运行。 可以使用策略对其进行配置。 Device Guard 代码完整性策略是Microsoft建议签名的二进制文件。 代码完整性策略的签名有助于防止具有管理员权限的恶意用户尝试修改或删除当前的代码完整性策略。

  • Credential Guard。 Credential Guard 使用基于硬件的凭据隔离来保护公司凭据。

    在 Windows 中，Credential Guard 旨在防止域公司凭据被盗并被恶意软件重用。 使用 Credential Guard，Windows 实现了体系结构更改，从根本上防止了当前形式的传递哈希 (PtH) 攻击。

    通过使用 Hyper-V 和新的基于虚拟化的安全功能来创建一个受保护的容器，其中受信任的代码和机密与 Windows 内核隔离，可以实现这种无攻击状态。 这一成就意味着，即使 Windows 内核遭到入侵，攻击者也无法读取和提取启动 PtH 攻击所需的数据。 Credential Guard 可防止这种未经授权的访问，因为存储机密的内存不再可从常规 OS 访问，即使在内核模式下也是如此 - 虚拟机监控程序控制谁可以访问内存。

  • 运行状况证明。 设备的固件记录启动过程，Windows 可以将它发送到可检查和评估设备运行状况的受信任服务器。

    Windows 会测量 UEFI 固件，并在启动过程中加载每个 Windows 和反恶意软件组件时进行。 此外，它们按顺序进行测量，而不是全部一次进行。 完成这些测量后，其值将进行数字签名并安全地存储在 TPM 中，除非系统已重置，否则无法更改。

    有关详细信息，请参阅 安全启动和测量启动：针对恶意软件强化早期启动组件。

    在每次后续启动期间，都会测量相同的组件，这样就可以将度量值与预期的基线进行比较。 为了获得更高的安全性，可以对 TPM 测量的值进行签名并将其传输到远程服务器，然后远程服务器可以执行比较。 此过程称为 远程设备运行状况证明，允许服务器验证 Windows 设备的运行状况状态。

    虽然安全启动是一种主动保护形式，但运行状况证明是启动保护的一种反应形式。 运行状况证明在 Windows 中已禁用，并由反恶意软件或 MDM 供应商启用。 与安全启动不同，运行状况证明不会停止启动过程，并在度量不起作用时进入修正。 但通过条件访问控制，运行状况证明有助于防止访问高价值资产。

基于虚拟化的安全功能

基于虚拟化的安全性为 Windows 提供了新的信任边界，并使用 Hyper-V 虚拟机监控程序技术来增强平台安全性。 基于虚拟化的安全性提供了一个安全执行环境，用于运行特定的 Windows 受信任代码 (trustlet) 并保护敏感数据。

基于虚拟化的安全性有助于防范受到入侵的内核或具有管理员权限的恶意用户。 基于虚拟化的安全性不会试图防范物理攻击者。

以下 Windows 服务受基于虚拟化的安全性保护：

  • Credential Guard (LSA 凭据隔离) ：防止通过读取和转储 lsass 内存的内容而发生的传递哈希攻击和企业凭据被盗
  • Device Guard (Hyper-V 代码完整性) ：Device Guard 使用 Windows 中新的基于虚拟化的安全性将代码完整性服务与 Windows 内核本身隔离开来，从而允许服务使用企业控制策略定义的签名来帮助确定什么是可信的。 实际上，代码完整性服务与受 Windows 虚拟机监控程序保护的容器中的内核一起运行。
  • 其他独立服务：例如，在 Windows Server 2016 上，vTPM 功能允许在服务器上) 加密虚拟机 (VM。

注意

基于虚拟化的安全性仅适用于企业版。 基于虚拟化的安全性要求设备具有 UEFI (2.3.1 或更高版本，) 启用了安全启动、x64 处理器且启用了虚拟化扩展和 SLAT。 IOMMU，TPM 2.0。 和对安全内存覆盖的支持是可选的，但建议这样做。

下面的架构是具有基于虚拟化的安全性的 Windows 的高级视图。

图 5.

Credential Guard

在 Windows 中，启用 Credential Guard 后，本地安全机构子系统服务 (lsass.exe) 在独立用户模式下运行敏感代码，以帮助保护数据免受可能在正常用户模式下运行的恶意软件的侵害。 此代码执行有助于确保受保护的数据不会被盗并在远程计算机上重复使用，从而缓解许多 PtH 样式的攻击。

Credential Guard 使用每启动密钥或持久密钥加密凭据，从而帮助保护凭据：

  • 每启动密钥 用于不需要持久性的任何内存中凭据。 此类凭据的一个示例是 (TGT) 会话密钥的票证授予票证。 每次进行身份验证时，都会与密钥分发中心 (KDC) 协商此密钥，并使用每启动密钥进行保护。
  • 永久性密钥或某些派生项用于帮助保护重新启动后存储和重新加载的项。 此类保护适用于长期存储，必须使用一致的密钥进行保护。 Credential Guard 由注册表项激活，然后使用 UEFI 变量启用。 此激活是为了防止远程修改配置。 使用 UEFI 变量意味着需要物理访问才能更改配置。 当 lsass.exe 检测到凭据隔离已启用时，它会生成 LsaIso.exe 作为一个独立进程，以确保它在隔离的用户模式下运行。 LsaIso.exe 的启动是在安全支持提供程序初始化之前执行的，这可确保在任何身份验证开始之前，安全模式支持例程已准备就绪。

Device Guard

Device Guard 是 Windows 企业版的一项功能，它允许组织锁定设备，以帮助防止其运行不受信任的软件。 在此配置中，允许运行的唯一应用程序是组织信任的应用程序。

执行代码的信任决策通过使用 Hyper-V 代码完整性来执行，该完整性在基于虚拟化的安全性中运行，这是一个与常规 Windows 一起运行的 Hyper-V 保护容器。

Hyper-V 代码完整性是一项功能，每次将驱动程序或系统文件加载到内存中时，都会验证其完整性。 代码完整性检测是否正在将未签名的驱动程序或系统文件加载到内核中，或者系统文件是否已由具有管理员权限的用户帐户运行的恶意软件修改。 在基于 x64 的 Windows 版本上，内核模式驱动程序必须进行数字签名。

注意

与激活 Device Guard 策略无关，Windows 驱动程序必须由Microsoft签名，更具体地说，由 WHQL (Windows 硬件质量实验室) 门户签名。 此外，从 2015 年 10 月开始，WHQL 门户将仅接受具有有效的扩展验证 (“EV”) 代码签名证书的驱动程序提交，包括内核和用户模式驱动程序提交。

借助 Device Guard，组织现在可以定义自己的代码完整性策略，以便在运行 Windows 企业版的 x64 系统上使用。 组织能够配置策略，以确定要运行的受信任内容。 其中包括驱动程序和系统文件，以及传统的桌面应用程序和脚本。 然后，系统会锁定为仅运行组织信任的应用程序。

Device Guard 是 Windows 企业版的一项内置功能，可防止执行不需要的代码和应用程序。 可以使用两个规则操作配置 Device Guard - 允许和拒绝：

  • 允许 将应用程序执行限制为允许的代码列表或受信任的发布者，并阻止其他所有内容。
  • 拒绝 通过阻止执行特定应用程序来完成允许受信任的发布者方法。

撰写本文时，根据Microsoft的最新研究，超过 90% 的恶意软件完全未签名。 因此，实现基本的 Device Guard 策略可以简单有效地帮助阻止恶意软件。 事实上，Device Guard 有可能走得更远，并且还有助于阻止已签名的恶意软件。

需要规划和配置 Device Guard 才能真正有效。 它不仅仅是启用或禁用的保护。 Device Guard 是硬件安全功能和软件安全功能的组合，在一起配置后，可以锁定计算机，以帮助确保系统尽可能安全且具有抵抗力。

Windows 中的 Device Guard 解决方案由三个不同的部分组成：

  • 第一部分是以前版本的 Windows 中引入 的基本硬件安全功能集 。 用于硬件加密操作的 TPM 和具有新式固件的 UEFI 以及安全启动，使你可以控制系统启动时正在运行的设备。
  • 硬件安全功能之后，还有代码完整性引擎。 在 Windows 中， 代码完整性现已完全可配置 ，现在驻留在独立用户模式中，这是受基于虚拟化的安全性保护的内存的一部分。
  • Device Guard 的最后一部分是 可管理性。 代码完整性配置通过特定的组策略对象、PowerShell cmdlet 和 MDM 配置服务提供程序 (CSP) 公开。

有关如何在企业中部署 Device Guard 的详细信息，请参阅 Device Guard 部署指南。

Device Guard 方案

如前所述，Device Guard 是锁定系统的强大方法。 Device Guard 不打算广泛使用，它可能并不总是适用，但存在一些高兴趣方案。

Device Guard 非常有用，适用于固定工作负载系统，例如收银机、展台计算机、安全管理工作站 (SAW) 或托管良好的桌面。 Device Guard 在具有定义完善的软件的系统上具有高度相关性，这些软件应运行且不会更改太频繁。 它还可以帮助保护信息工作者 (IW) ，而不仅仅是 SAW，只要他们需要运行的内容是已知的，并且应用程序集不会每天更改。

SAW 是旨在帮助显著降低恶意软件、网络钓鱼攻击、虚假网站和 PtH 攻击以及其他安全风险而构建的计算机。 尽管 SAW 不能被视为这些攻击的“灵丹妙药”安全解决方案，但这些类型的客户端作为分层深层防御安全方法的一部分非常有用。

为了保护高价值资产，SAW 用于与这些资产建立安全连接。

同样，在企业完全托管的工作站上，使用 Microsoft Configuration Manager、Intune 或任何第三方设备管理等分发工具来安装应用程序，则 Device Guard 适用。 在该类型的方案中，组织对普通用户正在运行的软件有一个很好的了解。

在通常允许用户自行安装软件的公司轻型管理工作站上使用 Device Guard 可能具有挑战性。 当组织提供极大的灵活性时，很难在强制模式下运行 Device Guard。 不过，Device Guard 可以在审核模式下运行，在这种情况下，事件日志包含违反 Device Guard 策略的任何二进制文件的记录。 在审核模式下使用 Device Guard 时，组织可以获得有关用户安装和运行的驱动程序和应用程序的丰富数据。

在从 Device Guard 中包含的保护中受益之前，必须使用 Microsoft 提供的工具创建代码完整性策略，但可以使用通用管理工具（如组策略）部署策略。 代码完整性策略是二进制编码的 XML 文档，其中包含 Windows 用户模式和内核模式的配置设置，以及 Windows 脚本主机的限制。 Device Guard 代码完整性策略限制可在设备上运行的代码。

注意

可以在 Windows 中登录 Device Guard 策略，这增加了针对管理用户更改或删除此策略的额外保护。

签名的 Device Guard 策略提供更强大的保护，防止恶意本地管理员试图击败 Device Guard。

签署策略后，策略的 GUID 存储在提供篡改保护的 UEFI 预 OS 安全变量中。 稍后更新 Device Guard 策略的唯一方法是在 UpdateSigner 部分中提供由同一签名者或从指定为 Device Guard 策略一部分的签名者签名的策略的新版本。

对应用程序进行签名的重要性

在具有 Device Guard 的计算机上，Microsoft建议从可以不受限制地运行未签名应用的世界迁移到仅允许在 Windows 上运行已签名和受信任的代码的世界。

借助 Windows，组织通过 Microsoft 应用商店基础结构向组织成员提供业务线 (LOB) 应用。 更具体地说，LOB 应用在公共Microsoft应用商店中的专用应用商店中可用。 Microsoft应用商店对通用 Windows 应用和经典 Windows 应用进行签名和分发。 从 Microsoft Store 下载的所有应用均已签名。

在当今的组织中，许多 LOB 应用程序都是未签名的。 由于各种原因（例如缺乏代码签名专业知识），代码签名通常被视为一个需要解决的难题。 即使代码签名是最佳做法，许多内部应用程序也不会签名。

Windows 包含的工具允许 IT 专业人员获取已打包的应用程序，并通过一个过程运行它们，以创建可与现有应用程序一起分发的更多签名。

为什么仍需要反恶意软件和设备管理解决方案？

尽管允许列表机制在确保只能运行受信任的应用程序方面是有效的，但它们无法防止受信任的 (但易受攻击的) 应用程序受到旨在利用已知漏洞的恶意内容的攻击。 Device Guard 无法通过利用漏洞来防止用户模式恶意代码运行。

漏洞是软件中的弱点，攻击者可能破坏设备的完整性、可用性或机密性。 一些最严重的漏洞允许攻击者在用户不知情的情况下运行恶意代码，从而利用受攻击的设备。

攻击者通常会分发特制的内容，试图利用用户模式软件（如 Web 浏览器 (及其插件) 、Java 虚拟机、PDF 阅读器或文档编辑器）中的已知漏洞。 截至目前，与托管它们的操作系统和内核模式驱动程序相比，90% 的已发现的漏洞会影响用户模式应用程序。

为了应对这些威胁，修补是最有效的单一控制措施，反恶意软件构成了互补的防御层。

大多数应用程序软件没有用于更新自身的工具，因此，即使软件供应商发布了修复漏洞的更新，用户也可能不知道更新是否可用或如何获取更新，因此仍然容易受到攻击。 组织仍需要管理设备和修补漏洞。

MDM 解决方案作为一种轻型设备管理技术正变得越来越普遍。 Windows 扩展了已可用于 MDM 的管理功能。 Microsoft已添加到 Windows 的一个关键功能是 MM 能够从托管和已注册的设备获取设备运行状况的强声明。

设备运行状况证明

设备运行状况证明使用 TPM 来提供用于启动设备的软件链的加密强且可验证的度量值。

对于基于 Windows 的设备，Microsoft引入了一个新的公共 API，允许 MDM 软件访问名为 Windows Health 证明服务的远程证明服务。 运行状况证明结果以及其他元素可用于允许或拒绝对网络、应用或服务的访问，具体取决于设备是否正常。

有关设备运行状况证明的详细信息，请参阅 检测基于 Windows 的设备运行不正常 部分。

Windows 版本和许可要求

下表列出了支持设备运行状况证明服务的 Windows 版本：

Windows 专业版 Windows 企业版 Windows 专业教育版/SE Windows 教育版
是 是 是 是

设备运行状况证明服务许可证权利由以下许可证授予：

Windows 专业版/专业教育版/SE Windows 企业版 E3 Windows 企业版 E5 Windows 教育版 A3 Windows 教育版 A5
是 是 是 是 是

有关 Windows 许可的详细信息，请参阅 Windows 许可概述。

硬件要求

下表详细介绍了基于虚拟化的安全服务和运行状况证明功能的硬件要求。 有关详细信息，请参阅 最低硬件要求。

硬件 目的
启用了安全启动的 UEFI 2.3.1 或更高版本固件 支持 UEFI 安全启动所必需的。 UEFI 安全启动可确保设备仅启动授权代码。 此外，必须遵循 Windows 系统硬件兼容性规范中“System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby”下的要求，支持启动完整性 (平台安全启动)
必须启用虚拟化扩展，例如 Intel VT-x、AMD-V 和 SLAT 支持基于虚拟化的安全性所必需的。 注意： 无需使用基于虚拟化的安全性即可启用 Device Guard。
X64 处理器 支持使用 Windows 虚拟机监控程序的基于虚拟化的安全性所必需的。 Hyper-V 仅在 x64 处理器 (上受支持，在 x86) 上不受支持。 可以启用直接内存访问 (DMA) 保护以提供额外的内存保护，但需要处理器包含 DMA 保护技术。
IOMMU（例如 Intel VT-d）AMD-Vi Windows 中对 IOMMU 的支持增强了系统对 DMA 攻击的复原能力。
受信任的平台模块 (TPM) 需要支持运行状况证明，并且对于基于虚拟化的安全性的其他关键保护是必需的。 支持 TPM 2.0。 从 Windows 10 版本 1607 开始添加了对 TPM 1.2 的支持， (RS1)

本部分介绍有关 Windows 中多个密切相关的控件的信息。 多层防御和深入方法有助于在启动序列期间消除低级别恶意软件。 基于虚拟化的安全性是一项基本的操作系统体系结构更改，可添加新的安全边界。 Device Guard 和 Credential Guard 分别有助于阻止不受信任的代码，并防止公司域凭据被盗和重复使用。 本部分还简要讨论了管理设备和修补漏洞的重要性。 所有这些技术都可用于强化和锁定设备，同时限制攻击者破坏设备的风险。

检测基于 Windows 的设备运行不正常

截至目前，许多组织仅在设备通过各种检查后才认为设备符合公司策略，这些检查显示操作系统处于正确状态、正确配置并启用了安全保护。 遗憾的是，对于当今的系统，这种形式的报告并不完全可靠，因为恶意软件可以欺骗有关系统运行状况的软件声明。 rootkit 或类似的低级别攻击可以向传统合规性工具报告错误正常状态。

使用 rootkit 的最大挑战是客户端无法检测到它们。 由于它们先于反恶意软件，并且具有系统级特权，因此他们可以完全伪装自己，同时继续访问系统资源。 因此，即使运行反恶意软件，受 rootkit 感染的传统计算机似乎也正常。

如前所述，Windows 的运行状况证明功能使用 TPM 硬件组件安全地记录每个启动相关组件（包括固件、Windows 内核甚至早期启动驱动程序）的度量值。 由于运行状况证明使用 TPM 的基于硬件的安全功能，因此所有启动测量组件的日志仍不受任何恶意软件的侵害。

设备证明受信任的启动状态后，可以证明它们未运行可能欺骗后续合规性检查的低级别恶意软件。 基于 TPM 的运行状况证明为包含高价值数据的资产提供可靠的信任定位点。

设备运行状况的概念是什么？

若要了解设备运行状况的概念，请务必了解 IT 专业人员为防止恶意软件泄露而采取的传统措施。 恶意软件控制技术高度侧重于防止安装和分发。

但是，使用传统的恶意软件防护技术（如反恶意软件或修补解决方案）给 IT 专业人员带来了一组新的问题：能够监视和控制访问组织资源的设备的合规性。

设备符合性的定义将因组织已安装的反恶意软件、设备配置设置、修补程序管理基线和其他安全要求而异。 但设备的运行状况是整个设备符合性策略的一部分。

设备的运行状况不是二进制的，取决于组织的安全实现。 运行状况证明服务使用可信硬件 TPM 向 MDM 提供信息，在设备启动期间启用哪些安全功能。

但运行状况证明仅提供信息，这就是为什么需要 MDM 解决方案来做出和执行决策的原因。

远程设备运行状况证明

在 Windows 中，运行状况证明是指在启动过程中生成的测量启动数据发送到由 Microsoft 运营的远程设备运行状况证明服务的功能。

此方法是最安全的方法，可供基于 Windows 的设备检测安全防御何时关闭。 在启动过程中，TCG 日志和 PCR 的值将发送到远程Microsoft云服务。 然后，运行状况证明服务会检查日志，以确定设备上发生了哪些更改。

像 MDM 这样的信赖方可以检查远程运行状况证明服务生成的报告。

注意

若要使用 Windows 的运行状况证明功能，设备必须配备离散或固件 TPM。 任何特定版本的 Windows 都没有限制。

Windows 通过允许应用程序访问基础运行状况证明配置服务提供程序 (CSP) 支持运行状况证明方案，以便应用程序可以请求运行状况证明令牌。 反恶意软件或 MDM 代理可以随时在本地检查启动序列的度量值。

远程设备运行状况证明与 MDM 相结合，提供了一种硬件根方法，用于报告当前安全状态和检测任何更改，而无需信任系统上运行的软件。

在设备上运行恶意代码的情况下，需要使用远程服务器。 如果设备上存在 rootkit，则反恶意软件不再可靠，并且其行为可能会被启动序列中早期运行的恶意代码劫持。 因此，使用安全启动和设备防护来控制在启动序列期间加载的代码非常重要。

反恶意软件可以搜索以确定启动序列是否包含任何恶意软件的迹象，例如 rootkit。 它还可以将 TCG 日志和 PCR 发送到远程运行状况证明服务器，以在度量组件和验证组件之间提供分隔。

运行状况证明在启动过程中记录各种 TPM 平台配置寄存器 (PCR) 和 TCG 日志中的度量值。

图 6.

启动配备 TPM 的设备时，将执行不同组件的测量。 这些组件包括固件、UEFI 驱动程序、CPU 微代码，以及类型为“启动启动”的所有 Windows 驱动程序。 原始度量值存储在 TPM PCR 寄存器中，而 TCG 日志中提供了所有事件的详细信息， (可执行路径、颁发机构认证等) 。

图 7.

运行状况证明过程的工作方式如下：

  1. 测量硬件启动组件。
  2. 测量操作系统启动组件。
  3. 如果启用了 Device Guard，则测量当前的 Device Guard 策略。
  4. 测量 Windows 内核。
  5. 防病毒软件作为第一个内核模式驱动程序启动。
  6. 测量启动驱动程序。
  7. MDM 服务器通过 MDM 代理使用运行状况证明 CSP 发出运行状况检查命令。
  8. 启动度量值由运行状况证明服务验证

注意

默认情况下，最后 100 个系统启动日志和所有相关的恢复日志都存档在 %SystemRoot%\logs\measuredboot 文件夹中。 保留的日志数可以在 HKLM\SYSTEM\CurrentControlSet\Services\TPM 键下使用注册表REG_DWORD值 PlatformLogRetention 进行设置。 值为 0 将关闭日志存档，值为 0xffffffff 将保留所有日志。

以下过程介绍了如何将运行状况启动度量值发送到运行状况证明服务：

  1. 客户端使用 TPM (基于 Windows 的设备，) 使用远程设备运行状况证明服务启动请求。 由于运行状况证明服务器应为Microsoft云服务，因此该 URI 已在客户端中预先预配。

  2. 然后，客户端发送 TCG 日志、AIK 签名数据 (PCR 值、启动计数器) 和 AIK 证书信息。

  3. 然后，远程设备健康证明服务：

    1. 验证 AIK 证书是否由已知且受信任的 CA 颁发，以及证书是否有效且未吊销。
    2. 验证 PCR 引用上的签名是否正确且与 TCG 日志值一致。
    3. 分析 TCG 日志中的属性。
    4. 颁发包含运行状况信息、AIK 信息和启动计数器信息的设备运行状况令牌。 运行状况令牌还包含有效的颁发时间。 设备运行状况令牌经过加密和签名，这意味着信息受保护，并且只能访问颁发运行状况证明服务。

  4. 客户端将运行状况加密的 Blob 存储在其本地存储中。 设备运行状况令牌包含设备运行状况状态、windows AIK) (设备 ID 以及启动计数器。

图 8.

设备运行状况证明组件

设备运行状况证明解决方案涉及 TPM、运行状况证明 CSP 和 Windows 运行状况证明服务等不同组件。 本节将介绍这些组件。

受信任的平台模块

本部分介绍如何 (包含系统配置数据) 、认可密钥 (EK) (充当 TPM) 的标识卡、保护密钥) 的 SRK (，以及可用于报告平台状态) 的 AIK (用于运行状况证明报告。

以简化的方式，TPM 是资源有限的被动组件。 它可以计算随机数、RSA 密钥、解密短数据、存储启动设备时采用的哈希。

TPM 合并到单个组件中：

  • RSA 2048 位密钥生成器
  • 随机数生成器
  • 用于存储 EK、SRK 和 AIK 密钥的非易失性内存
  • 用于加密、解密和签名的加密引擎
  • 用于存储 PCR 和 RSA 密钥的易失性内存

认可密钥

TPM 具有称为认可密钥的嵌入式唯一加密密钥。 TPM 认可密钥是一对非对称密钥， (RSA 大小为 2048 位) 。

认可密钥公钥用于发送安全敏感参数，例如，获取包含所有者密码定义哈希的 TPM 时。 创建辅助密钥（如 AIK）时使用 EK 私钥。

认可密钥充当 TPM 的标识卡。 有关详细信息，请参阅 了解 TPM 认可密钥。

认可密钥通常附带一两个数字证书：

  • 一个证书由 TPM 制造商生成，称为 认可证书。 认可证书用于证明 TPM 的真实性 (例如，它是由特定芯片制造商制造的真实 TPM，) 本地流程、应用程序或云服务。 认可证书是在制造过程中创建的，或者在首次通过与联机服务通信初始化 TPM 时创建。
  • 另一个证书由平台生成器生成，称为 平台证书 ，以指示特定 TPM 与特定设备集成。 对于使用 Intel 或 Qualcomm 生成的基于固件的 TPM 的某些设备，在 Windows 的 OOBE 期间初始化 TPM 时会创建认可证书。

注意

安全启动会保护平台，直到加载 Windows 内核。 然后，受信任的启动、Hyper-V 代码完整性和 ELAM 等保护将接管。 使用 Intel TPM 或 Qualcomm TPM 的设备从已创建芯片的制造商处获取签名证书，然后将签名证书存储在 TPM 存储中。 若要使操作成功，如果要筛选来自客户端设备的 Internet 访问，则必须授权以下 URL：

  • 对于 Intel 固件 TPM： https://ekop.intel.com/ekcertservice
  • 对于 Qualcomm 固件 TPM： https://ekcert.spserv.microsoft.com/

证明标识密钥

由于认可证书对于每个设备都是唯一的，并且不会更改，因此它的用法可能会引发隐私问题，因为理论上可以跟踪特定设备。 为了避免这种隐私问题，Windows 会基于认可证书颁发派生证明定位点。 此中间密钥（可证明认可密钥）是 AIK) (证明标识密钥，相应的证书称为 AIK 证书。 此 AIK 证书由Microsoft云服务颁发。

注意

在设备可以使用 TPM 证明函数报告其运行状况之前，必须将 AIK 证书与第三方服务（如 Microsoft Cloud CA 服务）一起预配。 预配后，可以使用 AIK 私钥来报告平台配置。 Windows 使用 AIK 创建基于平台日志状态 (签名，并在每次启动时) 一个单调计数器值。

AIK 是一个非对称 (公钥/私钥) 密钥对，用作 EK 的替代项，作为 TPM 的标识，以用于隐私目的。 AIK 的专用部分永远不会在 TPM 外部显示或使用，并且只能在 TPM 内用于一组有限的操作。 此外，它只能用于签名，并且只能用于有限的 TPM 定义的操作。

Windows 创建受 TPM 保护的 AIK（如果可用），这些 AIK 是 2048 位 RSA 签名密钥。 Microsoft托管名为 Microsoft Cloud CA 的云服务，以加密方式确定它正在与真正的 TPM 通信，并且 TPM 拥有提供的 AIK。 Microsoft云 CA 服务建立这些事实后，将向基于 Windows 的设备颁发 AIK 证书。

许多将升级到 Windows 10 的现有设备没有 TPM，或者 TPM 不会包含认可证书。 为了适应这些设备，Windows 10 允许在没有认可证书的情况下颁发 AIK 证书。 此类 AIK 证书不是由 Microsoft Cloud CA 颁发的。 这些证书不如在制造过程中烧入设备的认可证书那么可信，但它将为高级方案（如没有 TPM 的 Windows Hello 企业版）提供兼容性。

在颁发的 AIK 证书中，添加了一个特殊的 OID，用于证明在证明过程中使用了认可证书。 信赖方可以使用此信息来决定是拒绝使用没有认可证书的 AIK 证书进行证明的设备，还是接受它们。 另一种情况可能是不允许从未经认可证书支持的 AIK 证书证明的设备访问高价值资产。

存储根密钥

存储根密钥 (SRK) 也是 RSA (非对称密钥对，) 长度至少为 2048 位。 SRK 具有主要作用，用于保护 TPM 密钥，因此没有 TPM 就无法使用这些密钥。 获取 TPM 的所有权时会创建 SRK 密钥。

平台配置寄存器

TPM 包含一组寄存器，这些寄存器旨在提供启动的软件和状态的加密表示形式。 这些寄存器称为平台配置寄存器 (PCR) 。

启动序列的度量基于 PCR 和 TCG 日志。 若要建立静态信任根，当设备启动时，设备必须能够在执行之前测量固件代码。 在这种情况下，从启动执行核心信任根 (CRTM) ，计算固件的哈希，然后通过扩展寄存器 PCR[0] 来存储它，并将执行转移到固件。

启动平台时，PCR 设置为零，这是启动平台的固件的工作，用于测量启动链中的组件，并在 PCR 中记录度量值。 通常，启动组件采用要运行的下一个组件的哈希，并在 PCR 中记录度量值。 启动度量链的初始组件是隐式信任的。 此组件是 CRTM。 平台制造商必须有 CRTM 的安全更新过程，或者不允许更新它。 PCR 记录已测量的组件的累积哈希。

PCR 的值本身很难解释 (它只是一个哈希值) ，但平台通常会保留一个日志，其中包含所测量内容的详细信息，而 PCR 只是确保日志未被篡改。 这些日志称为 TCG 日志。 每次扩展寄存器 PCR 时，都会向 TCG 日志添加一个条目。 因此，在整个启动过程中，会在 TCG 日志中创建可执行代码和配置数据的跟踪。

TPM 预配

若要使基于 Windows 的设备的 TPM 可用，必须首先对其进行预配。 预配过程因 TPM 版本而异，但如果成功，则会导致 TPM 可用，并且所有者授权数据 (ownerAuth) 本地存储在注册表上的 TPM。

预配 TPM 后，Windows 将首先尝试通过在注册表中查找以下位置来确定 EK 和本地存储 的 ownerAuth 值： HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

在预配过程中，可能需要重启设备。

Get-TpmEndorsementKeyInfo PowerShell cmdlet 可与管理权限一起使用，以获取有关 TPM 的认可密钥和证书的信息。

如果 TPM 所有权未知但 EK 存在，则客户端库将预配 TPM，并在策略允许的情况下将生成的 ownerAuth 值存储在注册表中： HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub

在预配过程中，Windows 将使用 TPM 创建 AIK。 执行此操作时，生成的 AIK 公共部分存储在注册表中的以下位置： HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub

注意

若要预配 AIK 证书并筛选 Internet 访问，必须授权以下通配符 URL： https://\*.microsoftaik.azure.net

Windows 运行状况证明 CSP

Windows 包含配置服务提供程序 (CSP) 专用于与运行状况证明功能交互。 CSP 是一个组件，它插入 Windows MDM 客户端，并提供一个已发布的协议，用于 MDM 服务器如何配置设置和管理基于 Windows 的设备。 管理协议表示为树结构，可以指定为 URI，其中包含对 URI 执行的功能，例如“get”、“set”、“delete”等。

以下列表是 Windows 运行状况证明 CSP 执行的函数：

  • 收集用于验证设备运行状况的数据
  • 将数据转发到运行状况证明服务
  • 预配它从运行状况证明服务接收的运行状况证明证书
  • 根据请求，将从运行状况证明服务收到的运行状况证明证书 () 和相关运行时信息转发到 MDM 服务器进行验证

在运行状况证明会话期间，运行状况证明 CSP 使用安全信道将 TCG 日志和在启动期间测量的 PCR 值转发到运行状况证明服务。

当 MDM 服务器验证设备是否已向运行状况证明服务时，将向其提供一组有关该设备如何启动的语句和声明，并保证设备在证明其运行状况和 MDM 服务器验证它的时间之间不会重新启动。

Windows 运行状况证明服务

Windows 运行状况证明服务的作用实质上是评估一组运行状况数据 (TCG 日志和 PCR 值) ，根据可用的运行状况数据) 进行一系列检测 (，并生成加密的运行状况 Blob 或向 MDM 服务器生成报告。

注意

设备和 MDM 服务器都必须有权使用端口 443 上的 TCP 协议访问 has.spserv.microsoft.com ， (HTTPS) 。

检查 TPM 证明和关联的日志是否有效，需要执行几个步骤：

  1. 首先，服务器必须检查报表是否由 可信 AIK 签名。 可以通过检查 AIK 的公共部分是否在资产数据库中列出，或者是否检查了证书来完成此验证。
  2. 检查密钥后，应检查带符号证明 (引号结构) ，以查看它是否是 有效签名（超过 PCR 值）。
  3. 接下来，应检查日志，以确保它们与报告的 PCR 值匹配。
  4. 最后，MDM 解决方案应检查日志本身，以确定它们是否表示 已知或有效的安全配置。 例如，简单的检查可能是查看测量的早期 OS 组件是否已知良好、ELAM 驱动程序是否符合预期以及 ELAM 驱动程序策略文件是否是最新的。 如果所有这些检查都成功，则可以发出证明语句，该语句稍后可用于确定是否应向客户端授予对资源的访问权限。

运行状况证明服务向 MDM 解决方案提供有关设备运行状况的以下信息：

  • 安全启动启用
  • 启动和内核调试启用
  • BitLocker 启用
  • 已启用 VSM
  • 已签名或未签名的设备防护代码完整性策略度量
  • 已加载 ELAM
  • 安全模式启动、DEP 启用、测试签名启用
  • 设备 TPM 已使用受信任的认可证书进行预配

有关度量的完整性，请参阅 运行状况证明 CSP。

以下列表显示了一些可向基于 Windows 的设备报告回 MDM 的关键项：

  • PCR0 测量
  • 已启用安全启动
  • 安全启动 db 与预期匹配
  • 安全启动 dbx 是最新的
  • 安全启动策略 GUID 与预期匹配
  • 已启用 BitLocker
  • 已启用基于虚拟化的安全性
  • 已加载 ELAM
  • 代码完整性版本是最新的
  • 代码完整性策略哈希匹配预期

使用 MDM 和运行状况证明服务

若要使设备运行状况相关，MDM 解决方案会评估设备运行状况报告，并针对组织的设备运行状况要求进行配置。

使用 MDM 和运行状况证明服务的解决方案由三个主要部分组成：

  1. 启用了运行状况证明的设备。 此启用将在 MDM 提供程序注册过程中完成， (运行状况证明在默认情况下将禁用) 。

  2. 启用此服务并随后每次启动后，设备将向由 Microsoft 托管的运行状况证明服务发送运行状况度量值，并接收运行状况证明 Blob 作为回报。

  3. 在此周期后的任何时间点，MDM 服务器都可以从设备请求运行状况证明 Blob，并要求运行状况证明服务解密内容并验证是否已证明。

    图 9.

可以在基于 Windows 的设备、运行状况证明服务和 MDM 之间执行交互，如下所示：

  1. 客户端启动与 MDM 服务器的会话。 MDM 服务器的 URI 将是启动请求的客户端应用的一部分。 此时，MDM 服务器可以使用相应的 CSP URI 请求运行状况证明数据。

  2. MDM 服务器与请求一起指定 nonce。

  3. 然后，客户端发送 AIK 引号 nonce + 启动计数器和运行状况 blob 信息。 此运行状况 Blob 使用只有运行状况证明服务可以解密的运行状况证明服务公钥进行加密。

  4. MDM 服务器：

    1. 验证 nonce 是否与预期一样。
    2. 将带引号的数据、nonce 和加密的运行状况 Blob 传递到运行状况证明服务服务器。

  5. 运行状况证明服务：

    1. 解密运行状况 Blob。
    2. 使用运行状况 Blob 中的 AIK 验证引号中的启动计数器是否正确，并且是否与运行状况 Blob 中的值匹配。
    3. 验证引号中的 nonce 是否匹配，以及从 MDM 传递的引号。
    4. 由于启动计数器和 nonce 与运行状况 Blob 中的 AIK 一起引用，因此它还证明设备与为其生成运行状况 Blob 的设备相同。
    5. 将数据发送回 MDM 服务器，包括运行状况参数、新鲜度等。

注意

MDM 服务器 (信赖方) 从不自行执行引号或启动计数器验证。 它获取) 加密的带引号的数据和运行状况 blob (并将数据发送到运行状况证明服务进行验证。 这样，AIK 就永远不会对 MDM 可见，从而解决了隐私问题。

设置设备符合性要求是确保检测、跟踪不符合运行状况和符合性要求的已注册设备并由 MDM 解决方案强制实施操作的第一步。

尝试连接到资源的设备必须评估其运行状况，以便检测和报告不正常和不符合的设备。 为了完全高效，端到端安全解决方案必须对不正常的设备施加后果，例如拒绝访问高价值资产。 设备运行不正常的后果是条件访问控制的目的，下一部分将详细介绍这一目的。

在授予访问权限之前控制基于 Windows 的设备的安全性

在大多数情况下，当今的访问控制技术侧重于确保正确的人员能够访问正确的资源。 如果用户可以进行身份验证，则他们可以使用组织的 IT 人员和系统知之甚少的设备访问资源。 也许有一些检查，例如在授予对电子邮件的访问权限之前确保设备已加密，但如果设备感染了恶意软件，该怎么办？

远程设备运行状况证明过程使用测量的启动数据来验证设备的运行状况状态。 然后，设备的运行状况可用于 Intune 等 MDM 解决方案。

注意

有关 Intune 和 Windows 功能支持的最新信息，请参阅 Microsoft Intune 中的新增功能。

下图显示了运行状况证明服务应如何与Microsoft基于云的 Intune MDM 服务配合使用。

图 10.

然后，MDM 解决方案可以使用运行状况状态语句，并将其与客户端策略耦合，以便根据设备证明其无恶意软件、其反恶意软件系统正常运行且最新、防火墙正在运行以及设备修补程序状态合规的能力授予条件访问。

最后，可以通过拒绝访问无法证明其正常运行的终结点来保护资源。 需要访问组织资源的 BYOD 设备非常需要此功能。

Windows 中 MDM 的内置支持

Windows 具有作为操作系统的一部分随附的 MDM 客户端。 此 MDM 客户端使 MDM 服务器无需单独的代理即可管理基于 Windows 的设备。

非Microsoft MDM 服务器支持

非Microsoft MDM 服务器可以使用 MDM 协议管理 Windows。 内置管理客户端能够与支持 OMA-DM 协议的兼容服务器进行通信，以执行企业管理任务。 有关详细信息，请参阅 Microsoft Entra 与 MDM 的集成。

注意

MDM 服务器无需创建或下载客户端即可管理 Windows。 有关详细信息，请参阅 移动设备管理。

第三方 MDM 服务器将具有相同一致的注册第一方用户体验，这也为 Windows 用户提供了简单性。

由第三方 MDM 管理 Windows Defender

借助此管理基础结构，IT 专业人员可以使用支持 MDM 的产品（如 Intune）来管理基于 Windows 的设备上的运行状况证明、Device Guard 或 Windows Defender，包括未加入域的 BYOD。 IT 专业人员将能够管理和配置他们熟悉的所有操作和设置，方法是在下层操作系统上使用 Intune 和 Intune Endpoint Protection 进行自定义。 目前仅通过组策略管理已加入域的设备的管理员会发现，使用 MDM 可以轻松过渡到管理基于 Windows 的设备，因为许多设置和操作在两种机制之间共享。

有关如何使用 MDM 解决方案管理 Windows 安全和系统设置的详细信息，请参阅 Windows 设备的自定义 URI 设置。

条件访问控制

在大多数平台上，Microsoft Entra 设备注册在注册期间自动进行。 设备状态由 MDM 解决方案写入到 Microsoft Entra ID 中，然后由 Office 365 (或任何授权的 Windows 应用读取，这些应用在客户端下次尝试访问 Office 365 兼容工作负载时) 与 Microsoft Entra ID 交互。

如果未注册设备，用户将收到一条消息，其中包含有关如何注册 (也称为注册) 的说明。 如果设备不符合要求，用户将收到一条不同的消息，将他们重定向到 MDM Web 门户，可在其中获取有关合规性问题以及如何解决它的详细信息。

Microsoft Entra ID 对用户和设备进行身份验证， MDM 管理合规性和条件访问策略， 运行状况证明服务 以证明的方式报告设备运行状况。

图 11.

Office 365 条件访问控制

Microsoft Entra ID 强制实施条件访问策略来保护对 Office 365 服务的访问。 租户管理员可以创建条件访问策略，阻止不合规设备上的用户访问 Office 365 服务。 用户必须符合公司的设备策略，然后才能向服务授予访问权限。 或者，管理员还可以创建一个策略，要求用户只需注册其设备即可访问 Office 365 服务。 策略可以应用于组织的所有用户，或者限制为几个目标组，并随着时间的推移而增强以包括更多目标组。

当用户从受支持的设备平台请求访问 Office 365 服务时，Microsoft Entra 对用户从中启动请求的用户和设备进行身份验证;和 仅在用户符合为服务设置的策略时授予对服务的访问权限。 系统会向未注册其设备的用户提供修正说明，说明如何注册并使其符合要求以访问公司 Office 365 服务。

用户注册时，设备注册Microsoft Entra ID，并使用兼容的 MDM 解决方案（如 Intune）注册。

注意

Microsoft使用第三方 MDM ISV 来支持自动 MDM 注册和基于策略的访问检查。 Windows、Microsoft Entra ID 和 Microsoft Intune：由云提供支持的自动 MDM 注册！博客文章中介绍了使用 Microsoft Entra ID 和 Intune 启用自动 MDM 注册 的步骤。

用户成功注册设备后，设备将变得受信任。 Microsoft Entra ID 提供访问公司应用程序的单一登录，并强制实施条件访问策略，不仅在用户首次请求访问时，而且在用户每次请求续订访问权限时授予对服务的访问权限。

当登录凭据发生更改、设备丢失/被盗或请求续订时不符合合规性策略时，用户将被拒绝访问服务。

根据员工用来访问 Exchange Online 的电子邮件应用程序类型，建立对电子邮件的安全访问的路径可能略有不同。 但是，关键组件：Microsoft Entra ID、Office 365/Exchange Online 和 Intune 是相同的。 IT 体验和最终用户体验也相似。

图 12.

尝试访问 Office 365 的客户端将针对以下属性进行评估：

  • 设备是否由 MDM 管理？
  • 设备是否已使用 Microsoft Entra ID 注册？
  • 设备是否符合要求？

若要达到合规状态，基于 Windows 的设备需要：

  • 使用 MDM 解决方案注册。
  • 使用 Microsoft Entra ID 注册。
  • 符合 MDM 解决方案设置的设备策略。

注意

目前，有选择地对 iOS 和 Android 设备上的用户强制实施条件访问策略。 有关详细信息，请参阅 Microsoft Entra ID，Microsoft Intune 和 Windows - 使用云实现企业移动性现代化！ 博客文章。

云和本地应用条件访问控制

条件访问控制是内置于 Entra ID Microsoft 的强大策略评估引擎。 它为 IT 专业人员提供了一种在 Office 365 之外创建访问规则的简单方法，该规则评估用户的登录上下文，从而实时决定应允许他们访问哪些应用程序。

IT 专业人员可以为受Microsoft Entra ID 甚至本地应用程序保护的云 SaaS 应用程序配置条件访问控制策略。 Microsoft Entra ID 中的访问规则使用条件访问引擎检查由兼容的 MDM 解决方案（如 Intune）报告的设备运行状况和符合性状态，以确定是否允许访问。

有关条件访问的详细信息，请参阅 适用于 SaaS 应用的 Azure 条件访问预览版。

注意

条件访问控制是 EMS 中提供的Microsoft Entra ID P1 或 P2 功能。 如果没有 Microsoft Entra ID P1 或 P2 订阅，可以从 azure 站点Microsoft 获取试用版。

对于本地应用程序，有两个选项可根据设备的符合性状态启用条件访问控制：

  • 对于通过 Microsoft Entra 应用程序代理发布的本地应用程序，可以像配置云应用程序一样配置条件访问控制策略。 有关详细信息，请参阅 使用 Microsoft Entra 应用程序代理为远程用户发布本地应用。
  • 此外，Microsoft Entra Connect 会将设备符合性信息从 Microsoft Entra ID 同步到本地 AD。 Windows Server 2016 上的 ADFS 将基于设备的符合性状态支持条件访问控制。 IT 专业人员将在 ADFS 中配置条件访问控制策略，这些策略使用兼容的 MDM 解决方案报告的设备的符合性状态来保护本地应用程序。

图 13.

以下过程介绍了 Microsoft Entra 条件访问的工作原理：

  1. 用户已通过工作区访问/Azure AD 联接向 MDM 注册，该联接使用 Microsoft Entra ID 注册设备。
  2. 当设备启动或从休眠状态恢复时，将触发任务“Tpm-HASCertRetr”，以在后台请求运行状况证明 Blob。 设备将 TPM 启动度量值发送到运行状况证明服务。
  3. 运行状况证明服务会验证设备状态，并根据运行状况向设备发出加密的 Blob，以及有关失败检查的详细信息 (（如果有任何) ）。
  4. 用户登录，MDM 代理会联系 Intune/MDM 服务器。
  5. MDM 服务器会向下推送新策略（如果可用），并查询运行状况 Blob 状态和其他清单状态。
  6. 设备发送以前获取的运行状况证明 Blob，以及 Intune/MDM 服务器请求的其他状态清单的值。
  7. Intune/MDM 服务器将运行状况证明 Blob 发送到运行状况证明服务进行验证。
  8. 运行状况证明服务验证发送运行状况证明 Blob 的设备是否正常，并将此结果返回给 Intune/MDM 服务器。
  9. Intune/MDM 服务器根据设备的合规性和查询的清单/运行状况证明状态评估符合性。
  10. Intune/MDM 服务器根据 Entra ID 中的设备对象更新符合性状态Microsoft。
  11. 用户打开应用，尝试访问公司托管资产。
  12. Microsoft Entra ID 中由符合性声明限制的访问。
  13. 如果设备符合要求并且用户已获得授权，则会生成访问令牌。
  14. 用户可以访问公司托管资产。

有关Microsoft Entra 联接的详细信息，请参阅 Microsoft Entra ID & Windows：更好地协作工作或学校，白皮书。

条件访问控制是许多组织和 IT 专业人员可能不知道的一个主题，他们应该知道。 与条件访问引擎一起使用时，描述用户、设备、合规性和访问上下文的不同属性非常强大。 条件访问控制是帮助组织保护其环境的重要步骤。

要点和摘要

以下列表包含用于改善任何组织安全状况的高级密钥要点。 但是，本部分中提供的少数要点不应被解释为安全最佳做法的详尽列表。

  • 了解没有任何解决方案是 100% 安全的

    如果具有恶意意图的已确定攻击者获得对设备的物理访问权限，他们最终可能会突破其安全层并对其进行控制。

  • 将运行状况证明与 MDM 解决方案配合使用

    尝试连接到高价值资产的设备必须评估其运行状况，以便检测、报告和最终阻止不正常和不符合的设备。

  • 使用 Credential Guard

    Credential Guard 是一项功能，可极大地帮助保护公司域凭据免受传递哈希攻击。

  • 使用 Device Guard

    Device Guard 在安全性方面是一种真正的进步，也是帮助防范恶意软件的有效方法。 Windows 中的 Device Guard 功能阻止不受信任的应用 (未经组织) 授权的应用。

  • 对 Device Guard 策略进行签名

    签名的 Device Guard 策略有助于防止具有管理员权限的用户尝试破坏当前策略。 签署策略后，以后修改 Device Guard 的唯一方法是提供由同一签名者签名的策略的新版本，或者从指定为 Device Guard 策略一部分的签名者处提供策略的新版本。

  • 使用基于虚拟化的安全性

    如果内核模式代码完整性受基于虚拟化的安全性保护，即使漏洞允许未经授权的内核模式内存访问，仍会强制实施代码完整性规则。 请记住，使用基于虚拟化的安全性运行内核代码完整性的 Device Guard 设备必须具有兼容的驱动程序。

  • 开始部署具有审核模式的 Device Guard

    在审核模式下将 Device Guard 策略部署到目标计算机和设备。 监视代码完整性事件日志，指示如果在强制模式下配置 Device Guard，则会阻止程序或驱动程序。 调整 Device Guard 规则，直到达到高度置信度。 测试阶段完成后，可以将 Device Guard 策略切换到强制模式。

  • 部署 Device Guard 时生成独立引用计算机

    由于公司网络可能包含恶意软件，因此应开始配置与主公司网络隔离的引用环境。 之后，可以创建一个代码完整性策略，其中包含要在受保护设备上运行的受信任应用程序。

  • 在合理的时候使用 AppLocker

    尽管 AppLocker 不被视为新的 Device Guard 功能，但在某些方案中，它补充了 Device Guard 功能，例如能够拒绝特定用户或一组用户的特定通用 Windows 应用程序。

  • 锁定固件和配置

    安装 Windows 后，锁定固件启动选项访问权限。 此锁定可防止具有物理访问权限的用户修改 UEFI 设置、禁用安全启动或启动其他操作系统。 此外，为了防止管理员尝试禁用 Device Guard，请在当前 Device Guard 策略中添加一个规则，以拒绝和阻止 执行 C：\Windows\System32\SecConfig.efi 工具。

运行状况证明是 Windows 的一项关键功能，它包括客户端和云组件，用于根据用户及其设备的标识和符合公司治理策略来控制对高价值资产的访问。 组织可以选择检测和报告不正常的设备，或根据其需求配置运行状况强制规则。 运行状况证明提供端到端安全模型和集成点，供应商和软件开发人员可以使用这些模型和集成点来生成和集成自定义解决方案。