Javni AI chatbot vs. korisnički portal: Sigurno odvajanje identiteta i pristupa podacima

Chatbot na javnoj web stranici smije odgovarati na pitanja o proizvodima, objašnjavati radno vrijeme ili usmjeravati na odgovarajuću servisnu stranicu. Međutim, čim u korisničkom portalu treba pregledavati status narudžbe, ugovore, račune ili slučajeve podrške, ne mijenja se samo sadržaj. Nastaje nova sigurnosna granica. Autentificirani AI chatbot mora uredno razdvojiti identitet, ovlaštenje, sesiju i konkretnu akciju.

Stoga najvažnija arhitektonska odluka ne glasi: „Koji model koristimo?“, nego: „Koja je informacija i koja akcija dopuštena u kojem području povjerenja?“ Tko odgovori na ovo pitanje prije dizajniranja prompta, smanjuje curenje podataka, pogrešno dodjeljivanje računa i neželjene akcije. Sljedeći vodič pruža tehničku i organizacijsku orijentaciju, a ne pojedinačni pravni savjet.

Zašto su javni i autentificirani način rada dva različita načina rada

U javnom chatu osoba je u početku nepoznata. Sustav u najboljem slučaju može znati kontekst razgovora, odabrani jezik i tehnički nužne podatke o sesiji. Stoga bi se odgovori trebali ograničiti na odobrene, opće dostupne izvore. Unesena e-mail adresa, broj narudžbe ili tvrdnja poput „To je moj ugovor“ još uvijek nisu dokaz ovlaštenja.

U korisničkom portalu, s druge strane, postoji prijavljena sesija. No i tamo vrijedi: prijava ne znači automatski da su svaki resurs i svaka akcija dopušteni. Dokument OWASP Authentication Cheat Sheet razlikuje autentifikaciju, provjeru identiteta i upravljanje sesijom. Aktualne smjernice NIST Digital Identity Guidelines, Revision 4 također tretiraju provjeru identiteta, autentifikaciju i federaciju kao zasebne gradivne blokove. Za timove zadužene za web stranice iz toga slijedi: Chat smije koristiti samo signale povjerenja koje okolni sustav dokazivo pruža.

Tri zone umjesto svemogućeg chatbota

Robusno rješenje dijeli znanje i alate na najmanje tri zone:

• Javna zona: odobreni sadržaji web stranice, opće informacije o proizvodima, procesi, načini kontakta i neobvezujuća pomoć.
• Autentificirana zona: podaci i postupci koji su vezani uz prijavljeni račun, organizaciju, ulogu ili ovlaštenje.
• Posebno zaštićena zona: osjetljive promjene, isplate, sklapanja ugovora, nove adrese dostave, promjene ovlaštenja ili druge akcije koje zahtijevaju dodatnu potvrdu ili ljudsku provjeru.

Ove zone ne bi trebale postojati samo u sistemskom promptu. Moraju biti preslikane u izvorima podataka, API-jima, ulogama, ovlaštenjima alata i poslužiteljskim provjerama. Prompt može usmjeravati ponašanje, ali nije kontrola pristupa. Isto vrijedi i za RAG: pretraživanje javnih i privatnih dokumenata u zajedničkom, nefiltriranom indeksu stvara nepotrebno široku površinu za napad.

Autentifikacija nije autorizacija

Pojednostavljeno, autentifikacija odgovara na pitanje: „Koja je digitalna identifikacija prijavljena?“, dok autorizacija odgovara na: „Smije li taj identitet pročitati točno taj objekt ili izvršiti tu funkciju?“ Ta se razlika u chatu lako zamagli jer korisnici prirodno formuliraju brojeve objekata: „Prikaži mi račun 4711“ ili „Promijeni adresu za narudžbu 815“.

Preporuke OWASP-a protiv IDOR-a zahtijevaju provjeru ovlaštenja vezanu uz objekt, čak i ako je identifikatore teško pogoditi. U praksi to znači: poslužitelj izvodi trenutni račun iz zaštićene sesije i pri svakom upitu provjerava pripada li račun, narudžba ili ulaznica (ticket) tom dopuštenom prostoru podataka. Jezični model ne smije prihvatiti slobodno uneseni ID korisnika ili objekta kao sidro povjerenja.

