Shielded VMs в Windows Server 2016: защита виртуалки от привилегированного инсайдера

На прошлой неделе разворачивали тестовый стенд с Shielded VMs - одной из фич Windows Server 2016, о которой на Ignite говорили много, но на которую в реальных задачах мы добрались только сейчас. Концепция интересная, реализация требует планирования, впечатления - смешанные в хорошем смысле.

Зачем это вообще нужно

Стандартная модель угроз для виртуальной инфраструктуры выглядит примерно так: вы доверяете гипервизору. Если хост скомпрометирован - администратор Hyper-V или злоумышленник с доступом к хост-машине может подключить диск виртуалки, прочитать память, снять снапшот и унести данные. Шифрование на уровне самой виртуалки (например, BitLocker внутри гостя) тут не помогает: ключи всё равно хранятся там же, а при живом доступе к хосту их можно извлечь.

Shielded VMs решают именно эту задачу - защиту виртуальной машины от привилегированного инсайдера или скомпрометированного хост-узла. Ключевая идея: виртуалка работает только на верифицированных хостах, её диск зашифрован BitLocker с ключами через vTPM, и даже Hyper-V-администратор не может просто так заглянуть внутрь.

Для клиентов из регулируемых отраслей - банки, медицина, государственные контракты - это звучит актуально. Не потому что сейчас идёт массовая атака через привилегированный доступ к гипервизору, а потому что модель угроз меняется: инсайдер становится отдельным вектором в корпоративной безопасности.

Как это работает

Ключевой компонент - Host Guardian Service (HGS). Это отдельная роль Windows Server, которая выступает доверенным арбитром: она решает, какие хосты считаются «здоровыми» (guarded hosts), и только таким хостам выдаёт ключи для запуска защищённых виртуалок.

Упрощённая схема:

[Shielded VM] <-> [Guarded Host] <-> [Host Guardian Service]
                        |                     |
                   аттестация          выдача ключей

Аттестация работает в двух режимах. TPM-аттестация - строгая: хост измеряет свою конфигурацию через физический TPM-чип (UEFI, Secure Boot, загрузчик), HGS сверяет с эталонными значениями. AD-аттестация - проще: принадлежность к нужной группе Active Directory как признак «доверенности». Второй режим существенно слабее по безопасности, но проще в развёртывании и используется для тестовых сред.

vTPM для виртуальной машины - программный TPM, который видит гостевая ОС как обычный чип. BitLocker внутри виртуалки берёт ключ из vTPM. Ключи vTPM зашифрованы HGS. Цепочка: без HGS хост не получит ключи vTPM, без них BitLocker не откроет диск, виртуалка не загрузится.

Что пришлось настроить

Стенд собирали на двух физических серверах с WS2016 Datacenter. Один - под HGS (выделенный лес AD, отдельная роль), второй - Hyper-V guarded host.

HGS требует отдельного леса AD. Это не рекомендация - это требование. HGS поднимается в изолированном домене, и это правильно: если корпоративный AD скомпрометирован, HGS должен остаться под отдельным контролем. На практике это означает ещё одну пару DC, ещё один домен в схеме, ещё одна точка управления. Для небольших инфраструктур - ощутимый overhead.

# Установка HGS
Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools

# Инициализация нового леса HGS
Install-HgsServer -HgsDomainName "hgs.internal" -SafeModeAdministratorPassword $securePassword

# Инициализация HGS с AD-аттестацией (для теста)
Initialize-HgsServer -HgsServiceName "hgs" -SigningCertificateThumbprint $sigCert `
    -EncryptionCertificateThumbprint $encCert -TrustActiveDirectory

На стороне Hyper-V-хоста нужно установить его как guarded host и прописать HGS:

Set-HgsClientConfiguration -AttestationServerUrl "https://hgs.internal/Attestation" `
    -KeyProtectionServerUrl "https://hgs.internal/KeyProtection"

После успешной аттестации хост получает статус «guarded» и может запускать Shielded VMs.

Shielding Data File (PDK). Это зашифрованный файл, который содержит параметры развёртывания виртуалки: пароль администратора, RDP-сертификат, список хостов-владельцев. Создаётся владельцем виртуалки - не Hyper-V-администратором. PDK передаётся вместе с шаблоном виртуалки, и хост разворачивает VM без доступа к её содержимому.

Концепция интересная: администратор инфраструктуры видит, что VM запущена, но не видит, что внутри. Это разделение ролей на уровне архитектуры, а не политики.

Где споткнулись

Время аттестации. При каждом старте VM хост проходит аттестацию в HGS. Если HGS недоступен - guarded host не запускает Shielded VMs. Вообще. Это означает, что HGS - критический компонент инфраструктуры, который нужна высокая доступность. Два HGS-сервера минимум, и они должны быть живы при каждом рестарте виртуалок. Для инфраструктуры с одним HGS это неприятная точка отказа.

Шаблоны VM. Shielded VM нельзя создать «с нуля» в обычном смысле - нужен подписанный шаблон диска. Процесс подготовки шаблона отдельный: создать образ, запечатать через sysprep, добавить специализированный диск через New-ShieldingDataFile. Это не сложно, но требует дисциплины: каждый новый шаблон - отдельная процедура.

TPM-аттестация в тестовом стенде. У нас не было физического TPM на обоих серверах в нужной конфигурации, пришлось работать с AD-аттестацией. Для production с реальными требованиями по безопасности это компромисс - AD-аттестация не даёт гарантий на уровне железа. TPM 2.0 и UEFI Secure Boot - реальные требования для строгого режима.

Для кого это реально актуально

Shielded VMs не для всех. Overhead на инфраструктуру (HGS, отдельный лес, аттестация) оправдан в конкретных сценариях:

• Мультитенантный хостинг - когда несколько клиентов на одном физическом железе и нужна гарантия изоляции даже от провайдера.
• Регуляторные требования - когда модель угроз явно включает привилегированного инсайдера (финансы, гос-сектор, персональные данные по 152-ФЗ).
• Аутсорсинг инфраструктуры - клиент хочет размещать данные у нас, но не хочет давать нам доступ к содержимому VM.

Последний сценарий - наиболее интересный с точки зрения managed-инфраструктуры. Клиент получает управляемую инфраструктуру, мы берём на себя эксплуатацию, но доступ к данным внутри VM остаётся только у клиента. Технически это теперь реализуемо.

Где мы сейчас

Тестовый стенд работает, первая Shielded VM запущена и живёт. Аттестация работает, BitLocker внутри гостя активен, PDK создан и применён - в целом всё сходится с документацией.

Для production-внедрения у конкретного клиента потребуется нормальное железо с TPM 2.0, проектирование отказоустойчивого HGS и отработка процедур создания шаблонов. Это не «поднял за вечер» история - это архитектурное решение, которое нужно включать в проект с самого начала.

Следующий шаг - посмотреть на интеграцию с SCVMM 2016: там есть нативная поддержка управления Shielded VMs, что должно упростить операционную часть. Пока - ручной PowerShell, что для тестирования достаточно.