Управление доступом на уровне документа в Поиск с использованием ИИ Azure

Note

Поиск с использованием ИИ Azure доступна через портал Azure, REST API и Azure SDKs. Он также лежит в основе Foundry IQ — управляемого слоя знаний, который преобразует корпоративный контент в многократно используемые базы знаний с учетом разрешений доступа для агентов на портале Microsoft Foundry.

Important

Эти функции и функциональные возможности являются частью REST API 2026-08-01-preview. Версия 2026-08-01-preview лицензируется вам в рамках вашей подписки Azure и регулируется условиями, применимыми к "Предварительным версиям", изложенными в Условиях на продукты Microsoft, Дополнении о защите данных для продуктов и служб Microsoft ("DPA") и Дополнительных условиях использования предварительных версий Microsoft Azure.

Предварительная версия 2026-08-01 поддерживает подключения к другим службы Майкрософт и сторонним службам. Использование этих служб регулируется соответствующими условиями и может привести к обработке или хранению данных за пределами периметра соответствия требованиям Azure, а также к передаче данных в периметр соответствия требованиям Azure.

Предварительная версия 2026-08-01-preview не может изменять разрешения доступа, установленные вне предварительной версии 2026-08-01-preview. Если вы используете предварительную версию 2026-08-01-preview с контентом с ограниченным доступом или ограничениями разрешений, пройдет некоторое время, прежде чем 2026-08-01-preview распознает изменения этих ограничений доступа или разрешений.

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

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

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

Подходы к управлению доступом на уровне документа

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

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

Фильтры безопасности — это способ достижения контроля доступа на уровне документа. Этот подход не привязан к API, поэтому вы можете использовать любую версию или пакет.
Области, подобные POSIX, для ACL/RBAC (предварительная версия) Субъект безопасности Microsoft Entra, связанный с токеном запроса, сопоставляется с метаданными разрешений документов, возвращённых в результатах поиска, при этом исключаются все документы, для которых разрешения не совпадают. Разрешения списка управления доступом (ACL) применяются к каталогам и файлам Azure Data Lake Storage (ADLS) 2-го поколения. Области управления доступом на основе ролей (RBAC) применяются к содержимому ADLS 2-го поколения и к Azure BLOB-объектам.

Встроенная поддержка доступа на основе удостоверений на уровне документа доступна в предварительной версии, доступна в REST API и предварительных версиях пакетов Azure SDK, которые предоставляют эту функцию. Сведения о поддержке функций см. в сведениях о поддержке версий пакета SDK.
метки конфиденциальности Microsoft Purview (предварительная версия) Индексатор извлекает метки конфиденциальности, определенные в Microsoft Purview, из поддерживаемых источников данных (Хранилище BLOB-объектов Azure, ADLS Gen2, SharePoint в Microsoft 365, OneLake). Эти метки хранятся в виде метаданных и оцениваются во время запроса, чтобы обеспечить доступ пользователей на основе маркеров Microsoft Entra и назначений политик Purview. Метки также доступны через источники знаний и ответ агентного поиска, благодаря чему ИИ-агенты и чат-приложения, использующие базу знаний, получают ту же фильтрацию с учётом меток. Этот подход синхронизирует авторизацию Поиск с использованием ИИ Azure с моделью Microsoft Information Protection вашего предприятия.
SharePoint в списке управления доступом Microsoft 365 (предварительная версия) Поиск с использованием ИИ Azure индексаторы извлекают метаданные разрешений из поддерживаемого содержимого SharePoint и используют его для проверок доступа во время запроса. Поддерживаемые материалы, субъекты, связи групп, поведение синхронизации и разрешения см. в разделе "Использование индексатора SharePoint для приема метаданных разрешений".

Для индексированных источников ingestionPermissionOptions знаний нельзя сочетать с assetStore. Таким образом, служба изображений (предварительная версия) недоступна при включении приема разрешений на уровне собственного документа.

Выбор подхода

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