Što javni chat na web stranici smije odgovarati

Za javno područje bolja je pozitivna lista od duge liste zabrana. Odobreni mogu biti, primjerice, rokovi povrata, regije dostave, značajke proizvoda, upute, opća logika cijena ili put do prijave. Nisu odobreni pojedinačni statusi narudžbi, detalji ugovora, osobni termini, interne bilješke niti podatak o tome postoji li uopće određeni račun.

Čak i naizgled bezazleni odgovori mogu otkriti informacije. „Za ovu e-mail adresu ne postoji račun“ potvrđuje pokušaj provjere. Neutralan odgovor poput „Prijavite se u korisnički portal kako biste dohvatili informacije vezane uz račun“ održava granicu stabilnom. Za pokušaje manipulacije potrebne su dodatne zaštitne mjere, kako je opisano u članku Prompt Injection bei Website-Chatbots.

Što autentificirani AI chatbot dodatno treba

Nakon prijave asistent smije više, ali samo unutar konteksta koji je definiran na poslužitelju. Smisleni ulazni podaci su interna referenca sesije, dopuštena organizacija ili klijent, uloge te usko definiran opseg funkcija. Sirov pristupni podaci, lozinke, potpuni tokeni sesije ili nepotrebna polja s osobnim podacima ne pripadaju u kontekst modela.

Dokument OWASP Authorization Cheat Sheet preporučuje provjere ovlaštenja za svaki konkretan resurs i funkciju. Za pozive alata to znači: model ne odlučuje o tome je li račun vidljiv. On traži dopuštenu informaciju od usluge, a usluga ponovno provjerava sesiju, ulogu, klijenta i objekt. Chat zatim prima samo polja potrebna za odgovor.

Praktično definiranje granica podataka i alata

Čitanje i pisanje trebaju biti odvojeni alati. Alat „Upravljanje korisničkim računom“ preširok je. Bolje su male funkcije poput „prikaži vlastite otvorene narudžbe“, „pročitaj status dopuštene narudžbe“ ili „pripremi slučaj podrške“. Svaka funkcija dobiva minimalnu ulaznu shemu, poslužiteljsku provjeru ovlaštenja, razumljive slučajeve pogrešaka i ograničeni izlaz.

Za RAG se preporučuje ista logika: javni izvori u javni prostor pretraživanja, a dokumenti vezani uz račun u prostor pretraživanja filtriran prema klijentu i ulozi. Filtri se stvaraju na poslužitelju iz sesije, a ne iz slobodno formuliranih navoda u chatu. Promjene izvora, uloga i odobrenja pripadaju u dokumentirani postupak; predložak donosi članak o Content Governance und Change Control.

Uzimanje u obzir isteka sesije, odjave i dijeljenih uređaja

Sučelje chata ne smije ostavljati dojam da ovlaštenje ostaje neograničeno. Dokument OWASP Session Management Cheat Sheet opisuje sesiju kao vezu između autentifikacije, HTTP prometa i kontrole pristupa. Ako sesija istekne, sljedeće dohvaćanje privatnih podataka mora sigurno propasti. Stari odgovor u vidljivoj povijesti ne smije se tumačiti kao novo ovlaštenje.

Timovi bi također trebali testirati odjavu, promjenu računa, promjenu uloge i zajednički korištene uređaje. Privatne povijesti razgovora ne smiju se pojaviti na sljedećem računu nakon promjene. Kod istekle sesije asistent bi trebao jasno voditi prema ponovnoj prijavi, bez ponavljanja osjetljivih detalja iz prethodne sesije. Za zapisivanje i evaluaciju vrijedi načelo smanjenja količine podataka; članak o datensparsamer Chatbot-Analytics prikazuje odgovarajuće granice događaja i pohrane.

Osjetljive akcije trebaju vlastitu potvrdu

Prijava na portal nije nužno dovoljna za svaku akciju. Ako chat mijenja adresu dostave, potvrđuje ugovor ili pokreće plaćanje, sustav bi trebao zahtijevati jasno prepoznatljivu potvrdnu akciju. Dokument OWASP Transaction Authorization Cheat Sheet razdvaja prijavu od odobrenja transakcije te zahtijeva poslužiteljske kontrole i provjeru ključnih podataka transakcije.

