Publisks AI čatbots vs. klientu portāls: droša identitātes un datu piekļuves nošķiršana

Čatbots publiskā tīmekļa vietnē drīkst atbildēt uz jautājumiem par produktiem, skaidrot darba laiku vai novirzīt uz attiecīgo servisa lapu. Taču, tiklīdz tam klientu portālā ir jāpārbauda pasūtījuma statuss, līgumi, rēķini vai atbalsta pieteikumi, mainās ne tikai saturs. Rodas jauna drošības robeža. Autentificētam AI čatbotam ir precīzi jānošķir identitāte, tiesības, sesija un konkrēta darbība.

Tāpēc svarīgākais arhitektūras lēmums nav: „Kādu modeli mēs izmantosim?“ Tas ir: „Kāda informācija un kāda darbība ir atļauta kurā uzticamības zonā?“ Tie, kas atbild uz šo jautājumu pirms sistēmas uzvednes dizaina, samazina datu noplūdes, nepareizu kontu piesaisti un nevēlamas darbības. Tālāk sniegtā rokasgrāmata ir tehniska un organizatoriska orientācija, nevis individuāla juridiskā konsultācija.

Kāpēc publiskais un autentificētais režīms ir divi atšķirīgi darbības veidi

Publiskajā tērzēšanā persona sākotnēji nav zināma. Sistēma labākajā gadījumā var zināt sarunas kontekstu, izvēlēto valodu un tehniski nepieciešamos sesijas datus. Tāpēc atbildēm vajadzētu aprobežoties ar apstiprinātiem, vispārpieejamiem avotiem. Ievadīta e-pasta adrese, pasūtījuma numurs vai apgalvojums „Tas ir mans līgums“ vēl nav tiesību apliecinājums.

Turpretī klientu portālā pastāv pieteikusies sesija. Bet arī tur spēkā ir noteikums: pieteikšanās nenozīmē, ka katrs resurss un katra darbība ir automātiski atļauta. OWASP Authentication Cheat Sheet nošķir autentifikāciju, identitātes pārbaudi un sesiju pārvaldību. Pašreizējās NIST Digital Identity Guidelines, Revision 4 arī izskata identitātes pārbaudi, autentifikāciju un federāciju kā atsevišķus blokus. Tīmekļa vietņu komandām no tā izriet: čatbots drīkst izmantot tikai tos uzticamības signālus, kurus pierādāmi nodrošina ietverošā sistēma.

Trīs zonas visvarena čatbota vietā

Izturīgs risinājums sadala zināšanas un rīkus vismaz trīs zonās:

• Publiskā zona: apstiprināts tīmekļa vietnes saturs, vispārīga informācija par produktiem, procesi, saziņas veidi un nesaistoša palīdzība.
• Autentificētā zona: dati un procesi, kas ir piesaistīti pieteiktajam kontam, organizācijai, lomai vai tiesībām.
• Īpaši aizsargātā zona: jutīgas izmaiņas, izmaksas, līgumu slēgšana, jaunas piegādes adreses, tiesību maiņa vai citas darbības, kurām nepieciešams papildu apstiprinājums vai cilvēka pārbaude.

Šīm zonām vajadzētu būt definētām ne tikai sistēmas uzvednē. Tām jābūt atspoguļotām datu avotos, API, lomās, rīku tiesībās un servera puses pārbaudēs. Uzvedne var novirzīt uzvedību, bet tā nav piekļuves kontrole. Tas pats attiecas uz RAG: meklēšana publiskajos un privātajos dokumentos kopīgā, nefiltrētā indeksā rada nevajardzīgi plašu uzbrukumu virsmu.

Autentifikācija nav autorizācija

Vienkāršoti runājot, autentifikācija atbild uz jautājumu: „Kāda digitālā identitāte ir pieteikusies?“ Autorizācija atbild: „Vai šī identitāte drīkst lasīt tieši šo objektu vai izpildīt šo funkciju?“ Čatbotā šī atšķirība viegli izplūst, jo lietotāji dabiski formulē objektu numurus: „Parādi man rēķinu 4711“ vai „Maini adresi pasūtījumam 815“.

OWASP ieteikumi pret IDOR pieprasa uz objektu attiecināmu tiesību pārbaudi pat tad, ja identifikatorus ir grūti uzminēt. Praksē tas nozīmē: serveris nosaka pašreizējo kontu no aizsargātās sesijas un pie katra pieprasījuma pārbauda, vai rēķins, pasūtījums vai pieteikums pieder šai atļautajai datu telpai. Valodas modelis nedrīkst pieņemt brīvi ievadītu klienta vai objekta ID kā uzticamības pamatu.

Ko drīkst atbildēt publiskās tīmekļa vietnes čatbots

