OT-сеть глубже VLAN: ACL, маршрутизация и типовая ошибка «из офиса видно слишком много»

VLAN на коммутаторе даёт ощущение, что сеть уже «разделена». На практике этого часто хватает только для порядка в кабельной журнале. Как только появляется маршрутизатор с SVI между сегментами, общий шлюз для инженерных станций или «временный» доступ сотрудника IT из корпоративной подсети, граница OT снова становится прозрачной. Статья про то, что делать после VLAN: межсегментные ACL, осмысленная маршрутизация, доступ наладчиков через jump-host, журналы и снижение east-west риска внутри производственного контура.

VLAN отделяет широковещательные домены. Это полезно: меньше шума, проще адресация, понятнее зоны на схеме. Но VLAN не отвечает на вопрос «кто к кому может подключиться по TCP». Как только трафик между VLAN идёт через L3-устройство, без явных правил по умолчанию часто разрешено всё, что маршрутизатор умеет пересылать. Отсюда классическая картина пуска: из офисной подсети пингуется ПЛК, открывается веб-интерфейс частотника, виден файловый сервер SCADA на том же маршруте. Формально сегменты есть, фактически OT доступен слишком широкому кругу.

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

На промышленном коммутаторе или L3-шлюзе интерфейсы VLAN получают IP на SVI (Switch Virtual Interface) — логические адреса шлюзов для каждого сегмента. Именно через эти точки проходит межсегментный трафик. Их удобно считать контрольными постами: сюда вешают ACL, сюда смотрят логи, здесь же чаще всего ошибаются, открыв «для удобства» маршрут по умолчанию из OT в IT или обратно без фильтрации.

Разумная схема для многих объектов: минимум маршрутов между зонами, явный список разрешённых направлений (инженерная станция → ПЛК по нужным портам, сервер сбора → устройства поля, запрет всего остального). Маршрут «в интернет через корпоративный шлюз» из VLAN с ПЛК — отдельное осознанное решение с жёстким ACL, а не побочный эффект общей таблицы маршрутизации.

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

На практике полезно мыслить парами «источник зона → назначение зона → сервис». Например, VLAN инженерных станций может инициировать TCP к ПЛК на портах программирования, но VLAN камер или гостевого Wi‑Fi к тем же адресам не должен доходить вообще. Обратное направление (с ПЛК «наружу») часто ограничивают ещё жёстче: устройству поля редко нужен произвольный доступ в корпоративную сеть.

Типовая ошибка — симметричное «разрешить всё между OT-VLAN» ради скорости наладки. Через полгода никто не помнит, зачем SCADA-сегмент видит сегмент приводов целиком, а worm или скомпрометированная рабочая станция уже имеет east-west путь ко всему парку.

Наладчикам нужен доступ к ПЛК и HMI. Давать каждому ноутбуку прямой маршрут из корпоративной сети в OT — самый короткий путь к фразе «из офиса видно слишком много». Устойчивее схема с выделенной инженерной зоной (отдельный VLAN или физически изолированный сегмент) и входом через jump-host (bastion): сначала аутентификация на узле перехода, затем — только к разрешённым целям по ACL и по учётной записи.

Jump-host не заменяет ACL, но сужает точку входа и упрощает аудит: видно, кто и когда зашёл, с какого адреса открыл сессию к ПЛК. Прямой RDP с ноутбука заказчика на HMI в цехе без промежуточного контроля — то, что потом всплывает на разборе инцидента.

Если межсегментный трафик не логируется, после сбоя остаётся только догадка. Минимум, который окупается: отказ ACL (deny), сессии на jump-host, изменения конфигурации коммутатора и маршрутизатора, входы в ПЛК и SCADA. Хранение и доступ к логам — по регламенту предприятия; важно, чтобы OT-зона не была «слепой» только потому, что «у нас и так VLAN».

Внешний злоумышленник — не единственный сценарий. Чаще вред несёт горизонтальное движение внутри контура: заражённая инженерная машина, подрядчик с широкими правами, сервисный ноутбук на линии. Если все OT-VLAN видят друг друга без ограничений, компрометация одного узла быстро превращается в доступ ко всему участку.

Снижение риска — не один приём, а связка: узкие ACL между зонами, отсутствие лишних маршрутов, разделение «операторский HMI» и «инженерное программирование», запрет произвольного доступа между цехами без шлюза с политикой. VLAN здесь задаёт границы; ACL и маршрутизация — кто через эти границы проходит.

Ниже — текстовый каркас для согласования с OT и IT. Пароли, ключи и реальные IP в документ не включают; в эксплуатации подставляют утверждённые диапазоны.

Такой блок не заменяет проект сети, но даёт общий язык между наладкой, эксплуатацией и IT.

Контроллеры СТАБУР в OT-сегменте должны быть достижимы только с тех станций и по тем сервисам, которые зафиксированы в политике — загрузка проекта CODESYS, диагностика, опрос по согласованному протоколу. Широкий доступ «чтобы удобнее с ноутбука из офиса» увеличивает поверхность атаки и смешивает зоны ответственности; узкая схема с jump-host и ACL обычно дольше живёт на объекте без сюрпризов при смене персонала.

Граница нужна, но внутри OT без межсегментных правил east-west риск остаётся. VLAN плюс ACL на L3 — типичная пара.

Только с датой закрытия в заявке и возвратом к политике; иначе «временное» становится постоянным.

OT как владелец процесса и допустимых сервисов, IT как исполнитель на оборудовании — при явном разделении в регламенте.

•VLAN и маршрутизация в OT: практическая сегментация;

•OT/IT-конвергенция: как организовать без хаоса;

•Modbus TCP для интегратора: Unit ID, транзакции, таймауты и диагностика.