Где ломается интеграция: API, данные или ответственность?
06.08.26 · 16:00 МСК Присоединиться → Корпоративный контур ERP CRM ITSM MDM DATA
HUB SYNC BROKEN ФСТЭК идет в цех. Как доказать защищенность АСУ ТП без сканера
Промышленные предприятия годами готовились к проверкам ФСТЭК как к ревизии документов. Теперь одного комплекта документов, включая модели угроз, приказы и акты внедрения, недостаточно.
Если в документах указана защита удаленного доступа, организация должна показать, как он предоставляется, кто согласует подключение, как фиксируются действия пользователя и как выявляются нарушения. Для АСУ ТП это создает отдельную проблему: привычное активное сканирование может нарушить работу контроллера, операторской станции или сетевого оборудования. Поэтому состояние технологического контура приходится подтверждать методами, которые не создают дополнительного риска для производства.
Задача стала острее после изменения правил категорирования. Постановление Правительства № 1762 от 7 ноября 2025 года изменило порядок выявления объектов КИИ: теперь организации должны сопоставлять свои информационные системы, сети и АСУ с типовыми отраслевыми объектами. Распоряжением Правительства № 360-р от 26 февраля 2026 года утвержден единый перечень из 397 позиций для 14 отраслей. Одновременно предприятия заменяют зарубежное оборудование, подключают новые системы и расширяют обмен данными между технологической и корпоративной сетями. Поэтому приходится не только пересматривать результаты категорирования, но и актуализировать документы, которые продолжают описывать уже изменившуюся архитектуру.
Содержание:
Документы остались, система изменилась
Расхождение обычно возникает постепенно. Инженеры меняют логику работы АСУ ТП, добавляют оборудование, обновляют прошивки, открывают порты и настраивают новые маршруты обмена. Каждое изменение может быть оправдано производственной задачей, но без единого порядка согласования оно не попадает в модель угроз и схемы взаимодействия. Через несколько лет организация предъявляет регулятору корректно оформленный комплект документов, который уже не соответствует реальному устройству системы.
Проблему усиливает представление о технологической сети как о физически изолированном контуре. Прямого выхода в интернет действительно может не быть, но остаются сервисные каналы, беспроводные подключения, переносные инженерные станции и временный доступ внешних специалистов. Иногда один компьютер взаимодействует и с корпоративным, и с промышленным сегментом, хотя утвержденная схема такой связи не предусматривает. На практике такой разрыв может сохраняться годами. На одном из обследований станция инженера подрядчика оказалась одновременно включена в корпоративный и технологический сегменты. Правило межсетевого экрана добавили на время пусконаладки, но оно осталось в конфигурации еще на четыре года, и о его назначении не знал ни один из действующих администраторов. Отсутствие постоянного выхода в интернет при этом продолжали считать доказательством изоляции технологической сети.
Формальным может оказаться и внедрение средств защиты. Межсетевой экран установлен на границе сегмента и принят по акту, но его правила давно не пересматривались, новые соединения добавлялись как исключения, а события не поступают на мониторинг. В такой конфигурации само наличие сертифицированного средства ничего не говорит о состоянии технологической сети. Мера становится проверяемой только тогда, когда организация может объяснить назначение разрешенных взаимодействий и показать, как выявляются отклонения. Однако обнаружить этот разрыв привычным для корпоративной инфраструктуры способом в АСУ ТП часто нельзя.
Когда проверка опаснее уязвимости
В корпоративной инфраструктуре активный сканер последовательно опрашивает узлы, определяет версии программного обеспечения и сопоставляет их с известными уязвимостями. В АСУ ТП аналогичная нагрузка может исчерпать ресурсы устаревшего контроллера, промышленного компьютера или операторской станции. Устройство перестает обрабатывать штатный обмен, разрывает сессию либо переходит в нештатный режим. Инструмент, который должен оценить защищенность, в такой ситуации сам становится причиной технологического сбоя.
Это не теоретический риск. В одном из проектов штатная инвентаризация корпоративным сканером затронула диапазон адресов технологического сегмента, после чего контроллер устаревшей серии перестал отвечать системе верхнего уровня. Участок до перезапуска устройства пришлось вести в ручном режиме, однако для корпоративных систем процедура завершилась штатно и не была зафиксирована как инцидент.
Опасность связана не только с количеством запросов. Некоторые контроллеры и реализации промышленных протоколов нестандартно реагируют на пакеты, которые не встречаются в обычном технологическом обмене. Устройство может ошибочно интерпретировать запрос, перезапустить сервис или разорвать соединение, которое не восстановится автоматически. Тяжесть последствий определяется тем, какую функцию затронутый узел выполняет в производственном процессе.
При этом отказаться от проверки тоже нельзя. Подход «не трогаем, потому что работает» сохраняет доступность оборудования только в текущий момент, но лишает организацию понимания его фактического состояния. Неучтенное подключение, измененная конфигурация или устаревшая прошивка продолжают существовать, просто риск остается невидимым для руководства. Задача состоит не в выборе между безопасностью и непрерывностью производства, а в подборе методов оценки, допустимых для конкретного сегмента.
Увидеть сеть, не вмешиваясь в процесс
Начинать следует с восстановления фактического состава технологического контура. Пассивный анализ трафика позволяет определить активные устройства, используемые протоколы и реальные связи по уже существующему обмену, не отправляя дополнительные запросы на оборудование. Так можно обнаружить узлы и взаимодействия, которых нет в документации. Вместо автоматически сформированного перечня уязвимостей организация получает восстановленную по фактическому обмену картину, которую можно на месте сопоставить с утвержденными схемами. Почему банки теряют интерес к МСБ ИИ в современном образовании. Что изменили высокие технологии в аудиториях ИИ-образование как экономика партнерства университета и бизнеса
Следующий источник данных связан с конфигурациями и действиями пользователей. Настройки коммутаторов, маршрутизаторов, контроллеров и автоматизированных рабочих мест можно собирать и сравнивать с утвержденными эталонами. Журналы показывают перезапуски сервисов, ошибки доступа и использование учетных записей, а системы управления привилегированным доступом позволяют контролировать действия внешних и внутренних специалистов. Эти методы не заменяют техническое исследование уязвимостей, но выявляют изменения, которые чаще всего создают реальные точки входа.
Активные проверки допустимы после того, как организация понимает состав оборудования и его ограничения. Инструмент сначала испытывают на резервном устройстве или тестовом полигоне, где воспроизведены критичные компоненты и характерный сетевой обмен. Для каждого типа оборудования определяют разрешенные запросы, интенсивность, технологическое окно и порядок восстановления при сбое. Активное сканирование становится точечной процедурой, а не универсальным способом обследовать всю АСУ ТП.
Не отчет, а управляемый контур
Достаточность защиты нельзя оценивать только количеством найденных уязвимостей. Для руководителя показательнее доля активов с назначенным владельцем, количество несогласованных соединений и число отклонений, для которых не принято решение. Отдельно следует контролировать, какая часть удаленных подключений проходит через установленную процедуру и насколько быстро команда может восстановить последовательность действий при инциденте. Такие показатели связывают информационную безопасность с реальным состоянием производства. Самый честный вопрос, который руководитель может задать своей команде уже завтра: сколько времени проходит между изменением в технологическом контуре и моментом, когда о нем узнает служба безопасности. Если ответа на этот вопрос нет, любой отчет о защищенности лишен опоры.
Владельцем процесса оценки должен быть руководитель, отвечающий за технологический актив и последствия его остановки: технический директор, главный инженер или руководитель производства. Служба ИБ определяет требования и методы контроля, специалисты АСУ ТП оценивают допустимость действий для оборудования, а ИТ-служба обеспечивает необходимую инфраструктуру. Руководство организации закрепляет полномочия и выделяет ресурсы, чтобы разногласия между подразделениями не блокировали проверку. Без такого распределения ответственности команда ИБ остается без доступа к системе, а производство не получает понятной оценки риска.
При таком подходе к проверке не приходится срочно восстанавливать состояние АСУ ТП по старым схемам и разрозненным журналам: данные об изменениях, доступах и работе мер защиты собираются в ходе эксплуатации. Эту логику развивает проект изменений в приказы ФСТЭК № 235 и № 239, который предусматривает регулярный расчет показателей защищенности и зрелости. На дату подготовки колонки документ остается проектом, а планируемой датой его вступления в силу указано 1 сентября 2026 года. Поэтому измеримая защищенность АСУ ТП определяется не объемом документов и не количеством закупленных продуктов, а способностью вовремя заметить отклонение, оценить его влияние на производство и выбрать действие, которое не создаст новый риск.
Ольга ЛуценкоЭксперт UDV Group Информационная безопасностьКиберугрозы
