Удалённый доступ вендора к АСУ ТП: почему VPN подрядчику - это слишком широко

Сложные станки, контроллеры и линии почти всегда обслуживает вендор, и часто удалённо: производитель сидит в другом регионе или стране, а чинить прошивку ПЛК надо здесь и сейчас. Схема живучая и удобная, но у неё есть неприятная изнанка. Скомпрометированная учётка подрядчика - один из самых частых векторов проникновения в промышленный сегмент. Атакующему не нужно ломать периметр завода, если можно зайти под доверенным вендором, которому и так открыт доступ. У одного заказчика мы этот доступ пересобирали - расскажу, что не так с привычной схемой и чем её заменить.

Почему постоянный VPN подрядчику - это слишком широко

Классика: вендору выдают клиентский или межплощадочный VPN, он поднимает туннель и попадает в сеть. Проблемы начинаются сразу.

Туннель пускает не к конкретному контроллеру, а в сегмент. Дальше подрядчик ограничен только тем, как нарезана сеть, а нарезана она в АСУ ТП исторически плоско. Учётка у вендора обычно одна на всю компанию-подрядчика, общий пароль знают несколько инженеров, и кто именно сидел в сессии, по логам не восстановить. Доступ выдан бессрочно и работает 24/7, хотя реально обслуживание случается пару раз в квартал по регламенту. Между сессиями туннель либо висит открытым, либо его поднимают по звонку, и никто не проверяет, тот ли это инженер и с того ли устройства.

Получается доверенный канал внутрь самого чувствительного сегмента, привязанный к учётке, которую вендор контролирует слабо. Это ровно та поверхность атаки, которую управление рисками поставщиков должно закрывать, а плоский VPN, наоборот, раздувает.

Что мы поставили вместо

Идея Zero Trust в промышленном контуре звучит так: вендору не доверяют канал, ему выдают доступ к конкретной системе, на конкретное окно, под запись. Сессия, а не туннель.

Собрали трёхслойно.

Бастион перед OT-сегментом. Подрядчик не попадает в сеть вообще. Он подключается к бастион-хосту в демилитаризованной зоне между корпоративной сетью и АСУ ТП, а уже бастион проксирует к целевому контроллеру или инженерной станции. Прямого маршрута от устройства вендора до ПЛК нет ни на одном этапе. Проброс файловой системы и буфера обмена по умолчанию выключен.

Доступ по заявке и окну. Никакого постоянного права. Инженер вендора подаёт заявку с указанием системы и планового окна, дежурный со стороны заказчика согласует. По истечении окна доступ отзывается автоматически. Механика та же, что мы описывали для JIT-доступа через PAM, только целевые системы здесь промышленные и согласование строже.

Запись сессии. Пишется не факт входа, а действия: что открывали, какие параметры меняли. Для промышленной среды это ещё и страховка при разборе - если после обслуживания линия повела себя не так, есть запись, что именно делал подрядчик.

Где OT ломает привычную IT-логику

Перенести сюда IT-подход один в один не выходит, и вот почему.

На ПЛК и промышленный контроллер нельзя поставить агент. Проверить состояние устройства так, как в корпоративной среде, не получится - модель угроз строится вокруг доступа к нему, а не на нём.

Ноутбук самого вендора почти всегда вне управления заказчика. Заставить производителя станка поставить ваш агент на свою машину нереально. Поэтому доверие переносится с устройства подрядчика на бастион: раз мы не можем проверить его ноутбук, мы не пускаем этот ноутбук в сеть вообще, только изолированную сессию через бастион.

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

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

Что осталось сложным

Честно, как всегда.

Часть вендоров требует собственный инструмент прямого подключения к контроллеру и упирается, когда его заворачивают через бастион. Здесь помогает не техника, а договор: требование к безопасному удалённому доступу проще заложить в контракт на обслуживание заранее, чем продавливать постом фактум.

Некоторые промышленные протоколы бастион нормально не проксирует. Для таких случаев оставили узкий проброс конкретного порта к конкретному узлу на время сессии, с записью на сетевом уровне - компромисс, но контролируемый и временный, а не постоянный туннель.

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

Итого

Zero Trust в промышленном контуре - это не запрет вендорам и не ещё один межсетевой экран. Это смена единицы доступа: не «доверенный туннель для подрядчика», а «сессия к конкретному контроллеру, на окно, через бастион, под запись». Скомпрометированная учётка подрядчика при такой схеме открывает не сегмент АСУ ТП, а одну согласованную сессию в известное время - и это принципиально другая величина ущерба.

Начинать стоит не с покупки продукта, а с ревизии того, кто и как сегодня ходит к вашим контроллерам снаружи. Такую инвентаризацию и модель доступа удобно собрать в рамках предварительного аудита.