Pomocí indexeru Azure AI Vyhledávač načítejte štítky citlivosti Microsoft Purview a vynucujte zabezpečení na úrovni dokumentů (Preview)

Přidání podpory popisků citlivosti Microsoft Purview (Preview) do existujícího kanálu indexeru Azure AI Vyhledávač Nakonfigurujte extrakci štítků, anotujte pole cílových metadat a namapujte tyto hodnoty na každý indexovaný dokument nebo chunk. Azure AI Vyhledávač používá indexované popisky k vynucení přístupu na úrovni dokumentu v době dotazu podle vašich zásad Microsoft Purview.

Tato funkce je dostupná pro následující zdroje dat:

• Azure Blob Storage
• Azure Data Lake Storage Gen2
• SharePoint v Microsoft 365 (náhled)
• Microsoft OneLake

Třípolové příklady v tomto článku používají metadata potvrzená pro soubory jednotky (knihovny dokumentů) SharePointu v Microsoftu 365. Příjem popisků citlivosti nepodporuje položky seznamu SharePoint ani stránky webu.

Požadavky

• Existující zdroj dat a indexer nakonfigurované pomocí pokynů konektoru propojených v předchozí části. Pokud vaše kanálová pipeline indexuje bloky dat, nakonfigurujte sadu dovedností a projekce indexu před přidáním mapování popisků.

• Cílový index vytvořený pomocí purviewEnabled: truenebo plánu pro vytvoření nového indexu s podporou Purview a změna cílení existujícího kanálu, jak je popsáno v kroku 4.

• Nakonfigurujte zásady Microsoft Purview pro popisky citlivosti a před indexováním je použijte u dokumentů.

• V tenantovi Microsoft Entra požádejte globálního správce nebo správce privilegovaných rolí, aby vyhledávací službě udělil přístup k rozhraním API Purview a popiskům citlivosti.

• Služba Azure AI Vyhledávač i uživatel, který dotaz vydává, musí být ve stejném tenantovi Microsoft Entra.

• Používejte zdrojové dokumenty s typy souborů, které jsou podporovány popisky citlivosti Purview a podporované indexery Azure AI Vyhledávač.

• Použijte rozhraní REST API verze 2026-08-01-preview nebo ekvivalentní balíček sady SDK verze Preview.

• Vyhledávací služba musí použít spravovanou identitu přiřazenou systémem k ověření pomocí Microsoft Purview. Tato funkce nepodporuje spravované identity přiřazené uživatelem.

Omezení

• Tuto funkci nepodporuje portál Azure.

• API pro automatické dokončování a návrh nejsou podporována pro indexy s funkcí Purview, protože zatím nemohou vynucovat řízení přístupu založené na popiscích.

• Účty hostů a dotazy mezi tenanty se nepodporují.

• Následující funkce indexeru nepodporují dokumenty s popisky citlivosti. Pokud některou z těchto funkcí použijete v sadě dovedností nebo indexeru, nezpracují se dokumenty s popisky citlivosti.

  • Vlastní funkce webového API

  • Úložiště znalostí, včetně úložiště prostředků vyžadovaného pro poskytování obrázků (preview) v agentním vyhledávání. Proto se zobrazování obrázků nepodporuje u zdrojů znalostí, které přebírají popisky citlivosti.

  • Mezipaměť rozšiřování indexeru

  • Ladicí relace

Jak funguje vynucení zásad

Podpora popisků citlivosti má dvě fáze: indexování a vynucování času dotazu.

Indexování

Indexer extrahuje obsah dokumentu a metadata popisků citlivosti. Při následných spuštěních aktualizuje indexované hodnoty, když detekuje změny popisku, obsahu nebo metadat dokumentu.

Index neodráží změny štítků ve zdrojových dokumentech až do dalšího úspěšného spuštění indexátoru.

Vynucení času dotazu

V době dotazu Azure AI Vyhledávač nejprve vyhodnocuje citlivost popisků a vynucuje řízení přístupu na úrovni dokumentu na základě tokenu Microsoft Entra ID uživatele a zásad popisků Microsoft Purview. Jen uživatelé oprávnění k přístupu k obsahu s právem ke čtení pod daným štítkem mohou získat odpovídající dokumenty ve výsledcích hledání.

