L’ennesimo incidente di sicurezza che coinvolge un fornitore mette nel mirino LastPass. Questa volta non sono sotto attacco i suoi celebri vault crittografati, ma i dati personali dei clienti custoditi in Salesforce, il sistema CRM usato per l’assistenza. E il punto di ingresso non è stato un attacco diretto all’infrastruttura di LastPass, bensì una falla in Klue, fornitore di competitive intelligence che deteneva token OAuth con accesso all’ambiente Salesforce del gestore di password.

L’incidente: cosa è successo

LastPass ha iniziato a notificare i propri clienti dopo che, nelle scorse settimane, i pirati informatici hanno violato i sistemi di Klue, un vendor specializzato in analisi competitiva. Klue conservava token OAuth che garantivano l’accesso programmatico all’istanza Salesforce di LastPass. Sfruttando quei token, gli attaccanti hanno potuto estrarre dati personali e contenuti dei ticket di assistenza: nomi, numeri di telefono, indirizzi email e dettagli dei casi di supporto.

L’azienda rassicura che la violazione non ha compromesso né i propri server, né i vault crittografati degli utenti, che restano inaccessibili agli estranei. Tuttavia, i dati sottratti possono essere utilizzati per attacchi di phishing mirato o per social engineering, e rappresentano una minaccia concreta per la privacy delle persone coinvolte. L’accaduto conferma quanto sia insidiosa la catena dei fornitori: un partner apparentemente marginale, se dotato di privilegi eccessivi, può diventare il tallone d’Achille.

Il ruolo dei token OAuth e l’ambiente Salesforce

Al centro della vicenda ci sono i token OAuth, meccanismi standard per consentire a servizi terzi di operare su piattaforme cloud senza richiedere ogni volta le credenziali dell’utente. Klue li utilizzava per accedere in modo automatizzato ai dati di Salesforce, probabilmente per incrociare informazioni competitive con le richieste di assistenza dei clienti. Quando i sistemi di Klue sono stati compromessi, i token sono diventati una chiave d’accesso diretta all’ambiente Salesforce di LastPass, senza bisogno di violare ulteriori barriere.

Salesforce è un bersaglio sensibile per molte organizzazioni, poiché raccoglie dati di clienti, contratti e comunicazioni. Un accesso non autorizzato a queste informazioni, anche se separato dai sistemi core, può causare danni reputazionali e conformità, soprattutto in settori regolati. La natura “fiduciaria” del modello OAuth implica che la compromissione del fornitore si trasformi in una compromissione del cliente, senza che quest’ultimo abbia subito un attacco diretto.

Supply chain e sovranità dei dati: lezioni per chi sceglie l’on-premise

L’episodio LastPass-Klue offre spunti importanti per chi gestisce infrastrutture on-premise, tipicamente mosso da esigenze di controllo e sovranità dei dati. Sebbene l’incidente riguardi un servizio cloud come Salesforce, il principio vale anche in contesti locali: integrazioni con fornitori esterni — CRM, piattaforme di analytics, sistemi di ticketing — possono introdurre vettori di attacco imprevisti. Un token OAuth con scoping troppo ampio o una chiave API non ruotata a dovere rappresentano una minaccia ugualmente seria all’interno della rete aziendale.

Per chi ospita LLM e pipeline di inference in sede, magari in configurazione air-gapped, il rischio supply chain si manifesta nell’ecosistema di tool collegati: software di monitoring, database vettoriali, sistemi di logging. Un vendor compromesso che detiene credenziali per ambienti di staging o produzione può aprire una breccia anche nel perimetro più blindato. La lezione è chiara: i token di accesso vanno trattati come credenziali primarie, con politiche di least privilege, rotazione forzata e audit costante. Non basta proteggere il core (vault, dati sensibili) se poi si lascia la porta socchiusa attraverso terze parti.

Gestire il rischio dei vendor: un approccio strutturato

La vicenda rinforza la necessità di valutare i fornitori non solo in base alle funzionalità, ma anche alla loro postura di sicurezza. In fase di procurement, occorre mappare i permessi che ogni integrazione richiede, limitandoli allo stretto indispensabile e prevedendo contrattualmente obblighi di notifica immediata in caso di incidente. Strumenti come l’Identity and Access Management (IAM) e la gestione dei segreti (vault per chiavi e token) aiutano a contenere il danno quando un partner viene compromesso.

Per chi adotta architetture on-premise per LLM o altri carichi AI, la superficie d’attacco si estende ai servizi integrativi esterni che alimentano i modelli (pipeline di dati, API di arricchimento, strumenti di valutazione). La domanda da porsi non è se un vendor sarà mai violato, ma quanto l’azienda è pronta a isolare l’impatto di quella violazione senza mettere a repentaglio i dati e i modelli addestrati. Un framework di analisi dei rischi, come quello proposto da AI-RADAR per i deployment on-premise, aiuta a mappare dipendenze e privilegi, trasformando un incidente come quello di LastPass da allarme generico a caso di studio concreto.