RAG-jogosultságok weboldal-chatbotokhoz: A dokumentum-hozzáférés biztonságos vezérlése

Egy weboldal-chatbot képes összevonni a válaszokat a GYIK-oldalakból, termékdokumentációkból és belső tudásforrásokból. Ez rendkívül hasznos – mindaddig, amíg ugyanaz a tudásbázis nem tartalmaz olyan tartalmat, amely nem mindenkinek szól. Ilyenkor nem csupán a nyelvi modell minősége dönt a biztonságos válaszról, hanem az azt megelőző keresési (retrieval) lépés: Mely dokumentumokat láthat egyáltalán ez a konkrét kérés?

A RAG-jogosultságok az ellenőrzött személyazonosságokat, szerepköröket vagy csoportokat kapcsolják össze a dokumentumok metaadataival. A chatbot csak a már megszűrt forrásokat kapja meg. A cél szándékosan szűk: Nem a modellnek kell a prompt alapján eldöntenie, hogy valami bizalmas-e. Az alkalmazás korlátozza a megengedett kontextust, dokumentálja ezt a döntést, és bizonytalanság esetén biztonságos tartalék megoldást (fallback) választ.

Miért nem helyettesítik a prompt-szabályok a hozzáférés-vezérlést

Egy olyan rendszerutasítás, mint a „Ne adj ki belső információkat”, hasznos, de nem jelent jogosultsági réteget. Ha egy nem megengedett dokumentum már bejut a kontextusba, a válasz összefoglalhatja, közvetve felfedheti vagy rákérdezésre rekonstruálhatja azt. A utólagos szövegellenőrzés is túl késő, és hajlamos a hibákra. A biztonság ezért a generálás előtt, ideális esetben a találatok rangsorolása előtt kezdődik.

Az Azure AI Search szűrőmintaként írja le a Security Trimming módszert: A dokumentumok személyazonossági vagy csoportértékeket hordoznak; a lekérdezés csak a kérelmező személy entitásait (principals) tartalmazza. Az Amazon Bedrock hasonlóan rámutat arra, hogy az ACL-tudatos keresési szűrők nem helyettesítik az hitelesítést. Az alkalmazásnak először saját magának kell megbízhatóan ellenőriznie a személyazonosságot, és csak ellenőrzött kontextust szabad átadnia.

Egy ellenálló megoldás négy építőköve

1. A személyazonosság és a munkamenet (session) szerveroldali ellenőrzése

A nyilvános ablakos chatnek általában nincsenek dokumentumjogai. Csak nyilvános forrásokhoz férhet hozzá. Egy ügyfélportál vagy munkatársi terület esetében viszont a személyt a meglévő bejelentkezés alapján azonosítják. Olvassa ki a szerepkört, a szervezetet és a releváns csoportokat szerveroldalon a munkamenetből vagy egy aláírt tokenből. Soha ne hagyatkozzon a böngésző által szabadon küldött mezőkre, mint például a role=admin, vagy olyan chat-üzenetre, amely egy csoporthoz való tartozást állít.

2. Jogosultsági metaadatok karbantartása minden forrásnál

Minden szövegrészletnek (chunk) a szöveg, az URL és a frissítési dátum mellett nyomon követhető hozzáférési információkra van szüksége: például audience=public, egy bérlői azonosító (tenant ID), az engedélyezett csoportok listája vagy egy osztályozás. Ezeknek a metaadatoknak ugyanabból a szakmai forrásból kell származniuk, mint a dokumentumjogosultságnak. Egy különálló táblázat, amelyet csak néha frissítenek, veszélyes eltéréseket (drift) eredményez. Új dokumentumok és a csoportjogok változása esetén a metaadat-szinkronizálásnak a közzétételi vagy a beolvasási (crawl) munkafolyamat részét kell képeznie.

3. Szűrés a rangsorolás (ranking) előtt

A lekérdezés egy szűrőt épít fel az ellenőrzött kontextusból. A szemantikai vagy hibrid találatokat csak ezután értékelik. Így egy bizalmas kézikönyv nem nyerhet különösen találó találatként azért, hogy később újra eltávolítsák. Több bérlő (multi-tenant) esetén a bérlői azonosító kötelező szűrő, nem csupán rangsorolási szignál. A személyes vagy különösen védett adatok esetében a közös, csak logikailag megszűrt gyűjtemény helyett saját adattartomány használata javasolt.

