Hyper-V WS2019: Shielded VM с упрощённым HGS и LAPS против lateral movement

Когда строишь managed-инфраструктуру на новом кластере, момент «а что с безопасностью гипервизора» приходит не сразу. Обычно сначала: ноды, сеть, хранилище, первые VM. А потом кто-нибудь задаёт вопрос про изоляцию гостей от администраторов Hyper-V, и выясняется, что в WS2016 ответ на этот вопрос требовал изрядных усилий. В WS2019 стало заметно легче - и именно это мы проверили в новом кластере на этой неделе.

Что такое Shielded VM и почему это вообще тема

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

Shielded VM шифрует диск виртуальной машины через BitLocker, привязывает запуск к аттестации хоста через Host Guardian Service, и не даёт запустить VM на хосте, который не прошёл проверку. Администратор Hyper-V не может просто так подключить диск и посмотреть что там - ключи шифрования доступны только через HGS, а HGS выдаёт их только проверенным хостам.

В WS2016 это работало, но развернуть было больно. HGS требовал отдельного домена Active Directory - отдельного леса, без federation с production AD. Отдельный лес означал отдельные DC, отдельное управление, отдельная точка сложности. Для небольших инфраструктур это было ощутимо избыточно, и часть клиентов от Shielded VM отказывалась именно из-за этого порога.

Что изменилось в WS2019

В WS2019 появился режим развёртывания HGS без выделенного леса AD - HGS может работать в существующем домене. Это не просто упрощение деплоя: это снятие главного организационного барьера для сред, где Shielded VM нужен, но поднимать дополнительный лес не было ни времени, ни ресурсов.

Ещё одно изменение - поддержка аттестации на основе TPM 2.0 стала стандартной, а режим Admin-trusted attestation (где доверие к хосту основывалось на членстве в группе AD) сохранился, но TPM-путь теперь документируется как основной. Для нашего кластера - железо с TPM 2.0 - это оказалось чище: аттестация привязана к конкретному железу, а не к управляемой записи в AD.

Как разворачивали

Кластер - три ноды WS2019 Datacenter, железо с TPM 2.0, Hyper-V настроен. HGS поставили на отдельную VM в том же домене - не отдельный лес, именно то что изменилось в 2019.

# На HGS-сервере
Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools
Initialize-HgsServer -HgsServiceName 'hgs' -TrustTpm

Регистрация хостов через TPM-аттестацию: собрали TPM endorsement key и platform identifier с каждой ноды, зарегистрировали в HGS. Baseline конфигурации хоста - через Measured Boot: HGS запоминает корректное состояние загрузки, и если что-то изменилось - аттестация не пройдёт.

Создание Shielded VM потребовало shielding data file - архив с настройками, ключами и RDP-сертификатом, который определяет кому разрешено использовать VM. Это немного непривычный workflow если не делал раньше: VM создаётся через шаблон, shielding data подставляется в момент деплоя и запечатывает машину. Никакой возможности подключиться к консоли Hyper-V после этого - только через RDP или WinRM из гостевой ОС.

На тест взяли два сценария. Первый: попытка подключить диск Shielded VM к обычной VM. Диск монтируется, но данные зашифрованы - без ключей из HGS читать нечего. Второй: снести один из HGS-узлов (для отказоустойчивости поставили два) - VM продолжают работать на аттестованных хостах.

Итого развёртывание HGS с нуля до первой рабочей Shielded VM заняло день, включая возню с документацией. В WS2016 мы делали это однажды на пилоте - там только настройка отдельного леса AD занимала столько же.

LAPS: вторая часть задачи

Shielded VM защищает данные от администратора гипервизора. Но есть другая проблема, которая с этим не пересекается - lateral movement через локальные administrator-аккаунты.

Типичная ситуация: десяток гостевых Windows Server, у всех локальный Administrator с одним и тем же паролем. Пароль задали при создании шаблона, забыли что он одинаковый. Или не забыли, но «потом поменяем». Если атакующий получил этот пароль на одной машине - он получил его на всех. Классика.

Local Administrator Password Solution (LAPS) решает это в лоб: агент на каждой VM генерирует случайный пароль локального Administrator, ротирует его по расписанию и хранит в атрибуте объекта компьютера в AD. Читать этот атрибут могут только те, кому дана явная делегация. Никаких общих паролей - у каждой машины свой, и он меняется.

Развернули на всех гостевых VM в кластере:

• Схема AD - расширили, добавили атрибуты для LAPS. Разовая операция на весь лес, обратно несовместима в смысле схемы, но на практике никто не откатывает.
• GPO - политика для OU с гостевыми VM: включить LAPS, длина пароля, срок ротации. Поставили 30 дней и длину 24 символа.
• Клиентский MSI - развернули через GPO на все гостевые VM. После первого цикла обновления политик каждая машина установила агент и сгенерировала пароль.
• Делегация - кто может читать пароли: выделенная группа AD для helpdesk с явным ограничением на конкретные OU. Не «все Domain Admins», а конкретная роль.

Проверка: зашли в AD, прочитали пароль конкретной VM через LAPS UI (есть простой GUI от Microsoft) - работает. Попробовали с аккаунтом без делегации - атрибут пустой. Ротация - подождали принудительного обновления политики, пароль сменился, старый перестал работать.

Что в итоге

Связка Shielded VM + LAPS закрывает два разных вектора атаки в виртуальной среде: доступ к данным через гипервизор и lateral movement через общие локальные пароли. Ни то, ни другое не экзотика - оба вектора встречаются в реальных расследованиях.

WS2019 сделал Shielded VM достаточно доступным чтобы ставить его на средние кластеры без специальных усилий. LAPS как инструмент существует давно, но встречается далеко не везде - часто просто не доходят руки. Теперь у нас есть стандартный порядок развёртывания для обоих компонентов, и в следующих проектах это уже не будет занимать целый день на изучение.

Один открытый вопрос - ротация паролей сервисных аккаунтов. LAPS закрывает только локального Administrator, сервисные аккаунты с фиксированными паролями остались за бортом. Это отдельная задача, там другие инструменты.