Dokumentumszintű hozzáférés-vezérlés a Azure AI Keresés

Note

Azure AI Keresés a Azure portálon, REST API-kon és Azure SDK-k keresztül érhető el. Emellett a Foundry IQ-t is támogatja, amely a vállalati tartalmakat újrafelhasználható, engedélytudatos tudásbázisokká alakítja át az Microsoft Foundry portálon található ügynökök számára.

Important

Az (előzetes verzióban) megjelölt funkciókra, képességekre vagy tulajdonságokra nem vonatkozik szolgáltatási szintű szerződés, nem ajánlott éles számítási feladatokhoz, és az általános elérhetővé válásuk előtt változhatnak vagy korlátozhatók. Az Azure AI Keresés előzetes verziójú kifejezések az összes előzetes verziós funkcióra vonatkoznak, függetlenül attól, hogy önálló vagy egy általánosan elérhető funkció része.

Azure AI Keresés támogatja a dokumentumszintű hozzáférés-vezérlést, lehetővé téve a szervezetek számára, hogy részletes engedélyeket kényszeríthessenek ki a dokumentum szintjén az adatbetöltéstől a lekérdezések végrehajtásáig. Ez a képesség elengedhetetlen az adatok biztonságos AI autonóm rendszerek, a visszakereséssel kibővített generációs (RAG) alkalmazások és a dokumentumszintű hitelesítési ellenőrzéseket igénylő vállalati keresési megoldások létrehozásához.

A dokumentumszintű hozzáférés-vezérlés megközelítései

Azure AI Keresés négy elsődleges megközelítést biztosít a dokumentumszintű engedélyek kikényszerítéséhez, amelyek mindegyike különböző adatforrásokhoz és identitásmodellekhez igazodik.

Megközelítés Leírás
Biztonsági szűrők Sztringek összehasonlítása. Az alkalmazás sztringként adja át a felhasználó vagy a csoport identitását, amely kitölt egy szűrőt egy lekérdezésen, kivéve a sztringen nem egyező dokumentumokat.

A biztonsági szűrők a dokumentumszintű hozzáférés-vezérlés elérésének technikái. Ez a megközelítés nem egy API-hoz van kötve, így bármilyen verziót vagy csomagot használhat.
POSIX-szerű ACL/RBAC-hatókörök (előzetes verzió) A lekérdezési jogkivonat mögötti Microsoft Entra biztonsági tagot a rendszer összehasonlítja a keresési eredményekben visszaadott dokumentumok engedély metaadataival, kivéve az engedélyekkel nem egyező dokumentumokat. A hozzáférés-vezérlési lista (ACL) engedélyei Azure Data Lake Storage (ADLS) Gen2-címtárakra és fájlokra vonatkoznak. A szerepköralapú hozzáférés-vezérlési (RBAC) hatókörök az ADLS Gen2-tartalmakra és Azure blobokra vonatkoznak.

A dokumentum szintjén az identitásalapú hozzáférés beépített támogatása előzetes verzióban érhető el, REST API-kban és előzetes verziójú Azure SDK csomagokban, amelyek biztosítják a szolgáltatást. A funkciók támogatásáról az SDK-verzió támogatási részleteiben tájékozódhat.
Microsoft Purview bizalmassági címkék (előzetes verzió) Az Indexelő a támogatott adatforrásokból (Azure Blob Storage, ADLS Gen2, SharePoint Microsoft 365, OneLake) kinyeri a Microsoft Purview definiált bizalmassági címkéket. Ezek a címkék metaadatként vannak tárolva, és a lekérdezési időpontban kiértékelve biztosítják a felhasználói hozzáférés szabályozását a Microsoft Entra jogkivonatok és Purview-szabályzat-hozzárendelések alapján. A címkék a tudásforrásokon és az ügynökalapú lekérdezési válaszon keresztül is megjelennek, így a tudásbázist használó AI-ügynökök és csevegőalkalmazások ugyanazt a címkealapú szűrést kapják meg. Ez a megközelítés Azure AI Keresés hitelesítést a vállalat Microsoft Information Protection modelljéhez igazítja.
SharePoint Microsoft 365 ACL-ben (előzetes verzió) Azure AI Keresés indexelők a támogatott SharePoint tartalomból nyerik ki az engedély metaadatait, és lekérdezési idejű hozzáférés-ellenőrzésekhez használják. A támogatott tartalmakról, a tagokról, a csoportkapcsolatokról, a szinkronizálási viselkedésről és az engedélyekről lásd: SharePoint indexelő használata az engedély metaadatainak betöltéséhez.

