Инженерная команда уже пробует чат-боты для 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
Можно ли отправлять код, если убрать название завода?
Обезличивание помогает, но уникальная логика и адресация часто всё равно идентифицируют объект. Решение по классу данных, не «на глаз».
Локальная модель = безопасно?
Нет автоматически: остаются журналы, доступы, утечки через бэкапы диска и неправильную сегментацию сети.
Кто отвечает, если подрядчик залил проект в чат?
Ответственность задаётся договором; технически – блокировка и расследование по журналам, если контур был корпоративным.
Обсуждение