Viešas DI pokalbių botas ir klientų portalas: kaip saugiai atskirti tapatybę ir prieigą prie duomenų

Svetainės viešas pokalbių botas gali atsakinėti į klausimus apie produktus, paaiškinti darbo laiką ar nukreipti į tinkamą paslaugų puslapį. Tačiau kai tik jis klientų portale turi peržiūrėti užsakymo būseną, sutartis, sąskaitas faktūras ar pagalbos užklausas, pasikeičia ne tik turinys. Atsiranda nauja saugumo riba. Autentifikuotas DI pokalbių botas privalo aiškiai atskirti tapatybę, teises, sesiją ir konkretų veiksmą.

Todėl svarbiausias architektūrinis sprendimas yra ne: „Kurį modelį naudosime?“, o: „Kokia informacija ir koks veiksmas yra leidžiami kurioje pasitikėjimo zonoje?“ Atsakius į šį klausimą prieš kuriant užklausų (prompt) dizainą, sumažinama duomenų nutekėjimo, netinkamo paskyrų priskyrimo ir nepageidaujamų veiksmų rizika. Tolesnis vadovas yra techninė ir organizacinė gairė, o ne individuali teisinė konsultacija.

Kodėl viešasis ir autentifikuotas režimai yra dvi skirtingos veikimo būsenos

Viešajame pokalbyje asmuo iš pradžių yra nežinomas. Sistema gali žinoti nebent pokalbio kontekstą, pasirinktą kalbą ir techniškai būtinus sesijos duomenis. Todėl atsakymai turėtų apsiriboti tik patvirtintais, visiems prieinamais šaltiniais. Įvestas el. pašto adresas, užsakymo numeris ar teiginys, pavyzdžiui, „tai mano sutartis“, dar nėra teisių įrodymas.

Klientų portale, priešingai, egzistuoja aktyvi prisijungimo sesija. Tačiau ir čia galioja taisyklė: prisijungimas automatiškai nereiškia, kad leidžiamas kiekvienas išteklius ir kiekvienas veiksmas. OWASP autentifikavimo gairėse skiriama autentifikacija, tapatybės patikrinimas ir sesijų valdymas. Naujausios NIST skaitmeninės tapatybės gairės (4 leidimas) tapatybės patikrinimą, autentifikaciją ir federaciją taip pat laiko atskirais komponentais. Svetainių komandoms iš to išplaukia: pokalbių botas gali naudoti tik tuos pasitikėjimo signalus, kuriuos įrodomai pateikia jį supanti sistema.

Trijų zonų architektūra vietoje visagalio pokalbių boto

Patikimas sprendimas žinias ir įrankius padalija bent į tris zonas:

• Viešoji zona: patvirtintas svetainės turinys, bendra informacija apie produktus, procesai, kontaktai ir neįpareigojanti pagalba.
• Autentifikuota zona: duomenys ir procesai, susieti su prisijungusia paskyra, organizacija, vaidmeniu ar teisėmis.
• Ypač apsaugota zona: jautrūs pakeitimai, išmokėjimai, sutarčių sudarymas, nauji pristatymo adresai, teisių keitimas ar kiti veiksmai, reikalaujantys papildomo patvirtinimo arba žmogaus patikros.

Šios zonos turėtų būti apibrėžtos ne tik sisteminėje užklausoje (system prompt). Jos privalo būti realizuotos duomenų šaltiniuose, API, vaidmenyse, įrankių teisėse ir serverio pusės patikrinimuose. Užklausa gali nukreipti elgseną, tačiau ji nėra prieigos kontrolė. Tą patį galima pasakyti ir apie RAG: paieška viešuose ir privačiuose dokumentuose bendrame, nefiltruotame indekse sukuria be reikalo didelį atakos plotą.

Autentifikavimas nėra autorizavimas

Supaprastintai kalbant, autentifikavimas atsako į klausimą: „Kokia skaitmeninė tapatybė yra prisijungusi?“, o autorizavimas atsako: „Ar ši tapatybė gali skaityti būtent šį objektą arba atlikti šią funkciją?“ Pokalbyje šis skirtumas lengvai susilieja, nes vartotojai objektų numerius formuluoja natūraliai: „Parodyk sąskaitą 4711“ arba „Pakeisk adresą užsakymui 815“.

OWASP rekomendacijose dėl IDOR prevencijos reikalaujama tikrinti teises kiekvienam objektui atskirai, net jei identifikatorius sunku atspėti. Praktiškai tai reiškia: serveris nustato esamą paskyrą iš apsaugotos sesijos ir su kiekviena užklausa tikrina, ar sąskaita, užsakymas ar bilietas priklauso šiai leidžiamai duomenų erdvei. Kalbos modelis neturi priimti laisvai įvesto kliento ar objekto ID kaip pasitikėjimo pagrindo.

Ką gali atsakyti viešas svetainės pokalbių botas