Indexelt tudásforrások esetén a(z) ingestionPermissionOptions nem kombinálható a következővel: assetStore. Ezért a rendszerkép-szolgáltatás (előzetes verzió) nem érhető el, ha engedélyezve van a natív dokumentumszintű engedélybetöltés.

Megközelítés kiválasztása

Az alábbi feltételekkel azonosíthatja az adatforrásnak, az identitásmodellnek és a megfelelőségi követelményeknek leginkább megfelelő megközelítést.

Scenario Ajánlott megközelítés Miért
Egyéni identitásrendszer, nem Microsoft-alapú biztonsági keretrendszer vagy bármilyen push alapú index. Biztonsági szűrők API-agnosztikus, széles körben elérhető, és egyszerű karakterlánc-egyeztetésen alapul.
Az ADLS Gen2-ben vagy az Azure Blob Storage-ban található tartalom meglévő ACL- vagy RBAC-hozzárendelésekkel. POSIX-szerű ACL- és RBAC-hatókörök Natív Microsoft Entra integráció; a lekérdezési idő kényszerítése a dokumentált szinkronizálási mechanizmus által az indexbe írt engedély metaadatokat használja.
A vállalati tartalomra már Microsoft Purview adatvédelmi szabályzatok vonatkoznak. Microsoft Purview bizalmassági címkék Újra felhasználja a központosított besorolást és a szabályzat-hozzárendeléseket az Azure AI Keresés egészében.
A Microsoft 365 SharePoint származó tartalom (tárak, listák, ASPX-webhelylapok). ACL-ek a Microsoft 365 SharePointban Natív SharePoint engedélyekkel rendelkezik, beleértve SharePoint webhelycsoportokat is.

A szűrőkkel végzett biztonsági vágás mintája

Azokban a forgatókönyvekben, ahol a natív ACL/RBAC-hatókörök integrációja nem megvalósítható, biztonsági karakterláncszűrőkkel szűrje az eredményeket a kizárási kritériumok alapján. A minta a következő összetevőket tartalmazza:

  • A felhasználói vagy csoportidentitások tárolásához hozzon létre egy sztringmezőt az indexben.
  • Töltse be az indexet a társított ACL-eket tartalmazó forrásdokumentumokkal.
  • Adjon meg egy szűrőkifejezést a lekérdezési logikában a sztringen való egyeztetéshez.
  • Lekérdezéskor kérje le a hívó identitását.
  • Adja meg a hívó identitását szűrősztringként.
  • A rendszer levágja az eredményeket, hogy kizárja azokat az egyezéseket, amelyek nem tartalmazzák a felhasználó vagy a csoport identitási sztringét.

Leküldéses vagy lekéréses modell API-kat is használhat. Mivel ez a megközelítés API-agnosztikus, csak meg kell győződnie arról, hogy az index és a lekérdezés érvényes sztringekkel (identitásokkal) rendelkezik a szűrési lépéshez.

Ez a megközelítés egyéni hozzáférési modellekkel vagy nem Microsoft biztonsági keretrendszerekkel rendelkező rendszerek esetében hasznos. Erről a megközelítésről és az eredmények szűréséről a Biztonsági szűrők a vágáshoz az Azure AI Keresés-ben című témakörben talál további információt.