Požadavky na ověřování a autorizaci dotazů najdete v tématu Dotazování indexu s povolenými popisky citlivosti. Informace o administrativním šetření a chování auditování najdete v tématu Čtení se zvýšenými oprávněními.

1. Povolit spravovanou identitu AI Search

Povolte spravovanou identitu přiřazenou systémem pro vaši službu Azure AI Vyhledávač. Indexer používá vlastní identitu služby k ověření pomocí Microsoft Purview a provádění privilegovaných EXTRACT operací, včetně čtení šifrovaného obsahu a klasifikací zabezpečení. Přiřaďte požadované role přímo této identitě v kroku 3.

2. Povolte RBAC ve službě AI Search

Povolte řízení přístupu na základě role (RBAC) ve službě Azure AI Vyhledávač. Indexy s podporou Purview vyžadují ověřování RBAC pro operace s dokumenty, včetně indexování obsahu a dotazování. Pokud jiné operace služby spoléhají na klíče rozhraní API, ponechejte povolené RBAC i klíče rozhraní API. Tato konfigurace nepovoluje operace s dokumenty pomocí klíče rozhraní API u indexů s podporou Purview.

3. Udělení přístupu k extrahování štítků citlivosti

Přístup k metadatům popisků citlivosti Microsoft Purview zahrnuje vysoce privilegované operace. Zapojte týmy zabezpečení nebo dodržování předpisů a před přiřazením oprávnění získejte schválení v rámci schvalovacího procesu vaší organizace.

Po schválení zapojte Global Administrator nebo Privileged Role Administrator, aby tyto role přiřadili spravované identitě přiřazené systémem Azure AI Vyhledávač:

• Content.SuperUser pro extrakci popisků a obsahu.
• UnifiedPolicy.Tenant.Read pro přístup k zásadám Purview a metadatům popisků

Přiřazení rolí pomocí PowerShellu

Tyto role přiřaďte pouze spravované identitě přiřazené systémem služby Azure AI Vyhledávač, nikoli spravované identitě přiřazené uživatelem, samostatnému instančnímu objektu aplikace nebo individuálnímu uživatelskému účtu. Skript PowerShellu načte ID objektu spravované identity automaticky z prostředku služby.

Globální správce nebo správce privilegovaných rolí by měli k udělení požadovaných oprávnění použít následující skript PowerShellu. Získejte souhlas správce s delegovanými oprávněními Microsoft Graph AppRoleAssignment.ReadWrite.All a Application.Read.All prostřednictvím schváleného procesu správy. Samotná role správce tenanta neposkytuje tyto rozsahy tokenů.

Po instalaci modulů zobrazených v následující části před spuštěním zbývajících příkazů vytvořte samostatný ověřený kontext Azure PowerShell ve stejné relaci PowerShellu. Pomocí Connect-AzAccount se přihlaste k tenantovi vyhledávací služby a pomocí Set-AzContext vyberte správného tenanta a předplatné. Účet Azure musí mít oprávnění ke čtení prostředku vyhledávací služby, například role Čtenář. Connect-Entra nenastavuje tento kontext Az.

Zástupné symboly nahraďte skutečným ID tenanta, ID předplatného, skupinou prostředků a názvem vyhledávací služby.

Install-Module -Name Az -Scope CurrentUser
Install-Module -Name Microsoft.Entra -AllowClobber
Import-Module Az.Resources
Connect-Entra -TenantId "<tenantId>" `
    -Scopes 'AppRoleAssignment.ReadWrite.All', 'Application.Read.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 `
    -PrincipalId $managedIdentityObjectId `
    -ResourceId $MIPResourceSP.Id `
    -Id "8b2071cd-015a-4025-8052-1c0dba2d3f64"

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

Referenční informace: Connect-Entra, Get-AzResource, Get-EntraServicePrincipal, New-EntraServicePrincipalAppRoleAssignment a Microsoft Graph oprávnění k přiřazení role aplikace.

Skript přiřadí role aplikace na následujících instančních objektech služeb prostředků spravované identitě vyhledávací služby:

4. Nakonfigurujte index tak, aby povolil popisek citlivosti Purview.

Pro změny konfigurace v následujících krocích použijte verzi 2026-08-01-preview rozhraní REST API.

