Урок 3: ФСТЭК, приказ 117 и AI-угрозы — защита с 01.03.2026

Чему вы научитесь

• Разводить требования ФСТЭК по контурам: где действует приказ № 21, где № 31, где № 239, а где с 1 марта 2026 года включается приказ № 117 (Приказ ФСТЭК № 21, Приказ ФСТЭК № 31, Приказ ФСТЭК № 239, Приказ ФСТЭК № 117)
• Понимать, какие AI-угрозы надо включать в модель угроз уже в 2026 году: от отравления данных и LoRA-backdoors до prompt injection и кражи модели
• Превращать сроки ФСТЭК по уязвимостям в управленческий SLA: критические — 24 часа, высокие — 7 дней
• Понимать, почему для промышленной AI-системы почти всегда важнее целостность и управляемость, чем «красивый пилот в облаке» (Приказ ФСТЭК № 31)
• Собрать минимальный чек-лист для AI-системы в промышленности: данные, веса, интегратор, обновления, журналирование, тесты восстановления, режим подрядчика

С 1 марта 2026 года приказ ФСТЭК № 17 уходит, а приказ № 117 становится новой базой именно для ГИС и смежных систем госсектора (КонсультантПлюс; publication.pravo.gov.ru). Для промышленного предприятия это важно по двум причинам. Первая: многие AI-сервисы живут не в одном контуре, а сразу в трёх — ИСПДн, АСУ ТП и иногда КИИ. Вторая: в декабре 2025 года в БДУ ФСТЭК появился отдельный блок AI-угроз, и теперь «мы просто поставили LLM поверх базы знаний» больше не выглядит нейтральным техническим решением (БДУ АСУ ТП ФСТЭК).

Какой приказ ФСТЭК у вас главный

Главная ошибка руководителя — пытаться найти один «главный закон про AI». Его нет. Для промышленного AI-проекта обычно действует стек требований.

Что именно поменял приказ № 117

Если убрать юридическую форму, приказ № 117 делает три вещи сразу. Во-первых, заменяет старый приказ № 17 с 1 марта 2026 года (КонсультантПлюс). Во-вторых, переводит защиту из проекта «раз в три года прошли аттестацию» в режим постоянного измерения. В-третьих, заставляет оператора учитывать новые типы угроз и новые поверхности атаки — подрядчика, API, облачные компоненты, цепочку поставки и AI-модули.

flowchart TD
    A[Есть AI-система] --> B{Есть ПД?}
    B -->|Да| C[ИСПДн и приказ № 21]
    B -->|Нет| D{Система влияет на технологический процесс?}
    C --> D
    D -->|Да| E[АСУ ТП и приказ № 31]
    D -->|Нет| F{Объект значимый для КИИ?}
    E --> F
    F -->|Да| G[Приказ № 239 и связка с уроком 02]
    F -->|Нет| H{Заказчик — госсектор или ГИС?}
    G --> H
    H -->|Да| I[С 01.03.2026 добавляется приказ № 117]
    H -->|Нет| J[Берите № 117 как ориентир зрелости, но не подменяйте им № 31 и № 239]

Для CDTO вывод простой: если у вас AI-сервис прогнозирует отказ насоса, подсказывает оператору режим плавки или управляет очередью на ремонт, то вопрос не в том, «LLM это или не LLM». Вопрос в том, какие функции системы затрагиваются и в какой контур она встроена. Именно поэтому в уроке 02 про КИИ мы сначала определяем значимость объекта, а уже потом спорим о модели и вендоре.

Какие AI-угрозы включать в модель угроз

В исследовательском отчёте 07 декабрьский блок БДУ ФСТЭК по AI-угрозам сведён в две рабочие группы. Это удобная управленческая рамка: одна группа для этапа разработки, другая — для эксплуатации (БДУ ФСТЭК, раздел «Угрозы ИИ»).

Для промышленности особенно опасны не самые модные угрозы, а самые тихие. Prompt injection в офисном чат-боте часто кончается смешным ответом. Prompt injection в помощнике технолога может кончиться тем, что модель начнёт советовать оператору режим, который противоречит карте процесса. Adversarial-атака на CV-модель в рознице — это ошибка в классификации товара. Та же техника на контроле качества сварного шва или проката — это пропуск дефекта в реальный производственный цикл.

SLA по уязвимостям и метрики, которые меняют операционку

