VLAN и маршрутизация в OT: Практическая сегментация без «всё в одной подсети»
2026-04-22 16:18
На многих площадках OT-сеть исторически росла “как получилось”: новый шкаф - новый свитч, новая линия - еще один диапазон, а потом все это стягивалось в одну большую подсеть “чтобы точно пинговалось”. Пока контур маленький, схема живет. Когда появляются дополнительные линии, удаленная поддержка, historian, интеграции с MES/ERP и подрядчики, монолитная сеть становится источником рисков и простоев.
Сегментация в OT - это не мода из IT, а способ управлять отказами, безопасностью и диагностикой. Правильно построенные VLAN и маршрутизация снижают blast radius инцидента, делают правила доступа прозрачными и упрощают поиск проблем по трафику.
Короткий ответ
Практичная OT-сегментация начинается с зон и потоков данных, а не с “нарезать VLAN по шкафам”. Сначала фиксируют, кто и с кем должен общаться (особенно east-west внутри цеха), затем вводят ACL по принципу deny-by-default, и только после этого включают межсегментную маршрутизацию с контролируемыми исключениями.
Почему “одна подсеть на всё” перестает работать
Монолитная L2-сеть создает сразу несколько проблем:
•широковещательный шум и непредсказуемая деградация;
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 “мосты” между производственными сегментами не допускаются.
Минимальная матрица доступа (пример)
Откуда
Куда
Разрешено
Примечание
SEG-3 HMI
SEG-1/SEG-2 PLC
только технологические порты протокола линии
запрет общего сканирования сети
SEG-5 Eng WS
SEG-1/SEG-2 PLC
по заявке, через jump-процедуру
постоянный full-access запрещен
SEG-4 SCADA
SEG-1/SEG-2 PLC
чтение/запись по утвержденным сервисам
журналировать изменения
SEG-4 SCADA
SEG-6 DMZ
выгрузка historian/репликация
односторонние потоки где возможно
SEG-6 DMZ
SEG-7 Corp IT
строго ограниченные API/DB каналы
инспекция и аудит обязательны
Типовые ошибки внедрения
•VLAN нарезали, но межсегментные ACL оставили permit any any.
•Смешали инженерные ноутбуки и операторские HMI в одном сегменте.
•Оставили “временные” маршруты в проде после пусконаладки.
•Не предусмотрели отдельный сервисный контур для backup/NTP/обновлений.
•Нет стендовой проверки правил до выкатки в смену.
Исправляется это только дисциплиной: проектная модель потоков + MOC + регулярный аудит правил.
Где уместен СТАБУР
При тиражировании архитектуры между цехами важна не просто схема VLAN, а повторяемый стандарт зон, ACL и эксплуатационных процедур. В платформенном подходе, включая проекты на базе решений СТАБУР, легче поддерживать единый сетевой стандарт и снижать риск “локальных исключений”, которые ломают безопасность и доступность.
Заключение
Сегментация OT-сети - это инженерный инструмент управления риском, а не “галочка по безопасности”. Когда зоны определены по процессу, ACL документированы, east-west трафик прозрачен, а диагностика встроена в эксплуатацию, сеть становится предсказуемой даже при росте производства.
FAQ
Сколько VLAN нужно для старта сегментации?
Стартуйте с функциональных зон (обычно 5-7), а не с максимальной детализации. Избыточная дробность без процесса поддержки только усложняет эксплуатацию.
Можно ли оставить прямую L2-связь между линиями “для надежности”?
Как правило, нет. Это расширяет зону отказа и обходы политик доступа.
Что важнее: firewall или ACL на L3 core?
Оба слоя важны. ACL дают контроль внутри OT, firewall/DMZ - управляемую границу с IT и внешними контурами.
Как часто ревьюить ACL?
Минимум раз в квартал и после каждого крупного изменения линии/интеграции.
Нужно ли документировать “разовый” временный доступ?
Да. В OT именно “временные” исключения чаще всего становятся постоянной уязвимостью.