Verejný AI chatbot vs. klientsky portál: Bezpečné oddelenie identity a prístupu k dátam

Chatbot na verejnom webe môže odpovedať na otázky o produktoch, vysvetľovať otváracie hodiny alebo nasmerovať na príslušnú servisnú stránku. Ak však má v klientskom portáli zobrazovať stav objednávok, zmluvy, faktúry alebo prípady podpory, mení sa nielen obsah. Vzniká nová bezpečnostná hranica. Autentifikovaný AI chatbot musí jednoznačne oddeľovať identitu, oprávnenia, reláciu a konkrétnu akciu.

Najdôležitejšie architektonické rozhodnutie preto neznie: „Aký model použijeme?“ Znie: „Aké informácie a aké akcie sú povolené v ktorej dôveryhodnej zóne?“ Kto odpovie na túto otázku ešte pred návrhom promptov, zníži riziko úniku dát, chybného priradenia účtov a nežiaducich akcií. Nasledujúci sprievodca slúži ako technická a organizačná orientácia, nie ako individuálne právne poradenstvo.

Prečo sú verejný a autentifikovaný režim dve odlišné prevádzky

Vo verejnom chate je osoba najprv neznáma. Systém môže poznať nanajvýš kontext rozhovoru, zvolený jazyk a technicky nevyhnutné údaje o relácii. Odpovede by sa preto mali obmedziť na schválené, všeobecne dostupné zdroje. Zadaná e-mailová adresa, číslo objednávky alebo tvrdenie typu „Toto je moja zmluva“ zatiaľ nie sú dôkazom o oprávnení.

V klientskom portáli naopak existuje prihlásená relácia. Ale aj tam platí: Prihlásenie automaticky neznamená, že je povolený každý zdroj a každá akcia. OWASP Authentication Cheat Sheet rozlišuje autentifikáciu, overenie identity a správu relácií. Aktuálne NIST Digital Identity Guidelines, Revision 4 rovnako pristupujú k overovaniu identity, autentifikácii a federácii ako k samostatným stavebným prvkom. Pre tímy spravujúce web z toho vyplýva: Chat smie používať iba tie signály dôvery, ktoré okolitému systému preukázateľne poskytuje.

Tri zóny namiesto všemocného chatbota

Robustné riešenie rozdeľuje vedomosti a nástroje minimálne do troch zón:

• Verejná zóna: schválený obsah webu, všeobecné informácie o produktoch, procesy, kontaktné kanály a nezáväzná pomoc.
• Autentifikovaná zóna: dáta a procesy viazané na prihlásený účet, organizáciu, rolu alebo oprávnenie.
• Osobitne chránená zóna: citlivé zmeny, výplaty, uzatváranie zmlúv, nové doručovacie adresy, zmeny oprávnení alebo iné akcie, ktoré vyžadujú dodatočné potvrdenie alebo ľudskú kontrolu.

Tieto zóny by nemali byť definované iba v systémovom prompte. Musia byť zakotvené v dátových zdrojoch, API, úlohách, oprávneniach nástrojov a kontrolách na strane servera. Prompt môže usmerňovať správanie, ale nie je riadením prístupu. To isté platí pre RAG: vyhľadávanie vo verejných aj súkromných dokumentoch v spoločnom nefiltrovanom indexe vytvára zbytočne širokú plochu na útok.

Autentifikácia nie je autorizácia

Autentifikácia zjednodušene odpovedá na otázku: „Aká digitálna identita je prihlásená?“ Autorizácia odpovedá: „Smie táto identita čítať práve tento objekt alebo vykonať túto funkciu?“ Tento rozdiel sa v chate ľahko stiera, pretože používatelia prirodzene zadávajú čísla objektov: „Ukáž mi faktúru 4711“ alebo „Zmeň adresu pre objednávku 815“.

Odporúčania OWASP proti IDOR vyžadujú kontrolu oprávnení na úrovni jednotlivých objektov, aj keď sú identifikátory ťažko uhádnuteľné. V praxi to znamená: Server odvodí aktuálny účet z chránenej relácie a pri každej požiadavke overí, či faktúra, objednávka alebo ticket patria do tohto povoleného dátového priestoru. Jazykový model nesmie prevziať voľne zadané ID zákazníka alebo objektu ako dôveryhodný bod.

Čo smie zodpovedať verejný chat na webe

