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

Azure AI Search 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, à partir de l’ingestion de données par le biais de l’exécution des requêtes. Cette capacité est essentielle pour développer des systèmes d'agents IA sécurisés, établir les données de base, les applications de génération Retrieval-Augmented (RAG) et les solutions de recherche d'entreprise qui nécessitent des contrôles d'autorisation au niveau du document.

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

Approche	Descriptif
Filtres de sécurité	Comparaison de chaînes. Votre application envoie une identité d'utilisateur ou de groupe en tant que chaîne de caractères, qui remplit un filtre sur une requête, excluant 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 (aperçu)	Le principal de sécurité Microsoft Entra associé au jeton de requête est comparé aux métadonnées d'autorisation des documents renvoyés dans les résultats de recherche, à l'exclusion des documents dont les autorisations ne correspondent pas. Les autorisations ACL (Access Control Lists) s’appliquent aux répertoires et fichiers 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 en préversion des packages du Kit de développement logiciel (SDK) Azure qui fournissent la fonctionnalité. Veillez à vérifier le journal des modifications du package sdk pour obtenir des preuves de prise en charge des fonctionnalités.
Étiquettes de sensibilité Microsoft Purview (aperçu)	L'indexeur extrait les étiquettes de sensibilité 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. Cette approche aligne l’autorisation Recherche Azure AI avec le modèle Microsoft Information Protection de votre entreprise.
SharePoint dans les listes de contrôle d’accès Microsoft 365 (préversion)	Une fois configurés, les indexeurs Recherche Azure AI extraient les autorisations de document SharePoint directement à partir des listes de contrôle d’accès Microsoft 365 pendant l’ingestion initiale. Les vérifications d’accès utilisent les appartenances des utilisateurs et des groupes Microsoft Entra. Les types de groupes pris en charge incluent les groupes de sécurité Microsoft Entra, les groupes Microsoft 365 et les groupes de sécurité activés pour la messagerie. Les groupes SharePoint ne sont pas encore pris en charge en préversion.

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, nous vous recommandons d'utiliser des filtres de chaînes de sécurité pour affiner 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 expression de requête pour faire correspondre la chaîne.
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 ajusté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 vous assurer 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 Filtres de sécurité pour réduire les résultats dans Recherche IA Azure.

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

La prise en charge native est basée sur les utilisateurs et groupes Microsoft Entra affiliés à des 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 ACL, nous vous recommandons de privilégier l'accès par groupe plutôt que par utilisateur individuel afin de faciliter la gestion. Le modèle inclut les composants suivants :

Commencez par des documents ou fichiers qui ont des ACL.
Activez les filtres d’autorisation dans l’index.
Ajoutez un filtre d’autorisation à un champ de chaîne dans un index.
Chargez l’index avec des documents sources ayant des ACL associées.
Interrogez l’index, en ajoutant x-ms-query-source-authorization dans l’en-tête de la requête.

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’autorisation transmettent un jeton d’utilisateur ou de groupe sous la forme de x-ms-query-source-authorization dans l’en-tête de 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, compte tenu du jeton supplémentaire dans la demande, il vérifie les autorisations d'utilisateur ou de groupe sur les documents retournés dans les résultats de recherche, en excluant ceux qui ne correspondent pas.

Pour obtenir des métadonnées d’autorisation dans l’index, vous pouvez utiliser 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 la ciselure de sécurité est que les métadonnées du filtre d'autorisation dans l'index et la requête sont reconnues via l'authentification d'ID Microsoft Entra, tandis que la solution de contournement de la ciselure de sécurité 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 en préversion pour l’indexation.

Récupérer les métadonnées des autorisations ACL pendant le processus d’ingestion des données (aperçu)

La façon dont vous récupérez les autorisations d'ACL varie selon si vous envoyez une charge utile de documents ou si vous utilisez l’indexeur ADLS Gen2.

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

Pour l’approche du modèle Push :

Vérifiez que votre schéma d’index est également créé avec un kit SDK d’aperçu ou de préversion et que le schéma dispose de filtres d’autorisation.
Envisagez d’utiliser le Kit de développement logiciel (SDK) Microsoft Graph pour obtenir des identités de groupe ou d’utilisateur.
Utilisez les documents d’index ou l’API Azure SDK équivalente pour envoyer 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) :

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.
Utilisez l’API REST Créer un indexeur ou créer une API REST source de connaissances ou une API AZURE SDK équivalente pour créer l’indexeur, l’index et la source de données.

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

Pour le contenu SharePoint dans Microsoft 365, Azure AI Recherche peut appliquer des autorisations au niveau du document en fonction des listes de contrôle d’accès SharePoint. Cette intégration favorise que seuls les utilisateurs ou les groupes ayant accès au document source dans SharePoint peuvent les récupérer dans les résultats de recherche, dès que les autorisations sont synchronisées dans l’index. Les autorisations sont appliquées à l’index soit pendant l'ingestion initiale des documents.

La prise en charge des ACL SharePoint est disponible en préversion via l'indexeur SharePoint à l'aide de l'API REST 2025-11-01-preview ou du SDK pris en charge. L’indexeur extrait les métadonnées d’autorisation de fichier et d’élément de liste et les conserve dans l’index de recherche, où il est utilisé pour appliquer le contrôle d’accès au moment de la requête.

Le modèle inclut les composants suivants :

