Управление службой защиты узла

Статья
04/22/2023

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

Служба защиты узла (HGS) является центральным элементом защищенного решения структуры. Он отвечает за обеспечение того, чтобы узлы Hyper-V в структуре известны хост-сайту или организации и работали с доверенным программным обеспечением, а также управлять ключами, используемыми для запуска экранированных виртуальных машин. Когда клиент решит доверять размещению экранированных виртуальных машин, они размещают доверие к вашей конфигурации и управлению службой защиты узлов. Поэтому очень важно следовать рекомендациям при управлении службой защиты узла, чтобы обеспечить безопасность, доступность и надежность защищенной структуры. В следующих разделах приведены рекомендации по наиболее распространенным операционным проблемам, которые сталкиваются с администраторами HGS.

Ограничение доступа администратора к HGS

Из-за конфиденциальности безопасности HGS важно убедиться, что ее администраторы являются высоконадежными членами вашей организации и, в идеале, отделяются от администраторов ресурсов структуры. Кроме того, рекомендуется управлять только HGS с защищенных рабочих станций с помощью безопасных протоколов связи, таких как WinRM по протоколу HTTPS.

Разделение обязанностей

При настройке HGS вы можете создать изолированный лес Active Directory только для HGS или присоединить HGS к существующему доверенному домену. Это решение, а также роли, назначенные администраторам в организации, определяют границу доверия для HGS. Кто ever имеет доступ к HGS, будь то непосредственно как администратор или косвенно как администратор чего-то другого (например, Active Directory), который может повлиять на HGS, имеет контроль над защищенной структурой. Администраторы HGS выбирают, какие узлы Hyper-V разрешены для запуска экранированных виртуальных машин и управления сертификатами, необходимыми для запуска экранированных виртуальных машин. Злоумышленник или злоумышленник, имеющий доступ к HGS, может использовать эту возможность, чтобы авторизовать скомпрометированные узлы для запуска экранированных виртуальных машин, инициировать атаку типа "отказ в обслуживании", удалив материалы ключей и многое другое.

Чтобы избежать этого риска, настоятельно рекомендуется ограничить перекрытие между администраторами HGS (включая домен, к которому присоединено HGS) и среды Hyper-V. Гарантируя, что ни один администратор не имеет доступа к обеим системам, злоумышленнику потребуется скомпрометировать 2 разных учетных записей от 2 человек, чтобы завершить свою миссию, чтобы изменить политики HGS. Это также означает, что администраторы домена и предприятия для двух сред Active Directory не должны быть одинаковыми пользователями, а также не должны использовать один и тот же лес Active Directory, что и узлы Hyper-V. Любой пользователь, который может предоставить себе доступ к дополнительным ресурсам, представляет угрозу безопасности.

Использование just Enough Администратор istration

HGS поставляется с ролями Just Enough Администратор istration (JEA), встроенными, чтобы помочь вам управлять им более безопасно. JEA помогает, позволяя делегировать задачи администратора неадминистраторным пользователям, то есть пользователям, которые управляют политиками HGS, на самом деле не должны быть администраторами всего компьютера или домена. JEA работает путем ограничения команд, которые пользователь может выполнять в сеансе PowerShell и использовать временную локальную учетную запись за кулисами (уникальную для каждого сеанса пользователя) для выполнения команд, которые обычно требуют повышения прав.

HGS поставляется с предварительно настроенными ролями JEA:

HGS Администратор istrator, который позволяет пользователям управлять всеми политиками HGS, включая авторизацию новых узлов для запуска экранированных виртуальных машин.
Рецензенты HGS, которые позволяют пользователям проверять существующие политики только пользователями. Они не могут вносить изменения в конфигурацию HGS.

Чтобы использовать JEA, сначала необходимо создать нового стандартного пользователя и сделать их членом группы рецензентов HGS или HGS. Если вы использовали Install-HgsServer для настройки нового леса для HGS, эти группы будут называться "servicename Администратор istrators" и "Рецензенты имени службы", соответственно, где имя службы — сетевое имя кластера 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

Введите команду Exit-PSSession или его псевдоним, exitкогда вы закончите работу с сеансом JEA.

Добавление новой политики в HGS с помощью роли администратора

Чтобы изменить политику, необходимо подключиться к конечной точке JEA с удостоверением, принадлежащим группе hgs Администратор istrators. В приведенном ниже примере показано, как скопировать новую политику целостности кода в 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 будут отображаться в журнале событий Windows в 2 источниках:

Аттестация 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 и скачайте защищенный пакет управления fabric. Включено руководство по пакету управления объясняет, как настроить пакет управления и понять область его мониторов.

Резервное копирование и восстановление HGS

План аварийного восстановления

При разработке планов аварийного восстановления важно учитывать уникальные требования службы защиты узла в защищенной структуре. Если вы потеряете некоторые или все узлы HGS, вы можете столкнуться с непосредственными проблемами доступности, которые помогут пользователям запускать экранированные виртуальные машины. В сценарии, когда вы теряете весь кластер HGS, вам потребуется выполнить полные резервные копии конфигурации HGS, чтобы восстановить кластер HGS и возобновить обычные операции. В этом разделе рассматриваются действия, необходимые для подготовки к такому сценарию.

Во-первых, важно понимать, что касается HGS, важно создать резервную копию. HGS сохраняет несколько фрагментов информации, которые помогают определить, какие узлы разрешены для запуска экранированных виртуальных машин. В том числе:

Идентификаторы безопасности Active Directory для групп, содержащих доверенные узлы (при использовании аттестации Active Directory);
Уникальные идентификаторы доверенного платформенного модуля для каждого узла в вашей среде;
Политики TPM для каждой уникальной конфигурации узла; И
Политики целостности кода, определяющие, какое программное обеспечение разрешено запускать на узлах.

Эти артефакты аттестации требуют координации с администраторами структуры размещения для получения, потенциально что затрудняет получение этой информации после аварии.

Кроме того, HGS требует доступа к 2 или нескольким сертификатам, используемым для шифрования и подписывания информации, необходимой для запуска экранированного виртуальной машины (средства защиты ключей). Эти сертификаты хорошо известны (используются владельцами экранированных виртуальных машин для авторизации структуры для запуска виртуальных машин) и должны быть восстановлены после аварии для простого восстановления. Если вы не восстановите HGS с теми же сертификатами после аварии, каждая виртуальная машина должна быть обновлена, чтобы авторизовать новые ключи для расшифровки их информации. По соображениям безопасности только владелец виртуальной машины может обновить конфигурацию виртуальной машины, чтобы авторизовать эти новые ключи, что означает, что сбой восстановления ключей после аварии приведет к тому, что каждому владельцу виртуальной машины потребуется выполнить действия для повторного запуска виртуальных машин.

Подготовка к худшему

Чтобы подготовиться к полной потере HGS, необходимо выполнить 2 действия.

Резервное копирование политик аттестации HGS
Резервное копирование ключей HGS

Инструкции по выполнению обоих этих действий приведены в разделе резервного копирования HGS .

Кроме того, рекомендуется создать резервную копию списка пользователей, авторизованных для управления HGS в домене Active Directory или в самом Active Directory.

Резервные копии следует регулярно принимать, чтобы обеспечить актуальность и безопасное хранение информации, чтобы избежать изменения или кражи.

Не рекомендуется создавать резервные копии или пытаться восстановить весь системный образ узла HGS. В случае потери всего кластера рекомендуется настроить новый узел HGS и восстановить только состояние HGS, а не всю ОС сервера.

Восстановление после потери одного узла

Если вы потеряете один или несколько узлов (но не каждый узел) в кластере HGS, вы можете просто добавить узлы в кластер , следуя инструкциям в руководстве по развертыванию. Политики аттестации будут синхронизироваться автоматически, так как все сертификаты, которые были предоставлены HGS в качестве PFX-файлов с сопровождающими паролями. Для сертификатов, добавленных в HGS, с помощью отпечатка (не экспортируемых и аппаратных резервных сертификатов), необходимо убедиться, что каждый новый узел имеет доступ к закрытому ключу каждого сертификата.

Восстановление после потери всего кластера

Если весь кластер HGS выходит из строя, и вы не сможете вернуть его в сеть, вам потребуется восстановить HGS из резервной копии. Восстановление HGS из резервной копии включает в себя первую настройку нового кластера HGS в руководстве по развертыванию. Настоятельно рекомендуется использовать то же имя кластера, но не обязательно при настройке среды HGS восстановления для разрешения имен с узлов. Использование того же имени позволяет избежать необходимости перенастройки узлов с новыми URL-адресами аттестации и защиты ключей. Если вы восстановили объекты в домене Active Directory с поддержкой HGS, рекомендуется удалить объекты, представляющие кластер HGS, компьютеры, учетные записи службы и группы JEA перед инициализацией сервера HGS.

После настройки первого узла HGS (например, он был установлен и инициализирован), выполните процедуры, описанные в разделе "Восстановление HGS из резервной копии " для восстановления политик аттестации и общедоступных половин сертификатов защиты ключей. Вам потребуется восстановить закрытые ключи для сертификатов вручную в соответствии с руководством поставщика сертификатов (например, импортировать сертификат в Windows или настроить доступ к сертификатам, поддерживаемым HSM). После настройки первого узла можно продолжать устанавливать дополнительные узлы в кластер , пока не достигнете требуемой емкости и устойчивости.

Резервное копирование HGS

Администратор HGS должен отвечать за резервное копирование HGS на регулярной основе. Полная резервная копия будет содержать материалы с конфиденциальными ключами, которые должны быть надлежащим образом защищены. Если недоверенная сущность получает доступ к этим ключам, они могут использовать этот материал для настройки вредоносной среды HGS для целей компрометации экранированных виртуальных машин.

Резервное копирование политик аттестации для резервного копирования политик аттестации HGS выполните следующую команду на любом рабочем узле сервера HGS. Вам будет предложено указать пароль. Этот пароль используется для шифрования сертификатов, добавленных в HGS, с помощью PFX-файла (вместо отпечатка сертификата).

Export-HgsServerState -Path C:\temp\HGSBackup.xml

Примечание.

Если вы используете аттестацию с доверенным администратором, необходимо отдельно создать резервную копию членства в группах безопасности, используемых HGS для авторизации защищенных узлов. HGS будет создавать резервную копию идентификатора безопасности групп безопасности, а не членство в них. В случае потери этих групп во время аварии необходимо повторно создать группы и добавить к ним каждый защищенный узел.

Резервное копирование сертификатов

Команда Export-HgsServerState будет создавать резервные копии всех сертификатов на основе PFX, добавленных в HGS во время выполнения команды. Если вы добавили сертификаты в HGS, используя отпечаток (типичный для не экспортируемых и аппаратных сертификатов), вам потребуется вручную создать резервную копию закрытых ключей для сертификатов. Чтобы определить, какие сертификаты зарегистрированы в HGS и необходимо создать резервную копию вручную, выполните следующую команду PowerShell на любом рабочем узле сервера HGS.

Get-HgsKeyProtectionCertificate | Where-Object { $_.CertificateData.GetType().Name -eq 'CertificateReference' } | Format-Table Thumbprint, @{ Label = 'Subject'; Expression = { $_.CertificateData.Certificate.Subject } }

Для каждого из перечисленных сертификатов потребуется вручную создать резервную копию закрытого ключа. Если вы используете сертификат на основе программного обеспечения, который не экспортируется, обратитесь в центр сертификации, чтобы убедиться, что у них есть резервная копия сертификата и (или) может повторно выполнить его по запросу. Для сертификатов, созданных и хранящихся в аппаратных модулях безопасности, обратитесь к документации по устройству, чтобы получить рекомендации по планированию аварийного восстановления.

Резервные копии сертификатов следует хранить вместе с резервными копиями политики аттестации в безопасном расположении, чтобы обе части могли быть восстановлены вместе.

Дополнительная конфигурация для резервного копирования

Резервное копирование состояния сервера HGS не будет включать имя кластера HGS, любые сведения из Active Directory или любые SSL-сертификаты, используемые для защиты связи с API HGS. Эти параметры важны для согласованности, но не критически важны для восстановления кластера HGS в сети после аварии.

Чтобы записать имя службы HGS, выполните Get-HgsServer и запишите неструктурированное имя в URL-адресах аттестации и защиты ключей. Например, если URL-адрес аттестации имеет значение "https://hgs.contoso.com/Attestation", "hgs" — это имя службы HGS.

Домен Active Directory, используемый HGS, должен управляться как и любой другой домен Active Directory. При восстановлении HGS после аварии вам не обязательно потребуется воссоздать точные объекты, присутствующих в текущем домене. Однако это упрощает восстановление при резервном копировании Active Directory и сохранении списка пользователей JEA, авторизованных для управления системой, а также членства в любых группах безопасности, используемых доверенным администратором аттестации для авторизации защищенных узлов.

Чтобы определить отпечаток SSL-сертификатов, настроенных для HGS, выполните следующую команду в PowerShell. Затем вы можете создать резервную копию этих SSL-сертификатов в соответствии с инструкциями поставщика сертификатов.

Get-WebBinding -Protocol https | Select-Object certificateHash

Восстановление HGS из резервной копии

В следующих шагах описывается восстановление параметров HGS из резервной копии. Действия относятся к обоим ситуациям, когда вы пытаетесь отменить изменения, внесенные в уже запущенные экземпляры HGS, и когда вы стоите в новом кластере HGS после полной потери предыдущего.

Настройка замены кластера HGS

Прежде чем восстановить HGS, необходимо иметь инициализированный кластер HGS, в который можно восстановить конфигурацию. Если вы просто импортируете параметры, которые были случайно удалены в существующий (запущенный) кластер, можно пропустить этот шаг. Если вы восстанавливаетесь после полной потери HGS, необходимо установить и инициализировать по крайней мере один узел HGS после руководства по развертыванию.

В частности, необходимо:

Настройка домена HGS или присоединение HGS к существующему домену
Инициализировать сервер HGS с помощью существующих ключей или набора временных ключей. Временные ключи можно удалить после импорта фактических ключей из файлов резервной копии HGS.
Импорт параметров HGS из резервной копии для восстановления доверенных групп узлов, политик целостности кода, базовых показателей TPM и идентификаторов доверенного платформенного модуля

Совет

Новый кластер HGS не должен использовать те же сертификаты, имя службы или домен, что и экземпляр HGS, из которого экспортирован файл резервной копии.

Импорт параметров из резервной копии

Чтобы восстановить политики аттестации, сертификаты на основе PFX и открытые ключи сертификатов, отличных от PFX, на узле HGS из файла резервной копии выполните следующую команду на инициализированном узле сервера HGS. Вам будет предложено ввести пароль, указанный при создании резервной копии.

Import-HgsServerState -Path C:\Temp\HGSBackup.xml

Если вы хотите импортировать только политики аттестации доверенных администраторов или политики аттестации доверенного платформенного модуля, это можно сделать, указав -ImportActiveDirectoryModeState или флаги для Import-HgsServerState-ImportTpmModeState.

Убедитесь, что перед запуском Import-HgsServerStateустановлена последняя накопительная версия обновления для Windows Server 2016. Сбой этого может привести к ошибке импорта.

Примечание.

Если вы восстанавливаете политики на существующем узле HGS, который уже имеет одну или несколько этих политик, команда импорта отобразит ошибку для каждой повторяющейся политики. Это ожидаемое поведение и может быть безопасно проигнорировано в большинстве случаев.

Переустановка закрытых ключей для сертификатов

Если любой из сертификатов, используемых в HGS, из которого была создана резервная копия, был добавлен с помощью отпечатков, в файл резервной копии будет включен только открытый ключ этих сертификатов. Это означает, что необходимо вручную установить и /или предоставить доступ к закрытым ключам для каждого из этих сертификатов, прежде чем HGS может обслуживать запросы от узлов Hyper-V. Действия, необходимые для выполнения этого шага, зависят от способа первоначального выпуска сертификата. Чтобы получить закрытый ключ и установить его на каждом узле HGS, необходимо связаться с центром сертификации. Аналогичным образом, если сертификаты являются аппаратными, вам потребуется обратиться к документации поставщика модуля безопасности оборудования, чтобы установить необходимые драйверы на каждом узле HGS для подключения к HSM и предоставить каждому компьютеру доступ к закрытому ключу.

Как напоминание, сертификаты, добавленные в HGS с помощью отпечатков, требуют ручного реплика выведения закрытых ключей на каждый узел. Этот шаг потребуется повторить на каждом дополнительном узле, добавленном в восстановленный кластер HGS.

Проверка импортированных политик аттестации

После импорта параметров из резервной копии рекомендуется внимательно просмотреть все импортированные политики, чтобы Get-HgsAttestationPolicy убедиться, что только узлы, которым вы доверяете запускать экранированные виртуальные машины, смогут успешно проверить. Если вы найдете какие-либо политики, которые больше не соответствуют вашей системе безопасности, их можно отключить или удалить.

Запуск диагностика для проверка состояния системы

После завершения настройки и восстановления состояния узла HGS необходимо запустить средство HGS диагностика, чтобы проверка состояние системы. Для этого выполните следующую команду на узле HGS, где вы восстановили конфигурацию:

Get-HgsTrace -RunDiagnostics

Если значение "Общий результат" не является "Pass", для завершения настройки системы требуются дополнительные шаги. Проверьте сообщения, сообщаемые в вложенных тестах, которые не удалось получить дополнительные сведения.

Исправление HGS

Важно обеспечить актуальность узлов службы защиты узла, установив последнее накопительное обновление при выходе. Если вы настраиваете новый узел HGS, настоятельно рекомендуется установить все доступные обновления перед установкой роли HGS или его настройкой. Это обеспечит немедленное выполнение любых новых или измененных функций.

При исправлении защищенной структуры настоятельно рекомендуется сначала обновить все узлы Hyper-V перед обновлением HGS. Это позволяет убедиться, что все изменения политик аттестации в HGS выполняются после обновления узлов Hyper-V, чтобы предоставить сведения, необходимые для них. Если обновление изменит поведение политик, они не будут включены автоматически, чтобы избежать нарушения структуры. Для таких обновлений необходимо выполнить инструкции, приведенные в следующем разделе, чтобы активировать новые или измененные политики аттестации. Мы рекомендуем прочитать заметки о выпуске Для 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

Если была введена новая политика, она будет отключена по умолчанию. Чтобы включить новую политику, сначала найдите ее в списке политик Майкрософт (префикс с помощью HGS_), а затем включите ее с помощью следующих команд:

Get-HgsAttestationPolicy

Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>

Управление политиками аттестации

HGS поддерживает несколько политик аттестации, определяющих минимальный набор требований, которые должны соответствовать узлу, чтобы считаться "работоспособным" и разрешать запускать экранированные виртуальные машины. Некоторые из этих политик определены корпорацией Майкрософт, другие добавляются для определения допустимых политик целостности кода, базовых показателей доверенного платформенного модуля и узлов в вашей среде. Регулярное обслуживание этих политик необходимо, чтобы узлы могли правильно проверить, как обновить и заменить их, и убедиться, что все ненадежные узлы или конфигурации заблокированы от успешного проверки.

Для аттестации доверия администратора существует только одна политика, которая определяет работоспособность узла: членство в известной доверенной группе безопасности. Аттестация доверенного платформенного модуля сложнее и включает в себя различные политики для измерения кода и конфигурации системы перед определением работоспособности.

Единый HGS можно настроить одновременно с политиками Active Directory и TPM, но служба будет проверка политики для текущего режима, для которого она настроена, когда узел пытается подтвердить. Чтобы проверка режим сервера HGS, выполните командуGet-HgsServer.

Политики по умолчанию

Для аттестации доверенного платформенного модуля существует несколько встроенных политик, настроенных в HGS. Некоторые из этих политик "заблокированы" — это означает, что они не могут быть отключены по соображениям безопасности. В таблице ниже объясняется назначение каждой политики по умолчанию.

Имя политики	Характер использования
Hgs_SecureBootEnabled	Требует, чтобы узлы включили безопасную загрузку. Это необходимо для измерения двоичных файлов запуска и других параметров, заблокированных UEFI.
Hgs_UefiDebugDisabled	Гарантирует, что узлы не включены отладчик ядра. Отладчики пользовательского режима блокируются политиками целостности кода.
Hgs_SecureBoot Параметры	Отрицательная политика для обеспечения соответствия узлам по крайней мере одного (определяемого администратором) базового уровня доверенного платформенного модуля.
Hgs_CiPolicy	Отрицательная политика, чтобы гарантировать, что узлы используют одну из определяемых администратором политик CI.
Hgs_HypervisorEnforcedCiPolicy	Требует, чтобы политика целостности кода применялась гипервизором. Отключение этой политики ослабляет защиту от атак политики целостности кода в режиме ядра.
Hgs_FullBoot	Гарантирует, что узел не возобновляется из спящего режима или гибернации. Узлы должны быть правильно перезапущены или выключены для передачи этой политики.
Hgs_VsmIdkPresent	Требуется, чтобы безопасность на основе виртуализации выполнялось на узле. IdK представляет ключ, необходимый для шифрования информации, отправляемой обратно в безопасное пространство памяти узла.
Hgs_PageFileEncryptionEnabled	Требует шифрования файлов страниц на узле. Отключение этой политики может привести к раскрытию информации, если незашифрованный файл страницы проверяется для секретов клиента.
Hgs_BitLockerEnabled	Требуется включить BitLocker на узле Hyper-V. Эта политика отключена по умолчанию по соображениям производительности и не рекомендуется включать. Эта политика не имеет отношения к шифрованию экранированных виртуальных машин.
Hgs_IommuEnabled	Требует, чтобы узел использовал устройство IOMMU для предотвращения атак прямого доступа к памяти. Отключение этой политики и использование узлов без включения IOMMU может предоставлять секреты виртуальной машины клиента для прямой атаки памяти.
Hgs_NoHibernation	Требуется отключение гибернации на узле Hyper-V. Отключение этой политики может позволить узлам сохранять экранированную память виртуальной машины в незашифрованном файле гибернации.
Hgs_NoDumps	Требует отключать дампы памяти на узле Hyper-V. Если эта политика отключена, рекомендуется настроить шифрование дампа, чтобы предотвратить сохранение экранированных памяти виртуальной машины в незашифрованных файлах аварийного дампа.
Hgs_DumpEncryption	Требуется дампы памяти, если они включены на узле Hyper-V, чтобы шифроваться с помощью ключа шифрования, доверенного HGS. Эта политика не применяется, если дампы не включены на узле. Если эта политика и Hgs_NoDumps отключены, экранированная память виртуальной машины может быть сохранена в незашифрованном файле дампа.
Hgs_DumpEncryptionKey	Отрицательная политика, чтобы узлы, настроенные для разрешения дампов памяти, использовали ключ шифрования файлов дампа, определенный администратором, известный HGS. Эта политика не применяется при отключении Hgs_DumpEncryption .

Авторизация новых защищенных узлов

Чтобы авторизовать новый узел, чтобы стать защищенным узлом (например, успешное подтверждение), HGS должен доверять узлу и (при настройке использования аттестации доверенного доверенного платформенного модуля) программного обеспечения, работающего на нем. Действия по авторизации нового узла отличаются в зависимости от режима аттестации, для которого в настоящее время настроено HGS. Чтобы проверка режим аттестации для защищенной структуры, запустите на Get-HgsServer любом узле HGS.

Настройка оборудования

На новом узле Hyper-V убедитесь, что установлен выпуск Windows Server 2016 Datacenter. Windows Server 2016 Standard не может запускать экранированные виртуальные машины в защищенной структуре. Узел может быть установлен с рабочим столом или серверной ядром.

На сервере с рабочим возможностями и серверной ядром необходимо установить роли сервера поддержки Hyper-V и Host Guardian Hyper-V:

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

аттестация Администратор доверенных

Чтобы зарегистрировать новый узел в HGS при использовании аттестации, доверенной администратором, необходимо сначала добавить узел в группу безопасности в домене, к которому он присоединен. Как правило, каждый домен будет иметь одну группу безопасности для защищенных узлов. Если вы уже зарегистрировали эту группу в HGS, необходимо выполнить единственное действие, чтобы перезапустить узел, чтобы обновить членство в группе.

Вы можете проверка, какие группы безопасности являются доверенными HGS, выполнив следующую команду:

Get-HgsAttestationHostGroup

Чтобы зарегистрировать новую группу безопасности в HGS, сначала запишите идентификатор безопасности (SID) группы в домене узла и зарегистрируйте идентификатор безопасности в HGS.

Add-HgsAttestationHostGroup -Name "Contoso Guarded Hosts" -Identifier "S-1-5-21-3623811015-3361044348-30300820-1013"

Инструкции по настройке доверия между доменом узла и HGS доступны в руководстве по развертыванию.

Аттестация доверенного платформенного модуля

При настройке HGS в режиме TPM узлы должны передавать все заблокированные политики и "включенные" политики с префиксом "Hgs_", а также по крайней мере одну базовую конфигурацию доверенного платформенного модуля, идентификатор TPM и политику целостности кода. Каждый раз при добавлении нового узла необходимо зарегистрировать новый идентификатор доверенного платформенного модуля в HGS. Если узел работает с тем же программным обеспечением (и имеет ту же политику целостности кода) и базовый план доверенного платформенного модуля, что и другой узел в вашей среде, вам не нужно добавлять новые политики ci или базовые показатели.

Добавьте идентификатор доверенного платформенного модуля для нового узла на новом узле, выполните следующую команду, чтобы записать идентификатор доверенного платформенного модуля. Обязательно укажите уникальное имя узла, которое поможет вам найти его в HGS. Эти сведения потребуются, если вы удаляете узел или хотите запретить запуск экранированных виртуальных машин в HGS.

(Get-PlatformIdentifier -Name "Host01").InnerXml | Out-File C:\temp\host01.xml -Encoding UTF8

Скопируйте этот файл на сервер HGS, а затем выполните следующую команду, чтобы зарегистрировать узел в HGS.

Add-HgsAttestationTpmHost -Name 'Host01' -Path C:\temp\host01.xml

Добавление нового базового плана доверенного платформенного модуля, если новый узел выполняет новую конфигурацию оборудования или встроенного ПО для вашей среды, может потребоваться создать новый базовый план доверенного платформенного модуля. Для этого выполните следующую команду на узле.

Get-HgsAttestationBaselinePolicy -Path 'C:\temp\hardwareConfig01.tcglog'

Примечание.

Если вы получаете сообщение об ошибке, в котором произошел сбой проверки узла и не будет успешно подтверждено, не беспокойтесь. Это предварительный проверка, чтобы убедиться, что узел может запускать экранированные виртуальные машины, и, вероятно, означает, что вы еще не применили политику целостности кода или другой обязательный параметр. Прочтите сообщение об ошибке, внесите изменения, предложенные им, а затем повторите попытку. Кроме того, вы можете пропустить проверку в это время, добавив -SkipValidation флаг в команду.

Скопируйте базовый план доверенного платформенного модуля на сервер HGS, а затем зарегистрируйте его с помощью следующей команды. Мы рекомендуем использовать соглашение об именовании, которое помогает понять конфигурацию оборудования и встроенного ПО этого класса узла Hyper-V.

Add-HgsAttestationTpmPolicy -Name 'HardwareConfig01' -Path 'C:\temp\hardwareConfig01.tcglog'

Добавление новой политики целостности кода, если вы изменили политику целостности кода, выполняемую на узлах Hyper-V, необходимо зарегистрировать новую политику в HGS, прежде чем эти узлы смогут успешно подтвердить. На эталонном узле, который служит главным образом для доверенных компьютеров Hyper-V в вашей среде, захватывает новую политику CI с помощью New-CIPolicy команды. Мы рекомендуем использовать уровень FilePublisher и резервную версию Хэша для политик CI узла Hyper-V. Сначала следует создать политику 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 командлет для предоставления HGS хэша ключа шифрования дампа. Если вы записываете базовый план доверенного платформенного модуля на узле Hyper-V, настроенном с шифрованием дампа, хэш включается в tcglog и может быть предоставлен командлету Add-HgsAttestationDumpPolicy .

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey01' -Path 'C:\temp\TpmBaselineWithDumpEncryptionKey.tcglog'

Кроме того, можно напрямую предоставить строковое представление хэша командлету.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey02' -PublicKeyHash '<paste your hash here>'

Не забудьте добавить каждый уникальный ключ шифрования дампа в HGS, если вы решили использовать разные ключи в защищенной структуре. Узлы, которые шифруют дампы памяти с ключом, неизвестным HGS, не будут передавать аттестацию.

Дополнительные сведения о настройке шифрования дампа на узлах см. в документации по Hyper-V.

Проверка того, пройдена ли система аттестации

После регистрации необходимых сведений в HGS необходимо проверка, если узел проходит аттестацию. На недавно добавленном узле Hyper-V запустите Set-HgsClientConfiguration и укажите правильные URL-адреса для кластера HGS. Эти URL-адреса можно получить, выполнив на Get-HgsServer любом узле HGS.

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. Когда вы будете готовы к переключению, вы можете предварительно загрузить все артефакты аттестации (политики CI, базовые показатели TPM и идентификаторы TPM) в HGS, продолжая запускать HGS с аттестацией, доверенной администратором. Для этого просто следуйте инструкциям в разделе авторизации нового защищенного узла .

После добавления всех политик в HGS следующим шагом является запуск искусственной аттестации на узлах, чтобы узнать, будут ли они передавать аттестацию в режиме TPM. Это не влияет на текущее рабочее состояние HGS. Приведенные ниже команды должны выполняться на компьютере с доступом ко всем узлам в среде и по крайней мере одному узлу HGS. Если брандмауэр или другие политики безопасности препятствуют этому, этот шаг можно пропустить. По возможности рекомендуется запустить синтетическую аттестацию, чтобы дать вам хорошее представление о том, будет ли режим TPM перевернутый режим, что приведет к простою виртуальных машин.

# 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. Повторно запустите диагностика, пока не получите "pass" от каждого узла, а затем перейдите к изменению режима HGS на TPM.

Для завершения перехода на режим доверенного платформенного модуля требуется всего несколько секунд. Выполните следующую команду на любом узле HGS, чтобы обновить режим аттестации.

Set-HgsServer -TrustTpm

Если возникают проблемы и требуется вернуться в режим Active Directory, это можно сделать, выполнив команду Set-HgsServer -TrustActiveDirectory.

Убедившись, что все работает должным образом, необходимо удалить все доверенные группы узлов Active Directory из HGS и удалить доверие между доменами HGS и структуры. Если вы не доверяете Active Directory, вы рискуете, что кто-то повторно включает доверие и переключает HGS в режим Active Directory, что может позволить ненадежному коду выполняться без проверка на защищенных узлах.

Управление ключами

Решение защищенной структуры использует несколько пар открытых и закрытых ключей для проверки целостности различных компонентов в решении и шифрования секретов клиента. Служба защиты узла настроена как минимум с двумя сертификатами (с открытыми и закрытыми ключами), которые используются для подписывания и шифрования ключей, используемых для запуска экранированных виртуальных машин. Эти ключи должны быть тщательно управляемы. Если закрытый ключ приобретается злоумышленником, он сможет расшифовать все виртуальные машины, работающие в вашей структуре, или настроить отказоустойчивый кластер HGS, который использует более слабые политики аттестации для обхода защиты, которую вы создали. Если во время аварии вы потеряете закрытые ключи и не найдете их в резервной копии, необходимо настроить новую пару ключей и повторно ключи каждой виртуальной машины, чтобы авторизовать новые сертификаты.

В этом разделе рассматриваются общие разделы по управлению ключами, которые помогут вам настроить ключи, чтобы они были функциональными и безопасными.

Добавление новых ключей

Хотя HGS необходимо инициализировать с одним набором ключей, вы можете добавить несколько ключей шифрования и подписывания в HGS. Ниже приведены две наиболее распространенные причины, по которым вы добавите новые ключи в HGS:

Для поддержки сценариев "принести собственный ключ", в которых клиенты копируют свои закрытые ключи в аппаратный модуль безопасности и разрешают запуск экранированных виртуальных машин.
Чтобы заменить существующие ключи для HGS, сначала добавив новые ключи и сохраняя оба набора ключей, пока каждая конфигурация виртуальной машины не будет обновлена, чтобы использовать новые ключи.

Процесс добавления новых ключей отличается в зависимости от типа используемого сертификата.

Вариант 1. Добавление сертификата, хранящегося в HSM

Наш рекомендуемый подход к защите ключей HGS — использовать сертификаты, созданные в аппаратном модуле безопасности (HSM). Устройства HSM гарантируют использование ключей, привязанных к физическому доступу к устройству с учетом безопасности в центре обработки данных. Каждый HSM отличается и имеет уникальный процесс для создания сертификатов и регистрации их в HGS. Приведенные ниже действия предназначены для предоставления грубого руководства по использованию поддерживаемых сертификатов HSM. Ознакомьтесь с документацией поставщика HSM по точным шагам и возможностям.

Установите программное обеспечение HSM на каждом узле HGS в кластере. В зависимости от наличия сетевого или локального устройства HSM может потребоваться настроить HSM для предоставления компьютеру доступа к хранилищу ключей.
Создание 2 сертификатов в HSM с 2048-разрядными ключами RSA для шифрования и подписывания
1. Создание сертификата шифрования со свойством использования ключа encipherment в HSM
2. Создание сертификата подписи со свойством использования ключа цифровой подписи в HSM
Установите сертификаты в локальном хранилище сертификатов HGS для каждого поставщика HSM.
Если HSM использует детализированные разрешения для предоставления определенным приложениям или пользователям разрешений на использование закрытого ключа, вам потребуется предоставить управляемой учетной записи службы HGS доступ к сертификату. Имя учетной записи GMSA HGS можно найти, выполнив команду (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

Добавьте сертификаты подписи и шифрования в HGS, заменив отпечатки на сертификаты в следующих командах:

Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA"

Вариант 2. Добавление не экспортируемых сертификатов программного обеспечения

Если у вас есть сертификат с поддержкой программного обеспечения, выданный организацией или общедоступным центром сертификации с не экспортируемым закрытым ключом, необходимо добавить сертификат в HGS с помощью отпечатка.

Установите сертификат на компьютере в соответствии с инструкциями центра сертификации.
Предоставьте управляемой учетной записи службы HGS доступ на чтение закрытого ключа сертификата. Имя учетной записи GMSA HGS можно найти, выполнив команду (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName
Зарегистрируйте сертификат с помощью HGS, выполнив следующую команду и подставив отпечаток сертификата (измените шифрование на подписывание сертификатов):
```
Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
```

Внимание

Необходимо вручную установить закрытый ключ и предоставить доступ на чтение учетной записи gMSA на каждом узле HGS. HGS не может автоматически реплика te закрытые ключи для любого сертификата, зарегистрированного его отпечатком.

Вариант 3. Добавление сертификатов, хранящихся в PFX-файлах

Если у вас есть сертификат с поддержкой программного обеспечения с экспортируемым закрытым ключом, который может храниться в формате PFX-файла и защищенном паролем, HGS может автоматически управлять вашими сертификатами. Сертификаты, добавленные с помощью PFX-файлов, автоматически реплика с каждым узлом кластера HGS и HGS защищает доступ к закрытым ключам. Чтобы добавить новый сертификат с помощью PFX-файла, выполните следующие команды на любом узле HGS (измените шифрование на подпись для подписывания сертификатов):

$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 не указывает на слабость или потерю защиты экранированных виртуальных машин. Кроме того, проверка отзыва сертификатов не выполняются HGS. Если сертификат HGS или сертификат выдающего центра отзывается, он не повлияет на использование сертификата HGS.

Единственный раз, когда вам нужно беспокоиться о сертификате HGS, если у вас есть основания полагать, что его закрытый ключ был украден. В этом случае целостность экранированных виртуальных машин находится под угрозой, так как хранение частной половины шифрования HGS и пары ключей подписывания достаточно, чтобы удалить защиту экранирования на виртуальной машине или встать на поддельный сервер HGS, имеющий более слабые политики аттестации.

Если вы находитесь в этой ситуации или требуются стандартами соответствия для регулярного обновления ключей сертификатов, в следующих шагах описан процесс изменения ключей на сервере HGS. Обратите внимание, что следующее руководство представляет собой значительное предприятие, которое приведет к нарушению работы каждой виртуальной машины, обслуживаемой кластером HGS. Необходимо правильное планирование изменения ключей HGS для минимизации нарушений работы службы и обеспечения безопасности виртуальных машин клиента.

На узле 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, будет использовать новые сертификаты, но существующие виртуальные машины будут продолжать работать, так как старые сертификаты по-прежнему существуют.

Чтобы убедиться, что все существующие виртуальные машины будут работать с новыми ключами, необходимо обновить средство защиты ключей на каждой виртуальной машине.

Это действие, которое требует, чтобы владелец виртуальной машины (лицо или сущность в распоряжении "владельца" опекуна) был вовлечен. Для каждой экранированной виртуальной машины выполните следующие действия.

Выключите виртуальную машину. Виртуальная машина не может быть включена до тех пор, пока оставшиеся шаги не будут завершены или вам потребуется снова запустить процесс.
Сохраните текущий предохранитель ключей в файл: Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp'
Передача ключевого показателя эффективности владельцу виртуальной машины
Загрузите владельцу обновленные данные защиты из HGS и импортируйте его в локальную систему.
Прочитайте текущий ключевой показатель эффективности в память, предоставьте новому опекуну доступ к ключевому показателю эффективности и сохраните его в новом файле, выполнив следующие команды:
```
$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
```
Скопируйте обновленный ключевой показатель эффективности обратно в структуру размещения.
Примените ключевой показатель эффективности к исходной виртуальной машине:
```
$updatedKP = Get-Content -Path .\updatedVM001.kp
Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP
```
Наконец, запустите виртуальную машину и убедитесь, что она успешно выполняется.

Примечание.

Если владелец виртуальной машины задает неверный защищенный ключ на виртуальной машине и не авторизует структуру для запуска виртуальной машины, вы не сможете запустить экранированную виртуальную машину. Чтобы вернуться к последнему известному надежному защитнику ключей, выполните команду Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector

После обновления всех виртуальных машин для авторизации новых ключей защиты можно отключить и удалить старые ключи.
Получение отпечатков старых сертификатов из Get-HgsKeyProtectionCertificate -IsPrimary $false

Отключите каждый сертификат, выполнив следующие команды:

Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsEnabled $false
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsEnabled $false

После того как виртуальные машины по-прежнему смогут начать работу с отключенными сертификатами, удалите сертификаты из HGS, выполнив следующие команды:
```
Remove-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>`
Remove-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>`
```

Внимание

Резервные копии виртуальных машин будут содержать старые сведения о защите ключей, которые позволяют использовать старые сертификаты для запуска виртуальной машины. Если вы знаете, что закрытый ключ скомпрометирован, следует предположить, что резервные копии виртуальных машин также могут быть скомпрометированы и принять соответствующие меры. При уничтожении конфигурации виртуальной машины из резервных копий (VMCX) будут удалены средства защиты ключей за счет необходимости использовать пароль восстановления BitLocker для загрузки виртуальной машины в следующий раз.

Реплика ключ между узлами

Каждый узел в кластере HGS должен быть настроен с одинаковым шифрованием, подписью и (при настройке) SSL-сертификатов. Это необходимо, чтобы узлы Hyper-V, поступающие к любому узлу в кластере, могли успешно обслуживать свои запросы.

Если вы инициализировали сервер HGS с сертификатами на основе PFX, HGS автоматически реплика te как открытый, так и закрытый ключ этих сертификатов на каждом узле в кластере. Необходимо добавить ключи только на одном узле.

Если вы инициализировали сервер HGS со ссылками на сертификаты или отпечатки, HGS будет реплика использовать открытыйключ в сертификате на каждом узле. Кроме того, HGS не может предоставить себе доступ к закрытому ключу на любом узле в этом сценарии. Таким образом, вы несете ответственность за:

Установка закрытого ключа на каждом узле HGS
Предоставьте группе HGS доступ к управляемой учетной записи службы (gMSA) к закрытому ключу на каждом узле Эти задачи добавляют дополнительную рабочую нагрузку, однако они необходимы для ключей и сертификатов с поддержкой HSM с не экспортируемыми закрытыми ключами.

SSL-сертификаты никогда не реплика в любой форме. Вы несете ответственность за инициализацию каждого сервера HGS с одинаковым SSL-сертификатом и обновление каждого сервера при каждом обновлении или замене SSL-сертификата. При замене SSL-сертификата рекомендуется использовать командлет Set-HgsServer .

Отмена настройки HGS

Если необходимо удалить или значительно перенастроить сервер HGS, это можно сделать с помощью командлетов Clear-HgsServer или Uninstall-HgsServer .

Очистка конфигурации HGS

Чтобы удалить узел из кластера HGS, используйте командлет Clear-HgsServer . Этот командлет вносит следующие изменения на сервере, на котором выполняется:

Отменяет регистрацию служб аттестации и защиты ключей
Удаляет конечную точку управления JEA microsoft.windows.hgs
Удаляет локальный компьютер из отказоустойчивого кластера HGS

Если сервер является последним узлом HGS в кластере, кластер и соответствующий ресурс имени распределенной сети также будут уничтожены.

# Removes the local computer from the HGS cluster
Clear-HgsServer

После завершения операции очистки сервер HGS можно повторно инициализировать с помощью Initialize-HgsServer. Если вы использовали Install-HgsServer для настройки домена служб домен Active Directory, этот домен будет оставаться настроенным и операционным после операции очистки.

Удаление HGS

Если вы хотите удалить узел из кластера HGS и понизить на него контроллер домен Active Directory, используйте командлет Remove-HgsServer. Этот командлет вносит следующие изменения на сервере, на котором выполняется:

Отменяет регистрацию служб аттестации и защиты ключей
Удаляет конечную точку управления JEA microsoft.windows.hgs
Удаляет локальный компьютер из отказоустойчивого кластера 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

После завершения операции удаления и перезапуска компьютера можно переустановить ADDC и HGS с помощью Install-HgsServer или присоединить компьютер к домену и инициализировать сервер HGS в этом домене с помощью Initialize-HgsServer.

Если вы больше не планируете использовать компьютер в качестве узла HGS, вы можете удалить роль из Windows.

Uninstall-WindowsFeature HostGuardianServiceRole

Управление службой защиты узла

Ограничение доступа администратора к HGS

Разделение обязанностей

Использование just Enough Администратор istration

Мониторинг HGS

Источники событий и переадресация

Использование System Center Operations Manager

Резервное копирование и восстановление HGS

План аварийного восстановления

Подготовка к худшему

Восстановление после потери одного узла

Восстановление после потери всего кластера

Резервное копирование HGS

Восстановление HGS из резервной копии

Настройка замены кластера HGS

Импорт параметров из резервной копии

Переустановка закрытых ключей для сертификатов

Проверка импортированных политик аттестации

Запуск диагностика для проверка состояния системы

Исправление HGS

Обновления требуется активация политики

Управление политиками аттестации

Политики по умолчанию

Авторизация новых защищенных узлов

Настройка оборудования

аттестация Администратор доверенных

Аттестация доверенного платформенного модуля

Проверка того, пройдена ли система аттестации

Проверка политик аттестации

Изменение режимов аттестации

Управление ключами

Добавление новых ключей

Продление или замена ключей

Реплика ключ между узлами

Отмена настройки HGS

Очистка конфигурации HGS

Удаление HGS

Дополнительные ресурсы