RAG leidimai svetainės pokalbių botams: saugus dokumentų prieigos valdymas

Svetainės pokalbių botas gali sujungti atsakymus iš DUK puslapių, produkto dokumentacijos ir vidinių žinių šaltinių. Tai naudinga – kol toje pačioje žinių bazėje nėra turinio, kuris nėra skirtas kiekvienam asmeniui. Tuomet saugų atsakymą lemia ne vien kalbos modelio kokybė, bet ir prieš tai atliekamas paieškos (retrieval) žingsnis: kokius dokumentus ši konkreti užklausa apskritai turi teisę matyti?

RAG leidimai susieja patvirtintas tapatybes, vaidmenis ar grupes su dokumentų metaduomenimis. Pokalbių botas gauna tik jau išfiltruotus šaltinius. Tikslas yra sąmoningai siauras: ne modelis pagal užklausą (prompt) turi spręsti, ar kažkas yra konfidencialu. Programa apriboja leidžiamą kontekstą, užregistruoja šį sprendimą ir, kilus neaiškumams, pasirenka saugų atsarginį scenarijų (fallback).

Kodėl prompt taisyklės nepakeičia prieigos kontrolės

Sisteminė instrukcija, tokia kaip „Neteik vidinės informacijos“, yra naudinga, tačiau tai nėra prieigos teisių sluoksnis. Jei netinkamas dokumentas jau patenka į kontekstą, atsakymas gali jį apibendrinti, netiesiogiai atskleisti arba atkurti pagal papildomą užklausą. Vėlesnis teksto tikrinimas taip pat yra per vėlyvas ir linkęs į klaidas. Saugumas prasideda prieš generavimą ir, geriausiu atveju, prieš rezultatų rikiavimą.

Azure AI Search aprašo „Security Trimming“ kaip filtravimo šabloną: dokumentai turi tapatybės arba grupių reikšmes; užklausoje yra tik užklausą teikiančio asmens identifikatoriai (principals). Amazon Bedrock panašiai pabrėžia, kad ACL suprantantys paieškos filtrai nepakeičia autentifikavimo. Jūsų programa pati pirmiausia turi patikimai patikrinti tapatybę ir perduoti tik patvirtintą kontekstą.

Keturi tvaraus sprendimo komponentai

1. Tapatybės ir sesijos tikrinimas serverio pusėje

Viešas pokalbių langas paprastai neturi teisių į dokumentus. Jis gali pasiekti tik viešus šaltinius. Tuo tarpu klientų portale arba darbuotojų zonoje asmuo identifikuojamas pagal esamą prisijungimą. Vaidmenį, organizaciją ir susijusias grupes nuskaitykite serverio pusėje iš sesijos arba pasirašyto žetono (token). Niekada nepasitikėkite iš naršyklės laisvai atsiųstu lauku, pavyzdžiui, role=admin, arba pokalbio žinute, kurioje teigiama priklausomybė grupei.

2. Leidimų metaduomenų palaikymas su kiekvienu šaltiniu

Kiekvienam fragmentui (chunk), be teksto, URL ir atnaujinimo datos, reikalinga aiški prieigos informacija: pavyzdžiui, audience=public, kliento ID (tenant ID), leidžiamų grupių sąrašas arba klasifikacija. Šie metaduomenys turi būti gauti iš to paties funkcinio šaltinio kaip ir dokumento teisės. Atskira lentelė, kuri prižiūrima tik retkarčiais, sukelia pavojingą duomenų nesutapimą. Todėl naujų dokumentų atveju ir keičiantis grupių teisėms, metaduomenų sinchronizavimas priklauso publikavimo arba nuskaitymo (crawl) eigai.

3. Filtravimas prieš rangavimą

Užklausa suformuoja filtrą iš patvirtinto konteksto. Tik po to vertinami semantiniai arba hibridiniai rezultatai. Taip konfidencialus vadovas negali tapti ypač tinkančiu rezultatu vien tam, kad vėliau būtų pašalintas. Esant keliems klientams, kliento ID yra privalomas filtras, o ne tik rangavimo signalas. Asmens duomenims arba ypač saugomai informacijai papildomai rekomenduojama atskira duomenų zona, o ne bendra, tik logiškai filtruojama kolekcija.

