管理主机保护者服务
主机保护者服务 (HGS) 是受保护结构解决方案的核心组件。 它负责确保结构中的 Hyper-V 主机对托管商或企业已知并运行受信任的软件,同时负责管理用于启动受防护 VM 的密钥。 当租户决定信任由你托管他们的受防护 VM 时,他们就会信任你配置和管理主机保护者服务。 因此,在管理主机保护者服务时遵循最佳做法极其重要,以确保受保护结构的安全性、可用性和可靠性。 以下部分中的指导可帮助解决 HGS 管理员面临的最常见操作问题。
限制管理员对 HGS 的访问
由于 HGS 的安全敏感性,必须确保 HGS 的管理员是组织中高度受信任的成员,理想情况下,他们应该独立于结构资源的管理员。 此外,建议仅使用安全通信协议(例如基于 HTTPS 的 WinRM)从安全工作站管理 HGS。
职责分离
设置 HGS 时,可以选择仅为 HGS 创建隔离的 Active Directory 林,或者将 HGS 加入现有的受信任域。 此项决策以及你为组织中的管理员分配的角色决定了 HGS 的信任边界。 有权访问 HGS 的任何人 - 无论是以管理员身份直接访问,还是以管理员身份以其他某种能够影响 HGS 的方式间接访问(例如通过 Active Directory),都可以控制受保护的结构。 HGS 管理员选择授权哪些 Hyper-V 主机运行受防护的 VM 并管理启动受防护 VM 所需的证书。 有权访问 HGS 的攻击者或恶意管理员可以使用此权力授权遭入侵的主机运行受防护的 VM,并通过删除密钥材料发起拒绝服务攻击等恶意活动。
为了避免这种风险,强烈建议限制 HGS(包括 HGS 加入的域)和 Hyper-V 环境的管理员之间的重叠权限。 如果可以确保没有任何管理员能够访问这两个系统,则攻击者需要入侵 2 个人的 2 个不同帐户才能更改 HGS 策略。 这也意味着,两个 Active Directory 环境的域和企业管理员不应是同一个人,并且 HGS 不应使用与 Hyper-V 主机相同的 Active Directory 林。 任何可以授权自己访问其他资源的人都会带来安全风险。
使用 Just Enough Administration
HGS 内置了 Just Enough Administration (JEA) 角色,这些角色可帮助你以更安全的方式管理 HGS。 借助 JEA,可以将管理任务委托给非管理员用户,这意味着 HGS 策略管理者实际上不需要是整个计算机或域的管理员。 JEA 的工作原理是限制用户可以在 PowerShell 会话中运行的命令,并在幕后使用临时本地帐户(对于每个用户会话是唯一的)来运行通常需要提升权限的命令。
HGS 中预先配置了 2 个 JEA 角色:
- HGS 管理员,此角色允许用户管理所有 HGS 策略,包括授权新主机运行受防护的 VM。
- HGS 评审者,此角色仅允许用户评审现有的策略。 他们无法对 HGS 配置进行任何更改。
要使用 JEA,首先需要创建一个新的标准用户,并将其分配为 HGS 管理员组或 HGS 评审者组的成员。
如果使用 Install-HgsServer
为 HGS 设置了新林,这些组将分别命名为“servicenameAdministrators”和“servicenameReviewers”,其中 servicename 是 HGS 群集的网络名称。
如果你已将 HGS 加入现有域,则应参考在 Initialize-HgsServer
中指定的组名称。
为 HGS 管理员和评审者角色创建标准用户
$hgsServiceName = (Get-ClusterResource HgsClusterResource | Get-ClusterParameter DnsName).Value
$adminGroup = $hgsServiceName + "Administrators"
$reviewerGroup = $hgsServiceName + "Reviewers"
New-ADUser -Name 'hgsadmin01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Admin Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $adminGroup -Members 'hgsadmin01'
New-ADUser -Name 'hgsreviewer01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Reviewer Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $reviewerGroup -Members 'hgsreviewer01'
使用评审者角色审核策略
在与 HGS 建立了网络连接的远程计算机上的 PowerShell 中运行以下命令,以使用评审者凭据进入 JEA 会话。 请务必注意,由于评审者帐户只是一个标准用户,因此无法将其用于普通的 Windows PowerShell 远程处理、通过远程桌面访问 HGS 等操作。
Enter-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsreviewer01' -ConfigurationName 'microsoft.windows.hgs'
然后,可以使用 Get-Command
检查会话中允许哪些命令,并运行任何允许的命令来审核配置。
在以下示例中,我们将检查在 HGS 上启用了哪些策略。
Get-Command
Get-HgsAttestationPolicy
完成 JEA 会话后,键入命令 Exit-PSSession
或其别名 exit
。
使用管理员角色将新策略添加到 HGS
要实际更改某个策略,需要使用属于“hgsAdministrators”组的身份连接到 JEA 终结点。 以下示例演示如何将新的代码完整性策略复制到 HGS,并使用 JEA 注册该策略。 语法可能与你平时使用的不同。 这是为了适应 JEA 中的某些限制,例如无法访问整个文件系统。
$cipolicy = Get-Item "C:\temp\cipolicy.p7b"
$session = New-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsadmin01' -ConfigurationName 'microsoft.windows.hgs'
Copy-Item -Path $cipolicy -Destination 'User:' -ToSession $session
# Now that the file is copied, we enter the interactive session to register it with HGS
Enter-PSSession -Session $session
Add-HgsAttestationCiPolicy -Name 'New CI Policy via JEA' -Path 'User:\cipolicy.p7b'
# Confirm it was added successfully
Get-HgsAttestationPolicy -PolicyType CiPolicy
# Finally, remove the PSSession since it is no longer needed
Exit-PSSession
Remove-PSSession -Session $session
监视 HGS
事件源和转发
来自 HGS 的事件显示在 2 个源下的 Windows 事件日志中:
- HostGuardianService-Attestation
- HostGuardianService-KeyProtection
可以通过打开事件查看器并导航到 Microsoft-Windows-HostGuardianService-Attestation 和 Microsoft-Windows-HostGuardianService-KeyProtection 来查看这些事件。
在大型环境中,通常最好是将事件转发到中心 Windows 事件收集器,以方便分析事件。 有关详细信息,请查看 Windows 事件转发文档。
使用 System Center Operations Manager
你还可以使用 System Center 2016 - Operations Manager 来监视 HGS 和受保护的主机。 受保护的结构管理包中提供了事件监视器用于检查可能导致数据中心停机的常见错误配置,包括通不过证明的主机和报告错误的 HGS 服务器。
要开始使用,请安装并配置 SCOM 2016,并下载受保护的结构管理包。 随附的管理包指南介绍了如何配置该管理包和了解其监视范围。
备份和还原 HGS
灾难恢复规划
在草拟灾难恢复计划时,必须考虑受保护结构中主机保护者服务的独特要求。 如果丢失部分或全部 HGS 节点,你可能会立即遇到可用性问题,这会导致用户无法启动其受防护的 VM。 如果丢失了整个 HGS 群集,需要使用 HGS 配置的现有完整备份来还原 HGS 群集和恢复正常操作。 本部分介绍针对这种情况做好准备所要执行的步骤。
首先,必须了解需要备份 HGS 的哪些方面。 HGS 将保留几条信息,以帮助确定哪些主机有权运行受防护的 VM。 这包括:
- 包含受信任主机的组的 Active Directory 安全标识符(使用 Active Directory 证明时);
- 环境中每个主机的唯一 TPM 标识符;
- 主机的每个唯一配置的 TPM 策略;
- 用于确定允许在主机上运行哪些软件的代码完整性策略。
获取这些证明项目需要与宿主结构的管理员协调,在发生灾难后,可能很难再次获取这些信息。
此外,HGS 需要访问 2 个或更多个证书,这些证书用于对启动受防护 VM 所需的信息(密钥保护程序)进行加密和签名。 这些证书是已知的(由受防护 VM 的所有者用来授权结构运行他们的 VM),在发生灾难后,必须还原这些证书才能获得无缝的恢复体验。 如果在发生灾难后不使用相同的证书还原 HGS,则需要更新每个 VM 以授权新密钥解密其信息。 出于安全原因,只有 VM 所有者可以更新 VM 配置以便为这些新密钥授权,这意味着,如果在发生灾难后不还原密钥,每个 VM 所有者必须采取措施才能使他们的 VM 再次运行。
为最坏的情况做好准备
要为 HGS 完全丢失做好准备,必须执行 2 个步骤:
- 备份 HGS 证明策略
- 备份 HGS 密钥
备份 HGS 部分提供了有关如何执行这两个步骤的指导。
此外,建议(但不强制要求)备份有权在 Active Directory 域中或 Active Directory 本身中管理 HGS 的用户列表。
应定期创建备份,确保信息最新并以安全方式存储,以避免其遭到篡改或盗窃。
不建议备份或尝试还原 HGS 节点的整个系统映像。 如果丢失了整个群集,最佳做法是设置一个全新的 HGS 节点,并仅还原 HGS 状态而不是整个服务器操作系统。
在丢失一个节点后进行恢复
如果丢失了 HGS 群集中的一个或多个节点(但不是所有节点),只需按照部署指南中的指导将节点添加到群集即可。 证明策略会自动同步,以附有密码的 PFX 文件形式提供给 HGS 的任何证书也是如此。 对于使用指纹添加到 HGS 的证书(通常是不可导出且由硬件支持的证书),需要确保每个新节点可以访问每个证书的私钥。
在丢失整个群集后进行恢复
如果整个 HGS 群集出现故障并且你无法使其恢复联机,则需要从备份还原 HGS。 从备份还原 HGS 需要首先根据部署指南中的指导设置新的 HGS 群集。 强烈建议(但不强制要求)在设置恢复 HGS 环境时使用相同的群集名称,以帮助从主机进行名称解析。 使用相同的名称可以避免使用新的证明和密钥保护 URL 来重新配置主机。 如果已将对象还原到支持 HGS 的 Active Directory 域,建议在初始化 HGS 服务器之前删除代表 HGS 群集、计算机、服务帐户和 JEA 组的对象。
设置第一个 HGS 节点(例如,安装并初始化该节点)后,可以按照从备份还原 HGS 中的过程来还原证明策略以及密钥保护证书的公钥部分。 需要根据证书提供者的指导手动还原证书的私钥(例如,在 Windows 中导入证书,或配置对 HSM 支持的证书的访问)。 设置第一个节点后,可以继续在群集中安装更多节点,直到达到所需的容量和复原能力。
备份 HGS
HGS 管理员应负责定期备份 HGS。 完整备份包含必须妥善保护的敏感密钥材料。 如果不受信任的实体获得了这些密钥的访问权限,他们可能会使用这些材料来设置恶意 HGS 环境,以达到入侵受防护 VM 的目的。
备份证明策略。要备份 HGS 证明策略,请在任何正在运行的 HGS 服务器节点上运行以下命令。 系统将提示你提供密码。 此密码用于加密任何通过 PFX 文件(而不是证书指纹)添加到 HGS 的证书。
Export-HgsServerState -Path C:\temp\HGSBackup.xml
注意
如果使用管理员信任的证明,则必须单独备份由 HGS 用来授权受保护主机的安全组中的成员身份。 HGS 只备份安全组的 SID,而不会备份其中的成员身份。 如果这些组在灾难期间丢失,你需要重新创建这些组,并再次将每个受保护的主机添加到其中。
备份证书
Export-HgsServerState
命令在运行时将备份添加到 HGS 的任何基于 PFX 的证书。
如果你使用指纹将证书(通常是不可导出且由硬件支持的证书)添加到了 HGS,则需要手动备份证书的私钥。
要确定哪些证书已注册到 HGS 并且需要手动备份,请在任何正在运行的 HGS 服务器节点上运行以下 PowerShell 命令。
Get-HgsKeyProtectionCertificate | Where-Object { $_.CertificateData.GetType().Name -eq 'CertificateReference' } | Format-Table Thumbprint, @{ Label = 'Subject'; Expression = { $_.CertificateData.Certificate.Subject } }
对于列出的每个证书,需要手动备份私钥。 如果使用不可导出的基于软件的证书,你应该联系证书颁发机构,以确保他们能够提供你的证书的备份,并且/或者可以按需重新颁发证书。 对于在硬件安全模块中创建和存储的证书,请查阅设备文档以获取有关灾难恢复计划的指导。
应该将证书备份与证明策略备份一起存储在安全位置,以便可以一起还原两者。
要备份的其他配置
备份的 HGS 服务器状态不包括 HGS 群集的名称、来自 Active Directory 的任何信息,或用于保护与 HGS API 的通信的任何 SSL 证书。 这些设置对于确保一致性非常重要,但对于在发生灾难后让 HGS 群集恢复联机并不重要。
要捕获 HGS 服务的名称,请运行 Get-HgsServer
并记下证明和密钥保护 URL 中的服务名称。
例如,如果证明 URL 为“https://hgs.contoso.com/Attestation”,则“hgs”是 HGS 服务名称。
应该像管理任何其他 Active Directory 域一样管理 HGS 使用的 Active Directory 域。 在灾难后还原 HGS 时,不一定需要重新创建当前域中存在的确切对象。 但是,如果你要备份 Active Directory,并保留有权管理系统的 JEA 用户列表,以及由管理员信任的证明用来授权受保护主机的任何安全组的成员身份,这样做会使恢复变得更容易。
要识别针对 HGS 配置的 SSL 证书的指纹,请在 PowerShell 中运行以下命令。 然后,可以根据证书提供者的说明备份这些 SSL 证书。
Get-WebBinding -Protocol https | Select-Object certificateHash
从备份还原 HGS
以下步骤说明如何从备份还原 HGS 设置。 这些步骤与你尝试撤消对已运行的 HGS 实例所做的更改,以及在完全丢失前一个 HGS 群集之后创建全新群集这两种情况相关。
设置替换 HGS 群集
在还原 HGS 之前,需要准备好一个已初始化的、可将配置还原到的 HGS 群集。 如果你只是将意外删除的设置导入现有(正在运行的)群集,则可以跳过此步骤。 如果你要在完全丢失 HGS 之后进行恢复,需要按照部署指南中的指导安装并初始化至少一个 HGS 节点。
具体而言,需要:
- 设置 HGS 域或将 HGS 加入现有域
- 使用现有密钥或一组临时密钥初始化 HGS 服务器。 从 HGS 备份文件导入实际密钥后,可以删除临时密钥。
- 从备份导入 HGS 设置以还原受信任的主机组、代码完整性策略、TPM 基线和 TPM 标识符
提示
新 HGS 群集使用的证书、服务名称或域不需要与从中导出了备份文件的 HGS 实例相同。
从备份导入设置
要从备份文件将证明策略、基于 PFX 的证书和非 PFX 证书的公钥还原到 HGS 节点,请在已初始化的 HGS 服务器节点上运行以下命令。 系统将提示你输入在创建备份时指定的密码。
Import-HgsServerState -Path C:\Temp\HGSBackup.xml
如果你只想导入管理员信任的证明策略或 TPM 信任的证明策略,可以在 Import-HgsServerState 命令中指定 -ImportActiveDirectoryModeState
或 -ImportTpmModeState
标志。
在运行 Import-HgsServerState
之前,确保已安装 Windows Server 2016 的最新累积更新。
否则可能会导致导入错误。
注意
如果在已安装上述一个或多个策略的现有 HGS 节点上还原策略,import 命令将针对每个重复策略显示错误。 这是预期的行为,在大多数情况下可以放心忽略此错误。
重新安装证书的私钥
如果从中创建备份的 HGS 上使用的任何证书是使用指纹添加的,则只会将这些证书的公钥包含在备份文件中。 这意味着,你需要手动安装和/或授予对其中每个证书的私钥的访问权限,然后 HGS 才能为来自 Hyper-V 主机的请求提供服务。 完成该步骤所需的操作因最初颁发证书的方式而异。 对于证书颁发机构颁发的由软件支持的证书,则你需要联系 CA 获取私钥,并按照他们的说明将此私钥安装在每个 HGS 节点上。 同理,如果证书由硬件支持,则你需要查阅硬件安全模块供应商的文档,以在每个 HGS 节点上安装所需的驱动程序,以便能够连接到 HSM 并授予每台计算机对私钥的访问权限。
提醒一下,对于使用指纹添加到 HGS 的证书,需要将私钥手动复制到每个节点。 需要在添加到已还原的 HGS 群集的每个附加节点上重复此步骤。
检查导入的证明策略
从备份导入设置后,建议使用 Get-HgsAttestationPolicy
仔细检查所有导入的策略,确保只有你信任其运行受防护 VM 的主机才能成功通过证明。
如果你发现任何策略不再符合你的安全态势,可将其禁用或删除。
运行诊断程序以检查系统状态
设置和还原 HGS 节点的状态后,应运行 HGS 诊断工具来检查系统的状态。 为此,请在还原了配置的 HGS 节点上运行以下命令:
Get-HgsTrace -RunDiagnostics
如果“总体结果”不是“通过”,则需要执行额外的步骤来完成系统配置。 检查失败的子测试中报告的消息以了解详细信息。
修补 HGS
安装发布的最新累积更新来使主机守护者服务节点保持最新状态非常重要。如果你想要设置全新的 HGS 节点,强烈建议在安装 HGS 角色或对其进行配置之前安装任何可用更新。 这可以确保任何新的或已更改的功能立即生效。
修补受保护的结构时,强烈建议先升级所有 Hyper-V 主机,然后再升级 HGS。 这是为了确保在更新 Hyper-V 主机之后对 HGS 的证明策略进行任何更改,以提供主机所需的信息。 如果某项更新会更改策略的行为,将不会自动启用该更新,以避免中断结构。 此类更新要求按照下一部分中的指导激活新的或已更改的证明策略。 建议阅读 Windows Server 和安装的任何累积更新的发行说明,检查是否需要进行策略更新。
需要进行策略激活的更新
如果 HGS 的更新引入了或者大幅更改了证明策略的行为,则需要执行额外的步骤来激活更改的策略。 策略更改仅在导出和导入 HGS 状态后生效。 请仅在将累积更新应用于环境中的所有主机和所有 HGS 节点之后,才激活新的或已更改的策略。 更新每台计算机后,在任何 HGS 节点上运行以下命令以触发升级过程:
$password = Read-Host -AsSecureString -Prompt "Enter a temporary password"
Export-HgsServerState -Path .\temporaryExport.xml -Password $password
Import-HgsServerState -Path .\temporaryExport.xml -Password $password
如果引入了新策略,默认会禁用该策略。 要启用新策略,请首先在 Microsoft 策略列表中找到它(前缀为“HGS_”),然后使用以下命令启用它:
Get-HgsAttestationPolicy
Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>
管理证明策略
HGS 维护多个证明策略,这些策略定义主机被视为“正常”并可以运行受防护 VM 而必须满足的一套最低要求。 其中有些策略由 Microsoft 定义,还有一些策略由你添加,以定义允许的代码完整性策略、TPM 基线和环境中的主机。 必须定期维护这些策略,以确保在你更新和替换它们时主机可以继续正常通过证明,并确保阻止任何不受信任的主机或配置成功通过证明。
对于管理员信任的证明,只有一个策略可以确定主机是否正常:已知且受信任的安全组中的成员身份。 TPM 证明更复杂,它需要先通过各种策略来衡量系统的代码和配置,然后再确定系统是否正常。
可为单个 HGS 同时配置 Active Directory 和 TPM 策略,但服务只会检查主机尝试证明时配置的当前模式的策略。
要检查 HGS 服务器的模式,请运行 Get-HgsServer
。
默认策略
对于 TPM 信任的证明,在 HGS 上配置了多个内置策略。 其中一些策略是“锁定的”– 即,无法出于安全原因将其禁用。 下表解释了每个默认策略的用途。
策略名称 | 用途 |
---|---|
Hgs_SecureBootEnabled | 要求为主机启用安全启动。 必须使用此策略来衡量启动二进制文件和其他 UEFI 锁定设置。 |
Hgs_UefiDebugDisabled | 确保不为主机启用内核调试器。 用户模式调试器将被代码完整性策略阻止。 |
Hgs_SecureBootSettings | 用于确保主机至少匹配一个(管理员定义的)TPM 基线的否定策略。 |
Hgs_CiPolicy | 用于确保主机使用管理员定义的 CI 策略之一的否定策略。 |
Hgs_HypervisorEnforcedCiPolicy | 要求虚拟机监控程序强制实施代码完整性策略。 禁用此策略会削弱针对内核模式代码完整性策略攻击的保护。 |
Hgs_FullBoot | 确保主机未从睡眠或休眠状态恢复。 主机必须正确重启或关闭才能通过此策略。 |
Hgs_VsmIdkPresent | 要求在主机上运行基于虚拟化的安全性。 IDK 表示用于将发送回主机安全内存空间的信息加密的密钥。 |
Hgs_PageFileEncryptionEnabled | 要求在主机上加密页面文件。 如果检查未加密页面文件中的租户机密,禁用此策略可能导致信息泄露。 |
Hgs_BitLockerEnabled | 要求在 Hyper-V 主机上启用 BitLocker。 出于性能原因,此策略默认处于禁用状态,不建议启用。 此策略不影响受防护的 VM 本身的加密。 |
Hgs_IommuEnabled | 要求主机使用 IOMMU 设备来防止直接内存访问攻击。 禁用此策略并使用未启用 IOMMU 的主机可能会将租户 VM 机密暴露给直接内存攻击。 |
Hgs_NoHibernation | 要求在 Hyper-V 主机上禁用休眠。 禁用此策略可能会允许主机将受防护的 VM 内存保存到未加密的休眠文件中。 |
Hgs_NoDumps | 要求在 Hyper-V 主机上禁用内存转储。 如果你禁用此策略,建议配置转储加密以防止将受防护的 VM 内存保存到未加密的故障转储文件中。 |
Hgs_DumpEncryption | 要求使用 HGS 信任的加密密钥对内存转储(如果已在 Hyper-V 主机上启用)进行加密。 如果主机上未启用转储,则此策略不适用。 如果同时禁用了此策略和 Hgs_NoDumps,则可以将受防护的 VM 内存保存到未加密的转储文件中。 |
Hgs_DumpEncryptionKey | 用于确保配置为允许内存转储的主机使用 HGS 已知的、管理员定义的转储文件加密密钥的否定策略。 如果禁用了 Hgs_DumpEncryption,则此策略不适用。 |
授权新的受保护主机
要授权某个新主机成为受保护的主机(例如成功证明时),HGS 必须信任该主机以及(配置为使用 TPM 信任的证明时)在其上运行的软件。
授权新主机的步骤根据当前为 HGS 配置的证明模式而异。
要检查受保护结构的证明模式,请在任何 HGS 节点上运行 Get-HgsServer
。
软件配置
在新的 Hyper-V 主机上,确保安装了 Windows Server 2016 Datacenter 版。 Windows Server 2016 Standard 无法在受保护的结构中运行受防护的 VM。 可以在主机上安装桌面体验或服务器核心。
在装有桌面体验和服务器核心的服务器上,需要安装 Hyper-V 和主机保护者 Hyper-V 支持服务器角色:
Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart
管理员信任的证明
要在使用受管理员信任的证明时在 HGS 中注册新主机,必须先将该主机添加到它所加入到的域中的安全组。 通常,每个域都有一个用于受保护主机的安全组。 如果已将该组注册到 HGS,则需要执行的唯一操作是重启主机以刷新其组成员身份。
可以通过运行以下命令来检查 HGS 信任哪些安全组:
Get-HgsAttestationHostGroup
要将新安全组注册到 HGS,请先捕获该组在主机域中的安全标识符 (SID),然后将该 SID 注册到 HGS。
Add-HgsAttestationHostGroup -Name "Contoso Guarded Hosts" -Identifier "S-1-5-21-3623811015-3361044348-30300820-1013"
部署指南中提供了有关如何在主机域和 HGS 之间设置信任的说明。
TPM 信任的证明
在 TPM 模式下配置 HGS 时,主机必须通过所有锁定策略、以“Hgs_”为前缀的“已启用”策略,以及至少一个 TPM 基线、TPM 标识符和代码完整性策略。 每次添加新主机时,都需要向 HGS 注册新的 TPM 标识符。 只要主机运行与环境中另一台主机相同的软件(并已应用相同的代码完整性策略)和 TPM 基线,就不需要添加新的 CI 策略或基线。
为新主机添加 TPM 标识符。在新主机上,运行以下命令以捕获 TPM 标识符。 请务必为主机指定唯一名称,以帮助在 HGS 上查找该主机。 如果你要停用该主机或想要防止它在 HGS 中运行受防护的 VM,则需要提供此信息。
(Get-PlatformIdentifier -Name "Host01").InnerXml | Out-File C:\temp\host01.xml -Encoding UTF8
将此文件复制到 HGS 服务器,然后运行以下命令将主机注册到 HGS。
Add-HgsAttestationTpmHost -Name 'Host01' -Path C:\temp\host01.xml
添加新的 TPM 基线。如果新主机正在为环境运行新的硬件或固件配置,你可能需要采用新的 TPM 基线。 为此,请在主机上运行以下命令。
Get-HgsAttestationBaselinePolicy -Path 'C:\temp\hardwareConfig01.tcglog'
注意
如果有错误消息指出主机验证失败且无法成功证明,请不要担心。
这是一项先决条件检查,旨在确保主机可以运行受防护的 VM,它可能表示你尚未应用代码完整性策略或其他所需设置。
阅读错误消息,根据其中的建议做出任何更改,然后重试。
或者,此时可以通过在命令中添加 -SkipValidation
标志来跳过验证。
将 TPM 基线复制到 HGS 服务器,然后使用以下命令注册它。 我们建议使用某种命名约定来帮助了解此类 Hyper-V 主机的硬件和固件配置。
Add-HgsAttestationTpmPolicy -Name 'HardwareConfig01' -Path 'C:\temp\hardwareConfig01.tcglog'
添加新的代码完整性策略。如果你更改了在 Hyper-V 主机上运行的代码完整性策略,则需要先将新策略注册到 HGS,然后这些主机才能成功通过证明。
在用作环境中受信任 Hyper-V 计算机的主映像的参考主机上,使用 New-CIPolicy
命令捕获新的 CI 策略。
我们建议为 Hyper-V 主机 CI 策略使用 FilePublisher 级别和哈希回退。
应该首先在审核模式下创建一个 CI 策略,以确保一切按预期进行。
在系统上验证示例工作负荷后,可以强制实施策略并将强制实施的版本复制到 HGS。
有关代码完整性策略配置选项的完整列表,请参阅 Device Guard 文档。
# Capture a new CI policy with the FilePublisher primary level and Hash fallback and enable user mode code integrity protections
New-CIPolicy -FilePath 'C:\temp\ws2016-hardware01-ci.xml' -Level FilePublisher -Fallback Hash -UserPEs
# Apply the CI policy to the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer
# Check the event log for any untrusted binaries and update the policy if necessary
# Consult the Device Guard documentation for more details
# Change the policy to be in enforced mode
Set-RuleOption -FilePath 'C:\temp\ws2016-hardare01-ci.xml' -Option 3 -Delete
# Apply the enforced CI policy on the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer
创建、测试并强制实施策略后,将二进制文件 (.p7b) 复制到 HGS 服务器并注册该策略。
Add-HgsAttestationCiPolicy -Name 'WS2016-Hardware01' -Path 'C:\temp\ws2016-hardware01-ci.p7b'
添加内存转储加密密钥
当禁用 Hgs_NoDumps 策略并启用 Hgs_DumpEncryption 策略时,可为受保护的主机启用内存转储(包括故障转储),前提是将这些转储加密。 仅当受保护的主机禁用了内存转储或使用 HGS 已知的密钥对内存转储进行加密时,受保护的主机才能通过证明。 默认情况下,HGS 上未配置转储加密密钥。
要将转储加密密钥添加到 HGS,请使用 Add-HgsAttestationDumpPolicy
cmdlet 为 HGS 提供转储加密密钥的哈希。
如果在配置了转储加密的 Hyper-V 主机上捕获 TPM 基线,则哈希将包含在 tcglog 中,可将其提供给 Add-HgsAttestationDumpPolicy
cmdlet。
Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey01' -Path 'C:\temp\TpmBaselineWithDumpEncryptionKey.tcglog'
或者,你可以直接在该 cmdlet 中提供哈希的字符串表示形式。
Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey02' -PublicKeyHash '<paste your hash here>'
如果你选择在受保护的结构中使用不同的密钥,请务必将每个唯一转储加密密钥添加到 HGS。 使用 HGS 不知道的密钥加密内存转储的主机将通不过证明。
请查阅 Hyper-V 文档了解有关在主机上配置转储加密的详细信息。
查看系统是否通过了证明
将必要的信息注册到 HGS 后,应该检查主机是否通过了证明。
在新添加的 Hyper-V 主机上,运行 Set-HgsClientConfiguration
并提供 HGS 群集的正确 URL。
可以通过在任何 HGS 节点上运行 Get-HgsServer
来获取这些 URL。
Set-HgsClientConfiguration -KeyProtectionServerUrl 'https://hgs.bastion.local/KeyProtection' -AttestationServerUrl 'https://hgs.bastion.local/Attestation'
如果得到的状态未指示“IsHostGuarded: True”,则你需要排查配置问题。 在证明失败的主机上,运行以下命令以获取有关问题的详细报告来帮助解决证明失败的原因。
Get-HgsTrace -RunDiagnostics -Detailed
重要
如果你使用的是 Windows Server 2019 或 Windows 10 版本 1809,并且在使用代码完整性策略,则对于“代码完整性策略处于活动状态”诊断,Get-HgsTrace
可能返回失败结果。
如果这是唯一失败的诊断,则可以放心地忽略此结果。
查看证明策略
要查看 HGS 上配置的策略的当前状态,请在任何 HGS 节点上运行以下命令:
# List all trusted security groups for admin-trusted attestation
Get-HgsAttestationHostGroup
# List all policies configured for TPM-trusted attestation
Get-HgsAttestationPolicy
如果你发现启用的某个策略不再符合安全要求(例如,某个旧代码完整性策略现在被认为不安全),可以通过替换以下命令中的策略名称来禁用该策略:
Disable-HgsAttestationPolicy -Name 'PolicyName'
同样,可以使用 Enable-HgsAttestationPolicy
来重新启用策略。
如果你不再需要某个策略并希望将其从所有 HGS 节点中删除,请运行 Remove-HgsAttestationPolicy -Name 'PolicyName'
以永久删除该策略。
更改证明模式
如果你使用管理员信任的证明启动了受保护的结构,一旦环境中有足够的 TPM 2.0 兼容主机,你就可能想要升级到更强大的 TPM 证明模式。 当准备好切换时,可以在 HGS 中预加载所有证明项目(CI 策略、TPM 基线和 TPM 标识符),同时继续使用管理员信任的证明运行 HGS。 为此,只需按照授权新的受保护主机部分中的说明操作即可。
将所有策略添加到 HGS 后,下一步是在主机上尝试运行综合证明,以查看它们是否会在 TPM 模式下通过证明。 这不会影响 HGS 的当前运行状态。 以下命令必须在可以访问环境中所有主机和至少一个 HGS 节点的计算机上运行。 如果防火墙或其他安全策略阻止此操作,你可以跳过此步骤。 我们建议尽可能运行综合证明,以便清楚地了解“切换”到 TPM 模式是否会导致 VM 停机。
# Get information for each host in your environment
$hostNames = 'host01.contoso.com', 'host02.contoso.com', 'host03.contoso.com'
$credential = Get-Credential -Message 'Enter a credential with admin privileges on each host'
$targets = @()
$hostNames | ForEach-Object { $targets += New-HgsTraceTarget -Credential $credential -Role GuardedHost -HostName $_ }
$hgsCredential = Get-Credential -Message 'Enter an admin credential for HGS'
$targets += New-HgsTraceTarget -Credential $hgsCredential -Role HostGuardianService -HostName 'HGS01.bastion.local'
# Initiate the synthetic attestation attempt
Get-HgsTrace -RunDiagnostics -Target $targets -Diagnostic GuardedFabricTpmMode
诊断完成后,查看输出的信息以确定是否有任何主机在 TPM 模式下通不过证明。 重新运行诊断,直到每个主机的诊断结果为“通过”,然后继续将 HGS 更改为 TPM 模式。
只需一秒即可更改为 TPM 模式。 在任何 HGS 节点上运行以下命令以更新证明模式。
Set-HgsServer -TrustTpm
如果你遇到问题并需要切换回 Active Directory 模式,可以运行 Set-HgsServer -TrustActiveDirectory
。
确认一切按预期进行后,应该从 HGS 中删除所有受信任的 Active Directory 主机组,并删除 HGS 和结构域之间的信任。 如果你保留 Active Directory 信任,则面临的风险是,某人可能会重新启用该信任并将 HGS 切换到 Active Directory 模式,导致不受信任的代码未经检查在受保护的主机上运行。
密钥管理
受保护的结构解决方案使用多个公钥/私钥对来验证解决方案中各个组件的完整性和加密租户机密。 主机保护者服务中至少配置了两个证书(带有公钥和私钥),这些证书为用于启动受防护 VM 的密钥进行签名和加密。 必须用心管理这些密钥。 如果攻击者获取了私钥,他们就可以取消保护在结构上运行的任何 VM,或者设置一个仿冒的 HGS 群集并在其中使用较弱的证明策略来绕过你实施的保护措施。 如果在灾难期间丢失了私钥并且在备份中找不到它们,则需要设置一个新的密钥对,并在每个 VM 上重建密钥以便为新证书授权。
本部分涵盖一般性的密钥管理主题,以帮助你配置密钥,使其可以发挥作用并且安全。
添加新密钥
虽然 HGS 必须使用一组密钥进行初始化,但你可以向 HGS 添加多个加密密钥和签名密钥。 将新密钥添加到 HGS 的两个最常见原因是:
- 支持“自带密钥”方案,在其中,租户可将其私钥复制到你的硬件安全模块,并仅授权其密钥启动其受防护的 VM。
- 替换 HGS 的现有密钥,方法是先添加新密钥并保留两组密钥,直到每个 VM 配置已更新为使用新密钥。
添加新密钥的过程根据使用的证书类型而异。
选项 1:添加存储在 HSM 中的证书
保护 HGS 密钥的建议方法是使用在硬件安全模块 (HSM) 中创建的证书。 HSM 确保密钥的使用方式与以物理方式访问数据中心内的安全敏感型设备相关联。 每个 HSM 都是不同的,它通过一个独特的过程来创建证书并将其注册到 HGS。 以下步骤旨在提供有关使用 HSM 支持的证书的粗略指导。 有关确切的步骤和功能,请查阅 HSM 供应商的文档。
在群集中的每个 HGS 节点上安装 HSM 软件。 根据你使用的是网络设备还是本地 HSM 设备,可能需要配置 HSM 以授予计算机访问其密钥存储的权限。
使用 2048 位 RSA 密钥在 HSM 中创建 2 个证书用于加密和签名
- 使用数据加密密钥用法属性在 HSM 中创建加密证书
- 使用数字签名密钥用法属性在 HSM 中创建签名证书
根据 HSM 供应商的指导,在每个 HGS 节点的本地证书存储中安装这些证书。
如果 HSM 使用粒度权限为特定应用程序或用户授予使用私钥的权限,则你需要为 HGS 组托管服务帐户授予对证书的访问权限。 可以通过运行
(Get-IISAppPool -Name KeyProtection).ProcessModel.UserName
找到 HGS gMSA 帐户的名称通过将以下命令中的 thumbprint 替换为你的证书指纹,将签名证书和加密证书添加到 HGS:
Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899" Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA"
选项 2:添加不可导出的软件证书
如果你使用由你的公司或公共证书颁发机构颁发的软件支持证书,并且该证书中的私钥不可导出,则你需要使用证书指纹将证书添加到 HGS。
根据证书颁发机构的说明在计算机上安装证书。
为 HGS 组托管服务帐户授予对证书私钥的读取访问权限。 可以通过运行
(Get-IISAppPool -Name KeyProtection).ProcessModel.UserName
找到 HGS gMSA 帐户的名称使用以下命令并将占位符替换为你的证书指纹,将证书注册到 HGS并(对于签名证书,请将 Encryption 更改为 Signing):
Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
重要
需要在每个 HGS 节点上手动安装私钥并为 gMSA 帐户授予读取访问权限。 HGS 无法为通过证书指纹注册的任何证书自动复制私钥。
选项 3:添加存储在 PFX 文件中的证书
如果你有一个包含可导出私钥的软件支持证书,并且该证书能够以 PFX 文件格式存储并使用密码进行保护,则 HGS 可以自动为你管理证书。 使用 PFX 文件添加的证书会自动复制到 HGS 群集的每个节点,并且 HGS 会保护对私钥的访问。 要使用 PFX 文件添加新证书,请在任何 HGS 节点上运行以下命令(对于签名证书,请将 Encryption 更改为 Signing):
$certPassword = Read-Host -AsSecureString -Prompt "Provide the PFX file password"
Add-HgsKeyProtectionCertificate -CertificateType Encryption -CertificatePath "C:\temp\encryptionCert.pfx" -CertificatePassword $certPassword
识别和更改主要证书。虽然 HGS 支持多个签名证书和加密证书,但它只会使用一对证书作为其“主要”证书。 如果某人下载该 HGS 群集的保护者元数据,将使用这些证书。 要检查当前已将哪些证书标记为主要证书,请运行以下命令:
Get-HgsKeyProtectionCertificate -IsPrimary $true
要设置新的主要加密证书或签名证书,请找到所需证书的指纹,并使用以下命令将其标记为主要证书:
Get-HgsKeyProtectionCertificate
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899" -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA" -IsPrimary
续订或替换密钥
当你创建 HGS 使用的证书时,系统将根据证书颁发机构的策略和你的请求信息为证书分配一个过期日期。 通常,在证书有效性非常重要的情况下(例如用于保护 HTTP 通信),必须在证书过期之前续订证书,以避免服务中断或出现令人焦虑的错误消息。 HGS 不会在这种意义上使用证书。 HGS 只会将证书用作创建和存储非对称密钥对的便捷方式。 HGS 上的加密证书或签名证书过期并不意味着受防护的 VM 出现弱点或失去保护。 此外,HGS 不会执行证书吊销检查。 吊销 HGS 证书或颁发机构的证书不会影响 HGS 使用该证书。
对于 HGS 证书,唯一需要担心的情况是你有理由相信其私钥被盗。 在这种情况下,受防护 VM 的完整性将面临风险,因为拥有 HGS 加密和签名密钥对的私钥部分足以取消 VM 上的保护,或建立一个实施较弱证明策略的仿冒 HGS 服务器。
如果你发现自己处于这种局面,或者合规性标准要求定期刷新证书密钥,请按照以下步骤所述的过程更改 HGS 服务器上的密钥。 请注意,以下指导中所述的任务会造成严重影响,它会导致由 HGS 群集提供服务的每个 VM 发生服务中断。 需要正确规划 HGS 密钥的更改,以最大程度地减少服务中断并确保租户 VM 的安全性。
在 HGS 节点上,执行以下步骤以注册一对新的加密证书和签名证书。 有关向 HGS 添加新密钥的各种方法的详细信息,请参阅有关添加新密钥的部分。
为 HGS 服务器创建一对新的加密证书和签名证书。 理想情况下,会在硬件安全模块中创建这些证书。
使用 Add-HgsKeyProtectionCertificate 注册新的加密证书和签名证书
Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>
如果使用了指纹,则需要转到群集中的每个节点,以安装私钥并授予 HGS gMSA 访问密钥的权限。
将新证书设为 HGS 中的默认证书
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsPrimary Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsPrimary
现在,将使用新证书来保护使用从 HGS 节点获取的元数据创建的数据,但现有 VM 将继续运行,因为旧证书仍然存在。
为了确保所有现有 VM 使用新密钥,需要更新每个 VM 上的密钥保护程序。
此操作需要 VM 拥有者(拥有“所有者”保护者的个人或实体)的参与。 对于每个受防护的 VM,请执行以下步骤:
关闭 VM。 在完成其余步骤之前不能重新打开 VM,否则需要再次执行该过程。
将当前密钥保护程序保存到文件:
Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp'
将 KP 转移给 VM 所有者
让所有者从 HGS 下载更新的保护者信息并将其导入他们的本地系统
将当前 KP 读入内存,为新保护者授予对 KP 的访问权限,并通过运行以下命令将 KP 保存到新文件中:
$kpraw = Get-Content -Path .\VM001.kp $kp = ConvertTo-HgsKeyProtector -Bytes $kpraw $newGuardian = Get-HgsGuardian -Name 'UpdatedHgsGuardian' $updatedKP = Grant-HgsKeyProtectorAccess -KeyProtector $kp -Guardian $newGuardian $updatedKP.RawData | Out-File .\updatedVM001.kp
将更新的 KP 复制回宿主结构。
将 KP 应用于原始 VM:
$updatedKP = Get-Content -Path .\updatedVM001.kp Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP
最后,启动 VM 并确保其成功运行。
注意
如果 VM 所有者在 VM 上设置了错误的密钥保护程序并且未授权结构运行 VM,则你将无法启动受防护的 VM。 要返回到上次已知良好的密钥保护程序,请运行
Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector
更新所有 VM 以授权新的保护者密钥后,可以禁用并删除旧密钥。
使用
Get-HgsKeyProtectionCertificate -IsPrimary $false
获取旧证书的指纹通过运行以下命令禁用每个证书:
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsEnabled $false Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsEnabled $false
确保 VM 仍然可以在禁用证书的情况下启动后,通过运行以下命令从 HGS 中删除证书:
Remove-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>` Remove-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>`
重要
VM 备份将包含旧密钥保护程序信息,借助这些信息可以使用旧证书启动 VM。 如果你知道自己的私钥已被泄露,则应该假设 VM 备份也可能被泄露,并采取适当的措施。 从备份 (.vmcx) 中销毁 VM 配置可以删除密钥保护程序,代价是下次需要使用 BitLocker 恢复密码来启动 VM。
节点之间的密钥复制
必须为 HGS 群集中的每个节点配置相同的加密、签名和(如果已配置)SSL 证书。 只有这样,才能确保成功处理与群集中任何节点通信的 Hyper-V 主机的请求。
如果你使用基于 PFX 的证书初始化了 HGS 服务器,则 HGS 将自动在群集中的每个节点上复制这些证书的公钥和私钥。 只需在一个节点上添加密钥即可。
如果你使用证书引用或指纹初始化了 HGS 服务器,则 HGS 只会将证书中的公钥复制到每个节点。 此外,在这种情况下,HGS 无法授予自己对任何节点上的私钥的访问权限。 因此,你需要负责:
- 在每个 HGS 节点上安装私钥
- 为 HGS 组托管服务帐户 (gMSA) 授予对每个节点上的私钥的访问权限。这些任务增加了额外的操作负担,但是,对于 HSM 支持的密钥以及包含不可导出私钥的证书,必须执行这些任务。
永远不会以任何形式复制 SSL 证书。 你需要负责使用相同的 SSL 证书初始化每个 HGS 服务器,并且每次续订或替换 SSL 证书时,都需要更新每个服务器。 替换 SSL 证书时,建议使用 Set-HgsServer cmdlet 执行此操作。
取消配置 HGS
如果你需要停用 HGS 服务器或者对其进行重大配置更改,可以使用 Clear-HgsServer 或 Uninstall-HgsServer cmdlet。
清除 HGS 配置
要从 HGS 群集中删除节点,请使用 Clear-HgsServer cmdlet。 此 cmdlet 将在其运行所在的服务器上进行以下更改:
- 取消注册证明和密钥保护服务
- 删除“microsoft.windows.hgs”JEA 管理终结点
- 从 HGS 故障转移群集中删除本地计算机
如果该服务器是群集中的最后一个 HGS 节点,则也会销毁该群集及其对应的分布式网络名称资源。
# Removes the local computer from the HGS cluster
Clear-HgsServer
清除操作完成后,可以使用 Initialize-HgsServer 重新初始化 HGS 服务器。 如果你使用 Install-HgsServer 设置了 Active Directory 域服务域,则在完成清除操作后,将保留配置该域,并且它可以正常运行。
卸载 HGS
如果你希望从 HGS 群集中删除节点并降级其上运行的 Active Directory 域控制器,请使用 Uninstall-HgsServer cmdlet。 此 cmdlet 将在其运行所在的服务器上进行以下更改:
- 取消注册证明和密钥保护服务
- 删除“microsoft.windows.hgs”JEA 管理终结点
- 从 HGS 故障转移群集中删除本地计算机
- 降级 Active Directory 域控制器(如果已配置)
如果该服务器是群集中的最后一个 HGS 节点,则也会销毁域、故障转移群集和群集的分布式网络名称资源。
# Removes the local computer from the HGS cluster and demotes the ADDC (restart required)
$newLocalAdminPassword = Read-Host -AsSecureString -Prompt "Enter a new password for the local administrator account"
Uninstall-HgsServer -LocalAdministratorPassword $newLocalAdminPassword -Restart
完成卸载操作并重启计算机后,可以使用 Install-HgsServer 重新安装 ADDC 和 HGS,或者将计算机加入域并使用 Initialize-HgsServer 初始化该域中的 HGS 服务器。
如果你不打算再将该计算机用作 HGS 节点,可以从 Windows 中删除相应的角色。
Uninstall-WindowsFeature HostGuardianServiceRole