Готовность объекта КИИ к переходу на отечественное: самоаудит до объявления закупки

Требование 187-ФЗ формулируется в терминах закона - категория значимости, отечественное программное обеспечение, программно-аппаратный комплекс. Главному инженеру эту формулировку нужно перевести в список конкретных шкафов на своём объекте: какой контроллер стоит на щите вентиляции, что за диспетчерский софт рисует мнемосхему оператору, и подтверждено ли это железо и ПО там, где закон требует подтверждения. Пока перевода нет, закупку объявлять рано - подрядчики получат разное понимание объёма и дадут несопоставимые предложения.

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

Проверка последовательная, а не параллельная

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

Есть ли у объекта акт категорирования

Коротко: без утверждённой категории значимости требования 187-ФЗ к объекту формально не применяются, но это не повод откладывать остальную проверку.

Категорирование по 187-ФЗ проводит сама организация - эксплуатант объекта, с участием ФСТЭК России на этапе согласования. Итог - акт с присвоенной категорией значимости (1, 2 или 3) либо решение о том, что объект не относится к значимым. Первый шаг самоаудита - убедиться, что такой акт существует и что он актуален: категория пересматривается при существенном изменении инфраструктуры объекта, а не присваивается один раз навсегда.

Если акта нет - это отдельная задача, не связанная напрямую с парком АСУ ТП, и её решает служба информационной безопасности совместно с профильным подразделением, а не инженер автоматизации. Но даже без акта разумно провести остальную часть проверки ниже: если по факту объект явно тянет на 2 или 3 категорию (последствия инцидента затрагивают значимое число людей или существенный ущерб), закладывать переход на реестровое оборудование имеет смысл заранее, не дожидаясь формального категорирования.

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

Что фактически стоит в парке ПЛК и SCADA

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

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

Что фиксировать	Зачем
Модель и серия контроллера, год выпуска, производитель	Определяет, попадает ли позиция под требование к ПАК (дедлайн 2030)
Инженерная среда, в которой ведётся проект (фирменная IDE вендора или открытый стандарт)	Определяет требование к ПО (дедлайн 2028) - это отдельная позиция от контроллера
Диспетчерский софт верхнего уровня и его версия	Отдельная позиция реестра ПО, часто с отдельным сроком поддержки лицензий
Сетевые протоколы на объекте	Открытые (Modbus, OPC UA) не создают риска зависимости от вендора; проприетарные (Profibus, X-Way) - создают
Год ввода в эксплуатацию и остаточный ресурс оборудования	Позволяет расставить очерёдность замены - что действительно на грани отказа, а что проработает ещё годы

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

Два реестра под два дедлайна, и позиция закрывает только один

Коротко: у объекта КИИ требование к ПО и требование к ПАК идут по разным реестрам и разным срокам, поэтому запись «в реестре» по контроллеру ничего не говорит о готовности SCADA, и наоборот.

Специфика именно для 187-ФЗ - не в том, как читать одну реестровую запись (эта механика разобрана отдельно, включая балльную оценку локализации и сроки действия - см. источники ниже), а в том, что опись из предыдущего раздела нужно разложить по двум срокам сразу:

• Позиции, закрывающие требование к программно-аппаратному комплексу (контроллеры, сетевое оборудование, серверы) - проверяются по реестру Минпромторга, дедлайн 2030 год.
• Позиции, закрывающие требование к программному обеспечению (SCADA, инженерная среда, прикладной софт) - проверяются по реестру Минцифры, дедлайн 2028 год.

Практическое следствие: контроллер конкретной модели может числиться у Минпромторга, а инженерная среда для него - у Минцифры вовсе не значиться. Это два независимых риска с разными сроками устранения. Программную часть логично двигать к 2028 году отдельно от замены самого контроллера, если зависимость подсистем это позволяет (см. следующий раздел).

Отдельно стоит развести два вопроса, которые на объекте легко перепутать: «оборудование российского происхождения» и «оборудование в действующей реестровой записи» - для целей 187-ФЗ значение имеет только второе.

Какие подсистемы связаны между собой и что можно заменить отдельным этапом

Коротко: 187-ФЗ не требует одномоментной замены всего объекта - подсистемы можно переводить поэтапно, если это не разрывает критичные связи между ними.

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

• Обменивается ли она данными с другими подсистемами объекта напрямую (по проприетарному протоколу) или только через верхний уровень SCADA.
• Есть ли у неё независимый контур управления, который продолжит работать при переключении соседней подсистемы, или отказ одной тянет за собой другую.
• Кто эксплуатирует смежную систему - сам объект или сторонняя организация (например, отдельный контракт мониторинга) - такие системы обычно выводятся за периметр проекта, но об этом нужно договориться заранее, а не постфактум.

