IEC 62443 на практике: сегментируем АСУ ТП по модели zone & conduit без остановки производства

IEC 62443 в России долгое время был скорее академическим интересом - на него ссылались в методичках, упоминали на конференциях по промышленной безопасности, но реально применять начинали единицы. С приходом 187-ФЗ и требований ФСТЭК к значимым объектам КИИ ситуация сдвинулась: промышленные предприятия начали смотреть на стандарт не как на красивый документ IEC, а как на рабочую методологию. У нас сейчас идёт такой проект, и есть что рассказать.

Контекст задачи

Клиент - производственное предприятие, один объект КИИ второй категории значимости. Сеть сложилась исторически: SCADA-система оказалась в одном широком сегменте вместе с инженерными станциями, historian-сервером и куском корпоративной сети. Формально сегментация есть - VLAN-ы расставлены, - но firewall между корпоративной и промышленной частью фактически отсутствует: трафик ходит почти свободно, правила на граничном устройстве не менялись года три и представляют собой небольшой музей permit any.

Задача: привести сетевую архитектуру в соответствие модели zone & conduit из IEC 62443-3-3, не останавливая производство. Последнее - принципиальное условие заказчика. Технологический процесс непрерывный, плановая остановка раз в квартал по несколько часов. Работать нужно в эти окна и между ними, не затрагивая живые потоки данных.

Что такое zone & conduit в двух словах

В IEC 62443 промышленная сеть делится на зоны (zone) - группы систем с похожим уровнем доверия и требованиями безопасности - и каналы (conduit), через которые зоны общаются. Каждая зона получает уровень целевой защиты - Security Level (SL) от 1 до 4. Conduit - это не просто физическое соединение, а контролируемый и задокументированный переход: что именно ходит, как это фильтруется, кто авторизован.

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

Как выглядит работа на месте

Первый этап - инвентаризация и картографирование трафика. Перед тем как рисовать новые границы, нужно понять что реально происходит в сети. Мы поставили SPAN на граничный коммутатор и неделю смотрели на трафик пассивно - никаких изменений, только сбор данных.

Результат оказался предсказуемо неприятным:

• Корпоративные рабочие станции обращались напрямую к historian-серверу по протоколам, которые ни в каких регламентах не значились. Несколько человек из планово-экономического отдела выгружали исторические данные прямым SQL-запросом, потому что «так удобнее».
• Инженерные станции ходили в интернет через общий корпоративный прокси - те же маршруты, что и обычные рабочие станции бухгалтерии.
• Обновления ПО для ПЛК прилетали через общий файловый сервер без каких-либо дополнительных проверок.

Ни одна из этих историй не является катастрофой сама по себе. В совокупности это архитектура, в которой атакующий, получивший доступ к любой корпоративной машине, имеет прямую дорогу к промышленному сегменту. По классификации IEC 62443 вся эта конструкция - одна большая зона с минимальным уровнем защиты.

Проектирование зон

По результатам анализа трафика и интервью с технологами и инженерами АСУ ТП выделили четыре зоны:

• Корпоративная зона - офисные рабочие станции, корпоративные серверы, AD. SL-T 2.
• DMZ / зона передачи данных - historian в режиме только-чтение, интерфейсы интеграции с MES. SL-T 2-3. Именно сюда выносится точка обмена данными, а не в промышленный сегмент напрямую.
• Инженерная зона - инженерные станции, серверы управления SCADA. SL-T 3. Доступ только для авторизованных инженеров, без интернета, с жёстким контролем съёмных носителей.
• Полевая зона - ПЛК, датчики, исполнительные устройства. SL-T 3. Коммуникация только с инженерной зоной через строго определённые протоколы.

Conduit между корпоративной зоной и DMZ - промышленный firewall с deep packet inspection для промышленных протоколов. Между DMZ и инженерной зоной - отдельный firewall плюс однонаправленный шлюз (data diode) для потока данных из historian наружу.

Реализация без останова

Это самая интересная часть с точки зрения инженерии. Изменить маршрутизацию и добавить firewall в существующую сеть без разрыва потоков данных - задача, которую на бумаге решить проще, чем в реальности.

Схема, которую мы выбрали: параллельное развёртывание. Новый промышленный firewall - мы работаем с Cisco ASA в промышленном исполнении плюс Tofino для зоны ПЛК - устанавливается в режиме мониторинга рядом с существующим оборудованием. Несколько недель в таком режиме: трафик идёт как прежде, firewall только логирует что бы он заблокировал по новым правилам. Это позволяет выловить всё, что пассивный SPAN пропустил, и не положить производство правилом permit-deny в неподходящий момент.

Переключение на принудительную фильтрацию - в плановое окно. К тому моменту правила уже протестированы на реальном трафике, список легитимных соединений задокументирован, исключения согласованы с технологами. Не «вроде должно работать», а «мы это видели неделю, оно работает именно так».

Где мы сейчас

Параллельный режим идёт третью неделю. Список правил firewall в процессе согласования - часть легитимного трафика выявляется итерационно: технологи вспоминают про процессы, которые «всегда так работали» и о которых никто не сказал на первом интервью. Это нормально и ожидаемо.

Плановое окно для переключения - в конце июля. До этого ещё предстоит разобраться с historian: текущая схема, где планово-экономический отдел ходит напрямую, заменяется на репликацию в DMZ-сегмент с read-only доступом через стандартный OPC DA интерфейс. Пользователи не в восторге, но альтернатива - дыра размером с ворота - их убеждает быстро.

По аудиту АСУ ТП будем продолжать - переключение и первые недели после него дадут материал для отдельного поста.