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

Базовые архитектурные принципы сопряжения

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

1. Физическая сегментация — приоритет везде, где она возможна. Технологическая сеть должна быть отделена от корпоративной не только логически, но и инфраструктурно. Если есть возможность физически разделить контуры — это необходимо делать. Там, где физическая изоляция невозможна, применяется строгая логическая сегментация через межсетевые экраны с минимально необходимыми правилами взаимодействия.
2. Минимизация связности. Связь между корпоративной и технологической сетью чаще всего создается «для удобства». На практике значительная часть транзитного трафика не является критически необходимой для производственного процесса. Если от канала можно отказаться — от него стоит отказаться. Любая связность должна быть обоснована эксплуатационной потребностью, а не организационным комфортом.
3. Контроль на границе сегментов. Если взаимодействие необходимо, граница должна быть формализована: отдельная зона сопряжения, ограниченные направления трафика, четко определенные протоколы и обязательное журналирование. Нельзя допускать размытой связности, при которой ИТ- и технологический сегменты фактически работают как единая сеть.
4. Разделение доменов и учетных записей. Недопустимо использовать общие учетные записи или единый домен для корпоративного и технологического сегмента. Разделение идентификационных контуров — базовое условие управляемости и расследуемости инцидентов.
5. Принцип локальности критических функций. Функции, влияющие на безопасность процесса — аварийная остановка, защитные блокировки, уставки и пороговые значения — должны оставаться автономными и не зависеть от доступности корпоративной инфраструктуры или внешних сервисов.

Эти принципы не означают отказ от цифровой интеграции. Они задают рамку, в пределах которой интеграция становится управляемой и не влияет на устойчивость технологического процесса.

Недопустимые и допустимые компромиссы

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

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

К ним относятся:

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

Такие решения могут казаться рациональными с точки зрения администрирования, но фактически уничтожают архитектурную модель изоляции.

Допустимые компромиссы возможны, но только при соблюдении инженерной дисциплины.

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

• создан тестовый стенд, воспроизводящий реальный процесс;
• обновления проходят предварительное тестирование;
• внедрение происходит по согласованному регламенту и в контролируемое окно.

То же касается удаленного доступа подрядчиков: он допустим при условии индивидуальных учетных записей, строгого ограничения по времени, журналирования действий и выделенной зоны сопряжения.

Ключевой критерий прост: удобство не должно определять архитектуру. Любой компромисс допустим только в том случае, если он не создает неконтролируемой зависимости между сегментами и не влияет на устойчивость технологического процесса.

Что нельзя централизовывать и выносить в ИТ-контур

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

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

Критические логики управления и защитные блокировки также не должны быть связаны с ИТ-контуром. Уставки, минимальные и максимальные пороговые значения, алгоритмы защиты оборудования обязаны работать независимо от состояния корпоративной сети. Изменение этих параметров должно быть строго регламентировано и контролируемо внутри технологического сегмента.

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

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

Мониторинг без иллюзии контроля

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

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

Для АСУ ТП принципиально важны:

• загрузка новой логики в контроллер или изменение управляющей программы;
• корректировка уставок и пороговых значений;
• отклонения во временных циклах выполнения команд;
• команды, противоречащие технологическому регламенту.

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

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

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

Регуляторные требования и эксплуатационная реальность

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

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

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

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

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

Например:

• невозможность обновления операционной системы компенсируется усиленной сегментацией, закрытием неиспользуемых сервисов и дополнительным мониторингом;
• устранение критической уязвимости без замены оборудования компенсируется ограничением доступа и контролем изменений.

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

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

Где теряется ответственность и как ее закрепить

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

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

Ситуацию усугубляют управленческие ошибки. Первая — формальное объединение ответственности без реальной компетенции. Назначение одного руководителя «за все» при недостаточной экспертизе в технологической или ИБ-сфере приводит к перекосу решений в сторону более понятного ему контура.

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

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

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

Без закрепленной модели ответственности даже правильные архитектурные решения со временем теряют устойчивость.

Культура взаимодействия: от конфликта к совместному проектированию

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

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

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

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

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

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

Инженерная устойчивость достигается не только схемами сегментации, но и синхронизацией управленческих контуров.

Стратегический вывод для ИТ- и ИБ-директоров

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

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

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

Только в этой логике цифровизация и интеграция становятся не источником конфликта, а инструментом управляемого развития.