Viešajai sričiai teigiamas sąrašas (leidimų sąrašas) yra geriau nei ilgas draudimų sąrašas. Pavyzdžiui, gali būti leidžiama informacija apie grąžinimo terminus, pristatymo regionus, produktų savybes, instrukcijas, bendrą kainodaros logiką ar kelią iki prisijungimo. Neleidžiama informacija apima individualias užsakymų būsenas, sutarčių detales, asmeninius susitikimus, vidines pastabas arba informaciją apie tai, ar tam tikra paskyra apskritai egzistuoja.

Net iš pažiūros nekalti atsakymai gali atskleisti informaciją. Atsakymas „Su šiuo el. pašto adresu paskyros nėra“ patvirtina patikrinimo bandymą. Neutralus atsakymas, pavyzdžiui, „Prisijunkite prie klientų portalo, kad gautumėte informaciją apie paskyrą“, išlaiko tvirtą ribą. Apsaugai nuo manipuliavimo bandymų papildomai reikalingos apsaugos priemonės, aprašytos straipsnyje Prompt Injection priemonės svetainės pokalbių botams.

Ko papildomai reikia autentifikuotam DI pokalbių botui

Prisijungus asistentas gali daryti daugiau, tačiau tik serverio pusėje apibrėžto konteksto ribose. Prasmingi įvesties duomenys yra vidinė sesijos nuoroda, leidžiama organizacija ar klientas (tenant), vaidmenys ir siaurai apibrėžta funkcijų apimtis. Neapdoroti prisijungimo duomenys, slaptažodžiai, pilni sesijos žetonai (tokens) ar nereikalingi asmens duomenų laukai neturi patekti į modelio kontekstą.

OWASP autorizavimo gairėse rekomenduojama tikrinti teises kiekvienam konkrečiam ištekliui ir funkcijai. Įrankių iškvietimui tai reiškia: ne modelis sprendžia, ar sąskaita faktūra yra matoma. Jis paprašo tarnybos pateikti leidžiamą informaciją, o tarnyba iš naujo patikrina sesiją, vaidmenį, klientų grupę ir objektą. Tada pokalbių botas gauna tik tuos laukus, kurių reikia atsakymui.

Praktiškas duomenų ir įrankių ribų nustatymas

Skaitymas ir rašymas turėtų būti atskiri įrankiai. Įrankis „valdyti kliento paskyrą“ yra per platus. Geriau naudoti mažas funkcijas, pavyzdžiui, „išvardyti savo aktyvius užsakymus“, „perskaityti leidžiamo užsakymo būseną“ arba „paruošti pagalbos užklausą“. Kiekviena funkcija gauna minimalią įvesties schemą, serverio pusės teisių patikrinimą, aiškius klaidos atvejus ir apribotą išvestį.

RAG sistemai rekomenduojama ta pati logika: viešieji šaltiniai patenka į viešą paieškos erdvę, o su paskyra susiję dokumentai – į paieškos erdvę, filtruojamą pagal klientų grupę ir vaidmenį. Filtrai formuojami serverio pusėje iš sesijos duomenų, o ne iš laisvai suformuluotų pokalbio duomenų. Šaltinių, vaidmenų ir patvirtinimų pakeitimai turi būti atliekami pagal dokumentuotą procedūrą; pavyzdį rasite straipsnyje apie turinio valdymą ir pokyčių kontrolę (Content Governance).

Sesijos pabaigos, atsijungimo ir bendrinamų įrenginių įvertinimas

Pokalbių sąsaja neturi sudaryti įspūdžio, kad teisės galioja neribotą laiką. OWASP sesijų valdymo gairėse sesija apibūdinama kaip ryšys tarp autentifikavimo, HTTP srauto ir prieigos kontrolės. Pasibaigus sesijai, kitas privataus duomenų gavimo bandymas turi saugiai atmesti užklausą. Senas atsakymas matomoje istorijoje neturi būti interpretuojamas kaip nauja teisė.

Komandos taip pat turėtų išbandyti atsijungimą, paskyros keitimą, vaidmens pakeitimą ir bendrai naudojamus įrenginius. Privati pokalbių istorija pakeitus paskyrą neturi pasirodyti kitam vartotojui. Pasibaigus sesijai, asistentas turėtų aiškiai nukreipti iš naujo prisijungti, nepakartodamas jautrių detalių iš ankstesnės sesijos. Registravimui ir analizei galioja duomenų mažinimo (mažesnio kiekio) principas; straipsnis apie duomenis tausojančią pokalbių botų analitiką parodo tinkamas įvykių ir saugojimo ribas.

Jautriems veiksmams reikalingas atskiras patvirtinimas

Prisijungimo prie portalo ne visada pakanka kiekvienam veiksmui. Jei pokalbių botas keičia pristatymo adresą, tvirtina sutartį ar inicijuoja mokėjimą, sistema turėtų pareikalauti aiškiai atpažįstamo, su konkrečiu veiksmu susijusio patvirtinimo. OWASP transakcijų autorizavimo gairėse atskiriamas prisijungimas ir transakcijos patvirtinimas bei reikalaujama serverio pusės kontrolės bei esminių transakcijos duomenų patikrinimo.

