Безопасность RAG: как защитить базу знаний ИИ от утечек и инъекций

RAG (Retrieval-Augmented Generation) — самый популярный способ «научить» LLM вашим данным: модель во время ответа подтягивает документы из базы знаний. Удобно — и рискованно: именно эти документы становятся каналом атаки. В OWASP Top 10 для LLM это отдельная угроза (LLM08: Vector and Embedding Weaknesses). Разбираем, как защитить RAG.

Как устроен RAG и где его слабые места

Классический конвейер: документ → разбивка на фрагменты (chunks) → эмбеддинги → векторная база → поиск похожих фрагментов по запросу → подстановка в контекст модели → ответ. Атаковать можно каждое звено.

1. Косвенные инъекции через документы

Любой документ, попавший в базу знаний, во время ответа оказывается в контексте модели. Если в него встроена скрытая инструкция — модель может её выполнить. Особенно опасно, когда документы загружают сами пользователи (тикеты поддержки, резюме, договоры): один заражённый файл влияет на ответы другим пользователям. Это прямое продолжение темы prompt-инъекций.

2. Утечка чужих документов (нарушение изоляции)

Самый частый и опасный баг RAG. Если фильтрация доступа происходит после поиска (или не происходит вовсе), пользователь получает в ответе фрагменты документов, к которым у него нет прав. В мульти-арендных (multi-tenant) системах это прямая cross-tenant утечка — один клиент видит данные другого. По сути это IDOR на уровне базы знаний.

# ❌ УЯЗВИМО: сначала ищем по всей базе, потом (иногда) фильтруем
chunks = vector_db.search(query, top_k=10)          # ищет по ВСЕМ тенантам
answer = llm(context=chunks)

# ✅ БЕЗОПАСНО: фильтр доступа встроен в сам поиск
chunks = vector_db.search(query, top_k=10,
            filter={"tenant_id": user.tenant_id})      # только свои данные

3. Слабости векторной базы и эмбеддингов

Из эмбеддингов можно частично восстановить исходный текст (embedding inversion), а отравление базы (внедрение вредоносных «авторитетных» фрагментов) подменяет источники знаний и стабильно влияет на ответы модели в нужную атакующему сторону.

Как защитить RAG-систему

1. Разграничение доступа на уровне данных. Пользователь должен получать в контекст только те документы, на которые у него есть права, — фильтр внутри поиска, а не после.
2. Фильтрация загружаемого контента. Обрабатывайте документы как недоверенные: очищайте от скрытых инструкций, невидимого текста и подозрительного форматирования на этапе индексации.
3. Изоляция арендаторов. Отдельные пространства данных (namespace/collection) на тенанта; не смешивайте чувствительные данные в общей коллекции.
4. Защита векторного хранилища. Контроль доступа, шифрование, мониторинг аномальных запросов к базе.
5. Контроль источников. Проверяйте, что и кем попадает в базу знаний, чтобы исключить отравление; ведите provenance.
6. Обработка вывода модели как недоверенного (см. небезопасный вывод в OWASP LLM).

Экспертное наблюдение: почти в каждом втором RAG-проекте, который мы тестируем, изоляция документов реализована «на honor system» — фильтр по тенанту стоит в UI или в промпте, но не в самом векторном поиске. Достаточно чуть изменить запрос — и в контекст попадают чужие данные. Это находится за первые часы теста.

Как это проверяется

Главный тест RAG — попытаться из одного аккаунта получить чужие документы и провести инъекцию через загруженный файл. Мы делаем это в рамках тестирования безопасности RAG-систем, а для приложения целиком подойдёт пентест ИИ.

Читайте также: OWASP Top 10 для LLM, Prompt-инъекции.