4. Források és döntések naplózása

Az ügyfélszolgálathoz és az incidensek elemzéséhez a chat-átiratok önmagukban nem elegendőek. Kérésenként nyomon követhetőnek kell lennie, hogy mely nem érzékeny személyazonossági attribútumokat használták a szűrő kialakításához, mely szűrőosztály volt érvényben, hány találat maradt a szűrés után, és mely források jutottak be ténylegesen a promptba. Ne tároljon felesleges teljes tartalmakat vagy tokeneket. Egy adatminimalizáló audit-esemény megkönnyíti a hibák felderítését anélkül, hogy a monitorozásból második adatszivárgási forrást csinálna.

Gyakorlati folyamat a weboldalakkal foglalkozó csapatok számára

1. Rendeljen minden tudásforrást egy egyértelmű célcsoporthoz: nyilvános, ügyfél, partner, belső csapat vagy egy konkrét bérlő.
2. Határozza meg, hogy mely munkamenet-követelések (session claims) igazolják ezt a célcsoportot. Az azonosító rendszerből származó csoportok megbízhatóbbak, mint a szabadon kitölthető űrlapmezők.
3. Vigye át ezeket a követeléseket szerveroldalon a keresési szűrőbe, és csak a szűrőmezők egy kicsi, ismert halmazát engedélyezze.
4. Minden beolvasáskor (crawl) végezzen összehasonlítást: az új, módosított és eltávolított dokumentumoknak frissített jogosultsági metaadatokra is szükségük van.
5. Csak a megszűrt találatokat adja át a modellnek, egyértelmű utasítással kiegészítve, hogy a hiányzó információkat ne találja ki.
6. Ha nincs találat, ellentmondásosak a források vagy tisztázatlan a jogosultság, irányítsa át a felhasználót egy biztonságos kapcsolatfelvételi útvonalra.

Ez a folyamat kiegészíti a RAG-darabolásról (chunking) szóló cikkünkben leírt struktúrát: a jó szegmensek javítják a találatokat, de nem helyettesítik a hozzáférés-vezérlést. Ugyanígy fontosak maradnak a friss források; az elavult jogosultsági állapot egyszerre minőségi és biztonsági probléma.

Hibás megközelítés: Szűrés a keresés (retrieval) után

Gyakori hibás felépítés: a rendszer lekéri a tíz legjobb találatot, majd ellenőrzi azok címkéit, és eltávolítja a problémás dokumentumokat. Ez elsőre elegendőnek tűnik, de a mellékhatások miatt megbukik. A nem megengedett találat már megjelenhet a naplókban, a gyorsítótárakban (cache) vagy a hibakeresési kimeneten. Ezenkívül annak pontszáma (score) megváltoztatja a többi találat kiválasztását. Jobb megoldás a keresési kérelemben lévő szűrő, amely csak a jogosult dokumentumokat engedi jelöltként szerepelni.

A második hibás megközelítés a szolgáltató ACL-funkciójába vetett vak bizalom. A gyártói dokumentáció egyértelműen kimondhatja, hogy egy szolgáltatás figyelembe veszi az ACL-eket a lekérés során, de maga nem ellenőrzi az átadott felhasználói kontextus valódiságát. Ezért pontosan ellenőrizze: Ki hitelesíti a személyt? Honnan származnak a csoportok? Mikor szinkronizálódnak a jogok a keresési rendszerbe? Mi történik, ha hiányoznak a metaadatok?

Fail closed (zárt alapértelmezés): Mi történjen bizonytalanság esetén?

Hiányzó claim, nem szinkronizált forrás vagy keresési hiba esetén a chatbot ne próbálkozzon szélesebb körű kereséssel. Használjon semleges választ: A kért tartalom a jelenlegi hozzáférési kontextusban nem áll rendelkezésre; egy emberi kapcsolattartó ellenőrizheti a hozzáférést. Ez nem a társalgási UX (Conversational UX) gyengesége, hanem egy őszinte korlát. Az emberi átadásról (Human Handoff) szóló cikk megmutatja, hogyan alakítható ki egy ilyen átadás konkrétan és zsákutcák nélkül.

