Подрядчики нужны в 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 часа” между площадками без ручного хаоса.
Заключение
Удаленный доступ подрядчиков в OT не должен быть компромиссом между безопасностью и скоростью. При правильной схеме с MFA, jump host, сегментацией, логированием и JIT-доступом на 24 часа можно поддерживать оборудование оперативно и без открытия лишних рисков для цеха.
FAQ
Можно ли вообще запретить удаленку подрядчиков?
Можно, но это увеличит время простоя на диагностику и поддержку. Обычно эффективнее сделать удаленку управляемой и трассируемой.
Что важнее в первую очередь: MFA или jump host?
Оба обязательны, но jump host критичен для изоляции OT-активов и контроля сессии.
Нужен ли отдельный VPN для каждого подрядчика?
Лучше отдельные учетные записи и роли на подрядчика/инженера, а не общий «вендорский» доступ.
Какой срок хранения логов выбрать?
Опирайтесь на требования ИБ и расследований инцидентов; для критичных контуров обычно хранят дольше стандартного IT-уровня.
Как проверять, что регламент работает?
Проводите ежеквартальный тест: выдача доступа по заявке, наблюдение сессии, аварийный отзыв, проверка полноты логов.