Принудительное применение меток конфиденциальности Microsoft Purview во время запроса в Поиск с использованием ИИ Azure (предварительная версия)

Во время запроса Поиск с использованием ИИ Azure может применять политики меток конфиденциальности, определенные в Microsoft Purview. Эти политики включают оценку EXTRACT прав на использование, связанных с каждым документом, обеспечивая, что пользователи могут получать доступ только к тем документам, к которым у них есть разрешение.

Эта возможность расширяет управление доступом на уровне документов, чтобы соответствовать требованиям вашей организации по защите информации и соблюдению норм, управляемых в Microsoft Purview.

Если индексирование меток конфиденциальности Purview включено, Поиск с использованием ИИ Azure проверяет метаданные меток каждого документа в момент выполнения запроса. Он применяет фильтры доступа на основе политик Purview для возврата только результатов, к которым пользователь запрашивает доступ.

В этой статье объясняется, как работает применение меток конфиденциальности в момент запроса и как осуществлять безопасные поисковые запросы.

Необходимые условия

• Выполните все действия в использовании индексаторов Поиск с использованием ИИ Azure для загрузки меток конфиденциальности Microsoft Purview.

• Убедитесь, что для службы Поиск с использованием ИИ Azure включено управляемое удостоверение, назначаемое системой (а не управляемое удостоверение, назначаемое пользователем) и что ей назначены роли Content.SuperUser и UnifiedPolicy.Tenant.Read. Применение правил во время выполнения запроса зависит от метаданных меток классификации, которые индексатор может извлечь только в том случае, если системно назначаемая идентичность настроена правильно. См. шаг 1 в статье о настройке индексатора.

• Служба Поиск с использованием ИИ Azure и пользователь, выдавающий запрос, должны находиться в одном клиенте Microsoft Entra.

• REST API версии 2025-11-01-preview или эквивалентный пакет SDK предварительной версии для запроса индекса. Возможность чтения с повышенными правами и ведение журнала аудита Purview требуют 2026-05-01-preview или более поздней версии.

• Аутентификация запросов с помощью ролевого управления доступом Azure (RBAC), а не API-ключей. Если метки конфиденциальности Purview включены, доступ к ключу API ограничивается получением схемы индекса.

Ограничения

• Гостевые учетные записи и межтенантные запросы не поддерживаются.

• Автозавершение и подсказка API не поддерживаются для индексов, поддерживающих Purview.

• Если оценка меток завершается ошибкой, служба возвращает определенный код ошибки HTTP, а не частичный или нефильтрованный результирующий набор. Полный список кодов ошибок и причин см. в разделе "Устранение ошибок запроса".

• Система оценивает метки только по мере их существования во время последнего запуска индексатора. Последние изменения в метках могут не отражаться до следующей запланированной переиндексации.

Как осуществляется применение меток конфиденциальности в момент выполнения запроса

При запросе индекса, включающего метки конфиденциальности Microsoft Purview, Поиск с использованием ИИ Azure проверяет связанные политики Purview перед возвратом результатов. Таким образом, запрос возвращает только документы, к которым разрешен доступ токен пользователя.

Ввод данных идентификации пользователей и ролей приложений

Во время запроса Поиск с использованием ИИ Azure проверяет оба:

• Роль RBAC вызывающего приложения, указанная в заголовке Authorization . Минимально требуемая роль — Search Index Data Reader. Дополнительные сведения см. в руководстве Поиск с использованием ИИ Azure RBAC.
• Идентификация пользователя с помощью токена, предоставленного в заголовке x-ms-query-source-authorization.

Оба требуются для управления видимостью, настраиваемой на основе меток.

2. Оценка меток чувствительности

При получении запроса Поиск с использованием ИИ Azure вычисляет:

1. Поле sensitivityLabel в каждом индексованном документе (извлеченном из Microsoft Purview во время приема).
2. Действующие разрешения Purview пользователя, определенные политикой меток Microsoft Entra ID и Purview.

Если пользователь не авторизован для метки конфиденциальности документа с EXTRACT разрешениями, этот документ исключается из результатов запроса.

3. Защита фильтрации результатов

Поиск с использованием ИИ Azure применяет фильтр безопасности после всех пользовательских фильтров и шагов оценки.
Документ включается в окончательный результирующий набор только в том случае, если:

• Вызывающее приложение имеет действующее назначение ролей (с помощью RBAC) и
• Маркер удостоверения пользователя x-ms-query-source-authorization является действительным и имеет разрешение для просмотра содержимого с грифом конфиденциальности документа.

