Chatbot IA pubblico vs. Portale Clienti: Separare in modo sicuro identità e accesso ai dati

Un chatbot su un sito web pubblico può rispondere alle domande sui prodotti, spiegare gli orari di apertura o indirizzare alla pagina di servizio idonea. Tuttavia, quando deve consultare lo stato degli ordini, i contratti, le fatture o i casi di supporto all'interno di un portale clienti, non cambia solo il contenuto. Si crea un nuovo confine di sicurezza. Un chatbot IA autenticato deve separare nettamente identità, autorizzazione, sessione e azione concreta.

La decisione architetturale più importante non è quindi: «Quale modello utilizziamo?», bensì: «Quale informazione e quale azione sono consentite in ciascun livello di fiducia?». Rispondere a questa domanda prima di progettare i prompt riduce le fughe di dati, le errate associazioni di account e le azioni indesiderate. La seguente guida offre un orientamento tecnico e organizzativo, non una consulenza legale individuale.

Perché pubblico e autenticato sono due modalità operative distinte

Nella chat pubblica, l'utente è inizialmente sconosciuto. Il sistema può conoscere al massimo il contesto della conversazione, la lingua selezionata e i dati di sessione tecnicamente necessari. Le risposte dovrebbero quindi limitarsi a fonti approvate e liberamente accessibili. Un indirizzo e-mail, un numero d'ordine inserito o una dichiarazione come «Questo è il mio contratto» non costituiscono una prova di autorizzazione.

Nel portale clienti, al contrario, esiste una sessione autenticata. Tuttavia, anche in questo caso vale il principio che l'accesso non implica automaticamente l'autorizzazione a qualsiasi risorsa o azione. Il Cheat Sheet sull'autenticazione OWASP distingue tra autenticazione, verifica dell'identità e gestione della sessione. Anche le attuali NIST Digital Identity Guidelines, Revisione 4 trattano la verifica dell'identità, l'autenticazione e la federazione come moduli distinti. Per i team che gestiscono i siti web ne consegue che la chat può utilizzare solo i segnali di fiducia forniti in modo verificabile dal sistema circostante.

Tre zone anziché un chatbot onnipotente

Una soluzione solida suddivide le conoscenze e gli strumenti in almeno tre zone:

• Zona pubblica: contenuti del sito web approvati, informazioni generali sui prodotti, processi, canali di contatto e assistenza non vincolante.
• Zona autenticata: dati e operazioni vincolati all'account connesso, a un'organizzazione, a un ruolo o a un'autorizzazione specifica.
• Zona ad alta protezione: modifiche sensibili, pagamenti, stipula di contratti, nuovi indirizzi di consegna, cambi di autorizzazione o altre azioni che richiedono un'ulteriore conferma o una verifica umana.

Queste zone non dovrebbero figurare soltanto nel prompt di sistema. Devono essere definite nelle fonti dati, nelle API, nei ruoli, nei permessi degli strumenti e nei controlli lato server. Un prompt può guidare il comportamento, ma non costituisce un controllo degli accessi. Lo stesso vale per la RAG: una ricerca eseguita su documenti pubblici e privati in un indice comune e non filtrato crea una superficie di attacco inutilmente ampia.

L'autenticazione non è l'autorizzazione

In parole semplici, l'autenticazione risponde a: «Quale identità digitale ha effettuato l'accesso?». L'autorizzazione risponde a: «Questa identità può leggere esattamente questo oggetto o eseguire questa funzione?». Nella chat questa differenza tende facilmente a sfumare, poiché gli utenti formulano i numeri d'oggetto in modo naturale: «Mostrami la fattura 4711» o «Modifica l'indirizzo per l'ordine 815».

Le raccomandazioni OWASP contro l'IDOR richiedono un controllo delle autorizzazioni riferito al singolo oggetto, anche se gli identificatori sono difficili da indovinare. In pratica, ciò significa che il server ricava l'account corrente dalla sessione protetta e verifica ad ogni richiesta se la fattura, l'ordine o il ticket appartengono allo spazio dati consentito. Il modello linguistico non deve mai accettare un ID cliente o un ID oggetto liberamente inserito come elemento di fiducia.

Cosa può rispondere la chat pubblica del sito web

