Руководство по планированию защищенных виртуальных машин и экранированных виртуальных машин для хост-приложений

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

В этом разделе рассматриваются решения по планированию, которые необходимо принять для включения экранированных виртуальных машин для работы в структуре. Независимо от того, обновляете существующую структуру Hyper-V или создаете новую структуру, выполняя экранированные виртуальные машины, состоят из двух основных компонентов:

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

Решение #1. Уровень доверия в структуре

Как вы реализуете службу защиты узла и защищенные узлы Hyper-V будут зависеть главным образом от силы доверия, которую вы хотите достичь в вашей структуре. Сила доверия регулируется режимом аттестации. Существует два взаимоисключающих варианта:

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

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

2. Аттестация ключа узла

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

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

   Однако отладчики, пытающиеся подключиться непосредственно к процессу (например, WinDbg.exe), блокируются для экранированных виртуальных машин, так как рабочий процесс виртуальной машины (VMWP.exe) является защищенным светом процесса (PPL). Альтернативные методы отладки, такие как те, которые используются LiveKd.exe, не блокируются. В отличие от экранированных виртуальных машин рабочий процесс для шифрования поддерживаемых виртуальных машин не выполняется как PPL, поэтому традиционные отладчики, такие как WinDbg.exe будут продолжать работать нормально.

   Аналогичный режим аттестации с именем Администратор доверенной аттестации (на основе Active Directory) устарел, начиная с Windows Server 2019.

Выбранный уровень доверия будет диктовать требования к оборудованию для узлов Hyper-V, а также политики, применяемые в структуре. При необходимости можно развернуть защищенную структуру с помощью существующего оборудования и доверенной аттестации администратора, а затем преобразовать ее в доверенное аттестацию TPM при обновлении оборудования и укрепить безопасность структуры.

Решение 2. Существующая структура Hyper-V и новая отдельная структура Hyper-V

Если у вас есть существующая структура (Hyper-V или в противном случае), скорее всего, вы можете использовать ее для запуска экранированных виртуальных машин вместе с обычными виртуальными машинами. Некоторые клиенты предпочитают интегрировать экранированные виртуальные машины в существующие инструменты и структуры, а другие отделяют структуру по бизнес-причинам.

Планирование администратора HGS для службы защиты узлов

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

