Chatbot IA public vs. portal clienți: Separarea sigură a identității și a accesului la date

Un chatbot de pe un site web public poate răspunde la întrebări despre produse, poate explica orele de program sau poate direcționa către pagina de servicii potrivită. Cu toate acestea, de îndată ce ar trebui să vizualizeze statusul comenzilor, contractele, facturile sau cazurile de suport într-un portal pentru clienți, nu se schimbă doar conținutul. Se creează o nouă limită de securitate. Un chatbot IA autentificat trebuie să separe clar identitatea, permisiunea, sesiunea și acțiunea concretă.

Prin urmare, cea mai importantă decizie de arhitectură nu este: „Ce model folosim?”, ci: „Ce informație și ce acțiune sunt permise în fiecare zonă de încredere?” Oricine răspunde la această întrebare înainte de proiectarea prompturilor reduce scurgerile de date, atribuirile incorecte ale conturilor și acțiunile nedorite. Ghidul următor este o orientare tehnică și organizațională, nu o consultanță juridică individuală.

De ce modul public și cel autentificat sunt două moduri de operare diferite

În chatul public, persoana este inițial necunoscută. Sistemul poate cunoaște cel mult contextul conversației, limba selectată și datele de sesiune necesare din punct de vedere tehnic. Prin urmare, răspunsurile ar trebui să se limiteze la surse aprobate, accesibile publicului. O adresă de e-mail introdusă, un număr de comandă sau o afirmație precum „Acesta este contractul meu” nu reprezintă încă o dovadă de autorizare.

În schimb, în portalul pentru clienți există o sesiune autentificată. Dar și acolo se aplică regula: autentificarea nu înseamnă automat că fiecare resursă și fiecare acțiune sunt permise. OWASP Authentication Cheat Sheet face diferența între autentificare, verificarea identității și gestionarea sesiunii. Ghidul actualizat NIST Digital Identity Guidelines, Revision 4 tratează, de asemenea, verificarea identității, autentificarea și federația ca componente separate. Pentru echipele web, concluzia este: chatul poate utiliza doar semnalele de încredere pe care sistemul gazdă le furnizează în mod verificabil.

Trei zone în loc de un chatbot atotputernic

O soluție robustă împarte cunoștințele și instrumentele în cel puțin trei zone:

• Zona publică: conținut aprobat al site-ului web, informații generale despre produse, procese, opțiuni de contact și asistență neobligatorie.
• Zona autentificată: date și operațiuni legate de contul autentificat, o organizație, un rol sau o permisiune.
• Zona cu protecție sporită: modificări sensibile, plăți, încheierea de contracte, adrese noi de livrare, schimbări de permisiuni sau alte acțiuni care necesită o confirmare suplimentară sau o verificare umană.

Aceste zone nu ar trebui definite doar în promptul de sistem. Ele trebuie să fie reflectate în sursele de date, API-uri, roluri, permisiunile instrumentelor și verificările de pe server. Un prompt poate ghida comportamentul, dar nu este un control al accesului. Același lucru este valabil și pentru RAG: o căutare în documente publice și private dintr-un index comun, nefiltrat, creează o suprafață de atac inutil de mare.

Autentificarea nu este autorizare

Pe scurt, autentificarea răspunde la întrebarea: „Ce identitate digitală este conectată?”. Autorizarea răspunde la: „Are voie această identitate să citească exact acest obiect sau să execute această funcție?”. În chat, această diferență este ușor estompată, deoarece utilizatorii formulează în mod natural numere de obiecte: „Arată-mi factura 4711” sau „Schimbă adresa pentru comanda 815”.

Recomandările OWASP împotriva IDOR cer o verificare a permisiunilor bazată pe obiecte, chiar și atunci când identificatorii sunt greu de ghicit. În practică, acest lucru înseamnă că serverul derivă contul curent din sesiunea protejată și verifică la fiecare solicitare dacă factura, comanda sau tichetul aparține acelui spațiu de date permis. Modelul de limbaj nu trebuie să preia ca ancoră de încredere un ID de client sau de obiect introdus liber.

La ce poate răspunde chatul public de pe site

