Se connecter à la recherche Azure AI en utilisant le contrôle d’accès en fonction du rôle Azure (RBAC Azure)

Azure fournit un système d’autorisation global de contrôle d’accès basé sur les rôles pour tous les services exécutés sur la plateforme. Dans la recherche Azure AI, vous pouvez utiliser des rôles Azure pour :

• Les opérations de plan de contrôle (tâches d’administration de service via Azure Resource Manager).

• Les opérations de plan de données, telles que la création, le chargement et l’interrogation d’index.

L’accès par utilisateur sur les résultats de la recherche (parfois appelé sécurité au niveau des lignes ou sécurité au niveau du document) n’est pas pris en charge. En guise de solution de contournement, créez des filtres de sécurité qui ajustent les résultats par identité utilisateur, en supprimant les documents auxquels le demandeur ne doit pas avoir accès.

Remarque

Dans la recherche Azure AI, « plan de contrôle » fait référence aux opérations prises en charge dans l’API REST de gestion ou les bibliothèques clientes équivalentes. Le « plan de données » fait référence aux opérations sur le point de terminaison du service de recherche, telles que l’indexation ou les requêtes, ou toute autre opération spécifiée dans l'API REST de recherche ou les bibliothèques clientes équivalentes.

Rôles intégrés utilisés dans la Recherche

Les rôles suivants sont intégrés. Si ces rôles sont insuffisants, créez un rôle personnalisé.

