Импортозамещение ОС: матрица приоритетов для КИИ после рекомендаций Минцифры и ФСТЭК

Последние три недели у нас ушли на экстренные вещи: кто уходит, у кого что горит, как продержаться без поддержки вендора. Это было нужно и правильно. Но одновременно с этим произошло кое-что, что требует другого режима работы.

Минцифры и ФСТЭК выпустили рекомендации по приоритетному переходу субъектов КИИ на отечественное ПО. Документы не имеют силы обязательных приказов, но в регуляторном контексте «рекомендации» от ФСТЭК - это практически предписание, которое станет обязательным через несколько месяцев. Паттерн известный.

Мы решили сделать паузу в режиме тушения пожаров и сформулировать долгосрочный роадмап для клиентов из числа субъектов КИИ. Начать решили с операционных систем - как самого видимого и понятного слоя, по которому есть хоть какой-то ассортимент отечественных решений.

Зачем матрица, а не просто список

Когда говорят «замените Windows на отечественную ОС», это звучит как одна задача. На деле это несколько десятков разных задач в зависимости от того, какая именно Windows, на каком железе, с каким ПО и какую роль выполняет машина.

Без приоритизации получается одно из двух: либо все задачи в очереди одновременно и непонятно, за что хвататься, либо начинают с того, что легче, - и регулятор потом задаёт неудобные вопросы, почему заменили файловый сервер, а не АРМ оператора на объекте КИИ.

Матрица нужна для того, чтобы двигаться в правильном порядке, а не в удобном.

Как мы делим серверные ОС

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

Регуляторный приоритет высокий там, где ОС входит в состав объекта КИИ или обрабатывает данные, попадающие под 239-й приказ ФСТЭК. Это серверы АСУ ТП, узлы ГИС, хосты, на которых крутятся СЗИ с сертификатами. Низкий - у вспомогательной инфраструктуры: серверы мониторинга, резервного копирования, тестовые среды.

Наличие альтернативы - не вопрос мнений, а вопрос реестра. Проверяется через реестр отечественного ПО Минцифры. Для серверных ОС на базе Linux картина сейчас выглядит так:

• Astra Linux Special Edition - в реестре, есть сертификаты ФСТЭК по 1-му классу защищённости, актуальная версия 1.7. Самый зрелый вариант для объектов КИИ с высокими требованиями.
• РЕД ОС - в реестре, сертифицирована ФСТЭК, хорошо совместима с RPM-экосистемой (RHEL, CentOS). Для тех, у кого исторически Red Hat-стек.
• ОС «Альт» (семейство ALT Linux) - в реестре, сертификаты есть, давно используется в госсегменте. Специфическая экосистема пакетов, требует привыкания.
• РОСА Линукс - в реестре, есть серверная редакция. Менее распространена в корпоративном сегменте, но для некоторых задач подходит.

Вне этого списка - AlmaLinux, Rocky Linux и прочие community-дистрибутивы. Они хорошие, мы их используем сами и рекомендуем там, где нет регуляторного давления. Но в реестре их нет и не будет - это зарубежные проекты. Для объектов КИИ они не годятся как конечная цель.

Матрица приоритетов по серверным ОС

Это не закрытый список - у каждого клиента будут свои комбинации. Но логика двух осей работает для любого случая.

Клиентские ОС: отдельная история

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

Основная проблема не в самой ОС. Astra Linux или РЕД ОС на рабочей станции установить несложно. Проблема в прикладном ПО, которое работало под Windows: 1С работает, браузер работает, офисный пакет - вопрос, а вот специализированный клиент АСУ ТП или банковский клиент - нередко нет.

Поэтому для клиентских ОС матрица выглядит иначе: первый вопрос не «есть ли отечественная ОС», а «всё ли прикладное ПО на рабочей станции имеет Linux-версию или работает через Wine/Crossover». Если нет - миграция ОС превращается в миграцию прикладного ПО, что отдельный большой проект.

Рабочие станции операторов на объектах КИИ мы выносим в отдельный трек с отдельным анализом ПО.

Что мы делаем с этим прямо сейчас

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

Дальше - роадмап: не абстрактный, а с конкретными серверами, ответственными и примерными сроками. Документ, с которым можно идти к руководству и говорить предметно, а не «регулятор требует, нужны деньги».

Технические детали по Astra Linux 1.7 и интеграции с Active Directory - это отдельная тема, там есть нюансы, которые стоит разобрать отдельно.

Если нужна помощь с аудитом инфраструктуры под эти задачи - мы сейчас именно этим и занимаемся у нескольких клиентов.