В прошлый четверг аудит безопасности зарубил RAG-систему крупного страховщика. Команда искренне считала массив float32 необратимым хешем. Пришлось прямо на сервере доказывать, что эмбеддинг — не анонимизация: из вектора восстанавливается 80%+ текста (embedding inversion) и почему это утечка ПДн в самом кристальном, уголовно наказуемом виде.
Индустрия живет в опасной галлюцинации. Разработчики думают, что нейросеть «перемешивает» слова в непонятную математическую кашу, сбрасывая исходники в облачные кластеры векторных баз данных. Это фундаментальное непонимание природы семантического пространства. Криптографический хеш вроде SHA-256 создан для уничтожения связей: смена одного байта меняет весь результат. Эмбеддинг делает прямо противоположное. Его задача — сохранить смысл. Близкие по содержанию тексты ложатся рядом в многомерном пространстве. Значит, геометрия вектора содержит всю информацию о документе. Это жесточайший архиватор с потерями, и потерь с каждым релизом новых моделей все меньше.
Эмбеддинг — не анонимизация: из вектора восстанавливается 80%+ текста (embedding inversion) и почему это утечка ПДн
Существуют готовые архитектуры типа vec2text, которые берут «обезличенный» вектор и итеративно предсказывают токены, шаг за шагом минимизируя расстояние между эмбеддингом сгенерированного текста и вашей оригинальной целью. Это работает как gradient descent прямо по тексту.
from vec2text import invert_embeddings
# Имитация атаки: скормили вектор размерности 768, получили ПДн
recovered_text = invert_embeddings(
embeddings=stolen_float_array,
model="jinaai/jina-embeddings-v2-base-en",
max_steps=50
)
print(recovered_text[0]) # Вывод: Пациент А.В. Смирнов, диагноз C34.9, назначен...Если запустить это на потребительской GPU, результаты заставляют безопасников пить корвалол. Посмотрим на сухие цифры качества реконструкции.
| Длина фрагмента (токены) | Дословное восстановление | Восстановление фактологии |
|---|---|---|
| 32 | 92% | 99% |
| 64 | 75% | 95% |
| 128 | 60% | 88% |
| 256 (типичный чанк RAG) | 45% | 75% |
Точные имена, диагнозы, суммы контрактов и номера счетов вытаскиваются элементарно, потому что они формируют железобетонные семантические якоря. Модель выдаст не «какой-то больной», а конкретно: «Иванов И.И., положительный статус, назначен Зидовудин». В контексте врачебной тайны или банковской тайны это чистая компрометация.
Карта угроз: как ломают векторные хранилища
Никто не думает про threat modeling векторных баз. Считается, что если Qdrant или pgvector торчат только во внутреннюю сеть, мы в домике. Но реальность бьет с другой стороны. Угроза номер один — дамп коллекции. Кто-то сливает снапшот диска или делает бэкап в незащищенный бакет S3. Дальше злоумышленник применяет inversion-модель в спокойной обстановке.
Угроза номер два — membership inference, атака на принадлежность. Нам даже не нужно восстанавливать текст. Достаточно прогнать через энкодер фразу «Иванов И.И. лечится от гепатита» и сделать KNN-запрос к базе клиники. Если возвращается дистанция, близкая к нулю, мы подтвердили факт без взлома серверов.
Угроза номер три — инъекции в метаданные. Если вы кладете в payload документа JSON с правами доступа и слабо его санитизируете, банальная подмена поля tenant_id при апдейте чужого вектора отдаст финансовые сводки конкурента в выдачу злоумышленника.
Угроза номер четыре кроется в обходе фильтров доступа. Разработчики RAG обожают фильтровать результаты после поиска (post-filtering). Вытащили top-100 векторов, а потом приложение отсекает те, на которые нет прав. Если из ста векторов девяносто девять принадлежат другому клиенту, легитимный пользователь получит пустой ответ. А по таймингам ответа хакер поймет плотность кластера чужих документов. Это сайд-чэнел утечка в чистом виде.
Шифрование: ловушка CMEK и иллюзия поиска по шифру
Типичная реакция CISO: «Давайте все зашифруем». Внедряется Customer Managed Encryption Keys (CMEK), шифруются тома EBS, и все успокаиваются. Но как только векторная БД загружает индексы в оперативную память для выполнения векторного поиска, все эмбеддинги лежат там в открытом (plaintext) виде. Любой LFI/RCE эксплойт или банальный дамп памяти через уязвимость гипервизора умножает вашу криптографию на ноль. Полноценного Fully Homomorphic Encryption (FHE) для векторов размерности 1024 в реальном времени под high-load пока нет — latency измеряется часами. Шифрование дисков спасает от кражи железа, но не защищает данные в процессе использования.
Compliance и суровая реальность 152-ФЗ
Российское законодательство, в частности 152-ФЗ и приказы ФСТЭК №17/21, не дают поблажек на хайп. Если данные позволяют прямо или косвенно идентифицировать субъекта и его состояние, это персональные данные. Поскольку из эмбеддинга вытаскивается фактология и возможно проведение membership inference, векторная база с медицинскими картами — это информационная система персональных данных (ИСПДн), часто самого высокого уровня защищенности. Размещать это в публичном SaaS без сертифицированных контуров — значит сознательно идти на отзыв аттестации и оборотные штрафы при первой проверке.
Я обещал чек-лист защиты векторного хранилища. Загибайте пальцы, если готовы показывать систему аудитору. Первым пунктом идет полное уничтожение иллюзий: признаем вектор сырыми персональными данными со всеми вытекающими регламентами ФСТЭК, включая обязательный контур on-prem. Вторым шагом настраиваем pre-filtering для Role-Based Access Control, отсекая чужие сегменты строго до начала вычисления дистанций, чтобы исключить side-channel утечки. Третье правило требует тотальной физической изоляции данных: наш подход в MoranaLabs здесь бескомпромиссен — никаких общих графов HNSW для разных клиентов, только изолированные процессы и неймспейсы. Четвертая позиция закрывает сеть: векторная база не торчит наружу даже во внутреннем DMZ, доступ идет по gRPC с жесткой mTLS-аутентификацией. Пятое: внедряем мониторинг на membership inference, отслеживая аномальные паттерны KNN-запросов и дистанции возвратов. Шестое требование: применяем differential privacy, инжектируя математический шум в векторы перед записью, что незначительно снижает recall, но критически ломает градиенты моделям инверсии. Седьмой, финальный шаг — шифруем тома at-rest, отдавая себе отчет, что это лишь базовый слой, не заменяющий защиту in-memory.
В MoranaLabs мы не строим воздушных замков из маркетинговых терминов. Мы проектируем защищенный on-prem семантический поиск под ключ, который реально работает под нагрузкой и проходит строгую аттестацию регуляторов. Искусственный интеллект в enterprise начинается там, где заканчивается вера в безопасность из коробки.