Компания финансового сектора

КЛИЕНТ

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

ОТРАСЛЬ

Финансовый сектор.

ЗАДАЧА

В состав решения заказчика входили LLM, механизм RAG, векторная база данных, корпоративные источники данных и интеграции с CRM. Перед специалистами компании «КРЕДО-С» были поставлены ключевые задачи:

• Оценить риски использования LLM в корпоративном контуре;
• Определить достаточность реализованных организационных и технических мер защиты;
• Сформировать модель угроз, специфичных для архитектуры LLM/RAG.

ПРОБЛЕМАТИКА

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

Состав проектной команды «КРЕДО-С»: ведущий эксперт по кибербезопасности, ведущий специалист по информационной безопасности и руководитель проекта.

РЕШЕНИЕ

Экспертами «КРЕДО-С» выполнен полный цикл работ по анализу защищённости информационных систем с методикой, адаптированной под LLM/RAG:

• Анализ архитектуры LLM/RAG-решения и потоков данных;
• Определение границ доверия между пользователями, LLM, RAG, источниками данных и внешними сервисами;
• Анализ механизмов аутентификации и разграничения доступа;
• Оценка способов передачи корпоративной информации в LLM и её дальнейшей обработки;
• Анализ system prompts и механизмов ограничения поведения модели;
• Оценка безопасности RAG: формирование базы знаний, ingestion, retrieval и предоставление контекста модели;
• Анализ рисков prompt injection и indirect prompt injection;
• Проверка рисков получения пользователем информации, к которой он не должен иметь доступа;
• Оценка журналирования, мониторинга событий ИБ и возможностей расследования инцидентов;
• Моделирование специфичных для LLM/RAG угроз.

ВЫЯВЛЕННЫЕ НЕДОСТАТКИ

• Недостаточное разграничение доступа к данным, поступающим в RAG;
• Возможность влияния недоверенного содержимого документов на формируемый моделью ответ;
• Отсутствие достаточной фильтрации данных до передачи модели;
• Возможность раскрытия части системных инструкций;
• Избыточные права компонентов, взаимодействующих с корпоративными источниками;
• Недостаточное журналирование LLM-запросов и действий;
• Отсутствие специализированного мониторинга событий безопасности AI/LLM;
• Отсутствие формализованной модели угроз для LLM/RAG.

РЕЗУЛЬТАТЫ

• Оценка текущего уровня защищённости LLM/RAG-решения;
• Модель актуальных угроз;
• Реестр выявленных рисков;
• Рекомендации по архитектурным и техническим изменениям;
• Предложения по совершенствованию процессов эксплуатации и мониторинга;
• Roadmap устранения выявленных недостатков.

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ

Чем аудит безопасности LLM/RAG отличается от обычного аудита информационной безопасности?

Классические методики не покрывают специфику генеративных систем. В LLM/RAG размыты границы доверия между пользователем, моделью, механизмом извлечения и корпоративными источниками, а недоверенное содержимое обычного документа способно повлиять на ответ модели. Поэтому к стандартному анализу защищённости информационных систем добавляются проверки system prompts, ingestion и retrieval, а модель угроз строится отдельно под архитектуру решения.

Что такое prompt injection и indirect prompt injection?

Prompt injection — попытка пользователя инструкцией в запросе вывести модель за пределы предусмотренного сценария. Indirect prompt injection опаснее: инструкция прячется в самом документе, который попадает в базу знаний RAG, и срабатывает, когда модель берёт этот фрагмент в контекст. В проекте подтвердилась возможность влияния недоверенного содержимого документов на формируемый моделью ответ.

Какие недостатки чаще всего находятся в корпоративных LLM/RAG-решениях?

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

Нужно ли останавливать сервис на время работ?

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

Что заказчик получает по итогам?

Оценку текущего уровня защищённости LLM/RAG-решения, модель актуальных угроз, реестр выявленных рисков, рекомендации по архитектурным и техническим изменениям, предложения по процессам эксплуатации и мониторинга и roadmap устранения недостатков — с приоритетами, по которому можно планировать работы.

Другие проекты по безопасности ИИ: практическое тестирование LLM (AI Red Teaming) · обезличивание персональных данных для LLM и RAG.