Veřejný AI chatbot vs. klientský portál: Jak bezpečně oddělit identitu a přístup k datům

Chatbot na veřejném webu může odpovídat na dotazy k produktům, vysvětlovat otevírací dobu nebo směrovat na odpovídající servisní stránku. Jakmile však má v klientském portálu zobrazovat stav objednávek, smlouvy, faktury nebo případy podpory, mění se nejen obsah. Vzniká nová bezpečnostní hranice. Autentizovaný AI chatbot musí čistě oddělovat identitu, oprávnění, relaci a konkrétní akci.

Nejdůležitější architektonické rozhodnutí proto nezní: „Jaký model použijeme?“, ale: „Jaké informace a jaké akce jsou v které důvěryhodné zóně povoleny?“ Kdo na tuto otázku odpoví ještě před návrhem promptů, sníží riziko úniku dat, chybného přiřazení účtů a nežádoucích akcí. Následující průvodce slouží jako technická a organizační orientace, nikoli jako individuální právní poradenství.

Proč jsou veřejný a autentizovaný provoz dva odlišné režimy

Ve veřejném chatu je osoba zpočátku neznámá. Systém může znát nanejvýš kontext rozhovoru, zvolený jazyk a technicky nezbytná data relace. Odpovědi by se proto měly omezit na schválené, veřejně přístupné zdroje. Zadaná e-mailová adresa, číslo objednávky nebo tvrzení typu „Toto je moje smlouva“ ještě nepředstavují doklad o oprávnění.

V klientském portálu naopak existuje přihlášená relace. Ale i tam platí: Přihlášení neznamená automaticky, že je povolen každý prostředek a každá akce. OWASP Authentication Cheat Sheet rozlišuje autentizaci, ověření identity a správu relace. Aktuální pokyny NIST Digital Identity Guidelines, Revision 4 rovněž přistupují k ověření identity, autentizaci a federaci jako k samostatným stavebním kamenům. Pro týmy spravující web z toho vyplývá: Chat smí používat pouze ty signály důvěry, které okolní systém prokazatelně poskytuje.

Tři zóny místo všemocného chatbota

Robustní řešení rozděluje znalosti a nástroje minimálně do tří zón:

• Veřejná zóna: schválený obsah webu, obecné informace o produktech, postupy, kontaktní kanály a nezávazná nápověda.
• Autentizovaná zóna: data a procesy vázané na přihlášený účet, organizaci, roli nebo oprávnění.
• Zvláště chráněná zóna: citlivé změny, výplaty, uzavírání smluv, nové doručovací adresy, změny oprávnění nebo jiné akce vyžadující dodatečné potvrzení či lidskou kontrolu.

Tyto zóny by neměly být definovány pouze v systémovém promptu. Musí být promítnuty do datových zdrojů, API, rolí, oprávnění nástrojů a serverových kontrol. Prompt může usměrňovat chování, ale nepředstavuje řízení přístupu. Totéž platí pro RAG: Vyhledávání ve veřejných i soukromých dokumentech v společném, nefiltrovaném indexu vytváří zbytečně širokou plochu pro útok.

Autentizace není autorizace

Autentizace zjednodušeně odpovídá na otázku: „Jaká digitální identita je přihlášena?“ Autorisace odpovídá na otázku: „Smí tato identita číst přesně tento objekt nebo provést tuto funkci?“ V chatu se tento rozdíl snadno stírá, protože uživatelé přirozeně formulují čísla objektů: „Ukaž mi fakturu 4711“ nebo „Změň adresu pro objednávku 815“.

Doporučení OWASP pro prevenci IDOR vyžadují kontrolu oprávnění na úrovni objektu, i když je obtížné identifikátory uhodnout. V praxi to znamená: Server odvodí aktuální účet z chráněné relace a při každém požadavku ověří, zda faktura, objednávka nebo tiket patří do tohoto povoleného datového prostoru. Jazykový model nesmí převzít volně zadané ID zákazníka nebo objektu jako důvěryhodný prvek.

Co smí zodpovídat veřejný chatbot na webu