Siguran uzorak glasi: Chat prikuplja zahtjev, prikazuje razumljiv sažetak, portal provjerava trenutno ovlaštenje i po potrebi traži ponovnu autentifikaciju ili drugi faktor. Tek nakon toga poslužiteljska usluga izvršava točno potvrđenu akciju. Ako se promijene cilj, iznos ili drugi bitni podaci, prethodno odobrenje prestaje vrijediti.

Primjer: Povrat bez curenja podataka

Anonimna osoba pita: „Mogu li vratiti svoju narudžbu?“ Javni chat objašnjava opću logiku povrata i povezuje na portal. Ne traži punu adresu niti podatke o plaćanju. Nakon prijave, chat na portalu može putem alata za čitanje izlistati vlastite narudžbe koje je moguće vratiti. Ako osoba odabere narudžbu, poslužitelj ponovno provjerava ovlaštenje nad objektom i važeća pravila.

Za stvarni povrat zasebni akcijski alat stvara sažetak. Osoba potvrđuje artikle i opciju preuzimanja u sučelju portala. Ako provjera ne uspije, chat ne navodi interne signale rizika, nego nudi siguran sljedeći korak. Ako je pojašnjenje od strane čovjeka nužno, slijedi kontrolirani Human Handoff sa samo nužnim, odobrenim kontekstom.

Matrica testiranja prije puštanja u rad (Go-live)

Matrica testiranja ne bi trebala provjeravati samo idealne scenarije. Upotrijebite najmanje dva računa sa sličnim ulogama i odvojenim podacima te testirajte sljedeće slučajeve:

• Anonimni upit za opće informacije i za privatne podatke računa.
• Prijavljeni račun A čita vlastiti objekt, a zatim pokušava upotrijebiti identifikator objekta s računa B.
• Istekla sesija, odjava, promjena računa i oduzimanje uloge tijekom aktivnog chata.
• Promjena jezika usred postupka bez promjene prostora podataka ili ovlaštenja.
• Prompt injection u korisničkim unosima i u dohvaćenim dokumentima.
• Kvar alata za čitanje, prekoračenje vremena (timeout) i proturječni pozadinski (backend) podaci.
• Akcija pisanja bez potvrde, s izmijenjenim podacima i s isteklim odobrenjem.
• Prijenos na čovjeka s minimalnim, razumljivim kontekstom razgovora.

Očekivani rezultati trebaju unaprijed biti dio testa: koji je odgovor javno dopušten? Koja se HTTP pogreška stvara na poslužitelju? Koja informacija smije biti vidljiva u chatu? Koji se događaj bilježi u dnevnik bez povjerljivog sadržaja? Planirani degradirani način rada (Degraded Mode) pomaže kada otkažu usluge identiteta ili pozadinske usluge; za to postoji poseban Incident-Response- und Rollback-Leitfaden.

Kontrolna lista za pouzdanu granicu portala

• Dokumentirati javnu, autentificiranu i posebno zaštićenu zonu.
• Zasebno modelirati autentifikaciju, autorizaciju i odobrenje transakcije.
• Izvesti račun i klijenta iz sigurne sesije.
• Provjeravati ovlaštenje nad objektom na poslužitelju pri svakom čitanju i pisanju.
• Tehnički odvojiti i filtrirati javne i privatne RAG izvore.
• Ograničiti prava alata na minimum; razdvojiti čitanje i pisanje.
• Uzeti u obzir istek sesije, odjavu, promjenu računa i promjene uloga u chatu.
• Jasno sažeti osjetljive akcije i zatražiti njihovu ciljanu potvrdu.
• Ograničiti prijenos na čovjeka i bilježenje u dnevnik na nužne podatke.
• Reproducibilno testirati horizontalne pokušaje pristupa s najmanje dva računa.

Autentificirani AI chatbot ne postaje siguran samo zato što se pojavljuje iza prijave. Sigurnost nastaje kada svaka informacija i svaka akcija ima provjerljivu granicu. Stoga započnite s kartom zona i matricom testiranja prije spajanja privatnih izvora podataka ili alata koji pišu podatke. Tako javni chat ostaje koristan, a chat na portalu sposoban za rad, bez miješanja dvaju područja povjerenja.

Izvori

• 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