Итоги года обязательного перехода КИИ на отечественное ПО: что удалось, что зависло

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

Спойлер: никто не сделал всё. Никто.

Что реально перевели

Есть позиции, где переход прошёл относительно чисто. Обычно это инфраструктурный слой, который достаточно хорошо закрывается отечественными продуктами и не требует переписывания прикладного ПО.

Гипервизоры. Большинство наших клиентов из КИИ так или иначе завершили или почти завершили уход с VMware. Кто на zVirt, кто на Deckhouse Virtualization, один заказчик - на Proxmox в той части инфраструктуры, где требований к сертификации нет. Это, пожалуй, самый «закрытый» пункт в списке: продукты есть, миграционный путь понятен, несколько итераций уже пройдено.

Операционные системы на серверах. Astra Linux и РЕД ОС закрывают большинство потребностей. Боль здесь не в ОС как таковой, а в прикладном слое, который на неё переехал с разной степенью готовности - но об этом ниже.

Средства защиты информации. Парадоксально, но именно СЗИ обновились раньше всего - возможно, потому что требования ФСТЭК здесь конкретны, а у вендоров сертификаты актуальные. Антивирусы, SIEM, средства обнаружения вторжений - здесь чаще всего картина приемлемая. Мы подробно разбирали изменения в перечне допустимых СЗИ ещё летом - см. пост про обновление приказа ФСТЭК № 239.

Где завис процесс

Вот тут интереснее - и честнее.

Прикладное ПО. Это главная незакрытая дыра. У трёх клиентов из пяти есть специализированное отраслевое ПО, которое не имеет отечественного аналога, принятого регулятором. Геологическое, инженерное, технологическое. Один заказчик из энергетики до сих пор работает на иностранном SCADA-пакете - не потому что не хотел мигрировать, а потому что отечественный аналог проходит опытную эксплуатацию и пока не готов к промышленному внедрению.

СУБД. Переход с Oracle и MS SQL на отечественные СУБД - это не «установить PostgreSQL». Это месяцы работы с хранимыми процедурами, пересмотр схем, тюнинг производительности под новый движок. У нескольких клиентов процесс идёт, но половина данных по-прежнему на зарубежных СУБД. Tantor и другие сертифицированные PostgreSQL-дистрибутивы технически закрывают потребность - но объём работы по миграции недооценивали все без исключения.

Рабочие места. Офисные пакеты, почта, браузеры - здесь самый низкий прогресс среди всех слоёв. Ряд организаций формально поставил «МойОфис» или «Р7», но часть пользователей продолжает работать через браузерные версии иностранных сервисов, которые технически не запрещены, но явно не то, чего требовал дух перехода. Это серая зона, в которой регулятор пока ведёт себя терпеливо.

Какие исключения запрашивают у регулятора

Здесь самое любопытное. Практика запросов на продление сроков или получение исключений сложилась, и мы уже видим несколько паттернов.

Отсутствие отечественного аналога. Самое распространённое основание. Регулятор принимает этот аргумент, если он подкреплён: официальным отказом или подтверждением от российских вендоров, анализом реестра отечественного ПО, обоснованием невозможности замены на смежные продукты. Голый «нет аналога» не работает - нужно показать, что искали.

Риск нарушения технологического процесса. Для объектов, где замена ПО может повлечь остановку производства или создать угрозу безопасности, исключения дают охотнее. Обоснование должно быть техническим, с оценкой рисков, а не просто ссылкой на «у нас сложно».

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

Что не работает как основание для исключения: «дорого», «некогда», «наш подрядчик не успел». Организационные и бюджетные причины без технической подложки исключений не дают.

Что из этого следует

Картина по нашей базе такая: у большинства заказчиков выполнено 40-60% от формального перечня требуемых переходов. Инфраструктурный слой закрыт лучше, прикладной - значительно хуже. Ни один клиент не находится в состоянии «всё готово, можно проверять».

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

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