Как детектировать и предотвращать vector DB poisoning?

Краткий тезис

Vector DB poisoning — атака, при которой злоумышленник загружает в векторную базу данных специально сконструированные векторы, которые всегда попадают в топ результатов поиска (retrieval) и подменяют легитимный контекст RAG-системы. Детекция основана на проверке соответствия эмбеддинга исходному документу (re-embedding) и аномалиях в распределении similarity. Предотвращение включает криптографическую подпись эмбеддингов (HMAC), белые списки источников и подтверждение пользователем для новых данных.

1. Что такое vector DB poisoning?

Vector DB poisoning (отравление векторной базы данных) — это вид атаки на RAG-систему, при которой злоумышленник внедряет в векторную БД вредоносные векторы (эмбеддинги), которые при поиске по любому (или целевому) запросу оказываются среди top-k результатов. Цель — заставить LLM использовать подставной контекст и сгенерировать неверный, вредоносный или предвзятый ответ.

Основная особенность: атакующий может не контролировать исходный документ, а напрямую загрузить вектор, который имеет similarity|высокое сходство (cosine similarity) с широким кругом запросов. Например, вектор, состоящий из всех единиц, будет близок к любому нормализованному эмбеддингу (по cosine similarity равен 1, если оба единичные). Такие «ядовитые» векторы становятся невидимыми фильтрами и обходят обычные проверки контента.

2. Мотивация: почему это опасно для RAG?

RAG-система полагается на retrieved контекст для генерации ответа. Если retrieval отравлен, то:

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

Пример: чат-бот поддержки банка. Злоумышленник загружает вектор, имитирующий ответ про перевод средств на «безопасный» счёт мошенников. Любой запрос клиента о переводе будет дополнен этим вектором, и LLM скопирует инструкцию.

3. Типы атак на векторную БД

На практике наиболее опасна прямая загрузка, так как она не оставляет следов в виде исходного текста.

4. Методы детекции: проверка целостности эмбеддингов (re-embedding)

Основной принцип: каждый загруженный вектор должен быть пересчитан из соответствующего документа с помощью того же эмбеддера. Если эмбеддинг не совпадает — это признак подмены.

4.1 Re-embedding (повторное эмбеддирование)

1. Хранить в БД не только вектор, но и исходный текст (или его хеш).
2. При загрузке вектора от клиента: получить текст, вычислить эмбеддинг на сервере, сравнить с переданным.
3. Если расхождение превышает порог (например, cosine distance > 0.01) — отклонить запись.

Реализация:

import numpy as np
from sentence_transformers import SentenceTransformer

model = SentenceTransformer('all-MiniLM-L6-v2')

def verify_embedding(text, claimed_vector, threshold=0.01):
    computed_vector = model.encode(text, normalize_embeddings=True)
    similarity = np.dot(computed_vector, claimed_vector)
    return similarity > (1 - threshold)

4.2 Хранение хеша документа

Вместо полного текста можно хранить криптографический хеш (SHA-256) исходного документа. При проверке пересчитывается эмбеддинг и сравнивается с хешем — это быстрее, но не защищает от коллизий (злоумышленник может подобрать другой текст с таким же хешем, что маловероятно).

4.3 Границы метода

• Требует хранения исходного текста (увеличение объёма хранилища).
• Медленнее (каждая запись требует вызова эмбеддера).
• Не защищает, если атакующий контролирует сам эмбеддер.

5. Методы детекции: anomaly detection по распределению сходств

Второй подход — мониторинг статистик retrieval на наличие аномалий. Идея: вредоносный вектор будет иметь необычно высокую average similarity с большим набором разнородных запросов.

5.1 Метрики для мониторинга

• Average retrieval score: средняя cosine similarity по всем запросам для данного вектора.
• 95-й перцентиль similarity: если для многих запросов вектор попадает в топ-1, это подозрительно.
• Entropy распределения: если вектор одинаково близок к запросам из разных тем — аномалия.

5.2 Простая эвристика

Периодически прогонять набор тестовых запросов (например, 1000 случайных) и для каждого вектора считать hit rate across queries — долю запросов, где этот вектор попал в top-k. Если hit rate > 0.9 — высокая вероятность отравления.

def detect_poisoned_vectors(vector_db, test_queries, k=5, threshold=0.9):
    hit_counts = {id: 0 for id in vector_db.ids}
    for query in test_queries:
        results = vector_db.search(query, top_k=k)
        for id in results.ids:
            hit_counts[id] += 1
    total = len(test_queries)
    for id, hits in hit_counts.items():
        if hits / total > threshold:
            print(f"Potential poisoned vector {id} with hit rate {hits/total}")

5.3 Машинное обучение для anomaly detection

Можно обучить модель (Isolation Forest, Autoencoder) на признаках вектора (статистики эмбеддинга, распределение similarity по калибровочным запросам). Однако это требует предварительной разметки и может давать ложные срабатывания.

6. Методы предотвращения: HMAC-подпись эмбеддингов

HMAC (Hash-based Message Authentication Code) — криптографический способ подписи данных с использованием секретного ключа. В контексте vector DB poisoning:

