📚 Безопасность RAG-приложений как поверхности: защита архитектуры развёртывания retrieval-augmented generation

Целевая аудитория: Команды, разворачивающие RAG-приложения — ассистенты по базе знаний, doc-QA, корпоративный поиск-копилот; инженеры, проектирующие конвейер «ингест → эмбеддинг → векторная БД → ретривер → LLM».

Эта страница смотрит на RAG как на поверхность развёртывания, а не как на каталог атак: где физически сидит контроль в архитектуре, кто получает доступ к чему и как данные текут от ингеста до ответа. Конвейер RAG имеет четыре стадии плоскости данных — (1) ингест → (2) эмбеддинг-модель → (3) векторная БД/индекс → (4) ретривер → LLM — и у каждой свой класс рисков и своё правильное место для защиты. Полный таксономический разбор угроз RAG (отравление, инверсия эмбеддингов, инъекция через документы как класс) — в отдельном пилларе Безопасность RAG-систем; здесь же фокус на архитектуре и развёртывании: какой контроль ставить на ингесте, какой на векторной БД, какой между ретривером и индексом. Когда стоит задача обеспечить безопасность RAG на уровне развёртывания, защищать нужно каждую стадию конвейера по отдельности — потому что контроль, поставленный не на той стадии, не закрывает риск.

SYNTREX (защитный слой Spectorn) работает на двух стадиях конвейера: на ингесте пре-фильтрует документы на встроенные инструкции и индикаторы отравления, а на ретриве инспектирует втянутый контент перед тем, как он попадёт в контекст LLM, маскирует утечку PII и секретов из чанков и ведёт неизменяемый журнал решений. SYNTREX работает в составе платформы Spectorn и разворачивается standalone на внутреннем контуре заказчика.

Эта страница разбирает риски развёртывания RAG в терминах OWASP Top 10 для LLM-приложений (2025) и техник MITRE ATLAS — и показывает, какие движки SYNTREX закрывают каждый вектор и на какой стадии.

🛑 Ключевые риски и как SYNTREX их закрывает

1. Косвенная инъекция через ингестируемые документы (Indirect Injection at Retrieval)

Риск: Атакующий прячет инструкцию внутри документа, который конвейер ингестирует — PDF, вики-страница, краулёная веб-страница, тикет поддержки. Когда этот чанк позже извлекается в контекст LLM, модель исполняет инструкцию атакующего как свою. Где сидит контроль: на стадии ретрива (любой извлечённый контент трактуется как недоверенные данные, а не инструкция) и на санитизации ингеста.

OWASP LLM01:2025 Prompt Injection, LLM05:2025 Improper Output Handling · MITRE ATLAS AML.T0051 (LLM Prompt Injection, индиректный поток).

Защита SYNTREX:

Движки: injection, dormant_payload, output_scanner.
injection инспектирует чанк на встроенные инструкции и скрытые/невидимые символы — и на ингесте (до записи в индекс), и на ретриве (до попадания в контекст).
dormant_payload распознаёт отложенные нагрузки, рассчитанные сработать при последующем извлечении; output_scanner перехватывает попытку LLM действовать по внедрённой инструкции.

2. Отравление базы знаний на ингесте (Knowledge-Base Poisoning)

Риск: Атакующий вбрасывает несколько сконструированных текстов в источник знаний так, чтобы они извлекались по выбранному триггер-запросу и направляли ответ — дезинформация, навязывание бренда, опасные инструкции. Исследование PoisonedRAG показывает ~90% успеха атаки всего при 5 вредоносных текстах в корпусе из миллионов. Где сидит контроль: на стадии ингеста — провенанс источника, allow-list, валидация контента, подписанные/доверенные фиды, ревью записываемых источников.

OWASP LLM04:2025 Data and Model Poisoning, LLM08:2025 Vector and Embedding Weaknesses, LLM09:2025 Misinformation · MITRE ATLAS AML.T0070 (RAG Poisoning), AML.T0020 (Poison Training Data — если отравление доходит до дообучения).

Защита SYNTREX:

Движки: injection, memory_integrity, dormant_payload.
injection пре-фильтрует каждый ингестируемый фрагмент на инструкции-перехватчики и индикаторы отравления до записи в индекс.
memory_integrity контролирует целостность того, что закрепляется в хранилище знаний: аномальный или инструкция-несущий документ помечается до индексации.

3. Слабости векторной БД и кросс-тенантная утечка извлечения (Vector-DB Weaknesses)

