VLAN и маршрутизация в OT: Практическая сегментация без «всё в одной подсети»

На многих площадках OT-сеть исторически росла “как получилось”: новый шкаф - новый свитч, новая линия - еще один диапазон, а потом все это стягивалось в одну большую подсеть “чтобы точно пинговалось”. Пока контур маленький, схема живет. Когда появляются дополнительные линии, удаленная поддержка, historian, интеграции с MES/ERP и подрядчики, монолитная сеть становится источником рисков и простоев.

Сегментация в OT - это не мода из IT, а способ управлять отказами, безопасностью и диагностикой. Правильно построенные VLAN и маршрутизация снижают blast radius инцидента, делают правила доступа прозрачными и упрощают поиск проблем по трафику.

Короткий ответ

Практичная OT-сегментация начинается с зон и потоков данных, а не с “нарезать VLAN по шкафам”. Сначала фиксируют, кто и с кем должен общаться (особенно east-west внутри цеха), затем вводят ACL по принципу deny-by-default, и только после этого включают межсегментную маршрутизацию с контролируемыми исключениями.

Почему “одна подсеть на всё” перестает работать

Монолитная L2-сеть создает сразу несколько проблем:

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

•сложность локализации инцидента (все “видят” всех);

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

•высокий риск lateral movement при компрометации одной точки;

•отсутствие понятной зоны ответственности между OT/IT.

В результате даже мелкая ошибка (неправильный сервис, loop, лишний multicast) влияет на весь участок.

От чего отталкиваться: зоны и потоки

Перед проектом сегментации зафиксируйте:

1.Критические активы: PLC, SCADA-серверы, historian, инженерные станции.

2.Направления обмена: north-south (вверх к MES/ERP) и east-west (между ячейками/линиями).

3.Допустимые протоколы и порты для каждой пары зон.

4.Требования по задержке и отказоустойчивости для производственных потоков.

Зона - это не просто VLAN ID, а набор активов с общим профилем рисков и одинаковыми правилами доступа.

ACL в OT: меньше “any-any”, больше предсказуемости

Рабочий подход для OT: разрешать только необходимое и документированное.

Базовые принципы:

•deny-by-default между зонами;

•разрешения по конкретным src zone -> dst zone -> protocol/port;

•отдельные правила для сервисного доступа (jump host, backup, мониторинг);

•обязательные комментарии/теги у каждого ACL-правила с владельцем и сроком ревью.

Если правило нельзя объяснить за 20 секунд, оно почти наверняка лишнее или опасное.

East-west трафик: главный слепой участок

В классических IT-проектах больше внимания north-south периметру. В OT часто критичнее east-west: связь между PLC, распределенными I/O, панелями оператора и локальными серверами линии. Именно там обычно прячутся “временные” исключения, которые потом ломают сегментацию.

Практика:

•инвентаризировать фактический east-west трафик до внесения изменений;

•выявить технологически обязательные потоки и “исторические” лишние;

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

Диагностика после сегментации: что должно быть под рукой

После внедрения VLAN/ACL команда должна уметь быстро ответить на вопрос “почему не ходит”:

•трассировка пути трафика через L3-границы;

•счетчики deny/hit по ACL;

•мониторинг latency/jitter по ключевым технологическим потокам;

•оперативный packet capture на пограничных точках зон;

•журнал изменений конфигурации с автором и причиной.

Без этих инструментов сегментация превращается в “черный ящик”.

Документирование правил: не бюрократия, а безопасность эксплуатации

Самая частая эксплуатационная ошибка - правила есть, но никто не помнит, зачем они. Через полгода появляется второй “временный allow”, потом третий, и политика доступа деградирует.

Минимальный набор артефактов:

•матрица межзонных доступов;

•схема L2/L3 границ с VLAN ID и VRF (если применимо);

•описание сервисных контуров (NTP, AD/LDAP, backup, антивирусные зеркала и т.д.);

•процедура MOC для сетевых изменений;

•периодический ревью ACL с удалением неиспользуемых правил.

Эталонная сегментация цеха (ASCII, 7 сегментов)

Ниже практичный референс, который можно адаптировать под конкретный участок:

Принцип маршрутизации: весь межсегментный трафик только через L3 OT Core и ACL-политику; прямые L2 “мосты” между производственными сегментами не допускаются.

Минимальная матрица доступа (пример)

Типовые ошибки внедрения

•VLAN нарезали, но межсегментные ACL оставили permit any any.

•Смешали инженерные ноутбуки и операторские HMI в одном сегменте.

•Оставили “временные” маршруты в проде после пусконаладки.

•Не предусмотрели отдельный сервисный контур для backup/NTP/обновлений.

•Нет стендовой проверки правил до выкатки в смену.

Исправляется это только дисциплиной: проектная модель потоков + MOC + регулярный аудит правил.

Где уместен СТАБУР

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

FAQ

Сколько VLAN нужно для старта сегментации?

Стартуйте с функциональных зон (обычно 5-7), а не с максимальной детализации. Избыточная дробность без процесса поддержки только усложняет эксплуатацию.

Можно ли оставить прямую L2-связь между линиями “для надежности”?

Как правило, нет. Это расширяет зону отказа и обходы политик доступа.

Что важнее: firewall или ACL на L3 core?

Оба слоя важны. ACL дают контроль внутри OT, firewall/DMZ - управляемую границу с IT и внешними контурами.

Как часто ревьюить ACL?

Минимум раз в квартал и после каждого крупного изменения линии/интеграции.

Нужно ли документировать “разовый” временный доступ?

Да. В OT именно “временные” исключения чаще всего становятся постоянной уязвимостью.

Внутренняя перелинковка

Промышленный Wi‑Fi и беспроводные датчики;

RBAC в АСУ ТП ;

IEC 62443 на практике.