• Только trusted клиенты (серверы, имеющие ключ) могут загружать векторы.
• При записи клиент вычисляет HMAC от конкатенации: (текст || вектор || timestamp).
• База данных хранит подпись и проверяет её при каждой записи. Если подпись не совпадает или отсутствует — запись отклоняется.

6.1 Схема работы

1. Генерация секретного ключа (32 байта) и распространение его среди доверенных сервисов.
2. Клиент формирует сообщение: text (UTF-8) + separator + vector (bytes) + separator + timestamp (ISO).
3. Вычисляет HMAC-SHA256(message, key).
4. Отправляет: {text, vector, timestamp, signature}.
5. Сервер проверяет подпись, вычисляет эмбеддинг (опционально re-embedding) и только тогда сохраняет.

import hmac, hashlib, json

key = b"my_secret_key_32_bytes"
def sign(text, vector, timestamp):
    message = text.encode() + b"|" + vector.tobytes() + b"|" + timestamp.encode()
    return hmac.new(key, message, hashlib.sha256).hexdigest()

6.2 Преимущества

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

6.3 Недостатки

• Усложняет архитектуру (нужен сервис управления ключами).
• Не защищает от атак, где злоумышленник имеет легитимный ключ (например, инсайдер).

7. Методы предотвращения: whitelist источников и user confirmation

7.1 Whitelist источников (белый список)

Ограничить, какие клиенты или IP-адреса могут записывать данные в векторную БД. Все остальные запросы на запись блокируются. Это базовая защита, но неэффективна при компрометации учётной записи.

7.2 User confirmation для новых источников

Если RAG-система позволяет пользователям добавлять документы (например, корпоративная wiki), каждый новый источник должен пройти этап подтверждения:

• Автоматическая проверка: re-embedding, проверка на вредоносный контент (LLM as a judge).
• Ручная модерация администратором.
• Временное ограничение: документы новых пользователей помечаются как "непроверенные" и не участвуют в retrieval, пока не пройдут модерацию.

7.3 Rate limiting и капча

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

8. Мониторинг и автоматические сигналы

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

8.1 Дашборд метрик

• Количество новых векторов в единицу времени — резкий всплеск может указывать на атаку.
• Распределение similarity по запросам — появление кластера векторов с аномально высокими скорами.
• Доля запросов, в которых top-1 результат занимает один и тот же вектор — признак доминирования отравленного вектора.

8.2 Автоматические алерты

Настроить правила, например:

• Если какой-то вектор появляется в top-5 более чем для 50% запросов за последние 10 минут → алерт.
• Если средняя cosine similarity для нового вектора > 0.95 с калибровочным набором → алерт.

8.3 Периодический аудит

Регулярно запускать пакетную проверку всех векторов: re-embedding для каждого документа и сравнение с хранимым вектором. Это выявит как атаки, так и ошибки обновления эмбеддера.

9. Практические рекомендации по архитектуре безопасной векторной БД

1. Никогда не доверяйте клиентским эмбеддингам. Всегда пересчитывайте их на сервере.
2. Используйте HMAC-подпись для всех операций записи. Храните ключи в секретном хранилище (Vault, AWS Secrets Manager).
3. Внедрите re-embedding как обязательный шаг при вставке. Если latency критична, делайте асинхронную верификацию и помечайте векторы как «непроверенные», пока верификация не завершится.
4. Настройте whitelist и rate limiting на уровне API Gateway.
5. Для публичных систем — user confirmation (модерация) с использованием LLM для проверки контента на вредоносность.
6. Мониторьте метрики retrieval в реальном времени и настройте алерты.
7. Планируйте ротацию ключей и регулярный аудит векторов.

10. Пет-проект для закрепления

Задача: Разработать прототип системы детекции и предотвращения отравления векторной БД на основе ChromaDB.

Инструменты:

• Python 3.10+
• ChromaDB (in-memory)
• Sentence-Transformers (all-MiniLM-L6-v2)
• Flask (для имитации API)
• hashlib, hmac (для подписи)

Шаги:

1. Создайте векторную БД ChromaDB с коллекцией documents.
2. Реализуйте эндпоинт /add_document, который принимает JSON: {"text": "...", "vector": [...]}.
3. Добавьте проверку HMAC: предполагайте, что ключ передан в заголовке X-Signature. Вычислите ожидаемую подпись и сравните.
4. Реализуйте re-embedding: пересчитайте вектор из текста, отклоните запись, если cosine similarity < 0.99.
5. Создайте детектор аномалий: имитируйте 100 случайных запросов, для каждого вектора посчитайте hit rate и выдайте предупреждение, если он > 0.8.
6. Напишите тест, который загружает «ядовитый» вектор (например, все единицы) и проверяет, что система его блокирует.

Ожидаемый результат:

• Рабочий API, который принимает только подписанные и верифицированные векторы.
• Консольный скрипт, который обнаруживает аномалии в существующих данных.
• Отчёт с демонстрацией, как атака предотвращается.

11. Связь с другими вопросами

12. Навигация

• Предыдущий: 888
• Следующий: 890
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 888
• Следующий: 890
• Индекс: 00. Индекс разборов