Řízení přístupu na úrovni dokumentu v Azure AI Vyhledávač

Note

Azure AI Vyhledávač je k dispozici prostřednictvím portálu Azure, rozhraní REST API a Sady Azure SDK. Podporuje také Foundry IQ, spravovanou znalostní vrstvu, která transformuje podnikový obsah na opakovaně použitelné znalostní báze s podporou oprávnění pro agenty na portálu Microsoft Foundry.

Important

Na funkce, možnosti nebo vlastnosti označené jako (Preview) se nevztahuje smlouva o úrovni služeb, nejsou doporučené pro produkční úlohy a mohou se změnit nebo být omezeny dříve, než budou obecně k dispozici. Podmínky Azure AI Vyhledávač Preview platí pro všechny funkce ve verzi Preview, ať už jsou samostatné nebo součástí obecně dostupné funkce.

Azure AI Vyhledávač podporuje řízení přístupu na úrovni dokumentu a umožňuje organizacím vynucovat jemně odstupňovaná oprávnění na úrovni dokumentu od příjmu dat prostřednictvím provádění dotazů. Tato funkce je nezbytná pro vytváření zabezpečených agentních systémů AI založených na datech, aplikací rozšířené generace na základě vyhledávání (RAG) a podnikovými vyhledávacími řešeními, která vyžadují autorizaci na úrovni dokumentu.

Přístupy pro řízení přístupu na úrovni dokumentu

Azure AI Vyhledávač poskytuje čtyři primární přístupy k vynucení oprávnění na úrovni dokumentu, které jsou vhodné pro různé zdroje dat a modely identit.

Přístup Popis
Filtry zabezpečení Porovnání řetězců Vaše aplikace předává identitu uživatele nebo skupiny jako řetězec, který použije filtr v dotazu k vyloučení jakýchkoli dokumentů, jež se neshodují s řetězcem.

Filtry zabezpečení jsou technika pro dosažení řízení přístupu na úrovni dokumentu. Tento přístup není vázán na rozhraní API, takže můžete použít jakoukoli verzi nebo balíček.
Rozsahy ACL typu POSIX / RBAC (Preview) Objekt zabezpečení Microsoft Entra použitý pro token dotazu se porovnává s metadaty oprávnění dokumentů vrácených ve výsledcích hledání a vylučují se všechny dokumenty, jejichž oprávnění se neshodují. Oprávnění seznamu řízení přístupu (ACL) platí pro adresáře a soubory Azure Data Lake Storage (ADLS) Gen2. Rozsahy řízení přístupu na základě role (RBAC) se vztahují na obsah ADLS Gen2 a na Azure bloby.

Integrovaná podpora přístupu na základě identity na úrovni dokumentu je ve verzi Preview, dostupná v rozhraních REST API a v preview verzi balíčků Azure SDK, které tuto funkci poskytují. Informace o podpoře funkcí najdete v podrobnostech o podpoře verzí sady SDK.
Microsoft Purview popisky citlivosti (Preview) Indexer extrahuje popisky citlivosti definované v Microsoft Purview z podporovaných zdrojů dat (Azure Blob Storage, ADLS Gen2, SharePoint v Microsoft 365, OneLake). Tyto popisky se ukládají jako metadata a vyhodnocují se při dotazu, aby byl řízen přístup uživatelů na základě tokenů Microsoft Entra a přiřazení zásad Purview. Štítky se také zpřístupňují prostřednictvím zdrojů znalostí a odpovědi agentického vyhledávání, což agentům AI a chatovacím aplikacím využívajícím znalostní bázi umožňuje využívat stejné filtrování se zohledněním štítků. Tento přístup slaďuje autorizaci vyhledávání Azure AI s modelem Microsoft Information Protection vaší organizace.
SharePoint v Microsoft 365 ACL (náhled) Azure AI Vyhledávač indexery extrahují metadata oprávnění z podporovaného SharePoint obsahu a používají je k kontrolám přístupu v době dotazu. Informace o podporovaném obsahu, objektech zabezpečení, vztazích mezi skupinami, chování synchronizace a oprávněních najdete v tématu Použití indexeru SharePointu k načítání metadat oprávnění.

