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

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

Автор: Команда Retrivium
Обновлено: 2026-11-03
Канонический URL: https://retrivium.ai/ru/journal/milvus-partition-key-tenant-query-boundary/
Language: ru

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

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

[Документация partition key](https://milvus.io/docs/use-partition-key.md) описывает выделенное скалярное поле для размещения по разделам и связанного поведения поиска. Такой механизм не определяет, кто вправе выбирать значение арендатора в запросе приложения. Сохраните поле и допустимые значения в описании схемы. Организация разделов может быть технически правильной, хотя приложение всё ещё формирует слишком широкий запрос из недоверенного параметра и ошибочно допускает к поиску документы другой группы.

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

[Руководство multi-tenancy Milvus](https://milvus.io/docs/multi_tenancy.md) сравнивает размещение по базам, коллекциям и разделам. Выбирайте границу по требованиям изоляции и эксплуатационным условиям. Не предполагайте, что каждому арендатору обязательно нужен другой сервер либо что общей коллекции достаточно всегда. Опишите компонент, принимающий решение о доступе. Ключ маршрутизации, имя коллекции и учётная запись являются разными идентичностями, даже если в небольшой демонстрации им случайно назначили одинаковые метки.

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

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

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

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

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

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

[Справочник согласованности](https://milvus.io/docs/consistency.md) определяет момент видимости записей при выбранном контракте чтения. Это другая ось относительно авторизации. Позднее появление запрещённого документа остаётся ошибкой доступа; временное отсутствие разрешённого нового документа может быть вопросом видимости. При диагностике сохраняйте обе настройки, чтобы изменение consistency не скрыло неверный tenant-предикат и не создало ложное объяснение результата, связанного с другой границей системы.

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

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

Связанные материалы: [Локальный RAG-сервер: какие компоненты размещать рядом с GPU](/ru/journal/rag-server-local-architecture/); [DLP для AI gateway: как уменьшить утечки через запросы к LLM](/ru/journal/ai-gateway-dlp/).