Minta a POSIX-szerű ACL- és RBAC-hatókörengedélyek natív támogatásához (előzetes verzió)

A natív támogatás Microsoft Entra indexelni és lekérdezni kívánt dokumentumokkal társított felhasználókon és csoportokon alapul.

Azure Data Lake Storage (ADLS) Gen2-tárolók támogatják a tárolón és a fájlokon található ACL-eket. Az ADLS Gen2 esetében az RBAC-hatókör dokumentumszinten történő megőrzése natív módon támogatott, ha ADLS Gen2-indexelőt vagy Blob-tudásbázist (az ADLS Gen2-t támogatja) és egy előzetes API-t használ a tartalom betöltéséhez. A Azure blobindexelőt vagy tudásbázist használó Azure blobok esetében az RBAC-hatókör megőrzése a tároló szintjén van.

Az ACL által védett tartalmak esetében a könnyű kezelés érdekében használjon csoporthozzáférést egyéni felhasználói hozzáféréssel. A minta a következő összetevőket tartalmazza:

Az ügyfélalkalmazás olvasási engedélyeket kap az indexhez a Keresési index adatolvasója vagy a Keresési index adatszolgáltató szerepkörén keresztül. A lekérdezési időpontban való hozzáférést az indexelt tartalom felhasználói vagy csoportengedély-metaadatai határozzák meg. Az engedélyszűrőt tartalmazó lekérdezések a kérelem fejlécében szereplő x-ms-query-source-authorization felhasználói vagy csoportjogkivonatot adják át. Ha a lekérdezéskor engedélyszűrőket használ, Azure AI Keresés két dolgot keres:

  • Először a keresési index adatolvasójának engedélyét ellenőrzi, amely lehetővé teszi az ügyfélalkalmazás számára az index elérését.

  • Másodszor, a kéréshez tartozó extra token figyelembevételével, ellenőrzi a keresési eredményekben visszaadott dokumentumok felhasználók vagy csoportok számára biztosított engedélyeket, kivéve azokat, amelyek nem felelnek meg.

Az engedélymetaadatok indexbe juttatásához használja a pushmodell API-t, és küldjön JSON-dokumentumokat a keresési indexbe, ahol az adatcsomag minden dokumentumhoz tartalmaz egy karakterláncmezőt, amely POSIX-szerű ACL-eket ad meg. A megközelítés és a biztonsági vágás között az a fontos különbség, hogy az engedélyszűrő metaadatai az indexben és a lekérdezésben Microsoft Entra ID hitelesítésként lesznek felismerve, míg a biztonsági vágás megkerülő megoldása az egyszerű sztringek összehasonlítása. Emellett a Graph SDK-val is lekérheti az identitásokat.

A lekéréses modell (indexelő) API-kat akkor is használhatja, ha az adatforrás Azure Data Lake Storage (ADLS) Gen2, és a kód egy előzetes API-t hív meg indexelésre.

ACL-engedélyek metaadatainak lekérése az adatbetöltési folyamat során (előzetes verzió)

Az ACL-engedélyek lekérésének menete attól függően változik, hogy dokumentumterheléseket küld le, vagy az ADLS Gen2 indexelőt használja.

Kezdje a funkciót biztosító előzetes verziójú API-val:

A leküldéses modell megközelítéséhez:

  1. Ellenőrizze, hogy az indexséma előzetes vagy előzetes SDK-val lett-e létrehozva, és hogy a séma rendelkezik-e engedélyszűrőkkel.
  2. Fontolja meg a Microsoft Graph SDK használatát csoport- vagy felhasználói identitások lekéréséhez.
  3. A Index Dokumentumok vagy azzal egyenértékű Azure SDK API használatával leküldheti a dokumentumokat és a hozzájuk tartozó engedély metaadatait a keresési indexbe.