Сценарий Рекомендуемый подход Почему
Пользовательская система идентификации, среда безопасности, отличная от Microsoft, или любой индекс, использующий push-модель. Фильтры безопасности не зависит от API, широко доступен и основан на простом сопоставлении строк.
Содержимое в ADLS Gen2 или Хранилище BLOB-объектов Azure с уже существующими назначениями ACL или RBAC. Области ACL или RBAC, подобные POSIX Собственная интеграция с Microsoft Entra; проверка прав доступа во время выполнения запроса использует метаданные прав доступа, записанные в индекс с помощью описанного в документации механизма синхронизации.
Корпоративное содержимое уже регулируется политиками защиты информации Microsoft Purview. метки чувствительности Microsoft Purview Повторно использует централизованную классификацию и назначения политик в службе Поиск с использованием ИИ Azure.
Содержимое, исходное из SharePoint в Microsoft 365 (библиотеки, списки, страницы сайта ASPX). SharePoint в списке управления доступом Microsoft 365 Учитывает собственные разрешения SharePoint, включая группы сайтов SharePoint.

Шаблон для обрезки безопасности с помощью фильтров

В сценариях, когда встроенная интеграция областей ACL/RBAC недоступна, используйте фильтры строк безопасности для обрезки результатов на основе критериев исключения. Шаблон включает следующие компоненты:

  • Чтобы сохранить идентификаторы пользователя или группы, создайте строковое поле в индексе.
  • Загрузите индекс с помощью исходных документов, включающих связанные списки управления доступом.
  • Включите выражение фильтра в логику запроса для сопоставления в строке.
  • Во время запроса получите идентификатор вызывающего.
  • Укажите идентификатор вызывающего в качестве строки фильтра.
  • Результаты обрезаются, чтобы исключить все совпадения, которые не включают строку удостоверения пользователя или группы.

Api модели отправки или извлечения можно использовать. Так как этот подход не зависит от API, необходимо только убедиться, что индекс и запрос имеют допустимые строки (удостоверения) для шага фильтрации.

Этот подход полезен для систем с пользовательскими моделями доступа или не Microsoft платформами безопасности. Дополнительные сведения об этом подходе см. в разделе Фильтры безопасности для обрезки результатов в Поиск с использованием ИИ Azure.

Шаблон для нативной поддержки POSIX-подобных разрешений ACL и области RBAC (предварительный просмотр)

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

контейнеры Azure Data Lake Storage (ADLS) 2-го поколения поддерживают списки управления доступом к контейнерам и файлам. Для ADLS 2-го поколения нативная поддержка сохранения области действия RBAC на уровне документа обеспечивается при использовании индексатора ADLS 2-го поколения или знаниевой базы Blob (поддерживается ADLS 2-го поколения) и API предварительного просмотра для приема содержимого. Для объектов BLOB Azure, использующих индексатор блобов Azure или источник знаний, сохранение сферы действия RBAC осуществляется на уровне контейнера.

Для содержимого, защищенного с помощью ACL, используйте групповой доступ вместо предоставления доступа отдельным пользователям для упрощения администрирования. Шаблон включает следующие компоненты:

Клиентское приложение получает разрешения на чтение индекса с помощью роли читателя данных индекса поиска или участника индекса поиска . Доступ во время запроса определяется метаданными разрешений пользователя или группы в индексированного содержимого. Запросы с фильтром разрешений передают маркер пользователя или группы как x-ms-query-source-authorization в заголовке запроса. При использовании фильтров разрешений во время запроса Поиск с использованием ИИ Azure проверяет наличие двух элементов:

  • Во-первых, он проверяет разрешение средства чтения данных индекса поиска , позволяющее клиентскому приложению получить доступ к индексу.

  • Во-вторых, с учетом дополнительного маркера в запросе, он проверяет разрешения пользователя или группы в отношении документов, которые возвращаются в результатах поиска, исключая те, которые им не соответствуют.

Чтобы добавить метаданные разрешений в индекс, используйте API модели push, отправляя любые JSON-документы в индекс поиска, где полезная нагрузка содержит строковое поле со списками управления доступом (ACL), подобными POSIX, для каждого документа. Важное различие между этим подходом и управляемым редактированием безопасности заключается в том, что метаданные фильтра разрешений в индексе и запросе распознаны как аутентификация с Microsoft Entra ID, а обходной путь для обрезки безопасности — простое сравнение строк. Кроме того, вы можете использовать Graph SDK для получения идентификаторов.

