RAG-õigused veebilehe juturobotitele: Dokumentide juurdepääsu turvaline juhtimine

Veebilehe juturobot saab koondada vastuseid KKK-lehtedelt, tootedokumentidest ja sisemistest teadmusallikatest. See on kasulik – seni, kuni sama teadmusbaas sisaldab sisu, mis pole mõeldud igaühele. Sellisel juhul ei otsusta turvalise vastuse üle ainult keelemudeli kvaliteet, vaid sellele eelnev otsingusamm (retrieval): milliseid dokumente tohib see konkreetne päring üldse näha?

RAG-õigused ühendavad kinnitatud isikusamasused, rollid või rühmad dokumentide metsaandmetega. Juturobot saab ainult juba filtreeritud allikad. Eesmärk on teadlikult kitsas: mudel ei peaks prompti põhjal otsustama, kas miski on konfidentsiaalne. Rakendus piirab lubatud konteksti, dokumenteerib selle otsuse ja valib ebamäärasuse korral turvalise varulahenduse (fallback).

Miks prompti reeglid ei asenda juurdepääsukontrolli

Süsteemijuhis nagu „Ära väljasta siseinfot“ on mõistlik, kuid see ei ole õiguste kiht. Kui lubamatu dokument jõuab juba konteksti, võib vastus seda kokku võtta, kaudselt paljastada või lisaküsimuse peale rekonstrueerida. Ka hilisem tekstikontroll on liiga hiline ja veaaldis. Turvalisus algab seetõttu enne genereerimist ja ideaalis enne tulemuste järjestamist.

Azure AI Search kirjeldab turvalisuse kärpimist (Security Trimming) filtreerimismustrina: dokumendid kannavad isikusamasuse või rühma väärtusi; päring sisaldab ainult päringut tegeva isiku subjekte (principals). Amazon Bedrock viitab sarnaselt sellele, et ACL-iteadlikud otsingufiltrid ei asenda autentimist. Teie rakendus peab isikusamasust kõigepealt ise usaldusväärselt kontrollima ja edastama ainult kinnitatud konteksti.

Vastupidava lahenduse neli ehituskivi

1. Isikusamasuse ja seansi verifitseerimine serveri poolel

Avalikul vestlusaknal ei ole tavaliselt dokumendiõigusi. See tohib juurde pääseda ainult avalikele allikatele. Kliendiportaali või töötajate ala puhul tuvastatakse isik aga olemasoleva sisselogimise kaudu. Lugege roll, organisatsioon ja asjakohased rühmad serveri poolel seansist või allkirjastatud pääsutõendist (token). Ärge kunagi lootke brauseri poolt vabalt saadetud väljale nagu role=admin või vestlussõnumile, mis väidab kuuluvust.

2. Õiguste metsaandmete haldamine iga allikaga

Iga lõik (chunk) vajab lisaks tekstile, URL-ile ja värskuse kuupäevale arusaadavat juurdepääsuinfot: näiteks audience=public, rentniku ID-d (tenant ID), lubatud rühmade loendit või klassifikatsiooni. Need metsaandmed peavad pärinema samast sisulisest allikast kust dokumendiõigusedki. Eraldi tabel, mida hooldatakse vaid aeg-ajalt, tekitab ohtlikku nihket. Uute dokumentide ja rühmaõiguste muudatuste korral kuulub metsaandmete süncroniseerimine seepärast avaldamis- või indekseerimisvoogu (crawl-workflow).

3. Filtreerimine enne järjestamist

Päring moodustab filtri kinnitatud kontekstist. Alles pärast seda hinnatakse semantilisi või hübriidseid vasteid. Nii ei saa konfidentsiaalne käsiraamat võita eriti sobiva vastena, et seda hiljem uuesti eemaldada. Mitme rentniku (multi-tenant) puhul on rentniku ID kohustuslik filter, mitte pelgalt järjestussignaal. Isikuandmete või eriti kaitstud andmete puhul on lisaks soovitatav kasutada eraldi andmeala ühise, ainult loogiliselt filtreeritud kollektsiooni asemel.

4. Allikate ja otsuste logimine

Kasutajatugede ja intsidentide analüüsi jaoks ei piisa ainult vestluste transkriptidest. Päringu kohta peaks olema jälgitav, milliseid mittetundlikke isikusamasuse atribuute filtri loomiseks kasutati, milline filtriklass kehtis, mitu vastet jäi pärast filtrit järele ja millised allikad tegelikult prompti jõudsid. Ärge salvestage tarbetut täissisu ega tõendeid. Andmesäästlik auditisündmus teeb vead leitavaks ilma monitooringut teiseks teadmuslekkeks muutmata.

Praktiline töövoog veebitiimidele

1. Määrake iga teadmusallikas selgele sihtrühmale: avalik, klient, partner, sise-tiim või konkreetne rentnik.
2. Defineerige, millised seansi väited (claims) seda sihtrühma tõendavad. Isikusamasuse süsteemi rühmad on usaldusväärsemad kui vabalt valitavad vormisisestused.
3. Võtke need väited serveri poolel üle otsingufiltrisse ja lubage ainult väikest tuntud hulka filtrivälju.
4. Viige iga indekseerimise (crawl) ajal läbi võrdlus: uued, muudetud ja eemaldatud dokumendid vajavad ka uuendatud õiguste metsaandmeid.
5. Andke mudelile ainult filtreeritud vasted koos selge juhisega puuduvat infot mitte ära arvata.
6. Tulemuste puudumisel, vastuoluliste allikate või ebaselgete õiguste korral suunake kasutaja turvalisele kontaktikanalile.