Исследовательский отчёт 07 фиксирует для приказа № 117 четыре управленчески важных требования: расчёт показателя защищённости Кзи не реже 1 раза в 6 месяцев, показателя зрелости Пзи — не реже 1 раза в 2 года, закрытие критических уязвимостей за 24 часа и высоких — за 7 дней. Даже если формально ваш проект сегодня живёт не в ГИС, эти цифры уже становятся нормой для зрелого AI-контура.

Здесь полезно связать урок 03 с уроком 01. Если ваш AI-сервис содержит персональные данные, то нарушение сроков по уязвимостям становится не только проблемой ФСТЭК, но и фактором риска по 152-ФЗ: утечка через логи, embeddings, admin-панель или backup может превратиться в инцидент с РКН и штрафом. Поэтому безопасный проект строится не по логике «сначала функциональность, потом ИБ», а по логике «одна дорожная карта на функциональность, ПД и ИБ».

Как применять это к AI-системе

Ниже — минимальный порядок для промышленного проекта. Он нужен до закупки и до подписания акта пилота.

1. Опишите функцию AI в терминах производства. Не «ставим нейросеть», а «модель влияет на выбор режима компрессора», «модель классифицирует дефект», «LLM подсказывает оператору действия». От этого зависит, попадаете ли вы в АСУ ТП по приказу № 31 или даже в значимый объект КИИ по приказу № 239.

2. Разметьте данные по типам. Телеметрия, технологические параметры, сервисные журналы, видео с линии, инструкции, ПД сотрудников и подрядчиков — разные классы риска. Если в логах есть ФИО, табельный номер, голос или видео, возвращайтесь к уроку 01 и применяйте ещё и контур 152-ФЗ.

3. Соберите карту компонентов. Модель, embeddings, vector DB, OCR, gateway, web-интерфейс, Git, контейнерный registry, VPN, jump-host, SIEM, backup. ФСТЭК проверяет не «модель как магию», а конкретные компоненты и каналы.

4. Проверьте происхождение артефактов. Для весов, LoRA-адаптеров, датасетов и пакетов нужны доверенный источник, хеш-сумма, процедура приёмки и запрет на прямую загрузку из интернета в промышленный контур. Для обучения на обезличенных примерах можно использовать внешние песочницы и arckep.ru, но не как канал прямого подключения к рабочему OT-контуру.

5. Встройте AI в существующий ИБ-процесс, а не рядом с ним. У модели должен быть тот же владелец инцидента, что у остальной системы: CISO, SOC, журналирование, резервирование, регламент обновлений, контроль доступа, процедура экстренного отключения.

6. Зафиксируйте деградационный режим. Если inference-сервис недоступен, производство не должно останавливаться из-за отсутствия AI. Должна существовать ручная или rule-based схема обхода. Для АСУ ТП это обязательная инженерная дисциплина, а не «избыточный перфекционизм» (Приказ ФСТЭК № 31).

7. Перенесите сроки ФСТЭК в договор с интегратором. Если подрядчик обслуживает AI-систему, SLA на устранение критических и высоких уязвимостей должен быть зеркален внутреннему регламенту. Иначе в момент инцидента у вас будет норматив на 24 часа, а в договоре — «исправление в следующем релизе».

8. Проводите тесты не только по качеству модели, но и по устойчивости. Отдельно — prompt injection, отдельно — отказ в обслуживании, отдельно — подмена документа в RAG, отдельно — восстановление из резервной копии. Это и есть практическое применение логики БДУ к AI-системе.

Что спросить у интегратора или внутренней команды до пилота

1. На какой приказ ФСТЭК вы опираетесь как на базовый: № 21, № 31, № 239 или № 117 — и почему?
2. Где лежат веса модели, кто проверяет их целостность и как вы запрещаете несанкционированную замену адаптеров?
3. Что произойдёт, если AI-сервис отдаст ошибочный совет или станет недоступен на рабочую смену?
4. Какой у вас список AI-угроз: только prompt injection или ещё data poisoning, adversarial и model theft?
5. Кто устраняет критические уязвимости ночью и в выходные, если SLA — 24 часа?
6. Как вы тестируете документы перед загрузкой в RAG, чтобы вредоносная инструкция не стала частью базы знаний?
7. Где журналируются действия модели, администратора и оператора, и кто имеет к этим журналам доступ?
8. Если это КИИ, как решение увязано с режимом из урока 02: категорирование, ГосСОПКА, запрет иностранного ПО и требования к подрядчику?

Итоги