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

• Применяется к:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

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

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

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

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

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

   Если ваша цель заключается в защите виртуальных машин от вредоносных администраторов или скомпрометированной инфраструктуры, то вы будете использовать аттестацию, доверенную модулем TPM. Этот вариант хорошо подходит для сценариев размещения с несколькими клиентами, а также для ресурсов с высоким уровнем ценности в корпоративных средах, таких как контроллеры домена или серверы содержимого, такие как 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. Этот параметр подходит для хостеров, которые могут предоставить внеканальный процесс, позволяющий клиентам загружать свои ключи.
Хранилище ключей службы Host Guardian	Для обеспечения максимальной безопасности рекомендуется создавать и хранить ключи HGS исключительно в аппаратном модуле безопасности (HSM). Если вы не используете виртуальные машины HSM, настоятельно рекомендуется применить BitLocker на серверах HGS.

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

Площадь	Сведения
Оборудование	Аттестация ключа хоста: вы можете использовать любое существующее оборудование в качестве защищенного хоста. Существует несколько исключений (чтобы убедиться, что хост может использовать новые механизмы безопасности начиная с Windows Server 2016, см. статью Совместимое оборудование с Windows Server 2016 на базе виртуализации для защиты целостности кода). Аттестация с доверенным TPM: Вы можете использовать любое оборудование, имеющее дополнительную квалификацию 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, работающий в филиале, нуждается в подключении к службе защиты узлов для включения или динамической миграции экранированных виртуальных машин. Дополнительные сведения см. в рекомендациях по филиалам.