A lekéréses modell ADLS Gen2 indexelő megközelítése vagy Blob (ADLS Gen2) tudásbázis esetében:

  1. Ellenőrizze, hogy a címtárban lévő fájlok biztonságban vannak-e az ADLS Gen2 hozzáférés-vezérlési modellel.
  2. A Indexers – Create (REST API), Knowledge Sources – Create (REST API) vagy egy egyenértékű Azure SDK API használata az indexelő, az index és az adatforrás létrehozásához.

Ha a készségkészlet dokumentumokat darabokra bont, például az integrált vektorizáláshoz használt Text Split készséggel, az engedélymetaadat-mezők az indexelőmező-leképezésekből az indexvetítésekbe kerülnek át. Lásd: Válassza ki, hol töltse ki az ACL-mezőket.

Minta SharePoint Microsoft 365 alapszintű ACL-engedélyek betöltéséhez (előzetes verzió)

Indexelt SharePoint tartalom esetén a Azure AI Keresés metaadatként tárolhatja a forrásengedélyeket, és a lekérdezési eredmények szűrésére használhatja őket. Ezt a képességet előzetes verzióként érheti el a Microsoft 365 SharePoint-indexelőjén, valamint a legújabb REST API vagy egy azzal egyenértékű, előzetes verziójú SDK-csomag használatával.

Az engedélykövetelményekkel, a támogatott csoportkapcsolatokkal, az engedély-szinkronizálással és a korlátozásokkal kapcsolatban lásd: SharePoint indexelő használata az engedély metaadatainak betöltéséhez.

Ha a készségkészlet dokumentumokat darabol fel (például az integrált vektorizáláshoz használt Text Split-készséggel), az ACL-mezők az indexelő mezőleképezéseiből az indexkivetítésekbe kerülnek. Lásd: Válassza ki, hol töltse ki az ACL-mezőket.

Minta Microsoft Purview bizalmassági címkékhez (előzetes verzió)

Ha engedélyezi a címkék betöltését, az Azure AI Keresés bizalmassági metaadatokat nyer ki a támogatott adatforrásokból. Ezek az adatforrások közé tartozik a Azure Blob Storage, a Azure Data Lake Storage Gen2 (ADLS Gen2), a Microsoft 365 SharePoint és a OneLake Microsoft. A kinyert címkék a dokumentumtartalom mellett az indexben vannak tárolva.

Lekérdezéskor Azure AI Keresés ellenőrzi az egyes dokumentumok bizalmassági címkéit, a felhasználó Microsoft Entra jogkivonatát és a szervezet Purview-szabályzatát a hozzáférés meghatározásához. A rendszer csak akkor ad vissza dokumentumokat, ha a felhasználó identitás- és címkealapú engedélyei engedélyezik a hozzáférést a konfigurált Purview-szabályzatok alatt.

Ez a minta a következő összetevőket tartalmazza:

  • Konfigurálja az indexelőt, az adatforrást és az indexelőt (ütemezési célokra) a legújabb előzetes REST API vagy a Purview-címkebetöltést támogató előzetes SDK használatával.
  • Engedélyezze a rendszer által hozzárendelt felügyelt identitást a keresési szolgáltatásban. A felhasználó által hozzárendelt felügyelt identitások nem támogatottak a Purview-címkék kinyerése során – a szolgáltatás saját identitásának rendelkeznie kell az emelt szintű Purview-engedélyekkel. Ezután kérje meg a bérlő globális rendszergazdáját vagy emelt szintű szerepkör-rendszergazdáját, hogy engedélyezze a szükséges hozzáférést ahhoz, hogy a keresési szolgáltatás hitelesíthessen a Microsoft Purview szolgáltatással, és kinyerhesse a címkék metaadatait.
  • Az indexelés előtt alkalmazza a bizalmassági címkéket a dokumentumokra, hogy a rendszer felismerje és megőrizze őket a betöltés során.
  • Lekérdezéskor csatoljon egy érvényes Microsoft Entra jogkivonatot a fejlécen keresztül x-ms-query-source-authorization az egyes lekérdezési kérelmekhez. Azure AI Keresés kiértékeli a jogkivonatot és a kapcsolódó címke metaadatait a címkealapú hozzáférés-vezérlés kényszerítéséhez.