U indexovaných zdrojů ingestionPermissionOptions znalostí nelze kombinovat s assetStore. Proto není poskytování obrázků (náhled) k dispozici, pokud je povoleno nativní načítání oprávnění na úrovni dokumentu.

Volba přístupu

Pomocí následujících kritérií identifikujte přístup, který nejlépe vyhovuje vašemu zdroji dat, modelu identit a požadavkům na dodržování předpisů.

Scenario Doporučený přístup Proč
Vlastní systém identit, bezpečnostní rámec jiný než od Microsoftu nebo jakýkoli index používající model push. Filtry zabezpečení Nezávislá na rozhraní API, obecně dostupná a založená na jednoduché shodě řetězců.
Obsah v ADLS Gen2 nebo Azure Blob Storage s existujícími přiřazeními ACL nebo RBAC. Rozsahy ACL typu POSIX / RBAC Nativní integrace s Microsoft Entra; vynucování při dotazu používá metadata o oprávněních zapsaná do indexu pomocí zdokumentovaného synchronizačního mechanismu.
Podnikový obsah se už řídí zásadami ochrany informací Microsoft Purview. popisky citlivosti Microsoft Purview Používá centralizované klasifikace a přiřazení zásad napříč Azure AI Vyhledávač.
Obsah zdrojový z SharePoint v Microsoft 365 (knihovny, seznamy, stránky webu ASPX). SharePoint v seznamech ACL Microsoft 365 Respektuje nativní oprávnění SharePoint, včetně skupin webů SharePoint.

Model pro bezpečnostní omezení pomocí filtrů

V situacích, kdy není možná integrace nativních rozsahů ACL/RBAC, použijte filtry bezpečnostních řetězců k omezení výsledků na základě kritérií vyloučení. Vzor zahrnuje následující komponenty:

  • Pokud chcete ukládat identity uživatelů nebo skupin, vytvořte v indexu pole řetězce.
  • Načtěte index pomocí zdrojových dokumentů, které obsahují přidružené seznamy ACL.
  • Do logiky dotazu zahrňte výraz filtru pro porovnávání s řetězcem.
  • V době dotazu získejte identitu volajícího.
  • Předejte identifikaci volajícího jako filtrovací řetězec.
  • Výsledky se upraví tak, aby byly vyloučeny všechny shody, které nezahrnují identifikační řetězec uživatele nebo skupiny.

Můžete použít API pro model push nebo model pull. Vzhledem k tomu, že tento přístup je nezávislý na rozhraní API, stačí ověřit, že index a dotaz mají platné řetězce (identity) pro krok filtrace.

Tento přístup je užitečný pro systémy s vlastními modely přístupu nebo architekturami zabezpečení, které nejsou Microsoft. Další informace o tomto přístupu najdete v tématu Filtry zabezpečení pro oříznutí výsledků v Azure AI Vyhledávač.

Model nativní podpory pro oprávnění ACL typu POSIX a rozsah RBAC (Preview)

Nativní podpora je založena na uživatelích a skupinách Microsoft Entra přidružených k dokumentům, které chcete indexovat a dotazovat.

kontejnery Azure Data Lake Storage (ADLS) Gen2 podporují seznamy ACL pro kontejner a soubory. Pro ADLS Gen2 je nativně podporováno zachování rozsahu RBAC na úrovni dokumentu při použití indexeru ADLS Gen2 nebo zdroje znalostí Blob (podporuje ADLS Gen2) a API Preview pro příjem obsahu. Pro objekty blob Azure pomocí indexeru objektů blob Azure nebo zdroje znalostí je zachování rozsahu RBAC na úrovni kontejneru.

Pro obsah zabezpečený seznamem ACL použijte přístup ke skupině přes individuální uživatelský přístup, aby se usnadnila správa. Vzor zahrnuje následující komponenty:

Klientská aplikace má oprávnění ke čtení indexu prostřednictvím role Čtenář dat indexu vyhledávání nebo role Přispěvatel dat indexu vyhledávání. Přístup v době dotazu určuje metadata oprávnění uživatele nebo skupiny v indexovaném obsahu. Dotazy, které obsahují filtr oprávnění, předávají token uživatele nebo skupiny jako x-ms-query-source-authorization v hlavičce požadavku. Když použijete filtry oprávnění v době dotazu, Azure AI Vyhledávač zkontroluje dvě věci:

  • Nejprve zkontroluje oprávnění Čtenář dat indexu vyhledávání , které klientské aplikaci umožňuje přístup k indexu.

  • Za druhé, vzhledem k dodatečnému tokenu na požadavku zkontroluje oprávnění uživatele nebo skupiny u dokumentů vrácených ve výsledcích hledání, s výjimkou všech, které se neshodují.

Pokud chcete zahrnout metadata oprávnění do indexu, použijte rozhraní API modelu push a odešlete do vyhledávacího indexu libovolné dokumenty JSON, přičemž datová část požadavku obsahuje řetězcové pole poskytující pro každý dokument seznamy ACL podobné systému POSIX. Důležitým rozdílem mezi tímto přístupem a oříznutím zabezpečení je to, že metadata filtru oprávnění v indexu a dotazu jsou rozpoznána jako ověřování Microsoft Entra ID, zatímco alternativní řešení oříznutí zabezpečení spočívá v prostém porovnání textových řetězců. Identity můžete načíst také pomocí sady Graph SDK.

Pokud je zdroj dat Azure Data Lake Storage (ADLS) Gen2 a váš kód volá rozhraní API v režimu náhledu pro indexování, můžete také použít rozhraní API modelu "pull" (indexer).

Získání metadat oprávnění ACL v procesu ingestování dat (verze preview)

Způsob načtení oprávnění ACL se liší v závislosti na tom, jestli posíláte obsah dokumentů nebo používáte indexer ADLS Gen2.

Začněte s rozhraním API ve verzi Preview, které tuto funkci poskytuje:

Přístup k push modelu:

  1. Ověřte, že je schéma indexu vytvořené pomocí sady SDK verze Preview nebo předběžné verze a že schéma obsahuje filtry oprávnění.
  2. Zvažte použití sady Microsoft Graph SDK k získání identit skupin nebo uživatelů.
  3. Pomocí rozhraní API Index Documents nebo ekvivalentního rozhraní API Azure SDK nasdílejte dokumenty a související metadata oprávnění do indexu vyhledávání.

Pro pro přístup k indexeru ADLS Gen2 modelu pull nebo ke zdroji znalostí blob (ADLS Gen2):

  1. Ověřte, že jsou soubory v adresáři zabezpečené pomocí modelu řízení přístupu ADLS Gen2.
  2. Použijte Indexers – Create (REST API), Knowledge Sources – Create (REST API) nebo ekvivalentní rozhraní API Azure SDK k vytvoření indexeru, indexu a zdroje dat.

Pokud vaše sada dovedností rozděluje dokumenty na části, například pomocí dovednosti Rozdělení textu pro integrovanou vektorizaci, pole metadat oprávnění se přesunou z mapování polí indexeru do projekcí indexu. Viz Výběr umístění pro vyplnění polí ACL.

Model pro SharePoint v Microsoft 365 základní příjem oprávnění seznamu ACL (Preview)

U indexovaného obsahu SharePoint může Azure AI Vyhledávač ukládat zdrojová oprávnění jako metadata a používat je k filtrování výsledků dotazu. K této funkci ve verzi Preview máte přístup prostřednictvím indexeru SharePointu v Microsoftu 365 a nejnovějšího rozhraní REST API nebo ekvivalentního balíčku Preview SDK.

Informace o požadavcích na oprávnění, podporovaných relacích skupin, synchronizaci oprávnění a omezeních najdete v tématu Použití indexeru SharePoint k ingestování metadat oprávnění.

Pokud vaše sada dovedností rozděluje dokumenty na části (například pomocí dovednosti Rozdělení textu pro integrovanou vektorizaci), pole ACL se přesouvají z mapování polí indexeru do projekcí indexu. Viz Výběr umístění pro vyplnění polí ACL.

Vzor pro popisky citlivosti Microsoft Purview (Preview)