Риск: Мультитенантный RAG над общей векторной БД утекает чанки тенанта A тенанту B, когда отсутствует или плохо ограничена namespace-изоляция или метаданные-фильтры по тенанту. Кардинальное правило — «фильтровать до извлечения, а не после»: данные другого арендатора не должны попадать в контекст даже транзиторно. Где сидит контроль: на слое векторной БД — per-tenant namespace, обязательная инъекция фильтра по тенанту в каждый запрос, scoped-ключи.

OWASP LLM08:2025 Vector and Embedding Weaknesses, LLM02:2025 Sensitive Information Disclosure · MITRE ATLAS AML.T0024 (Exfiltration via AI Inference API), AML.T0051 (LLM Prompt Injection — если утечку провоцирует сконструированный запрос).

Защита SYNTREX:

Движки/компоненты: pii, exfiltration, Decision Logger.
pii маскирует персональные данные в извлечённых чанках до попадания в ответ; exfiltration ловит аномальный паттерн выгрузки, характерный для кросс-тенантного слива.
Decision Logger фиксирует, какие чанки и из какого namespace были извлечены — это даёт аудит пересечения границы арендатора.

Что SYNTREX честно НЕ заменяет: саму архитектуру изоляции — per-tenant namespace, обязательный tenant-фильтр на каждом запросе, scoped-ключи и принцип «фильтровать до извлечения». SYNTREX маскирует утечку в содержимом ответа и даёт аудит, но не подменяет namespace-сегментацию вашей векторной БД. Периметр мультитенантного шлюза разбирает Защита LLM-шлюзов и AI-API.

4. Извлечение избыточно-привилегированных документов (Access-Control Bypass)

Риск: Ретривер работает с более широкими правами, чем у конечного пользователя, ИЛИ индекс построен в обход ACL источников — и пользователь естественным языком достаёт документы, которые ему видеть не положено («RAG видит больше, чем должен пользователь»). По отраслевым данным, ~16% бизнес-критичных данных в среднем тенанте M365 «перешарены» — копилот наследует эти права и применяет их без суждения. Где сидит контроль: между ретривером и индексом — права запрашивающего пользователя применяются на ретриве (тримминг/пост-фильтр по ACL), а не только сервис-аккаунта.

OWASP LLM02:2025 Sensitive Information Disclosure, LLM08:2025 Vector and Embedding Weaknesses · MITRE ATLAS AML.T0024 (Exfiltration via AI Inference API).

Защита SYNTREX:

Движки/компоненты: pii, exfiltration, Decision Logger.
pii маскирует чувствительные поля в извлечённых документах; exfiltration помечает аномальный объём извлечения, характерный для «вычёрпывания» сверх роли.
Decision Logger даёт след того, какие документы были подняты в ответ на запрос — основа для разбора несанкционированного доступа.

Граница ответственности: применение прав конкретного пользователя на ретриве — фундаментально задача вашего слоя авторизации и индексации (ACL-aware retrieval, тримминг по правам). SYNTREX маскирует утечку и даёт аудит, но не подменяет ACL-aware ретривер и устранение пере-шаринга у источника.

5. Инверсия эмбеддингов и реконструкция данных (Embedding Inversion)

Риск: Команды хранят эмбеддинги без исходного текста, считая векторы необратимыми. Это не так: генеративная модель-инвертор, обученная на той же эмбеддинг-модели, реконструирует ~60–80% содержания (восстанавливая больше половины слов). Если векторная БД (или её бэкапы/реплики) утечёт, эмбеддинги ≈ открытый текст. Где сидит контроль: на слое хранения/доступа векторной БД — шифрование at-rest, ограничение экспорта сырых векторов, обращение с эмбеддингами как с чувствительными данными.

OWASP LLM08:2025 Vector and Embedding Weaknesses, LLM02:2025 Sensitive Information Disclosure · MITRE ATLAS AML.T0024 (Exfiltration via AI Inference API — Invert AI Model).

Защита SYNTREX:

Движки/компоненты: exfiltration, secret_scanner, output_scanner.
exfiltration распознаёт в содержимом запросов и ответов признаки аномального массового экспорта векторов/данных; output_scanner блокирует или редактирует ответ, в котором эмбеддинги или данные выгружаются наружу. Это инспекция контента на шлюзе, а не сетевой egress-фильтр.
secret_scanner маскирует секреты, попавшие в индекс, в содержимом ответа, не давая им утечь в составе выдаваемых данных.

