RAG atļaujas tīmekļa vietņu tērzēšanas robotiem: droša piekļuves vadība dokumentiem

Tīmekļa vietnes tērzēšanas robots var apkopot atbildes no BUJ lapām, produktu dokumentiem un iekšējiem zināšanu avotiem. Tas ir ļoti noderīgi — līdz brīdim, kad tajā pašā zināšanu bāzē parādās saturs, kas nav paredzēts katram lietotājam. Tādā gadījumā drošu atbildi nenoteic tikai valodas modeļa kvalitāte, bet gan ieguves (retrieval) solis pirms tā: kurus dokumentus šis konkrētais pieprasījums vispār drīkst redzēt?

RAG atļaujas savieno pārbaudītas identitātes, lomas vai grupas ar dokumentu metadatiem. Tērzēšanas robots saņem tikai jau nofiltrētus avotus. Mērķis ir apzināti šaurs: nevis modelim pēc uzvednes (prompt) ir jāizlemj, vai kaut kas ir konfidenciāls, bet gan lietojumprogramma ierobežo atļauto kontekstu, dokumentē šo lēmumu un šaubu gadījumā izvēlas drošu rezerves risinājumu.

Kāpēc uzvedņu noteikumi neaizstāj piekļuves kontroli

Sistēmas norāde, piemēram, „Neizsniedz iekšējo informāciju”, ir lietderīga, taču tā nav piekļuves atļauju slānis. Ja neatļauts dokuments jau ir iekļuvis kontekstā, atbilde var to apkopot, netieši atklāt vai pēc papildu jautājuma rekonstruēt. Arī pēcapstrādes teksta pārbaude ir par vēlu un ar augstu kļūdu risku. Tāpēc drošība sākas pirms ģenerēšanas un ideālā gadījumā — pirms atbilžu rezultātu sarindošanas.

Azure AI Search apraksta drošības apgriešanu (Security Trimming) kā filtra modeli: dokumenti satur identitātes vai grupu vērtības; pieprasījums ietver tikai pieprasītājas personas identitātes subjektus (principals). Amazon Bedrock līdzīgi norāda, ka ACL apzinīgi ieguves filtri neaizstāj autentifikāciju. Jūsu lietojumprogrammai vispirms pašai droši jāpārbauda identitāte un jānodod tikai pārbaudīts konteksts.

Uzticama risinājuma četri pamatpīlāri

1. Verificēt identitāti un sesiju servera pusē

Publiskam tērzēšanas logam parasti nav piekļuves tiesību dokumentiem. Tas drīkst piekļūt tikai publiskiem avotiem. Savukārt klientu portālā vai darbinieku zonā persona tiek identificēta, izmantojot esošo pieteikšanos. Nolasiet lomu, organizāciju un attiecīgās grupas servera pusē no sesijas vai parakstīta žetona (token). Nekad nepaļaujieties uz pārlūkprogrammas brīvi nosūtītu lauku, piemēram, role=admin, vai uz tērzēšanas ziņu, kurā apgalvota piederība kādai grupai.

2. Uzturēt atļauju metadatus katram avotam

Katram fragmentam (chunk) papildus tekstam, URL un atjaunināšanas datumam ir nepieciešama izsekojama piekļuves informācija: piemēram, audience=public, nomnieka ID (tenant ID), atļauto grupu saraksts vai klasifikācija. Šiem metadatiem jānāk no tā paša biznesa avota, no kura nāk dokumentu atļaujas. Atsevišķa izklājlapa, kas tiek atjaunināta tikai reizēm, rada bīstamas atstarpes datu atbilstībā. Tāpēc jaunu dokumentu gadījumā un mainoties grupu tiesībām, metadatu sinhronizācijai jābūt daļai no publicēšanas vai pārlūkošanas (crawl) darba plūsmas.

3. Filtrēt pirms sarindošanas (ranking)

Pieprasījums izveido filtru no pārbaudītā konteksta. Tikai pēc tam tiek novērtēti semantiskie vai hibrīdie atbilstības rezultāti. Tādējādi konfidenciāla rokasgrāmata nevar uzvarēt kā īpaši piemērots rezultāts, lai vēlāk tiktu atkal dzēsta. Ja ir vairāki nomnieki, nomnieka ID ir obligāts filtrs, nevis tikai sarindošanas signāls. Personas datiem vai īpaši aizsargātiem datiem ieteicams izmantot arī atsevišķu datu zonu, nevis kopīgu, tikai loģiski filtrētu kolekciju.

