你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

从 Device Guard 签名服务 (DGSSv2) 迁移到受信任签名，以符合代码完整性策略

2024-10-15

Device Guard 签名服务将于 2024 年 12 月初弃用。所有计划继续使用该服务的现有 DGSSv2 客户都必须过渡到受信任签名。在 DGSSv2 和受信任签名之间，颁发代码签名证书和 CI 策略签名证书的根保持不变。由于受信任签名是一项 Azure 服务，因此现在需要有 Azure 租户 ID 和订阅 ID 才能访问签名，还需要有一个新的专用 EKU 用于签名。需要执行的步骤包括：

获取 Azure 帐户
设置对签名控制的访问权限（通过 Azure 门户和 Azure 标识进行控制）
选择定价层（受信任签名是付费服务 - 在此处了解有关定价的详细信息）
根据迁移方案执行相应步骤

本指南概述了迁移到受信任签名所需的步骤。请阅读本文档的全部内容，并注意必须仔细遵循这些步骤；错过任何一个步骤都可能导致 OS 映像损坏。

迁移方案

方案 1：已签名 CI 策略的迁移和部署
- 已有一个使用 DGSSv2 签名的 CI 策略，现在希望将其迁移到受信任签名。
方案 2：未签名到已签名 CI 策略的迁移和部署
- 已有一个未签名的 CI 策略，现在想要将其迁移到具有已签名 CI 策略的受信任签名。
方案 3：未签名到未签名 CI 策略的迁移和部署
- 已有一个未签名的 CI 策略，现在希望将其迁移到受信任签名，并将其保留为未签名的 CI 策略。
方案 4：没有现有的 CI 策略
- 当前环境中没有部署 CI 策略，并且想要迁移到受信任签名。

先决条件

我们强烈建议在继续迁移步骤之前先创建还原映像。
如果以前在环境中部署了 CI 策略（上述方案 #1 和 #2），则必须有权访问现有策略 xml 文件。
强烈建议先在一台计算机上执行以下步骤，然后再尝试部署到更广泛的环境中。

重要

如果不按照快速入门：设置受信任签名中的步骤创建受信任签名帐户、专用信任标识验证和专用信任 CI 策略签名证书配置文件，则无法进行迁移。

方案 1：已签名 CI 策略的迁移和部署

已签名 CI 策略的迁移仅适用于已在其环境中实施 DGSSv2 签名 CI 策略的客户。为确保顺利过渡和部署，请仔细执行以下两个步骤：

步骤 1：从单个计算机中删除已部署的已签名 CI 策略

注意

按照步骤 1 进行操作后，在部署新的策略之前，计算机不会受到 CI 的保护。新策略的部署将在步骤 2 中进行

请与系统管理员确认是否已部署 DGSSv2 签名策略，或者使用以下手动方式：
- 转到 C:\Windows\System32\CodeIntegrity，如果存在 SiPolicy.p7b 文件，表明已部署 CI 策略。
- 打开文件。如果显示证书，则表示 CI 策略已签名。
- 如果看到错误 “This file is invalid for use as the following: PKCS #7”，则 CI 策略未签名。
在当前 CI 策略 XML 文件的“规则”部分下，添加以下规则：
```
<Rule>
<Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
```
使用以下 PowerShell 将策略 xml 转换为.bin 文件：ConvertFrom-CIPolicy

示例：

ConvertFrom-CIPolicy -XmlFilePath <xmlCIPolicyFilePath> -BinaryFilePath <binaryCIPolicyFilePath>

按照对 CI 策略进行签名中的说明使用受信任签名对生成的策略 .bin 文件进行签名。
部署此签名策略 .bin 文件。有关详细信息，请参阅部署 Windows Defender 应用程序控制策略。
重启计算机并确认代码完整性事件 3099 显示策略已激活。
- 打开“事件查看器”（选择“开始”、键入“事件查看器”）→应用程序和服务日志→ Microsoft → Windows → CodeIntegrity →运行
- 按事件 ID 3099 进行筛选

注意

如果未看到事件 3099，请不要继续执行步骤 7。从步骤 1 重新开始，并确保 CI 策略文件格式正确且已成功签名。

格式正确：将 xml 与默认 CI 策略 xml 进行比较，以验证格式。
已成功签名：若要验证，请使用 SignTool；请参阅此链接。

运行 del SiPolicy.p7b 命令，从 C:\Windows\System32\CodeIntegrity 和 S:\EFI\Microsoft\Boot 两个文件夹中删除此 CI 策略。
1. 如果没有 S: 驱动器，请运行命令：mountvol.exe s: /s。
2. 如果计算机已有 S: 驱动器，请将 EFI 分区装载到其他驱动器，例如 X。
3. 如果计算机中没有 EFI 分区，请忽略删除 EFI 的步骤（如果命令 mountvol.exe 没有 /s 选项）。
删除完成后重启计算机。
再重启计算机两次，以确保正确删除 CI 策略，然后再继续或将此更改部署到其他计算机。

步骤 2：在同一台计算机上部署和测试新的 CI 策略

继续执行方案 2 中概述的步骤。

方案 2：未签名到已签名 CI 策略的迁移和部署

步骤 1：确定新的 EKU

由于受信任签名是一项新服务，其 EKU 不同于 DGSSv2。因此，需要将新的 EKU 添加到策略中。需要从受信任签名帐户获取 EKU，并将其添加到 CI 策略的 EKU 部分。可通过两种方法来执行此操作：
1. 使用对 CI 策略进行签名中的步骤运行命令 Get-AzCodeSigningCustomerEkuto 获取客户 EKU。
2. 在受信任签名帐户中，选择“证书配置文件”，然后选择专用信任证书配置文件。你将看到有关配置文件的信息，如以下屏幕截图所示。列出的“增强型密钥使用”就是客户 EKU。