See töövoog täiendab meie artiklis RAG-chunking kirjeldatud struktureerimist: head lõigud parandavad tulemusi, kuid ei asenda juurdepääsukontrolli. Samamoodi jäävad oluliseks värsked allikad; aegunud õiguste seis on korraga nii kvaliteedi- kui ka turvaprobleem.

Vea muster: filtreerimine pärast otsingut

Sagedane vale arhitektuurimuster on järgmine: süsteem pärib kümme parimat vastet, kontrollib seejärel nende silte ja eemaldab probleemse dokumendi. See tundub esialgu piisav, kuid ebaõnnestub kõrvalmõjude tõttu. Lubamatu vaste võib ilmuda juba logidesse, puhvritesse või debug-väljundisse. Lisaks muudab selle skoor ülejäänud tulemuste valikut. Parem on filter otsingupäringus (retrieval-request), mis lubab kandidaatideks ainult õigustega dokumente.

Teine vea muster on teenusepakkuja ACL-funktsiooni pime usaldamine. Tootja dokumentatsioon võib selgelt öelda, et teenus arvestab päringul ACL-e, kuid ei kontrolli ise edastatud kasutajakonteksti ehtsust. Kontrollige seepärast täpselt: kes autendib isiku? Kust tulevad rühmad? Millal synchroniseeritakse õigused otsingusüsteemi? Mis saab siis, kui metsaandmed puuduvad?

Fail closed: mis peaks juhtuma ebamäärasuse korral

Puuduva väite, synchroniseerimata allika või otsinguvea korral ei tohiks juturobot proovida laiemat otsingut. Kasutage neutraalset vastust: küsitud sisu pole praeguses juurdepääsukontekstis saadaval; inimkontakt saab juurdepääsu kontrollida. See ei ole vestluse kasutajakogemuse (Conversational UX) nõrkus, vaid aus piir. Artikkel inimoperaatorile üleandmise (Human Handoff) kohta näitab, kuidas sellist üleandmist konkreetselt ja umbtänavata kujundada.

Avaliku sisu puhul kehtib sama idee väiksemas skaalas: kui allikatest ei piisa, peaks robot nimetama ebamäärasust, pakkuma kinnitatud linke või esitama kontaktikanali – selle asemel et väljamõelda usutavaid detaile. See vähendab hallutsinatsioone ja hoiab ära olukorra, kus näiliselt abivalmis vastus kutsub üles valeks kinnitamiseks.

Testjuhtumid enne kasutuselevõttu

Õiguste testimine ei ole ühekordne administraatori kontroll. Looge väike etalonkomplekt (Golden Set) identsete küsimustega mitme rolli jaoks: külaline, registreeritud klient, volitatud partner, blokeeritud kasutaja ja administraator. Määratlege iga kombinatsiooni jaoks oodatavad allikad, mitte ainult oodatav vastuse tekst. Testige lisaks rühmavahetusi, aegunud seansse, kustutatud dokumente, puuduvaid ACL-metsaandmeid ja otsinguteenuse katkemist.

Kontrollige tulemustes vähemalt nelja asja: ükski lubamatu URL ega dokumendi ID ei jõua konteksti; lubatud allikad jäävad kättesaadavaks; vastus ei nimeta filtreeritud dokumentide sisu; ja varulahendus jääb arusaadavaks. Lisage need kontrollid oma vastusekvaliteedi testidele, et mõõta turvalisust ja sisulist kvaliteeti koos.

Andmekaitse ja läbipaistvuse pragmaatiline rakendamine

Õiguste andmed on ise kaitset vajavad. Kasutage otsingu metsaandmetes selgete nimede asemel võimalusel stabiilseid tehnilisi ID-sid. Piirake auditi logisid eesmärgi, ajavahemiku ja vajalike atribuutidega. Teavitage kasutajaid arusaadavalt, kui juturobot pääseb juurde sisselogitud alale, ja pakkuge inimlikku teed juurdepääsuküsimuste jaoks. See artikkel ei asenda individuaalset õigusnõustamist; konkreetsed säilitustähtajad ja õiguslikud alused sõltuvad kasutuskontekstist.

Tehniliselt tasub ära selge vastutus: sisu omanikud haldavad sihtrühmi, isikusamasuse tiim vastutab väidete ja seansikontrolli eest, tootetiim hoiab filtrid ja varulahendused testituna. Nii ei muutu teadmusbaas kontrollimatuks andmebasseiniks, vaid allikaks, mille ulatus jääb jälgitavaks.

Kontrollnimekiri enne avaldamist

• Kas iga mitteavalik allikas on määratud rollile, rühmale või rentniku ID-le?
• Kas päringukontekst pärineb serveri poolel verifitseeritud isikusamasusest?
• Kas filter toimib enne otsingut ja järjestamist?
• Kas õiguste muudatused ja indekseerimised synchroniseeritakse koos?
• Kas on olemas rollipõhised regressioonitestid koos oodatavate allikatega?
• Kas iga tundmatu või vigane olek viib turvalise üleandmiseni?
• Kas logid on andmesäästlikud ja veaanalüüsiks piisavad?

Kokkuvõte

Hea veebilehe juturobot ei vasta igale küsimusele igaühe jaoks. See näitab ainult allikaid, mis sobivad kinnitatud juurdepääsukontekstiga, ja jääb ebamäärasuse korral teadlikult tagasihoidlikuks. Alustage väikese allikamaatriksi, serveripoolse filtri ja mõne selge testrolliga. Pärast seda saate õiguste metsaandmeid, auditeid ja synchroniseerimist samm-sammult laiendada – ilma turvalisust prompti sõnastustele edasi volitamata.

Allikad

• 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