Кибербезопасная удаленка для подрядчиков в OT: Как дать доступ и не открыть весь цех
Временные доступы, MFA, jump host, журналирование, сегментация и практический регламент “доступ на 24 часа”
Подрядчики нужны в OT регулярно: пусконаладка, обновления, диагностика, поддержка редкого оборудования. Ошибка многих предприятий - давать «временный RDP/VPN», который на практике живет месяцами, без жестких ограничений по зоне, времени и действиям. В результате один сервисный доступ превращается в потенциальный вход во весь производственный контур.
Ниже - прикладной подход, как организовать удаленный доступ подрядчиков безопасно: временные доступы, MFA, jump host, журналирование, сегментация и четкий регламент «доступ на 24 часа».
Короткий ответ
Безопасная удаленка в OT строится по принципу минимального доступа на минимальное время с полной прослеживаемостью. Подрядчик не должен видеть сеть напрямую: только через jump host, с MFA, по заявке, в согласованное окно, с записью сессии и автоматическим отключением по таймеру. Если доступ нельзя быстро выдать и так же быстро закрыть по регламенту, схема небезопасна.
Почему «просто дать VPN» опасно
Типовые риски: - доступ выдан на всю подсеть вместо одного узла; - временная учетная запись остается активной после работ; - нет контроля команд и действий внутри сессии; - подрядчик подключается с неподконтрольного устройства; - одна учетная запись используется несколькими людьми.
В OT это особенно критично: ошибка в одном сегменте может повлиять на реальный технологический процесс.
Базовая архитектура безопасной удаленки в OT
Ключевая идея: подрядчик работает не «в сети OT», а в контролируемой точке доступа с трассируемой сессией.
Пять обязательных контролей
1) Временные доступы (JIT/JEA)
Выдавайте права только на окно работ. Роль и зона доступа должны создаваться под задачу и истекать автоматически.
2) MFA для всех внешних входов
MFA обязателен не только для VPN, но и для входа в jump host/бастион.
3) Jump host вместо прямого подключения
Запретите прямой доступ к ПЛК/SCADA из внешних сетей. Только через промежуточный узел в DMZ с контролем сессий.
4) Полное журналирование
Логируйте: кто вошел, когда, откуда, к какому узлу, что запускал, когда вышел. Для критичных работ - запись экрана/сессии.
5) Сегментация и allowlist
Подрядчик видит только нужный хост/сервис. Разрешения на уровне «подсеть целиком» в OT обычно избыточны и опасны.
Практический регламент “доступ на 24 часа”
Ниже шаблон регламента, который можно внедрять как операционный стандарт.
Роли
Шаги согласования и выдачи
Минимальные поля заявки на 24 часа
Критерии автоматического отзыва доступа
·истекло согласованное окно;
·подрядчик вне согласованного IP/устройства;
·попытка доступа к неразрешенному узлу;
·неактивность сессии дольше N минут;
·завершение работ подтверждено дежурным.
Что часто ломает даже хорошую схему
1.Исключения «на один раз» без фиксации в заявке.
2.Общие сервисные учетные записи для нескольких подрядчиков.
3.Отсутствие регулярного ревью активных доступов.
4.Логи есть, но никто не анализирует их по инцидентам.
5.Нет теста аварийного отзыва доступа.
KPI удаленного доступа в OT
Где уместен СТАБУР
Безопасная удаленка проще внедряется там, где OT-контур уже стандартизирован: предсказуемые сегменты, единые шаблоны доступа, понятные роли и контроль изменений. В платформенном подходе, включая проекты на базе решений СТАБУР, легче масштабировать регламент “24 часа” между площадками без ручного хаоса.
FAQ
Можно ли вообще запретить удаленку подрядчиков?
Можно, но это увеличит время простоя на диагностику и поддержку. Обычно эффективнее сделать удаленку управляемой и трассируемой.
Что важнее в первую очередь: MFA или jump host?
Оба обязательны, но jump host критичен для изоляции OT-активов и контроля сессии.
Нужен ли отдельный VPN для каждого подрядчика?
Лучше отдельные учетные записи и роли на подрядчика/инженера, а не общий «вендорский» доступ.
Какой срок хранения логов выбрать?
Опирайтесь на требования ИБ и расследований инцидентов; для критичных контуров обычно хранят дольше стандартного IT-уровня.
Как проверять, что регламент работает?
Проводите ежеквартальный тест: выдача доступа по заявке, наблюдение сессии, аварийный отзыв, проверка полноты логов.
Внутренняя перелинковка
IEC 62443 на практике;