Publiskajai zonai pozitīvais saraksts ir labāks par garu aizliegumu sarakstu. Atļauti var būt, piemēram, atgriešanas termiņi, piegādes reģioni, produktu īpašības, pamācības, vispārīgā cenu loģika vai ceļš uz pieteikšanos. Nav atļauti individuāli pasūtījumu statusi, līgumu detaļas, personīgās tikšanās, iekšējās piezīmes vai paziņojums par to, vai konkrēts konts vispār pastāv.

Arī šķietami nekaitīgas atbildes var atklāt informāciju. „Ar šo e-pasta adresi konts neeksistē“ apstiprina pārbaudes mēģinājumu. Neitrāla atbilde, piemēram, „Lūdzu, piesakieties klientu portālā, lai piekļūtu ar kontu saistītajai informācijai“, saglabā drošu robežu. Manipulācijas mēģinājumiem ir nepieciešami papildu aizsardzības pasākumi, kā aprakstīts rakstā Prompt Injection bei Website-Chatbots.

Kas papildus nepieciešams autentificētam AI čatbotam

Pēc pieteikšanās asistents drīkst darīt vairāk, taču tikai servera pusē noteiktā konteksta ietvaros. Lietderīgi ievaddati ir iekšējā sesijas atsauce, atļautā organizācija vai klients, lomas, kā arī šauri definēts funkciju apjoms. Neapstrādāti piekļuves dati, paroles, pilni sesijas žetoni vai nevajadzīgi personas datu lauki nepieder modeļa kontekstam.

OWASP Authorization Cheat Sheet iesaka tiesību pārbaudi katram konkrētam resursam un funkcijai. Rīku izsaukumiem tas nozīmē: nevis modelis pieņem lēmumu, vai rēķins ir redzams, bet gan tas lūdz pakalpojumam atļauto informāciju; pakalpojums no jauna pārbauda sesiju, lomu, klientu un objektu. Tērzēšana pēc tam saņem tikai atbildei nepieciešamos laukus.

Datu un rīku robežu praktiska nošķiršana

Lasīšanai un rakstīšanai vajadzētu būt atsevišķiem rīkiem. Rīks „Pārvaldīt klienta kontu“ ir pārāk plašs. Labākas ir mazas funkcijas, piemēram, „uzskaitīt savus atvērtos pasūtījumus“, „lasīt atļautā pasūtījuma statusu“ vai „sagatavot atbalsta pieteikumu“. Katrai funkcijai tiek piešķirta minimāla ievades shēma, servera puses tiesību pārbaude, saprotami kļūdu gadījumi un ierobežota izvade.

RAG gadījumā ieteicama tā pati loģika: publiskie avoti publiskā meklēšanas telpā, ar kontu saistītie dokumenti klientu un lomu filtrētā meklēšanas telpā. Filtri tiek izveidoti servera pusē no sesijas, nevis no brīvi formulētām norādēm tērzēšanā. Izmaiņas avotos, lomās un atļaujās pieder dokumentētai procedūrai; veidne ir sniegta rakstā par Content Governance und Change Control.

Sesijas beigas, izrakstīšanās un koplietojamu ierīču ņemšana vērā

Tērzēšanas saskarne nedrīkst radīt iespaidu, ka tiesības paliek spēkā nenoteiktu laiku. OWASP Session Management Cheat Sheet raksturo sesiju kā savienojumu starp autentifikāciju, HTTP trafiku un piekļuves kontroli. Ja sesijai beidzas termiņš, nākamajam privāto datu pieprasījumam droši jāneizdodas. Veca atbilde redzamajā vēsturē nedrīkst tikt interpretēta kā jauna tiesība.

Komandām vajadzētu arī pārbaudīt izrakstīšanos, konta maiņu, lomu izmaiņas un koplietojamās ierīces. Privātās sarunu vēstures pēc konta maiņas nedrīkst parādīties nākamajam kontam. Ja sesijai beidzies termiņš, asistentam skaidri jāvada lietotājs uz atkārtotu pieteikšanos, neatkārtojot jutīgas detaļas no iepriekšējās sesijas. Žurnālēšanai un analīzei tiek piemērota datu minimizēšana; raksts par datensparsamer Chatbot-Analytics parāda piemērotas notikumu un uzglabāšanas robežas.

Jutīgām darbībām nepieciešams atsevišķs apstiprinājums

Ar pieteikšanos portālā ne vienmēr pietiek katrai darbībai. Ja čatbots maina piegādes adresi, apstiprina līgumu vai veic maksājumu, sistēmai jāpieprasa skaidri atpazīstams, uz darbību attiecināms apstiprinājums. OWASP Transaction Authorization Cheat Sheet nošķir pieteikšanos no darījuma apstiprināšanas un pieprasa servera puses kontroles, kā arī būtisko darījuma datu pārbaudi.

