Javni AI chatbot vs. uporabniški portal: Varno ločevanje identitete in dostopa do podatkov

Chatbot na javnem spletnem mestu lahko odgovarja na vprašanja o izdelkih, pojasnjuje delovni čas ali usmerja na ustrezno storitveno stran. Ko pa mora na uporabniškem portalu vpogledati v status naročila, pogodbe, račune ali podporne primere, se ne spremeni le vsebina. Nastane nova varnostna meja. Avtenticiran AI chatbot mora čisto ločiti identiteto, dovoljenja, sejo in konkretno dejanje.

Najpomembnejša arhitekturna odločitev zato ni: „Kateri model uporabiti?“, temveč: „Katere informacije in katera dejanja so dovoljena v posameznem območju zaupanja?“ Kdor na to vprašanje odgovori pred oblikovanjem pozivov, zmanjša tveganje za uhajanje podatkov, napačne dodelitve računov in neželena dejanja. Naslednji vodnik služi kot tehnična in organizacijska usmeritev ter ne predstavlja individualnega pravnega svetovanja.

Zakaj sta javni in avtenticirani način dve različni vrsti delovanja

V javnem klepetu je oseba sprva neznana. Sistem lahko kvečjemu pozna kontekst pogovora, izbrani jezik in tehnično potrebne podatke o seji. Odgovori bi se zato morali omejevati na odobrene, splošno dostopne vire. Vneseni e-poštni naslov, številka naročila ali izjava, kot je „To je moja pogodba“, še ne predstavljajo dokazila o pravicah dostopa.

Na uporabniškem portalu po drugi strani obstaja prijavljena seja. Vendar tudi tam velja: prijava ne pomeni samodejno, da sta dovoljena vsak vir in vsako dejanje. OWASP Authentication Cheat Sheet razlikuje med avtentikacijo, preverjanjem identitete in upravljanjem seje. Trenutne smernice NIST Digital Identity Guidelines, Revision 4 prav tako obravnavajo preverjanje identitete, avtentikacijo in federacijo kot samostojne gradnike. Za ekipo spletnega mesta iz tega sledi: klepet sme uporabljati le tiste signale zaupanja, ki jih spremljajoči sistem dokazljivo zagotavlja.

Tri območja namesto vsemočnega chatbota

Robustna rešitev razdeli znanje in orodja na vsaj tri območja:

• Javno območje: odobrena vsebina spletnega mesta, splošne informacije o izdelkih, postopkih, kontaktih in neobvezujoča pomoč.
• Avtenticirano območje: podatki in postopki, vezani na prijavljeni račun, organizacijo, vlogo ali dovoljenje.
• Posebej zaščiteno območje: občutljive spremembe, izplačila, sklenitve pogodb, novi naslovi za dostavo, spremembe pravic ali druga dejanja, ki zahtevajo dodatno potrditev ali človeško preverjanje.

Ta območja ne bi smela obstajati le v sistemskem pozivu. Biti morajo preslikana v podatkovne vire, API-je, vloge, dovoljenja orodij in strežniška preverjanja. Poziv lahko usmerja vedenje, vendar ni nadzor dostopa. Enako velja za RAG: iskanje po javnih in zasebnih dokumentih v skupnem, nefiltriranem indeksu ustvarja po nepotrebnem široko napadalno površino.

Avtentikacija ni avtorizacija

Poenostavljeno povedano avtentikacija odgovarja na vprašanje: „Katera digitalna identiteta je prijavljena?“ Avtorizacija pa odgovarja: „Ali sme ta identiteta prebrati natanko ta objekt ali izvesti to funkcijo?“ V klepetu se ta razlika hitro zamegli, saj uporabniki naravno navajajo številke objektov: „Pokaži mi račun 4711“ ali „Spremeni naslov za naročilo 815“.

Priporočila OWASP proti ranljivosti IDOR zahtevajo preverjanje dovoljenj na ravni posameznega objekta, tudi če je identifikatorje težko uganiti. V praksi to pomeni: strežnik izpelje trenutni račun iz zaščitene seje in ob vsaki zahtevi preveri, ali račun, naročilo ali zahtevek sodi v ta dovoljeni podatkovni prostor. Jezikovni model ne sme uporabiti prosto vnesenega ID-ja stranke ali objekta kot sidra zaupanja.