Результат этого шага - список подсистем, ранжированный по тому, насколько независимо их можно менять. Верхний уровень (SCADA, среда разработки) обычно можно унифицировать одним этапом под дедлайн 2028, а замену контроллеров по подсистемам растянуть на несколько этапов до 2030, если связи между ними позволяют.

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

Часть вопросов методом самоаудита не закрывается - для них нужен внешний специалист по конкретной теме, и делать вид, что своими силами разобрались, дороже, чем честно передать вопрос дальше:

• Соответствие модели угроз требованиям ФСТЭК для присвоенной категории значимости - это работа службы информационной безопасности или профильного подрядника, не инженера автоматизации.
• Юридическая корректность акта категорирования - составляется и утверждается по установленной процедуре, самостоятельная переоценка задним числом рисков не снимает.
• Совместимость сертифицированных средств защиты (межсетевые экраны промышленного класса, системы обнаружения вторжений для АСУ ТП) с конкретной архитектурой сети объекта - требует стыковки с командой ИБ и профильным интегратором по средствам защиты.
• Финальное подтверждение статуса позиции на дату планируемой закупки - номенклатура обновляется, и последнюю сверку логично делать непосредственно перед объявлением закупки, отдельно от общего самоаудита.

Что заложить в ТЗ

• Опись парка ПЛК, SCADA и сетевого оборудования по образцу таблицы выше, с результатом проверки статуса на каждую позицию.
• Акт категорирования объекта либо обоснование, почему категорирование не завершено на момент закупки.
• Карту зависимостей подсистем - что можно заменить отдельным этапом, а что требует синхронной замены.
• Требование к подрядчику подтвердить актуальный статус позиции на дату поставки, а не на дату подготовки КП - между этими датами он способен измениться.
• Разделение сроков закупки на два дедлайна: программная часть (SCADA, среда разработки) - к 2028 году, аппаратная часть (контроллеры, сетевое оборудование) - к 2030 году, с промежуточными точками для крупных объектов.
• Требования к сегментации сети и журналированию, согласованные заранее с командой информационной безопасности объекта.
• Состав документации, которую подрядчик передаёт по итогам: обновлённая исполнительная документация, протоколы испытаний, подтверждение статуса каждой позиции на дату сдачи.

Частые вопросы

С чего начать, если описи парка АСУ ТП вообще нет? С инвентаризации на месте - обхода щитовых с фиксацией шильдиков контроллеров и версий установленного ПО на инженерных станциях. На объектах, прошедших через нескольких подрядчиков, реальный состав парка нередко расходится с последней исполнительной документацией, и сверять стоит по факту, а не по бумаге.

Самоаудит проводится один раз или его нужно повторять? Повторять - минимум при каждом существенном изменении парка и заранее перед каждой закупочной кампанией. Статус позиции способен меняться со временем, а сроки закона неподвижны, поэтому опись, собранная за год до тендера, к моменту его объявления может частично устареть.

Что делать с оборудованием, которое работает нормально и менять его пока не хочется? Если объект отнесён к значимой категории, срок закона не зависит от технического состояния парка - работоспособность и юридическое требование это разные вопросы. Планировать переход стоит заранее, не дожидаясь ни отказа железа, ни последнего года перед дедлайном.

Можно ли заменить только часть подсистем, оставив остальное как есть? Да, если карта зависимостей это позволяет. Обычный порядок: сначала верхний уровень к 2028 году, затем контроллеры по подсистемам к 2030-му, начиная с тех, где меньше остаточный ресурс.

Кто в организации должен вести этот самоаудит - ИТ, ИБ или служба эксплуатации АСУ ТП? Опись оборудования логично ведёт служба эксплуатации - она знает состав парка по факту. Категорирование и модель угроз - зона ответственности ИБ. Список для закупки собирается на стыке двух служб, и расхождения стоит сверить до тендера, а не в процессе его проведения.

Нужно ли отдельно проверять полевой уровень - датчики, приводы? 187-ФЗ в части ПО и ПАК касается уровня контроллеров, SCADA и сетевого оборудования, а не полевых приборов - датчиков и исполнительных механизмов. Их замена возникает по факту физического состояния или несовместимости протокола с новым уровнем контроллеров, а не по требованию закона напрямую.

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

Источники

• 187-ФЗ КИИ для АСУ ТП - дедлайны 2028/2030, три категории значимости, реестры Минпромторга и Минцифры применительно к парку АСУ ТП.
• Реестр Минпромторга по ДГУ и ИБП: что проверять в реестровой записи - механика чтения реестровой записи (наименование, производитель, ОКПД2, срок действия, балльная оценка локализации), применима к любой позиции реестра, не только к силовому оборудованию.
• Кейс: ЕСУМИС для Федеральной таможенной службы - работа с госзаказчиком по 44-ФЗ, отечественное оборудование из реестра, режимные требования к документации и персоналу на 53 объектах.
• Помощь с ТЗ под импортозамещение - формулировка требований к подрядчику и объёма замены до объявления закупочной процедуры.

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