4. Šaltinių ir sprendimų registravimas žurnale

Pagalbai ir incidentų analizei vien pokalbių transkripcijų neužtenka. Kiekvienai užklausai turėtų būti įmanoma atsekti, kokie neskelbtini tapatybės atributai buvo panaudoti filtrui sudaryti, kokia filtro klasė galiojo, kiek rezultatų liko po filtravimo ir kokie šaltiniai iš tikrųjų pateko į promptą. Nesaugokite nereikalingo pilno turinio ar žetonų. Duomenis taupantys audito įvykiai leidžia rasti klaidas, nepaverčiant stebėsenos sistemos antruoju duomenų nuotėkio šaltiniu.

Praktinė eiga svetainių komandoms

1. Priskirkite kiekvieną žinių šaltinį aiškiai tikslinei grupei: viešai, klientams, partneriams, vidinei komandai arba konkrečiam klientui.
2. Apibrėžkite, kokie sesijos teiginiai (claims) įrodo šią tikslinę grupę. Grupės iš tapatybės valdymo sistemos yra patikimesnės nei laisvai pasirenkami formos įvesties duomenys.
3. Perkelkite šiuos teiginius serverio pusėje į paieškos filtrą ir leiskite tik nedidelį, žinomą filtro laukų kiekį.
4. Kiekvieno nuskaitymo metu atlikite palyginimą: naujiems, pakeistiems ir pašalintiems dokumentams taip pat reikia atnaujintų leidimų metaduomenų.
5. Pateikite modeliui tik išfiltruotus rezultatus ir aiškią instrukciją nespėlioti trūkstamos informacijos.
6. Jei nėra jokių rezultatų, šaltiniai prieštaringi arba leidimai neaiškūs, nukreipkite į saugų kontakto kanalą.

Ši eiga papildo mūsų straipsnyje apie RAG chunking aprašytą struktūrizavimą: geri fragmentai pagerina rezultatus, tačiau nepakeičia prieigos kontrolės. Taip pat išlieka svarbūs švieži šaltiniai; pasenusi leidimų būsena yra tiek kokybės, tiek saugumo problema.

Klaidos pavyzdys: filtravimas po paieškos

Dažna klaidinga architektūra: sistema gauna dešimt geriausių rezultatų, po to patikrina jų žymas ir pašalina probleminius dokumentus. Iš pradžių tai atrodo pakankama, tačiau žlunga dėl šalutinių poveikių. Netinkamas rezultatas jau gali atsirasti žurnaluose (logs), podėlyje (cache) arba derinimo (debug) išvestyje. Be to, jo įvertinimas pakeičia likusių rezultatų pasirinkimą. Geresnis sprendimas – filtras paieškos užklausoje, kuris kaip kandidatus leidžia tik turinčius teises dokumentus.

Antroji klaida – visiškas pasitikėjimas tiekėjo ACL funkcija. Gamintojo dokumentacijoje gali būti aiškiai nurodyta, kad paslauga atsižvelgia į ACL išgaunant duomenis, tačiau pati netikrina perduoto vartotojo konteksto autentiškumo. Todėl patikrinkite tiksliai: kas autentifikuoja asmenį? Iš kur gaunamos grupės? Kada teisės sinchronizuojamos į paieškos sistemą? Kas nutinka, jei trūksta metaduomenų?

Fail closed: kas turi įvykti kilus neaiškumams

Trūkstant teiginio (claim), nesinchronizavus šaltinio arba įvykus paieškos klaidai, pokalbių botas neturėtų bandyti atlikti platesnės paieškos. Naudokite neutralų atsakymą: prašomas turinys dabartiniame prieigos kontekste nepasiekiamas; žmogiškasis kontaktas gali patikrinti prieigą. Tai nėra pokalbio sąsajos (Conversational UX) silpnybė, o sąžininga riba. Straipsnis apie Human Handoff parodo, kaip toks perdavimas gali būti suprojektuotas konkrečiai ir be aklavietės.