Pre verejnú oblasť je zoznam povolených vecí lepší ako dlhý zoznam zákazov. Povolené môžu byť napríklad lehoty na vrátenie tovaru, doručovacie oblasti, vlastnosti produktov, návody, všeobecná cenová logika alebo cesta k prihláseniu. Nepovolené sú individuálne stavy objednávok, podrobnosti zmlúv, osobné termíny, interné poznámky alebo informácia o tom, či konkrétny účet vôbec existuje.

Aj zdanlivo neškodné odpovede môžu prezradiť informácie. Odpoveď „K tejto e-mailovej adrese neexistuje žiadny účet“ potvrdzuje pokus o overenie. Neutrálna odpoveď typu „Prihláste sa do klientskeho portálu pre získanie informácií viazaných na účet“ udržiava hranicu stabilnú. Proti pokusom o manipuláciu sú navyše potrebné ochranné opatrenia, ako ich popisuje článok Prompt Injection bei Website-Chatbots.

Čo navyše potrebuje autentifikovaný AI chatbot

Po prihlásení môže asistent robiť viac, ale iba v rámci kontextu určeného na strane servera. Zmysluplné vstupné údaje sú interná referencia relácie, povolená organizácia alebo tenant, úlohy a úzko definovaný rozsah funkcií. Surové prístupové údaje, heslá, kompletné tokeny relácie alebo nepotrebné osobné polia do kontextu modelu nepatria.

OWASP Authorization Cheat Sheet odporúča kontrolu oprávnení pre každý konkrétny zdroj a funkciu. Pri volaniach nástrojov to znamená: Nie model rozhoduje o tom, či je faktúra viditeľná. Požiada službu o povolenú informáciu; služba opätovne overí reláciu, rolu, tenanta a objekt. Chat následne dostane iba polia potrebné na odpoveď.

Ako prakticky nastaviť dátové a nástrojové hranice

Čítanie a zápis by mali byť oddelené nástroje. Nástroj „Spravovať zákaznícky účet“ je príliš široký. Lepšie sú malé funkcie ako „zobraziť vlastné otvorené objednávky“, „prečítať stav povolenej objednávky“ alebo „pripraviť prípad podpory“. Každá funkcia dostane minimálnu vstupnú schému, kontrolu oprávnení na strane servera, sledovateľné chybové stavy a obmedzený výstup.

Pre RAG sa odporúča rovnaká logika: verejné zdroje do verejného vyhľadávacieho priestoru, dokumenty viazané na účet do vyhľadávacieho priestoru filtrovaného podľa tenanta a roly. Filtre sa vytvárajú na strane servera z relácie, nie z voľne formulovaných údajov v chate. Zmeny v zdrojoch, úlohách a schváleniach patria do dokumentovaného postupu; šablónu poskytuje článok o Content Governance und Change Control.

Zohľadnenie vypršania relácie, odhlásenia a zdieľaných zariadení

Rozhranie chatu nesmie pôsobiť tak, akoby oprávnenie trvalo neobmedzene. OWASP Session Management Cheat Sheet popisuje reláciu ako spojenie medzi autentifikáciou, HTTP prevádzkou a riadením prístupu. Ak relácia vyprší, ďalšie načítanie súkromných dát musí bezpečne zlyhať. Stará odpoveď vo viditeľnej histórii sa nesmie interpretovať ako nové oprávnenie.

Tímy by mali okrem toho testovať odhlásenie, zmenu účtu, zmenu roly a zdieľané zariadenia. Súkromné histórie konverzácií sa po zmene nesmú zobraziť pri nasledujúcom účte. Asistent by mal pri vypršanej relácii jasne naviesť na opätovné prihlásenie bez toho, aby opakoval citlivé detaily z predchádzajúcej relácie. Pre protokolovanie a vyhodnocovanie platí minimalizácia dát; článok o datensparsamer Chatbot-Analytics ukazuje vhodné hranice pre udalosti a uchovávanie.

Citlivé akcie vyžadujú samostatné potvrdenie

Prihlásenie do portálu nemusí stačiť pre každú akciu. Ak chat mení doručovaciu adresu, potvrdzuje zmluvu alebo spúšťa platbu, systém by mal vyžadovať jasne rozpoznateľné potvrdenie viazané na danú akciu. OWASP Transaction Authorization Cheat Sheet oddeľuje prihlásenie od schválenia transakcie a vyžaduje kontroly na strane servera ako aj overenie kľúčových údajov transakcie.