Když povolíte příjem štítků, Azure AI Vyhledávač extrahuje metadata citlivosti z podporovaných zdrojů dat. Mezi tyto zdroje dat patří Azure Blob Storage, Azure Data Lake Storage Gen2 (ADLS Gen2), SharePoint v Microsoft 365 a Microsoft OneLake. Extrahované popisky se ukládají v indexu spolu s obsahem dokumentu.

Při dotazu Azure AI Vyhledávač zkontroluje označení citlivosti každého dokumentu, uživatelův token Microsoft Entra a zásady purview organizace, které určují přístup. Systém vrátí dokumenty pouze v případě, že identita uživatele a oprávnění založená na popiscích povolují přístup v rámci nakonfigurovaných zásad Purview.

Tento model zahrnuje následující komponenty:

  • Nakonfigurujte index, zdroj dat a indexer (pro účely plánování) pomocí nejnovějšího rozhraní REST API verze Preview nebo sady SDK verze Preview, která podporuje příjem popisků Purview.
  • Povolte spravovanou identitu přiřazenou systémem ve vyhledávací službě. Uživatelem přiřazené spravované identity nejsou pro extrakci popisných štítků Purview podporovány – zvýšená oprávnění Purview musí mít vlastní identita této služby. Pak požádejte globálního správce tenanta nebo správce privilegovaných rolí, aby udělil požadovaný přístup, který vyhledávací službě umožní ověřit se vůči Microsoft Purview a extrahovat metadata popisků.
  • Před indexováním použijte popisky citlivosti na dokumenty, aby je systém během příjmu dat rozpoznal a zachoval.
  • V době dotazu připojte platný token Microsoft Entra prostřednictvím hlavičky x-ms-query-source-authorization ke každému požadavku dotazu. Azure AI Vyhledávač vyhodnotí token a přidružená metadata popisků k vynucení řízení přístupu na základě popisků.

Vynucování popisků citlivosti Purview je omezeno na scénáře s jedním tenantem a vyžaduje ověřování pomocí RBAC. Ve verzi Preview se podporuje jenom prostřednictvím rozhraní REST API a Sady Azure SDK. Rozhraní API pro automatické dokončování a návrhy nejsou aktuálně k dispozici pro indexy s podporou Purview.

Kde se zobrazují popisky citlivosti

Než systém může při dotazu uplatňovat štítky nebo je vracet v odpovědích na načtení, musíte nejprve synchronizovat metadata štítků do indexu. Obě cesty spotřeby popsané v této části závisí na tomto kroku synchronizace. Popisky můžete synchronizovat buď nastavením indexeru Azure AI Vyhledávač přímo pro podporovaný zdroj dat, nebo povolením odpovídající možnosti ingestace při vytváření zdroje znalostí. V obou případech musí vaše prostředí splňovat požadavky konfigurace synchronizace metadat popisků citlivosti (spravovaná identita, RBAC pro vyhledávací službu a požadovaná oprávnění pro Microsoft Purview a ke zdroji dat). Kompletní konfiguraci indexeru najdete v tématu Použití indexerů Azure AI Vyhledávač k příjmu popisků citlivosti Microsoft Purview. Pro ingestování řízené zdrojem znalostí nastavte ingestionPermissionOptions tak, aby zahrnovala sensitivityLabel při vytváření zdroje znalostí.

Po synchronizaci popisků využívají dva způsoby dotazování stejná metadata indexovaných popisků. Zvolte cestu, která odpovídá tomu, jak vaše aplikace volá Azure AI Vyhledávač:

Pokud zdroj znalostí odkazuje na index rozdělený na bloky, například naplněný pomocí integrované vektorizace nebo vlastní dovednosti Text Split, musí sada dovedností také promítnout štítek citlivosti do každého řádku bloku. Bez této projekce se nefiltrují odkazy na úrovni bloků dat.

Další informace najdete v tématu Použití indexerů Azure AI Vyhledávač k příjmu popisků citlivosti Microsoft Purview.

Vynucení oprávnění na úrovni dokumentu v době dotazu (Preview)