Rôle	Plane	Description
Propriétaire	Contrôle et données	Accès complet au plan de contrôle de la ressource de recherche, y compris la possibilité d’affecter des rôles Azure. Seul le rôle Propriétaire peut activer ou désactiver les options d’authentification ou gérer des rôles pour d’autres utilisateurs. Les administrateurs d’abonnements sont membres par défaut. Sur le plan de données, ce rôle a le même accès que le rôle Contributeur de service de recherche. Il inclut l’accès à toutes les actions de plan de données, à l’exception de la possibilité d’interroger les documents d’index.
Contributeur	Contrôle et données	Même niveau d’accès au plan de contrôle que le Propriétaire, moins la possibilité d’affecter des rôles ou de modifier les options d’authentification. Sur le plan de données, ce rôle a le même accès que le rôle Contributeur de service de recherche. Il inclut l’accès à toutes les actions de plan de données, à l’exception de la possibilité d’interroger les documents d’index.
Lecteur	Contrôle et données	L’accès en lecture dans le service entier, ce qui inclut les métriques de recherche, les métriques de contenu (stockage consommé, nombre d’objets) et les définitions d’objet des ressources de plan de données (index, indexeurs, etc.). Toutefois, il ne peut pas lire les clés API ni le contenu dans les index.
Contributeur du service de recherche	Contrôle et données	Accès en lecture-écriture aux définitions d’objets (index, mappages de synonymes, indexeurs, sources de données et ensembles de compétences). Consultez Microsoft.Search/searchServices/* pour obtenir la liste des autorisations. Ce rôle ne peut pas accéder au contenu d’un index, donc pas d’interrogation ou d’indexation, mais il peut créer, supprimer et répertorier des index, retourner des définitions d’index et des statistiques et tester des analyseurs. Ce rôle est destiné aux administrateurs de service de recherche qui doivent gérer le service de recherche et ses objets, mais sans accès au contenu.
Contributeur de données d’index de la Recherche	Données	Accès en lecture/écriture au contenu de tous les index sur le service de recherche. Ce rôle est destiné aux développeurs ou aux propriétaires d’index qui ont besoin d’importer, d’actualiser ou d’interroger la collection de documents d’un index.
Lecteur de données d’index de la Recherche	Données	Accès en lecture seule aux index de recherche sur le service de recherche. Ce rôle est destiné aux applications et utilisateurs qui exécutent des requêtes.

Remarque

Si vous désactivez l’accès en fonction du rôle Azure, les rôles intégrés pour le plan de contrôle (Propriétaire, Contributeur, Lecteur) continuent d’être disponibles. La désactivation d’Azure RBAC supprime uniquement les autorisations liées aux données associées à ces rôles. Dans un scénario avec le RBAC désactivé, le contributeur du service de recherche équivaut au contributeur de plan de contrôle.

Limites

• L’adoption du contrôle d’accès en fonction du rôle risque d’augmenter la latence de certaines requêtes. Chaque combinaison unique de ressource de service (index, indexeur, etc.) et de principal du service utilisé sur une requête déclenche une vérification d’autorisation. Ces vérifications d’autorisation peuvent ajouter jusqu’à 200 millisecondes de latence à une demande.

• Dans de rares cas où les demandes proviennent d’un grand nombre de principaux de service différents, ciblant différentes ressources de service (index, indexeurs, etc.), il est possible que les vérifications d’autorisation entraînent une limitation. La limitation se produit uniquement si des centaines de combinaisons uniques de chaque ressource du service de recherche et du principal de service ont été utilisées en une seconde.

Configurer l’accès en fonction du rôle pour le plan de données

S’applique à : Recherche dans l’index de données Contributeur, Lecteur de données d’index de recherche, Contributeur du Service de recherche

Dans cette étape, configurez votre service de recherche afin qu’il reconnaisse un en-tête d’autorisation sur les demandes de données qui fournissent un jeton d’accès OAuth2.

Azure portal

1. Connectez-vous au portail Azure et ouvrez la page du service de recherche.

2. Sélectionnez Clés dans le volet de navigation de gauche.

   

3. Choisissez une option de contrôle d’accès à l’API. Nous vous recommandons de choisir l’option Les deux si vous souhaitez une flexibilité ou si vous avez besoin de migrer des applications.

   Option	Description
   Clé API	(Valeur par défaut.) Requiert un administrateur ou des clés API de requête dans l'en-tête de la demande pour l'autorisation. Aucun rôle n’est utilisé.
   Contrôle d’accès en fonction du rôle	Nécessite l’appartenance à une attribution de rôle pour terminer la tâche, décrite dans l’étape suivante. Chaque requête nécessite un en-tête d’autorisation.
   Les deux	Les requêtes sont valides à l’aide d’une clé API ou du contrôle d’accès en fonction du rôle (RBAC).

La modification est effective immédiatement, mais attendez quelques secondes avant de tester.

Tous les appels réseau pour les opérations de service de recherche et le contenu respectent l’option que vous sélectionnez : clés API, jeton du porteur ou les deux si vous sélectionnez Les deux.

Lorsque vous activez le contrôle d’accès en fonction du rôle dans le portail, le mode d’échec est « http401WithBearerChallenge » si l’autorisation échoue.

REST API

Utilisez l’API REST de gestion Créer ou mettre à jour le service pour configurer votre service pour le contrôle d’accès en fonction du rôle (RBAC).

Tous les appels à l’API REST de gestion sont authentifiés via Microsoft Entra ID, avec les autorisations Contributeur ou Propriétaire. Pour obtenir de l’aide sur la configuration des requêtes authentifiées, consultez Gérer recherche Azure AI à l’aide de REST.

1. Obtenez les paramètres de service pour pouvoir passer en revue la configuration actuelle.

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

2. Utilisez PATCH pour mettre à jour la configuration du service. Les modifications suivantes activent à la fois les clés et l’accès en fonction du rôle. Si vous souhaitez une configuration de rôles uniquement, consultez Désactiver les clés API.

   Sous « Propriétés », définissez « authOptions » sur « aadOrApiKey ». La propriété « disableLocalAuth » doit être false pour définir « authOptions ».

   Si vous le souhaitez, définissez « aadAuthFailureMode » pour spécifier si 401 est retourné à la place de 403 lorsque l’authentification échoue. Les valeurs valides sont « http401WithBearerChallenge » ou « 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"
               }
           }
       }
   }
   

3. Suivez les instructions de l’étape suivante pour attribuer des rôles pour les opérations de plan de données.

Attribuer des rôles

Les attributions de rôles sont cumulatives et généralisées pour tous les outils et bibliothèques de client. Vous pouvez attribuer des rôles à l’aide de l’une des approches prises en charge décrites dans la documentation sur le contrôle d’accès basé sur les rôles d’Azure.

Vous devez être un Propriétaire ou avoir des autorisationsMicrosoft.Authorization/roleAssignments/write pour gérer les attributions de rôles.

Azure portal

Les attributions de rôles dans le portail s’appliquent à l’ensemble du service. Si vous souhaitez accorder des autorisations à un seul index, utilisez plutôt PowerShell ou Azure CLI.

1. Connectez-vous au portail Azure.

2. Accéder à votre service de recherche.

3. Sélectionnez Contrôle d’accès (IAM) dans le menu de navigation de gauche.

4. Sélectionnez + Ajouter>Ajouter une attribution de rôle.

   

5. Sélectionnez un rôle applicable :

   • Propriétaire
   • Contributeur
   • Lecteur
   • Contributeur du service de recherche
   • Contributeur de données d’index de la Recherche
   • Lecteur de données d’index de la Recherche

6. Sous l’onglet Membres, sélectionnez l’identité de l’utilisateur ou du groupe Microsoft Entra.

7. Dans l’onglet Passer en revue + affecter, sélectionnez Passer en revue + affecter pour affecter le rôle.

PowerShell

Lorsque vous utilisez PowerShell pour attribuer des rôles, appelez New-AzRoleAssignment en indiquant le nom de l'utilisateur ou du groupe Azure et la portée de l'attribution.

Avant de commencer, veillez à charger les modules Az et AzureAD et à vous connecter à Azure :

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

Cet exemple crée une attribution de rôle délimitée à un service de recherche :

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

Cet exemple crée une attribution de rôle délimitée à un index spécifique :

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

Rappelez-vous que vous pouvez uniquement limiter l’accès à des ressources de niveau supérieur, telles que des index, des cartes de synonymes, des indexeurs, des sources de données et des compétences. Vous ne pouvez pas contrôler l’accès aux documents de recherche (contenu d’index) avec des rôles Azure.

Tester les attributions de rôles

Utilisez un client pour tester les attributions de rôles. N’oubliez pas que les rôles sont des rôles cumulatifs et hérités qui sont délimités à l’abonnement ou au groupe de ressources et donc qui ne peuvent pas être supprimés ou refusés au niveau de la ressource (service de recherche).

Assurez-vous d’inscrire votre application cliente avec Microsoft Entra ID et d’avoir des attributions de rôles en place avant de tester l’accès.

Azure portal

1. Connectez-vous au portail Azure.

2. Accéder à votre service de recherche.

3. Dans la page de la vue d’ensemble, sélectionnez l’onglet Index :

   • Les contributeurs peuvent voir et créer n’importe quel objet, mais ils ne peuvent pas interroger un index avec l’Explorateur de recherche.

   • Les lecteurs de données d’index de recherche peuvent utiliser l’Explorateur de recherche pour interroger l'index. Vous pouvez utiliser n’importe quelle version d’API pour vérifier l’accès. Vous devez être en mesure d’envoyer des requêtes et d’afficher les résultats, mais vous ne devriez pas être en mesure d’afficher la définition de l’index.

   • Les contributeurs de données d’index de recherche peuvent sélectionner Nouvel Index pour créer un nouvel index. L’enregistrement d’un nouvel index vérifie l’accès en écriture au service.

REST API

Cette approche suppose Visual Studio Code avec une extension de client REST.

1. Ouvrez un interpréteur de commandes pour Azure CLI et connectez-vous à votre abonnement Azure.

   az login
   

2. Obtenez votre ID de locataire et votre ID d’abonnement. L’ID est utilisé comme variable dans une étape ultérieure.

   az account show
   

3. Obtenez un jeton d’accès.

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

4. Dans un nouveau fichier texte dans Visual Studio Code, collez ces variables :

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

5. Collez puis envoyez une requête qui utilise les variables que vous avez spécifiées. Pour le rôle « Lecteur de données d’index de recherche », vous pouvez envoyer une requête. Vous pouvez utiliser n’importe quelle version d’API prise en charge.

   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
        }
   

Pour plus d’informations sur l’acquisition d’un jeton pour un environnement spécifique, consultez Gérer un service Recherche Azure AI avec des API REST et Bibliothèques d’authentification de la plateforme d’identité Microsoft.

.NET

1. Utilisez le package Azure.Search.Documents.

2. Utilisez Azure.Identity pour .NET pour l’authentification par jeton. Microsoft recommande DefaultAzureCredential() pour la plupart des scénarios.

   • Lors de l’obtention du jeton OAuth, l’étendue est « https://search.azure.com/.default" ». Le kit de développement logiciel (SDK) exige que l’audience soit « https://search.azure.com" ». Le « .default » est une convention Microsoft Entra.

   • Le kit de développement logiciel (SDK) vérifie que l’utilisateur dispose de l’étendue « user_impersonation », qui doit être accordée par votre application, mais le kit de développement logiciel (SDK) lui-même demande « https://search.azure.com/.default" ».

3. Voici un exemple de connexion client utilisant 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. Voici un autre exemple d’utilisation des informations d’identification de la clé secrète client :

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

Python

1. Utilisez azure.search.documents (SDK Azure pour Python).

2. Utilisez Azure.Identity pour Python pour l’authentification par jeton.

3. Utilisez DefaultAzureCredential si le client Python est une application qui exécute côté serveur. Activez l’authentification interactive si l’application s’exécute dans un navigateur.

4. Voici un exemple :

   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. Utilisez @azure/search-documents (kit de développement logiciel Azure pour JavaScript) version 11.3.

2. Utilisez Azure.Identity pour JavaScript pour l’authentification par jeton.

3. Si vous utilisez React, utilisez InteractiveBrowserCredential pour l’authentification Microsoft Entra à rechercher. Consultez Quand utiliser @azure/identity pour plus d’informations.

Java

1. Utilisez azure.search.documents (SDK Azure pour Java).

2. Utilisez Azure.Identity pour Java pour l’authentification par jeton.

3. Microsoft recommande DefaultAzureCredential pour les applications qui s’exécutent sur Azure.

Tester en tant qu’utilisateur actuel

Si vous êtes déjà contributeur ou propriétaire de votre service de recherche, vous pouvez présenter un jeton de porteur pour votre identité utilisateur pour l’authentification auprès de la recherche Azure AI.

1. Obtenez un jeton du porteur pour l’utilisateur actuel à l’aide d’Azure CLI :

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

   Ou à l’aide de PowerShell :

   Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com/"
   

2. Dans un nouveau fichier texte dans Visual Studio Code, collez ces variables :

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

3. Collez puis envoyez une requête pour vérifier l’accès. En voici une qui interroge l’index 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
        }
   

Accorder l’accès à un index unique

Dans certains scénarios, il est possible que vous souhaitiez limiter l’accès d’une application à une seule ressource, comme un index.

Le portail ne prend actuellement pas en charge les attributions de rôles à ce niveau de précision, mais vous pouvez le faire avec PowerShell ou Azure CLI.

Dans PowerShell, utilisez New-AzRoleAssignment, en indiquant le nom de l’utilisateur ou du groupe Azure et l’étendue de l’attribution.

1. Chargez les modules Azure et AzureAD, et connectez-vous à votre compte Azure :

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

2. Ajoutez une attribution de rôle étendue à un index individuel :

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

Créer un rôle personnalisé

Si les rôles intégrés ne fournissent pas la bonne combinaison d’autorisations, vous pouvez créer un rôle personnalisé pour prendre en charge les opérations requises.

Cet exemple clone le lecteur de données d’index de recherche, puis ajoute la possibilité de répertorier les index par nom. Normalement, la liste des index sur un service de recherche est considérée comme un droit administratif.

Azure portal

Ces étapes sont dérivées de Créer ou de mettre à jour des rôles personnalisés Azure à l’aide du Portail Azure. Le clonage à partir d’un rôle existant est pris en charge dans une page de service de recherche.

Ces étapes créent un rôle personnalisé qui augmente les droits de requête de recherche pour inclure des index de liste par nom. En règle générale, la liste des index est considérée comme une fonction d’administrateur.

1. Dans le portail Azure, accédez à votre service de recherche.

2. Sélectionnez Contrôle d’accès (IAM) dans le menu de navigation de gauche.

3. Dans la barre d’action, sélectionnez Rôles.

4. Cliquez avec le bouton droit sur Lecteur de données d’index de recherche (ou un autre rôle) et sélectionnez Cloner pour ouvrir l’Assistant Créer un rôle personnalisé.

5. Sous l’onglet Informations de base, indiquez un nom pour le rôle personnalisé, comme "Explorateur de données d’index de recherche", puis sélectionnez Suivant.

6. Sous l’onglet Autorisations, cliquez sur Ajouter des autorisations.

7. Sous l’onglet Ajouter des autorisations, recherchez, puis sélectionnez la vignette Recherche Microsoft.

8. Définissez les autorisations pour votre rôle personnalisé. En haut de la page, à l’aide de la sélection Actions par défaut :

   • Sous Microsoft.Search/operations, sélectionnez Lecture : Répertorier toutes les opérations disponibles.
   • Sous Microsoft.Search/searchServices/index, sélectionnez Lecture : Index de lecture.

9. Dans la même page, basculez vers Actions de données et sous Microsoft.Search/searchServices/index/documents, sélectionnez Lecture : Lire des documents.

   La définition JSON ressemble à l’exemple qui suit :

   {
    "properties": {
        "roleName": "search index data explorer",
        "description": "",
        "assignableScopes": [
            "/subscriptions/a5b1ca8b-bab3-4c26-aebe-4cf7ec4791a0/resourceGroups/heidist-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. Sélectionnez Vérifier + créer pour créer le rôle. Vous pouvez maintenant affecter des utilisateurs et des groupes au rôle.

Azure PowerShell

L’exemple PowerShell montre la syntaxe JSON pour créer un rôle personnalisé qui est un clone du lecteur de données d’index de recherche, mais avec la possibilité de répertorier tous les index par nom.

1. Examinez la liste des autorisations atomiques pour déterminer celles dont vous avez besoin. Pour cet exemple, vous aurez besoin des éléments suivants :

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

2. Configurez une session PowerShell pour créer le rôle personnalisé. Pour obtenir des instructions détaillées, consultez Azure PowerShell.

3. Fournissez la définition de rôle sous la forme d’un document JSON. L’exemple suivant montre la syntaxe permettant de créer un rôle personnalisé avec 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}"
  ]
}

Remarque

Si l’étendue assignable se trouve au niveau de l’index, l’action de données doit être "Microsoft.Search/searchServices/indexes/documents/read".

REST API

1. Examinez la liste des autorisations atomiques pour déterminer celles dont vous avez besoin.

2. Pour savoir comment procéder, consultez Créer ou mettre à jour des rôles personnalisés Azure à l’aide de l’API REST.

3. Clonez ou créez un rôle, ou utilisez JSON pour spécifier le rôle personnalisé (voir l’onglet PowerShell pour la syntaxe JSON).

Azure CLI

1. Examinez la liste des autorisations atomiques pour déterminer celles dont vous avez besoin.

2. Pour savoir comment procéder, consultez Créer ou mettre à jour des rôles personnalisés Azure à l’aide d’Azure CLI.

3. Clonez ou créez un rôle, ou utilisez JSON pour spécifier le rôle personnalisé (voir l’onglet PowerShell pour la syntaxe JSON).

Désactiver l'authentification par clé API

Vous pouvez désactiver l’accès à la clé, ou l’authentification locale, sur votre service si vous utilisez les rôles Contributeur du service de recherche, Contributeur aux données d’index de recherche et Lecteur de données d’index de recherche, ainsi que l’authentification Microsoft Entra. La désactivation des clés API entraîne le refus par le service de recherche de toutes les requêtes liées aux données qui passent une clé API dans l’en-tête.

Remarque

Les clés API d’administrateur peuvent uniquement être désactivées, et non supprimées. Vous pouvez supprimer des clés API de requête.

Des autorisations de Propriétaire ou de Contributeur sont requises pour désactiver les fonctionnalités.

Pour désactiver l’authentification basée sur les clés, utilisez le portail Azure ou l’API REST de gestion.

Portail

1. Dans le portail Azure, accédez à votre service de recherche.

2. Dans le volet de navigation gauche, sélectionnez Clés.

3. Sélectionnez Contrôle d’accès en fonction du rôle.

La modification est effective immédiatement, mais attendez quelques secondes avant de tester. En supposant que vous êtes autorisé à attribuer des rôles en tant que membre du propriétaire, administrateur de service ou coadministrateur, vous pouvez utiliser les fonctionnalités du portail pour tester l’accès en fonction du rôle.

REST API

Pour désactiver l’authentification basée sur des clés, définissez « disableLocalAuth » sur true.

1. Obtenez les paramètres de service pour pouvoir passer en revue la configuration actuelle.

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

2. Utilisez PATCH pour mettre à jour la configuration du service. La modification suivante définit « authOptions » sur 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
       }
   }
   

Les requêtes qui incluent une clé API uniquement, sans jeton de porteur, échouent avec un HTTP 401.

Pour réactiver l’authentification de la clé, réexécutez la dernière demande, en affectant la valeur false à « disableLocalAuth ». Le service de recherche recommence à accepter automatiquement les clés API sur la requête (en supposant qu'elles soient spécifiées).

Accès conditionnel

L’accès conditionnel est un outil utilisé dans Microsoft Entra ID pour appliquer des stratégies organisationnelles. En utilisant des stratégies d’accès conditionnel, vous pouvez appliquer les contrôles d’accès nécessaires pour garantir la sécurité de votre organisation. Lors de l’accès à un service Search Azure AI à l’aide du contrôle d’accès en fonction du rôle, l’accès conditionnel peut appliquer des stratégies organisationnelles.

Pour activer une stratégie d’accès conditionnel pour la recherche Azure AI, procédez comme suit :

1. Connectez-vous au portail Azure.

2. Recherchez l’accès conditionnel Microsoft Entra.

3. Sélectionnez Stratégies.

4. Sélectionnez + Nouvelle stratégie.

5. Dans la section Applications cloud ou actions de la stratégie, ajoutez Recherche Azure AI en tant qu’application cloud selon la manière dont vous souhaitez configurer votre stratégie.

6. Mettez à jour les paramètres restants de la stratégie. Par exemple, spécifiez les utilisateurs et les groupes auxquels cette stratégie s’applique.

7. Enregistrez la stratégie.

Important

Si une identité managée est attribuée à votre service de recherche, celui-ci apparaîtra comme une application cloud qui peut être incluse ou exclue dans le cadre de la stratégie d’accès conditionnel. Les stratégies d’accès conditionnel ne peuvent pas être appliquées à un service de recherche spécifique. Veillez plutôt à sélectionner l’application cloud générale Recherche Azure AI.

Résolution des problèmes de contrôle d’accès en fonction du rôle

Lorsque vous développez des applications qui utilisent le contrôle d’accès en fonction du rôle pour l’authentification, il est possible que certains problèmes courants se produisent :

• Si le jeton d’autorisation provient d’une identité managée et que les autorisations appropriées ont été récemment attribuées, il est possible que la prise d’effet de celles-ci prenne plusieurs heures.
• La configuration par défaut d’un service de recherche est une authentification en fonction d’une clé uniquement. Si vous n’avez pas modifié le paramètre de clé par défaut sur Les deux ou Contrôle d’accès en fonction du rôle, toutes les requêtes utilisant l’authentification en fonction du rôle sont automatiquement refusées, quelles que soient les autorisations sous-jacentes.