Pro veřejnou oblast je lepší vytvořit seznam povolených položek než dlouhý seznam zákazů. Schváleny mohou být například lhůty pro vrácení zboží, oblasti doručení, vlastnosti produktů, návody, obecná cenová logika nebo cesta k přihlášení. Neschváleny zůstávají individuální stavy objednávek, detaily smluv, osobní schůzky, interní poznámky nebo informace o tom, zda konkrétní účet vůbec existuje.

I zdánlivě neškodné odpovědi mohou prozradit informace. Odpověď „K této e-mailové adrese neexistuje žádný účet“ potvrzuje pokus o ověření. Neutrální odpověď jako „Přihlaste se do klientského portálu pro získání informací k účtu“ udržuje hranici stabilní. Pro případ pokusů o manipulaci jsou zapotřebí dodatečná ochranná opatření, jak popisuje článek Prompt Injection bei Website-Chatbots.

Co navíc potřebuje autentizovaný AI chatbot

Po přihlášení smí asistent dělat více, ale pouze v rámci kontextu určeného na straně serveru. Smysluplnými vstupními daty jsou interní reference relace, povolená organizace nebo tenant, role a úzce definovaný rozsah funkcí. Nešifrované přístupové údaje, hesla, kompletní relační tokeny nebo zbytečná osobní pole do kontextu modelu nepatří.

OWASP Authorization Cheat Sheet doporučuje kontroly oprávnění pro každý konkrétní prostředek a funkci. U volání nástrojů to znamená: Model nerozhoduje o tom, zda je faktura viditelná. Požádá službu o povolené informace; služba znovu ověří relaci, roli, tenanta a objekt. Chat následně obdrží pouze pole nezbytná pro odpověď.

Jak prakticky vymezit hranice dat a nástrojů

Čtení a zápis by měly být oddělené nástroje. Nástroj „Spravovat zákaznický účet“ je příliš široký. Lepší jsou malé funkce jako „zobrazit vlastní otevřené objednávky“, „přečíst stav povolené objednávky“ nebo „připravit případ podpory“. Každá funkce dostane minimální schéma vstupů, serverovou kontrolu oprávnění, srozumitelné chybové stavy a omezený výstup.

Pro RAG se doporučuje stejná logika: veřejné zdroje do veřejného vyhledávacího prostoru, dokumenty vázané na účet do vyhledávacího prostoru filtrovaného podle tenanta a role. Filtry se vytvářejí na straně serveru z relace, nikoli z volně formulovaných údajů v chatu. Změny zdrojů, rolí a schválení patří do zdokumentovaného postupu; šablonu nabízí článek o Content Governance und Change Control.

Zohlednění vypršení relace, odhlášení a sdílených zařízení

Chatovací rozhraní nesmí působit tak, jako by oprávnění zůstávalo neomezeně platné. OWASP Session Management Cheat Sheet popisuje relaci jako spojení mezi autentizací, HTTP provozem a řízením přístupu. Pokud relace vyprší, musí následující načtení soukromých dat bezpečně selhat. Stará odpověď ve viditelné historii nesmí být interpretována jako nové oprávnění.

Týmy by měly rovněž testovat odhlášení, změnu účtu, změnu role a sdílená zařízení. Soukromé historie konverzací se po změně nesmí objevit u dalšího účtu. Při vypršení relace by měl asistent jasně navést k novému přihlášení, aniž by opakoval citlivé detaily z předchozí relace. Pro protokolování a vyhodnocování platí zásada minimalizace dat; příspěvek věnovaný datensparsamer Chatbot-Analytics ukazuje vhodné hranice pro události a uchovávání dat.

Citlivé akce vyžadují samostatné potvrzení

Přihlášení k portálu nemusí nutně stačit pro každou akci. Pokud chat mění doručovací adresu, potvrzuje smlouvu nebo spouští platbu, měl by systém vyžadovat jasně rozpoznatelné potvrzení vázané na danou akci. OWASP Transaction Authorization Cheat Sheet odděluje přihlášení od schválení transakce a vyžaduje serverové kontroly i ověření klíčových údajů transakce.

