КИИ 2025: финальный спринт - аудит реестра ПО и план до 31 декабря

До 1 января 2025 года - ровно полгода. Указ № 166 никуда не делся, ФСТЭК контролирует, и момент, когда можно было «подождать и посмотреть», очевидно прошёл. Мы запустили финальный аудитный цикл по объектам КИИ: идём по реестру ПО каждого клиента и построчно сверяем его с реестром Минцифры.

Если коротко - картина везде разная, но структура пробелов одна и та же.

Почему именно сейчас

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

Шесть месяцев до дедлайна - это ровно тот момент, когда внедрение ещё физически успевает пройти все этапы. Через ещё один квартал - уже нет.

Именно поэтому мы перешли от «готовим план» к «фиксируем пробелы и закрываем».

Как устроен финальный аудит

Мы проходим по каждому значимому объекту КИИ в три шага.

Первый - инвентаризация фактического ПО. Берём актуальный реестр ПО объекта и делим на три группы: отечественное с записью в реестре Минцифры, иностранное с утверждённой альтернативой, иностранное без закрытого плана замены. Третья группа - это и есть зона работы.

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

Третий - план по каждому пробелу. Для каждой незакрытой позиции - конкретный ответ: что меняем, на что, кто делает, к какой дате. Без обтекаемых формулировок. Срок финала у всего - 31 декабря, чтобы оставить буфер на возможные проблемы при сдаче в январе.

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

Несколько наблюдений, которые повторяются у разных клиентов.

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

Мониторинг и резервное копирование - пятно. Zabbix в реестре Минцифры есть, и это закрывает мониторинг у большинства. Но резервное копирование - отдельная история: если на объекте стоит что-то импортное, замена ещё в процессе выбора и тестирования.

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

АСУ ТП - отдельный разговор. Там своя нормативная база, свои сроки и своя регуляторная логика. Для объектов с промышленным управлением мы ведём отдельный трек - его в этот чеклист не включаем, чтобы не смешивать.

Что фиксируем в итоге

По результату аудита каждый объект получает таблицу с колонками: ПО - статус (закрыто / в процессе / пробел) - альтернатива - ответственный - срок. Этот документ - и рабочий инструмент на ближайшие месяцы, и основа для отчётности перед регулятором.

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

Это аудит, который мы ведём не для галочки - потому что 31 декабря ближе, чем кажется.