Безопасность локальной LLM: от модели угроз к проверяемым ограничениям

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

Что именно защищаем

Составьте список: документы, переписка, учётные данные, настройки модели, результаты обработки и доступность сервиса. Для каждого актива укажите возможного нарушителя и последствия. Внутренний пользователь с обычной ролью, вредоносный документ, ошибочный администратор и внешний посетитель требуют разных проверок. Формулировка «система закрыта» не сообщает, как проходит аутентификация и кто обновляет контейнеры.

Риск-ориентированный подход NIST AI RMF предлагает управлять рисками в контексте применения, а не оценивать модель отдельно от процесса 1. Для небольшого проекта полезным артефактом станет таблица из нескольких десятков сценариев: что должно быть запрещено, каким механизмом, каким тестом и кто подтверждает результат. Не нужно превращать пилот в бесконечный каталог угроз; начните с наиболее тяжёлых последствий.

Документы не должны управлять приложением

OWASP рассматривает prompt injection и раскрытие чувствительных сведений среди угроз приложениям на основе LLM 2. Инструкция, найденная внутри документа, не становится поручением от пользователя. Поиск возвращает данные для анализа; право отправить письмо, изменить запись или выгрузить файл задаётся приложением отдельно.

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

Разделить контуры доступа

Контур	Минимальное ограничение	Проверка
Пользовательский API	Аутентификация, квоты, лимиты запросов	Чужая роль не получает данные
Поиск документов	Фильтрация по правам до контекста	Закрытый фрагмент не попадает в выдачу
Администрирование	Отдельный доступ и журнал изменений	Пользовательский токен не меняет настройки
Модельный сервер	Доступ только от приложения	Прямой внешний запрос отклоняется
Секреты	Отдельное хранение и ротация	Ключи отсутствуют в промптах и образах

Векторную базу также нужно защищать. Qdrant описывает сетевые меры, TLS и ключи с разными разрешениями 3. Эти возможности полезны, но не заменяют привязку документа к корпоративным ролям. Одна общая коллекция с общим ключом без фильтра прав способна отменить ограничения, которые аккуратно реализованы в файловом хранилище.

Проверить цепочку поставки

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

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

Как выглядит полезная приёмка

Тестовый набор должен содержать запросы к недоступным документам, инструкции внутри найденного текста, попытки вызвать запрещённый инструмент и превышение квот. Используйте безопасные синтетические сведения, по которым легко заметить утечку. У каждого теста должны быть ожидаемое поведение и проверяемый след в журнале без сохранения секретного содержимого.

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

Безопасность принимают по наблюдаемому поведению и документированным ограничениям. Абсолютное обещание защиты не заменяет эти результаты. В аудите инфраструктуры разумно начинать с одной рабочей цепочки и расширять её после исправления обнаруженных нарушений.