Стыки ИТ и АСУ ТП — не про эффективность, а про скрытые уязвимости. Как привычные практики, удалённый доступ и «удобные» решения превращаются в точки отказа и почему граница между контурами решает всё.
- 1. Введение
- 2. Базовые архитектурные принципы сопряжения
- 3. Недопустимые и допустимые компромиссы
- 4. Что нельзя централизовывать и выносить в ИТ-контур
- 5. Мониторинг без иллюзии контроля
- 6. Регуляторные требования и эксплуатационная реальность
- 7. Где теряется ответственность и как ее закрепить
- 8. Культура взаимодействия: от конфликта к совместному проектированию
- 9. Выводы
Введение
В предыдущей статье эксперт UDV Group Ольга Луценко разобрала, где на стыке корпоративных и технологических сетей формируются системные риски — от транзитного трафика и удалённого доступа до некритичного переноса ИТ-практик и размывания ответственности между ИТ, ИБ и эксплуатацией.
Во второй части речь пойдёт о том, как решать эти конфликты инженерно: какие принципы должны быть заложены в архитектуру сопряжения ИТ и АСУ ТП (автоматизированной системы управления технологическим процессом), где допустимы компромиссы, какие функции нельзя централизовывать и как закрепить ответственность на границе контуров. Если интеграция неизбежна, задача — не изолировать любой ценой, а спроектировать управляемую границу. Именно эту модель разберём подробнее.
Базовые архитектурные принципы сопряжения
Если рассматривать интеграцию ИТ и АСУ ТП как инженерную задачу, а не как проект по внедрению средств защиты, то в основе должны лежать несколько фундаментальных принципов:
- Физическая сегментация. Приоритет везде, где она возможна. Технологическая сеть должна быть отделена от корпоративной не только логически, но и инфраструктурно. Если есть возможность физически разделить контуры, это необходимо делать. Там, где физическая изоляция невозможна, применяется строгая логическая сегментация через межсетевые экраны с минимально необходимыми правилами взаимодействия.
- Минимизация связности. Связь между корпоративной и технологической сетью чаще всего создаётся «для удобства». На практике значительная часть транзитного трафика не является критически необходимой для производственного процесса. Если от канала можно отказаться — от него стоит отказаться. Любая связность должна быть обоснована эксплуатационной потребностью, а не организационным комфортом.
- Контроль на границе сегментов. Если взаимодействие необходимо, граница должна быть формализована: отдельная зона сопряжения, ограниченные направления трафика, чётко определённые протоколы и обязательное журналирование. Нельзя допускать размытой связности, при которой ИТ- и технологический сегменты фактически работают как единая сеть.
- Разделение доменов и учётных записей. Недопустимо использовать общие учётные записи или единый домен для корпоративного и технологического сегмента. Разделение идентификационных контуров — базовое условие управляемости и расследуемости инцидентов.
- Принцип локальности критических функций. Функции, влияющие на безопасность процесса — аварийная остановка, защитные блокировки, уставки и пороговые значения — должны оставаться автономными и не зависеть от доступности корпоративной инфраструктуры или внешних сервисов.
Эти принципы не означают отказ от цифровой интеграции. Они задают рамку, в пределах которой интеграция становится управляемой и не влияет на устойчивость технологического процесса.
Недопустимые и допустимые компромиссы
Сопряжение ИТ и АСУ ТП почти всегда связано с компромиссами. Важно заранее определить, какие из них допустимы, а какие создают системный риск.
Недопустимые компромиссы — это решения, которые размывают границу сегментов и создают прямую зависимость технологического процесса от корпоративной среды.
К ним относятся:
- прямой доступ из интернета в технологическую зону;
- использование общих учётных записей или единых доменов для ИТ и АСУ ТП;
- отказ от физической сегментации ради экономии или удобства;
- постоянные универсальные VPN-доступы без жёсткого ограничения по времени и задачам.
Такие решения могут казаться рациональными с точки зрения администрирования, но фактически уничтожают архитектурную модель изоляции.
Допустимые компромиссы возможны, но только при соблюдении инженерной дисциплины.
Например, передача обновлений или управляющих файлов из корпоративной сети в технологическую может быть реализована, если:
- создан тестовый стенд, воспроизводящий реальный процесс;
- обновления проходят предварительное тестирование;
- внедрение происходит по согласованному регламенту и в контролируемое окно.
То же касается удалённого доступа подрядчиков: он допустим при условии индивидуальных учётных записей, строгого ограничения по времени, журналирования действий и выделенной зоны сопряжения.
Ключевой критерий прост: удобство не должно определять архитектуру. Любой компромисс допустим только в том случае, если он не создаёт неконтролируемой зависимости между сегментами и не влияет на устойчивость технологического процесса.
Что нельзя централизовывать и выносить в ИТ-контур
В технологической сети существуют функции, которые принципиально не должны зависеть от корпоративной инфраструктуры, даже если централизованное управление выглядит удобным.
Аварийная остановка процесса должна быть локальной, автономной и аппаратной. Доступ к механизму аварийного отключения не может зависеть от сетевого соединения, работы центра обработки данных или удалённого интерфейса. Решение о прекращении процесса принимает оператор на месте через физический орган управления. Любая возможность удалённого вмешательства в эту функцию создаёт недопустимый риск.
Критические логики управления и защитные блокировки также не должны быть связаны с ИТ-контуром. Уставки, минимальные и максимальные пороговые значения, алгоритмы защиты оборудования обязаны работать независимо от состояния корпоративной сети. Изменение этих параметров должно быть строго регламентировано и контролируемо внутри технологического сегмента.
Причина проста: вмешательство в эти механизмы влияет не на данные, а на физический процесс. Ошибка, некорректная настройка или несанкционированное изменение могут привести к выходу оборудования из строя, аварии или угрозе для персонала. Даже случайное изменение порога температуры или давления способно повлечь критические последствия.
Если функция напрямую влияет на безопасность людей и стабильность процесса, она должна оставаться автономной и изолированной. Централизация в таких случаях — это не оптимизация, а увеличение системного риска.
Мониторинг без иллюзии контроля
Перенос корпоративной логики тотальной наблюдаемости в АСУ ТП часто создаёт ощущение контроля, но не снижает реальные риски. В ИТ-среде системы мониторинга ориентированы на сбор максимального объёма телеметрии — статусы сервисов, события входа, старт и остановка процессов. В технологической сети такой подход редко даёт информацию о нарушении самого процесса.
Фиксация того, что станок работает или переключён в ручной режим, ещё не говорит о корректности его действий. Контроль должен быть сфокусирован не на объёме данных, а на событиях, изменяющих состояние системы.
Для АСУ ТП принципиально важны:
- загрузка новой логики в контроллер или изменение управляющей программы;
- корректировка уставок и пороговых значений;
- отклонения во временны́х циклах выполнения команд;
- команды, противоречащие технологическому регламенту.
Например, открытие задвижки при превышении допустимого давления — это событие, которое должно фиксироваться и интерпретироваться как потенциальный инцидент, даже если с точки зрения корпоративного мониторинга трафик выглядит легитимным.
Инженерно задача решается через пассивный анализ промышленного трафика с декодированием команд, а не только метрик состояния. Активное вмешательство, агрессивное сканирование или инспектирование пакетов без учёта временных характеристик может само стать причиной отказа.
В технологической среде мониторинг эффективен не тогда, когда фиксируется всё подряд, а тогда, когда отслеживаются изменения, способные повлиять на устойчивость процесса. Это принципиальное отличие от корпоративной модели наблюдаемости.
Регуляторные требования и эксплуатационная реальность
Ещё один источник конфликтов на стыке ИТ и АСУ ТП — формальное применение регуляторных требований без адаптации к специфике технологической среды.
Значительная часть нормативных мер разрабатывалась с ориентиром на корпоративные информационные системы, а затем была распространена на технологические сегменты. При буквальном применении это может приводить к избыточности или эксплуатационным противоречиям.
Например, требование регулярного обновления операционных систем и средств защиты информации может быть технически невыполнимым для устаревших рабочих станций или оборудования, функционирующего в рамках жёстко зафиксированных версий ПО. Закрытие отдельной уязвимости может потребовать замены всего узла, что в промышленной среде не всегда оправдано с точки зрения риска и затрат.
Попытка «выполнить любой ценой» в таких условиях создаёт риск остановки производства или нестабильной работы оборудования. Формальное соответствие не гарантирует эксплуатационной безопасности.
Баланс достигается через принцип компенсирующих мер. Если требование невозможно реализовать напрямую, организация должна предложить инженерное решение, снижающее риск альтернативным способом.
Например:
- невозможность обновления операционной системы компенсируется усиленной сегментацией, закрытием неиспользуемых сервисов и дополнительным мониторингом;
- устранение критической уязвимости без замены оборудования компенсируется ограничением доступа и контролем изменений.
Ключевой инструмент — реестр рисков АСУ ТП, в котором каждому требованию сопоставляются оценка вероятности и последствий, а также выбранные компенсирующие меры. Это позволяет обсуждать соответствие с регулятором в терминах управления рисками, а не только формального выполнения пунктов.
Таким образом, задача — не игнорировать требования, а адаптировать их с учётом технологических ограничений, документируя логику принятых решений.
Где теряется ответственность и как ее закрепить
Даже при корректной архитектуре риски на стыке ИТ и АСУ ТП остаются управляемыми только при чётком распределении ответственности. На практике же она чаще всего размывается между тремя контурами — ИТ, ИБ и эксплуатацией.
ИТ отвечает за инфраструктуру и связность. ИБ — за требования и контроль. Эксплуатация — за устойчивость технологического процесса. На стыке этих функций возникает зона, где решения принимаются без единого владельца последствий. Изменение конфигурации, внедрение средства защиты или открытие канала удалённого доступа могут быть технически реализованы одной стороной, но влияют на риски другой.
Ситуацию усугубляют управленческие ошибки. Первая — формальное объединение ответственности без реальной компетенции. Назначение одного руководителя «за всё» при недостаточной экспертизе в технологической или ИБ-сфере приводит к перекосу решений в сторону более понятного ему контура.
Вторая — некорректные показатели эффективности. Если ИБ-подразделение оценивается по проценту закрытых уязвимостей, возникает стимул устранять их любой ценой, даже если это влияет на стабильность процесса. Если ИТ измеряется только доступностью сервисов, риски технологической среды остаются вне фокуса.
Третья — внедрение решений подрядчиками без участия технологических специалистов. Типовой проект, реализованный без учёта реального процесса, формально соответствует требованиям, но создаёт эксплуатационные риски.
Закрепление ответственности требует институционального механизма: постоянной рабочей группы или технического комитета, где ИТ, ИБ и эксплуатация совместно принимают решения по изменениям на стыке сегментов. Любое изменение должно оцениваться не только с точки зрения соответствия требованиям, но и с точки зрения влияния на технологический процесс.
Без закреплённой модели ответственности даже правильные архитектурные решения со временем теряют устойчивость.
Культура взаимодействия: от конфликта к совместному проектированию
Технические решения не работают без изменения модели взаимодействия между ИТ, ИБ и эксплуатацией. Конфликт на стыке сегментов часто связан не с несовместимостью технологий, а с разрывом понимания.
ИБ-специалист, который не знаком с реальной производственной средой, склонен воспринимать технологическую сеть как очередной ИТ-контур с устаревшими настройками. Инженер АСУ ТП, не видящий логику мониторинга и анализа событий, воспринимает ИБ как источник дополнительных ограничений.
Изменить ситуацию возможно только через системное сближение команд.
Во-первых, совместные учения и разбор инцидентов. Моделирование сценариев с участием всех сторон позволяет увидеть, как решения одной команды влияют на риски другой.
Во-вторых, ротация и стажировки. ИБ-специалист должен понимать, как работает реальный технологический процесс, какие параметры критичны и какие задержки недопустимы. Инженер АСУ ТП должен видеть, какие события фиксируются в системах мониторинга и как интерпретируются с точки зрения риска.
В-третьих, совместное проектирование новых решений. Закупка оборудования, внедрение системы защиты или изменение архитектуры должны обсуждаться на этапе проектирования, а не постфактум. Если ИБ подключается только после внедрения, её роль неизбежно становится запретительной.
Наконец, необходимы отдельные бюджеты и прозрачные зоны ответственности. Конкуренция за ресурсы усиливает конфликт. Совместное планирование инвестиций снижает вероятность того, что архитектурные решения будут приниматься в одностороннем порядке.
Инженерная устойчивость достигается не только схемами сегментации, но и синхронизацией управленческих контуров.
Выводы
Сближение корпоративных и технологических сетей — уже не вопрос «нужно или нет», а вопрос того, кто и как управляет этой границей. Для ИТ-директора важно признать: при наличии связности именно корпоративная инфраструктура становится основным источником риска для АСУ ТП. Задача ИТ — не расширять контроль, а обеспечивать безопасный сервис для технологического контура. Любой канал доступа, обновления или интеграции должен проектироваться с приоритетом устойчивости производства, а не административного удобства.
Для директора по информационной безопасности принципиально важно сместить фокус с формального закрытия уязвимостей на управление эксплуатационными рисками. В промышленной среде последствия остановки процесса или аварии могут быть несоизмеримо выше риска утечки данных. Разговор должен вестись не только на языке CVE и отчётности, а на языке вероятности, последствий и допустимого уровня риска для технологического процесса.
Общий вывод — переход от запретительной логики к инженерной модели управляемого компромисса. Безопасность АСУ ТП — это отдельная дисциплина на стыке кибербезопасности и промышленной автоматизации. Её задача — не максимизировать контроль, а обеспечить устойчивость физического мира через корректно спроектированную цифровую границу.
Только в этой логике цифровизация и интеграция становятся не источником конфликта, а инструментом управляемого развития.
