AI Security: как защитить ИИ-продукт от угроз и требований ФСТЭК

Андрей Отинов -

В небольшом отделе разработки ИИ команда обнаружила новый чат‑бот, который обещает ускорить работу, но никто не знает, как его защитить. В этой статье мы разберём, что такое AI Security, какие требования к защите в России и как построить систему защиты от начала до конца.

Источник: Habr

Что такое AI Security и зачем это нужно

AI Security – это набор мер, которые защищают ИИ‑системы от внешних и внутренних угроз и обеспечивают их надёжность и соответствие требованиям. Внутри AI Security выделяют четыре направления: безопасность данных, защита модели, контроль доступа и мониторинг. Это часть более широкой области AI Safety, которая охватывает безопасность ИИ для пользователей и общества в целом. В России терминологию часто путают с MLSecOps – практикой управления безопасностью машинного обучения, но в реальности они пересекаются: обе фокусируются на защите данных и моделей.

Регуляторные требования в России

В России регулирование ИИ основано на конкретных требованиях к разработке и эксплуатации ИИ‑систем. Ключевые документы:

  • Указ Президента РФ № 490 «О развитии искусственного интеллекта» (2023 г.) – задаёт стратегию до 2030 года, вводит понятие «доверенного ИИ» с требованиями безопасности, недискриминации и недопустимости причинения вреда.
  • Приказ ФСТЭК № 117 от 11.04.2025 (вступил в силу 1 марта 2026 г.) – впервые закрепил защиту ИИ как отдельное обязательное мероприятие (пункты 34т, 60 и 61). Технические меры вынесены в методический документ 3.18 от 12.04.2026 «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах». Там указаны цели, объекты защиты, ссылки на угрозы ИИ‑систем из БДУ и требования соблюдения ГОСТа по разработке безопасного ПО.

Практические шаги защиты: от разработки к эксплуатации

Этап Что делать Как проверить
Разработка 1. Изолировать инфраструктуру разработки в отдельный сегмент.
2. Отказ от небезопасных форматов (pickle) в пользу ONNX/Protobuf.
3. Использовать обучающие данные только из доверенных источников, антивирусно проверять и хранить отдельно.
4. Анализировать известные уязвимости входной модели.
5. Применять физическую изоляцию среды, шифрование обучающих данных, состязательное обучение, ограничение диапазонов данных, санитизацию входа, тестирование на устойчивость к промпт‑атакам.		 Проверка логов, аудит кода, сканирование уязвимостей, тесты на промпт‑атаки.
Эксплуатация 1. Фильтрация входных и выходных данных.
2. Регистрация событий безопасности по запросам к системе.
3. Мониторинг и квотирование числа запросов.
4. Анализ уязвимостей ПО.
5. Изоляция ИИ‑системы в отдельный сегмент, обеспечение целостности параметров (весов) модели.		 Мониторинг журналов, анализ трафика, аудит конфигураций, проверка целостности модели.

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

Red Team и Blue Team: как тестировать и защищать

  • Red Team – команда, которая имитирует реальные атаки на ИИ‑систему: от подмены данных до промпт‑атаки и манипуляции весами модели. Цель – выявить уязвимости и оценить их влияние на бизнес.
  • Blue Team – команда, которая защищает систему, реагирует на атаки, обновляет модели, применяет патчи и улучшает политики доступа.

Взаимодействие Red/Blue Team позволяет быстро обнаруживать и устранять угрозы, а также повышать общую устойчивость ИИ‑продукта.

Что проверить и как действовать дальше

  1. Соберите карту рисков – перечислите возможные угрозы (промпт‑атаки, утечка данных, изменение весов) и оцените их вероятность и влияние.
  2. Проверьте соответствие нормативам – убедитесь, что ваша система соответствует пунктам 34т, 60 и 61 Приказа ФСТЭК № 117 и требованиям ГОСТа.
  3. Запустите Red Team‑тест – имитируйте атаки, проанализируйте результаты и обновите защиту.
  4. Настройте Blue Team‑мониторинг – включите фильтрацию, регистрацию событий, квотирование запросов и аудит модели.
  5. Проведите аудит безопасности – внешняя проверка поможет выявить скрытые уязвимости и подтвердить соответствие требованиям.

Краткая чек‑лист:

  • [ ] Изолирована инфраструктура разработки
  • [ ] Используются безопасные форматы (ONNX/Protobuf)
  • [ ] Данные из доверенных источников, антивирусно проверены
  • [ ] Проведён анализ уязвимостей модели
  • [ ] Настроен мониторинг и квотирование запросов
  • [ ] Регулярно проводятся Red Team‑тесты

Если все пункты выполнены, ваша ИИ‑система будет защищена от большинства известных угроз и соответствовать российским нормативам.

Источники

Дополнительные рекомендации по усилению защиты

Для повышения уровня безопасности ИИ‑продуктов рекомендуется внедрить следующие практики:

  • Регулярное обновление моделей – своевременно устанавливайте патчи и обновления для используемых фреймворков и библиотек машинного обучения.
  • Обучение персонала – проводите тренинги по безопасности ИИ для разработчиков, инженеров и администраторов.
  • Автоматизация тестирования – используйте инструменты для автоматического сканирования уязвимостей и проведения пентестов.
  • Создание плана реагирования на инциденты – разработайте процедуры для быстрого выявления, анализа и устранения угроз.
  • Внедрение принципов Privacy by Design – учитывайте требования к конфиденциальности данных на всех этапах разработки и эксплуатации ИИ‑систем.

Эти меры помогут не только соответствовать текущим нормативам, но и подготовиться к будущим изменениям в регулировании.

Заключение

AI Security – это не разовое мероприятие, а непрерывный процесс, требующий внимания на всех этапах жизненного цикла ИИ‑продукта. Соблюдение российских нормативов, внедрение практик Red/Blue Team и регулярный аудит позволяют минимизировать риски и обеспечить доверие пользователей. Начните с базовых шагов, описанных в этой статье, и постепенно расширяйте систему защиты по мере развития вашего продукта.

Практический пример: защита чат-бота в реальном проекте

Рассмотрим гипотетический сценарий: команда разрабатывает корпоративного чат-бота для обработки запросов клиентов. На этапе разработки они изолировали среду, использовали ONNX для модели и провели тесты на промпт-атаки. В эксплуатации настроили фильтрацию входных данных и мониторинг запросов. После запуска Red Team выявила уязвимость в обработке специальных символов, которую Blue Team оперативно исправила. В результате чат-бот успешно прошёл аудит и соответствует требованиям Приказа ФСТЭК № 117. Этот пример показывает, как описанные шаги работают на практике, снижая риски и повышая доверие пользователей.

Что почитать дальше