Подключение в поиск azure AI с помощью управления доступом на основе ролей

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

• Администрирование службы
• Разработка или доступ на запись в службу поиска
• Доступ только для чтения для запросов
• Ограниченный доступ к одному индексу

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

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

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

Необходимые компоненты

• Владелец, доступ пользователей Администратор istrator или роль с разрешениями Microsoft.Authorization/roleAssignments/write.

• Служба поиска в любом регионе на любом уровне.

Ограничения

• Управление доступом на основе ролей может увеличить задержку некоторых запросов. Каждое уникальное сочетание ресурсов службы (индексатора, индексатора и т. д.) и субъекта-службы активирует проверка авторизации. Эти проверка авторизации могут добавлять до 200 миллисекунда задержки на запрос.

• В редких случаях, когда запросы исходят из большого числа разных субъектов-служб, все целевые ресурсы службы (индексы, индексаторы и т. д.), могут привести к регулированию проверка авторизации. Регулирование произойдет только в том случае, если в секунду использовались сотни уникальных сочетаний ресурсов службы поиска и субъекта-службы.

Включение доступа на основе ролей для операций плоскости данных

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

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

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

Портал Azure

1. Войдите в портал Azure и откройте страницу службы поиска.

2. В расположенной слева области навигации щелкните Ключи.

   

3. Выберите элемент управления на основе ролей или оба , если требуется гибкость.

   Вариант	Описание
   Ключ API	(по умолчанию). Требуется ключи API в заголовке запроса для авторизации.
   Управление доступом на основе ролей	Требуется членство в назначении ролей для выполнения задачи. Для этого также требуется заголовок авторизации для запроса.
   Оба	Запросы действительны с помощью ключа API или управления доступом на основе ролей, но если вы предоставляете оба в одном запросе, используется ключ API.

Изменение действует немедленно, но подождите несколько секунд перед назначением ролей.

Если включить управление доступом на основе ролей, режим сбоя — http401WithBearerChallenge, если авторизация завершается ошибкой.

REST API

Используйте REST API управления, чтобы настроить службу для управления доступом на основе ролей или обновить службу.

Все вызовы REST API управления проходят проверку подлинности с помощью идентификатора Microsoft Entra. Сведения о настройке аутентифицированных запросов см. в статье "Управление поиском ИИ Azure" с помощью REST.

1. Получите параметры службы, чтобы просмотреть текущую конфигурацию.

   GET https://management.azure.com/subscriptions/{{subscriptionId}}/providers/Microsoft.Search/searchServices?api-version=2023-11-01
   

2. Используйте PATCH для обновления конфигурации службы. Следующие изменения позволяют использовать ключи и доступ на основе ролей. Если требуется конфигурация только для ролей, см. раздел "Отключить ключи API".

   В разделе "Свойства" задайте для параметра authOptions значение aadOrApiKey. Свойство disableLocalAuth должно иметь значение false, чтобы задать authOptions.

   При необходимости задайте параметр aadAuthFailureMode , чтобы указать, возвращается ли 401 вместо 403 при сбое проверки подлинности. Допустимые значения: http401WithBearerChallenge или http403.

   PATCH https://management.azure.com/subscriptions/{{subscriptionId}}/resourcegroups/{{resource-group}}/providers/Microsoft.Search/searchServices/{{search-service-name}}?api-version=2023-11-01
   {
       "properties": {
           "disableLocalAuth": false,
           "authOptions": {
               "aadOrApiKey": {
                   "aadAuthFailureMode": "http401WithBearerChallenge"
               }
           }
       }
   }
   

Изменение действует немедленно, но подождите несколько секунд перед назначением ролей.

Если включить управление доступом на основе ролей, режим сбоя — http401WithBearerChallenge, если авторизация завершается ошибкой.

Встроенные роли, используемые в поиске ИИ Azure

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

