Partition key в Milvus: маршрутизация арендатора не заменяет права доступа

Partition key в Milvus помогает организовать и маршрутизировать данные, но не является политикой авторизации приложения. При общей коллекции сохраняйте различие между запрошенным арендатором, размещением записей и подтверждённой областью доступа пользователя к документам.

Понять назначение ключа

Документация partition key описывает выделенное скалярное поле для размещения по разделам и связанного поведения поиска. Такой механизм не определяет, кто вправе выбирать значение арендатора в запросе приложения. Сохраните поле и допустимые значения в описании схемы. Организация разделов может быть технически правильной, хотя приложение всё ещё формирует слишком широкий запрос из недоверенного параметра и ошибочно допускает к поиску документы другой группы.

Выбрать настоящую границу данных

Руководство multi-tenancy Milvus сравнивает размещение по базам, коллекциям и разделам. Выбирайте границу по требованиям изоляции и эксплуатационным условиям. Не предполагайте, что каждому арендатору обязательно нужен другой сервер либо что общей коллекции достаточно всегда. Опишите компонент, принимающий решение о доступе. Ключ маршрутизации, имя коллекции и учётная запись являются разными идентичностями, даже если в небольшой демонстрации им случайно назначили одинаковые метки.

Связать запрос с доверенной областью

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

Проверочный случай	Нужное наблюдение
Разрешённый источник	Допустимые доказательства доступны поиску
Другой арендатор	Запрещённые доказательства отсутствуют в результате
Отсутствующая область	Приложение соблюдает объявленное правило отказа

Явно проверить отрицательные случаи

Используйте разные идентификаторы документов с намеренно похожим текстом у разных арендаторов. Иначе слабая проверка может пройти лишь из-за отсутствия похожего материала в чужой группе. Отдельно исследуйте поиск, прямое получение записи и другие доступные приложению пути. Правильный фильтр одного endpoint не подтверждает одинаковую область всех маршрутов. Сохраняйте эти действия как функциональные проверки доступа, а не показатели производительности или косвенный тест качества эмбеддингов.

Не смешивать видимость с разрешением

Справочник согласованности определяет момент видимости записей при выбранном контракте чтения. Это другая ось относительно авторизации. Позднее появление запрещённого документа остаётся ошибкой доступа; временное отсутствие разрешённого нового документа может быть вопросом видимости. При диагностике сохраняйте обе настройки, чтобы изменение consistency не скрыло неверный tenant-предикат и не создало ложное объяснение результата, связанного с другой границей системы.

Сохранить проверяемую границу

Храните вместе схему, правила tenant-ключа, формирование доверенной области и отрицательные примеры. Укажите выбранную границу данных и проверенные маршруты приложения. После добавления другой поисковой операции или смены размещения повторите затронутые случаи. Итог должен подтверждать разделение доказательств в реализованной системе, а не объявлять, что включение одного поля базы автоматически обеспечивает полную безопасность нескольких арендаторов.

Связанные материалы: Локальный RAG-сервер: какие компоненты размещать рядом с GPU; DLP для AI gateway: как уменьшить утечки через запросы к LLM.