Utiliser un indexeur Recherche Azure AI pour ingérer les étiquettes de confidentialité Microsoft Purview et appliquer la sécurité au niveau des documents (préversion)

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 l’extraction des étiquettes de confidentialité Microsoft Purview et leur application au moment de l’interrogation (préversion). Pendant l’indexation, il extrait et stocke automatiquement les métadonnées d’étiquette de confidentialité pour chaque document. Au moment de la requête, il applique le contrôle d’accès basé sur l’étiquette en fonction des stratégies de protection des informations existantes dans Microsoft Purview, ce qui garantit que seuls les utilisateurs autorisés peuvent récupérer du contenu étiqueté dans les résultats de recherche.

Cette fonctionnalité est disponible pour les sources de données suivantes :

Architecture diagram showing a governed RAG solution where documents labeled with Microsoft Purview sensitivity labels are indexed into Recherche Azure AI, and a RAG orchestrator filters query results by label so junior users see only General content while executive users see General, Confidential, and Highly Confidential content.Architecture diagram showing a governed RAG solution where documents labeled with Microsoft Purview sensitivity labels are indexed into Recherche Azure AI, and a RAG orchestrator filters query results by label so junior users see only General content while executive users see General, Confidential, and Highly Confidential content.Diagramme d'architecture montrant une solution RAG régie où les documents étiquetés avec des étiquettes de confidentialité Microsoft Purview sont indexés dans Recherche Azure AI, et un orchestrateur RAG filtre les résultats de requête par étiquette afin que les utilisateurs juniors voient uniquement le contenu Général tandis que les utilisateurs exécutifs peuvent voir le contenu Général, Confidentiel et Hautement Confidentiel.

Conditions préalables

Configurez les stratégies d’étiquetage de confidentialité Microsoft Purview et appliquez-les aux documents avant l’indexation.
Disposez des rôles Administrateur général ou Administrateur de rôle privilégié dans votre locataire Microsoft Entra pour accorder au service de recherche l’accès aux API Purview et aux étiquettes de confidentialité.
Le service Recherche Azure AI et l’utilisateur qui émet la requête doivent se trouver dans le même locataire Microsoft Entra.
Utilisez des documents sources avec des types de fichiers pris en charge par les étiquettes de confidentialité Purview et pris en charge par les indexeurs Recherche Azure AI.
Utilisez l’API REST version 2026-08-01-preview ou un package de SDK en préversion équivalent.

Important

Le service de recherche doit utiliser son identité managée affectée par le système pour s’authentifier auprès de Microsoft Purview. Cette fonctionnalité ne prend pas en charge les identités managées affectées par l’utilisateur.

Limitations

Le portail Azure ne prend pas en charge cette fonctionnalité.
Les API Autocomplete etSuggest ne sont pas prises en charge pour les index activés Purview, car ils ne peuvent pas encore appliquer le contrôle d’accès basé sur les étiquettes.
Les comptes invités et les requêtes interlocataires ne sont pas pris en charge.
Les identités managées attribuées par l’utilisateur ne sont pas prises en charge pour les affectations de rôles Microsoft Purview. Seule l’identité managée affectée par le système du service peut se voir attribuer les rôles Content.SuperUser et UnifiedPolicy.Tenant.Read requis pour l’extraction des étiquettes. Attribuez ces rôles directement à l’identité du service : il effectue les opérations privilégiées EXTRACT (lecture de contenu chiffré et classifications de sécurité) pour le compte de l’indexeur. Consultez l’étape 1 et l’étape 3.
Les fonctionnalités d’indexeur suivantes ne prennent pas en charge les documents avec des étiquettes de confidentialité. Si vous utilisez l’une de ces fonctionnalités dans un ensemble de compétences ou un indexeur, les documents avec étiquettes de confidentialité ne sont pas traités.
- Compétence d’API web personnalisée
- Base de connaissances, y compris le magasin d’actifs requis pour le service d’images (version préliminaire) dans la récupération agentique. Par conséquent, le service d’images n’est pas pris en charge pour les sources de connaissances qui utilisent des étiquettes de confidentialité.
- Cache d’enrichissement de l’indexeur
- Sessions de débogage

Fonctionnement de l’application des stratégies