Utilisez l'indexeur SharePoint dans Microsoft 365 avec les autorisations d'application pour lire le contenu du site SharePoint et les autorisations complètes pour lire les ACL. Suivez les instructions de configuration de la liste de contrôle d’accès de l’indexeur SharePoint pour l’activation et les limitations.
Lors de l’indexation initiale, les entrées de liste de contrôle d’accès SharePoint (utilisateurs et groupes) sont stockées en tant que métadonnées d’autorisation dans l’index de recherche.
Pour l’indexation incrémentielle des listes de contrôle d’accès, passez en revue les mécanismes de resynchronisation de la liste de contrôle d’accès SharePoint disponibles lors de la préversion publique.
Lors de l'exécution de la requête, Azure AI Search vérifie le principal Microsoft Entra dans le jeton de requête par rapport aux métadonnées ACL SharePoint stockées dans l'index. Il exclut les documents auxquels l’appelant n’est pas autorisé à accéder.

Pendant la préversion, seuls les types principaux suivants sont pris en charge dans les listes de contrôle d’accès SharePoint :

Comptes d’utilisateur Microsoft Entra
Groupes de sécurité Microsoft Entra
Groupes Microsoft 365
Groupes de sécurité compatibles avec la messagerie

Les groupes SharePoint ne sont pas pris en charge dans la préversion.

Pour plus d’informations sur la configuration et les limitations complètes, consultez Comment indexer SharePoint dans les autorisations au niveau du document Microsoft 365 (préversion).

Gabarit pour les étiquettes de sensibilité Microsoft Purview (version préliminaire)

Azure AI Search peut ingérer et appliquer des étiquettes de confidentialité Microsoft Purview pour le contrôle d’accès au niveau du document, en étendant les stratégies de protection des informations de Microsoft Purview dans vos applications de recherche et de récupération.

Lorsque l’ingestion de labels est activée, Azure AI Search extrait les métadonnées de sensibilité des sources de données prises en charge. Notamment : 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, Azure AI Search vérifie l’étiquette de confidentialité de chaque document, le jeton Microsoft Entra de l’utilisateur et les stratégies Purview de l’organisation afin de déterminer l’accès. Les documents sont retournés uniquement si l’identité de l’utilisateur et les autorisations basées sur l’étiquette autorisent l’accès sous les stratégies Purview configurées.

Le modèle inclut les composants suivants :

Configurez votre index, votre source de données et votre indexeur (à des fins de planification) à l’aide de l’API REST 2025-11-01-preview ou d’un SDK correspondant qui prend en charge l’ingestion d’étiquette Purview.
Activez une identité managée affectée par le système à votre service de recherche. Demandez ensuite à votre administrateur général client ou administrateur de rôle privilégié d’accorder l’accès requis, afin que le service de recherche puisse accéder en toute sécurité à Microsoft Purview et extraire les métadonnées d’étiquette.
Appliquez des étiquettes de confidentialité aux documents avant l’indexation afin qu’elles puissent être reconnues et conservées pendant l’ingestion.
Au moment de la requête, joignez un jeton Microsoft Entra valide via l’en-tête x-ms-query-source-authorization à chaque requête. Azure AI Search évalue le jeton et les métadonnées d'étiquette associées pour appliquer le contrôle d'accès basé sur l'étiquette.

L'application des étiquettes de sensibilité Purview est limitée aux scénarios mono-locataires, nécessite une authentification RBAC et, pendant la préversion publique, n'est prise en charge que via l'API REST ou le SDK. Les APIs de saisie semi-automatique et de suggestion ne sont pas disponibles pour les index activés avec Purview pour l'instant.

Pour plus d’informations, consultez Utilisez les indexeurs de recherche Azure AI pour intégrer des étiquettes de sensibilité Microsoft Purview.

Appliquer des autorisations au niveau du document au moment de la requête

Avec l’interrogation native basée sur des jetons, Azure AI Search valide le jeton Microsoft Entra d’un utilisateur, réduisant les jeux de résultats pour inclure uniquement les documents auxquels l’utilisateur est autorisé à accéder.

Vous pouvez obtenir un découpage automatique en attachant le jeton Microsoft Entra de l’utilisateur à votre demande de requête. Pour plus d’informations, consultez le contrôle d'accès en temps de requête et l'application des contrôles RBAC dans Azure AI Search.

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

Le contrôle d’accès au niveau du document est essentiel pour protéger les informations sensibles dans les applications basées sur l’IA. Elle aide les organisations à créer des systèmes qui s’alignent sur leurs stratégies d’accès, ce qui réduit le risque d’exposer des données non autorisées ou confidentielles. En intégrant des règles d’accès directement dans le pipeline de recherche, les systèmes IA peuvent fournir des réponses ancrées dans des informations sécurisées et autorisées.

En déchargeant l’application des autorisations à Azure AI Search, les développeurs peuvent se concentrer sur la création de systèmes de récupération et de classement de haute qualité. Cette approche permet de réduire la nécessité de gérer des groupes imbriqués, d’écrire des filtres personnalisés ou de réduire manuellement les résultats de la recherche.

Les autorisations au niveau du document dans Recherche IA Azure fournissent une infrastructure structurée permettant d’appliquer des contrôles d’accès qui s’alignent sur les stratégies organisationnelles. En utilisant des listes de contrôle d’accès et des rôles RBAC basés sur Microsoft Entra, les organisations peuvent créer des systèmes qui prennent en charge la conformité robuste et favorisent la confiance entre les utilisateurs. Ces fonctionnalités intégrées réduisent le besoin de codage personnalisé, offrant une approche standardisée de la sécurité au niveau du document.

Tutoriels et exemples

Examinez plus en détail le contrôle d’accès au niveau du document dans Recherche IA Azure avec d’autres articles et exemples.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-11-19