Vynucování dotazů založené na tokenech je průřezová schopnost, která se vztahuje na oblasti ACL podobné systému POSIX a RBAC, popisky citlivosti v Microsoft Purview a vzory seznamů ACL služby SharePoint v Microsoftu 365. Pomocí nativního dotazování na základě tokenů Azure AI Vyhledávač ověří token Microsoft Entra volajícího na každém požadavku a oříznou sady výsledků pouze na dokumenty, které volající má oprávnění číst podle seznamů ACL dokumentu, pokud jsou metadata seznamu ACL dokumentu synchronizována s indexem.

Když k požadavku na dotaz připojíte token uživatele prostřednictvím hlavičky x-ms-query-source-authorization, Azure AI Vyhledávač:

  1. Extrahuje deklarace identity uživatele, skupiny a oboru z tokenu.
  2. Porovnává tyto deklarace s metadaty oprávnění uloženými spolu s indexovanými dokumenty (položky ACL, rozsahy RBAC, přiřazení štítků Purview nebo seznamy ACL SharePointu).
  3. Vrátí pouze dokumenty, jejichž synchronizovaná metadata oprávnění udělují volajícímu přístup.

Vynucování při dotazu porovnává claimy Microsoft Entra volajícího s metadaty oprávnění, která už jsou uložená v indexu. Změny oprávnění ve zdrojovém systému (členství ve skupinách Microsoft Entra, seznamy ACL ADLS Gen2, přiřazení popisků Purview nebo seznamy ACL SharePoint) se projeví pouze ve výsledcích hledání poté, co se metadata synchronizují s indexem prostřednictvím zdrojového mechanismu, například následného spuštění indexeru, aktualizace push-API nebo aktualizace řízené purview. U SharePointu se změny ACL u položek s jedinečnými oprávněními průběžně zachycují při každém úspěšném spuštění indexeru, a to od verze rozhraní REST API 2026-05-01-preview, zatímco změny zděděné z nadřazených rozsahů (web, knihovna, seznam nebo složka) vyžadují explicitní obnovení. Další informace naleznete v tématu Synchronizace oprávnění mezi indexovaným a zdrojovým obsahem.

Postup implementace dotazů od začátku do konce najdete v tématu Vynucování ACL a RBAC v době dotazu v Azure AI Vyhledávač.

Výhody řízení přístupu na úrovni dokumentu

Nativní řízení přístupu na úrovni dokumentu v Azure AI Vyhledávač přináší konkrétní výhody oproti filtrování na straně aplikace:

  • Odstraňuje potřebu vlastního kódu pro oprávnění: V aplikaci nemusíte implementovat vyhodnocování vnořených skupin, procházení víceúrovňových seznamů ACL ani dodatečné filtrování výsledků po dotazu. Azure AI Vyhledávač zpracovává porovnání a filtrování během provádění dotazu.
  • Je v souladu se stávajícími kontrolními mechanismy pro dodržování předpisů: Opětovné využití metadat oprávnění Microsoft Entra, Microsoft Purview a SharePointu pomáhá zachovat soulad výsledků vyhledávání se zdrojovým systémem identit. Projděte si model synchronizace oprávnění pro každý zdroj a seznamte se s jeho omezeními.
  • Zachovává zdrojová oprávnění po každé synchronizaci ACL: U přístupů založených na tokenech (ACL, rozsahy RBAC, popisky Purview, ACL SharePointu) vynucování při dotazu používá metadata oprávnění, která již do indexu zapsal zdokumentovaný synchronizační mechanismus specifický pro daný zdroj (spuštění indexeru, aktualizace přes rozhraní push API nebo aktualizace Purview).
  • Zlepšuje výkon oproti oříznutí po dotazu: Filtrování uvnitř vyhledávacího kanálu je rychlejší než načítání větších sad výsledků do vaší aplikace a oříznutí tam, zejména u velkých objemů dotazů.
  • Používá stávající infrastrukturu identit: Microsoft Entra a SharePoint identity zůstávají zdrojem pravdivých informací pro rozhodnutí o přístupu, což snižuje duplicitu identit a provozní režii při údržbě paralelního úložiště oprávnění.

Návody a ukázky

Prozkoumejte řízení přístupu na úrovni dokumentu v Azure AI Vyhledávač s dalšími články a ukázkami.

Související obsah

  • Last updated on