4. Protokolēt avotus un lēmumus

Atbalsta un incidentu analīzei ar tērzēšanas transkriptiem vien nepietiek. Katram pieprasījumam jābūt izsekojamam: kādi nesensitīvi identitātes atribūti tika izmantoti filtra izveidē, kāda filtra klase tika piemērota, cik atbilžu palika pāri pēc filtrēšanas un kuri avoti faktiski nonāca uzvednē. Neuzglabājiet nevajadzīgu pilno saturu vai žetonus. Datu taupīgs audita notikums ļauj atrast kļūdas, nepārvēršot pārraudzību par otro zināšanu noplūdes avotu.

Praktiska darba gaita tīmekļa vietņu komandām

1. Piesaistiet katru zināšanu avotu skaidrai mērķauditorijai: publisks, klients, partneris, iekšējā komanda vai konkrēts nomnieks.
2. Definējiet, kuri sesijas apgalvojumi (claims) pierāda šo mērķauditoriju. Identitātes sistēmas grupas ir uzticamākas par brīvi aizpildāmas formas ievadēm.
3. Pārņemiet šos apgalvojumus servera pusē ieguves filtrā un atļaujiet tikai nelielu, zināmu filtra lauku skaitu.
4. Veiciet salīdzināšanu katras pārlūkošanas (crawl) laikā: jauniem, mainītiem un dzēstiem dokumentiem ir nepieciešami arī atjaunināti atļauju metadati.
5. Sniedziet modelim tikai nofiltrētos rezultātus kopā ar skaidru norādi nemēģināt uzminēt trūkstošo informāciju.
6. Ja nav neviena atbilstoša rezultāta, avoti ir pretrunīgi vai atļauja nav skaidra, novirziet lietotāju uz drošu saziņas kanālu.
7. Šī gaita papildina mūsu rakstā par RAG fragmentēšanu (chunking) aprakstīto strukturēšanu: labi fragmenti uzlabo atbilstību, bet neaizstāj piekļuves kontroli. Tāpat saglabājas avotu svaiguma svarīgums; novecojis atļauju statuss ir gan kvalitātes, gan drošības problēma.

Kļūda arhitektūrā: filtrēšana pēc ieguves (retrieval)

Bieža kļūdaina pieeja ir šāda: sistēma iegūst desmit labākos rezultātus, pēc tam pārbauda to marķējumus un noņem problemātiskos dokumentus. Sākumā tas šķiet pietiekami, taču tas neizdodas blakusparādību dēļ. Neatļautais rezultāts jau var parādīties žurnālos, kešatmiņā vai atkļūdošanas izvadē. Turklāt tā novērtējums (score) maina pārējo rezultātu izvēli. Labāks risinājums ir filtrs pašā ieguves pieprasījumā, kas kā kandidātus pieļauj tikai atļautos dokumentus.

Otrā kļūda ir akla paļaušanās uz nodrošinātāja ACL funkciju. Izstrādātāja dokumentācijā var būt skaidri norādīts, ka pakalpojums ņem vērā ACL ieguves laikā, taču pats nepārbauda nodotā lietotāja konteksta īstumu. Tāpēc pārbaudiet precīzi: kas autentificē personu? No kurienes nāk grupas? Kad tiesības tiek sinhronizētas ieguves sistēmā? Kas notiek, ja trūkst metadatu?

Noklusējuma aizvēršana (Fail closed): ko darīt šaubu gadījumā

Ja trūkst sesijas apgalvojuma (claim), avots nav sinhronizēts vai radusies ieguves kļūda, tērzēšanas robotam nevajadzētu mēģināt veikt plašāku meklēšanu. Izmantojiet neitrālu atbildi: pieprasītais saturs pašreizējā piekļuves kontekstā nav pieejams; darbinieks var pārbaudīt piekļuvi. Tā nav sarunvalodas UX vājība, bet gan godīga robeža. Raksts par nodošanu cilvēkam (Human Handoff) parāda, kā šādu pāreju noformēt konkrēti un bez bezizejas situācijām.