Что SYNTREX честно НЕ заменяет: шифрование векторной БД at-rest, ограничение экспорта сырых эмбеддингов и контроль доступа к бэкапам. SYNTREX распознаёт аномальную выгрузку в содержимом запросов и ответов, но не управляет шифрованием и правами доступа к самому хранилищу векторов.

6. Supply chain эмбеддинг-модели и компонентов ингеста (Supply Chain)

Риск: Бэкдоренная или подменённая сторонняя эмбеддинг-модель либо скомпрометированная библиотека ингеста/парсинга может сместить извлечение, создать скрытый триггер или стать тем самым инвертор-оракулом из риска №5. Замена эмбеддинг-модели вдобавок молча инвалидирует индекс. Где сидит контроль: на слое провижининга модели/компонентов — провенанс, пиннинг версий, проверка целостности, SBOM для AI-стека.

OWASP LLM03:2025 Supply Chain, LLM04:2025 Data and Model Poisoning · MITRE ATLAS AML.T0010 (AI Supply Chain Compromise).

Защита SYNTREX:

Движки/компоненты: exfiltration, model_containment, Decision Logger.
exfiltration ловит скрытую пересылку данных скомпрометированным компонентом ингеста; model_containment удерживает поведение модели в безопасных границах; Decision Logger фиксирует версии и провенанс в неизменяемой цепочке.

Граница ответственности: проверку происхождения, подписи и репутации эмбеддинг-модели и библиотек до установки выполняют supply-chain инструменты и процессы закупки ПО. SYNTREX контролирует поведение в рантайме, а не легитимность артефакта при установке.

🛠️ Рекомендуемая конфигурация

Профиль для RAG-приложения — пре-фильтрация ингеста, инспекция ретрива и маскирование утечки из чанков:

YAML

# syntrex.yaml — профиль RAG-приложения (по стадиям конвейера)
version: "1.0"
mode: rag_app

engines:
  injection:
    action: block               # ингест (до индексации) + ретрив (до контекста LLM)
    inspect_ingested_content: true
    inspect_retrieved_content: true
    normalize_unicode: true       # скрытые инструкции в документах
    confidence_threshold: 0.80
  memory_integrity:
    action: block               # целостность того, что закрепляется в индексе
  dormant_payload:
    action: flag                # отложенные нагрузки в документах
  output_scanner:
    action: block               # попытка LLM действовать по внедрённой инструкции
  pii:
    action: redact              # маскирование PII в извлечённых чанках
    mask_character: "*"
  secret_scanner: always_on     # секреты не уходят в ответ/экспорт
  exfiltration:
    action: block               # кросс-тенантный слив, массовый экспорт векторов
    confidence_threshold: 0.90
  model_containment:
    action: flag                # удержание эмбеддинг/генеративной модели в границах

shield:
  dmz: true                     # инспекция содержимого запросов и ответов RAG

audit:
  decision_logger: true         # неизменяемая цепочка (SHA-256/HMAC): какие чанки/namespace извлечены

🚨 Правила корреляции (SOC)

Связки «отравление на ингесте → срабатывание на ретриве» и «инъекция в чанке → утечка» — ключевые индикаторы атаки на конвейер RAG:

JSON

{
  "name": "RAG_INGEST_POISON_TO_RETRIEVAL",
  "description": "Документ с инъекцией прошёл ингест и позже сработал на ретриве при выбранном триггер-запросе",
  "condition": "sequence(injection[stage='ingest', confidence>0.6], injection[stage='retrieval', confidence>0.7], 24h)",
  "severity": "HIGH",
  "playbook": "quarantine_document_and_reindex"
}

JSON

{
  "name": "RAG_CHUNK_INJECTION_EXFIL",
  "description": "Инъекция в извлечённом чанке, за которой следует утечка PII или массовый экспорт данных",
  "condition": "sequence(injection[source='retrieved_content', confidence>0.7], exfiltration[confidence>0.8] OR pii[match=true], 15s)",
  "severity": "CRITICAL",
  "playbook": "block_response_and_alert_soc"
}

❓ Частые вопросы (FAQ)

Чем эта страница отличается от пиллара «Безопасность RAG-систем»? Здесь фокус на архитектуре развёртывания: где в конвейере «ингест → эмбеддинг → векторная БД → ретривер → LLM» физически сидит контроль и кто получает доступ к чему. Таксономический разбор самих угроз RAG как классов (отравление, инверсия, инъекция через документы) — в пилларе Безопасность RAG-систем. Контроль, поставленный не на той стадии конвейера, риск не закрывает — поэтому развёртывание разбирается по стадиям.

