Gyakorlati tapasztalatok

Vállalati tudás MI-vel: miért kell jogosultság-ellenőrzés a RAG-hoz?

A jó keresési találat még nem jelent engedélyezett hozzáférést. Az identitás, a jogosultságok, az index és a gyorsítótárak egy ellenőrzött RAG-architektúra részei.

IntegrációIT-biztonság
Dokumentumforrásokat megjelenítő táblagép mappák és ellenőrzőlista mellett.

Egy MI-alapú kereső találó idézettel válaszol egy belső kérdésre. Technikailag lenyűgöző, de a kérdező egyáltalán elolvashatta az idézett dokumentumot? Itt dől el, hogy egy RAG-megoldás alkalmas-e vállalati használatra.

A RAG összekapcsolja a keresést és a nyelvi modellt.

A Retrieval-Augmented Generation a lekérdezést megfelelő forrásinformációkkal egészíti ki. A dokumentumokat előkészítik és kereshetővé teszik; a kiválasztott részletek ezután a nyelvi modell kontextusaként szolgálnak. A modell ezekből forráshivatkozásokkal ellátott választ készíthet.

Ez az összekapcsolás akkor hasznos, ha a megfelelő információk naprakészek, és a felhasználó hozzáférhet hozzájuk. Veszélyessé válik, ha egy közösen használt index hatékony jogosultsági korlátozás nélkül adja vissza az összes dokumentumot. A csevegőfelületre való bejelentkezés önmagában nem jogosít fel minden ott megtalálható dokumentum elérésére.

A hozzáférés-ellenőrzésnek a modell előtt kell működnie.

A jogosultságokat ellenőrző keresés csak engedélyezett dokumentumkontextust ad át a nyelvi modellnek; a forrásokat és a jogosultságok változásait követik.
Lehetséges helyzet vagy architektúra, tényleges ügyfél- vagy személyzeti adatok nélkül.

Az alkalmazás megbízható bejelentkezési eljárásból állapítja meg a felhasználó identitását. A keresés a megengedett körre korlátozza a találatokat és a részleteket. Csak ez az engedélyezett kontextus kerül a nyelvi modellhez. Magának az indexnek, adminisztrációs hozzáféréseinek és a forrással való kapcsolatának is megfelelő ellenőrzésekre van szüksége.

A bizalmas információk kiadását tiltó promptutasítás egyetlen hozzáférési védelemként túl későn lép működésbe. A nem engedélyezett adatokat addigra már feldolgozták volna. Egy idézet utólagos elrejtése sem javítja ki ezt az adatátadást.

Az apró mellékutak is számítanak.

A találatok címei
Már egy tervezett személyzeti intézkedésre utaló cím is bizalmas lehet. Nem csupán a teljes dokumentumszöveghez kell jogosultsági szűrő.
Gyorsítótárak
Az A felhasználónak készített válasz ellenőrzés nélkül nem használható fel újra B számára. A gyorsítótár tervezésekor figyelembe kell venni az identitást, a bérlőt és a megfelelő jogosultságokat.
Forráshivatkozások
Egy kattintható hivatkozásnak az eredeti dokumentum megnyitásakor továbbra is ellenőriznie kell a jogosultságot. Egy privát letöltési hivatkozás nem hozhat létre általános hozzáférést.
Naplók
A keresési lekérdezések, részletek és hibaadatok üzleti titkokat tartalmazhatnak. A betekintést és a megőrzési időt korlátozni kell.

A jogosultságok gyorsabban változnak, mint egyes indexek.

Valaki másik részlegre kerül, egy projekt lezárul, vagy visszavonnak egy megosztást. A forrásállománynak és a keresési jogosultságoknak ismét összhangba kell kerülniük. Ehhez az architektúrában dokumentált frissítési folyamatra és megfelelő reakcióidőre van szükség.

Különösen fontos teszt a jogosultság visszavonása: a módosítás után ugyanazzal a fiókkal ismét felteszik a korábban engedélyezett kérdést. Azt is ellenőrzik, hogy régebbi gyorsítótárak, előnézetek vagy mentett válaszok továbbra is lehetővé teszik-e a hozzáférést. Az eredményt dokumentálni kell; egy sikeresen befejezett importálás önmagában nem elegendő.

A termékfunkciók nem felcserélhető építőelemek.

Egyes keresőszolgáltatások támogatják a natív, dokumentumszintű ellenőrzést, mások kifejezetten kikényszerített szűrőket és saját szinkronizálást igényelnek. Az Azure AI Search aktuális dokumentációja például különbséget tesz a biztonsági szűrők és további integrált eljárások között, amelyek egy részét Preview jelöléssel látja el. Az API és a verzió ezért az architektúrával kapcsolatos döntés része.

Az eszköztől függetlenül az átvételnek igazolnia kell, hogy egy tesztidentitás mely forrásokat láthatja, és melyeket nem kapja meg. A kívánt határokat nem szabad utólag, a modell egy véletlenszerű válaszából levezetni.

Az ellenőrizhető pilot összekapcsolja a hasznosságot és a védelmet.

A DAXS körülhatárolt tudásállománnyal kezdhet: megnevezett forrásfelelősökkel, naprakész dokumentumokkal, tesztfiókokkal, egyértelmű válaszkritériumokkal és visszakövethető negatív tesztekkel. A hatókör csak akkor bővül, ha a keresés, a jogosultságok és a forráshivatkozások megfelelően működnek.

A Vállalati tudás és RAG szakoldal összefüggéseiben mutatja be az importálást és a lekérdezéseket. Az MI biztonsága részletesebben tárgyalja a túl széles megosztást, az identitásokat és az ágensek jogosultságait.

Források: Microsoft: dokumentumszintű hozzáférés-ellenőrzés · OWASP: a vektorok és beágyazások gyengeségei. Az ábra egy lehetséges architektúrát mutat be ügyféladatok nélkül.