Kaj lahko odgovori javni spletni klepet

Za javno območje je seznam dovoljenih stvari (pozitivni seznam) boljši od dolgega seznama prepovedi. Odobreni so lahko na primer roki za vračilo, regije dostave, lastnosti izdelkov, navodila, splošna cenovna logika ali pot do prijave. Ni pa dovoljen dostop do individualnih statusov naročil, podrobnosti pogodb, osebnih terminov, internih opomb ali potrditve, ali določen račun sploh obstaja.

Tudi na videz nedolžni odgovori lahko razkrijejo informacije. „Za ta e-poštni naslov ne obstaja noben račun“ potrjuje poskus preverjanja. Nevtralen odgovor, kot je „Prijavite se v uporabniški portal za dostop do informacij o računu“, ohranja mejo stabilno. Za poskuse manipulacije so potrebni dodatni zaščitni ukrepi, kot jih opisuje prispevek Prompt Injection pri spletnih chatbotih.

Kaj dodatno potrebuje avtenticirani AI chatbot

Po prijavi lahko asistent naredi več, vendar le v okviru strežniško določenega konteksta. Smiselni vhodni podatki so interna referenca seje, dovoljena organizacija ali naročnik, vloge ter natančno opredeljen obseg funkcij. Surovi dostopni podatki, gesla, celotni žetoni seje ali nepotrebna osebna polja ne sodijo v kontekst modela.

Dokument OWASP Authorization Cheat Sheet priporoča preverjanje dovoljenj za vsak konkretni vir in funkcijo. Za klice orodij to pomeni: model ne odloča o tem, ali je račun viden. Model prosi storitev za dovoljene informacije; storitev pa znova preveri sejo, vlogo, naročnika in objekt. Klepet nato prejme le tista polja, ki so potrebna za odgovor.

Praktična določitev meja podatkov in orodij

Branje in pisanje bi morali biti ločeni orodji. Orodje „Upravljanje računa stranke“ je preširoko. Boljše so manjše funkcije, kot so „Seznam lastnih odprtih naročil“, „Branje statusa dovoljenega naročila“ ali „Priprava podpornega primera“. Vsaka funkcija prejme minimalno vhodno shemo, strežniško preverjanje dovoljenj, razumljive primere napak in omejen izhod.

Za RAG se priporoča enaka logika: javni viri v javni iskalni prostor, dokumenti, vezani na račun, pa v iskalni prostor, filtriran glede na naročnika in vlogo. Filtri se ustvarijo na strani strežnika iz seje, ne pa iz prosto formuliranih vnosov v klepetu. Spremembe virov, vlog in odobritev sodijo v dokumentiran postopek; predlogo ponuja članek o upravljanju vsebin in nadzoru sprememb.

Upoštevanje poteka seje, odjave in deljenih naprav

Vmesnik klepeta ne sme delovati, kot da dovoljenje ostaja veljavno za nedoločen čas. Vodnik OWASP Session Management Cheat Sheet opisuje sejo kot povezavo med avtentikacijo, prometom HTTP in nadzorom dostopa. Ko seja poteče, mora naslednji dostop do zasebnih podatkov zanesljivo spodleteti. Stari odgovor v vidni zgodovini ne sme biti interpretiran kot novo dovoljenje.

Ekipe bi morale preizkusiti tudi odjavo, zamenjavo računa, spremembo vlog in skupno rabljene naprave. Zasebne zgodovine pogovorov po zamenjavi ne smejo biti vidne pri naslednjem računu. Ko seja poteče, mora asistent jasno usmeriti k ponovni prijavi, ne da bi ponavljal občutljive podrobnosti iz prejšnje seje. Za beleženje in analitiko velja načelo najmanjšega obsega podatkov; prispevek o analitiki chatbotov z minimalnimi podatki prikazuje ustrezne meje dogodkov in hrambe.

Občutljiva dejanja potrebujejo ločeno potrditev

Prijava v portal ni nujno zadostna za vsako dejanje. Če klepet spreminja naslov za dostavo, potrjuje pogodbo ali sproža plačilo, mora sistem zahtevati jasno prepoznavno potrditev, vezano na posamezno dejanje. Vodnik OWASP Transaction Authorization Cheat Sheet ločuje prijavo in odobritev transakcije ter zahteva strežniške kontrole in preverjanje ključnih podatkov transakcije.