На какой стадии конвейера ловить косвенную инъекцию через документы? На двух: на ингесте (до записи в индекс) и на ретриве (до попадания чанка в контекст LLM). SYNTREX инспектирует фрагмент движком injection с нормализацией Unicode на обеих стадиях, потому что отравленный документ может пройти ингест незаметно и сработать только при выбранном триггер-запросе — поэтому ретрив-инспекция обязательна даже при чистом на вид ингесте.

Что такое PoisonedRAG и где ставить контроль против отравления базы знаний? PoisonedRAG показал, что ~5 сконструированных текстов в корпусе из миллионов дают ~90% успеха, если они извлекаются по триггер-запросу. Контроль сидит на стадии ингеста: провенанс источника, allow-list, валидация контента, ревью записываемых источников. SYNTREX пре-фильтрует ингестируемые фрагменты движком injection и контролирует целостность индекса движком memory_integrity.

Как RAG может выдать пользователю документы, к которым у него нет доступа? Если ретривер работает с правами сервис-аккаунта шире пользовательских, или индекс построен в обход ACL источников, пользователь естественным языком достаёт «перешаренные» документы («RAG видит больше, чем должен пользователь»). Фундаментальный контроль — ACL-aware retrieval с применением прав запрашивающего пользователя. SYNTREX маскирует утечку (pii) и даёт аудит извлечения (Decision Logger), но не подменяет ACL-aware ретривер и устранение пере-шаринга.

Правда ли, что эмбеддинги можно «расшифровать» обратно в текст? Да: генеративная инверсия, обученная на той же эмбеддинг-модели, восстанавливает ~60–80% содержания — поэтому эмбеддинги нужно защищать как сами исходные данные (шифрование at-rest, ограничение экспорта сырых векторов, контроль доступа к бэкапам). SYNTREX распознаёт признаки аномального массового экспорта векторов в содержимом движком exfiltration и блокирует или редактирует выдающий их ответ движком output_scanner, но шифрование хранилища обеспечивает ваша платформа.

Как защитить мультитенантный RAG от кросс-тенантной утечки? Кардинальное правило — «фильтровать до извлечения, а не после»: данные другого арендатора не должны попадать в контекст даже транзиторно. Это обеспечивается per-tenant namespace, обязательным tenant-фильтром на каждом запросе и scoped-ключами на слое векторной БД. SYNTREX ловит утечку в содержимом ответа (pii, exfiltration) и фиксирует namespace извлечения в Decision Logger, но саму namespace-изоляцию не подменяет — см. также Защита LLM-шлюзов и AI-API.

Что SYNTREX в RAG-развёртывании НЕ заменяет? Архитектурную изоляцию арендаторов (namespace, tenant-фильтр, scoped-ключи), ACL-aware retrieval с правами запрашивающего пользователя, шифрование векторной БД at-rest, ограничение экспорта эмбеддингов и supply-chain проверку эмбеддинг-модели до установки. SYNTREX работает на ингесте и ретриве как слой обнаружения и маскирования, плюс даёт аудит — но архитектурные контроли стадий конвейера остаются на стороне платформы.

📚 Источники

OWASP Top 10 для LLM-приложений (2025) — LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation.
MITRE ATLAS — AML.T0051 (LLM Prompt Injection), AML.T0070 (RAG Poisoning), AML.T0020 (Poison Training Data), AML.T0024 (Exfiltration via AI Inference API), AML.T0010 (AI Supply Chain Compromise).
PoisonedRAG: Knowledge Corruption Attacks to RAG (USENIX Security 2025) — отравление базы знаний RAG малым числом текстов (цитата).
Sentence Embedding Leaks More Information than You Expect — генеративная инверсия эмбеддингов — реконструкция исходного текста из векторов (цитата).
Multi-Tenant RAG Data Isolation — архитектура изоляции арендаторов — принцип «фильтровать до извлечения» (цитата).
NIST AI Risk Management Framework (AI RMF 1.0) — управление рисками RAG-конвейера.

Внутренние материалы: OWASP Top 10 для LLM (2025) · Безопасность RAG-систем · Защита LLM-шлюзов и AI-API · Защита email/продуктивити-копилотов.