Bezpečný vzor znie: Chat zaznamená požiadavku, zobrazí zrozumiteľný prehľad, portál overí aktuálne oprávnenie a v prípade potreby vyžiada opätovnú autentifikáciu alebo druhý faktor. Až potom služba na strane servera vykoná presne potvrdenú akciu. Ak sa zmení cieľ, suma alebo iné podstatné údaje, predchádzajúce schválenie stráca platnosť.

Príklad: Vrátenie tovaru bez úniku dát

Anonymná osoba sa pýta: „Môžem vrátiť svoju objednávku?“ Verejný chat vysvetlí všeobecnú logiku vrátenia a odkáže na portál. Nepýta sa na úplnú adresu ani platobné údaje. Po prihlásení môže chat v portáli pomocou čítacieho nástroja zobraziť vlastné objednávky vhodné na vrátenie. Ak osoba vyberie objednávku, server opätovne overí oprávnenia k objektu a platné pravidlá.

Pre samotné vrátenie vytvorí samostatný akčný nástroj prehľad. Osoba potvrdí položky a možnosť vyzdvihnutia v rozhraní portálu. Ak kontrola zlyhá, chat neuvádza žiadne interné bezpečnostné signály, ale ponúkne bezpečný ďalší krok. Ak je potrebné ľudské riešenie, nasleduje kontrolované Human Handoff iba s nevyhnutným, schváleným kontextom.

Testovacia matica pred spustením do prevádzky

Testovacia matica by nemala overovať len ideálne scenáre. Použite minimálne dva účty s podobnými úlohami a oddelenými dátami a otestujte nasledujúce prípady:

• Anonymná požiadavka na všeobecné informácie a na súkromné údaje účtu.
• Prihlásený účet A číta vlastný objekt a následne sa pokúsi zadat ID objektu účtu B.
• Vypršaná relácia, odhlásenie, zmena účtu a odobratie roly počas prebiehajúceho chatu.
• Zmena jazyka uprostred procesu bez toho, aby sa zmenil dátový priestor alebo oprávnenia.
• Prompt Injection v používateľských vstupoch a v načítaných dokumentoch.
• Výpadok čítacieho nástroja, prekročenie časového limitu a rozporuplné dáta v backende.
• Zápisová akcia bez potvrdenia, so zmenenými dátami a s vypršaným potvrdením.
• Odovzdanie človeku s minimálnym, sledovateľným kontextom rozhovoru.

Očakávané výsledky musia byť definované vopred v teste: Aká odpoveď je verejne prípustná? Aká HTTP chyba vznikne na strane servera? Aké informácie môžu byť viditeľné v chate? Aká udalosť sa zaznamená do protokolu bez dôverných údajov? Plánovaný obmedzený režim (Degraded Mode) pomáha pri výpadku identitných alebo backendových služieb; pre tento prípad existuje samostatný ki-chatbot-incident-response-degraded-mode-rollback.

Kontrolný zoznam pre odolnú hranicu portálu

• Dokumentovať verejnú, autentifikovanú a osobitne chránenú zónu.
• Modelovať autentifikáciu, autorizáciu a schvaľovanie transakcií oddelene.
• Odvodzovať účet a tenanta z bezpečnej relácie.
• Kontrolovať oprávnenia k objektom na strane servera pri každom čítaní a zápise.
• Technicky oddeliť a filtrovať verejné a súkromné zdroje RAG.
• Nástrojové práva nastaviť minimálne; oddeliť čítanie a zápis.
• Zohľadniť v chate vypršanie relácie, odhlásenie, zmenu účtu a zmeny rolí.
• Srozumiteľne zhrnúť citlivé akcie a vyžadovať ich cielené potvrdenie.
• Obmedziť odovzdanie človeku a protokolovanie len na nevyhnutné dáta.
• Reprodukovateľne testovať horizontálne pokusy o prístup s minimálne dvoma účtami.

Autentifikovaný AI chatbot sa nestane bezpečným iba tým, že sa zobrazí za prihlásením. Bezpečnosť vzniká vtedy, keď má každá informácia a každá akcia overiteľnú hranicu. Začnite preto s mapou zón a testovacou maticou skôr, než pripojíte súkromné dátové zdroje alebo zápisové nástroje. Verejný chat tak zostane užitočný a chatbot v portáli akcieschopný – bez toho, aby sa zmiešali obe zóny dôvery.

Zdroje

• 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