Windows Server 2025 и КИИ: три сценария для тех, кто не может купить лицензию

Microsoft выпустил Windows Server 2025 GA ещё в конце прошлого года, но волна вопросов по нему у нас пошла не сразу, а сейчас - когда у части клиентов подходят к концу соглашения SA на Server 2019, и нужно принимать решение. Продлить нельзя: КИИ-объект под Указом № 166 не может легально приобретать лицензии Microsoft. Купить Server 2025 - тоже нельзя. А серверные роли работают, и выключать их завтра никто не собирается.

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

Что за роли и почему это проблема

Если бы речь шла о файловом сервере или веб-сервере, вопрос закрылся бы быстро: Samba или nginx на любом отечественном Linux. Но у большинства наших клиентов в периметре КИИ живут роли, которые не так просто заменить:

• Active Directory. Не просто служба каталогов, а корень аутентификации для сотен приложений. Включая, иногда, АСУ ТП с жёсткой привязкой к Windows-аутентификации.
• WSUS / SCCM. Управление обновлениями и инвентаризация. У части клиентов это вообще единственный инструмент централизованного контроля рабочих мест.
• MS SQL Server. Бэкенд прикладного ПО, которое само по себе тоже хочет мигрировать, но дорожная карта растянута на год-два.
• IIS + приложения на .NET Framework. Старый добрый корпоративный портал, который «работает и не трогать».

Именно эти роли держат Windows Server в инфраструктуре КИИ-объекта даже после формального перехода на отечественный стек.

Сценарий 1. Остаться на Windows Server 2019

Самый очевидный и самый рискованный долгосрочно. Server 2019 вышел из Mainstream Support в январе 2024 года, Extended Support действует до января 2029 года - это официально, и Microsoft пока не менял эти даты для пользователей без активного SA. Технически сервер продолжает работать, обновления безопасности поступают в рамках Extended Support.

Юридическая ловушка: лицензии, купленные до введения ограничений, считаются законно приобретёнными. Использование уже имеющегося ПО в большинстве интерпретаций не нарушает текущие нормы. Но здесь мнения юристов расходятся, и мы не берёмся давать однозначный ответ - это вопрос к профильным юристам конкретной организации, которые смотрят на конкретный контракт и регуляторный контекст.

Технически: нет доступа к новым функциям, нет возможности нормально патчить без активного SA-соглашения (хотя ESU-обновления формально поступают). И главный риск: если что-то сломается на уровне лицензионного ключа или активации - некому звонить.

Этот сценарий работает как временная мера с горизонтом до 2027-2028, не как стратегия.

Сценарий 2. Мигрировать на ROSA Server

ROSA Server 2.0 есть в Реестре отечественного ПО, сертифицирован ФСТЭК, и в нём есть Samba 4 с полноценной реализацией AD DS - включая контроллер домена, DNS, Kerberos, GPO. На бумаге это выглядит как прямая замена AD на Windows Server.

На практике - почти. Мы тестировали вход рабочих станций под управлением Windows 10 в домен на Samba 4 и в большинстве сценариев это работает. Групповые политики применяются, авторизация через Kerberos идёт. Проблемы начинаются в краях: сложные GPO с нестандартными ADMX-шаблонами, Dynamic Access Control, некоторые паттерны с доверием доменов. Это не значит «не работает», это значит «надо тестировать конкретную конфигурацию».

MS SQL в этом сценарии придётся заменить на Postgres Pro или Tantor SE - мы разбирали Tantor в феврале. IIS/.NET Framework - отдельная история, зависит от того, насколько приложение привязано к Windows-специфике.

Полная миграция на ROSA Server - это проект, а не задача. Горизонт от полугода до полутора лет в зависимости от сложности прикладного слоя. Зато на выходе - чистая позиция перед ФСТЭК и отсутствие вопросов по лицензиям.

Сценарий 3. Гибридный стенд

Компромисс, который мы видим чаще всего в реальных проектах. Схема простая: существующие Windows Server 2019 остаются работать, но новый функционал и новые роли разворачиваются исключительно на отечественном Linux. AD на Samba берёт на себя аутентификацию новых сегментов, Windows-домен остаётся для унаследованных систем с доверием между доменами.

Это позволяет двигаться постепенно: мигрировать приложения по одному, тестировать, не устраивать большой bang-миграцию с непредсказуемым окном простоя. Особенно это актуально для объектов с АСУ ТП, где плановые окна для изменений редки и коротки.

Сложность сценария - в поддержке двух параллельных стеков. Это операционные расходы и риск конфигурационного дрейфа. Нужна жёсткая документация и понятный план, когда какая система уйдёт на покой. Иначе «временный» гибрид живёт вечно.

Что мы реально делаем на практике

Когда к нам приходит такой вопрос, первый шаг - аудит текущего состояния: инвентаризация всех серверных ролей, их зависимостей от конкретной версии Windows Server, сложности прикладных интеграций. Без этого разговор о сценариях абстрактный.

Обычно по итогам аудита картина такая: 20-30% ролей мигрируют на Linux без особых усилий, ещё 40-50% - с умеренным объёмом работы, и 20-30% - это те самые «не трогать», которые держатся на устаревших зависимостях и пойдут последними.

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

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