A Purview bizalmassági címkéinek érvényesítése egy-bérlős környezetekre korlátozódik, és RBAC-hitelesítést igényel. Az előzetes verzióban ez csak a REST API-n és az Azure SDK-kon keresztül támogatott. Az automatikus kiegészítés és a Javaslat API-k jelenleg nem érhetők el Purview-kompatibilis indexekhez.

A bizalmassági címkék megjelenési helyei

Mielőtt a rendszer kikényszerítené a címkéket a lekérdezési időpontban, vagy vissza tudja adni őket a lekérdezési válaszokban, először szinkronizálnia kell a címke metaadatait az indexbe. Az ebben a szakaszban ismertetett mindkét használati útvonal a szinkronizálási lépéstől függ. A címkék szinkronizálásához konfiguráljon egy Azure AI Keresés indexelőt közvetlenül egy támogatott adatforráshoz, vagy engedélyezze az ezzel egyenértékű betöltési lehetőséget a tudásbázis létrehozásakor. A környezetnek mindkét esetben meg kell felelnie a szenzitivitási címke metaadatainak szinkronizálási konfigurációs előfeltételeinek (felügyelt identitás, A keresési szolgáltatás RBAC-ja és a szükséges Microsoft Purview és adatforrás-engedélyek). A teljes körű indexelőkonfigurálással kapcsolatban lásd: Az Azure AI Keresés indexelőinek használata a Microsoft Purview bizalmassági címkéinek betöltéséhez. A tudásforrás által vezérelt betöltéshez állítsa be a ingestionPermissionOptions elemet úgy, hogy tartalmazza a sensitivityLabel elemet a tudásforrás létrehozása során.

A címkék szinkronizálása után két lekérdezési útvonal ugyanazt az indexelt címke metaadatait használja. Válassza ki azt az útvonalat, amely megfelel annak, ahogyan az alkalmazás az Azure AI Keresésöt hívja:

Ha a tudásforrás egy adattömbös indexre mutat, például egy integrált vektorizálással vagy egy egyéni szövegfelosztási képességekkel kitöltött indexre, a képességkészletnek minden egyes adattömbsorra ki kell vetítenie a bizalmassági címkét. A kivetítés nélkül az adattömbszintű hivatkozások nem lesznek szűrve.

További információért, lásd: Az Azure AI Keresés indexelők használata Microsoft Purview bizalmassági címkék beolvasásához.

Dokumentumszintű engedélyek kényszerítése lekérdezéskor (előzetes verzió)

A tokenalapú lekérdezések kényszerítése egy több területre kiterjedő képesség, amely a POSIX-szerű ACL- és RBAC-hatókörökben, a Microsoft Purview bizalmassági címkéire és a Microsoft 365 SharePoint ACL-mintáira alkalmazható. Natív jogkivonatalapú lekérdezés használatával Azure AI Keresés ellenőrzi a hívó Microsoft Entra jogkivonatát minden egyes kérésen, és az eredményhalmazokat csak azokra a dokumentumokra vágja, amelyek olvasására jogosult a hívó a dokumentum ACL-jei szerint, feltéve, hogy a dokumentum ACL-metaadatai szinkronizálva lesznek az indexszel.