Pentru zona publică, o listă albă este mai bună decât o listă lungă de interdicții. Pot fi aprobate, de exemplu, termenele de returnare, regiunile de livrare, caracteristicile produselor, ghidurile, logica generală de prețuri sau calea către autentificare. Nu sunt aprobate statusurile individuale ale comenzilor, detaliile contractuale, programările personale, notele interne sau confirmarea dacă un anumit cont există.

Chiar și răspunsurile aparent inofensive pot divulga informații. „Nu există niciun cont asociat acestei adrese de e-mail” confirmă o încercare de verificare. Un răspuns neutru precum „Autentificați-vă în portalul pentru clienți pentru a accesa informațiile legate de cont” menține limita stabilă. Pentru încercările de manipulare, sunt necesare măsuri de protecție suplimentare, așa cum descrie articolul despre Prompt Injection la chatboturile pentru site-uri web.

Ce îi mai trebuie unui chatbot IA autentificat

După autentificare, asistentul are voie să facă mai multe, dar numai în cadrul contextului determinat pe server. Datele de intrare adecvate sunt o referință internă de sesiune, organizația sau entitatea permisă, rolurile și o sferă de funcționalitate restrânsă. Datele de acces brute, parolele, jetoanele complete de sesiune sau câmpurile cu date cu caracter personal inutile nu au ce căuta în contextul modelului.

OWASP Authorization Cheat Sheet recomandă verificări ale permisiunilor pentru fiecare resursă și funcție concretă. Pentru apelurile de instrumente, acest lucru înseamnă că nu modelul decide dacă o factură este vizibilă. Modelul solicită unui serviciu informațiile permise, iar serviciul verifică din nou sesiunea, rolul, entitatea și obiectul. Chatul primește apoi doar câmpurile necesare pentru răspuns.

Definirea practică a limitelor de date și instrumente

Citirea și scrierea ar trebui să fie instrumente separate. Un instrument intitulat „Gestionare cont client” este prea vast. Mai bune sunt funcțiile mici, cum ar fi „listare comenzi proprii deschise”, „citire status comanda permisă” sau „pregătire caz de suport”. Fiecare funcție primește o schemă minimă de intrare, o verificare a permisiunilor pe server, cazuri de eroare clare și o ieșire limitată.

Pentru RAG se recomandă aceeași logică: sursele publice într-un spațiu de căutare public, iar documentele legate de cont într-un spațiu de căutare filtrat în funcție de entitate și rol. Filtrele sunt generate pe server din sesiune, nu din indicațiile exprimate liber în chat. Modificările aduse surselor, rolurilor și aprobărilor aparțin unui proces documentat; un șablon este oferit în articolul despre Content Governance și Change Control.

Luarea în considerare a expirării sesiunii, deconectării și dispozitivelor partajate

Interfața de chat nu trebuie să lase impresia că o permisiune rămâne valabilă pe termen nelimitat. OWASP Session Management Cheat Sheet descrie sesiunea ca fiind legătura dintre autentificare, traficul HTTP și controlul accesului. Dacă sesiunea expiră, următoarea preluare de date private trebuie să eșueze în siguranță. Un răspuns vechi din istoricul vizibil nu trebuie interpretat ca o nouă autorizație.

Echipele ar trebui, de asemenea, să testeze deconectarea, schimbarea contului, modificarea rolurilor și dispozitivele utilizate în comun. Istoricul conversațiilor private nu trebuie să apară la următorul cont după o schimbare. Asistentul ar trebui să ghideze clar utilizatorul către o nouă autentificare dacă sesiunea a expirat, fără a repeta detalii sensibile din sesiunea anterioară. Pentru jurnalizare și analiză se aplică principiul minimizării datelor; articolul despre analiza datelor chatbot cu minimizarea datelor prezintă limite adecvate pentru evenimente și stocare.

Acțiunile sensibile au nevoie de o confirmare separată

Autentificarea în portal nu este neapărat suficientă pentru orice acțiune. Dacă chatul schimbă o adresă de livrare, confirmă un contract sau declanșează o plată, sistemul ar trebui să solicite o confirmare clară, specifică acțiunii respective. OWASP Transaction Authorization Cheat Sheet separează autentificarea de autorizarea tranzacției și solicită controale pe server, precum și o verificare a datelor esențiale ale tranzacției.