Bezpečný vzor vypadá takto: Chat shromáždí požadavek, zobrazí srozumitelný přehled, portál ověří aktuální oprávnění a v případě potřeby vyžaduje ponovnou autentizaci nebo druhý faktor. Teprve potom služba na straně serveru provede přesně potvzenou akci. Pokud se změní cíl, částka nebo jiné podstatné údaje, předchozí schválení pozbývá platnosti.

Příklad: Vrácení zboží bez úniku dat

Anonymní osoba se ptá: „Mohu vrátit svou objednávku?“ Veřejný chat vysvětlí obecnou logiku vrácení zboží a odkáže na portál. Neptá se na úplnou adresu ani na platební údaje. Po přihlášení může chat v portálu vypsat vlastní objednávky způsobilé k vrácení pomocí čtecího nástroje. Jakmile osoba vybere objednávku, server znovu ověří oprávnění k objektu a platná pravidla.

Pro samotné vrácení vytvoří samostatný akční nástroj souhrn. Osoba potvrdí položky a možnost vyzvednutí v rozhraní portálu. Pokud kontrola selže, chat neuvádí žádné interní rizikové signály, ale nabídne bezpečný další krok. Je-li nutné lidské řešení, následuje řízený Human Handoff pouze s nezbytným, schváleným kontextem.

Testovací matice před spuštěním

Testovací matice by neměla ověřovat pouze ideální průchody (happy paths). Použijte minimálně dva účty s podobnými rolemi a oddělenými daty a otestujte následující případy:

• Anonymní dotaz na obecné informace a na soukromé údaje k účtu.
• Přihlášený účet A přečte vlastní objekt a následně se pokusí použít identifikátor objektu účtu B.
• Vypršení relace, odhlášení, změna účtu a odebrání role během probíhajícího chatu.
• Změna jazyka uprostřed procesu, aniž by se změnil datový prostor nebo oprávnění.
• Prompt Injection v uživatelských vstupech a v načtených dokumentech.
• Výpadek čtecího nástroje, překročení časového limitu a rozporuplná data v backendu.
• Zápisová akce bez potvrzení, se změněnými daty a s vypršeným potvrzením.
• Předání člověku (handoff) s minimálním, srozumitelným kontextem rozhovoru.

Očekávané výsledky musí být stanoveny předem: Jaká odpověď je veřejně přípustná? Jaká HTTP chyba vznikne na straně serveru? Jaké informace smí být v chatu viditelné? Jaká událost se protokoluje bez důvěrného obsahu? Plánovaný omezený režim (degraded mode) pomáhá při výpadku služeb identity nebo backendu; k tomu existuje samostatný průvodce incident response a rollbackem.

Kontrolní seznam pro spolehlivé hranice portálu

• Zdokumentovat veřejnou, autentizovanou a zvláště chráněnou zónu.
• Modelovat autentizaci, autorizaci a schválení transakcí odděleně.
• Odvozovat účet a tenanta z bezpečné relace.
• Kontrolovat oprávnění k objektům na straně serveru při každém čtení i zápisu.
• Technicky oddělit a filtrovat veřejné a soukromé zdroje RAG.
• Nastavit oprávnění nástrojů na minimum; oddělit čtení a zápis.
• Zohlednit v chatu vypršení relace, odhlášení, změnu účtu a změny rolí.
• Citlivé akce srozumitelně shrnout a vyžadovat pro ně cílené potvrzení.
• Omezit handoff a protokolování na nezbytná data.
• Reprodukovatelně testovat pokusy o horizontální přístup pomocí minimálně dvou účtů.

Autentizovaný AI chatbot se nestane bezpečným pouhým umístěním za přihlášení. Bezpečnost vzniká tehdy, když každá informace a každá akce má ověřitelnou hranici. Začněte proto mapou zón a testovací maticí předtím, než připojíte soukromé datové zdroje nebo zápisové nástroje. Veřejný chat tak zůstane užitečný a portálový chat akceschopný, aniž by došlo ke směšování obou oblastí důvěry.

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