Application lors de l’exécution des requêtes des étiquettes de confidentialité Microsoft Purview dans Recherche Azure AI (préversion)

Lors de l’exécution d’une requête, Recherche Azure AI peut appliquer des stratégies d’étiquettes de confidentialité (préversion) définies dans Microsoft Purview. Ces stratégies incluent l’évaluation des EXTRACT droits d’utilisation associés à chaque document, ce qui garantit que les utilisateurs peuvent uniquement récupérer des documents auxquels ils sont autorisés à accéder.

Cette fonctionnalité étend contrôle d'accès au niveau du document pour s'aligner sur les exigences de protection et de conformité de votre organisation gérées dans Microsoft Purview.

Lorsque l’indexation d’étiquettes de confidentialité Purview est activée, Recherche Azure AI vérifie les métadonnées d’étiquette de chaque document au moment de la requête. Il applique des filtres d’accès basés sur des stratégies Purview pour renvoyer uniquement les résultats que l’utilisateur demandeur est autorisé à accéder.

Cet article explique comment fonctionne l’application des étiquettes de confidentialité au moment de la requête et comment émettre des requêtes de recherche sécurisées.

Conditions préalables

• Complétez toutes les étapes de Utiliser les indexeurs Recherche Azure AI pour ingérer les étiquettes de confidentialité Microsoft Purview.

• Vérifiez que le service Recherche Azure AI a son identité gérée attribuée par le système (et non une identité gérée attribuée par l’utilisateur) activée et qu’il dispose des attributions de rôles Content.SuperUser et UnifiedPolicy.Tenant.Read. L’application du temps de requête dépend des métadonnées d’étiquette que l’indexeur peut extraire uniquement lorsque l’identité affectée par le système a la configuration correcte. Consultez l’étape 1 dans l’article de configuration de l’indexeur.

• Le service Recherche Azure AI et l’utilisateur qui émet la requête doivent se trouver dans le même locataire Microsoft Entra.

• API REST version 2025-11-01-preview ou ultérieure, ou un package de SDK en préversion équivalent, pour interroger l’index. La fonctionnalité de lecture avec privilèges élevés et la journalisation d’audit Purview nécessitent 2026-05-01-preview ou version ultérieure.

• Authentifiez les requêtes à l’aide de Azure contrôle d’accès en fonction du rôle (RBAC), et non des clés API. Lorsque les étiquettes de sensibilité Purview sont activées, l'accès à la clé API est limité à la récupération du schéma d'index.

Limitations

• Les comptes invités et les requêtes interlocataires ne sont pas pris en charge.

• Les API Autocomplete et Suggest ne sont pas prises en charge pour les index activés avec Purview.

• Si l’évaluation de l’étiquette échoue, le service retourne un code d’erreur HTTP spécifique plutôt qu’un jeu de résultats partiel ou non filtré. Pour obtenir la liste complète des codes d’erreur et des causes, consultez Résoudre les erreurs de requête.

• Le système évalue uniquement les étiquettes comme elles existaient au moment de la dernière exécution de l’indexeur. Les modifications d’étiquette récentes peuvent ne pas être répercutées tant que la réindexation planifiée suivante n’est pas reflétée.

Fonctionnement de l’application des étiquettes de confidentialité au moment de la requête

Lorsque vous interrogez un index qui inclut les étiquettes de confidentialité de Microsoft Purview, Recherche Azure AI vérifie les stratégies Purview associées avant de renvoyer les résultats. De cette façon, la requête retourne uniquement les documents auxquels le jeton utilisateur est autorisé à accéder.

1. Entrée de l'identité de l'utilisateur et du rôle de l'application

Au moment de la requête, Recherche Azure AI valide les deux :

• Le rôle RBAC de l'application appelante, fourni dans l’en-tête Authorization. Le rôle minimal requis est Search Index Data Reader. Pour plus d’informations, consultez le guide Recherche Azure AI RBAC.
• Identité de l’utilisateur via un jeton, fourni dans l’en-tête x-ms-query-source-authorization .

Les deux sont nécessaires pour autoriser la visibilité basée sur l’étiquette.

2. Évaluation de l'étiquette de sensibilité

Lorsqu’une demande de requête est reçue, Recherche Azure AI évalue :

1. Champ sensitivityLabel dans chaque document indexé (extrait de Microsoft Purview pendant l’ingestion).
2. Les autorisations Purview effectives de l'utilisateur, telles que définies par Microsoft Entra ID et la stratégie d'étiquette Purview.

Si l’utilisateur n’est pas autorisé pour l’étiquette de sensibilité d’un document avec les permissions EXTRACT, ce document est exclu des résultats de la requête.

3. Filtrage des résultats sécurisé

Recherche Azure AI applique le filtre de sécurité après tous les filtres définis par l’utilisateur et les étapes de scoring.
Un document est inclus dans le jeu de résultats final uniquement si :

• L’application appelante a une attribution de rôle valide (via RBAC) et
• Le jeton d’identité utilisateur représenté par x-ms-query-source-authorization est valide et autorisé à afficher le contenu avec l’étiquette de confidentialité du document.

