Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Megjegyzés
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.
A dokumentumszintű engedélybetöltés a leküldéses REST API-kon (előzetes verzió) keresztül lehetővé teszi a dokumentumok indexelését a hozzájuk tartozó hozzáférés-vezérlési listákkal (ACL-ekkel) és a tároló szerepköralapú hozzáférés-vezérlési (RBAC) szerepköreivel együtt. Amikor leküldi a tartalmat egy Azure AI Keresés indexbe a leküldéses REST API-kon keresztül, a szolgáltatás megőrzi az indexelt tartalomra vonatkozó engedélyeket, és a lekérdezéskor kényszeríti őket.
A legfontosabb funkciók a következők:
- Az adatbetöltési csatornák rugalmas vezérlése.
- Az engedélyek metaadatainak szabványosított sémája.
- Hierarchikus engedélyek, például mappaszintű ACL-ek támogatása.
Ez a cikk bemutatja, hogyan használható a leküldéses REST API a dokumentumszintű engedély metaadatainak indexelésére Azure AI Keresés. Ez a folyamat előkészíti az indexet a keresési eredményekre vonatkozó végfelhasználói engedélyek lekérdezésére és kikényszerítésére.
Előfeltételek
Tartalom a Microsoft Entra ID vagy más POSIX típusú ACL-rendszer ACL-metaadataival.
userIdsAzgroupIdsACL-mezőkhöz Microsoft Entra objektumazonosítókat (GUID-ket) használjon, ne UPN-eket vagy e-mail-címeket. A stabil objektumazonosítók megbízható identitás-egyeztetést biztosítanak a lekérdezési időben, még akkor is, ha a címtárattribútumok megváltoznak.A latest preview REST API vagy egy olyan előzetes verziójú Azure SDK csomag, amely egyenértékű funkciókat biztosít.
A
permissionFilterOptionengedélyezést tartalmazó indexséma, valamint a dokumentumengedélyeket tárolópermissionFiltermezőattribútumok.
Korlátozások
Engedélyszűrő típusú
userIdsACL-mező, vagygroupIdslegfeljebb 1000 érték tárolására képes.Az index legfeljebb öt egyedi értéket tartalmazhat az összes dokumentum típusmezői
rbacScopeközött. Az azonos értékűrbacScopedokumentumok száma nincs korlátozva.Egy meglévő mező frissíthető úgy, hogy tartalmazza
permissionFiltera beépített ACL- vagy RBAC-metaadat-szűrés hozzárendelését. Ha egy meglévő index szűrését szeretné engedélyezni, adjon hozzá új mezőket, vagy frissítse a meglévő mezőket apermissionFilterértékkel.Egy indexben csak egy mező létezhet az egyes
permissionFiltertípusok közül (mindegyikgroupIdsuserIds, ésrbacScope) .Minden
permissionFiltermezőhöz állítsa be afilterableértékéttrue-re.A lekérdezési idő jogosultságának érvényesítése az indexbe legutóbb írt ACL-értékeket tükrözi. Ha a forrásengedélyek megváltoznak, ezek a frissítések mindaddig nem jelennek meg, amíg az érintett dokumentumok betöltése vagy frissítése nem történik meg. Növekményes újratöltés vagy részleges frissítések ütemezése az ACL-ek naprakészen tartásához.
Ez a funkció jelenleg nem támogatott a Azure portálon.
Index létrehozása engedélyszűrő mezőkkel
A dokumentum ACL-jeinek és RBAC-metaadatainak REST API-val való indexeléséhez olyan indexsémát kell beállítani, amely engedélyezi az engedélyszűrőket, és engedélyszűrő-hozzárendeléssel rendelkező mezőket tartalmaz.
Először adja hozzá a elemet permissionFilterOption. Az érvényes értékek a enabled vagy a disabled, és enabled-re kell beállítani. Átállíthatja a disabled elemre, ha az engedélyszűrő funkciót az index szintjén ki szeretné kapcsolni.
Másodszor hozzon létre sztringmezőket az engedély metaadataihoz, és adja meg a következőket permissionFilter: Ne feledje, hogy minden engedélyszűrő-típusból választhat egyet.
Íme egy egyszerű példaséma, amely az összes permissionFilter típust tartalmazza:
{
"fields": [
{ "name": "UserIds", "type": "Collection(Edm.String)", "permissionFilter": "userIds", "filterable": true },
{ "name": "GroupIds", "type": "Collection(Edm.String)", "permissionFilter": "groupIds", "filterable": true },
{ "name": "RbacScope", "type": "Edm.String", "permissionFilter": "rbacScope", "filterable": true },
{ "name": "DocumentId", "type": "Edm.String", "key": true }
],
"permissionFilterOption": "enabled"
}
Vállalati adattárak, például a SharePoint Online esetében a push API meghívása előtt, a betöltés során képezze le a dokumentumszintű vagy mappaszintű engedélyeket Microsoft Entra felhasználó- és csoportobjektum-azonosítókra. Ezután ezeket az azonosítókat a megfelelő engedélymezőkben kell tárolnia.
REST API indexelési példa
Miután rendelkezik engedélyszűrő mezőkkel rendelkező indexel, ezeket az értékeket feltöltheti a leküldéses indexelő API-val, ugyanúgy, mint bármely más dokumentummezővel. Íme egy példa a megadott indexséma használatával, ahol minden dokumentum megadja az indexelési műveletet, a kulcsmezőt (DocumentId) és az engedélymezőket. A dokumentumoknak tartalmazniuk kell a tartalmat is, de ez a mező hiányzik ebben a példában a rövidség kedvéért.
POST https://exampleservice.search.windows.net/indexes('indexdocumentsexample')/docs/search.index?api-version=2026-08-01-preview
{
"value": [
{
"@search.action": "upload",
"DocumentId": "1",
"UserIds": ["00aa00aa-bb11-cc22-dd33-44ee44ee44ee", "11bb11bb-cc22-dd33-ee44-55ff55ff55ff", "22cc22cc-dd33-ee44-ff55-66aa66aa66aa"],
"GroupIds": ["none"],
"RbacScope": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/Example-Storage-rg/providers/Microsoft.Storage/storageAccounts/azurestorage12345/blobServices/default/containers/blob-container-01"
},
{
"@search.action": "merge",
"DocumentId": "2",
"UserIds": ["all"],
"GroupIds": ["33dd33dd-ee44-ff55-aa66-77bb77bb77bb", "44ee44ee-ff55-aa66-bb77-88cc88cc88cc"]
},
{
"@search.action": "mergeOrUpload",
"DocumentId": "3",
"UserIds": ["1cdd8521-38cf-49ab-b483-17ddaa48f68f"],
"RbacScope": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/Example-Storage-rg/providers/Microsoft.Storage/storageAccounts/azurestorage12345/blobServices/default/containers/blob-container-03"
}
]
}
ACL hozzáférés-kezelési szabályok
Ez a szakasz azt ismerteti, hogyan határozza meg a rendszer a felhasználó dokumentumhozzáférését az egyes dokumentumok engedélymezői alapján. Ezek a mezők ACL-ek (userIds és groupIds, ahol groupIds biztonsági csoportokat és Microsoft 365-csoportok) vagy RBAC-hatókört (rbacScope) tartalmaznak. Azure az RBAC-hatókört és az ACL-eket meghatározott sorrendben értékeli ki, az ADLS Gen2 engedélymodellel összhangban.
A felhasználó az alábbi mezők valamelyikének való megfeleléssel kap hozzáférést: egy egyező userIds- vagy groupIds-bejegyzéssel, vagy a rbacScope-höz tartozó jogosító Azure-szerepkörhozzárendeléssel. A hívóidentitások lekérdezési időben való megadásáról további információt a lekérdezési idejű ACL és az RBAC-kényszerítés című témakörben talál.
Speciális ACL-értékek: "all" és "none"
Az ACL-mezők, például userIds és groupIds, általában olyan grafikus felhasználói azonosítók (globálisan egyedi azonosítók) listáját tartalmazzák, amelyek azonosítják a dokumentumhoz hozzáféréssel rendelkező felhasználókat és csoportokat. Két speciális sztringérték, az "all" és a "none" támogatott ezekhez az ACL-mezőtípusokhoz. Ezek az értékek széles körű szűrőkként működnek a globális szintű hozzáférés szabályozásához, ahogy az az alábbi táblázatban is látható.
| userIds / groupIds érték | Jelentése |
|---|---|
["all"] |
Bármely felhasználó hozzáférhet a dokumentumhoz |
["none"] |
Egyetlen felhasználó sem férhet hozzá a dokumentumhoz ennek az ACL-típusnak megfelelően |
| [] (üres tömb) | Egyetlen felhasználó sem férhet hozzá a dokumentumhoz ennek az ACL-típusnak megfelelően |
Mivel a felhasználónak csak egy mezőtípussal kell egyeznie, az "összes" speciális érték minden más ACL-mezőértéktől függetlenül nyilvános hozzáférést biztosít. Ezzel szemben a "nincs" vagy az üres tömb beállítása userIds azt jelenti, hogy egyetlen felhasználó sem kap hozzáférést a dokumentumhoz a felhasználói azonosító alapján. Előfordulhat, hogy még mindig kapnak hozzáférést, ha megfelelnek a csoportazonosító vagy az RBAC-metaadatok követelményeinek.
Hozzáférés-vezérlési példa
Ez a példa bemutatja, hogyan oldódnak fel a dokumentum-hozzáférési szabályok a ( és userIds) groupIdsengedélymező-értékek rbacScopealapján. Az olvashatóság érdekében ez a forgatókönyv olyan aliasokat használ, mint a "user1" és a "group1" a GUID-k helyett; éles környezetben Microsoft Entra objektumazonosítókat (GUID-ket) használjon.
| Dokumentum # | felhasználói azonosítók | csoportazonosítók | RBAC-hatókör | Engedélyezett felhasználók listája | Megjegyzés |
|---|---|---|---|---|---|
| 1 | ["none"] |
[] |
Üres | Egyetlen felhasználó sem rendelkezik hozzáféréssel | Az ["none"] és [] értékek pontosan ugyanúgy viselkednek. |
| 2 | ["none"] |
[] |
scope/to/container1 | A tárolóhoz RBAC-engedélyekkel rendelkező felhasználók1 | A "nincs" érték nem blokkolja a hozzáférést, ha más engedélymezők (groupIds vagy rbacScope) hozzáférést adnak |
| 3 | ["none"] |
["group1", "group2"] |
Üres | Csoport1 vagy csoport2 tagjai | |
| 4 | ["all"] |
["none"] |
Üres | Bármely felhasználó | Minden lekérdezést végző felhasználó egyezik az ACL szűrő "összes" beállításával, így minden felhasználó hozzáféréssel rendelkezik. |
| 5 | ["all"] |
["group1", "group2"] |
scope/to/container1 | Bármely felhasználó | Mivel minden felhasználó megfelel a userID "all" szűrőjének, a groupID és az RBAC szűrőknek nincs hatása |
| 6 | ["user1", "user2"] |
["group1"] |
Üres | Felhasználó1, felhasználó2 vagy csoport1 bármely tagja | |
| 7 | ["user1", "user2"] |
[] |
Üres | Felhasználó1 vagy felhasználó2 |