Вы также можете использовать API модели извлечения (индексатора), если источник данных Azure Data Lake Storage (ADLS) 2-го поколения и код вызывает API предварительной версии для индексирования.

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

Способ получения разрешений ACL зависит от того, отправляете ли вы нагрузку документов или используете индексатор ADLS 2-го поколения.

Начните с API предварительной версии, предоставляющей эту функцию:

Для подхода модели push:

  1. Убедитесь, что схема индекса создана с использованием предварительной или предрелизной версии SDK и что в схеме определены фильтры разрешений доступа.
  2. Используйте пакет SDK Microsoft Graph для получения идентичности групп или пользователей.
  3. Используйте API Index Documents или эквивалентный API Azure SDK для отправки документов и связанных метаданных разрешений в индекс поиска.

Для модели подхода индексатора ADLS Gen2 или источника знаний Blob (ADLS Gen2):

  1. Убедитесь, что файлы в каталоге защищены с помощью модели управления доступом ADLS 2-го поколения.
  2. Используйте Indexers — create (REST API), Knowledge Sources — Create (REST API) или эквивалентный API Azure SDK для создания индексатора, индекса и источника данных.

Если ваш набор навыков разбивает документы на фрагменты, например с помощью навыка «Разделение текста» для интегрированной векторизации, то поля метаданных разрешений доступа перемещаются из сопоставлений полей индексатора в проекции индекса. См. раздел "Выбор места для заполнения полей ACL".

Шаблон для SharePoint в Microsoft 365 загрузки базовых разрешений ACL (предварительный просмотр)

Для индексированного содержимого SharePoint Поиск с использованием ИИ Azure может хранить исходные разрешения в качестве метаданных и использовать их для фильтрации результатов запроса. Вы можете получить доступ к этой функции в режиме предварительной версии с помощью индексатора SharePoint в Microsoft 365 и последней версии REST API или эквивалентного пакета SDK предварительной версии.

Требования к разрешениям, поддерживаемые связи групп, синхронизация разрешений и ограничения см. в разделе "Использование индексатора SharePoint для приема метаданных разрешений".

Если ваш набор навыков разбивает документы на фрагменты (например, с помощью навыка Text Split для интегрированной векторизации), поля ACL перемещаются из сопоставлений полей индексатора в проекции в индекс. См. раздел "Выбор места для заполнения полей ACL".

Шаблон для меток конфиденциальности Microsoft Purview (предварительная версия)

При включении приема меток Поиск с использованием ИИ Azure извлекает метаданные о конфиденциальности из поддерживаемых источников данных. К этим источникам данных относятся Хранилище BLOB-объектов Azure, Azure Data Lake Storage 2-го поколения (ADLS 2-го поколения), SharePoint в Microsoft 365 и Microsoft OneLake. Извлеченные метки хранятся в индексе вместе с содержимым документа.

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

Этот шаблон включает следующие компоненты:

  • Настройте индекс,источник данных и индексатор (для планирования) с помощью последней предварительной версии REST API или пакета SDK предварительной версии, поддерживающего прием меток Purview.
  • Включите управляемый идентификатор системного назначения для службы поиска. Управляемые удостоверения, назначаемые пользователем, не поддерживаются для извлечения меток Purview. Собственное удостоверение службы должно содержать повышенные разрешения Purview. Затем попросите глобального администратора клиента или администратора привилегированных ролей предоставить необходимый доступ, чтобы служба поиска могла пройти проверку подлинности с помощью Microsoft Purview и извлекать метаданные меток.
  • Примените метки конфиденциальности к документам перед индексированием, чтобы система могла распознавать и сохранять их при приеме.
  • Во время выполнения запроса прикрепите действительный токен Microsoft Entra через заголовок x-ms-query-source-authorization к каждому запросу. Поиск с использованием ИИ Azure оценивает токен и связанные метаданные ярлыков для обеспечения управления доступом на основе меток.

Применение меток конфиденциальности Purview ограничено сценариями с одним тенантом и требует аутентификации на основе RBAC. Во время предварительной версии он поддерживается только через REST API и Azure SDKs. API автозаполнения и подсказок в настоящее время недоступны для индексов с поддержкой Purview.

Где отображаются метки конфиденциальности

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

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