Si l’une ou l’autre condition échoue, le document est omis des résultats.

Acquérir un jeton d’accès utilisateur

Pour interroger Recherche Azure AI à l’aide du contexte utilisateur, vous devez acquérir un jeton d’accès qui représente l’utilisateur connecté. L’approche que vous utilisez varie selon que vous effectuez des tests localement avec votre propre jeton, si vous avez accès au document source ou que vous implémentez le flux d’application qui nécessite la transmission du jeton de l’utilisateur final.

Pour les scénarios de test

Pour les tests locaux, vous pouvez récupérer un jeton d’accès utilisateur à l’aide de Azure CLI :

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

Cette approche utilise votre session de connexion Azure CLI actuelle, ce qui vous permet d’utiliser le contexte sur les documents pour lesquels vous avez des autorisations EXTRACT attribuées via des étiquettes de confidentialité. Cette méthode est destinée uniquement aux scénarios de développement et de validation.

Acquisition de jetons pour les scénarios OBO

Les applications qui implémentent le flux on-behalf-of (OBO) doivent acquérir des jetons via Microsoft Entra ID en utilisant une bibliothèque d’authentification prise en charge, telle que Microsoft Authentication Library (MSAL).

Dans les scénarios OBO, demandez le jeton pour l’API en aval que l’application appelle. Par exemple, lors de l’appel de Recherche Azure AI, l’URI de ressource est https://search.azure.com/.default.

L’étendue .default demande toutes les autorisations déléguées que l’application a préconsentées pour la ressource spécifiée.

Les autorisations d'étiquette de sensibilité, y compris EXTRACT, ne sont pas représentées en tant que scopes OAuth. Le service en aval, tel que Recherche Azure AI, évalue ces autorisations au moment de l’exécution en fonction de l’identité de l’utilisateur dans le jeton et de la stratégie d’étiquette de confidentialité appliquée.

Exemple de requête

Voici un exemple de requête qui utilise l’application des étiquettes de confidentialité Microsoft Purview.

Transmettez le jeton d’application en tant que jeton du porteur dans l'en-tête Authorization. Transmettez le jeton utilisateur sous forme de valeur brute du jeton dans l’en-tête x-ms-query-source-authorization, sans le préfixe Bearer.

POST  {{endpoint}}/indexes/sensitivity-docs/docs/search?api-version=2026-08-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"
}

Accès en lecture avec élévation de privilèges pour les enquêtes administratives (préversion)

La lecture avec élévation de privilèges permet à un développeur autorisé de retourner des documents étiquetés que l'utilisateur appelant ne peut normalement pas voir, tout en émettant une entrée de journal d'audit Microsoft Purview pour chaque document retourné par la demande. Utilisez-le pour les révisions de conformité, eDiscovery, réponse aux incidents et autres enquêtes administratives où un enregistrement auditable de l’accès est requis.

La lecture privilégiée est disponible sur les index compatibles avec Purview dans la version 2026-05-01-preview de l’API REST et les versions ultérieures.

Fonctionnement de la lecture avec élévation de privilèges

1. L’application appelante définit l’en-tête x-ms-enable-elevated-read: true sur la demande de recherche.

2. Recherche Azure AI ignore la vérification d'accès basée sur l'étiquette par document et retourne des documents correspondants, quelles que soient les autorisations EXTRACT de l'utilisateur demandées sur chaque étiquette.

3. Pour chaque document de la réponse, Recherche Azure AI émet une entrée au journal d’audit Microsoft Purview pour le compte du locataire demandeur. Une requête de recherche unique qui retourne N documents génère des entrées d’audit N .

4. Les entrées d’audit sont chargées de manière asynchrone vers Purview une fois la réponse de recherche retournée.

Attribution de rôle requise

L’utilisateur développeur appelant doit disposer du rôle Contributeur aux données d’index de recherche au niveau du service de recherche ou de l’index. Le lecteur de données d’index de recherche n’est pas suffisant. La lecture en mode élevé échoue avec 403 Forbidden si le rôle n’est pas attribué. Pour plus d’informations sur les rôles Recherche Azure AI, consultez Connect to Recherche Azure AI using roles.

Lorsque l’en-tête x-ms-enable-elevated-read est défini sur true, l’en-tête x-ms-query-source-authorization ne peut pas être utilisé.

Exemple de lecture avec élévation de privilèges

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

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

Champs d’audit envoyés à Microsoft Purview

Chaque entrée d’audit suit le schéma Office 365 l’API d’activité de gestion et inclut les champs suivants.

Dégradation progressive

Si Recherche Azure AI ne peut pas joindre Microsoft Purview lors du traitement d’une requête, par exemple en cas d’indisponibilité temporaire de Purview, il ignore l’évaluation des étiquettes pour cette requête. Le comportement dépend du fait que la demande inclut un jeton d’identité utilisateur :

• Demandes de lecture avec élévation de privilèges (x-ms-enable-elevated-read: true) : la requête échoue avec 5xx. Recherche Azure AI ne retourne pas de documents étiquetés sans pouvoir d'abord émettre des journaux d'audit.