Per l'area pubblica, una lista di autorizzazioni (allowlist) è preferibile a un lungo elenco di divieti. Possono essere autorizzati, ad esempio, i termini di reso, le aree di consegna, le caratteristiche dei prodotti, i manuali d'uso, la logica generale dei prezzi o le indicazioni per effettuare il login. Non sono invece autorizzati lo stato dei singoli ordini, i dettagli contrattuali, gli appuntamenti personali, le note interne o l'indicazione se un determinato account esista o meno.

Anche risposte apparentemente innocue possono rivelare informazioni. Rispondere «Non esiste alcun account per questo indirizzo e-mail» conferma un tentativo di verifica. Una risposta neutrale come «Effettui l'accesso al portale clienti per recuperare le informazioni relative all'account» mantiene saldo il confine. Per i tentativi di manipolazione sono necessarie ulteriori misure di protezione, come quelle descritte nell'articolo Prompt Injection nei chatbot per siti web.

Cosa occorre in più al chatbot IA autenticato

Dopo il login, l'assistente dispone di maggiori permessi, ma solo all'interno del contesto stabilito lato server. I dati in ingresso appropriati sono un riferimento di sessione interno, l'organizzazione o il tenant autorizzato, i ruoli e un insieme di funzioni strettamente definito. Credenziali grezze, password, token di sessione completi o campi di dati personali non necessari non devono figurare nel contesto del modello.

Il Cheat Sheet sull'autorizzazione OWASP raccomanda verifiche delle autorizzazioni per ogni singola risorsa e funzione. Per le chiamate agli strumenti ciò significa: non è il modello a decidere se una fattura è visibile. Il modello richiede l'informazione consentita a un servizio; il servizio verifica nuovamente sessione, ruolo, tenant e oggetto. Successivamente, la chat riceve soltanto i campi necessari per elaborare la risposta.

Definire in pratica i confini di dati e strumenti

Lettura e scrittura dovrebbero essere gestite da strumenti distinti. Un tool generico come «gestisci account cliente» è troppo ampio. È preferibile optare per piccole funzioni come «elenca propri ordini aperti», «leggi stato di un ordine autorizzato» o «prepara ticket di supporto». Ogni funzione riceve uno schema di input minimo, una verifica delle autorizzazioni lato server, casi di errore trasparenti e un output limitato.

La medesima logica si applica alla RAG: le fonti pubbliche vanno inserite in uno spazio di ricerca pubblico, mentre i documenti legati all'account in uno spazio di ricerca filtrato per tenant e ruoli. I filtri vengono generati lato server a partire dalla sessione, non dalle indicazioni espresse liberamente nella chat. Le modifiche a fonti, ruoli e autorizzazioni devono seguire una procedura documentata; un modello è fornito nell'articolo su Content Governance e Change Control.

Gestire scadenza della sessione, logout e dispositivi condivisi

Un'interfaccia di chat non deve dare l'impressione che un'autorizzazione rimanga valida a tempo indeterminato. Il Cheat Sheet sulla gestione delle sessioni OWASP descrive la sessione come l'elemento di collegamento tra autenticazione, traffico HTTP e controllo degli accessi. Quando la sessione scade, il successivo recupero di dati privati deve fallire in modo sicuro. Una vecchia risposta visibile nella cronologia non deve essere interpretata come una nuova autorizzazione.

I team dovrebbero inoltre testare le procedure di logout, cambio account, modifica dei ruoli e dispositivi condivisi. Le cronologie di conversazione private non devono comparire nell'account successivo dopo un cambio utente. In caso di sessione scaduta, l'assistente deve guidare chiaramente l'utente a effettuare nuovamente il login, senza ripetere dettagli sensibili della sessione precedente. Per la registrazione e l'analisi dei dati si applica il principio di minimizzazione dei dati; l'articolo su analytics per chatbot con minimizzazione dei dati illustra limiti adeguati per eventi e conservazione.

Le azioni sensibili richiedono una conferma dedicata

L'accesso al portale non è necessariamente sufficiente per ogni tipo di operazione. Se la chat modifica un indirizzo di spedizione, conferma un contratto o avvia un pagamento, il sistema deve richiedere una conferma ben visibile e specifica per l'azione. Il Cheat Sheet sull'autorizzazione delle transazioni OWASP separa l'autenticazione dall'approvazione delle transazioni, richiedendo controlli lato server e la verifica dei dati fondamentali della transazione.

