Contrôle d’accès au niveau du document dans Recherche Azure AI

Note

Recherche Azure AI est disponible via le portail Azure, les API REST et les SDK Azure. Il sous-tend également Foundry IQ, la couche de connaissances managée qui transforme le contenu d’entreprise en bases de connaissances réutilisables et prenant en charge les autorisations pour les agents dans le portail Microsoft Foundry.

Important

Les fonctionnalités, capacités ou propriétés marquées (préversion) ne sont pas couvertes par un accord de niveau de service, ne sont pas recommandées pour les workloads de production et peuvent être modifiées ou faire l’objet de restrictions avant leur mise à disposition générale. Les Recherche Azure AI termes de la préversion s'appliquent à toutes les fonctionnalités d'aperçu, qu'il s'agisse d'une fonctionnalité autonome ou d'une partie d'une fonctionnalité généralement disponible.

Recherche Azure AI prend en charge le contrôle d’accès au niveau du document, ce qui permet aux organisations d’appliquer des autorisations affinées au niveau du document, de l’ingestion des données par le biais de l’exécution des requêtes. Cette fonctionnalité est essentielle pour la création de systèmes IA agentiques sécurisés qui enracinent les données, d'applications de génération augmentée par la récupération (RAG) et de solutions de recherche en entreprise nécessitant des vérifications d’autorisation au niveau du document.

Approches pour le contrôle d’accès au niveau du document

Recherche Azure AI fournit quatre approches principales pour appliquer des autorisations au niveau du document, chacune adaptée à différentes sources de données et modèles d’identité.

Approche Description
Filtres de sécurité Comparaison de chaînes. Votre application transmet une identité d'utilisateur ou de groupe sous forme de chaîne, ce qui remplit un filtre dans une requête et exclut les documents qui ne correspondent pas à la chaîne.

Les filtres de sécurité sont une technique permettant d’obtenir un contrôle d’accès au niveau du document. Cette approche n’est pas liée à une API afin de pouvoir utiliser n’importe quelle version ou package.
Étendues ACL / RBAC de type POSIX (version d'évaluation) L’identité de sécurité Microsoft Entra associée au jeton de requête est comparée aux métadonnées d’autorisations des documents renvoyés dans les résultats de recherche, à l’exclusion de tout document dont les autorisations ne correspondent pas. Les autorisations de liste de contrôle d’accès (ACL) s’appliquent aux fichiers et répertoires Azure Data Lake Storage (ADLS) Gen2. Les étendues de contrôle d’accès en fonction du rôle (RBAC) s’appliquent au contenu ADLS Gen2 et aux objets blob Azure.

La prise en charge intégrée de l'accès basé sur l'identité au niveau du document est en préversion, disponible dans les API REST et les packages SDK Azure en préversion qui fournissent cette fonctionnalité. Pour obtenir des preuves de la prise en charge des fonctionnalités, consultez les détails de la prise en charge de la version du SDK.
Étiquettes de confidentialité Microsoft Purview (version préliminaire) Indexeur extrait les étiquettes de confidentialité définies dans Microsoft Purview à partir de sources de données prises en charge (Stockage Blob Azure, ADLS Gen2, SharePoint dans Microsoft 365, OneLake). Ces étiquettes sont stockées en tant que métadonnées et évaluées au moment de la requête pour appliquer l'accès utilisateur en fonction des jetons Microsoft Entra et des attributions de stratégie Purview. Les étiquettes sont également exposées par le biais de sources de connaissances et de la réponse de récupération agentique, ce qui permet aux agents IA et aux applications de conversation consommant une base de connaissances de recevoir le même filtrage prenant en charge les étiquettes. Cette approche aligne l’autorisation de Recherche Azure AI avec le modèle de Protection des informations de Microsoft de votre entreprise.
SharePoint dans les listes de contrôle d’accès Microsoft 365 (préversion) Recherche Azure AI indexeurs extraient les métadonnées d’autorisation à partir du contenu de SharePoint pris en charge et l’utilisent pour les vérifications d’accès au moment de la requête. Pour le contenu pris en charge, les principaux, les relations de groupe, le comportement de synchronisation et les autorisations, consultez Utiliser un indexeur SharePoint pour ingérer des métadonnées d’autorisation.

Pour les sources de connaissances indexées, ingestionPermissionOptions ne peut pas être combinée avec assetStore. Par conséquent, l’affichage d’images (version préliminaire) n’est pas disponible lorsque l’ingestion des autorisations au niveau du document en mode natif est activée.

Choisir une approche

Utilisez les critères suivants pour identifier l’approche qui correspond le mieux à vos exigences de source de données, de modèle d’identité et de conformité.

Scénario Approche recommandée Pourquoi
Système d’identité personnalisé, infrastructure de sécurité non Microsoft ou tout index de modèle push. Filtres de sécurité indépendante des API, en disponibilité générale et fondée sur une simple correspondance de chaînes.
Contenu dans ADLS Gen2 ou Stockage Blob Azure avec des affectations ACL ou RBAC existantes. Étendues ACL / RBAC de type POSIX Intégration native à Microsoft Entra ; l’application au moment de la requête utilise les métadonnées d’autorisation inscrites dans l’index par le mécanisme de synchronisation documenté.
Contenu d’entreprise déjà régi par les stratégies de protection des informations de Microsoft Purview. Étiquettes de sensibilité Microsoft Purview Réutilise les affectations centralisées de classification et de stratégie dans Recherche Azure AI.
Contenu provenant de SharePoint dans Microsoft 365 (bibliothèques, listes, pages de site ASPX). SharePoint dans les listes de contrôle d’accès Microsoft 365 Respecte les autorisations de SharePoint natives, y compris les groupes de sites SharePoint.

Modèle de filtrage de sécurité à l’aide de filtres

Pour les scénarios où l’intégration des étendues ACL/RBAC natives n’est pas viable, utilisez des filtres de chaîne de sécurité pour réduire les résultats en fonction des critères d’exclusion. Le modèle inclut les composants suivants :

  • Pour stocker des identités d’utilisateur ou de groupe, créez un champ de chaîne dans l’index.
  • Chargez l’index à l’aide de documents sources qui incluent des listes de contrôle d’accès associées.
  • Incluez une expression de filtre dans votre logique de requête afin d’effectuer une correspondance sur la chaîne de caractères.
  • Au moment de la requête, obtenez l’identité de l’appelant.
  • Transmettez l’identité de l’appelant comme chaîne de filtre.
  • Les résultats sont limités pour exclure les correspondances qui n'incluent pas la chaîne d'identité de l'utilisateur ou du groupe.

Vous pouvez utiliser des API push ou pull model. Étant donné que cette approche est indépendante de l’API, vous devez simplement vérifier que l’index et la requête ont des chaînes valides (identités) pour l’étape de filtrage.

Cette approche est utile pour les systèmes avec des modèles d’accès personnalisés ou des infrastructures de sécurité non Microsoft. Pour plus d’informations sur cette approche, consultez les filtres Security pour réduire les résultats dans Recherche Azure AI.

Modèle de prise en charge native des ACL de type POSIX et des autorisations d’étendue RBAC (version préliminaire)

La prise en charge native est basée sur les utilisateurs et groupes de Microsoft Entra affiliés aux documents que vous souhaitez indexer et interroger.

les conteneurs Azure Data Lake Storage (ADLS) Gen2 prennent en charge les listes de contrôle d’accès sur le conteneur et sur les fichiers. Pour ADLS Gen2, la conservation de l’étendue RBAC au niveau du document est prise en charge en mode natif lorsque vous utilisez un indexeur ADLS Gen2 ou une source de connaissances Blob (prend en charge ADLS Gen2) et une API en préversion pour ingérer du contenu. Pour les objets blob Azure utilisant l’indexeur d’objets blob Azure ou une source de connaissances, la portée RBAC est conservée au niveau du conteneur.

Pour le contenu sécurisé par la liste de contrôle d’accès, utilisez l’accès de groupe par rapport à l’accès utilisateur individuel pour faciliter la gestion. Le modèle inclut les composants suivants :

Votre application cliente reçoit des autorisations de lecture sur l’index via le rôle Lecteur de données d’index de recherche ou Contributeur de données d’index de recherche . L’accès au moment de la requête est déterminé par les métadonnées d’autorisation d’utilisateur ou de groupe dans le contenu indexé. Les requêtes qui incluent un filtre d’autorisations transmettent un jeton utilisateur ou de groupe sous la forme de x-ms-query-source-authorization dans l’en-tête de la requête. Lorsque vous utilisez des filtres d’autorisation au moment de la requête, Recherche Azure AI recherche deux éléments :

  • Tout d’abord, il recherche l’autorisation Lecteur de données de l’index de recherche qui permet à votre application cliente d’accéder à l’index.

  • Deuxièmement, en tenant compte du jeton supplémentaire sur la demande, il vérifie les autorisations d'utilisateur ou de groupe sur les documents retournés dans les résultats de recherche, à l'exclusion de ceux ne correspondant pas.

Pour obtenir des métadonnées d’autorisation dans l’index, utilisez l’API de modèle Push, en transmettant les documents JSON à l’index de recherche, où la charge utile inclut un champ de chaîne fournissant des ACL de type POSIX pour chaque document. La différence importante entre cette approche et le filtrage de sécurité réside dans le fait que les métadonnées du filtre d’autorisations dans l’index et la requête sont reconnues comme une authentification Microsoft Entra ID, tandis que la solution de contournement de type « security trimming » repose sur une simple comparaison de chaînes de caractères. Vous pouvez également utiliser le Kit de développement logiciel (SDK) Graph pour récupérer les identités.

Vous pouvez également utiliser les API de modèle d’extraction (indexeur) si la source de données est Azure Data Lake Storage (ADLS) Gen2 et que votre code appelle une API d’aperçu pour l’indexation.

Récupérer les métadonnées des autorisations ACL pendant le processus d’ingestion des données (version préliminaire)

La manière de récupérer les autorisations ACL varie selon que vous envoyez une charge utile de documents ou que vous utilisez l’indexeur ADLS Gen2.

Commencez par une API en préversion qui fournit la fonctionnalité :

Pour l’approche du modèle Push :

  1. Vérifiez que votre schéma d’index est créé avec un sdk d’aperçu ou de préversion et que le schéma a des filtres d’autorisation.
  2. Envisagez d’utiliser le Kit de développement logiciel (SDK) Microsoft Graph pour obtenir des identités de groupe ou d’utilisateur.
  3. Utilisez les Index Documents ou l’API Kit de développement logiciel (SDK) Azure équivalente pour envoyer (push) des documents et leurs métadonnées d’autorisation associées dans l’index de recherche.

Pour l’approche d’indexeur ADLS Gen2 du modèle pull ou la source de connaissances Blob (ADLS Gen2) :

  1. Vérifiez que les fichiers du répertoire sont sécurisés à l’aide du modèle de contrôle d’accès ADLS Gen2.
  2. Utilisez Indexers - Create (API REST), Knowledge Sources - Create (API REST) ou une API Kit de développement logiciel (SDK) Azure équivalente pour créer l’indexeur, l’indexeur et la source de données.

Si votre ensemble de compétences segmente des documents, par exemple avec la compétence Fractionnement de texte pour la vectorisation intégrée, les champs de métadonnées d’autorisation passent des mappages de champs d’indexeur aux projections d’index. Consultez Choisir où renseigner les champs ACL.

Modèle d’ingestion des autorisations ACL de base pour SharePoint dans Microsoft 365 (version préliminaire)

Pour le contenu SharePoint indexé, Recherche Azure AI pouvez stocker les autorisations sources en tant que métadonnées et les utiliser pour filtrer les résultats de la requête. Vous pouvez accéder à cette fonctionnalité en préversion via le SharePoint dans Microsoft 365 indexeur et la dernière API REST ou un package de SDK en préversion équivalent.

Pour connaître les exigences d’autorisation, les relations de groupe prises en charge, la synchronisation des autorisations et les limitations, consultez Utiliser un indexeur SharePoint pour ingérer des métadonnées d’autorisation.

Si votre ensemble de compétences segmente des documents (par exemple, avec la compétence Fractionnement de texte pour la vectorisation intégrée), les champs ACL passent des mappages de champs d’indexeur aux projections d’index. Consultez Choisir où renseigner les champs ACL.

Modèle pour les étiquettes de confidentialité Microsoft Purview (version préliminaire)

Lorsque vous activez l’ingestion des étiquettes, Recherche Azure AI extrait les métadonnées de sensibilité des sources de données prises en charge. Ces sources de données incluent Stockage Blob Azure, Azure Data Lake Storage Gen2 (ADLS Gen2), SharePoint dans Microsoft 365 et Microsoft OneLake. Les étiquettes extraites sont stockées dans l’index en même temps que le contenu du document.

Au moment de la requête, Recherche Azure AI vérifie l'étiquette de confidentialité de chaque document, le jeton Microsoft Entra de l'utilisateur et les stratégies Purview de l'organisation pour déterminer l'accès. Le système retourne des documents uniquement si l’identité et les autorisations basées sur l’étiquette de l’utilisateur autorisent l’accès sous les stratégies Purview configurées.

Ce modèle inclut les composants suivants :

  • Configurez votre index, votre source de données et votre indexeur (à des fins de planification) à l’aide de la dernière API REST en préversion ou d’un SDK en préversion qui prend en charge l’ingestion d’étiquette Purview.
  • Activez une identité managée affectée par le système sur votre service de recherche. Les identités managées attribuées par l’utilisateur ne sont pas prises en charge pour l’extraction des étiquettes Purview. La propre identité du service doit disposer des autorisations Purview élevées. Demandez ensuite à votre administrateur global du locataire ou à votre administrateur de rôle à privilèges d’accorder l’accès requis pour permettre au service de recherche de s’authentifier auprès de Microsoft Purview et d’extraire les métadonnées d’étiquetage.
  • Appliquez des étiquettes de confidentialité aux documents avant l’indexation afin que le système puisse les reconnaître et les conserver pendant l’ingestion.
  • Au moment de la requête, attachez un jeton de Microsoft Entra valide via l’en-tête x-ms-query-source-authorization à chaque demande de requête. Recherche Azure AI évalue le jeton et les métadonnées d’étiquette associées pour appliquer le contrôle d’accès en fonction de l’étiquette.

L’application des étiquettes de confidentialité Purview est limitée aux scénarios à locataire unique et nécessite l’authentification RBAC. Pendant la préversion, elle est prise en charge uniquement par le biais de l'API REST et de SDK Azure. Les API Autocomplete et Suggest ne sont actuellement pas disponibles pour les index compatibles avec Purview.

Où les étiquettes de confidentialité sont exposées

Avant que le système puisse appliquer des étiquettes au moment de la requête ou les retourner dans les réponses de récupération, vous devez d’abord synchroniser les métadonnées d’étiquette dans l’index. Les deux chemins de consommation décrits dans cette section dépendent de cette étape de synchronisation. Vous pouvez synchroniser des étiquettes en configurant un indexeur Recherche Azure AI directement sur une source de données prise en charge ou en activant l’option d’ingestion équivalente lorsque vous créez une source de connaissances. Dans les deux cas, votre environnement doit répondre aux prérequis de configuration de la synchronisation des métadonnées de l’étiquette de confidentialité (identité managée, RBAC sur le service de recherche, ainsi que les autorisations Microsoft Purview et de la source de données requises). Pour la configuration de l’indexeur de bout en bout, consultez Utilisez les indexeurs Recherche Azure AI pour ingérer des étiquettes de confidentialité Microsoft Purview. Pour l’ingestion pilotée par la source de connaissances, définissez ingestionPermissionOptions de façon à inclure sensitivityLabel lors de la création de la source de connaissances.

Après avoir synchronisé les étiquettes, deux chemins de requête consomment les mêmes métadonnées d’étiquette indexées. Choisissez le chemin qui correspond à la façon dont votre application appelle Recherche Azure AI :

Si la source de connaissances pointe vers un index découpé en segments, par exemple alimenté par une vectorisation intégrée ou par une compétence personnalisée de division du texte, l’ensemble de compétences doit également projeter l’étiquette de confidentialité vers chaque ligne de segment. En l'absence de cette projection, les références au niveau des segments ne sont pas filtrées.

Pour plus d’informations, consultez Utilisez les indexeurs Recherche Azure AI pour ingérer des étiquettes de confidentialité Microsoft Purview.

Appliquer des autorisations au niveau du document lors de la requête (version préliminaire)

L’application des contrôles sur les requêtes basée sur des jetons est une fonctionnalité transversale qui s’applique aux étendues ACL et RBAC de type POSIX, aux étiquettes de confidentialité Microsoft Purview et aux modèles de listes de contrôle d’accès (ACL) SharePoint dans Microsoft 365. En utilisant l'interrogation basée sur des jetons natifs, Recherche Azure AI valide le jeton Microsoft Entra de l'appelant sur chaque requête et supprime les jeux de résultats uniquement sur les documents que l'appelant est autorisé à lire en fonction des ACL du document, tant que les métadonnées de liste de contrôle d'accès du document sont synchronisées avec l'index.

Lorsque vous attachez le jeton de l'utilisateur à une requête via l'en-tête x-ms-query-source-authorization, Recherche Azure AI :

  1. Extrait du jeton les déclarations d’utilisateur, de groupe et de portée.
  2. Compare ces revendications aux métadonnées d’autorisation stockées en même temps que les documents indexés (entrées ACL, étendues RBAC, affectations d’étiquettes Purview ou SharePoint ACL).
  3. Retourne uniquement les documents dont les métadonnées d’autorisation synchronisées accordent l’accès de l’appelant.

L’application des autorisations au moment de la requête évalue les revendications Microsoft Entra de l’appelant au regard des métadonnées d’autorisation déjà stockées dans l’index. Les modifications d’autorisation dans le système source (appartenance à un groupe Microsoft Entra, ACL ADLS Gen2, attributions d’étiquettes Purview ou SharePoint ACL) ne sont répercutées que dans les résultats de recherche une fois que ces métadonnées sont synchronisées avec l’index via le mécanisme spécifique à la source, par exemple, une exécution d’indexeur ultérieure, une mise à jour d’API push ou une actualisation pilotée par Purview. Pour SharePoint, les modifications de liste de contrôle d’accès sur les éléments disposant d’autorisations uniques sont récupérées de manière incrémentielle sur chaque exécution d’indexeur réussie à partir de l’API REST 2026-05-01-preview, tandis que les modifications héritées des étendues parentes (site, bibliothèque, liste ou dossier) nécessitent une actualisation explicite. Pour plus d’informations, consultez Synchroniser les autorisations entre le contenu indexé et source.

Pour connaître les étapes de mise en œuvre des requêtes de bout en bout, consultez Application des ACL et du RBAC au moment de la requête dans Recherche Azure AI.

Avantages du contrôle d’accès au niveau du document

Le contrôle d’accès au niveau du document natif dans Recherche Azure AI offre des avantages concrets par rapport au filtrage côté application :

  • Élimine le code d’autorisation personnalisé : Vous n’avez pas besoin d’implémenter la résolution de groupe imbriquée, le parcours ACL multiniveau ou le découpage post-requête dans votre application. Recherche Azure AI gère la comparaison et le filtrage pendant l’exécution de la requête.
  • S’aligne sur les contrôles de conformité existants : la réutilisation des métadonnées d’autorisations de Microsoft Entra, Microsoft Purview et SharePoint permet de maintenir les résultats de recherche cohérents avec le système d’identité d’origine. Passez en revue le modèle de synchronisation d’autorisations pour chaque source afin de comprendre ses limitations.
  • Respecte les autorisations de la source après chaque synchronisation des ACL : Pour les approches basées sur des jetons (ACL, étendues de RBAC, étiquettes Purview, ACL SharePoint), l’application des autorisations au moment de la requête utilise les métadonnées d’autorisation que le mécanisme documenté de synchronisation propre à la source (exécution de l’indexeur, mise à jour via l’API Push ou actualisation de Purview) a déjà enregistrées dans l’index.
  • Améliore les performances par rapport au découpage post-requête : Le filtrage à l’intérieur du pipeline de recherche est plus rapide que le chargement de jeux de résultats plus volumineux dans votre application et le découpage là-bas, en particulier à des volumes de requêtes élevés.
  • Réutilise votre infrastructure d’identité existante : Microsoft Entra et les identités SharePoint restent la source de référence pour les décisions d’accès, ce qui réduit la duplication des identités et la charge opérationnelle liée à la maintenance d’un magasin d’autorisations parallèle.

Tutoriels et exemples

Explorez le contrôle d’accès au niveau du document dans Recherche Azure AI avec d’autres articles et exemples.

Contenu connexe

  • Last updated on