Secured-Core Server и железо: делаем матрицу совместимости после аудита парка

После выхода Windows Server 2022 GA мы начали разговор с несколькими клиентами про Secured-Core Server. Разговор у большинства шёл примерно одинаково: «звучит хорошо, включим». И вот здесь начинается работа, потому что Secured-Core - это не переключатель в настройках. Это требование к железу, которое либо выполняется, либо нет.

Один из клиентов на managed-сопровождении попросил помочь разобраться, какие из их серверов реально потянут Secured-Core, а какие нет. Парк у них смешанный: несколько волн закупок за последние шесть лет, разные производители, разные поколения. Как раз такой случай, где без инвентаризации не обойтись.

Что Secured-Core требует от железа

Мы уже разбирали требования в посте про GA-релиз, но для задачи аудита важно понимать, какие именно пункты становятся узким местом:

• UEFI Secure Boot - базовое требование, есть почти везде, где нет legacy BIOS.
• TPM 2.0 - не TPM 1.2. Чип часто есть физически, но бывает выключен в UEFI-настройках или числится как 1.2 через firmware downgrade.
• HVCI (Hypervisor-Protected Code Integrity) - требует Intel VT-x или AMD-V с SLAT. На серверах это норма, но в некоторых виртуальных средах нужна вложенная виртуализация.
• Kernel DMA Protection - IOMMU в чипсете (Intel VT-d / AMD-Vi), должен быть активирован в UEFI.
• DRTM (Dynamic Root of Trust for Measurement) - Intel TXT или AMD SKINIT. Вот здесь проблема.

DRTM - это механизм, который позволяет измерить состояние системы в момент загрузки ОС и убедиться, что прошивка не была скомпрометирована до старта. Intel реализует его через Intel TXT (Trusted Execution Technology), AMD - через SKINIT. Требует одновременно: CPU с поддержкой, чипсета с поддержкой, и правильной UEFI-прошивки, которая эту функцию активирует. Все три условия, а не одно из трёх.

Что показал аудит

Инвентаризацию мы начали с PowerShell. Команда Get-ComputerInfo с полями DeviceGuardSecurityServicesConfigured и DeviceGuardSecurityServicesRunning даёт быстрый срез: что настроено и что реально запущено. Расхождение между этими двумя значениями - сигнал, что hardware не поддерживает то, что включено в политике.

Для TPM - Get-Tpm и проверка TpmPresent, TpmReady, TpmActivated. Отдельно смотрим версию: если ManufacturerVersion начинается с 1., это TPM 1.2, Secured-Core не пройдёт.

По итогам аудита серверный парк клиента разбился на три группы:

Группа 1 - всё в порядке. Серверы последних двух-трёх лет, производители первого ряда. HPE Gen10 Plus, Dell PowerEdge последнего поколения. Secured-Core поднялся без доработок, все пять компонентов зелёные. Это меньшая часть парка.

Группа 2 - нужна настройка UEFI. Серверы 2017-2019 года с подходящим железом, но с выключенными функциями в BIOS/UEFI. TPM присутствует, но деактивирован. Intel TXT есть в CPU, но отключён в прошивке. После обновления UEFI до последней версии и включения нужных параметров - Secured-Core поднялся. Занимает время, но это решаемо.

Группа 3 - DRTM не поддерживается. Серверы 2015-2016 года. CPU формально поддерживает Intel TXT (смотрели через msinfo32 и через cpuid утилиту), но материнская плата не имеет нужной поддержки в чипсете или производитель не реализовал это в UEFI. Обновления прошивки с добавлением DRTM не выходило и не выйдет - железо списано с активной поддержки.

Именно группа 3 оказалась неприятным сюрпризом. Не потому что серверы старые - они работают нормально. А потому что Secured-Core на них просто невозможен технически. Никаким обновлением это не решить.

Матрица и план замены

По результатам аудита мы собрали таблицу на каждый сервер: модель, год, TPM-версия, статус Intel TXT/AMD SKINIT, статус HVCI, итоговая совместимость с Secured-Core. Четыре колонки, один итоговый статус: готов / требует настройки / несовместим.

С клиентом обсудили план действий по группам:

Группа 2 - плановое обслуживание ближайшего квартала. Обновить UEFI, включить TPM и TXT/AMD SKINIT, проверить через PowerShell. Работа на несколько часов на сервер с учётом окна обслуживания.

Группа 3 - она входит в план замены, который у клиента и так был, просто без привязки к Secured-Core. Теперь есть дополнительный аргумент для ускорения: если задача перехода на Secured-Core стоит всерьёз, железо 2015-2016 года в эту картину не вписывается. Конкретные сроки - отдельный разговор с учётом бюджета.

Почему это важно

Secured-Core - не декоративная функция. Это защита от атак на уровне прошивки: DRTM не позволяет вредоносному коду, внедрённому в UEFI или загрузчик, пережить перезагрузку незамеченным. VBS и HVCI изолируют критические части ОС в отдельном виртуализованном пространстве, куда код режима ядра без верификации не попадает. Для серверов, которые обрабатывают чувствительные данные или работают в сегментах с повышенными требованиями безопасности, это реальный уровень защиты, а не просто галочка в чеклисте.

Но именно поэтому требования к железу такие строгие. Нельзя сделать «Secured-Core lite» на железе, которое DRTM не поддерживает. Либо есть вся цепочка доверия от прошивки до ядра, либо её нет.

Если планируете Secured-Core - начинайте с аудита парка. Результат может оказаться неожиданным.