Роль	Плоскость	Description
Ответственное лицо	Управление и данные	Полный доступ к плоскости управления ресурса поиска, включая возможность назначения ролей Azure. Только роль владельца может включать или отключать параметры проверки подлинности или управлять ролями для других пользователей. По умолчанию администраторы подписок являются участниками. На плоскости данных эта роль имеет тот же доступ, что и роль участника службы поиска. Он включает доступ ко всем действиям плоскости данных, кроме возможности запрашивать или индексировать документы.
Участник	Управление и данные	Тот же уровень доступа уровня управления, что и владелец, минус возможность назначать роли или изменять параметры проверки подлинности. На плоскости данных эта роль имеет тот же доступ, что и роль участника службы поиска. Он включает доступ ко всем действиям плоскости данных, кроме возможности запрашивать или индексировать документы.
Читатель	Управление и данные	Доступ на чтение во всей службе, включая метрики поиска, метрики содержимого (используемое хранилище, количество объектов), а также определения объектов ресурсов плоскости данных (индексы, индексаторы и т. д.). Однако он не может считывать ключи API или читать содержимое в индексах.
Участник службы поиска	Управление и данные	Доступ на чтение и запись к определениям объектов (индексы, псевдонимы, карты синонимов, индексаторы, источники данных и наборы навыков). Эта роль предназначена для разработчиков, создающих объекты, а также для администраторов, которые управляют службой поиска и его объектами, но без доступа к содержимому индекса. Эта роль позволяет создавать, удалять и перечислять индексы, получать определения индексов, получать сведения о службе (статистика и квоты), тест-анализаторы, создавать карты синонимов, индексаторы, источники данных и наборы навыков. См Microsoft.Search/searchServices/* . список разрешений.
Участник данных индекса поиска	Data	Доступ на чтение и запись к содержимому в индексах. Эта роль предназначена для разработчиков или владельцев индексов, которые должны импортировать, обновить или запросить коллекцию документов индекса. Эта роль не поддерживает создание или управление индексами. По умолчанию эта роль используется для всех индексов в службе поиска. Чтобы сузить область, см. раздел "Предоставить доступ к одному индексу".
Читатель данных индекса поиска	Data	Доступ только для чтения для запросов индексов поиска. Эта роль предназначена для приложений и пользователей, выполняющих запросы. Эта роль не поддерживает доступ на чтение к определениям объектов. Например, невозможно прочитать определение индекса поиска или получить статистику службы поиска. По умолчанию эта роль используется для всех индексов в службе поиска. Чтобы сузить область, см. раздел "Предоставить доступ к одному индексу".

Примечание.

Если вы отключите доступ на основе ролей Azure, встроенные роли для уровня управления (владелец, участник, читатель) будут доступны. Отключение доступа на основе ролей удаляет только разрешения, связанные с данными, связанные с этими ролями. Если роли плоскости данных отключены, участник службы поиска эквивалентен участнику уровня управления.

Назначение ролей

В этом разделе назначьте роли для:

• Администрирование службы
• Разработка или доступ на запись в службу поиска
• Доступ только для чтения для запросов

Назначение ролей для администрирования службы

Администратор службы может создавать и настраивать службу поиска, а также выполнять все операции уровня управления, описанные в REST API управления или эквивалентных клиентских библиотеках. В зависимости от роли можно также выполнять большинство задач REST API поиска плоскости данных.

Портал Azure

1. Войдите на портал Azure.

2. Перейдите к своей службе поиска

3. На расположенной слева панели навигации щелкните Управление доступом (IAM).

4. Выберите + Добавить>Добавить назначение ролей.

5. Выберите соответствующую роль:

   • Владелец (полный доступ ко всем операциям плоскости данных и плоскости управления, за исключением разрешений запроса)
   • Участник (тот же, что и владелец, за исключением разрешений на назначение ролей)
   • Читатель (приемлемый для мониторинга и просмотра метрик)

6. На вкладке "Участники" выберите удостоверение пользователя Или группы Microsoft Entra.

7. Чтобы назначить роль, на вкладке Проверка и назначение выберите Проверка и назначение.

PowerShell

При использовании PowerShell для назначения ролей вызовите New-AzRoleAssignment, указав имя пользователя или группы Azure и область назначения.

В этом примере создается назначение ролей, область в службу поиска:

New-AzRoleAssignment -SignInName <email> `
    -RoleDefinitionName "Reader" `
    -Scope  "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Search/searchServices/<search-service>"

Назначение ролей для разработки

Назначения ролей являются глобальными в службе поиска. Чтобы область разрешения на один индекс, используйте PowerShell или Azure CLI для создания настраиваемой роли.

Внимание

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

Портал Azure

1. Войдите на портал Azure.

2. Перейдите к своей службе поиска

3. На расположенной слева панели навигации щелкните Управление доступом (IAM).

4. Выберите + Добавить>Добавить назначение ролей.

   

5. Выберите роль:

   • Участник службы поиска (операции create-read-update-delete для индексов, индексаторов, наборов навыков и других объектов верхнего уровня)
   • Участник данных индекса поиска (загрузка документов и выполнение заданий индексирования)
   • Средство чтения данных индексов поиска (запрос индекса)

   Другое сочетание ролей, предоставляющих полный доступ, — участник или владелец, а также средство чтения данных индекса поиска.

6. На вкладке "Участники" выберите удостоверение пользователя Или группы Microsoft Entra.

7. Чтобы назначить роль, на вкладке Проверка и назначение выберите Проверка и назначение.

8. Повторите для других ролей. Большинству разработчиков нужны все три.

PowerShell

При использовании PowerShell для назначения ролей вызовите New-AzRoleAssignment, указав имя пользователя или группы Azure и область назначения.

В этом примере создается назначение ролей, область в службу поиска:

New-AzRoleAssignment -SignInName <email> `
    -RoleDefinitionName "Search Index Data Contributor" `
    -Scope  "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Search/searchServices/<search-service>"

В этом примере создается назначение ролей, область в определенный индекс:

New-AzRoleAssignment -SignInName <email> `
    -RoleDefinitionName "Search Index Data Contributor" `
    -Scope  "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Search/searchServices/<search-service>/indexes/<index-name>"

Назначение ролей для запросов только для чтения

Используйте роль средства чтения индексов поиска для приложений и процессов, которым требуется доступ только для чтения к индексу. Это очень конкретная роль. Он предоставляет доступ GET или POST к коллекции документов индекса поиска для поиска, автозаполнения и предложений.

Он не поддерживает операции GET или LIST в индексе или других объектах верхнего уровня или статистике службы GET.

Портал Azure

1. Войдите на портал Azure.

2. Перейдите к своей службе поиска

3. На расположенной слева панели навигации щелкните Управление доступом (IAM).

4. Выберите + Добавить>Добавить назначение ролей.

5. Выберите роль читателя индексов поиска.

6. На вкладке "Участники" выберите удостоверение пользователя Или группы Microsoft Entra. Если вы настраиваете разрешения для другой службы, вы можете использовать системное или управляемое пользователем удостоверение. Выберите этот параметр, если назначение роли предназначено для удостоверения службы.

7. Чтобы назначить роль, на вкладке Проверка и назначение выберите Проверка и назначение.

PowerShell

При назначении ролей с помощью PowerShell выполните команду New-AzRoleAssignment, сообщив Azure имя пользователя или группы, а также область действия назначения.

1. Получите идентификатор подписки, группу ресурсов службы поиска и имя службы поиска.

2. Получите идентификатор объекта службы Azure, например Azure OpenAI.

    Get-AzADServicePrincipal -SearchString <YOUR AZURE OPENAI RESOURCE NAME>
   

3. Получите определение роли и просмотрите разрешения, чтобы убедиться, что это нужная роль.

   Get-AzRoleDefinition -Name "Search Index Data Reader"
   

4. Создайте назначение роли, заменив допустимые значения заполнителей.

   New-AzRoleAssignment -ObjectId YOUR-AZURE-OPENAI-OBJECT-ID -RoleDefinitionName "Search Index Data Reader" -Scope /subscriptions/YOUR-SUBSCRIPTION-ID/resourcegroups/YOUR-RESOURCE-GROUP/providers/Microsoft.Search/searchServices/YOUR-SEARCH-SERVICE-NAME
   

5. Ниже приведен пример назначения роли, область в определенный индекс:

   New-AzRoleAssignment -ObjectId YOUR-AZURE-OPENAI-OBJECT-ID `
       -RoleDefinitionName "Search Index Data Reader" `
       -Scope /subscriptions/YOUR-SUBSCRIPTION-ID/resourcegroups/YOUR-RESOURCE-GROUP/providers/Microsoft.Search/searchServices/YOUR-SEARCH-SERVICE-NAME/indexes/YOUR-INDEX-NAME
   

Тестирование назначений ролей

Используйте клиент для тестирования назначений ролей. Помните, что роли являются накопительными и унаследованными ролями, которые область на уровне подписки или группы ресурсов, нельзя удалить или запретить на уровне ресурса (службы поиска).

Убедитесь, что вы регистрируете клиентское приложение с идентификатором Microsoft Entra ID и имеете назначения ролей перед тестированием доступа.

Портал Azure

1. Войдите на портал Azure.

2. Перейдите к своей службе поиска

3. На странице "Обзор" перейдите на вкладку Индексы.

   • Участники службы поиска могут просматривать и создавать любой объект, но не могут загружать документы или запрашивать индекс. Чтобы проверить разрешения, создайте индекс поиска.

   • Участники индекса поиска могут загружать документы. На портале за пределами мастера импорта данных отсутствует параметр загрузки документов, но вы можете сбросить и запустить индексатор , чтобы подтвердить разрешения на загрузку документов.

   • Средства чтения данных индекса поиска могут запрашивать индекс. Чтобы проверить разрешения, используйте обозреватель поиска. Вы должны иметь возможность отправлять запросы и просматривать результаты, но вы не сможете просмотреть определение индекса или создать его.

REST API

Этот подход предполагает, что Visual Studio Code использует расширение клиента REST.

1. Откройте командную оболочку для Azure CLI и войдите в подписку Azure.

   az login
   

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

   az account show
   

3. Получение маркера доступа.

   az account get-access-token --query accessToken --output tsv
   

4. В новый текстовый файл в Visual Studio Code вставьте следующие переменные:

   @baseUrl = PASTE-YOUR-SEARCH-SERVICE-URL-HERE
   @index-name = PASTE-YOUR-INDEX-NAME-HERE
   @token = PASTE-YOUR-TOKEN-HERE
   

5. Вставьте и отправьте запрос, использующий указанные переменные. Для роли "Средство чтения данных индекса поиска" можно отправить запрос. Вы можете использовать любую поддерживаемую версию API.

   POST https://{{baseUrl}}/indexes/{{index-name}}/docs/search?api-version=2023-11-01 HTTP/1.1
     Content-type: application/json
     Authorization: Bearer {{token}}
   
       {
            "queryType": "simple",
            "search": "motel",
            "filter": "",
            "select": "HotelName,Description,Category,Tags",
            "count": true
        }
   

Дополнительные сведения о том, как получить маркер для конкретной среды, см. в статье "Управление служба ИИ Azure с помощью ИНТЕРФЕЙСов REST API и библиотек проверки подлинности платформа удостоверений Майкрософт".

.NET

1. Используйте пакет Azure.Search.Documents.

2. Используйте Azure.Identity для .NET для проверки подлинности маркеров. Корпорация Майкрософт рекомендует DefaultAzureCredential() для большинства сценариев.

3. Ниже приведен пример подключения клиента с помощью DefaultAzureCredential().

   // Create a SearchIndexClient to send create/delete index commands
   SearchIndexClient adminClient = new SearchIndexClient(serviceEndpoint, new DefaultAzureCredential());
   
   // Create a SearchClient to load and query documents
   SearchClient srchclient = new SearchClient(serviceEndpoint, indexName, new DefaultAzureCredential());
   

4. Ниже приведен еще один пример использования учетных данных секрета клиента:

   var tokenCredential =  new ClientSecretCredential(aadTenantId, aadClientId, aadSecret);
   SearchClient srchclient = new SearchClient(serviceEndpoint, indexName, tokenCredential);
   

Python

1. Используйте azure.search.documents (Azure SDK для Python).

2. Используйте Azure.Identity для Python для проверки подлинности маркеров.

3. Используйте DefaultAzureCredential , если клиент Python является приложением, которое выполняет серверную сторону. Включите интерактивную проверку подлинности , если приложение работает в браузере.

4. Приведем пример:

   from azure.search.documents import SearchClient
   from azure.identity import DefaultAzureCredential
   
   credential = DefaultAzureCredential()
   endpoint = "https://<mysearch>.search.windows.net"
   index_name = "myindex"
   client = SearchClient(endpoint=endpoint, index_name=index_name, credential=credential)
   

JavaScript

1. Используйте @azure/search-documents (Azure SDK для JavaScript) версии 11.3.

2. Используйте Azure.Identity для JavaScript для проверки подлинности маркеров.

3. Если вы используете React, используйте InteractiveBrowserCredential проверку подлинности Microsoft Entra для поиска. Дополнительные сведения см. в разделе "Когда следует использовать @azure/identity ".

Java

1. Используйте azure-search-documents (Azure SDK для Java).

2. Используйте Azure.Identity для Java для проверки подлинности маркеров.

3. Корпорация Майкрософт рекомендует использовать DefaultAzureCredential для приложений, работающих в Azure.

Тестирование от имени текущего пользователя

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

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

   az account get-access-token --scope https://search.azure.com/.default
   

   Или с помощью PowerShell:

   Get-AzAccessToken -ResourceUrl https://search.azure.com
   

2. В новый текстовый файл в Visual Studio Code вставьте следующие переменные:

   @baseUrl = PASTE-YOUR-SEARCH-SERVICE-URL-HERE
   @index-name = PASTE-YOUR-INDEX-NAME-HERE
   @token = PASTE-YOUR-TOKEN-HERE
   

3. Вставьте и отправьте запрос для подтверждения доступа. Вот тот, который запрашивает индекс hotels-quickstart

   POST https://{{baseUrl}}/indexes/{{index-name}}/docs/search?api-version=2023-11-01 HTTP/1.1
     Content-type: application/json
     Authorization: Bearer {{token}}
   
       {
            "queryType": "simple",
            "search": "motel",
            "filter": "",
            "select": "HotelName,Description,Category,Tags",
            "count": true
        }
   

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

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

Портал в настоящее время не поддерживает назначения ролей на этом уровне детализации, но его можно сделать с помощью PowerShell или Azure CLI.

В PowerShell используйте New-AzRoleAssignment, указав имя пользователя или группы Azure и область назначения.

1. Azure Загрузите и модули и AzureAD подключитесь к учетной записи Azure:

   Import-Module -Name Az
   Import-Module -Name AzureAD
   Connect-AzAccount
   

2. Добавьте назначение ролей, область в отдельный индекс:

   New-AzRoleAssignment -ObjectId <objectId> `
       -RoleDefinitionName "Search Index Data Contributor" `
       -Scope  "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Search/searchServices/<search-service>/indexes/<index-name>"
   

Создание пользовательской роли

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

В этом примере клонирует средство чтения данных индекса поиска, а затем добавляет возможность перечислять индексы по имени. Как правило, перечисление индексов в службе поиска считается административным правом.

Портал Azure

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

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

1. В портал Azure перейдите в службу поиска.

2. В области навигации слева выберите контроль доступа (IAM).

3. На панели действий выберите "Роли".

4. Щелкните правой кнопкой мыши средство чтения данных индекса поиска (или другую роль) и выберите "Клонировать ", чтобы открыть мастер создания настраиваемой роли .

5. На вкладке "Основные сведения" укажите имя настраиваемой роли, например "Поиск данных индекса Обозреватель", а затем нажмите кнопку "Далее".

6. На вкладке "Разрешения" нажмите кнопку "Добавить разрешение".

7. На вкладке "Добавление разрешений" найдите и выберите плитку Поиск (Майкрософт).

8. Задайте разрешения для пользовательской роли. В верхней части страницы с помощью выбора действий по умолчанию:

   • В разделе Microsoft.Search/operations выберите "Чтение: вывод списка всех доступных операций".
   • В разделе Microsoft.Search/searchServices/indexes выберите "Чтение: чтение индекса".

9. На той же странице переключитесь на действия данных и в разделе Microsoft.Search/searchServices/indexes/documents выберите "Чтение: чтение документов".

   Определение JSON выглядит следующим образом:

   {
    "properties": {
        "roleName": "search index data explorer",
        "description": "",
        "assignableScopes": [
            "/subscriptions/0000000000000000000000000000000/resourceGroups/free-search-svc/providers/Microsoft.Search/searchServices/demo-search-svc"
        ],
        "permissions": [
            {
                "actions": [
                    "Microsoft.Search/operations/read",
                    "Microsoft.Search/searchServices/indexes/read"
                ],
                "notActions": [],
                "dataActions": [
                    "Microsoft.Search/searchServices/indexes/documents/read"
                ],
                "notDataActions": []
            }
        ]
      }
    }
   

10. Выберите "Проверить и создать" , чтобы создать роль. Теперь вы можете назначить пользователей и группы роли.

Azure PowerShell

В примере PowerShell показан синтаксис JSON для создания настраиваемой роли, которая является клоном средства чтения данных индекса поиска, но с возможностью перечисления всех индексов по имени.

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

   "Microsoft.Search/operations/read",
   "Microsoft.Search/searchServices/read",
   "Microsoft.Search/searchServices/indexes/read"
   

2. Настройте сеанс PowerShell для создания настраиваемой роли. Подробные инструкции см. в статье Azure PowerShell

3. Укажите определение роли в виде документа JSON. В следующем примере показан синтаксис для создания настраиваемой роли с помощью PowerShell.

{
  "Name": "Search Index Data Explorer",
  "Id": "88888888-8888-8888-8888-888888888888",
  "IsCustom": true,
  "Description": "List all indexes on the service and query them.",
  "Actions": [
      "Microsoft.Search/operations/read",
      "Microsoft.Search/searchServices/read"
  ],
  "NotActions": [],
  "DataActions": [
      "Microsoft.Search/searchServices/indexes/read"
  ],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}"
  ]
}

Примечание.

Если назначаемый область находится на уровне индекса, действие данных должно быть"Microsoft.Search/searchServices/indexes/documents/read".

REST API

1. Просмотрите список атомарных разрешений, чтобы определить нужные.

2. Инструкции см. в статье "Создание или обновление пользовательских ролей Azure с помощью REST API ".

3. Клонируйте или создайте роль или используйте JSON для указания настраиваемой роли (см. вкладку PowerShell для синтаксиса JSON).

Azure CLI

1. Просмотрите список атомарных разрешений, чтобы определить нужные.

2. Инструкции см. в статье "Создание или обновление пользовательских ролей Azure с помощью Azure CLI ".

3. Клонируйте или создайте роль или используйте JSON для указания настраиваемой роли (см. вкладку PowerShell для синтаксиса JSON).

Отключение проверки подлинности на основании ключа API

Доступ к ключам или локальная проверка подлинности может быть отключена в службе, если вы используете встроенные роли и проверку подлинности Microsoft Entra. Отключение ключей API приводит к отказу службы поиска всех запросов, связанных с данными, которые передают ключ API в заголовке.

Примечание.

Администратор ключи API могут быть отключены, а не удалены. Ключи API запросов можно удалить.

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

Чтобы отключить проверку подлинности на основе ключей, используйте портал Azure или REST API управления.

Портал

1. В портал Azure перейдите в службу поиска.

2. В области навигации слева выберите "Ключи".

3. Выберите управление доступом на основе ролей.

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

REST API

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

1. Получите параметры службы, чтобы просмотреть текущую конфигурацию.

   GET https://management.azure.com/subscriptions/{{subscriptionId}}/providers/Microsoft.Search/searchServices?api-version=2023-11-01
   

2. Используйте PATCH для обновления конфигурации службы. Следующее изменение присвоит параметру authOptions значение NULL.

   PATCH https://management.azure.com/subscriptions/{{subscriptionId}}/resourcegroups/{{resource-group}}/providers/Microsoft.Search/searchServices/{{search-service-name}}?api-version=2023-11-01
   {
       "properties": {
           "disableLocalAuth": true
       }
   }
   

Запросы, содержащие только ключ API без маркера носителя, завершаются ошибкой HTTP 401.

Чтобы повторно включить проверку подлинности ключа, повторно выполните последний запрос, задав значение "disableLocalAuth" значение false. Служба поиска возобновляет прием ключей API в запросе автоматически (если они указаны).

Условный доступ

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

Чтобы включить политику условного доступа для поиска ИИ Azure, выполните следующие действия.

1. Войдите на портал Azure.

2. Найдите условный доступ Microsoft Entra.

3. Выберите Политики.

4. Выберите Новая политика.

5. В разделе "Облачные приложения" или "Действия " политики добавьте поиск ИИ Azure в качестве облачного приложения в зависимости от способа настройки политики.

6. Обновите оставшиеся параметры политики. Например, укажите, к каким пользователям и группам применяется эта политика.

7. Сохраните политику.

Внимание

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

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

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

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

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