Drošs paraugs ir šāds: čatbots apkopo vēlmi, parāda saprotamu kopsavilkumu, portāls pārbauda pašreizējās tiesības un nepieciešamības gadījumā pieprasa atkārtotu autentifikāciju vai otro faktoru. Tikai pēc tam servera puses pakalpojums izpilda tieši apstiprināto darbību. Ja mainās mērķis, summa vai citi būtiskie dati, iepriekšējais apstiprinājums zaudē spēku.

Piemērs: Preču atgriešana bez datu noplūdes

Anonīma persona jautā: „Vai es varu atgriezt savu pasūtījumu?“ Publiskais čatbots paskaidro vispārīgo atgriešanas loģiku un sniedz saiti uz portālu. Tas neprasa pilnu adresi vai maksājumu datus. Pēc pieteikšanās portāla čatbots, izmantojot lasīšanas rīku, var uzskaitīt paša lietotāja atgriežamos pasūtījumus. Ja persona izvēlas pasūtījumu, serveris vēlreiz pārbauda objekta tiesības un spēkā esošos noteikumus.

Faktiskajai atgriešanai atsevišķs darbības rīks ģenerē kopsavilkumu. Persona apstiprina preces un saņemšanas opciju portāla saskarnē. Ja pārbaude neizdodas, čatbots nesauc iekšējos riska signālus, bet gan piedāvā drošu nākamo soli. Ja nepieciešama cilvēka iesaiste, seko kontrolēta Human Handoff ar tikai nepieciešamo, apstiprināto kontekstu.

Testēšanas matrica pirms palaišanas

Testēšanas matricai nevajadzētu pārbaudīt tikai ideālos scenārijus. Izmantojiet vismaz divus kontus ar līdzīgām lomām un atsevišķiem datiem un pārbaudiet šādus gadījumus:

• Anonīms pieprasījums pēc vispārīgas informācijas un pēc privātiem konta datiem.
• Pieteicies konts A nolasa savu objektu un pēc tam mēģina izmantot konta B objekta identifikatoru.
• Sesijas beigas, izrakstīšanās, konta maiņa un lomas atsaukšana aktīvas tērzēšanas laikā.
• Valodas maiņa procesa vidū, nemainot datu telpu vai tiesības.
• Prompt Injection lietotāja ievadē un izgūtajos dokumentos.
• Lasīšanas rīka atteice, noildze un pretrunīgi aizmugursistēmas dati.
• Rakstīšanas darbība bez apstiprinājuma, ar izmainītiem datiem un ar beigušos apstiprinājuma termiņu.
• Nodošana cilvēkam ar minimālu, saprotamu sarunas kontekstu.

Gaidāmajiem rezultātiem jābūt iepriekš definētiem testā: kāda atbilde ir publiski atļauta? Kāda HTTP kļūda rodas servera pusē? Kāda informācija drīkst būt redzama tērzēšanā? Kāds notikums tiek reģistrēts žurnālā bez konfidenciāla satura? Plānots ierobežotas darbības režīms (degraded mode) palīdz, ja identitātes vai aizmugursistēmas pakalpojumi nedarbojas; tam ir paredzēta atsevišķa Incident-Response- und Rollback-Leitfaden.

Pārbaudes saraksts uzticamai portāla robežai

• Dokumentēt publisko, autentificēto un īpaši aizsargāto zonu.
• Atsevišķi modelēt autentifikāciju, autorizāciju un darījuma apstiprināšanu.
• Noteikt kontu un klientu no drošās sesijas.
• Pārbaudīt objekta tiesības servera pusē pie katras lasīšanas un rakstīšanas.
• Tehniski nošķirt un filtrēt publiskos un privātos RAG avotus.
• Piemērot minimālo rīku tiesību principu; nošķirt lasīšanu un rakstīšanu.
• Ņemt vērā sesijas beigas, izrakstīšanos, konta maiņu un lomu izmaiņas tērzēšanā.
• Skaidri apkopot jutīgas darbības un lūgt mērķtiecīgu apstiprinājumu.
• Ierobežot nodošanu operatoram un žurnālēšanu līdz nepieciešamajiem datiem.
• Atkārtoti testēt horizontālās piekļuves mēģinājumus ar vismaz diviem kontiem.

Autentificēts AI čatbots nekļūst drošs tikai tāpēc, ka tas atrodas aiz pieteikšanās ekrāna. Drošība rodas tad, ja katrai informācijai un katrai darbībai ir pārbaudāma robeža. Tāpēc sāciet ar zonu karti un testēšanas matricu, pirms pievienojat privātos datu avotus vai rakstīšanas rīkus. Tādējādi publiskais čatbots paliek noderīgs, bet portāla čatbots – rīcībspējīgs, nesajaucot abas uzticamības zonas.

Avoti

• 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