Конвергенция ОТ и ИТ-сетей в 2026: data diode не справился, добавляем шлюз

Год назад мы завершили внедрение data diode между ОТ-сегментом и корпоративной сетью у заказчика - производственное предприятие, второй класс значимости по КИИ. Задача была типовой: обеспечить однонаправленную передачу телеметрии из SCADA в корпоративный DataLake без физической возможности обратного канала. Диод поставили, документацию оформили, плановую интеграцию сдали. А потом начался первый год эксплуатации.

Рассказываем, где конструкция не выдержала, и что с этим делать.

Почему вообще диод, а не просто МЭ

Требования ИЭК 62443 к сегрегации ОТ/ИТ не запрещают использование межсетевых экранов на границе зон - они требуют, чтобы риски канала управления были явно оценены и задокументированы. Для части производственных контуров с высоким классом последствий заказчик и служба безопасности пришли к выводу, что любое двунаправленное устройство на этой границе - это потенциальный вектор, который требует сложной компенсации: whitelist-трафик, сигнатурный контроль, отдельный мониторинг. Data diode проще: физически нет обратного канала - физически нет вектора с ИТ-стороны в ОТ. Регулятор принял аргументацию без замечаний. Так и пошли.

Где диод справляется хорошо

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

Второй сценарий - передача файлов: отчёты SCADA, архивы событий, экспорт конфигураций на аналитику. Тоже без проблем, настроили FTP-like канал поверх диода, работает.

Где диод не справляется

Проблемы начались с тем, что можно обобщить как «обратная квитанция».

Многие протоколы и приложения АСУТП неявно предполагают подтверждение доставки или запрос обновления со стороны приёмника. Не TCP-ACK на уровне сети - диод с этим справляется через проксирование. А логику уровня приложения: система мониторинга на корпоративной стороне хочет запросить исторические данные за конкретный интервал. SCADA-система хочет получить подтверждение, что файл отчёта принят. Historian-база на ИТ-стороне хочет запросить re-sync при рассинхронизации временных меток.

Ни один из этих сценариев не проходит через диод. Это не баг диода - это его природа.

Три конкретных случая за год:

• Historian-рассинхронизация. После планового обслуживания ОТ-сегмента корпоративный историан и SCADA разошлись по времени примерно на 40 минут. Автоматического re-sync нет - диод не пропустит запрос. Пришлось решать вручную через физический доступ к сегменту, выгружать дельту на носителе и заливать через процедуру «белого ящика». Дольше, чем хотелось бы.

• Алёртинг из SCADA. Система мониторинга на корпоративной стороне хотела подтверждать получение критических алёртов обратным сигналом - чтобы SCADA знала, что алёрт принят и не слал его повторно. Логика разумная, но через диод не работает. Пришлось на стороне SCADA выставить таймаут повторной отправки и смириться с дублями на стороне приёмника.

• Обновление конфигураций. Это самое болезненное. Оператор корпоративной сети захотел централизовать управление конфигами промышленного оборудования - выкатывать изменения через CMDB. Через диод это в принципе невозможно: конфиги идут в ОТ-сегмент, а не из него. Задача легла на полку до решения вопроса с архитектурой.

Что добавляем: однонаправленный шлюз

Чистое решение через второй диод в обратном направлении - тоже не ответ: тогда теряется главное преимущество, физическая гарантия отсутствия обратного канала.

После анализа остановились на добавлении однонаправленного шлюза (unidirectional security gateway) с управляемым протоколом для ограниченного числа разрешённых запросов с ИТ-стороны в ОТ. По сути это специализированное устройство, где разрешённые операции зафиксированы на уровне аппаратной прошивки и конфигурации, а не программных правил. Принципиальное отличие от МЭ: нет общего IP-форвардинга, нет статeful inspection - только явно разрешённые команды через строго типизированный API.

Архитектура после изменения:

[ОТ-сегмент / SCADA]
       |
  [data diode]      <- телеметрия, файлы (только из ОТ в ИТ)
       |
[корпоративная сеть]
       |
 [uni-gw шлюз]     <- ограниченные запросы (только из ИТ в ОТ)
       |
[ОТ-сегмент / SCADA]  <- через отдельный физический порт шлюза

Шлюз решает historian-синхронизацию и позволяет ограниченно передавать конфигурации в ОТ по согласованной процедуре. Алёртинг пока оставили как есть - дубли не создают проблем на практике.

Текущий статус: шлюз в тестовой эксплуатации, документация для обновлённой модели угроз в работе. Плановая проверка ФСТЭК, о которой мы писали в марте, показала, что инспекторов интересует именно обоснованность каждого элемента на границе ОТ/ИТ - так что документировать надо тщательно.

Что из этого следует

Data diode - правильный инструмент для однонаправленной телеметрии. Если весь ваш трафик идёт в одну сторону и никакой обратной логики на уровне приложения нет - он закрывает задачу надёжно и без избыточной сложности.

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

ИЭК 62443 не диктует конкретные технические решения - он требует, чтобы выбранная архитектура соответствовала оценённым рискам и была задокументирована. Комбинация диод + однонаправленный шлюз с разными физическими каналами под разные классы трафика в этот фрейм укладывается нормально. Главное - не смешивать каналы и чётко прописать, что через шлюз разрешено, а что нет.