Чек-лист безопасности LLM-системы перед запуском: 37 пунктов и критерии провала

Перед запуском LLM-системы стоит пройти 37 проверок, сгруппированных по девяти областям: данные и права, ввод и prompt injection, обработка вывода, инструменты и действия агента, секреты и журналы, модель и зависимости, лимиты и отказоустойчивость, мониторинг и реагирование, тестовый набор атак. Каждый пункт можно проверить за один-два прогона, а в конце группы указано, что считается провалом: если провал найден, запуск откладывается до исправления.

Это самопроверка для команды, которая запускает систему, а не аттестация и не лицензируемая работа. Лицензии ФСТЭК у нас нет, аттестацию и оценку соответствия мы не проводим. Чек-лист помогает найти типовые дыры до того, как их найдёт кто-то другой, и подготовить систему к разговору со службой безопасности.

Как пользоваться чек-листом безопасности LLM-системы

Пункты пронумерованы по группам (1.1, 2.3 и так далее), чтобы на них можно было ссылаться в отчёте. Для каждого пункта нужен один из трёх ответов: выполнено и проверено, выполнено, но не проверено, не выполнено. Второй ответ приравнивается к третьему: непроверенная защита ничего не гарантирует.

Для каждой группы указано, как проверить и что считается провалом. Критерий провала лучше записать до начала проверки, иначе отчёт превращается в набор впечатлений. Ответы модели недетерминированы, поэтому атакующие сценарии повторяем несколько раз: один успешный отказ ещё не значит, что защита работает.

Отдельные требования зависят от контура. Если система обрабатывает персональные данные, действует 152-ФЗ; если объект относится к критической информационной инфраструктуре, действует 187-ФЗ. Эти требования чек-лист не заменяет; категорирование КИИ и аттестацию мы не проводим. Общую картину угроз описывает материал «Безопасность нейросетей», механику атаки — статья «Что такое prompt injection».

Данные и права: что проверить в первую очередь

• 1.1 Составлен перечень данных, которые попадают в запрос к модели: документы, поля из систем, история диалога. Отмечено, какие из них персональные или ограниченного доступа.
• 1.2 Права проверяются при поиске и выборке данных, до того как текст попал в запрос к модели. Группы пользователя берутся из шлюза, а не из текста запроса.
• 1.3 Данные пользователей с разными правами не смешиваются в кэше ответов, в истории и в индексе. Общий кэш либо отсутствует, либо учитывает набор прав.
• 1.4 Права обновляются: у уволенного сотрудника и у перенесённого или удалённого документа доступ исчезает в пределах согласованной задержки.
• 1.5 Запросы и документы не уходят внешним сервисам, в том числе для «улучшения качества» у поставщика модели. Это подтверждено настройками и сетевыми правилами.

Как проверить

Два пользователя с разными правами задают один и тот же вопрос по закрытому документу. Затем у одного из них отзывают права и повторяют вопрос. Отдельно изучают, что лежит в кэше и в истории. Сетевые правила проверяют отключением внешнего канала и просмотром журнала межсетевого экрана.

Что считается провалом

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

Ввод и prompt injection: как проверить защиту от подмены инструкций

• 2.1 Системные инструкции отделены от пользовательского ввода и от внешних данных. Документы, письма и страницы передаются как данные, а не как команды.
• 2.2 Защита одним системным промптом не считается границей безопасности. Ограничения опираются на права, подтверждения и проверки вне модели.
• 2.3 Составлен перечень источников, которые попадают в контекст (документы, почта, веб-страницы, ответы систем), и для каждого понятно, кто может в них писать.
• 2.4 Для каналов, где пишут недоверенные люди, включены дополнительные меры: фильтрация, урезанный набор инструментов, отсутствие чувствительных действий в том же сеансе.
• 2.5 Размер и формат ввода ограничены; скрытый текст (невидимые символы, белый текст на белом фоне, текст на изображениях) обрабатывается осознанно.

Как проверить

Подготовить набор прямых и косвенных инъекций: фразы в сообщении, скрытые инструкции в тестовом документе и письме, попытки вынуть системный промпт. Прогнать каждую несколько раз и записать результат. Подробнее о механике — в статье про prompt injection.

Что считается провалом

Модель выполняет инструкцию из данных, меняет роль или правила, раскрывает системные инструкции или совершает действие, которого пользователь не просил.

Вывод модели и его обработка: XSS, исполнение кода и утечка через ссылки

Ответ модели формируется из текста, на который влияют пользователи и документы. Поэтому для любого кода, который принимает ответ, он недоверенный ввод.

• 3.1 Ответ модели нигде не считается безопасным: любая программа, получающая его, проверяет и экранирует данные как пользовательский ввод.
• 3.2 Интерфейс экранирует HTML и разметку. Ссылки и картинки из ответа не загружаются автоматически с внешних адресов: такой запрос может унести данные в адресе.
• 3.3 Ответ не передаётся в командную строку, интерпретатор, выполнение выражений или шаблонизатор без проверки. Запросы к базе строятся с параметрами и выполняются от учётной записи только на чтение.
• 3.4 Структурированный вывод (например, JSON для другой системы) проверяется по схеме, значения сверяются с допустимыми диапазонами и перечнями.

Что считается провалом

Разметка из ответа выполняется в браузере; при открытии ответа идёт обращение к внешнему адресу; ответ модели попадает в команду или запрос без проверки.

Инструменты и действия агента: права, подтверждения, лимиты

Если у системы есть инструменты (отправка писем, запись в учёт, обращение к файлам и сети), она становится агентом. Последствия ошибки или атаки тогда измеряются не текстом, а действиями.