La prise en charge des étiquettes de confidentialité comprend deux phases : l’indexation et l’application au moment de la requête.

Indexation

Lorsque vous configurez l’indexation selon une planification, l’indexeur extrait de nouveaux documents et mises à jour à partir de la source de données. Pour chaque document, il capture :

Contenu du document
Étiquette de sensibilité associée
Modifications apportées au contenu ou aux étiquettes depuis la dernière exécution de l’indexeur

Note

L’index ne reflète pas les changements d’étiquette dans les documents sources avant la prochaine exécution réussie de l’indexeur.

Application des règles au moment des requêtes

Au moment de la requête, Recherche Azure AI évalue les étiquettes de confidentialité et applique le contrôle d'accès au niveau du document, en fonction du jeton Microsoft Entra ID de l'utilisateur et des stratégies d'étiquette Microsoft Purview. Seuls les utilisateurs autorisés à accéder au contenu avec le droit d’utilisation READ sous une étiquette donnée peuvent récupérer les documents correspondants dans les résultats de recherche.

Les administrateurs autorisés peuvent également émettre des demandes de lecture avec privilèges élevés, qui renvoient des documents étiquetés auxquels l’utilisateur appelant n’aurait normalement pas accès et émettent une entrée dans le journal d’audit Microsoft Purview pour chaque document renvoyé. La lecture avec privilèges élevés nécessite le rôle Contributeur aux données d’index de recherche sur le service de recherche et la version d’API 2026-05-01-preview ou ultérieure.

Exemple de bout en bout

Les images suivantes montrent comment les étiquettes de confidentialité passent de la création à l’expérience de recherche. Dans la première image, un utilisateur applique l’étiquette Confidential à un document dans Microsoft Word. Dans la deuxième image, un chatbot d’entreprise applique cette étiquette au moment de la requête, bloquant les actions de copie et de partage pour le contenu confidentiel.

1. Activer l'identité managée de la recherche AI

Activez une identité managée affectée par le système pour votre service Recherche Azure AI : les identités managées affectées par l'utilisateur ne sont pas prises en charge pour cette fonctionnalité. L’indexeur utilise cette identité pour s’authentifier avec Microsoft Purview et extraire les métadonnées d’étiquette de confidentialité. Il doit également recevoir les attributions de rôles à l’étape 3.

2. Activer RBAC sur votre service Recherche d’IA

Activez le contrôle d’accès en fonction du rôle (RBAC) sur votre service Recherche Azure AI. Cette étape est requise pour que les opérations liées au contenu, telles que l’indexation du contenu et l’interrogation de l’index réussissent. Conservez les clés RBAC et API pour éviter d’interrompre les opérations qui s’appuient sur des clés API.

3. Accorder l’accès pour extraire des étiquettes de confidentialité

L’accès aux métadonnées d’étiquettes de sensibilité de Microsoft Purview implique des opérations hautement privilégiées, notamment la lecture de contenu chiffré et des classifications de sécurité. Pour activer cette fonctionnalité dans Recherche Azure AI, vous devez accorder des rôles spécifiques à l'identité managée du service, en suivant les processus de gouvernance et d'approbation internes de votre organisation.

Identifier vos administrateurs de rôles globaux ou privilégiés

Si vous devez déterminer qui peut autoriser les autorisations pour le service de recherche, vous pouvez localiser les administrateurs généraux actifs ou éligibles dans votre locataire Microsoft Entra.

Dans le portail Azure, recherchez Microsoft Entra ID.
Dans le volet de navigation gauche, sélectionnez Gérer les > rôles et les administrateurs.
Recherchez le rôle Administrateur général ou Administrateur de rôle privilégié , puis sélectionnez-le.
Sous Affectations éligibles et affectations actives, passez en revue la liste des administrateurs autorisés à exécuter le processus de configuration des autorisations.

Obtenir l'approbation de la gouvernance

Engagez vos équipes de sécurité ou de conformité internes pour passer en revue la demande. Microsoft recommande de suivre le processus de gouvernance et de sécurité standard de votre entreprise avant de poursuivre les attributions de rôles.

Une fois approuvé, un administrateur général ou un administrateur de rôle privilégié doit attribuer les rôles suivants à l’identité managée affectée par le système Recherche Azure AI :