Un modello sicuro funziona così: la chat recepisce la richiesta, mostra un riepilogo comprensibile, il portale verifica l'autorizzazione corrente e, se necessario, richiede una nuova autenticazione o un secondo fattore. Solo a quel punto un servizio lato server esegue l'azione esattamente confermata. Se l'obiettivo, l'importo o altri dati essenziali cambiano, l'autorizzazione precedente decade.

Esempio: gestione di un reso senza fughe di dati

Un utente anonimo chiede: «Posso restituire il mio ordine?». La chat pubblica spiega la procedura generale di reso e fornisce il link al portale. Non richiede l'indirizzo completo o i dati di pagamento. Dopo il login, la chat del portale può elencare gli ordini idonei al reso tramite uno strumento di sola lettura. Quando l'utente seleziona un ordine, il server verifica nuovamente i permessi sull'oggetto e le regole applicabili.

Per la restituzione effettiva, uno strumento di azione separato genera un riepilogo. L'utente conferma gli articoli e la modalità di ritiro nell'interfaccia del portale. Se la verifica fallisce, la chat non rivela segnali di rischio interni, ma offre un passaggio successivo sicuro. Qualora sia necessario un chiarimento umano, viene avviato un Human Handoff controllato che trasmette unicamente il contesto necessario e autorizzato.

Matrice di test prima del go-live

Una matrice di test non dovrebbe verificare solo i casi d'uso lineari (happy path). Utilizzate almeno due account con ruoli simili ma dati separati e testate i seguenti casi:

• Richiesta anonima di informazioni generali e di dati personali dell'account.
• L'account A autenticato legge un proprio oggetto e successivamente tenta di accedere all'identificativo di un oggetto dell'account B.
• Sessione scaduta, logout, cambio account e revoca dei ruoli durante una chat in corso.
• Cambio di lingua a metà dell'operazione, senza che lo spazio dati o le autorizzazioni modifichino il loro perimetro.
• Prompt Injection negli input degli utenti e nei documenti recuperati.
• Mancato funzionamento di uno strumento di lettura, timeout e dati incoerenti nel backend.
• Azione di scrittura senza conferma, con dati modificati e con conferma scaduta.
• Handoff all'operatore umano con un contesto di conversazione minimo e verificabile.

I risultati attesi devono essere definiti in anticipo nel test: quale risposta è consentita pubblicamente? Quale errore HTTP si genera lato server? Quale informazione può essere visibile nella chat? Quale evento viene registrato senza includere contenuti riservati? Una modalità degradata (degraded mode) pianificata è d'aiuto in caso di malfunzionamento dei servizi di identità o di backend; a questo proposito esiste una guida alla risposta agli incidenti e al rollback dedicata.

Checklist per un confine di portale affidabile

• Documentare la zona pubblica, la zona autenticata e la zona ad alta protezione.
• Modellare separatamente autenticazione, autorizzazione e approvazione delle transazioni.
• Ricavare l'account e il tenant dalla sessione sicura.
• Verificare lato server le autorizzazioni sugli oggetti per ogni operazione di lettura e scrittura.
• Separare e filtrare tecnicamente le fonti RAG pubbliche e private.
• Limitare i permessi degli strumenti al minimo necessario; separare lettura e scrittura.
• Gestire nella chat la scadenza della sessione, il logout, il cambio account e le modifiche dei ruoli.
• Riepilogare chiaramente le azioni sensibili e richiederne una conferma specifica.
• Limitare l'handoff e la registrazione dei dati alle sole informazioni necessarie.
• Testare in modo riproducibile i tentativi di accesso orizzontale utilizzando almeno due account.

Un chatbot IA autenticato non diventa sicuro semplicemente perché appare dietro una schermata di login. La sicurezza si ottiene quando ogni informazione e ogni azione possiedono un confine verificabile. Iniziate quindi mappando le zone e predisponendo la matrice di test prima di collegare fonti dati private o strumenti di scrittura. In questo modo, la chat pubblica rimarrà utile e la chat del portale operativa, senza mai sovrapporre i due livelli di fiducia.

Fonti

• 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