U indexu s podporou Purview se u všech rozhraní API pro operace s dokumenty podporuje pouze ověřování RBAC. Přístup pomocí klíče API je omezený na načtení schématu indexu (seznam a získání).

Ve všech podporovaných zdrojích dat popisků citlivosti obsahuje metadata_sensitivity_label jedno ID popisku jako řetězec GUID. Definujte cílové pole indexu jako Edm.String, nikoli jako kolekci. Hodnota může být chybějící nebo null, pokud je dokument neoznačen nebo extrakce popisků úmyslně vynechána.

Přidejte tato tři řetězcová pole do cílového indexu. Pokud jsou bloky dat prohledávatelnými dokumenty, přidejte pole do indexu bloků dat.

Pole source_document_id identifikuje zdrojový dokument pro auditování. Nejedná se o klíč indexu vyhledávání ani nadřazený klíč projekce.

Vlastnost vytvoření indexu: Tuto vlastnost zahrňte do definice úplného vytvoření nového indexu. Pokud ho už existující index obsahuje, ponechte ho beze změny.

{
  "purviewEnabled": true
}

Přidání polí indexu: Připojte tyto objekty do pole fields úplné definice indexu se zachováním existujícího schématu a rozložení indexování.

[
  {
    "name": "sensitivity_label_id",
    "type": "Edm.String",
    "filterable": true,
    "retrievable": true,
    "sensitivityLabelId": true
  },
  {
    "name": "sensitivity_label_name",
    "type": "Edm.String",
    "retrievable": true,
    "sensitivityLabelName": true
  },
  {
    "name": "source_document_id",
    "type": "Edm.String",
    "retrievable": true,
    "sourceDocumentId": true
  }
]

Reference: Definice indexu.

U mapování na úrovni dokumentu postupujte podle kroku 7. V případě podřízených bloků dat postupujte podle kroku 6.

5. Konfigurace zdroje dat

Změna volby zdroje dat: Přidejte sensitivityLabel do indexerPermissionOptions ve vašem nakonfigurovaném zdroji dat. Pokud jsou již povoleny další možnosti oprávnění, zachovejte je a připojte tuto možnost místo přepsání celého pole.

{
  "indexerPermissionOptions": ["sensitivityLabel"]
}

Reference: Definice zdroje dat.

Tato možnost povolí extrakci popisků. Liší se od anotací polí indexu sensitivityLabelId, sensitivityLabelName a sourceDocumentId. Ponechte stávající přihlašovací údaje konektoru, výběr kontejneru a další nastavení.

6. Konfigurace projekcí indexu v sadě dovedností (pokud je k dispozici)

Pokud váš kanál indexuje bloky dat, rozšiřte jeho stávající selektor projekcí indexu. Použijte přidání polí a požadavek indexu s podporou Purview z kroku 4 na index chunků.

Doplnění mapování projekce: Připojte tyto položky do pole příslušného voliče mappings uvnitř indexProjections.selectors. Tato rozšíření nejsou úplným selektorem ani souborem dovedností.

[
  {
    "name": "sensitivity_label_id",
    "source": "/document/metadata_sensitivity_label"
  },
  {
    "name": "sensitivity_label_name",
    "source": "/document/metadata_sensitivity_label_name"
  },
  {
    "name": "source_document_id",
    "source": "/document/metadata_source_document_id"
  }
]

Reference: Definice sady dovedností.

Zachovejte selektor targetIndexName, parentKeyFieldName a blok sourceContext, s výjimkou přesměrování na nový index v případě potřeby. Zachovejte další selektory, mapování obsahu a vektorů a existující režim projekce. Explicitně mapovat každé neklíčové podřízené pole; výše uvedená tři doplnění nejsou kompletní sadou mapování.

Tyto cesty na kořenové úrovni zkopírují mapované řetězcové hodnoty dostupné u nadřazeného objektu do každého bloku dat. Projekce generují podřízený klíč a nadřazenou asociaci pro sledování změn. Nevytvářejte ručně mapování vygenerovaných klíčů, jako jsou chunk_id nebo parent_id, v projekcích nebo v fieldMappings indexeru chunků.