Un model sigur este următorul: chatul colectează solicitarea, afișează un rezumat clar, portalul verifică autorizarea curentă și, dacă este necesar, solicită o reautentificare sau un al doilea factor. Abia după aceea, un serviciu de pe server execută acțiunea confirmată cu exactitate. Dacă destinația, suma sau alte date esențiale se modifică, autorizarea anterioară devine nulă.

Exemplu: Returnare fără scurgeri de date

O persoană anonimă întreabă: „Pot să îmi returnez comanda?”. Chatul public explică logica generală de returnare și oferă un link către portal. Nu solicită adresa completă sau datele de plată. După autentificare, chatul din portal poate lista comenzile proprii care pot fi returnate, utilizând un instrument de citire. Dacă persoana selectează o comandă, serverul verifică din nou permisiunea asupra obiectului și regulile aplicabile.

Pentru returnarea efectivă, un instrument de acțiune separat generează un rezumat. Utilizatorul confirmă articolele și opțiunea de ridicare în interfața portalului. Dacă verificarea eșuează, chatul nu menționează semnale interne de risc, ci oferă un pas următor sigur. Dacă este necesară o clarificare umană, urmează un Human Handoff controlat, transmisiunea conținând doar contextul necesar și aprobat.

Matricea de testare înainte de lansare (Go-live)

O matrice de testare nu ar trebui să verifice doar scenariile ideale (happy paths). Utilizați cel puțin două conturi cu roluri similare, dar cu date separate, și testați următoarele situații:

• Solicitare anonimă pentru informații generale și pentru date private ale contului.
• Contul A autentificat citește un obiect propriu și încearcă apoi identificatorul unui obiect aparținând contului B.
• Sesiune expirată, deconectare, schimbare de cont și revocare a rolului în timpul unui chat în desfășurare.
• Schimbarea limbii în mijlocul procesului, fără ca spațiul de date sau permisiunile să se modifice.
• Prompt Injection în intrările utilizatorului și în documentele preluate.
• Defectarea unui instrument de citire, depășirea timpului de așteptare (timeout) și date contradictorii în backend.
• Acțiune de scriere fără confirmare, cu date modificate și cu confirmare expirată.
• Preluare de către un operator uman (handoff) cu un context de conversație minim și clar.

Rezultatele așteptate trebuie definite în prealabil în teste: Ce răspuns este permis public? Ce eroare HTTP este generată pe server? Ce informație poate fi vizibilă în chat? Ce eveniment este jurnalizat fără conținut confidențial? Un mod degradat (Degraded Mode) planificat ajută atunci când serviciile de identitate sau de backend eșuează; pentru aceasta există un ghid dedicat pentru incident response și rollback.

Listă de verificare pentru o limită solidă a portalului

• Documentarea zonei publice, autentificate și cu protecție sporită.
• Modelarea separată a autentificării, autorizării și aprobării tranzacțiilor.
• Derivarea contului și a entității din sesiunea securizată.
• Verificarea pe server a permisiunilor asupra obiectelor la fiecare citire și scriere.
• Separarea tehnică și filtrarea surselor RAG publice și private.
• Restricționarea minimă a drepturilor instrumentelor; separarea citirii de scriere.
• Luarea în considerare în chat a expirării sesiunii, deconectării, schimbării contului și modificărilor de rol.
• Rezumatul clar al acțiunilor sensibile și solicitarea confirmării specifice.
• Limitarea handoff-ului și a jurnalizării la datele absolut necesare.
• Testarea reproductibilă a încercărilor de acces orizontal cu cel puțin două conturi.

Un chatbot IA autentificat nu devine sigur doar pentru că apare în spatele unui ecran de autentificare. Securitatea apare atunci când fiecare informație și fiecare acțiune au o limită verificabilă. Prin urmare, începeți cu harta zonelor și matricea de testare înainte de a conecta surse de date private sau instrumente de scriere. În acest fel, chatul public rămâne util, iar chatul din portal capătă capacitate de acțiune, fără a amesteca cele două domenii de încredere.

Surse

• 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