IEC 62443 на практике: С чего начать кибербезопасность АСУ ТП
2026-04-08 09:07
Стандарт IEC 62443 не про «купить один продукт и забыть». Это язык для того, чтобы разделить промышленную сеть на зоны, понять пути обмена между ними (кондуиты) и ввести минимально достаточные меры без парализации производства. На объекте чаще всего не хватает не «ещё одного фаервола», а инвентаризации, сегментации, учетных записей, обновлений и реагирования на инциденты.
Ниже - практический старт: зоны и кондуиты, план на 30/60/90 дней, типовые провалы и чек-лист аудита для цеха.
Короткий ответ
Начните с карты активов и потоков данных, затем разделите OT и IT и ограничьте кондуиты (где и чем разрешён обмен). За первые 30 дней закройте самое дешёвое по риску: пароли по умолчанию, лишний удалённый доступ, неучтённые USB и «плоскую» сеть. За 60-90 дней добавьте мониторинг критичных кондуитов, политику патчей и учения на отказ. Без владельца со стороны производства проект обычно застревает.
Зоны и кондуиты в двух словах
Зона - логическая и физическая группа активов с похожими требованиями к безопасности: например, сегмент ПЛК и приводов, сегмент SCADA, сегмент инженерных станций, гостевая сеть подрядчиков.
Кондуит - контролируемый канал между зонами: межсетевой экран с явными правилами, VPN с MFA, односторонний шлюз (data diode) где уместно, DMZ для сервисов, которые «смотрят» и в OT, и в IT.
Цель не «запретить всё», а снизить радиус поражения: компрометация одной станции не должна автоматически открывать путь ко всему цеху.
Минимальные меры за 30 дней
Неделя 1-2: видимость - Список критичных узлов: ПЛК, HMI, серверы SCADA, шлюзы, Wi‑Fi/радио, удалённый доступ. - Схема физических подключений «как на самом деле», не «как в проекте 2018 года». - Учётные записи: кто администратор, кто оператор, где общий пароль.
Неделя 3-4: быстрые победы - Смена паролей по умолчанию, отключение неиспользуемых учёток и сервисов. - Запрет или контроль USB на инженерных станциях (политика + технически где возможно). - Разделение гостевой сети подрядчиков от производственной. - Документ: кто имеет право на удалёнку и через какой канал.
Минимальные меры за 60 дней
Сегментация VLAN/маршрутизация или отдельные физические сегменты для критичных ПЛК.
Правила на межсетевых экранах: только необходимые порты и адреса, запрет широких any-any для OT.
Централизованное резервное копирование конфигураций ПЛК/SCADA и проверка восстановления.
Журналирование входов на критичные системы и смена политики паролей (длина, ротация, запрет общих).
Процедура ввода изменений в АСУ ТП (кто утверждает, как фиксируется версия).
Минимальные меры за 90 дней
Мониторинг и оповещения на кондуитах IT-OT (аномалии трафика, сканирование, нехарактерные протоколы).
План патчей: окна обслуживания, тестовый стенд, откат, исключения для legacy.
Учение: сценарий «заражённая инженерная станция» или «подозрительный трафик с HMI».
Взаимодействие OT и ИБ: единый регламент инцидентов и эскалации.
Типовые провалы (и почему они дорогие)
Провал 1: «у нас воздушный зазор»
На деле ноутбук подрядчика уже бывал в интернете и в тот же день - на шине с ПЛК.
Провал 2: один VLAN на всё
Любой заражённый ПК видит то же, что и SCADA-сервер.
Провал 3: вечный пароль admin
Уходит с объектом вместе с людьми, дублируется между площадками.
Провал 4: удалёнка без MFA и без журналов
После инцидента невозможно доказать, кто что менял.
Провал 5: нет владельца безопасности на стороне цеха
ИБ пишет политику, производство её обходит «чтобы не остановить линию».
Провал 6: игнорирование поставщика
Оборудование без обновлений и с известными уязвимостями. Имеет смысл заранее выбирать вендоров с прозрачной политикой обновлений; в линейках вроде СТАБУР это часть долгосрочной эксплуатации, а не разовой закупки.
Связка с уровнями Purdue / ISA-95 (упрощённо)
Уровень / зона
Типичные активы
Главный риск
Первая мера
Поле (датчики, приводы)
IO, частотники
физический доступ, подмена
маркировка, шкафы, учёт доступа
Управление (ПЛК)
контроллеры
прямой доступ из IT
сегментация, запрет маршрутизации «лишнего»
Надзор (SCADA)
серверы, HMI
учётки, RDP, SMB
MFA, разграничение, патчи
MES / производственные сервисы
БД, интеграции
учётные данные ERP
кондуит через DMZ, минимальные права
IT / корпоратив
почта, интернет
фишинг, вредонос
не смешивать с OT без шлюза
Чек-лист аудита для цеха (полевой)
Используйте как основу; дополняйте внутренним регламентом.
Доступ и люди - Список лиц с физическим доступом в шкафы АСУ ТП и к инженерным портам. - Журнал выдачи ключей и пропусков на период работ. - Политика для подрядчиков: отдельная сеть или выделенный ноутбук.
Сеть и сегментация - Нарисована схема: какие устройства в одном широковещательном домене / VLAN. - Нет ли прямого выхода ПЛК в интернет или в корпоративную сеть без шлюза. - Правила на фаерволах согласованы с фактическим обменом (OPC, RDP, SQL и т.д.).
Учётные записи - Нет общих учёток «оператор/инженер» без персонализации. - Отключены дефолтные логины на сетевом оборудовании и панелях. - Удалённый доступ только через утверждённый канал, с MFA где возможно.
Конфигурации и изменения - Версии проектов ПЛК/SCADA хранятся и подписаны датой/автором. - Изменения на пуске не вносятся «вживую» без фиксации в репозитории.
Обновления и уязвимости - Перечень критичных CVE по установленным ОС и ПО (хотя бы ежеквартально). - Окна обновлений согласованы с производством.
Реагирование - Контакт OT-ответственного 24/7 для инцидента. - Заготовлен сценарий изоляции сегмента без полной остановки линии (где применимо).
Физика - Закрыты незанятые порты USB/сетевые розетки. - Камеры/домофоны не в той же «доверенной» сети, что ПЛК, без необходимости.
Заключение
IEC 62443 на практике начинается не с сертификата на бумаге, а с дисциплины зон и кондуитов и с реальных владельцев на стороне цеха и ИТ. За 30 дней можно убрать очевидные дыры, за 60-90 - выстроить устойчивый контур мониторинга и обновлений. Главное - не строить «идеальную крепость» в PowerPoint, а внедрять меры, которые производство готово соблюдать каждый день.
FAQ
Нужно ли сертифицировать всё по IEC 62443 сразу?
Нет. Начинают с оценки риска и поэтапного усиления критичных зон.
Обязателен ли data diode?
Только для отдельных сценариев. Чаще достаточно фаервола, DMZ и строгих правил.
Кто должен вести проект: ИБ или АСУ ТП?
Совместно: ИБ задаёт рамки, АСУ ТП знает процесс и допустимые окна работ.
Что делать с устаревшим ПЛК без патчей?
Сегментация, запрет ненужных сервисов, контроль физического доступа, план замены.
Можно ли использовать облако для OT-данных?
Только через явный кондуит, шифрование, договор и классификацию данных.