Удаленный доступ в промышленности обычно появляется не потому, что “так модно”, а потому что иначе дорого. Объект далеко, специалисты в дефиците, простой стоит денег, а подрядчик нужен “вчера”. И в какой-то момент в проекте возникает фраза, от которой у ИБ и АСУ ТП одновременно начинает дергаться глаз: “давайте сделаем удаленку”.
Дальше чаще всего происходит один из двух сценариев. В первом удаленный доступ делают “быстро”: пробрасывают порт, ставят RDP на контроллерный ПК, выдают общий пароль и надеются, что никто не заметит. Во втором сценарии удаленный доступ начинают “запрещать навсегда”, потому что страшно. Реальность, как обычно, посередине: удаленный доступ можно сделать и удобным, и управляемым, но для этого нужно понимать простую вещь.
Выбор протокола – это не выбор кнопки в настройках. Это выбор модели доверия. Кому вы доверяете, откуда, в каком объеме, как контролируете и как откатываетесь, если что-то пошло не так.
Ниже – практичная рамка, как выбирать протоколы и схемы удаленного доступа, если смотреть на мировой опыт, а не только на “как у нас принято”.
Сначала определяем задачу, а не протокол
Если сказать “удаленный доступ”, люди часто представляют одно и то же: инженер подключился к сети предприятия и “видит всё”. Но на практике задачи бывают разные, и под них нужны разные решения.
Один сценарий – удаленная диагностика и администрирование, когда вам нужно попасть на инженерный ноутбук/сервер SCADA/инженерную станцию. Второй – удаленное управление интерфейсом, когда оператору или технологу нужно открыть HMI/SCADA из другой локации. Третий – удаленный сбор данных, когда вы хотите только телеметрию и архив, но не хотите давать доступ к управлению. Четвертый – доступ вендора, когда внешняя компания должна периодически подключаться к оборудованию для сервиса.
CISA в своем руководстве по управлению удаленным доступом для промышленных сред как раз подчеркивает, что доступ “к OT” нужно рассматривать как удаленный даже если он технически внутри LAN, и дальше строить управление рисками вокруг того, куда именно и с какими правами человек попадает.
И это хороший принцип: не бывает “одного протокола на всё”. Бывает правильно выбранная архитектура, где протокол – просто инструмент.
Главная развилка: «сетевой туннель» или «доступ на уровне приложения»
Если упростить, есть две большие категории.
Первая – сетевые туннели (VPN). Вы как будто “прокладываете кабель через интернет” и даете удаленному пользователю виртуальное присутствие в сети. Это удобно для инженеров, но опасно, если не ограничить маршруты и права: через туннель можно случайно (или не случайно) попасть туда, куда вообще не планировали.
Вторая – доступ на уровне приложения. Вы не пускаете человека в сеть как таковую, а даете доступ к конкретному сервису: веб-интерфейсу, брокеру, API, удаленному рабочему столу через шлюз. Такой подход обычно лучше управляется, потому что “поверхность доступа” меньше.
В OT-мире сейчас явно растет популярность “управляемого доступа” вместо “полного VPN ко всему”. Это видно и по руководствам: например, в принципах безопасной связности для OT делается акцент на жестком укреплении границы, логировании, ограничении последствий компрометации и планах изоляции, то есть на архитектуре, а не на “подключили туннель и забыли”.
VPN-протоколы: IPsec, OpenVPN, WireGuard и почему выбор не только про скорость
VPN в промышленности любят за предсказуемость: подключился – и работаешь привычными инструментами. Но VPN бывает разный.
IPsec – зрелая технология, часто встроенная в промышленное сетевое оборудование и корпоративные политики. Она хороша там, где уже есть компетенции и стандарты эксплуатации. OpenVPN часто выбирают за гибкость и широкую поддержку. WireGuard стал популярным как “легкий” современный туннель с минималистичной моделью и хорошей производительностью; его устройство и криптографические свойства описаны в оригинальной работе Доненфельда, где подчеркиваются, например, PFS и выбранные примитивы шифрования.
Но важно: для промышленности “какой VPN быстрее” обычно не главный вопрос. Главный вопрос – как вы ограничите доступ внутри туннеля. В OT крайне опасно, когда VPN дает удаленному пользователю маршрут “во всю сеть”. Правильный дизайн обычно включает сегментацию, минимальные маршруты, правила межсетевого экрана, а часто – промежуточный узел (jump host), чтобы пользователь попадал не в OT сеть напрямую, а в контролируемую зону.
CISA отдельно выделяет необходимость более безопасного удаленного доступа к OT и рекомендует подходы, которые уменьшают экспозицию и упрощают контроль.
И вот здесь протокол VPN становится вторичным: IPsec, OpenVPN или WireGuard могут быть приемлемыми, если архитектура правильная, а эксплуатация зрелая.
RDP, VNC и «удаленный рабочий стол»: удобство, которое любят атакующие
Удаленный рабочий стол – самый понятный для бизнеса способ: “пусть инженер подключится и посмотрит”. Проблема в том, что протоколы удаленного рабочего стола исторически являются популярной точкой входа для злоумышленников, особенно если они выставлены наружу и защищены слабо. Даже в обзорных материалах по OT-экспозиции регулярно подчеркивают роль MFA для удаленного доступа, включая RDP, потому что такие каналы часто становятся “воротами” для атак.
Зрелая практика выглядит иначе: RDP не должен “торчать в интернет”. Его обычно прячут за VPN или, еще лучше, за шлюз/бастион с MFA и логированием, где доступ выдаётся по принципу “только туда, куда нужно”. В NIST SP 800-82 про безопасность ICS подход тоже архитектурный: сегментация, контроль удаленного доступа и учет специфики надежности/доступности систем управления.
Если коротко: удаленный рабочий стол сам по себе не зло. Зло – когда он становится прямым входом в OT без барьеров.
SSH: лучший “скальпель” для администрирования, если он не превращается в кувалду
SSH часто недооценивают в OT. Он не про красивые экраны, он про инженерную работу: попасть на Linux-шлюз, маршрутизатор, сервер, посмотреть логи, сделать минимальные изменения. Сильная сторона SSH – в том, что он хорошо дружит с ключевой аутентификацией, туннелированием и строгими политиками доступа.
Но и здесь действуют те же правила: SSH не должен быть “в интернет” напрямую, а учетные записи не должны быть общими. В нормальной схеме SSH живет внутри контролируемого контура (VPN/бастион), а у каждого действия есть след: кто зашел, когда, что делал.
HTTPS и веб-порталы: когда лучше дать “одну дверь”, чем “ключ от подъезда”
Если задача – дать доступ к SCADA-дэшборду, отчетам, истории, иногда к управлению через веб-интерфейс, то логично использовать HTTPS как транспорт. Он понятен, он хорошо поддерживается, и под него проще строить контролируемую аутентификацию и журналирование.
Но веб-доступ в промышленности должен быть не “просто сайт”. У него должна быть роль, сегментация, ограничения функций и, в идеале, вынесение наружу через DMZ/прокси, а не прямая публикация OT-сервера. Здесь полезно помнить мировую мысль из IEC/ISA-подходов: безопасность – это не одна настройка, а система уровней. Вокруг IEC 62443 часто описывают именно это: риск-ориентированная защита OT и требования к контролю доступа и зонной архитектуре.
MQTT, OPC UA и “данные наружу”: удаленный доступ без удаленного управления
Очень часто бизнесу на самом деле не нужен “удаленный доступ к управлению”. Ему нужны данные: состояние, тренды, KPI, диагностика. И тогда вместо того, чтобы давать инженеру вход в сеть, разумнее сделать поток данных наружу по контролируемым каналам.
Здесь появляются протоколы уровня IIoT: MQTT поверх TLS, OPC UA с безопасными соединениями, различные брокеры и шлюзы. И это принципиально другой класс решения: вы не открываете удаленному пользователю OT, вы “экспортируете” ограниченный набор телеметрии.
Это часто гораздо безопаснее и проще согласуется с ИБ. Цена – более сложная настройка модели данных и ответственности: кто публикует, кто подписывается, какие данные считаются истинными, как исключить несанкционированное управление через “обратный канал”.
Что реально выбирать: не “лучший протокол”, а подход под зрелость объекта
Чтобы не уйти в длинный список, вот короткая ориентировка в виде смысловой таблицы.
Смысл здесь один: чем менее зрелая инфраструктура и чем выше критичность объекта, тем сильнее вам нужен промежуточный слой контроля. И тем меньше вам нужен “прямой VPN во всё”.
Ошибка, которую делают почти все: путать удаленный доступ и удаленное доверие
Инженерно удаленный доступ – это техника. Организационно – это доверие. И большинство провалов происходит не из-за “не того протокола”, а из-за того, что:
- учетные записи общие и неотзываемые,
- нет MFA,
- нет журналов и мониторинга,
- нет ограничения по времени,
- нет процедуры “кто разрешил и зачем”,
- сеть плоская, и доступ “к одному ПК” фактически означает доступ “ко всему”.
Ровно поэтому в современных руководствах так много внимания уделяется принципам: ограничить последствия компрометации, логировать, укреплять границу, иметь план изоляции.
Протокол без этих принципов превращается в декоративную деталь.
Итог: как выбрать протоколы, чтобы потом спокойно жить с системой
Если сформулировать практично, выбор протоколов для удаленного доступа выглядит так.
Сначала вы честно отвечаете, что именно нужно: управление или данные, постоянный доступ или по заявке, один инженер или много ролей. Потом выбираете архитектуру: туннель или доступ к сервису, нужен ли бастион, где граница зон. И только после этого выбираете конкретный протокол: IPsec/OpenVPN/WireGuard для туннеля, SSH для администрирования, RDP через шлюз для удобства, HTTPS для порталов, MQTT/OPC UA для телеметрии.
И главное: в промышленности “удобно” должно означать “удобно под контролем”. Тогда удаленка действительно сокращает простой и облегчает сопровождение, а не создает новую точку риска.