Saugus šablonas yra toks: pokalbių botas surenka pageidavimą, parodo aiškią santrauką, portalas patikrina esamas teises ir, jei reikia, pareikalauja pakartotinio autentifikavimo arba antrojo faktoriaus. Tik po to serverio tarnyba atlieka tiksliai patvirtintą veiksmą. Jei pasikeičia tikslas, suma ar kiti esminiai duomenys, ankstesnis patvirtinimas anuliuojamas.

Pavyzdys: grąžinimas be duomenų nutekėjimo

Anoniminis asmuo klausia: „Ar galiu grąžinti savo užsakymą?“ Viešas pokalbių botas paaiškina bendrą grąžinimo logiką ir pateikia nuorodą į portalą. Jis neprašo pilno adreso ar mokėjimo duomenų. Prisijungus portalo pokalbių botas per skaitymo įrankį gali pateikti paties vartotojo užsakymus, kuriuos galima grąžinti. Kai asmuo pasirenka užsakymą, serveris dar kartą patikrina teises į objektą ir galiojančias taisykles.

Faktiniam grąžinimui atskiras veiksmų įrankis sugeneruoja santrauką. Vartotojas portalo sąsajoje patvirtina prekes ir paėmimo parinktį. Jei patikra nepavyksta, pokalbių botas nenurodo vidinių rizikos signalų, o pasiūlo saugų kitą žingsnį. Jei reikalingas žmogaus įsikišimas, atliekamas kontroliuojamas perdavimas žmogui (Human Handoff) pateikiant tik būtiną, patvirtintą kontekstą.

Testavimo matrica prieš sistemos paleidimą (Go-live)

Testavimo matrica turėtų tikrinti ne tik sėkmingus scenarijus (happy paths). Naudokite bent dvi paskyras su panašiais vaidmenimis bei atskirais duomenimis ir išbandykite šiuos atvejus:

• Anoniminis užklausimas dėl bendros informacijos ir dėl privačių paskyros duomenų.
• Prisijungusi paskyra A perskaito savo objektą, o tada bando pasiekti paskyros B objekto identifikatorių.
• Pasibaigusi sesija, atsijungimas, paskyros keitimas ir teisių atėmimas vykstant pokalbiui.
• Kalbos pakeitimas proceso viduryje, nepakeičiant duomenų erdvės ar teisių.
• Prompt Injection vartotojo įvestyse ir gautuose dokumentuose.
• Skaitymo įrankio gedimas, laiko limitas (timeout) ir prieštaringi galinės sistemos (backend) duomenys.
• Rašymo veiksmas be patvirtinimo, su pakeistais duomenimis ir su pasibaigusiu patvirtinimo galiojimu.
• Perdavimas žmogui pateikiant minimalų, aiškų pokalbio kontekstą.

Laukiami rezultatai turėtų būti apibrėžti iš anksto: koks atsakymas yra leidžiamas viešai? Kokia HTTP klaida susidaro serverio pusėje? Kokia informacija gali būti matoma pokalbyje? Koks įvykis užregistruojamas be konfidencialaus turinio? Suplanuotas riboto veikimo režimas („Degraded Mode“) padeda, kai sutrinka tapatybės ar galinės sistemos (backend) paslaugos; tam skirtas atskiras incidentų valdymo ir atstatymo (Rollback) vadovas.

Patikimos portalo ribos kontrolinis sąrašas

• Dokumentuoti viešąją, autentifikuotą ir ypač apsaugotą zonas.
• Atskirai sumodeliuoti autentifikavimą, autorizavimą ir transakcijų patvirtinimą.
• Nustatyti paskyrą ir klientų grupę (tenant) iš saugios sesijos.
• Tikrinti objekto teises serverio pusėje atliekant kiekvieną skaitymą ir rašymą.
• Techniškai atskirti ir filtruoti viešus bei privačius RAG šaltinius.
• Atskirtai apibrėžti įrankių teises iki minimumo; atskirti skaitymą ir rašymą.
• Atsižvelgti į sesijos pabaigą, atsijungimą, paskyros keitimą ir vaidmenų pokyčius pokalbių bote.
• Aiškliai apibendrinti jautrius veiksmus ir reikalauti tikslingo jų patvirtinimo.
• Perdavimą žmogui ir registravimą apriboti tik būtinais duomenimis.
• Atlikti atkuriamus horizontalių prieigos bandymų testus naudojant bent dvi paskyras.

Autentifikuotas DI pokalbių botas netampa saugus vien dėl to, kad atsiranda už prisijungimo lango. Saugumas atsiranda tada, kai kiekviena informacija ir kiekvienas veiksmas turi patikrinamą ribą. Todėl pradėkite nuo zonų žemėlapio ir testavimo matricos, prieš prijungdami privačius duomenų šaltinius ar rašymo įrankius. Taip viešas pokalbių botas išliks naudingos informacijos šaltinis, o portalo pokalbių botas – veiksmingas įrankis, nesumaišant abiejų pasitikėjimo sričių.

Šaltiniai

• NIST SP 800-63, Revision 4: Digital Identity Guidelines
• OWASP Authentication Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP Session Management Cheat Sheet
• OWASP Insecure Direct Object Reference Prevention Cheat Sheet
• OWASP Transaction Authorization Cheat Sheet