Content.SuperUser : pour l’extraction d’étiquettes et de contenu
UnifiedPolicy.Tenant.Read – pour l’accès aux stratégies Purview et aux métadonnées d’étiquettes

Attribuer des rôles via PowerShell

Note

Attribuez ces rôles uniquement à l’identité managée affectée par le système du service Recherche Azure AI, et non à une identité managée affectée par l’utilisateur, un principal de service ou un compte d’utilisateur individuel. Le script PowerShell récupère automatiquement l’ID d’objet d’identité managée à partir de la ressource de service.

Votre administrateur général ou administrateur de rôle privilégié doit utiliser le script PowerShell suivant pour accorder les autorisations requises. Remplacez les valeurs d'espace réservé par vos noms réels d'abonnement, de groupe de ressources et de service de recherche.

Install-Module -Name Az -Scope CurrentUser
Install-Module -Name Microsoft.Entra -AllowClobber
Import-Module Az.Resources
Connect-Entra -Scopes 'Application.ReadWrite.All'

$resourceIdWithManagedIdentity = "subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.Search/searchServices/<searchServiceName>"
$managedIdentityObjectId = (Get-AzResource -ResourceId $resourceIdWithManagedIdentity).Identity.PrincipalId

# Microsoft Information Protection (MIP)
$MIPResourceSP = Get-EntraServicePrincipal -Filter "appID eq '870c4f2e-85b6-4d43-bdda-6ed9a579b725'"
New-EntraServicePrincipalAppRoleAssignment -ServicePrincipalId $managedIdentityObjectId -Principal $managedIdentityObjectId -ResourceId $MIPResourceSP.Id -Id "8b2071cd-015a-4025-8052-1c0dba2d3f64"

# Microsoft Rights Management Services (MRMS) - Service Principal for policy read
$MRMSResourceSP = Get-EntraServicePrincipal -Filter "appID eq '00000012-0000-0000-c000-000000000000'"
New-EntraServicePrincipalAppRoleAssignment -ServicePrincipalId $managedIdentityObjectId -Principal $managedIdentityObjectId -ResourceId $MRMSResourceSP.Id -Id "7347eb49-7a1a-43c5-8eac-a5cd1d1c7cf0"

Les rôles appID dans le script PowerShell fourni sont associés aux rôles Azure suivants :

AppID	Principal de service
`870c4f2e-85b6-4d43-bdda-6ed9a579b725`	Microsoft Service de synchronisation Info Protection
`00000012-0000-0000-c000-000000000000`	Services de gestion des droits Microsoft

4. Configurer l’index pour activer l’étiquette de sensibilité Purview

Lorsque la prise en charge des étiquettes de confidentialité est requise, définissez la propriété purviewEnabled sur true dans votre définition d’index.

Important

La propriété purviewEnabled doit être définie sur true lors de la création de l’index. Ce paramètre est permanent et ne peut pas être modifié ultérieurement.

Lorsque purviewEnabled est défini sur true, seule l’authentification RBAC est prise en charge pour l’ensemble des API d’opérations sur les documents.

L'accès par clé API est limité à la récupération du schéma d'index (liste et obtention).

PUT https://{service}.search.windows.net/indexes('{indexName}')?api-version=2026-08-01-preview
{
  "purviewEnabled": true,
  "fields": [
    {
      "name": "sensitivityLabel",
      "type": "Edm.String",
      "filterable": true,
      "sensitivityLabel": true,
      "retrievable": true
    }
  ]
}

5. Configurer la source de données

Pour activer l’ingestion d’étiquette de confidentialité, configurez la source de données avec la propriété indexerPermissionOptions définie sur ["sensitivityLabel"].

{
  "name": "purview-sensitivity-datasource",
  "type": "azureblob", // < adjust type value according to the data source you are enabling this for: sharepoint, onelake, adlsgen2.
  "indexerPermissionOptions": [ "sensitivityLabel" ],
  "credentials": {
    "connectionString": <your-connection-string>;"
  },
  "container": {
    "name": "<container-name>"
  }
}

La indexerPermissionOptions propriété indique à l’indexeur d’extraire les métadonnées d’étiquette de sensibilité pendant le processus d'ingestion afin de les attacher au document indexé.