Если источник знаний указывает на индекс, разбитый на фрагменты, например индекс, заполненный с помощью встроенной векторизации или пользовательского навыка Text Split, набор навыков также должен проецировать метку конфиденциальности на каждую строку фрагмента. Без этой проекции ссылки на уровни блоков не фильтруются.

Дополнительные сведения см. в разделе Используйте индексаторы Поиск с использованием ИИ Azure для импорта меток чувствительности Microsoft Purview.

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

Принудительное применение запросов на основе токенов — это сквозная функция, которая применяется к областям действия ACL и RBAC, меткам конфиденциальности Microsoft Purview и моделям ACL SharePoint в Microsoft 365. Используя собственные запросы на основе маркеров, Поиск с использованием ИИ Azure проверяет маркер Microsoft Entra вызывающего объекта по каждому запросу и обрезает результирующие наборы только тем документам, которые вызывающий пользователь может читать в соответствии с списками управления доступом к документу, если метаданные ACL документа синхронизированы с индексом.

Когда вы добавляете токен пользователя к запросу через заголовок x-ms-query-source-authorization, Поиск с использованием ИИ Azure:

  1. Извлекает из токена утверждения о пользователе, группе и области действия.
  2. Сравнивает эти утверждения безопасности с метаданными разрешений, хранящимися рядом с индексированными документами (записи ACL, области RBAC, назначения меток Purview или списки управления доступом SharePoint).
  3. Возвращает только те документы, синхронизированные метаданные разрешений которых предоставляют вызывающему доступ.

Контроль доступа во время выполнения запроса проверяет утверждения Microsoft Entra вызывающей стороны по метаданным разрешений, которые уже хранятся в индексе. Изменения разрешений в исходной системе (членство в группах Microsoft Entra, ACL ADLS Gen2, назначения меток Purview или ACL SharePoint) отражаются в результатах поиска только после того, как эти метаданные будут синхронизированы с индексом через механизм, специфичный для источника данных, например после последующего запуска индексатора, обновления через push API или обновления, инициированного Purview. Для SharePoint изменения ACL для элементов с уникальными разрешениями обрабатываются инкрементно при каждом успешном выполнении индексатора, начиная с версии REST API 2026-05-01-preview, тогда как изменения, унаследованные от родительских областей (сайта, библиотеки, списка или папки), требуют явного обновления. Дополнительные сведения см. в разделе Синхронизация разрешений между индексированным и исходным содержимым.

Пошаговые инструкции по сквозной реализации запросов см. в статье Применение ACL и RBAC во время выполнения запроса в Поиск с использованием ИИ Azure.

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

Управление доступом на уровне собственного документа в Поиск с использованием ИИ Azure обеспечивает конкретные преимущества фильтрации на стороне приложения:

  • Устраняет необходимость в специальном коде для обработки разрешений: Вам не нужно реализовывать обработку вложенных групп, многоуровневый обход ACL или фильтрацию результатов после запроса в своем приложении. Поиск с использованием ИИ Azure обрабатывает сравнение и фильтрацию во время выполнения запроса.
  • Соответствует существующим средствам контроля соответствия: Повторное использование метаданных разрешений Microsoft Entra, Microsoft Purview и SharePoint помогает поддерживать соответствие результатов поиска исходной системе идентификации. Просмотрите модель синхронизации разрешений для каждого источника, чтобы понять его ограничения.
  • Соблюдает разрешения источника после каждой синхронизации ACL: Для подходов на основе токенов (ACL, области RBAC, метки Purview, ACL SharePoint) проверка прав во время выполнения запроса использует метаданные разрешений, которые документированный для конкретного источника механизм синхронизации (запуск индексатора, обновление через push API или обновление Purview) уже записал в индекс.
  • Повышает производительность по сравнению с отсеиванием результатов после выполнения запроса: Фильтрация непосредственно в конвейере поиска выполняется быстрее, чем загрузка больших наборов результатов в приложение и их последующее отсеивание там, особенно при большом количестве запросов.
  • Повторно использует существующую инфраструктуру удостоверений: идентификаторы Microsoft Entra и SharePoint остаются единым достоверным источником при принятии решений о предоставлении доступа, что снижает дублирование удостоверений и эксплуатационные затраты на обслуживание параллельного хранилища разрешений.

Руководства и примеры

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

Связанное содержимое

  • Last updated on