Pokud vaše dovednost Rozdělení textu generuje nezpracované řetězce v části chunks, použijte /document/chunks/* pro sourceContext selektoru a mapování obsahu, nikoli podřízenou cestu /id nebo /text.

Přímé skipIndexingParentDocumentsindexery fieldMappings nenaplní vnořené dokumenty. Projekce identifikátoru štítku je vyžadována pro vynucování dotazů na úrovni chunků a související metadata odpovědi štítku. Informace o zpracování odpovědí najdete v tématu Kontrola metadat popisku citlivosti v odpovědi.

V případě rozložení nadřazeného podřízeného objektu se dvěma indexy použijte přímé mapování v kroku 7 k naplnění nadřazeného indexu a tyto projekce použijte k naplnění podřízeného indexu. Sémantika mapování najdete v tématu Zkontrolovat mapování polí.

7. Nakonfigurujte indexer

Pro jeden vyhledávací dokument pro každý zdrojový dokument přidejte přímé mapování metadat do existujícího indexeru. Používejte nezpracované názvy zdrojových polí bez předpony /document/ .

Přidání mapování přímých polí: Tyto položky připojte k poli fieldMappings indexeru. Zachová mapování klíče konektoru, další mapování, zdroj dat a zapojení sady dovedností, cílový index a konfiguraci, kromě případného přesměrování na nový index v případě potřeby.

[
  {
    "sourceFieldName": "metadata_sensitivity_label",
    "targetFieldName": "sensitivity_label_id"
  },
  {
    "sourceFieldName": "metadata_sensitivity_label_name",
    "targetFieldName": "sensitivity_label_name"
  },
  {
    "sourceFieldName": "metadata_source_document_id",
    "targetFieldName": "source_document_id"
  }
]

Reference: Definice indexeru.

U chunků ponechte stávající indexer připojený ke své dovednostní sadě; mapování selektoru v kroku 6 naplní metadata podřízených položek.

Ověřit ingestaci popisků

Po sloučení změn do úplných definic prostředků proveďte počáteční doplnění dat, pokud už existující indexer zpracoval zdrojové soubory. Povolení extrakce, přidání polí metadat nebo změna cílení pipeline nezpůsobí, že nezměněné soubory budou způsobilé pro běžné přírůstkové spuštění. Chcete-li tyto soubory znovu zpracovat, resetujte indexer a poté ho spusťte. Reset vymaže sledování změn a následné spuštění znovu zpracuje všechny zdrojové dokumenty; počítejte s touto pracovní zátěží.

Pokud soubory ještě nejsou indexovány, spusťte indexer bez resetování. Pomocí funkce Získat stav indexeru potvrďte úspěšné dokončení spuštění a zkontrolujte chyby a upozornění dokumentu. Přijatý požadavek na spuštění není důkazem o dokončení ingesce.

Pomocí autorizované identity dotazu a průvodce dotazem ověřte známý označený dokument a jeho bloky dat:

• Označený soubor z libovolného podporovaného zdroje naplní sensitivity_label_id řetězcem GUID. U souboru knihovny dokumentů (jednotky) označeného popiskem SharePointu ověřte také název popisku a ID auditu zdrojového dokumentu v doprovodných polích. U jiných zdrojů ověřte doprovodné hodnoty, kde jsou metadata daného zdroje k dispozici.
• Neoznačený dokument nebo dokument s úmyslně přeskočeným extrahováním popisků má chybějící nebo null ID popisku.
• Každý podřízený blok dat dědí hodnoty mapovaných metadat, které jsou k dispozici v nadřazeném objektu, a vygenerované podřízené a nadřazené klíče zůstanou nedotčené.

Pokud chybí očekávaná metadata, zkontrolujte chyby a upozornění při spuštění, možnost extrakce zdroje dat v kroku 5 a přímá nebo projekční mapování v krocích 6 a 7. Ověřte, že backfill zpracoval známý soubor.

Pro pozdější přírůstkovou aktualizaci spusťte nebo naplánujte indexer, aby zpracovával zjištěné zdrojové změny; nenulujte ho pro každou aktualizaci štítku. Změny popisku zdroje se v indexu nezobrazí, dokud je nezpracuje úspěšné spuštění indexeru. Opakovanou aktualizaci najdete v tématu Naplánování indexeru.

Související obsah

• Jak dotazovat index s povolenými štítky citlivosti
• Rozšířený přístup pro čtení pro správní šetření
• Zabezpečení na úrovni dokumentu v Azure AI Vyhledávač