Publiskajam saturam gaita ir līdzīga, tikai mazākā mērogā: ja avotu bāze nav pietiekama, robotam vajadzētu norādīt uz nenoteiktību, piedāvāt pārbaudītas saites vai saziņas ceļu — tā vietā, lai izdomātu ticamas detaļas. Tas samazina halucinācijas un nepieļauj situāciju, kurā domājamā atbilde aicina veikt nepareizu piekļuves apstiprināšanu.

Testēšanas gadījumi, kas jāveic pirms ieviešanas

Atļauju tests nav vienreizēja administratora pārbaude. Izveidojiet nelielu pamatkopu (Golden Set) ar identiskiem jautājumiem vairākām lomām: viesim, reģistrētam klientam, pilnvarotam partnerim, bloķētam lietotājam un administratoram. Katrai kombinācijai definējiet paredzamos avotus, nevis tikai gaidāmo atbildes tekstu. Testējiet arī grupu maiņu, beigušās sesijas, dzēstus dokumentus, trūkstošos ACL metadatus un ieguves pakalpojuma atteici.

Rezultātos pārbaudiet vismaz četras lietas: kontekstā nenonāk neviens neatļauts URL vai dokumenta ID; atļautie avoti paliek pieejami; atbilde nesatur saturu no nofiltrētajiem dokumentiem; un rezerves risinājums paliek saprotams. Pievienojiet šīs pārbaudes saviem atbilžu kvalitātes testiem, lai drošība un funkcionālā kvalitāte tiktu mērīta kopā.

Datu aizsardzības un caurskatāmības pragmatiska īstenošana

Atļauju dati paši par sevi ir aizsargājami. Ieguves metadatos skaidra teksta nosaukumu vietā izmantojiet pēc iespējas stabilus tehniskos ID. Ierobežojiet audita žurnālus līdz mērķim, laika periodam un nepieciešamajiem atribūtiem. Saprotami informējiet lietotājus, kad tērzēšanas robots piekļūst autorizētajai zonai, un nodrošiniet saziņas iespēju ar cilvēku jautājumiem par piekļuvi. Šis raksts neaizstāj individuālas juridiskās konsultācijas; konkrēti glabāšanas termiņi un juridiskie pamati ir atkarīgi no izmantošanas konteksta.

Tehniski ir vērts noteikt skaidru atbildību: satura īpašnieki uztur mērķauditorijas, identitātes komanda ir atbildīga par apgalvojumiem un sesiju pārbaudi, produkta komanda uztur pārbaudītus filtrus un rezerves mehānismus. Tādējādi zināšanu bāze kļūst nevis par nekontrolētu datu pūlu, bet gan par avotu, kura sniedzamība paliek izsekojama.

Pārbaudes saraksts pirms palaišanas

• Vai katrs nepubliskais avots ir piesaistīts lomiņai, grupai vai nomnieka ID?
• Vai pieprasījuma konteksts ir cēlies no servera pusē pārbaudītas identitātes?
• Vai filtrs darbojas pirms ieguves un sarindošanas?
• Vai tiesību izmaiņas un pārlūkošana (crawl) tiek sinhronizēti kopā?
• Vai pastāv uz lomām balstīti regresijas testi ar paredzamajiem avotiem?
• Vai katrs nezināms vai kļūdains stāvoklis nodrošina drošu nodošanu cilvēkam (handoff)?
• Vai žurnāli ir datu taupīgi un pietiekami kļūdu analīzei?

Secinājums

Labs tīmekļa vietnes tērzēšanas robots neatbild uz katru jautājumu katrai personai. Tas rodot rāda tikai tos avotus, kas atbilst pārbaudītajam piekļuves kontekstam, un šaubu gadījumā apzināti atturas no minējumiem. Sāciet ar nelielu avotu matricu, servera puses filtru un dažām skaidrām testa lomām. Pēc tam varat pakāpeniski paplašināt atļauju metadatus, auditus un sinhronizāciju — neuzticot drošību tikai uzvednes formulējumiem.

Avoti

• 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