6. Configurer les projections d’index dans votre ensemble de compétences (le cas échéant)

Si votre indexeur a un ensemble de compétences et que vous implémentez une segmentation des données par le biais de la compétence Fractionnement de texte, par exemple avec la vectorisation intégrée, projetez l’étiquette de confidentialité sur chaque bloc via des projections d’index dans l’ensemble de compétences.

Pour obtenir une règle plus large sur le moment où les champs d’autorisation et de liste de contrôle d’accès appartiennent à des mappages de champs d’index et à des projections d’index, consultez Choisir où remplir les champs de liste de contrôle d’accès.

Cette étape est requise à la fois pour l’application au moment de la requête et pour que les réponses en récupération agentique incluent le champ sensitivityLabelInfo par document pour chaque fragment. Sans le mappage de projection, les lignes des fragments enfants ne seront pas correctement filtrées.

PUT https://{service}.search.windows.net/skillsets/{skillset}?api-version=2026-08-01-preview
{
  "name": "my-skillset",
  "skills": [
    {
      "@odata.type": "#Microsoft.Skills.Text.SplitSkill",
      "name": "#split",
      "context": "/document",
      "inputs": [{ "name": "text", "source": "/document/content" }],
      "outputs": [{ "name": "textItems", "targetName": "chunks" }]
    }
    // ... (other skills such as embeddings, entity recognition, etc.)
  ],
  "indexProjections": {
    "selectors": [
      {
        "targetIndexName": "chunks-index",
        "parentKeyFieldName": "parentId",          // must exist in target index
        "sourceContext": "/document/chunks/*",     // match your split output path
        "mappings": [
          { "name": "chunkId",           "source": "/document/chunks/*/id" },     // if you create an id per chunk
          { "name": "content",           "source": "/document/chunks/*/text" },   // chunk text
          { "name": "parentId",          "source": "/document/id" },              // parent doc id
          { "name": "sensitivityLabel",  "source": "/document/metadata_sensitivity_label" } // <-- parent → child
        ]
      }
    ],
    "parameters": {
      "projectionMode": "skipIndexingParentDocuments"
    }
  }
}

7. Configurer l’indexeur

Définissez des mappages de champs dans votre définition d’indexeur pour router les métadonnées d’étiquette extraites vers les champs d’index. Si votre source de données émet des métadonnées d’étiquette sous un autre nom de champ (par exemple, metadata_sensitivity_label), mappez-la explicitement.

{
  "fieldMappings": [
    {
      "sourceFieldName": "metadata_sensitivity_label",
      "targetFieldName": "sensitivityLabel"
    }
  ]
}

L’indexeur indexe automatiquement les mises à jour de l’étiquette de confidentialité lorsqu’il détecte les modifications apportées à l’étiquette, au contenu ou aux métadonnées d’un document lors de l’exécution d’un indexeur planifié. Configurez l’indexeur selon une planification périodique. L’intervalle minimal pris en charge est toutes les 5 minutes.

Étapes suivantes

Comment interroger un index compatible avec les étiquettes de confidentialité
Accès en lecture en mode privilégié pour les enquêtes administratives
sécurité au niveau du document dans Recherche Azure AI

Commentaires

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

Last updated on 2026-09-17

Utiliser un indexeur Recherche Azure AI pour ingérer les étiquettes de confidentialité Microsoft Purview et appliquer la sécurité au niveau des documents (préversion)

Conditions préalables

Limitations

Fonctionnement de l’application des stratégies

Indexation

Application des règles au moment des requêtes

Exemple de bout en bout

1. Activer l'identité managée de la recherche AI

2. Activer RBAC sur votre service Recherche d’IA

3. Accorder l’accès pour extraire des étiquettes de confidentialité

Identifier vos administrateurs de rôles globaux ou privilégiés

Obtenir l'approbation de la gouvernance

Attribuer des rôles via PowerShell

4. Configurer l’index pour activer l’étiquette de sensibilité Purview

5. Configurer la source de données

6. Configurer les projections d’index dans votre ensemble de compétences (le cas échéant)

7. Configurer l’indexeur

Étapes suivantes

Commentaires

Ressources supplémentaires