Сближение ИТ и АСУ ТП: где на практике рождаются системные риски

Сближение ИТ и АСУ ТП редко происходит через одно крупное решение. Чаще это цепочка локальных шагов — и именно в этих точках постепенно формируется системный риск. Транзит трафика через корпоративную инфраструктуру — одна из самых распространенных проблем. Формально для технологической сети может быть выделен отдельный коммутатор или сегмент, однако связь с корпоративной инфраструктурой сохраняется. В результате трафик АСУ ТП проходит транзитом через ИТ-контур. Такая связность создает путь для атаки: компрометация офисной сети автоматически повышает риск для технологического сегмента.

Средства удаленного доступа — вторая критическая зона. Даже если АСУ ТП изначально проектировалась как изолированная система, каналы подключения для подрядчиков или сервисных служб часто закладываются заранее. В момент активации такого доступа технологическая сеть фактически перестает быть изолированной. Проблема не только во внешнем злоумышленнике: любой неконтролируемый или избыточный удаленный канал размывает границу между сегментами.

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

Наконец, отдельный класс рисков — неучтенные каналы связи. USB-накопители, Wi-Fi-адаптеры, модемы для «временного» подключения подрядчиков часто появляются как оперативная мера и остаются в инфраструктуре. Эти каналы редко включаются в архитектурную модель защиты, но фактически создают альтернативный периметр.

Во всех перечисленных случаях проблема возникает не из-за самого факта взаимодействия ИТ и АСУ ТП, а из-за отсутствия четко спроектированной модели границы между ними. Именно на этой границе формируются основные архитектурные конфликты.

Когда зрелые ИТ-практики подрывают устойчивость АСУ ТП

Значительная часть проблем возникает не из-за откровенно небезопасных решений, а из-за прямого переноса корпоративных ИТ-подходов в технологическую среду.

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

Схожая проблема возникает при централизованном антивирусе с автоматическим обновлением сигнатур и функцией «лечения». Файл управляющей программы для станка с ЧПУ может быть ошибочно определен как вредоносный и удален. Кроме того, одновременное обновление всех узлов технологической сети создает пиковую нагрузку, которую устаревшее оборудование может не выдержать.

Еще одна типовая ИТ-практика — активное сетевое сканирование и агрессивный мониторинг. В промышленной среде такое поведение может восприниматься оборудованием как аномальное. Некоторые контроллеры и устройства реагируют на интенсивный опрос нестабильно, вплоть до перезагрузки или зависания.

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

Во всех этих случаях источник проблемы один — несоответствие логики обновляемости и контроля логике предсказуемости и устойчивости. В ИТ приоритетом является своевременное устранение уязвимостей, в АСУ ТП — гарантированная непрерывность технологического цикла. Без учета этого различия зрелые корпоративные практики начинают работать против надежности.

Разные модели риска: защита данных против устойчивости процесса

В основе многих конфликтов лежит различие в самой логике оценки рисков. В корпоративной ИТ-среде приоритетом традиционно является защита информации — предотвращение утечек, несанкционированного доступа, компрометации учетных записей. Даже при формальном учете триады «конфиденциальность, целостность, доступность» на практике доминирует защита данных.

В технологической сети приоритет иной — безопасность и непрерывность процесса. Здесь риск измеряется не утечкой информации, а остановкой производства, выходом оборудования из строя, нарушением технологического цикла или угрозой для персонала. Угроза — это любое отклонение от регламентированного режима работы, независимо от того, вызвано ли оно внешней атакой, ошибкой инженера или техническим сбоем.

Когда ИТ-модель угроз переносится в АСУ ТП без адаптации, возникает перекос. Закрытие логических уязвимостей или жесткое внедрение средств контроля может увеличить вероятность отказов. Например, автоматическая блокировка «аномального» трафика в корпоративной логике оправдана, но в технологической среде такой трафик может быть аварийной командой или сигналом ручного управления.

Граница, после которой усиление ИБ начинает вредить, проходит там, где средства защиты вмешиваются во временные характеристики и стабильность процесса. Перезагрузка серверов управления во время операции, блокировка технологических команд, изменение конфигурации без учета производственного цикла — именно в этих точках защита превращается в дополнительный фактор риска.

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

Повторяющиеся инженерные причины инцидентов

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

Первая типовая проблема — «временные» каналы доступа, которые становятся постоянными. Подключение подрядчика через корпоративную сеть, модем или дополнительный сетевой интерфейс изначально задумывается как оперативная мера. Со временем этот канал перестает восприниматься как исключение и превращается в устойчивую точку входа, часто обходящую базовую модель сегментации.

Вторая причина — отсутствие жесткой границы между сегментами. Единый домен, общий шлюз для офисной сети и АСУ ТП, транзит трафика через корпоративную инфраструктуру делают технологический контур зависимым от состояния ИТ-среды. Компрометация корпоративной сети автоматически повышает риск для производства.

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

Во всех этих случаях инцидент возникает не из-за сложности атаки или высокой технической изощренности злоумышленника. Причина — в отсутствии инженерной дисциплины на стыке двух сред и в размывании границы ответственности.

Именно поэтому в ряде ситуаций дополнительным фактором риска становятся не только внутренние решения, но и требования внешних поставщиков оборудования и сервисных служб.

Роль вендоров: фактор удобства как источник архитектурного риска

Поставщики оборудования и сервисные подрядчики объективно участвуют в формировании архитектуры технологической сети. Во многих случаях именно их требования становятся отправной точкой для создания дополнительных каналов связности.

Типовая ситуация — необходимость удаленного обслуживания. Для упрощения поддержки вендор предлагает открыть доступ или обеспечить постоянное подключение к серверу управления. Формально это повышает скорость реакции и снижает издержки сопровождения. Фактически же появляется канал, который обходит исходную модель изоляции.

Еще одна распространенная практика — универсальные сервисные учетные записи, общие пароли или технические механизмы доступа, оставленные «на всякий случай». Такие решения удобны для сопровождения, но создают долгосрочную уязвимость, особенно если не сопровождаются строгим контролем и журналированием.

Дополнительный риск связан с использованием закрытых или устаревших протоколов, которые не обновляются годами. Модернизация требует инвестиций со стороны вендора, поэтому проще сохранить существующую архитектуру и переложить ответственность на заказчика.

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

Сближение ИТ и АСУ ТП само по себе не является ошибкой. Риски возникают там, где граница между сегментами проектируется постфактум — после внедрения оборудования, подключения подрядчиков и запуска сервисов. Именно отсутствие заранее заданной инженерной модели сопряжения делает эти точки уязвимыми.

Итог: проблема не в интеграции, а в модели границы

Сближение корпоративных и технологических сетей само по себе неизбежно и зачастую оправдано задачами управления и цифровизации. Проблема возникает не в факте интеграции, а в отсутствии инженерно выстроенной модели границы — с четкими принципами сегментации, контролем связности и распределением ответственности.

Большинство инцидентов на этом стыке становятся следствием не сложных атак, а архитектурных компромиссов и управленческих решений, принятых ради удобства. Вопрос уже не в том, нужно ли разделять ИТ и АСУ ТП, а в том, как спроектировать их сопряжение так, чтобы цифровизация не подрывала устойчивость производства. Именно эти инженерные принципы и управляемые компромиссы стоит разобрать детально в следующей статье.