Если одно из условий не выполняется, документ исключается из результатов.

Получение маркера доступа пользователя

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

Для сценариев тестирования

Для локального тестирования можно получить маркер доступа пользователя с помощью Azure CLI:

$token = az account get-access-token `
  --resource https://search.azure.com `
  --query accessToken `
  --output tsv

Этот подход использует текущий сеанс входа Azure CLI, что позволяет вам работать с документами, для которых у вас есть EXTRACT разрешения, назначенные с помощью меток конфиденциальности. Этот метод предназначен только для сценариев разработки и проверки.

Получение токена для сценариев On-Behalf-Of (OBO)

Приложения, реализующие поток On-Behalf-Of (OBO), должны получать токены через Microsoft Entra ID с помощью поддерживаемой библиотеки аутентификации, такой как Microsoft Authentication Library (MSAL).

В сценариях OBO запросите маркер для нижестоящего API, вызываемого приложением. Например, при вызове Поиск с использованием ИИ Azure используется URI ресурса https://search.azure.com/.default.

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

Разрешения метки конфиденциальности, в том числе EXTRACT, не представлены в виде области действия OAuth. Нижележащая служба, например Поиск с использованием ИИ Azure, оценивает эти разрешения во время исполнения на основе удостоверения пользователя в токене и применяемой политики меток конфиденциальности.

Пример запроса

Вот пример запроса, в котором используется принудительное применение меток конфиденциальности Microsoft Purview.

Передайте токен приложения в качестве токена Bearer в заголовке Authorization. Передайте токен пользователя в заголовке x-ms-query-source-authorization как необработанное значение токена, без префикса Bearer.

POST  {{endpoint}}/indexes/sensitivity-docs/docs/search?api-version=2025-11-01-preview
Authorization: Bearer {{app-query-token}}
x-ms-query-source-authorization: {{user-query-token}}
Content-Type: application/json

{
    "search": "*",
    "select": "title,summary,sensitivityLabel",
    "orderby": "title asc"
}

Расширенный доступ на чтение для административных расследований (предварительная версия)

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

Расширенное чтение доступно для индексов с поддержкой Purview в REST API версии 2026-05-01-preview и более поздних.

Как работает чтение с повышенными привилегиями

1. Вызывающее приложение задает заголовок x-ms-enable-elevated-read: true в запросе поиска.

2. Поиск с использованием ИИ Azure пропускает проверку доступа к каждому документу на основе меток и возвращает найденные документы независимо от разрешений запрашивающего пользователя EXTRACT для каждой метки.

3. Для каждого документа в ответе Поиск с использованием ИИ Azure отправляется одна запись в журнал аудита Microsoft Purview от имени запрашивающего клиента. Один поисковый запрос, возвращающий N документов, создает N записей аудита.

4. Записи аудита асинхронно загружаются в Purview после получения ответа на поисковый запрос.

Обязательное назначение ролей

Пользователь-разработчик, выполняющий вызов, должен иметь роль Search Index Data Contributor на уровне службы поиска или индекса. Средство чтения данных индекса поиска недостаточно. Чтение с повышенными привилегиями завершается сбоем 403 Forbidden, если роль не назначена. Дополнительные сведения о ролях Поиск с использованием ИИ Azure см. в разделе Подключение к Поиск с использованием ИИ Azure с помощью ролей.

Если для заголовка x-ms-enable-elevated-read задано trueзначение, x-ms-query-source-authorization заголовок не может использоваться.

Пример чтения с повышенными привилегиями

POST  {{endpoint}}/indexes/sensitivity-docs/docs/search?api-version=2026-05-01-preview
Authorization: Bearer {{contributor-token}}
x-ms-enable-elevated-read: true
Content-Type: application/json

{
    "search": "*",
    "select": "title,summary,sensitivityLabel",
    "orderby": "title asc"
}

Поля аудита, отправленные в Microsoft Purview

Каждая запись аудита следует схеме Office 365 API действий управления и включает следующие поля.

плавная деградация

Если Поиск с использованием ИИ Azure не удается подключиться к Microsoft Purview при обработке запроса, например при временном сбое в работе Purview, Поиск с использованием ИИ Azure пропускает проверку меток для этого запроса. Поведение зависит от того, включает ли запрос маркер удостоверения пользователя:

• Повышенные запросы на чтение (x-ms-enable-elevated-read: true): Запрос завершается ошибкой 5xx. Поиск с использованием ИИ Azure не возвращает помеченные документы, пока не сможет создавать журналы аудита.

• Стандартные запросы с принудительным применением меток (с x-ms-query-source-authorization): запрос завершается ошибкой 5xx. Поиск с использованием ИИ Azure не возвращает частичные или нефильтрованные результаты, если не удается оценить политики меток.

• Запросы без x-ms-query-source-authorization, выполняемые приложением, имеющим как минимум роль Search Index Data Reader: запрос выполняется успешно и возвращает только документы, у которых нет метки конфиденциальности. Помеченные документы опущены из ответа.

Этот деградированный режим обработки предназначен только для процессов, не ориентированных на пользователя, которые явно допускают использование результатов без меток. Не полагайтесь на него при реализации поиска для конечных пользователей.

Полный список кодов ошибок, возвращаемых при оценке меток конфиденциальности во время запроса, см. в разделе "Устранение ошибок запроса".

Поиск журналов аудита с повышенными привилегиями в Microsoft Purview

Поиск с использованием ИИ Azure отправляет записи аудита в журнал аудита Microsoft Purview вызывающего клиента. Чтобы исследовать повышенную активность чтения:

1. В Портал Microsoft Purview выберите Solutions>Audit.

2. Выберите Audit Search, а затем отфильтруйте по диапазону дат, пользователю или типу записи Поиск с использованием ИИ Azure.

3. Откройте запись для просмотра стандартных полей схемы и настраиваемых полей Поиск с использованием ИИ Azure, включая SensitivityLabelName, DocumentDataSourceType и DocumentDataSourceId.

Пошаговые инструкции по выполнению поиска в журнале аудита, поведении хранения и необходимых ролях Purview см. в статье Поиск в журнале аудита на портале Microsoft Purview.

Обработка меток конфиденциальности в Поиск с использованием ИИ Azure

Если Поиск с использованием ИИ Azure индексирует содержимое документа с метками конфиденциальности из таких источников, как SharePoint, Azure Blob и другие, то он сохраняет как содержимое, так и метаданные меток. Поисковый запрос возвращает индексированное содержимое вместе с GUID, который определяет метку конфиденциальности, примененную к документу, только если у пользователя есть доступ к данным EXTRACT для этого документа, назначенного с помощью определения метки конфиденциальности. Этот GUID однозначно идентифицирует метку, но не включает свойства, доступные для чтения, такие как имя метки или связанные разрешения.

Обратите внимание, что один только идентификатор GUID недостаточен для сценариев с пользовательским интерфейсом, так как метки конфиденциальности часто содержат другие параметры управления политикой, применяемые Защита информации Microsoft Purview, такие как разрешения на печать или ограничения на создание снимков экрана и захват экрана. В Поиск с использованием ИИ Azure эти возможности не предоставляются.

Чтобы отобразить имена меток и (или) применить ограничения для пользовательского интерфейса, приложение должно вызвать конечную точку Защита информации Microsoft Purview для получения полных метаданных меток и связанных разрешений.

Guid, возвращаемый Поиск с использованием ИИ Azure, можно использовать для разрешения свойств метки и вызова API-интерфейсов меток Purview Labels для получения имени метки, описания и параметров политики.

Устранение ошибок запросов

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

400 Недопустимый запрос

Ошибка 400 указывает на проблему с конфигурацией индекса или заголовками запроса. Исправьте конфигурацию перед повтором.

401 — не авторизовано

Ошибка 401 указывает на проблему с токеном авторизации или разрешениями приложения Purview.

502 — Недопустимый шлюз

Ошибка 502 указывает на сбой подключения между Поиск с использованием ИИ Azure и Microsoft Purview. Эти ошибки обычно являются временными.

Ошибка 504: время ожидания шлюза истекло

Ошибка 504 указывает, что Microsoft Purview не ответили в течение допустимого времени.

Сквозная настройка тестирования

Чтобы проверить правильность конфигурации меток конфиденциальности в Поиск с использованием ИИ Azure, ознакомьтесь с эталонным примером сквозной настройки.

В этом репозитории показано, как:

• Настройка синхронизации и учета меток конфиденциальности в Поиск с использованием ИИ Azure
• Тестирование сценариев приема и применения запросов для документов с метками конфиденциальности
• Извлеките название метки и включите его в состав ссылок на источники, используемых в ваших RAG-приложениях или агентах.