Per capire come gestire i token di terze parti, è utile comprendere a fondo cosa accade quando in un’applicazione effettuiamo il login o registrazione veloce con servizi di terze parti (come per esempio i social network). Analizziamo la situazione, anche alla luce della data protection.
Indice degli argomenti
Che cos’è un token di terze parti
Il token tecnicamente è una stringa con caratteri pseudocasuali necessaria per effettuare una autenticazione e tramite la quale è possibile anche avere accesso ai dati dei nostri utenti sulla piattaforma attraverso la quale hanno effettuato il log in.
Supponiamo che il signor Rossi voglia registrarsi alla nostra nuova app e attratto dal “Login con Facebook” si registri tramite Facebook perché sa che generalmente con questa modalità la registrazione o il login è più veloce.
Al signor Rossi apparirà a questo punto una finestra esterna in cui Facebook gli chiederà di accettare che i suoi dati vengano resi accessibili alla nostra applicazione. Se accetta, la nostra applicazione riceverà una callback con il token e le informazioni dell’utente.
In questo meccanismo, il social è come se facesse da “garante” poiché ci assicura che l’utente Rossi è proprietario della sua e-mail (Facebook ha già verificato l’e-mail alla registrazione).
Quando memorizzare il token dell’utente nel nostro database
Per capire se dobbiamo memorizzare il token occorre avere chiaro a cosa serve il token. Un errore ricorrente che noto spesso durante i security assessment è la memorizzazione del token sul database dell’applicativo senza nessun reale motivo.
Se il token ha il solo scopo di validare l’autenticazione e la registrazione, non occorre salvarlo sul database semplicemente perché generalmente non servirà (o non dovrebbe servire) al server.
Quando occorre memorizzarlo? Quando lato server si dovranno effettuare operazioni di lettura o scrittura per conto dell’utente (ad esempio messaggi automatici in bacheca Facebook ogni qualvolta compio un’azione).
In questo caso ovviamente è buona norma cifrare il token nel proprio DB in modo da evitare abusi in caso di incidente e tutelare la privacy dei nostri utenti. Occorre infatti tenere sempre a mente che tramite quel token è possibile avere accesso ai dati dei nostri utenti su Facebook.
Come assicurare la compliance alla normativa privacy
L’utilizzo del social login è sempre più diffuso e presente pressoché in tutte le applicazioni. chiunque sviluppi una app ritiene fondamentale questo strumento in quanto riduce notevolmente i tempi per la registrazione e l’autenticazione, comportando quindi anche un aumento del numero degli utenti i quali, ormai abituati al social login, preferiscono le app che permettono una registrazione più rapida rispetto ad app che ne sono sprovviste e quindi richiedono più tempo per l’inserimento dei dati di registrazione oltre a presupporre che l’utente memorizzi l’ennesimo username e password.
È sicuramente possibile adottare questo strumento assicurando nel contempo la compliance, vediamo come.
Come per ogni trattamento il Titolare dovrà, in prima battuta, garantire il rispetto disposizioni dei principi generali del trattamento di cui all’art. 5 del GDPR, ovvero dovrà essere in grado di dimostrare, tra gli altri, la proporzionalità, la liceità, la minimizzazione dei dati, la limitazione della conservazione, l’integrità e riservatezza dei trattamenti posti in essere.
Per il caso in cui il token sia utilizzato in maniera corretta, e quindi non memorizzato se non necessario, gli adempimenti di compliance sono individuabili nel fornire una informativa all’utente circa il trattamento di dati che avviene tramite il login, effettuare una valutazione dei rischi e quindi considerare la necessità di una valutazione di impatto privacy, inserire il trattamento nel registro, sottoscrivere un Data Protection Agreement con i soggetti che forniscono il log in o servizi collegati, formare ed autorizzare i dipendenti a tale trattamento.
È dall’altro lato interessante analizzare i risvolti sul piano della compliance per i casi, ad oggi purtroppo ancora frequenti, in cui il token, creato per le sole finalità di registrazione ed autenticazione dell’utente, venga conservato nei DB e tale conservazione avvenga per di più “in chiaro”.
Quello che molto spesso non viene compreso da sviluppatori e soggetti proprietari di app è che la conservazione del token in chiaro nei DB, del Titolare o del suo Responsabile, comporta un trattamento di dati non proporzionato alla finalità di permettere la prima registrazione e gli accessi successivi.
Si deve sempre tenere ben presente che il Titolare del trattamento, quindi il proprietario della app, è tenuto, a memoria dell’art. 26 del GDPR, a porre in essere misure tecniche ed organizzative adeguate per garantire ed essere in grado di dimostrare che il trattamento è effettuato conformemente alle disposizioni del GDPR.
Queste misure adeguate devono essere valutate già prima dell’inizio del trattamento stesso e mantenute ad un livello adeguato per tutto il trattamento, quindi nel rispetto dei principi di privacy by design e by default.
Ed è evidente che la conservazione in chiaro nei DB non è conforme a nessuno di questi due ultimi principi. È sufficiente effettuare una sommaria valutazione dei rischi per comprendere quanto sia alta l’esposizione agli stessi e quanto gravi siano le conseguenze di un’eventuale data breach.
Un esempio pratico
Quali conseguenze potrebbe avere, ad esempio, la perdita di dati che consenta ad un terzo l’accesso all’account Google di un singolo utente? Questa violazione è potenzialmente in grado di fornire al terzo la possibilità di accedere ad una miriade di dati personali ed informazioni dell’interessato, come mail, calendario, contatti, foto, eventuali note che possono contenere qualsivoglia tipo di dato o informazione, anche credenziali bancarie o di altra natura.
In questo caso dovranno porsi in essere tutti gli adempi previsti in caso di data breach, ovvero entro 72 ore, dal momento in cui si sia venuti a conoscenza della violazione, notifica all’Autorità Garante per la protezione dei dati e notifica agli interessati.
A seguito della notifica, la quale è obbligatoria nel caso in cui dalla violazione possano derivare rischi per le libertà ed i diritti degli interessati, il Garante può prescrivere misure correttive qualora rilevi una violazione delle disposizioni del GDPR, ovviamente anche con riguardo all’adeguatezza misure di sicurezza tecnico-organizzative poste in essere.
Nel caso in cui l’utente riesca a dimostrare di aver subito un danno materiale o immateriale dalla violazione saranno il Titolare, proprietario della app, e il suo Responsabile, sviluppatore, a doverne rispondere risarcendo l’interessato.
Ed in considerazione dell’inversione dell’onere della prova prevista dall’art. 82 del GDPR questi dovranno dimostrare che l’evento non gli è in alcun modo imputabile: come possono liberarsi da tale responsabilità nel caso finora analizzato? In che modo possono dimostrare di aver posto in essere tutte le misure di sicurezza adeguate?
È evidente che non potranno dimostrare la mancanza nesso tra le loro azioni (trattamento) ed il danno subito dagli interessati, e rischiano in tal modo di dover sborsare risarcimenti a migliaia se non milioni di utenti/interessati fruitori della loro app, oltre al rischio della sanzione da parte delle Autorità garanti ed all’esposizione mediatica.
Conclusione
In conclusione, evitare di incorrere in risarcimenti, sanzioni ed esposizioni mediatiche è possibile se già nella fase di progettazione di una applicazione mobile si prendano come punti di partenza i principi della privacy by design e ci si pongano continuamente interrogativi ogni qual volta un’azione posta in essere comporti un trattamento di dati, i quali possono essere risolti ponendosi domande del genere “è proporzionato il trattamento?” “ho valutato tutti i rischi e posto in essere le misure adeguate per mitigarlo?”, ed ovviamente rivolgendosi a specialisti della materia che sappiano fornire le giuste indicazioni.
