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

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

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

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

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

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

Тестовый сценарий: managed-хостинг с изоляцией

Собрали стенд, максимально близкий к реальному использованию: два физических сервера с 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 не стал доступен. Для managed-хостинга это требует выстроить 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 - один из немногих ответов на этот вопрос с технической подложкой.

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

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

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

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

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