КИИ и отчёт в ФСТЭК: составляем матрицу замещения по слоям стека

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

К нам обратился клиент - промышленное предприятие, субъект КИИ второй категории значимости - с запросом помочь подготовить отчётные материалы для ФСТЭК. Работа началась стандартно: открыли то, что у них есть, и стало понятно, что собирать придётся почти с нуля.

Что регулятор ждёт от отчёта

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

• Реестр иностранного ПО на объекте КИИ - что именно используется, на каких автоматизированных системах, с обоснованием классификации как «иностранного».
• Перечень отечественных альтернатив из реестра Минцифры - по каждому иностранному продукту, с указанием статуса: замена выбрана, идёт пилот, замена в плане, замены нет.
• Сроки по каждой позиции - понятные и обоснованные, не «до конца 2024» по всему списку.
• Фактический прогресс - что уже переведено, что в работе, что ещё не тронуто.

Ключевая проблема большинства клиентов здесь не в том, что нечего показать регулятору. Проблема в том, что реестра иностранного ПО как структурированного документа просто не существует. Есть интуиция главного айтишника, есть разрозненные записи, есть что-то в системе мониторинга. В единый список это не сведено никогда.

Матрица замещения: как мы её строим

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

Слой 1 - операционные системы. Обычно самый понятный слой с точки зрения наличия альтернатив. У клиента на серверах стоял Windows Server и несколько машин на CentOS 7 (у которого EOL наступает в июне 2024). Astra Linux SE и РЕД ОС как замены известны, сертификаты ФСТЭК есть. Сложность здесь не в выборе дистрибутива - сложность в том, что под каждой ОС живёт прикладное ПО, и часть его на российском Linux просто не запускается. Поэтому в матрице напротив каждой ОС сразу проставляем флаг: есть ли зависимое ПО, которое нужно мигрировать одновременно.

Слой 2 - СУБД. У клиента MS SQL Server под несколькими внутренними системами и один оставшийся сервер Oracle под унаследованным приложением. MS SQL - переход на Postgres Pro или ванильный PostgreSQL реалистичен, но требует анализа SQL-диалекта и хранимых процедур. По Oracle ситуация хуже: приложение написано с расчётом на специфику Oracle, тащит пакеты PL/SQL, и «просто перелить данные» не получится. В отчёте это честно фиксируется как позиция без готового решения - с обоснованием технических препятствий, а не с фиктивным сроком.

Слой 3 - прикладное ПО и средства автоматизации. Самый разнородный слой. Здесь у клиента: ERP-система на зарубежной платформе, система управления документооборотом, несколько специализированных инженерных программ и пакет для управления персоналом. По каждому - своя история. ERP теоретически мигрируема на 1С-совместимые решения, но это отдельный проект на год-полтора. Инженерный CAD-софт - ситуация сложная, потому что отечественных аналогов с той же функциональностью мало, а те, что есть, требуют переобучения персонала и изменения форматов файлов.

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

Реалистичные сроки - это не оптимизм

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

Наш подход: сроки выставляются от реальной трудоёмкости и ресурсов, а не от желаемой даты. Если миграция СУБД с учётом анализа, тестирования, пилота и переключения реально займёт восемь месяцев - пишем восемь месяцев. Если замена инженерного ПО сейчас невозможна из-за отсутствия аналогов - фиксируем это честно, с обоснованием. ФСТЭК в нынешних разъяснениях прямо указывает, что признаёт случаи, когда отечественный аналог отсутствует или неприменим - главное, чтобы это было задокументировано, а не умолчано.

В итоге матрица у клиента разбилась на три блока:

• Можно закрыть до конца 2024 - серверные ОС на типовых серверах, часть СУБД, периферийные инструменты.
• Переход начат, завершение в 2024-2025 с пилотом - ERP, основная часть прикладного ПО.
• Аналог отсутствует или неприменим - специализированный инженерный софт, Oracle-зависимое приложение. По этим позициям - обоснование и план проработки, без ложных обещаний.

Что получается на выходе

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

Главный вывод из этого кейса несложный: отчёт для ФСТЭК - это побочный продукт нормальной инвентаризации. Если инвентаризации нет, отчёт будет либо фиктивным, либо его придётся делать с нуля за две недели до дедлайна. Второй вариант мы уже видели у других клиентов, и это не самое приятное зрелище.