Varno zaporedje korakov je naslednje: klepet zajame zahtevo in prikaže razumljiv povzetek, portal preveri trenutno dovoljenje ter po potrebi zahteva ponovno avtentikacijo ali drugi faktor. Šele nato strežniška storitev izvede natančno potrjeno dejanje. Če se spremenijo cilj, znesek ali drugi bistveni podatki, predhodna odobritev preneha veljati.

Primer: Vračilo brez uhajanja podatkov

Anonymna oseba vpraša: „Ali lahko vrnem svoje naročilo?“ Javni klepet pojasni splošno logiko vračil in ponudi povezavo do portala. Ne sprašuje po celotnem naslovu ali plačilnih podatkih. Po prijavi lahko klepet na portalu z orodjem za branje prikaže uporabnikova naročila, ki so primerna za vračilo. Ko oseba izbere naročilo, strežnik znova preveri dovoljenja za objekt in veljavna pravila.

Za dejansko vračilo ločeno orodje za dejanja ustvari povzetek. Oseba potrdi artikle in možnost prevzema v vmesniku portala. Če preverjanje spodleti, klepet ne razkrije internih opozorilnih signalov, temveč ponudi varen naslednji korak. Če je pojasnilo s strani človeka nujno, sledi nadzorovana predaja operaterju (Human Handoff) z le najnujnejšim, odobrenim kontekstom.

Testna matrika pred začetkom uporabe (Go-live)

Testna matrika ne bi smela preverjati le uspešnih poti. Uporabite vsaj dva računa s podobnimi vlogami in ločenimi podatki ter preizkusite naslednje primere:

• Anonymno povpraševanje po splošnih informacijah in po zasebnih podatkih računa.
• Prijavljeni račun A prebere svoj objekt in nato poskuša uporabiti identifikator objekta računa B.
• Potekla seja, odjava, zamenjava računa in odvzem vloge med potekom klepeta.
• Sprememba jezika sredi postopka, ne da bi se spremenila podatkovni prostor ali dovoljenja.
• Prompt injection v uporabniških vnosih in v pridobljenih dokumentih.
• Izpad orodja za branje, potek časa (timeout) in protislovni podatki v ozadju (backend).
• Dejanje pisanja brez potrditve, s spremenjenimi podatki in s pretečeno potrditvijo.
• Predaja človeku z minimalnim, razumljivim kontekstom pogovora.

Pričakovani rezultati sodijo vnaprej v testiranje: kateri odgovor je javno dovoljen? Katera napaka HTTP nastane na strežniku? Katere informacije so lahko vidne v klepetu? Kateri dogodek se zabeleži brez zaupne vsebine? Načrtovani omejeni način delovanja (degraded mode) pomaga ob izpadu identifikacijskih ali ozadnih storitev; za to obstaja ločen vodnik za odzivanje na incidente in povračilni način (rollback).

Kontrolni seznam za zanesljivo mejo portala

• Dokumentirajte javno, avtenticirano in posebej zaščiteno območje.
• Ločeno modelirajte avtentikacijo, avtorizacijo in odobritev transakcij.
• Račun in naročnika izpeljite iz zaščitene seje.
• Ob vsakem branju in pisanju na strežniku preverite dovoljenja objekta.
• Tehnično ločite in filtrirajte javne ter zasebne vire RAG.
• Orodjem dodelite minimalne pravice; ločite branje in pisanje.
• V klepetu upoštevajte potek seje, odjavo, zamenjavo računa in spremembe vlog.
• Občutljiva dejanja razumljivo povzemite in zahtevajte ciljno potrditev.
• Predajo in beleženje omejite le na nujne podatke.
• Z vsaj dvema računoma ponovljivo preizkusite vodoravne poskuse dostopa.

Avtenticiran AI chatbot ne postane varen zgolj zato, ker se pojavi za prijavo. Varnost nastane, ko ima vsaka informacija in vsako dejanje preverljivo mejo. Zato začnite z zemljevidom območij in testno matriko, preden povežete zasebne podatkovne vire ali orodja za pisanje. Tako bo javni klepet ostal koristen, klepet na portalu pa operativen, ne da bi pri tem pomešali obe območji zaupanja.

Viri

• 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