现在你已拥有客户 EKU。接下来需要生成函数 EKU。为此，请将客户 EKU 传递到以下代码中。输出就是函数 EKU。

private string CalculateEkuValue(string CustomerEku) 
{ 
     var ekuOid = CryptoConfig.EncodeOID(CustomerEku); 
     var ekuBit = BitConverter.ToString(ekuOid).Replace("-", ""); 

     var ekuArray = ekuBit.ToCharArray(); 
     ekuArray[1] = '1'; 

     return new string(ekuArray); 
}

步骤 2：部署和测试新的 CI 策略

有了两个 EKU 后，就可以编辑 CI 策略了。如果已有现有 CI 策略，可以转到下一部分。若要创建新的策略，请转到：常见 WDAC 使用方案策略创建 - Windows 安全。
使用步骤 1 中的两个 EKU 值在策略的 EKU 部分中添加新的 EKU。

<EKU ID="ID_EKU_ACS" FriendlyName="ACS EKU -Customer EKU" Value="function EKU"/>

验证 CI 策略中是否存在/已添加这些签名者：

<Signer ID="ID_SIGNER_ACS_CODE" Name="Your Account Name Code Signing Certificate"> 

<CertRoot Value="28D3FAEF436A9D7644F01BEFFBF9E143AE6FB7A00B125F86CC9594A078980904B0597DF0F6BDD15E65E80F4D74E6D606" Type="TBS"/> 

<CertEKU ID="ID_EKU_ACS"/> 

</Signer> 

<Signer ID="ID_SIGNER_ACS_POLICY" Name="Your Account Name CI Policy Signing Certificate"> 

<CertRoot Type="TBS" Value="FC9C3E96720126881A6CEA067B5EA11ED0ABFC77835F720EDCFF4660C9A59669"/> 

<CertEKU ID="ID_EKU_ACS"/> 

</Signer>

帐户名代码签名证书是受信任签名帐户名。请注意，该字段在 CI 策略中未经验证，但建议在该字段中输入受信任签名帐户名。若要在 Azure 门户中查找帐户名，请导航到 Azure 门户，在顶部搜索栏中搜索“受信任签名”，然后选择搜索结果中出现的帐户。以下屏幕截图显示了帐户名并用红色标出。

使用以下命令将 .xml 转换为 .bin 策略文件：ConvertFrom-CIPolicy

示例：

ConvertFrom-CIPolicy -XmlFilePath <xmlCIPolicyFilePath> -BinaryFilePath <binaryCIPolicyFilePath>

如果要对此策略进行签名，请按照对 CI 策略进行签名中的说明使用受信任签名对策略进行签名。
部署此签名策略 .bin 文件；有关说明，请参阅此链接。
重启计算机并确认代码完整性事件 3099 已显示，这意味着新的 CI 策略已激活。

注意

如果未看到事件 3099，请不要继续执行步骤 8。从步骤 1 重新开始，并确保 CI 策略文件格式正确且已成功签名。
1.格式正确：将 xml 与默认 CI 策略 xml 进行比较，以验证格式。 2.已成功签名：若要验证，请使用 SignTool；请参阅此链接。 8.再次重启计算机，确保成功启动。 9.再重启计算机两次，以确保正确启用 CI 策略，然后再继续或将此更改部署到其他计算机。

步骤 3：执行测试，验证新策略不会中断任何预期方案

验证使用受信任签名进行签名的所有文件是否仍按预期方式运行。
使用受信任签名对目录文件进行签名，并确保它可以在测试计算机上使用受信任签名（新的）CI 策略运行。
1. 若要使用受信任签名对目录文件进行签名：
  1. 请参阅快速入门：设置受信任签名以设置专用信任证书配置文件。
  2. 请参阅设置签名集成以使用受信任签名以使用受信任签名服务中的专用信任对文件进行签名。
2. 若要使用受信任签名对 MSIX 包进行签名，请参阅有关如何使用 MSIX 打包工具或 SignTool 直接通过受信任签名对 MSIX 包进行签名的说明。
  1. 若要在 MSIX 打包工具中使用受信任签名进行签名，需要加入 MSIX 预览体验计划。
确认在此计算机上激活 CI 策略并且所有方案按预期运行后，请对环境中的其余所需计算机重复这些步骤。

方案 3：未签名到未签名 CI 策略的迁移和部署

需要按照方案 2 中的步骤找到并更新 EKU，将受信任签名 EKU 添加到现有 CI 策略。

方案 4：没有现有的 CI 策略

如果需要隔离，请按照方案 2 中概述的步骤部署新的 CI 策略。

了解 Windows Defender 应用程序控制 (WDAC) 策略规则和文件规则。
部署目录文件以支持 Windows Defender 应用程序控制 (Windows 10) - Windows 安全性。
Windows Defender 应用程序控制 (WDAC) 基本策略示例 (Windows 10) - Windows 安全性 | Microsoft Docs
使用多个 Windows Defender 应用程序控制策略 (Windows 10)
需要迁移方面的帮助：通过以下方式联系我们：
- 支持 + 故障排除（在 Azure 门户中）
- Microsoft Q&A（使用标记“Azure 受信任签名”）
- Stack Overflow（使用标记“受信任签名”）。