• 4.1 Составлен перечень инструментов и действий; у каждого указан уровень: чтение, черновик, запись, удаление, внешняя отправка, деньги.
• 4.2 У агента отдельная учётная запись с минимальными правами. Он не работает от имени администратора и не наследует права пользователя целиком.
• 4.3 Действия выше чтения и черновика требуют подтверждения человека, который видит, что именно будет сделано. Подтверждение не сводится к кнопке «ок» без содержания.
• 4.4 Заданы лимиты: число действий и шагов за сеанс, допустимые суммы. Есть аварийный выключатель, который проверялся.
• 4.5 Инструменты для сети и файлов ограничены списками адресов и каталогов: нельзя обратиться к внутренним службам и выйти за пределы разрешённой папки.

Как проверить

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

Что считается провалом

Действие вне перечня выполнено без подтверждения; агент обратился к внутреннему адресу или файлу вне разрешённых; лимиты можно обойти повторными запросами; выключатель не отключает агента.

Секреты и журналы: где хранить ключи и что записывать

• 5.1 Ключи, пароли и токены не лежат в системном промпте, в индексе документов, в репозитории и в переменных, видимых модели. Исходим из того, что системный промпт может быть извлечён.
• 5.2 Ключи доступа персональные, с ограниченным сроком и возможностью отзыва. Общих ключей нет.
• 5.3 Журнал фиксирует, кто спрашивал, когда, какие фрагменты найдены, какая версия модели и шаблона отвечала, какие действия выполнены. Доступ к журналу ограничен, хранилище зашифровано, срок хранения задан.
• 5.4 Персональные данные в журнале маскируются либо хранятся по решению ответственного лица, срок согласован.

Как проверить

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

Что считается провалом

Секрет найден в промпте, индексе или репозитории; один ключ используют несколько человек или сервисов; журнал читает широкий круг; по журналу нельзя восстановить, кто и что спрашивал.

Модель и зависимости: происхождение, формат весов, версии

• 6.1 Источник, версия, контрольная сумма и лицензия каждой модели записаны в реестре, происхождение подтверждено.
• 6.2 Формат весов не исполняет код при загрузке. Загрузка кода из репозитория модели выключена либо этот код прочитан и принят.
• 6.3 Версии пакетов и образов зафиксированы, получены из внутреннего зеркала, образы просканированы на известные уязвимости.
• 6.4 Серверам моделей закрыт исходящий трафик, доступ к серверу инференса только через шлюз.

Как проверить

Сверить контрольные суммы с опубликованными источником. Развернуть систему с нуля без интернета. Просмотреть журнал межсетевого экрана на исходящие попытки с серверов моделей. Попробовать обратиться к серверу инференса напрямую с рабочего места. Порядок доставки весов разобран в статье «Как развернуть LLM в закрытом контуре».

Что считается провалом

Файл весов неизвестного происхождения; формат с исполнением кода при загрузке принят без разбора; зависимости ставятся из интернета; с сервера моделей идут внешние соединения.

Лимиты и отказоустойчивость: что будет при нагрузке и отказе

• 7.1 Заданы лимиты на число запросов пользователя, длину ввода и ответа, время запроса и число одновременных запросов. Защита нужна и от злоупотреблений, и от случайной перегрузки видеокарты.
• 7.2 Очередь ограничена, интерфейс сообщает о перегрузке, пакетные задачи (индексация) не мешают интерактивным.
• 7.3 Описано поведение при отказе: что видит пользователь, и система не выполняет действий без проверок, если проверяющий компонент недоступен.

Как проверить

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

Что считается провалом

Один пользователь занимает всю систему; запрос висит без ограничения по времени; при отказе компонента проверки агент продолжает действовать.

Мониторинг и реагирование на инциденты

• 8.1 Видны и журналируются отказы фильтров, срабатывания лимитов, необычные объёмы запросов, нетипичные обращения к инструментам.
• 8.2 Назначен ответственный и канал оповещения; описано, что считается инцидентом.
• 8.3 Есть порядок действий: отключить агента или канал, отозвать ключи, сохранить журналы, оценить, какие данные затронуты, кого уведомить. Порядок отработан на учебной тревоге.

Как проверить

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

Что считается провалом

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

Тестовый набор атак: как превратить проверку в повторяемую

• 9.1 Набор хранится в репозитории и включает прямые и косвенные инъекции, обходы ограничений, попытки извлечь системный промпт, обход прав, злоупотребление инструментами и слишком длинные входы.
• 9.2 Набор запускается перед каждым релизом и после смены модели, шаблона запроса или индекса; результаты сохраняются.
• 9.3 Каждая найденная проблема превращается в тест. Критерий провала для каждого сценария записан до запуска.
• 9.4 Каждый сценарий выполняется несколько раз, результаты сравниваются между версиями: единичный отказ модели не доказывает устойчивость.

Как проверить

Запустить набор на текущей версии и на предыдущей и сравнить. Убедиться, что набор запускается автоматически, а результат читается человеком. Для вспомогательной автоматизации существуют открытые средства для проверки LLM; их выбор и применимость определяются под вашу систему, основная часть сценариев пишется под вашу архитектуру.

Что считается провалом

Набора нет; проверка разовая и ручная; критерий успеха определяется «на глаз»; после смены модели набор не запускали.

Как оценить результат самопроверки и что делать дальше

Результат удобно свести к решению о запуске. Ориентир такой:

Если нужен взгляд со стороны, делаем аудит безопасности ИИ-системы: обследование стоит 200 000 ₽ для одной системы и 350 000 ₽ для нескольких, на выходе отчёт с критичностью, воспроизведением и исправлениями. Исправления идут этапами, цены — на странице тарифов. Проверка идёт на вашем стенде, как описано в разделе «Защита и аудит ИИ»; атаки на модель отдельно разбирает Red Team LLM. Аттестацию и лицензируемые работы мы не выполняем.