Windows Server 2022 Preview: тестируем Secured-core на железе Dell
Разбираем Secured-core server на сертифицированном железе Dell: DRTM через Windows Defender System Guard, TPM 2.0 и UEFI-требования на практике.
Windows Server 2022 Insider Preview: Secured-core server, SMB over QUIC, HTTPS DNS
В июле мы смотрели на Windows Server 2022 Insider Preview на Hyper-V VM - и тогда честно написали, что Secured-core в виртуальной машине проверить нормально нельзя: железо не то. С тех пор удалось устранить этот пробел: у одного из клиентов по managed-сопровождению стоят Dell PowerEdge 14-го поколения, которые числятся в списке Windows Server Secured-core certified hardware. Поставили свежую preview-сборку, посмотрели что реально включается, а что по-прежнему остаётся красивой картинкой в документации.
Что такое Secured-core в контексте железа
Когда мы тестировали в VM, System Guard Secure Launch просто не было в списке доступных настроек - оно требует физического DRTM. На Dell PowerEdge с Intel TXT и TPM 2.0 картина изменилась.
Secured-core - это связка из нескольких механизмов, часть из которых существует и раньше, но здесь они работают вместе и взаимно усиливают друг друга:
- DRTM (Dynamic Root of Trust for Measurement) - процессор выполняет измерение состояния системы в момент передачи управления ОС, минуя потенциально скомпрометированный BIOS. На Intel это реализуется через TXT (Trusted Execution Technology), на AMD - через SKINIT. Windows Defender System Guard использует DRTM именно так: даже если UEFI-прошивка тронута, измерение происходит на уровне, до которого вредоносный код в прошивке дотянуться не может.
- System Guard Secure Launch - оркестрация запуска через DRTM. В Security Center это виден как отдельный пункт; на сертифицированном железе он зелёный, на нашей VM летом он просто отсутствовал.
- HVCI (Hypervisor-Protected Code Integrity) - изоляция ядра через VBS, проверка подписи кода перед загрузкой в режим ядра. Убивает класс атак с подгрузкой неподписанных или патченых драйверов.
- TPM 2.0 - хранилище измерений и криптографических ключей. Credential Guard и BitLocker опираются на него; без TPM 2.0 часть цепочки Secured-core просто не работает.
На PowerEdge всё это включилось. Причём важен порядок: сначала нужно убедиться, что в UEFI включены Intel TXT и TPM 2.0, и только потом включать Secured-core в ОС - иначе Secure Launch остаётся в состоянии «не поддерживается», хотя железо на самом деле его поддерживает.
UEFI-прошивка: где прячутся проблемы
Неочевидный момент, который вышел только на практике: на одном из серверов Dell iDRAC и BIOS были обновлены, но Intel TXT в UEFI был выключен в разделе Security - по умолчанию он нередко идёт в выключенном состоянии даже на новом железе. System Guard Secure Launch после включения TXT в прошивке и перезагрузки заработал корректно.
Второй момент - Secure Boot. DRTM и Secure Boot независимы архитектурно, но Secured-core server требует Secure Boot включённым. На одном из серверов Secure Boot был выключен ещё при установке - видимо, кто-то в своё время боролся с проблемой загрузки и выключил «на время». Пришлось перегенерировать ключи Secure Boot и заново устанавливать ОС - в нашем случае это было приемлемо на тестовом сервере, в продуктивной среде такой операции надо планировать заранее.
Итого требования к прошивке для полноценного Secured-core:
- UEFI (не legacy BIOS) - очевидно, но встречаются серверы в compatibility mode.
- Secure Boot включён - с корректными ключами Microsoft.
- Intel TXT (или AMD SKINIT) включён в настройках безопасности UEFI.
- TPM 2.0 - дискретный или firmware-based; TPM 1.2 не подходит.
Последний пункт важен: firmware TPM (fTPM), который реализован в прошивке процессора без отдельного чипа, Secured-core принимает. Это хорошая новость для серверов, где дискретного TPM нет, но процессор современный.
SMB over QUIC и HTTPS DNS: коротко
В этой же сборке появились два новшества, которые мы посмотрели бегло.
SMB over QUIC - передача файлов по протоколу QUIC вместо TCP. Идея в том, что SMB можно использовать без VPN для удалённого доступа к файловым серверам: QUIC идёт по UDP/443, обходит ряд корпоративных ограничений и по задумке даёт лучшую производительность при нестабильных соединениях за счёт устойчивости к потерям пакетов. Пока это только Azure File Gateway, на on-premise серверах общего назначения SMB over QUIC в текущей preview не работает. Смотрели, убедились в ограничениях, отложили.
HTTPS DNS (DoH) - мы уже писали про это в июльском посте. В текущей сборке конфигурация через реестр и GPO стала немного чище, но концептуально ничего не изменилось. Для большинства клиентских окружений DoH интересен только в связке с корпоративным DoH-резолвером, иначе это скорее красиво, чем полезно.
Что нас остановило
Честно говоря, есть одна вещь, которая мешает воспринимать Secured-core как «просто включить и забыть». HVCI при включении требует, чтобы все драйверы в системе были подписаны и совместимы с HVCI. На чистой установке Server 2022 Preview это выполняется. Но при мысли о реальных серверах клиентов - с мониторинговыми агентами, backup-агентами, вендорскими утилитами для железа - возникают законные сомнения. Часть этих агентов работает на уровне драйвера, и не все из них HVCI-совместимы. Тестировать это придётся отдельно под каждый кейс, прежде чем включать в продуктиве.
На сертифицированном железе Secured-core работает и работает убедительно. Технически это существенный шаг в сторону hardware-backed security, где доверие строится снизу вверх - от процессора через прошивку к ОС, а не наоборот. Но путь от «тестовый сервер с preview-сборкой» до «продуктивный сервер клиента» длиннее, чем кажется на первый взгляд.