Amikor a felhasználó tokenjét a(z) x-ms-query-source-authorization fejlécen keresztül csatolja egy lekérési kérelemhez, az Azure AI Keresés:

  1. Kinyeri a tokenből a felhasználóra, a csoportra és a hatókörre vonatkozó jogosultságállításokat.
  2. Összehasonlítja ezeket a jogcímeket az indexelt dokumentumok (ACL-bejegyzések, RBAC-hatókörök, Purview-címke-hozzárendelések vagy SharePoint ACL-ek) mellett tárolt engedély metaadataival.
  3. Csak olyan dokumentumokat ad vissza, amelyek szinkronizált engedély metaadatai hozzáférést biztosítanak a hívó számára.

A lekérdezéskori érvényesítés a hívó Microsoft Entra-jogcímállításait az indexben már tárolt engedélymetaadatokkal összevetve értékeli ki. A forrásrendszer engedélyváltozásai (Microsoft Entra csoporttagság, ADLS Gen2 ACL-ek, Purview-címke-hozzárendelések vagy SharePoint ACL-ek) csak akkor jelennek meg a keresési eredményekben, ha a metaadatok a forrásspecifikus mechanizmuson keresztül szinkronizálódnak az indexre, például egy későbbi indexelő futtatása, egy push-API-frissítés vagy egy Purview-alapú frissítés. Az SharePoint esetében az egyedi engedélyekkel rendelkező elemek ACL-módosításait a rendszer növekményesen veszi fel a 2026-05-01-es előzetes verziójú REST API-ban kezdődő sikeres indexelő futtatásokon, míg a szülő hatóköröktől (webhelytől, tártól, listától vagy mappától) örökölt módosítások explicit frissítést igényelnek. További információ: Engedélyek szinkronizálása az indexelt és a forrástartalom között.

A lekérdezések implementálásának lépéseit a Lekérdezési idejű ACL és RBAC-kényszerítés a Azure AI Keresés című témakörben találja.

A dokumentumszintű hozzáférés-vezérlés előnyei

Az Azure AI Keresés natív dokumentumszintű hozzáférés-vezérlése konkrét előnyöket biztosít az alkalmazásoldali szűréssel szemben:

  • Megszünteti az egyéni engedélykódot: Nem kell beágyazott csoportfelbontást, többszintű ACL-bejárást vagy lekérdezés utáni vágást implementálnia az alkalmazásban. Azure AI Keresés kezeli az összehasonlítást és a szűrést a lekérdezés végrehajtása során.
  • Összhangban van a meglévő megfelelőségi szabályozókkal: A Microsoft Entra, a Microsoft Purview és a SharePoint engedélyezési metaadatainak újbóli felhasználása segít összhangban tartani a keresési eredményeket a forrásidentitás-rendszerrel. Tekintse át az egyes forrásokkal kapcsolatos engedélyszinkronizálási modellt, hogy megértse annak korlátait.
  • A forrásengedélyeket minden ACL-szinkronizálás után tiszteletben tartja: Jogkivonatalapú megközelítések (ACL, RBAC-hatókörök, Purview-címkék, SharePoint ACL-ek) esetén a lekérdezési időkorlát-kényszerítés azokat az engedély metaadatokat használja, amelyeket a dokumentált forrásspecifikus szinkronizálási mechanizmus (indexelő futtatása, push-API-frissítés vagy Purview-frissítés) már írt az indexhez.
  • Javítja a teljesítményt és a lekérdezés utáni vágást: A keresési folyamaton belüli szűrés gyorsabb, mint nagyobb eredményhalmazok betöltése az alkalmazásba, és ott levágni őket, különösen nagy lekérdezési kötetek esetén.
  • A meglévő identitásinfrastruktúra újrahasználata: Microsoft Entra és SharePoint identitások továbbra is az igazság forrása maradnak a hozzáférési döntésekhez, ami csökkenti az identitások duplikálását és a párhuzamos engedélytárolók fenntartásának működési többletterhelését.

Oktatóanyagok és minták

További cikkek és minták segítségével többet tudhat meg a dokumentumszintű hozzáférés-vezérlésről az Azure AI Keresésben.

Kapcsolódó tartalom

  • Utolsó frissítés időpontja: