LLM в корпоративной практике АСУ ТП: Политика данных, доступы и журналирование

Инженерная команда уже пробует чат-боты для ST, разбор логов и черновиков документации. Без правил это быстро превращается в неформальную утечку: в облако уходит архив проекта CODESYS, скриншот с IP-адресами шкафов, фрагмент OPC-карты или переписка с подрядчиком о уязвимости. Для АСУ ТП последствия не сводятся к «утёк текст» – это конфигурация производства, топология сети и иногда коммерческая тайна заказчика.

Ниже – как выстроить корпоративную практику: что запрещать загружать во внешние сервисы, как классифицировать данные, когда уместны локальные модели и когда облако допустимо только с рамками, зачем аудит и как LLM стыкуется с supply chain рисками. В конце – чек-лист ИБ из 10 пунктов для допуска LLM-инструмента в инженерную команду.

Что именно считается «данными АСУ ТП»

К данным относятся не только пароли. В зону риска попадают исходники проектов ПЛК/SCADA, экспорты конфигурации, схемы сети и адресация, описания технологических режимов, журналы аварий с привязкой к объекту, договоры и ТЗ с названием площадки, учётные записи и токены API, прошивки и контрольные суммы пакетов обновлений. Даже обезличенный фрагмент ST с уникальной логикой узла может позволить восстановить поведение оборудования.

Политика должна говорить простым языком: что нельзя отправлять в LLM вообще, что – только в утверждённый контур, что – можно в виде синтетического примера без привязки к объекту.

Запреты на загрузку проектов во внешние сервисы

Базовое правило для большинства предприятий: полные проекты, бэкапы шкафов, дампы БД SCADA и архивы с полевой конфигурацией не загружаются в публичные и неаттестованные облачные LLM, даже «временно для анализа». Исключения – только через письменное разрешение ИБ с указанием сервиса, срока, маскирования и ответственного.

Отдельно фиксируют запрет на личные аккаунты сотрудников для рабочих задач, вставку данных в браузерные расширения с неизвестной политикой хранения и использование мобильных приложений без корпоративного DLP. «Я только спросил у ChatGPT, почему не компилируется» – типичный инцидент, если в промпт попал реальный путь, IP или имя заказчика.

Классификация данных

Практичная схема для инженеров – три уровня (названия подставляют из внутреннего регламента предприятия):

Открытые / учебные – обобщённые примеры ST, типовые ошибки компилятора, публичная документация вендора без привязки к площадке. Допустимы в утверждённом LLM при соблюдении лицензий на ПО.

Внутренние – методики, шаблоны без адресов объектов, обезличенные фрагменты кода. Только корпоративный инструмент с договором о неиспользовании данных для обучения чужой модели (если это требование заказчика).

Конфиденциальные / критичные – всё, что идентифицирует объект, заказчика, сеть, safety, пароли, уязвимости. Запрет внешней LLM; при необходимости – локальная модель в изолированном контуре или ручная работа без автоматической отправки.

Классификация должна быть на одной странице в инженерном портале, а не в PDF на 80 листах, который никто не открывает.

Локальные модели и облако

Локальная или частная развёртка (on-prem, выделенный VPC заказчика) уместна, когда нужен черновик кода, поиск по внутренней базе знаний или суммаризация внутренних регламентов без выхода трафика в публичный интернет. Цена – администрирование, обновления модели, GPU, мониторинг и всё равно журналирование запросов.

Облачные SaaS-LLM иногда допускают для низкочувствительных задач (общие вопросы по стандарту, перевод публичного текста) при контракте Enterprise, запрете обучения на ваших данных и географии хранения по требованиям заказчика. Для АСУ ТП «бесплатный чат в браузере» почти никогда не проходит проверку ИБ.

Компромисс «локально для проектов, облако для всего остального» работает, если технически заблокированы обходы: личная почта, USB, скриншоты в мессенджеры.

Доступы и роли

LLM-инструмент – такой же корпоративный сервис, как Git или VPN: учётные записи по AD/LDAP, группы «инженер АСУ», «подрядчик с NDA», запрет общих паролей. Подрядчику не выдают доступ к внутренней базе промптов с объектными данными без отдельного соглашения.

Разграничение: кто может только читать шаблоны, кто может запускать запросы с внутренними данными, кто администрирует журналы. Инженер не должен иметь права отключать логирование «для скорости».

Журналирование и аудит

Минимум для допуска сервиса: кто, когда, какой класс данных (метка, не полный текст при высокой чувствительности), какой контур (локальный/облачный), идентификатор сессии. При инциденте должно быть возможно ответить, уходили ли на внешний API фрагменты с меткой «конфиденциально».

Регулярный аудит выборки (раз в квартал) ловит обходы: массовые запросы ночью, всплеск токенов с одной станции, попытки загрузить файлы .project, .zap16, архивы SCADA.

Supply chain и LLM

Риск цепочки поставок для LLM – не только «взломали OpenAI». Это плагины к IDE, непроверенные расширения «AI для CODESYS», сторонние обёртки с неизвестной политикой хранения, обновления локальной модели без контроля хеша. Тот же подход, что к инженерному ПО: реестр разрешённых инструментов, проверка обновлений на стенде, запрет установки «с сайта форума» на рабочую станцию OT.

Если LLM предлагает готовый блок кода или скрипт обновления – он проходит ту же ревью и тест, что и код коллеги; автоматическое копирование в прод запрещено политикой.

Чек-лист ИБ для допуска LLM-инструмента в инженерную команду (10 пунктов)

1.Утверждён класс данных и явный запрет на загрузку проектов ПЛК/SCADA и сетевых схем во внешние сервисы без исключений по заявке.

2.Выбран контур развёртывания (локальный / частное облако / SaaS) с описанием, где физически обрабатываются запросы и кто оператор.

3.Зафиксировано в договоре или DPA: не используются клиентские данные для обучения публичной модели (если требование заказчика/ИБ).

4.Настроена аутентификация (корпоративные учётки, MFA где принято), запрещены общие логины.

5.Включено журналирование запросов и ответов в объёме, согласованном с ИБ (с маскированием чувствительных полей).

6.Проведён DLP/технический контроль на инженерных станциях: блокировка неутверждённых LLM-URL и личных копий данных.

7.Описана процедура инцидента (утечка фрагмента проекта, подозрительный плагин) и контакты OT/ИБ.

8.Инструмент внесён в реестр разрешённого ПО; запрещены параллельные «теневые» аналоги.

9.Обучение инженеров: 5–10 минут на реальных примерах «можно / нельзя», с ссылкой на одностраничную памятку.

10.Определён владелец политики (ИБ + представитель OT) и срок пересмотра (не реже раза в год или при смене заказчика/контура).

Где уместен СТАБУР

При работе с проектами СТАБУР и CODESYS те же правила: бэкапы, StaburTarget, карты I/O и адресация RNDIS/Ethernet – конфиденциальные для большинства контрактов. LLM допустим для обобщённых вопросов по языку IEC 61131-3 или типовым ошибкам, но не как хранилище «живого» проекта объекта. Корпоративная политика защищает и заказчика, и интегратора от необратимой публикации конфигурации.

FAQ

Можно ли отправлять код, если убрать название завода?

Обезличивание помогает, но уникальная логика и адресация часто всё равно идентифицируют объект. Решение по классу данных, не «на глаз».

Локальная модель = безопасно?

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

Кто отвечает, если подрядчик залил проект в чат?

Ответственность задаётся договором; технически – блокировка и расследование по журналам, если контур был корпоративным.

Внутренняя перелинковка

•Промышленный GenAI, Structured Text и проверка кода;

•Supply chain и кибербезопасность OT;

•OT-сеть глубже VLAN: ACL, маршрутизация и доступ инженерных станций.