• Requêtes standard imposées par l’étiquette (avec x-ms-query-source-authorization) : la requête échoue avec 5xx. Recherche Azure AI ne retourne pas de résultats partiels ou non filtrés lorsqu'il ne peut pas évaluer les stratégies d'étiquette.

• Appels sans x-ms-query-source-authorization émis par une application disposant au minimum du rôle Lecteur des données d’index de recherche : la requête réussit et renvoie uniquement les documents qui n’ont pas d’étiquette de sensibilité. Les documents étiquetés sont omis de la réponse.

Ce chemin détérioré est destiné uniquement aux flux de travail non accessibles à l’utilisateur qui acceptent explicitement les résultats non étiquetés uniquement. Ne vous fiez pas à celle-ci pour les expériences de recherche des utilisateurs finaux.

Pour obtenir la liste complète des codes d’erreur retournés lors de l’évaluation de l’étiquette de confidentialité au moment de la requête, consultez Résoudre les erreurs de requête.

Rechercher les journaux d’audit de lecture avec élévation de privilèges dans Microsoft Purview

Recherche Azure AI charge les entrées d'audit dans le journal d'audit Microsoft Purview du locataire appelant. Pour enquêter sur une activité de lecture élevée :

1. Dans le portail Microsoft Purview, sélectionnez Solutions>Audit.

2. Sélectionnez Audit Search, puis filtrez par plage de dates, utilisateur ou Recherche Azure AI type d’enregistrement.

3. Ouvrez une entrée pour afficher les champs de schéma standard et les champs personnalisés Recherche Azure AI, notamment SensitivityLabelName, DocumentDataSourceType et DocumentDataSourceId.

Pour obtenir des instructions pas à pas sur la façon d’effectuer des recherches dans le journal d’audit, sur le comportement de rétention et sur les rôles Purview requis, consultez Rechercher dans le journal d’audit dans le portail Microsoft Purview.

Gestion des étiquettes de confidentialité dans Recherche Azure AI

Lorsque Recherche Azure AI indexe le contenu du document avec des étiquettes de confidentialité provenant de sources telles que SharePoint, Azure Blob et d’autres, il stocke le contenu et les métadonnées d’étiquette. La requête de recherche retourne du contenu indexé ainsi que le GUID qui identifie l’étiquette de confidentialité appliquée au document, uniquement si l’utilisateur dispose d’un accès aux données EXTRACT pour ce document affecté via la définition d’étiquette de confidentialité. Ce GUID identifie de manière unique l’étiquette, mais n’inclut pas de propriétés lisibles par l’homme, telles que le nom de l’étiquette ou les autorisations associées.

Notez que le GUID seul est insuffisant pour les scénarios qui incluent l’interface utilisateur, car les étiquettes de confidentialité comportent souvent d’autres contrôles de stratégie appliqués par Protection des données Microsoft Purview, par exemple : autorisations d’impression ou restrictions de capture d’écran et capture d’écran. Recherche Azure AI ne présente pas ces fonctionnalités.

Pour afficher les noms d’étiquettes et/ou appliquer des restrictions spécifiques à l’interface utilisateur, votre application doit appeler le point de terminaison Protection des données Microsoft Purview pour récupérer les métadonnées d’étiquette complètes et les autorisations associées.

Vous pouvez utiliser le GUID retourné par Recherche Azure AI pour résoudre les propriétés d’étiquette et appeler les API Purview Labels pour récupérer le nom, la description et les paramètres de stratégie de l’étiquette.

Dépanner les erreurs de requête

Lorsque l’évaluation de l’étiquette de confidentialité au moment de la requête échoue, Recherche Azure AI retourne un code d’erreur HTTP spécifique qui identifie la cause. Le service ne retourne jamais un jeu de résultats partiel ou non filtré. Si les stratégies d’étiquette ne peuvent pas être évaluées, la requête échoue plutôt que d’exposer du contenu non étiqueté ou non autorisé.

400 Demande incorrecte

Une erreur 400 indique un problème avec la configuration d’index ou les en-têtes de requête. Corrigez la configuration avant de réessayer.

401 Non autorisé

Une erreur 401 indique un problème avec le jeton d’autorisation ou les autorisations Purview de l’application.

502 Mauvaise passerelle

Une erreur 502 indique une défaillance de connectivité entre Recherche Azure AI et Microsoft Purview. Ces erreurs sont généralement temporaires.

Délai d’expiration de la passerelle 504

Une erreur 504 indique que Microsoft Purview n'a pas répondu dans le délai imparti.

Configuration des tests de bout en bout

Pour vous aider à valider la configuration de votre étiquette de sensibilité dans Recherche Azure AI, consultez la configuration de référence de bout en bout.

Ce référentiel montre comment :

• Configurer la synchronisation et le respect des étiquettes de sensibilité dans Recherche Azure AI
• Testez les scénarios d’ingestion et d’application des étiquettes au moment des requêtes pour les documents comportant des étiquettes de confidentialité.
• Extrayez le nom de l’étiquette et exposez-le dans les citations utilisées par vos applications ou agents RAG.