Shielded VMs для облачного хостинга: тест на практике, кому это нужно и какова цена

В ноябре мы первый раз подняли Shielded VMs в тестовой лаборатории - разобрались с Host Guardian Service, сделали первую защищённую виртуалку, сформулировали первые вопросы. Тогда угол был скорее «что это и как работает». Сейчас прошли второй круг, уже с конкретным прицелом: подходит ли эта механика для управляемого хостинга, когда клиент хочет, чтобы его данные были недоступны даже нашим администраторам.

Спойлер: подходит, но цена вопроса по сложности - ощутимая.

Что вообще даёт Shielded VM

Коротко, чтобы не повторять ноябрьский пост: защищённая виртуалка запускается только на «одобренных» хостах, диск зашифрован BitLocker через vTPM, ключи от vTPM хранит Host Guardian Service (HGS). Администратор Hyper-V видит, что VM запущена, но не может подключить диск напрямую, прочитать память или снять снапшот с содержимым.

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

Тестовый сценарий: управляемый хостинг с изоляцией

Собрали стенд, максимально близкий к реальному использованию: два физических сервера с WS2016 Datacenter, отдельная машина под HGS, всё в одной сети. Взяли AD-аттестацию - TPM-аттестация в полном виде требует физических TPM 2.0 на всех хостах, что не у каждого клиента есть, и это отдельный разговор.

Задача для теста: клиентская виртуалка с PostgreSQL и данными. Клиент сам создаёт Shielding Data File (PDK) - зашифрованный пакет с параметрами VM, который мы разворачиваем вслепую. После развёртывания клиент подключается по RDP, проверяет, что всё работает. Мы как провайдер должны не иметь доступа к содержимому диска.

Развёртывание прошло как задумано: PDK применён, VM запущена, BitLocker активен внутри гостя, клиент зашёл и видит свои данные. Мы со стороны хоста видим запущенный процесс с именем виртуалки - и ничего больше. Диск не монтируется без ключей от HGS, которых у нас нет.

Технически работает. Теперь про операционную сторону.

Где это ощутимо дорого

HGS как критическая точка отказа. Это самый неприятный момент. Если HGS недоступен - ни одна Shielded VM не запустится после рестарта. Зависание питания, техобслуживание, патч с перезагрузкой HGS-серверов - и клиентские VM стоят, пока HGS не вернётся. На практике это означает кластер HGS минимум из двух нод, собственный мониторинг с приоритетом, отдельная процедура восстановления.

В тесте мы специально отключили HGS посередине сессии - работающая VM продолжала работать, это нормально. Но при следующем рестарте хоста она не поднялась до тех пор, пока HGS не стал доступен. Для управляемого хостинга это требует выстроить SLA вокруг HGS отдельно от всего остального.

Процесс создания шаблонов. Клиент не может просто поставить произвольную ISO и развернуть VM как обычно. Нужен подписанный шаблон диска, прошедший через подготовку. Это процедура: sysprep, специализированный образ, подпись через PowerShell. Для клиентов, которые привыкли самостоятельно разворачивать VM из произвольных образов - смена привычки.

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

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

Кому это реально нужно

Мы прошли несколько сценариев и честно говорим: для большинства клиентов это избыточно.

Финансовые и медицинские данные в аутсорсинге. Клиент хочет передать инфраструктуру на обслуживание, но данные - например, базы с персональными данными или финансовые транзакции - не должны быть доступны провайдеру даже теоретически. Shielded VMs дают архитектурную гарантию, а не просто NDA. Это разные вещи.

Государственные контракты с требованием разделения доступа. Если в техническом задании явно прописано разделение прав между оператором инфраструктуры и владельцем данных - это может быть именно та механика.

Мультитенантная инфраструктура с параноидальными клиентами. Один из наших потенциальных клиентов прямо спросил: «вы можете технически гарантировать, что не имеете доступа к нашим данным, даже если захотите?». Shielded VMs - один из немногих ответов на этот вопрос с технической подложкой.

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

Что мы вынесли

Shielded VMs - архитектурное решение, которое нельзя добавить поверх существующей инфраструктуры «одним скриптом». Это меняет процессы: создание шаблонов, развёртывание VM, управление HGS, мониторинг, восстановление после отказа. Если принять это изменение осознанно и спроектировать инфраструктуру вокруг него с нуля - работает и закрывает реальную задачу.

Для сценария «несколько клиентов с требованием криптографической изоляции данных» мы видим смысл в отдельном выделенном кластере под Shielded VMs - со своим HGS, своей процедурой онбординга клиентов и отдельным SLA. Смешивать Shielded и обычные VM в одном пуле управления - источник операционных ошибок.

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