Viešam turiniui galioja ta pati idėja mažesniu mastu: jei šaltinių nepakanka, botas turėtų įvardyti neaiškumą, pasiūlyti patikrintas nuorodas arba nurodyti kontakto būdą – užuot išgalvojęs įtikimas detales. Tai sumažina haliucinacijas ir neleidžia neva naudingam atsakymui raginti neteisėtam patvirtinimui.

Testavimo atvejai, būtini prieš įdiegimą

Leidimų testas nėra vienkartinis administratoriaus patikrinimas. Sukurkite nedidelį kontrolinį rinkinį („Golden Set“) su identiškais klausimais keliems vaidmenims: svečiui, registruotam klientui, autorizuotam partneriui, blokuotam vartotojui ir administratoriui. Kiekvienai kombinacijai apibrėžkite tikėtinus šaltinius, o ne tik tikėtiną atsakymo tekstą. Taip pat patikrinkite grupių pasikeitimus, pasibaigusias sesijas, ištrintus dokumentus, trūkstamus ACL metaduomenis ir paieškos paslaugos sutrikimus.

Rezultatuose patikrinkite bent keturis dalykus: joks netinkamas URL ar dokumento ID nepateko į kontekstą; leidžiami šaltiniai lieka pasiekiami; atsakyme neminėjamas turinys iš išfiltruotų dokumentų; ir atsarginis scenarijus išlieka suprantamas. Papildykite šiais patikrinimais savo atsakymų kokybės testus, kad saugumas ir funkcinė kokybė būtų matuojami kartu.

Pragmatiškas duomenų apsaugos ir skaidrumo įgyvendinimas

Patys leidimų duomenys yra saugotini. Paieškos metaduomenyse naudokite kuo stabilesnius techninius ID, o ne atvirus vardus. Apribokite audito žurnalus iki tikslo, laikotarpio ir būtinų atributų. Suprantamai informuokite vartotojus, kai pokalbių botas pasiekia prisijungimo zoną, ir pasiūlykite žmogiškąjį būdą prieigos klausimams spęsti. Šis straipsnis nepakeičia individualios teisinės konsultacijos; konkretūs saugojimo terminai ir teisiniai pagrindai priklauso nuo naudojimo konteksto.

Techniškai verta turėti aiškią atsakomybę: turinio savininkai prižiūri tikslines grupes, tapatybės komanda atsakinga už teiginius (claims) ir sesijos tikrinimą, produkto komanda palaiko išbandytus filtrus ir atsarginius scenarijus. Taip žinių bazė netampa nekontroliuojamu duomenų telkiniu, o lieka šaltiniu, kurio pasiekiamumas išlieka atsekamas.

Kontrolinis sąrašas prieš paleidimą

• Ar kiekvienas neviešas šaltinis priskirtas vaidmeniui, grupei arba kliento ID (tenant ID)?
• Ar užklausos kontekstas gautas iš serverio pusėje patvirtintos tapatybės?
• Ar filtras veikia prieš paiešką (retrieval) ir rangavimą?
• Ar teisių pakeitimai ir nuskaitymai (crawls) sinchronizuojami kartu?
• Ar yra vaidmenimis pagrįsti regresiniai testai su tikėtinais šaltiniais?
• Ar kiekviena nežinoma arba klaidinga būsena veda į saugų perdavimą (handoff)?
• Ar žurnalai taupo duomenis ir yra pakankami klaidų analizei?

Išvada

Geras svetainės pokalbių botas neatsako į kiekvieną klausimą kiekvienam asmeniui. Jis rodo tik šaltinius, kurie atitinka patvirtintą prieigos kontekstą, ir, kilus neaiškumams, sąmoningai susilaiko. Pradėkite nuo nedidelės šaltinių matricos, serverio pusės filtro ir kelių aiškių testavimo vaidmenų. Po to galite palaipsniui plėtoti leidimų metaduomenis, auditą ir sinchronizavimą – neperkeliant saugumo ant promptų formuluočių.

Šaltiniai

• 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