Ovvero: come consultare un documento riservato senza dover creare un sistema di gestione utenti completo. Tratto da una storia vera*.
È ormai piuttosto frequente, specialmente dopo l’entrata in vigore della normativa GDPR, che si presenti l’esigenza di mettere in piedi un sistema di consultazione documenti che adotti una politica di sicurezza a più livelli.
Naturalmente esistono già diversi scenari canonici che prevedono l’introduzione di una gestione degli utenti. A questi scenari andremo ad associare tutta una serie di procedure legate all’autenticazione, l’invio di e-mail transazionali e altri tipi di notifiche. Ma se il nostro progetto non avesse bisogno di tutta questa infrastruttura?
È proprio necessario dover mettere in piedi un sistema così articolato anche nei casi in cui, ad esempio, non abbiamo un’area riservata perché dobbiamo semplicemente far scaricare un documento in maniera sicura?
Il sistema che andremo ad illustrare utilizza una selezione di tecnologie serverless, in modo da mantenere l’impronta il più piccola possibile, in combinazione con alcuni protocolli di sicurezza che garantiranno il livello di protezione del dato che ci serve.
Tutti gli strumenti che menzioneremo e che utilizziamo fanno parte dell’ecosistema di AWS (Amazon Web Services). In linea teorica è possibile adottare lo stesso approccio anche con altri strumenti software e piattaforme, anche se non avranno lo stesso livello di integrazione ed efficienza di AWS e il tutto sarà sicuramente più lungo e complesso da integrare.
Assumendo quindi che non disponiamo di un sito web con un’area riservata in cui andare a salvare in nostro documento, come possiamo rendere disponibile al destinatario questo documento senza farlo transitare per strumenti poco sicuri o poco automatizzabili?
La prima cosa da fare è di scindere il processo di accesso all’informazione in più parti: ormai abbiamo familiarità con questo approccio, visto che la quasi totalità dei sistemi di home banking sono passati a un’autenticazione a più fattori.
Supponiamo di voler inviare all'utente un documento contenente dati riservati. Il documento è un PDF generato da uno strumento separato di backoffice. Effettuiamo una chiamata REST a una funzione AWS Lambda, quindi utilizzando un sistema di elaborazione serverless, e carichiamo il documento su un sistema di archiviazione. In questo caso il documento finirà in un bucket Amazon S3, lo storage a oggetti di AWS, dove verrà archiviato in forma cifrata. Oltre al caricamento, la funzione provvederà a rimpiazzare il nome del PDF con uno UUID il quale, oltre a identificare univocamente il documento, renderà impossibile ricavare qualsiasi informazione dal nome del file.
Quindi ora il nostro documento risiede, cifrato e anonimizzato, su un sistema di archiviazione.
Contestualmente al caricamento, la funzione Lambda scrive un URL legato al documento in questione all’interno di un database NoSQL, nel caso specifico Amazon DynamoDB.
Viene dunque mandata una notifica (via e-mail o via SMS) all’indirizzo che nel backend è associato al destinatario tramite un servizio di gestione delle notifiche basato su Amazon Simple Queue Service, SQS per gli amici. Si tratta di un servizio di accodamento messaggi completamente gestito che consente di inviare, memorizzare e ricevere qualsiasi volume di messaggi tra componenti software.
Questa notifica, oltre ai convenevoli di rito, conterrà l’URL memorizzato in precedenza, il quale punta a una pagina web generata da una piccola applicazione Angular che viene servita da CloudFront, un servizio che consente la condivisione di contenuti web senza dover mettere in piedi un server web, acquistare un certificato SSL e tutto quanto richiesto da una web application.
Dalla pagina web contenuta nella notifica il nostro utente potrà richiedere una password temporanea, che il sistema scriverà in un record su DynamoDB associando al dato una scadenza. Se l’utente inserisce la password corretta, il record si cancella automaticamente alla scadenza e l’utente viene reindirizzato su uno URL prefirmato, con cui potrà accedere ai contenuti di S3 che altrimenti saranno completamente inaccessibili.
Quindi, nel sistema di archiviazione, non c’è un’impostazione che consente l’accesso ai documenti a determinati utenti, ma solo l’accesso tramite un URL autorizzato, il quale però ha una scadenza, non può essere copiato, trasferito su un altro dispositivo o passato a un altro utente: in breve, un approccio estremamente sicuro.
Lo è.
Anche se a prima vista il numero di servizi coinvolti può spaventare, non scordiamoci dei numerosi vantaggi.
Innanzitutto, questi servizi nascono per lavorare assieme. Quindi integrare procedure diverse è molto più semplice che fare una cosa analoga con strumenti “fisici”.
Parliamo inoltre di servizi serverless. Non abbiamo bisogno di mettere in piedi un server, configurarlo, manutenerlo in tutti i suoi componenti: sistema operativo, database, backup, webserver e via dicendo.
Infine: sono servizi a consumo. A differenza di un server canonico, che dobbiamo pagare tutto il tempo, in questo caso usiamo ciò che ci serve quando ci serve. E paghiamo a consumo.
E questo, in molti casi, può fare davvero un’enorme differenza.
* La storia vera è quella di un nostro cliente che aveva l'esigenza di consentire ai propri clienti l'accesso a uno specifico documento, ma non voleva fargli creare un account dedicato, almeno all'inizio. Abbiamo risolto il suo problema con la procedura che abbiamo qui descritto.