Windows Server 2022 Insider Preview: смотрим на Secured-Core Server и TLS 1.3 в лабе

Microsoft начала раздавать сборки Windows Server 2022 через программу Windows Insider for Business. Релиза нет - это превью, что-то в районе build 20348 - но материала для первичного взгляда достаточно. Нас зацепили два момента: Secured-Core Server и принудительный TLS 1.3. Именно это применительно к периметровым серверам клиентов разбираем в лабе.

Secured-Core Server: что это на практике

Microsoft продвигает концепцию Secured-core как пакет аппаратных и прошивочных гарантий: DRTM (Dynamic Root of Trust for Measurement), Hypervisor-Protected Code Integrity (HVCI), Secure Boot в обязательном режиме, Windows Defender Credential Guard включён по умолчанию. На клиентских Windows это появилось в Secured-core PC раньше, теперь то же самое переносится на серверную платформу.

На практике это означает следующее. Система при старте измеряет загрузчик и ядро через TPM 2.0 и UEFI Secure Boot - без этой цепочки аттестации гарантий нет. DRTM через Intel TXT или AMD SKINIT инициирует доверенное измерение после того как BIOS уже отработал - это закрывает класс атак, где BIOS скомпрометирован до загрузки ОС. HVCI - виртуализационная изоляция кода ядра - работает через VBS (Virtualization Based Security) и блокирует подгрузку неподписанных драйверов в режиме ядра.

Требования к железу при этом серьёзные: нужен TPM 2.0, UEFI (не Legacy BIOS), CPU с поддержкой виртуализации второго уровня (VT-x + VT-d у Intel, AMD-V + AMD-Vi), и поддержка DRTM от платформы. Это не каждый сервер в парке клиентов.

Мы прогнали превью в лабе на нескольких конфигурациях. На физическом сервере с Intel Xeon и TPM 2.0 на борту Secured-core включается и Device Security в параметрах показывает все галочки зелёными. На виртуалке VMware - по понятным причинам - картина другая: часть функций недоступна, потому что гипервизор не пробрасывает нужные возможности полностью. На Hyper-V с Shielded VM - работает нормально, там это всё проектировалось вместе.

Что это меняет для периметровых серверов клиентов. Если сервер физический и куплен относительно недавно (поколение железа последних 3-4 лет, с TPM 2.0 на плате), Secured-core становится опцией которую стоит включать на периметре. Файловые серверы, DC, шлюзы - классические цели атак с загрузкой вредоносных драйверов и буткитов. HVCI закрывает эту поверхность атаки аппаратными средствами, а не только ПО-политиками. Credential Guard в базовой поставке - отдельный плюс: LSASS работает в изолированном процессе VBS, дампить хэши стандартными средствами типа Mimikatz становится принципиально сложнее.

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

TLS 1.3 по умолчанию

Второй момент, который нас интересует - TLS 1.3 включён по умолчанию на уровне Schannel. В Windows Server 2019 TLS 1.3 был доступен начиная с определённых билдов, но требовал включения вручную или через реестр. В 2022 Preview он идёт по умолчанию.

Это означает, что IIS, RDP, LDAPS и всё что использует Schannel - будут предпочтительно согласовывать TLS 1.3 с клиентами, которые его поддерживают. TLS 1.0 и 1.1 в превью отключены - это важный момент для клиентов с легаси-приложениями, которые умеют только в старые версии протокола.

TLS 1.3 убирает несколько историй, которые регулярно всплывают в аудитах. Нет больше RSA key exchange - Perfect Forward Secrecy обязателен, только ECDHE. Сокращённый набор cipher suites: остаются только современные AEAD-шифры (AES-GCM, ChaCha20-Poly1305). Handshake сокращается с двух туров до одного, с поддержкой 0-RTT для возобновления сессий (хотя 0-RTT имеет свои риски, которые стоит понимать). OCSP stapling улучшен. И ключевое - certificate transparency становится значимее, потому что убраны старые escape hatch-и.

На периметровых серверах - HTTPS-шлюзы, веб-приложения, RD Gateway - переход на TLS 1.3 как базовый профиль это правильный шаг. Это то, что мы сейчас руками делаем через GPO и реестр, там где нужно: отключаем TLS 1.0/1.1, принудительно включаем TLS 1.3. В 2022 это будет состоянием из коробки.

Практическое замечание по тестированию. В лабе мы прогнали несколько типичных клиентских сценариев против сервера с 2022 Preview. Современные браузеры - Chrome, Firefox, Edge - договариваются по TLS 1.3 без вопросов. Старые Java-клиенты (Java 8 без свежих апдейтов) - могут упасть, потому что их SSLContext по умолчанию не поддерживает TLS 1.3. Некоторые сетевые устройства с SSL-инспекцией - тоже потенциальное узкое место: если инспектирующий прокси не умеет TLS 1.3, соединение деградирует или рвётся. Это нужно проверять для каждой конкретной инфраструктуры до развёртывания.

Что дальше

В лабе продолжаем смотреть на 2022 Preview. Ещё не всё трогали: HTTPS-поддержка в Windows Admin Center, улучшения в Hyper-V (NUMA-топология для вложенной виртуализации), SMB over QUIC (периметровый доступ к файловым шарам без VPN - интересная история, но пока только для Azure Edition). Это в следующих заходах.

Для клиентов на managed-сопровождении держим в голове: когда 2022 дойдёт до релиза, апгрейд периметровых серверов на него будет оправдан именно Secured-Core и TLS 1.3 по умолчанию - не ради новизны, а потому что это убирает целый класс ручных настроек, которые мы сейчас делаем при развёртывании.