La crittografia è spesso un argomento di sicurezza, ma è importante anche per la privacy. L'obiettivo della crittografia è impedire ad altri di leggere le informazioni criptate, ma impedire ad altri di leggere le tue informazioni è un modo per mantenerle private. Spesso, un utente ha dei limiti nelle attività che può svolgere autonomamente, ma con il tuo aiuto in qualità di fornitore di un servizio che utilizza, la crittografia può contribuire a conservare i suoi dati di sua proprietà.
Esistono tre modi pertinenti per applicare la crittografia a tutela della privacy dell'utente: crittografia dei dati in transito, crittografia dei dati inattivi e crittografia end-to-end:
- La crittografia in transito mantiene i dati criptati tra l'utente e il tuo sito, ovvero con i protocolli HTTPS. Probabilmente hai già configurato HTTPS per i tuoi siti, ma sei sicuro che tutti i dati in transito verso i tuoi siti siano criptati? Queste sono le finalità del reindirizzamento e del protocollo HSTS, descritte di seguito, che dovrebbero far parte della configurazione HTTPS.
- La crittografia at-rest è la crittografia dei dati archiviati sui tuoi server. Questa protezione protegge dalle violazioni dei dati ed è una parte importante della tua posizione sulla sicurezza.
- La crittografia end-to-end è la crittografia dei dati sul client prima che raggiungano il tuo server. In questo modo i dati utente sono protetti anche da te: puoi archiviare i dati degli utenti, ma non puoi leggerli. Questa soluzione è difficile da implementare e non è adatta a tutti i tipi di applicazione, ma è di grande aiuto per tutelare la privacy dell'utente, in quanto nessuno può vedere i suoi dati a parte sé stesso.
HTTPS
La prima fase consiste nel gestire il servizio web tramite HTTPS. È molto probabile che lo avrai già fatto, in caso contrario si tratta di un passaggio importante. HTTPS è HTTP, il protocollo utilizzato da un browser per richiedere pagine web a un server, ma criptato tramite SSL. Ciò significa che un utente malintenzionato esterno non può leggere o interferire con una richiesta HTTPS tra il mittente (l'utente) e il destinatario (tu), in quanto il messaggio è criptato e quindi non può leggerla o modificarla. Si tratta della crittografia in transito: i dati passano da un utente a un altro o da te a un utente. La crittografia HTTPS in transito impedisce inoltre all'ISP dell'utente, o al provider della rete Wi-Fi che utilizza, di leggere i dati che ti invia nell'ambito della relazione con il tuo servizio. Potrebbe influire anche sulle funzionalità del tuo servizio: molti utilizzi delle API JavaScript esistenti richiedono che il sito web venga pubblicato tramite HTTPS. MDN ha un elenco più completo, ma le API accessibili tramite un contesto sicuro includono i service worker, le notifiche push, la condivisione web e le criptovalute web e alcune API dei dispositivi.
Per pubblicare il tuo sito web tramite HTTPS, avrai bisogno di un certificato SSL. Queste possono essere create senza costi tramite Let's Encrypt o spesso possono essere fornite dal tuo servizio di hosting, se ne utilizzi uno. È anche possibile utilizzare un servizio di terze parti che esegue il "proxy" del tuo servizio web e può fornire HTTPS, nonché servizi di memorizzazione nella cache e CDN. Esistono numerosi esempi di servizi di questo tipo, come Cloudflare e Fastly, e l'opzione esatta dipende dall'infrastruttura attuale. In passato, HTTPS poteva essere gravoso o costoso da implementare, motivo per cui tendeva a essere utilizzato solo su pagine di pagamento o origini particolarmente sicure. Tuttavia, i certificati disponibili senza costi, i miglioramenti degli standard e la maggiore proliferazione dei browser hanno rimosso tutti questi ostacoli.
Cosa fare
- Attiva HTTPS sui tuoi server per tutto (indipendentemente dal metodo scelto).
- Prendi in considerazione l'utilizzo di un proxy davanti ai server, come Cloudflare (httpsiseasy.com/ spiega il processo).
- Let's Encrypt ti guiderà nella procedura di creazione del tuo certificato SSL Let's Encrypt.
- In alternativa, puoi utilizzare OpenSSL direttamente per creare il tuo certificato e farlo firmare dall'autorità di certificazione (CA) scelta da te (Abilita HTTPS spiega in dettaglio come farlo).
L'approccio che scegli dipende dai compromessi con l'attività. Avere a disposizione una terza parte per gestire la connessione SSL è il più facile da configurare e offre anche altri vantaggi, come il bilanciamento del carico, la memorizzazione nella cache e l'analisi. Ma comporta anche una chiara cedimento di un certo controllo alla terza parte e un'evitabile dipendenza dai servizi che offri (e da un eventuale pagamento, a seconda dei servizi che usi e dei livelli di traffico).
La generazione di certificati e la loro firma da una CA è il modo in cui veniva condotto il processo SSL, ma l'uso di Let's Encrypt può essere più semplice se è supportato dal provider o se il team del server è tecnicamente abbastanza competente ed è senza costi. Inoltre, capita di frequente che il tuo provider offra SSL come servizio se utilizzi qualcosa di più elevato rispetto all'hosting nel cloud, quindi vale la pena verificarlo.
Perché
La sicurezza è parte integrante della tua tutela della privacy: essere in grado di dimostrare che proteggi i dati utente dalle interferenze contribuisce a instaurare un rapporto di fiducia. Se non utilizzi HTTPS, i tuoi siti vengono inoltre contrassegnati come "non sicuri " dai browser (e lo sono da un po' di tempo). Le API JavaScript esistenti sono spesso disponibili solo per le pagine HTTPS ("origini sicure"). Inoltre, protegge gli utenti dall'utilizzo del web da parte del loro ISP. Si tratta certamente di una best practice; esiste un motivo preciso o nullo per non utilizzare al momento HTTPS per i siti web.
Modalità di visualizzazione di una pagina HTTP (non sicura) da parte dei browser
Reindirizzamento a HTTPS
Se il tuo sito è disponibile sia sugli URL http: che https:, devi reindirizzare tutti gli accessi da URL http a https. Questo è per i motivi sopra indicati e garantisce che il tuo sito non venga visualizzato su whynohttps.com se diventa popolare. Le modalità di esecuzione dipendono molto dall'infrastruttura. Se sei ospitato su AWS, puoi utilizzare un bilanciatore del carico classico o applicazione. Google Cloud è simile. In Azure puoi creare un Frontdoor; in Node con Express check for request.secure; in Nginx catch tutte le porte 80 e restituire 301; in Apache, usare una RewriteRule. Se usi un servizio di hosting, è molto probabile che siano loro a gestire automaticamente i reindirizzamenti agli URL HTTPS, tra cui le pagine Netlify, Firebase e GitHub.
HSTS
HSTS è l'acronimo di "HTTP Strict-Transport-Security" ed è un modo per bloccare per sempre un browser all'utilizzo del protocollo HTTPS per il tuo servizio. Quando la migrazione a HTTPS ti soddisfa, o se l'hai già fatto, puoi aggiungere un'intestazione di risposta HTTP Strict-Transport-Security alle tue risposte in uscita. Un browser che ha già avuto accesso al tuo sito registrerà dopo aver visto questa intestazione e da quel momento in poi accederà automaticamente a questo sito come HTTPS anche se richiedi HTTP. In questo modo eviterai di eseguire il reindirizzamento come spiegato in precedenza: è come se il browser "esegue automaticamente l'upgrade" di tutte le richieste al tuo servizio per l'utilizzo di HTTPS.
Allo stesso modo, puoi pubblicare un'intestazione Upgrade-Nonsecure-Requests insieme alle tue pagine. Ha qualcosa di diverso da ma correlato a Strict-Transport-Security. Se aggiungi Upgrade-Insecure-Requests: 1, le richieste da questa pagina ad altre risorse (immagini, script) verranno richieste come https anche se il link è http. Tuttavia, il browser non richiederà di nuovo la pagina stessa come https e non memorizzerà la pagina la volta successiva. In pratica, le richieste di upgrade non sicure sono utili se stai convertendo un sito esistente con molti link in HTTPS e convertendo gli URL dei link nei contenuti, ma se possibile, è preferibile modificare i contenuti.
HSTS è principalmente una funzionalità di sicurezza: "blocca" il tuo sito al protocollo HTTPS per gli utenti che hanno visitato il sito in precedenza. Tuttavia, come indicato in precedenza, HTTPS è utile per la privacy e HSTS è utile per HTTPS. Allo stesso modo, Upgrade-Insecure-Requests non è davvero necessario se stai aggiornando tutti i tuoi contenuti, ma è un utile approccio basato su parentesi graffe per aggiungere una difesa approfondita per garantire che il tuo sito sarà sempre HTTPS.
Cosa fare
Aggiungi l'intestazione HSTS alle risposte in uscita:
Strict-Transport-Security: max-age=300; includeSubDomains
Il parametro max-age determina per quanto tempo, in secondi, il browser deve memorizzare e applicare l'upgrade a HTTPS. (qui è impostato su 300 secondi, ad esempio 5 minuti). Alla fine, vorrai essere 6.3072.000, ovvero due anni, come consigliato da hstspreload.org, ma è abbastanza difficile recuperare in caso di problemi. Quindi ti consigliamo di impostare un numero basso all'inizio (300), di verificare che non ci siano errori e di aumentare il numero in fasi.
Aggiungi le intestazioni Upgrade-Insecure-Requests alle tue risposte in uscita:
Upgrade-Insecure-Requests: 1
Content-Security-Policy: upgrade-insecure-requests
Crittografia end-to-end
Un buon modo per mantenere privati i dati utente è non mostrarli a nessuno all'infuori dell'utente, incluso te. Questo è di grande aiuto per la tua posizione di fiducia: se non disponi dei dati dei tuoi utenti, è chiaro che non puoi farne nulla che non vorresti. Un modo per riuscirci è evitare che i dati utente lascino il dispositivo, archiviando tutto sul lato client. Questo approccio funziona, ma esistono limitazioni per un'applicazione lato client pura: l'archiviazione dei dati del browser può essere limitata per dimensioni e in alcuni browser potrebbe essere cancellata con un avviso minimo o nessun avviso. È anche difficile o impossibile accedere ai dati da due dispositivi, ad esempio un laptop e un cellulare. Per questo motivo può essere utile inviare i dati al server normalmente, ma criptarli con una chiave nota solo all'utente, in modo che il server non possa accedervi (perché non può decriptarli), ma archiviarli.
Come funziona?
Questo approccio viene spesso utilizzato dalle applicazioni di messaggistica, dove è definito "crittografia end-to-end" o "e2e". In questo modo, due persone che conoscono le chiavi l'una dell'altra possono criptare e decriptare i loro messaggi e inviarli tramite il provider di messaggistica, ma il provider di messaggistica (che non dispone di queste chiavi) non può leggere i messaggi. La maggior parte delle applicazioni non sono app di messaggistica, ma è possibile combinare i due approcci (un solo datastore lato client e crittografia dei dati con una chiave nota al client) per archiviare i dati localmente ma anche inviarli criptati al server. È importante capire che ci sono delle limitazioni a questo approccio: non è possibile per tutti i servizi e in particolare non può essere utilizzato se tu, in qualità di fornitore di servizi, hai bisogno di accedere ai contenuti archiviati dall'utente. Come descritto nella parte 2 di questa serie, è meglio rispettare il principio di minimizzazione dei dati; se possibile, evita di raccogliere dati. Se l'utente ha bisogno di spazio di archiviazione dei dati, ma non hai bisogno di accedervi per fornire il servizio, la crittografia end-to-end è un'alternativa utile. Se fornisci servizi che richiedono la possibilità di vedere cosa archivia l'utente per fornire il servizio, la crittografia end-to-end non è adatta. Tuttavia, in caso contrario, puoi fare in modo che il codice JavaScript lato client del tuo servizio web cripti tutti i dati che invia al server e i dati che riceve.
Un esempio: Excalidraw
Excalidraw lo fa e spiega come in un post del blog. Si tratta di un'app di disegno vettoriale che memorizza i disegni sul server, criptati con una chiave scelta in modo casuale. Uno dei motivi per cui Excalidraw è in grado di implementare questa crittografia end-to-end con relativamente poco codice è che ora le librerie crittografiche sono integrate nel browser con window.crypto, ovvero un insieme di API JavaScript supportate in tutti i browser moderni. La crittografia è complessa e l'implementazione
degli algoritmi comporta molti casi limite. L'esecuzione del lavoro pesante da parte del browser rende la crittografia più accessibile per gli sviluppatori web e, di conseguenza, semplifica l'implementazione della privacy tramite dati criptati. Come Excalidraw descrive nel suo processo di scrittura,
la chiave di crittografia rimane sul lato client perché fa parte del frammento URL: quando un browser visita un URL
https://example.com/path?param=1#fraghere, il percorso dell'URL (/path) e i parametri (param=1) vengono passati al server
(example.com), ma il frammento (fraghere) non lo è, quindi il server non lo vede mai. Ciò significa che anche se i dati criptati passano attraverso il server, la chiave di crittografia non passa e quindi la privacy viene preservata perché i dati sono protetti con crittografia end-to-end.
Limitazioni
Questo approccio alla crittografia dei dati utente non è infallibile. Contribuisce alla tua posizione di fiducia per gli utenti, ma non può sostituirla completamente. I tuoi utenti dovranno comunque fidarsi del tuo servizio, perché potresti, in qualsiasi momento, sostituire il codice JavaScript lato client con codice JavaScript leggermente simile che non consente di criptare in modo impenetrabile i dati e, sebbene sia possibile per gli utenti scoprire se un sito web che stai utilizzando lo ha fatto, è estremamente difficile farlo. In pratica, i tuoi utenti dovranno comunque fidarsi del fatto che i tuoi dati non sono deliberatamente letti e utilizzati in modo illecito.
È inoltre importante ricordare che uno degli obiettivi della crittografia end-to-end è impedire ai proprietari dei siti di leggere i dati. Questo fa bene alla privacy, ma significa anche che in caso di problemi non puoi aiutarti. In sostanza, un servizio che utilizza la crittografia end-to-end mette l'utente responsabile delle chiavi di crittografia. Potrebbe non essere ovvio o esplicito, ma qualcuno deve avere la chiave e se i tuoi dati sono privati, non sei tu. Se le chiavi vengono perse, non potrai fare nulla e probabilmente anche i dati criptati con quelle chiavi potrebbero andare persi. C'è un giusto equilibrio tra privacy e usabilità: mantenere i dati privati per tutti utilizzando la crittografia, ma anche evitare di costringere gli utenti a essere esperti di crittografia che gestiscono le proprie chiavi in modo sicuro.
Crittografia at-rest
Oltre a criptare i dati in transito degli utenti, è importante anche valutare la possibilità di criptare i dati che hai archiviato sul server. Questo ci aiuta a proteggerti dalle violazioni dei dati, in quanto chiunque riesca ad accedere senza autorizzazione ai tuoi dati archiviati avrà dati criptati e, probabilmente, non avrà le chiavi per decriptare. Esistono due approcci diversi e complementari alla crittografia dei dati at-rest: la crittografia opzionale e la crittografia aggiunta dal tuo provider di spazio di archiviazione sul cloud (se utilizzi un provider di spazio di archiviazione sul cloud). La crittografia del fornitore di spazio di archiviazione non offre una protezione elevata contro le violazioni dei dati tramite il software (perché la crittografia del fornitore di spazio di archiviazione di solito è trasparente per gli utenti del suo servizio), ma aiuta a evitare violazioni che si verificano a livello dell'infrastruttura del provider. Spesso è semplice da attivare e quindi vale la pena prenderlo in considerazione. Questo campo cambia rapidamente e il team di sicurezza (o gli ingegneri esperti di sicurezza del tuo team) sono i migliori esperti da consigliare, ma tutti i provider di spazio di archiviazione sul cloud offrono la crittografia at-rest per l'archiviazione a blocchi Amazon S3 mediante impostazione, Azure Storage e Google Cloud Storage per impostazione predefinita, nonché per l'archiviazione dei dati del database AWS RDS, Azure SQL e SQL Google Cloud.{/11 Consulta il tuo fornitore di spazio di archiviazione sul cloud, se ne usi uno. Gestire autonomamente la crittografia dei dati at-rest per proteggere i dati utente dalle violazioni dei dati è più difficile, perché la logistica per gestire in modo sicuro le chiavi di crittografia e renderle disponibili per il codice senza metterle a disposizione anche di utenti malintenzionati è complessa. Questo non è il posto migliore per dare consigli su problemi di sicurezza a quel livello; consulta i tuoi ingegneri esperti di sicurezza, il team dedicato o le agenzie di sicurezza esterne.