A nyilvános tartalmakra ugyanez az elv vonatkozik, kisebb léptékben: Ha a források nem elegendőek, a botnak meg kell neveznie a bizonytalanságot, ellenőrzött hivatkozásokat kell felkínálnia, vagy meg kell adnia egy kapcsolatfelvételi módot – ahelyett, hogy hihető részleteket találna ki. Ez csökkenti a hallucinációkat, és megakadályozza, hogy egy feltételezhetően hasznos válasz téves jóváhagyásra buzdítson.

Tesztesetek, amelyeket az élesítés előtt el kell végezni

A jogosultsági teszt nem egy egyszeri adminisztrátori ellenőrzés. Hozzon létre egy kis „Golden Set”-et azonos kérdésekkel több szerepkör számára: vendég, regisztrált ügyfél, jogosult partner, letiltott felhasználó és adminisztrátor. Minden kombinációhoz határozza meg az elvárt forrásokat, nem csak az elvárt válaszszöveget. Tesztelje ezenkívül a csoportváltásokat, a lejárt munkameneteket, a törölt dokumentumokat, a hiányzó ACL-metaadatokat és a keresési szolgáltatás kiesését.

Az eredményekben legalább négy dolgot ellenőrizzen: Egyetlen nem megengedett URL vagy dokumentum-azonosító sem kerül a kontextusba; az engedélyezett források elérhetőek maradnak; a válasz nem említ tartalmakat a kiszűrt dokumentumokból; és a tartalék megoldás érthető marad. Egészítse ki ezeket az ellenőrzéseket a válaszminőség-tesztjeihez, hogy a biztonságot és a szakmai minőséget együtt mérhesse.

Adatvédelem és átláthatóság pragmatikus megvalósítása

A jogosultsági adatok maguk is védendők. A keresési metaadatokban lehetőség szerint stabil technikai azonosítókat használjon az olvasható nevek helyett. Korlátozza az audit-naplókat a célra, az időtartamra és a szükséges attribútumokra. Tájékoztassa a felhasználókat érthetően, ha a chatbot hozzáfér a bejelentkezett területhez, és biztosítson emberi utat a hozzáférési kérdésekhez. Ez a cikk nem helyettesíti az egyéni jogi tanácsadást; a konkrét megőrzési idők és jogalapok a felhasználási kontextustól függenek.

Technikailag kifizetődő az egyértelmű felelősségi kör: A tartalomtulajdonosok (Content Owner) tartják karban a célcsoportokat, az azonosítási csapat (Identity Team) felel a claim-ekért és a munkamenet-ellenőrzésért, a termékcsapat pedig tesztelve tartja a szűrőket és a tartalék megoldásokat. Így a tudásbázis nem válik ellenőrizetlen adatmedencévé, hanem olyan forrás marad, amelynek elérése nyomon követhető.

Ellenőrzőlista az élesítés előtt

• Minden nem nyilvános forrás hozzá van rendelve egy szerepkörhöz, csoporthoz vagy bérlői azonosítóhoz?
• A lekérdezési kontextus egy szerveroldalon ellenőrzött személyazonosságból származik?
• A szűrő a keresés (retrieval) és a rangsorolás előtt fejti ki hatását?
• A jogok változásai és a beolvasások (crawls) együtt szinkronizálódnak?
• Léteznek szerepkör-alapú regressziós tesztek az elvárt forrásokkal?
• Minden ismeretlen vagy hibás állapot biztonságos átadáshoz (handoff) vezet?
• A naplók adatminimalizálóak és elegendőek a hibaelemzéshez?

Összegzés

Egy jó weboldal-chatbot nem válaszol meg minden kérdést mindenki számára. Csak olyan forrásokat mutat meg, amelyek illeszkednek az ellenőrzött hozzáférési kontextushoz, és bizonytalanság esetén szándékosan visszafogott marad. Kezdje egy kis forrásmátrixszal, egy szerveroldali szűrővel és néhány egyértelmű tesztszerepkörrel. Ezt követően lépésről lépésre kiépítheti a jogosultsági metaadatokat, az auditokat és a szinkronizálást – anélkül, hogy a biztonságot a prompt-megfogalmazásokra bízná.

Források

• Microsoft Learn: Security Filter Pattern in Azure AI Search
• Microsoft Learn: Document-level access control in Azure AI Search
• Amazon Bedrock: ACL awareness enablement
• Amazon Bedrock: Document-level access controls