Площадь	Сведения
Требования для установки	Один сервер (кластер с тремя узлами рекомендуется для обеспечения высокой доступности) Для резервного восстановления требуются по крайней мере два сервера HGS Серверы могут быть виртуальными или физическими (рекомендуется использовать физический сервер с TPM 2.0; TPM 1.2 также поддерживается) Установка основных серверных компонентов Windows Server 2016 или более поздней версии Сетевая линия видимости структуры, разрешающая конфигурацию HTTP или резервной конфигурации Сертификат HTTPS, рекомендуемый для проверки доступа
Определение параметров	Каждый узел сервера HGS среднего размера (8 ядер/4 ГБ) может обрабатывать 1000 узлов Hyper-V.
Управление	Назначьте определенных пользователей, которые будут управлять HGS. Они должны быть отделены от администраторов структуры. Для сравнения кластеры HGS можно рассматривать так же, как центр сертификации (ЦС) с точки зрения административной изоляции, физического развертывания и общего уровня конфиденциальности безопасности.
Служба защиты узла Active Directory	По умолчанию HGS устанавливает собственный внутренний Active Directory для управления. Это автономный самоуправляемый лес и рекомендуемая конфигурация для изоляции HGS от структуры. Если у вас уже есть лес Active Directory с высоким уровнем привилегий, используемый для изоляции, вы можете использовать этот лес вместо леса по умолчанию HGS. Важно, чтобы HGS не присоединялись к домену в том же лесу, что и узлы Hyper-V или средства управления структурами. Это может позволить администратору структуры получить контроль над HGS.
Аварийное восстановление	Доступно три параметра: Установите отдельный кластер HGS в каждом центре обработки данных и авторизуйте экранированные виртуальные машины для запуска как в основном, так и в центрах резервного копирования. Это позволяет избежать необходимости растяжения кластера по глобальной сети и позволяет изолировать виртуальные машины таким образом, чтобы они выполнялись только на указанном сайте. Установите HGS в растянутом кластере между двумя (или более) центрами обработки данных. Это обеспечивает устойчивость, если глобальная сеть снижается, но отправляет ограничения на отработку отказа кластеризация. Вы не можете изолировать рабочие нагрузки на одном сайте; Виртуальная машина, авторизованная для запуска на одном сайте, может выполняться на любом другом сайте. Зарегистрируйте узел Hyper-V в другом HGS в качестве отработки отказа. Кроме того, необходимо создать резервную копию каждого HGS, экспортируя его конфигурацию, чтобы всегда можно было восстановить локально. Дополнительные сведения см. в разделе Export-HgsServerState и Import-HgsServerState.
Ключи службы защиты узла	Служба защиты узла использует две пары асимметричных ключей — ключ шифрования и ключ подписи — каждый из которых представлен SSL-сертификатом. Существует два варианта создания этих ключей: Внутренний центр сертификации — эти ключи можно создать с помощью внутренней инфраструктуры PKI. Это подходит для среды центра обработки данных. Общедоступные доверенные центры сертификации — используйте набор ключей, полученных из общедоступного доверенного центра сертификации. Это параметр, который должны использовать хост-серверы. Обратите внимание, что хотя можно использовать самозаверяющие сертификаты, не рекомендуется использовать сценарии развертывания, отличные от лабораторий проверки концепции. Помимо использования ключей HGS, ведущий может использовать "принести собственный ключ", где клиенты могут предоставлять собственные ключи, чтобы некоторые (или все) клиенты могли иметь собственный ключ HGS. Этот параметр подходит для хост-администраторов, которые могут предоставлять внеполновый процесс для клиентов для отправки ключей.
Хранилище ключей службы защиты узла	Для обеспечения максимальной безопасности рекомендуется создавать и хранить ключи HGS исключительно в аппаратном модуле безопасности (HSM). Если вы не используете виртуальные машины HSM, настоятельно рекомендуется применить BitLocker на серверах HGS.

Планирование администраторов Структуры для защищенных узлов

Площадь	Сведения
Оборудование	Аттестация ключей узла: вы можете использовать любое существующее оборудование в качестве защищенного узла. Существует несколько исключений (чтобы убедиться, что узел может использовать новые механизмы безопасности, начиная с Windows Server 2016, см. статью "Совместимое оборудование с windows Server 2016 Virtualization на основе защиты целостности кода". Аттестация доверенного платформенного модуля. Вы можете использовать любое оборудование, которое имеет дополнительную квалификацию Hardware Assurance, если оно настроено соответствующим образом (см . конфигурации сервера, соответствующие экранированных виртуальным машинам и защите целостности кода на основе виртуализации для конкретной конфигурации). К ним относятся TPM 2.0 и UEFI версии 2.3.1c и выше.
ОС	Рекомендуется использовать параметр Server Core для ОС узла Hyper-V.
Влияние на производительность	На основе тестирования производительности мы ожидаем примерно 5% разницы плотности между запуском экранированных виртуальных машин и не экранированных виртуальных машин. Это означает, что если заданный узел Hyper-V может запускать 20 не экранированных виртуальных машин, мы ожидаем, что он может запускать 19 экранированных виртуальных машин. Обязательно проверьте размер с помощью типичных рабочих нагрузок. Например, могут возникнуть некоторые выбросы с интенсивными рабочими нагрузками ввода-вывода, ориентированными на запись, которые будут дополнительно влиять на разницу плотности.
Рекомендации для филиалов	Начиная с Windows Server версии 1709, можно указать резервный URL-адрес для виртуализированного сервера HGS, работающего локально как экранированная виртуальная машина в филиале. Резервный URL-адрес можно использовать, когда филиал теряет подключение к серверам HGS в центре обработки данных. В предыдущих версиях Windows Server узел Hyper-V, работающий в филиале, нуждается в подключении к службе защиты узлов для включения или динамической миграции экранированных виртуальных машин. Дополнительные сведения см. в рекомендациях по филиалам.