Безопасность IoT и промышленных сетей (OT)

Камеры, датчики, контроллеры станков — это тоже сеть, и её взлом ведёт не только к утечке, но и к физическим последствиям.

OT (Operational Technology) — техника и сети, управляющие физическими процессами (производство, энергетика, вода); IoT — массовые подключённые устройства. Их безопасность отличается от привычной IT-безопасности и часто важнее.

Здесь ставки выше, чем «украдут данные». Сбой OT-системы способен остановить завод, нарушить подачу воды, навредить людям. Поэтому защита IoT/OT — отдельная дисциплина, и подходить к ней «как к обычному серверу» нельзя.

Зачем это знать защитнику

IoT-устройств в сети обычно больше, чем компьютеров, и каждое — потенциальная точка входа. А OT-системы десятилетиями строились в расчёте на физическую изоляцию (air gap), которой сегодня почти нет: их подключили к корпоративной сети ради удобства, не добавив защиты. Защитник обязан понимать эту специфику, иначе он применит IT-приёмы там, где они навредят.

Почему IoT-устройства слабы

• Заводские пароли. Многие устройства поставляются с одинаковым логином admin/admin и попадают в сеть как есть. Ботнеты массово сканируют интернет и логинятся такими парами — так собирались крупные IoT-ботнеты для DDoS.
• Редкие или отсутствующие обновления. Прошивку либо не патчат, либо обновить её нельзя в принципе; известные уязвимости живут годами.
• Слабая криптография и открытые протоколы. Незашифрованные каналы, захардкоженные ключи, открытые наружу управляющие порты.
• Большая поверхность и невидимость. Устройства плодятся, их забывают инвентаризировать; «теневой» IoT никто не мониторит.
• Лишние сервисы и доступ наружу. Камеры и роутеры часто включают UPnP и сами «пробивают» порт в интернет, а в прошивке остаются отладочные интерфейсы и облачные подключения, о которых владелец не знает.

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

Чем OT отличается от IT

Это важнейший раздел: в OT перевёрнут привычный приоритет.

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

Как это работает под капотом

В основе OT — PLC (программируемые логические контроллеры) и SCADA-системы, общающиеся по индустриальным протоколам (Modbus, Profinet, DNP3). Многие из них создавались без аутентификации и шифрования: предполагалось, что в эту сеть просто никто чужой не попадёт. Команда «остановить насос» и легитимная команда выглядят одинаково, потому что протокол не проверяет, кто её прислал. Эталон проектирования таких сетей — модель Purdue: иерархия уровней от датчиков (Level 0) и контроллеров (Level 1–2) через производственную зону к корпоративной сети (Level 4–5), с обязательной буферной зоной DMZ между OT и IT. Трафик между уровнями строго ограничен, и прямой связи «интернет → контроллер» быть не должно.

Как защититься

Главные слова для IoT/OT — изоляция и сегментация. Если устройство нельзя обновить или укрепить, его хотя бы запирают в отдельной зоне, откуда оно не дотянется до важного.

• Отдельная сеть/VLAN для IoT и OT. Устройства не должны находиться в одной сети с рабочими станциями и серверами. Между сегментами — межсетевой экран, разрешающий лишь необходимый трафик.
• OT-сеть изолирована от интернета и IT через DMZ. Никакого прямого выхода контроллеров в сеть общего пользования; обмен с IT — только через контролируемый шлюз в демилитаризованной зоне.
• Сменить дефолтные пароли, отключить лишнее. Уникальные учётные данные, закрытые неиспользуемые порты и сервисы, выключенный UPnP. Инвентаризация всех устройств — нельзя защищать то, о чём не знаешь.
• Пассивный мониторинг. Системы обнаружения вторжений, понимающие индустриальные протоколы, слушают трафик и поднимают тревогу при аномалиях (неожиданная команда контроллеру, новое устройство в сети), не вмешиваясь в процесс.
• Контроль обновлений и доступа. Патчи в плановые окна и после тестов; удалённый доступ — через защищённый шлюз с MFA, а не «проброшенный наружу» порт; принцип наименьшего доступа.
• Физическая безопасность. Доступ к контроллерам и портам — только авторизованным лицам.

Логику простейшего детектора аномалий в OT-трафике можно представить так:

ALLOWED = {"read", "status"}  # в норме мониторинг только читает

traffic = ["read", "status", "read", "write_setpoint", "read"]

for i, cmd in enumerate(traffic):
    if cmd not in ALLOWED:
        print(f"ALERT[{i}]: неожиданная команда контроллеру -> {cmd}")
    else:
        print(f"ok[{i}]: {cmd}")

Вывод:

ok[0]: read
ok[1]: status
ok[2]: read
ALERT[3]: неожиданная команда контроллеру -> write_setpoint
ok[4]: read

В реальности базовую линию «нормы» строят на наблюдении за трафиком, и отклонение (команда записи там, где её быть не должно) — повод для тревоги.

Любые проверки безопасности OT проводят только на разрешённых стендах: ошибка на боевом контроллере опасна физически, а несанкционированное вмешательство наказуемо (УК РФ ст. 273/274).

Итоги

• IoT-устройства слабы из-за дефолтных паролей, отсутствия патчей и слабой криптографии; их много и они часто невидимы.
• В OT приоритет — доступность и безопасность процесса, а не конфиденциальность; активное сканирование может навредить — нужен пассивный мониторинг.
• Базовая защита — изоляция и сегментация: отдельные VLAN, OT отделена от IT через DMZ (модель Purdue), никакой прямой связи с интернетом.
• Смена дефолтных учёток, инвентаризация, контроль доступа и обновлений, защищённый удалённый доступ — обязательная гигиена.
• Цена ошибки в OT — не данные, а физические последствия, поэтому осторожность критична.