Negli ultimi anni il world wide web ha visto una crescita esponenziale di hacker, malware, ransomwares e altri software dannosi o parti che è costantemente cercando di trovare un modo per rubare i nostri dati personali: dato questo scenario, va da sé che la protezione dei dati è diventato uno dei compiti più importanti che si dovrebbe dare la priorità, a prescindere dal ruolo che siamo abituati a giocare. La necessità generale (e urgente) di impedire l’accesso non autorizzato a informazioni personali, sensibili e/o comunque critiche è qualcosa che dovrebbe essere riconosciuto da tutti – utenti finali, proprietari di servizi, amministratori di server e così via: le differenze sono principalmente legate a ciò che dobbiamo proteggere e come dovremmo farlo.

Inutile dire che l’atto di scegliere il modo corretto per proteggere i nostri dati è spesso successivo a una valutazione del rischio ben eseguita seguita da un’analisi costi-benefici, che è un ottimo approccio per aiutarci a trovare le misure tecniche e organizzative appropriate da implementare nel nostro scenario specifico. Questo è anche il modo corretto di agire secondo il Regolamento generale sulla protezione dei dati (GDPR), come indicato nell’Art. 32-Sicurezza del trattamento:

Tenendo conto dello stato dell’arte, i costi di implementazione e la natura, la portata, il contesto e le finalità del trattamento, nonché il rischio di varie probabilità e della gravità per i diritti e le libertà fondamentali delle persone fisiche, titolare e responsabile del trattamento deve attuare misure tecniche ed organizzative adeguate per garantire un livello di sicurezza adeguato al rischio

Ecco un elenco delle più comuni misure tecniche e organizzative per garantire la protezione e la sicurezza dei dati oggi:

  • controllo di Accesso: Proteggi tutti gli accessi fisici al tuo server, client e/o sale dati con chiavi, chip card, pareti, armadietti, allarmi e simili.
  • Minimizzazione: Assicurarsi che tutte le parti autorizzate possano accedere solo ai dati specificamente relativi alle loro specifiche attività e/o autorizzazione senza essere autorizzati a vedere nient’altro.
  • Integrità: proteggi i tuoi dati da perdite accidentali, distruzione o danni utilizzando contromisure appropriate (sensori di incendio/inondazione, disaster Recovery e simili).
  • Pseudonimizzazione: Sostituire i dati relativi all’utente con blocchi di testo casuali e anonimi, in modo che il titolare possa comunque conservare le voci (a fini statistici) e, allo stesso tempo, estrometterle da qualsiasi informazione personale.
  • Encryption in-transit: Assicurarsi che i dati vengano sempre trasmessi utilizzando standard di crittografia in-transit (certificati SSL/TLS) e attraverso connessioni sicure: questo vale anche per qualsiasi tipo di sito web e servizio web-based contenente moduli, schermate di accesso, funzionalità di upload/download e così via.
  • Crittografia a riposo: Proteggi le tue unità di archiviazione dati locali (incluse quelle utilizzate da server e desktop & client mobili) con un forte standard di crittografia at-rest; assicurati che i dati archiviati in SaaS e servizi basati su cloud siano crittografati anche a riposo.
  • Riservatezza: impedire l’elaborazione non autorizzata o illegale implementando concetti come separazione delle preoccupazioni & separazione dei doveri, applicazione delle politiche delle password e così via.
  • Recuperabilità: Assicurati che tutti i dati rilevanti siano soggetti a backup regolari e assicurati di controllarli regolarmente per assicurarti che i dati possano essere recuperati con successo.
  • Valutazione: sottoporre l’intero sistema a revisioni tecniche regolari, audit di terze parti, adottare un set efficace di indicatori di sicurezza e così via.

In questo post parleremo di due di queste misure tecniche: Encryption in-transit e Encryption at-rest, lasciando gli altri argomenti per ulteriori articoli.

Introduzione: le Tre Fasi di Dati Digitali

La prima cosa che si dovrebbe fare è quello di enumerare quante “stati” dati digitali possono avere, ed essere sicuri di capire ogni uno di loro:

  • A riposo: questo è lo stato iniziale di tutti i dati digitali: in termini molto brevi, questo indica che i dati che vengono memorizzati da qualche parte senza essere utilizzato da e/o trasmessi a chiunque (compreso il software di terze parti, gli esseri umani, e così via). Dai dischi rigidi locali agli archivi collegati alla rete, dalle pendrive USB ai dispositivi mobili, dalle cartelle di sistema ai server di database, qualsiasi sistema di archiviazione fisica e logica, unità o dispositivo è pensato per essere utilizzato per contenere i dati a riposo least almeno per un po’.
  • In transito: noto anche come “in movimento”. Questo è relativo ai dati che vengono trasmessi da qualche parte a qualche altra parte. Vale la pena notare che il concetto di” trasferimento dati ” può avvenire tra un numero qualsiasi di parti, non limitandosi a solo due (il mittente e un destinatario): ad esempio, quando trasferiamo un file dal nostro PC desktop al nostro laptop utilizzando la nostra LAN, stiamo fondamentalmente eseguendo un trasferimento di dati che coinvolge una singola parte (noi); al contrario, quando inviamo una transazione a un database distribuito, come una blockchain, stiamo applicando un trasferimento di dati tra una quantità indefinita di parti (l’intero nodo blockchain).
  • In uso: ogni volta che i dati non vengono solo memorizzati passivamente su un disco rigido o un supporto di memorizzazione esterno, ma vengono elaborati da una o più applicazioni – e quindi in fase di generazione, visualizzazione, aggiornamento, aggiunta, cancellazione e così via – è destinato ad essere “in uso”. Va da sé che i dati in uso sono suscettibili a diversi tipi di minacce, a seconda di dove si trova nel sistema e chi è in grado di accedervi e/o utilizzarlo. Tuttavia, la crittografia dei dati in uso è piuttosto difficile da tirare fuori, dal momento che sarebbe più probabile che storpio, ostacolare o crash dell’applicazione che è in realtà l’accesso: per questo motivo, il modo migliore per proteggere i dati in uso è quello di garantire che l’applicazione si occuperà di tale lavoro, adottando il più sicuro sviluppo e implementazione di modelli all’interno del suo codice sorgente.

La somma delle tre affermazioni sopra spiegate è chiamata “le tre fasi dei dati digitali”: ora che ne abbiamo preso il succo, siamo pronti a immergerci in profondità negli argomenti di crittografia.

Crittografia dei dati a riposo

Dalla definizione di “a riposo” sopra riportata possiamo facilmente capire come questo tipo di dati sia tipicamente in uno stato stabile: non viaggia all’interno del sistema o della rete e non viene agito da alcuna applicazione o da terze parti. È qualcosa che ha raggiunto una destinazione, almeno temporaneamente.

Motivi per usarlo

Perché dovremmo crittografare quei dati, allora? Bene, ci sono una serie di buone ragioni per farlo: diamo un’occhiata a quelle più significative.

Furto fisico

Se il nostro dispositivo viene rubato, la crittografia a riposo impedirà al ladro di essere immediatamente in grado di accedere ai nostri dati. Certo, si può ancora provare a decifrare utilizzando la forza bruta o altri metodi di crittografia-cracking, ma questo è qualcosa che ci vorrà una ragionevole quantità di tempo: dovremmo sicuramente essere in grado di tirare fuori le contromisure adeguate prima che ciò accada, come ad esempio: cambiare le informazioni account che potrebbe essere in grado di vedere o in qualche modo utilizzare tramite browser esistenti gestori di password, cookie di login, account client; monitorare il nostro dispositivo e / o emettere un “cancella tutti i dati” utilizzando i nostri servizi di gestione remota dei dispositivi Google o Apple; e così via.

Furto logico

Se il nostro PC, sito web o account di posta elettronica viene violato da un utente malintenzionato o software, la crittografia a riposo renderà l’autore del reato in grado di accedere ai nostri dati-anche quando rubato o scaricato: è fondamentalmente lo stesso scenario di furto fisico, tranne che è molto più sottile perché la maggior parte degli utenti (o amministratori) non

Ecco un’altra buona occasione per ricordare le parole terrificanti pronunciate da John T. La nostra azienda si occupa di:

Ci sono due tipi di aziende: quelle che sono state hackerate e quelle che non sanno di essere state hackerate.

Considerando lo stato attuale di Internet al giorno d’oggi e la sovrabbondanza di malware e tentativi di hacking misurabili, la stessa affermazione si può dire per qualsiasi utente finale in possesso di un dispositivo web-enabled: 100% guarranteed.

Errori umani

Per non parlare dei furti fisici e / o logici, ci sono molti altri scenari in cui la crittografia dei dati a riposo potrebbe essere un salvagente: per esempio, se abbiamo perso il nostro smartphone (e qualcuno lo trova); o se si commette un errore durante l’assegnazione delle autorizzazioni, la concessione di utenti non autorizzati (o clienti) l’accesso a file, cartelle e dati che non dovrebbero essere in grado di vedere; o se dimentichiamo il nostro PC locale o e-mail password in bella vista, permettendo a chi non ha voglia di rispettare la nostra privacy per dare un’occhiata alla nostra roba, e l’elenco potrebbe andare avanti per un po’.

Come può aiutarci

Per riassumere tutto ciò, potremmo rispondere alle nostre domande precedenti con una sola riga dicendo che crittografare i nostri dati a riposo potrebbe aiutarci a gestire meglio una possibile violazione dei dati.

Non ci aiuterà a prevenire che ciò accada – che è principalmente un compito per firewall, antivirus, buone pratiche e protocolli di sicurezza – ma sicuramente ci darà la possibilità (e il tempo) per impostare le contromisure appropriate, si spera minimizzando il danno complessivo causato da ogni possibile perdita.

Come implementare

l’Implementazione di una Crittografia dei Dati at-rest protocollo di sicurezza potrebbe essere facile o difficile, a seconda dei seguenti fattori:

  • che fisico e logico fonti di dati/archivi ci vogliono o devono proteggere: origini fisiche includono Hard disk, NAS elementi, smartphone, chiavette USB, e così via, mentre logico fonti di database locali o remoti, le risorse basate sul cloud e virtualizzati dispositivi, e così via;
  • chi ha bisogno di avere accesso a questi dati: gli esseri umani (locale o remoto agli utenti o a terzi di collegamento per noi), human-driven software (ad esempio MS Word) o automatico, processi o servizi (ad esempio un backup notturno di attività);
  • quanto siamo disposti a sacrificare in termini di prestazioni complessive e/o facilità di accesso per aumentare la sicurezza: possiamo chiedere a tutti i nostri locali (e remoto) gli utenti a decifrare questi dati, prima di essere in grado di accedervi? Dovremmo usare una password, un token fisico o un codice OTP? Possiamo rendere la crittografia abbastanza trasparente da non ostacolare i nostri utenti esterni e anche per consentire alle nostre app e strumenti software di gestire i dati crittografati ogni volta che avranno bisogno di gestirli?

per Fortuna, questi fattori sono ben noti per la maggior parte a riposo strumenti di crittografia, che sono stati progettati per proteggere i nostri dati, senza compromettere la funzionalità complessiva del nostro ambiente:

  • se si desidera crittografare fisico (o logico) del Disco Rigido, si può utilizzare strumenti software quali VeraCrypt (100% gratuitamente) o AxCrypt (versione gratuita disponibile);
  • se dobbiamo proteggere le nostre penne USB, è possibile utilizzare i suddetti strumenti o l’acquisto di una crittografia hardware Flash Drive attuazione di impronte digitali o basato su password, sbloccare i meccanismi (a partire dal 20~30 dollari);
  • se si desidera crittografare i dati memorizzati all’interno di un Sistema di Gestione di Database, la maggior parte dei DBMS disponibili oggi fornire nativo di tecniche di crittografia (InnoDB tablespace di crittografia per MySQL e MariaDB, Trasparente Crittografia di Dati di MSSQL, e così via);
  • se stai cercando un modo per memorizzare in modo sicuro i nostri messaggi di Posta elettronica, possiamo facilmente adottare una e-mail sicuro di crittografia standard come S/MIME o PGP (entrambi gratuiti): anche se questi protocolli sono per lo più legati al transito di crittografia, in quanto essi non proteggere i dati destinato per lo più ad essere trasferito in remoto parti, infatti essi sono comunemente utilizzati per eseguire la crittografia dal lato client, il che significa che essi proteggere i messaggi di posta elettronica mentre sei ancora a riposo. Inutile dire che, dal momento che tali messaggi saranno inviati, la nostra destinazione(s) dovrà anche adottare lo stesso standard per essere in grado di leggerli.

Crittografia dei dati in transito

Come suggerisce il nome, i dati in transito dovrebbero essere visti come un flusso di trasmissione: un grande esempio di dati in transito è una tipica pagina web che riceviamo da Internet ogni volta che navighiamo sul web. Ecco cosa succede sotto il cofano in poche parole:

  1. Inviamo una richiesta HTTP (o HTTPS) al server che ospita il sito Web che stiamo visitando.
  2. Il server web accetta la nostra richiesta, la elabora trovando il contenuto (statico o dinamico) che abbiamo richiesto, quindi lo invia a noi come risposta HTTP (o HTTPS) su una determinata porta TCP (di solito 80 per HTTP e 443 per HTTPS).
  3. Il nostro cliente, di solito un browser web come Google Chrome, Firefox o Edge, riceve la risposta HTTP(s), la memorizza nella sua cache interna e ce la mostra.

Come possiamo vedere, c’è chiaramente una trasmissione di dati in corso tra il server e il client: durante la trasmissione, i dati richiesti (la pagina web il codice HTML) diventa un flusso che passa attraverso almeno cinque diversi stati:

  1. si inizia a riposo (server, storage),
  2. quindi le modifiche in uso (web server di memoria),
  3. quindi in transito (HyperText Transfer Protocol su una determinata porta TCP),
  4. allora ancora in uso (browser web),
  5. e, infine, a riposo (cache del client).

Motivi per usarlo

Ora, diamo per scontato che sia il server che il client hanno implementato un forte livello di crittografia dei dati a riposo: ciò significa che il primo e il quinto stato sono internamente sicuri, perché qualsiasi tentativo di intrusione sarebbe fatto contro i dati crittografati. Tuttavia, il terzo stato, in cui i dati sono in transito, potrebbe essere crittografato o meno, a seconda del protocollo che il server e il client stanno effettivamente utilizzando per trasmettere i dati.

Ecco cosa succede di solito sotto il cofano quando viene utilizzato il protocollo HTTP:

Crittografia in transito e la Crittografia a riposo - Definizioni e Migliori Pratiche

Come possiamo vedere, il problema di sicurezza è abbastanza evidente: quando il web server elabora la richiesta in entrata e in modo trasparente decifra i dati richiesti, il canale utilizzato per il trasferimento a un client web (HTTP) non è crittografato: pertanto, qualsiasi offesa che riesce a tirare fuori con successo un attacco idonei (vedi sotto) potrebbe avere immediato accesso ai nostri dati non crittografati.

Come ci può aiutare

Se siete curiosi di sapere che tipo di attacchi può essere utilizzato nei confronti di una TCP non basato su protocollo di trasmissione, come ad esempio HTTP, ecco un paio di minacce che si dovrebbe essere a conoscenza di:

  • Intercettazioni: un livello di rete di attacco che si concentra sulla cattura di piccoli pacchetti dalla rete trasmessi da altri computer e la lettura dei dati contenuti nella ricerca di qualsiasi tipo di informazioni (più info qui).
  • Uomo nel mezzo: un attacco basato sulla manomissione in cui l’attaccante trasmette segretamente e/o altera la comunicazione tra due parti per far credere loro di comunicare direttamente tra loro (maggiori informazioni qui).

L’implementazione di protocolli di crittografia in transito adeguati per proteggere i nostri endpoint critici per il trasferimento dei dati ci aiuterà sicuramente a prevenire questo tipo di minacce.

Come implementarlo

Implementare un modello di crittografia in transito efficace è principalmente una questione di attenersi a una serie di raccomandazioni e best practice ben note durante la progettazione del trasferimento dei dati effettivo: quali protocolli usare (non), quale software adottare (non) e così via. Ad esempio:

  • Ogni volta che il dispositivo di trasmissione è raggiungibile tramite interfaccia Web, il traffico Web deve essere trasmesso solo su Secure Sockets Layer (SSL) utilizzando protocolli di sicurezza avanzati come Transport Layer Security (TLS): questo vale per qualsiasi sito web e / o servizio WAN-raggiungibile, compresi i server di posta elettronica e simili. Ad oggi, il modo migliore (e più semplice) per implementare la sicurezza TLS e implementare la crittografia in transito per qualsiasi sito Web è ottenere un certificato SSL/TLS HTTPS: questi possono essere acquistati dalle autorità CA registrate (Comodo, GlobalSign, GoDaddy, DigiCert e il loro enorme elenco di rivenditori/sottoseller) o generati automaticamente attraverso un processo di firma automatica, come abbiamo brevemente spiegato in questo post. Sebbene i certificati autofirmati garantiscano lo stesso livello di crittografia delle loro controparti firmate CA, generalmente non saranno attendibili dagli utenti in quanto i loro client browser non saranno in grado di verificare la buona fede dell’identità dell’emittente (tu), contrassegnando il tuo sito Web come “non attendibile”: per questo motivo, dovrebbero essere utilizzati solo su server/servizi non di produzione (o non accessibili al pubblico).
  • Tutti i dati trasmessi via e-mail devono essere protetti utilizzando strumenti di crittografia e-mail crittograficamente forti come S/MIME o PGP, che abbiamo già trattato quando abbiamo parlato di crittografia dei dati a riposo: sebbene questi protocolli eseguano la loro crittografia a livello client (e quindi a riposo), sono anche ottimi per proteggere il flusso asincrono in transito di un messaggio
  • Tutti i dati binari devono essere crittografati utilizzando strumenti di crittografia dei file appropriati prima di essere collegati alla posta elettronica e/o trasmessi in qualsiasi altro modo. La maggior parte dei protocolli di compressione, inclusi ZIP, RAR e 7Z, supportano un livello decente di crittografia protetta da password al giorno d’oggi: usarli è spesso un ottimo modo per aggiungere un ulteriore livello di sicurezza e ridurre le dimensioni degli allegati allo stesso tempo
  • Anche la trasmissione non web di testo e / o dati binari dovrebbe essere crittografata tramite crittografia a livello:
    • Se il database dell’applicazione risiede all’esterno del server delle applicazioni, la connessione tra il database e l’applicazione deve essere crittografata utilizzando algoritmi crittografici conformi a FIPS.
    • Ogni volta che la crittografia a livello di applicazione non è disponibile, implementare la crittografia a livello di rete come IPSec o SSH tunneling e/o assicurarsi che la trasmissione stessa venga eseguita utilizzando dispositivi autorizzati che operano all’interno di sottoreti protette con forti controlli firewall (VPN e simili).

La tabella seguente mostra alcuni esempi dei protocolli di rete non sicuri da evitare e delle loro controparti sicure da utilizzare:

Transfer Type What to avoid (insecure) What to use (secure)
Web Access HTTP HTTPS
E-Mail Servers POP3, SMTP, IMAP POP3S, IMAPS, SMTPS
File Transfer FTP, RCP FTPS, SFTP, SCP, WebDAV over HTTPS
Remote Shell telnet SSH2
Remote Desktop VNC radmin, RDP

Crittografia end-to-End

La crittografia in transito è davvero utile, ma ha una limitazione importante: non garantisce che i dati verranno crittografati al punto di partenza e non verranno decifrati fino a quando non saranno in uso. In altre parole, i nostri dati potrebbero ancora essere preceduti da intercettazioni occasionali e/o dannose, inclusi provider Internet, fornitori di servizi di comunicazione e chiunque possa accedere alle chiavi crittografiche necessarie per decifrare i dati durante il transito.

Il superamento di tale limitazione è possibile grazie alla crittografia End-to-End (E2EE), un paradigma di comunicazione in cui solo le parti finali comunicanti – ad esempio gli utenti – possono decifrare e quindi leggere i messaggi. I dati crittografati end-to-end vengono crittografati prima di essere trasmessi e rimarranno crittografati fino a quando non vengono ricevuti dalla parte finale.

Motivi per usarlo

Per capire meglio come la crittografia end-to-end superseeds in-transit encryption in termini di resilienza agli intercettatori, immaginiamo i seguenti scenari.

  1. Supponiamo che una terza parte riesca a piantare il proprio certificato radice su un’autorità di certificazione attendibile: tale azione potrebbe teoricamente essere eseguita da un attore statale, da un servizio di polizia o persino da un operatore dannoso/corrotto di un’autorità di certificazione. Chiunque sia in grado di farlo potrebbe operare con successo un attacco man-in-the-middle sulla connessione TLS stessa, intercettando la conversazione e forse persino manomettendola. I dati crittografati end-to-end sono nativamente resilienti a questo tipo di attacco, perché la crittografia non viene eseguita a livello di server.
  2. La crittografia end-to-end può anche aumentare il livello di protezione tra i processi utente generati da un sistema operativo. Ti ricordi i recenti difetti della CPU chiamati SPECTRE e MELTDOWN? Entrambi hanno permesso a una terza parte malevola (come un processo canaglia) di leggere i dati di memoria senza essere autorizzati a farlo. La crittografia end-to-end potrebbe evitare tale scenario finché la crittografia viene eseguita tra il processo utente (al contrario del kernel), impedendo così che tutti i dati non crittografati vengano inseriti nella memoria.

Come può aiutarci

La crittografia end-to-end è la forma di comunicazione più sicura che può essere utilizzata al giorno d’oggi, in quanto garantisce che solo tu e la persona con cui stai comunicando possano leggere ciò che viene inviato, e nessuno in mezzo, nemmeno il servizio che esegue effettivamente la trasmissione tra pari. Varie implementazioni di crittografia end-to-end sono già efficaci sulla maggior parte delle app e dei servizi di messaggistica (inclusi Whatsapp, LINE, Telegram e simili). In un tipico scenario di “app di comunicazione”, i messaggi sono protetti con un lucchetto e solo il mittente e il destinatario hanno la chiave speciale necessaria per sbloccarli e leggerli: per una maggiore protezione, ogni messaggio viene inviato automaticamente con il proprio lucchetto e chiave univoci.

Come implementarlo

La crittografia end-to-end può essere utilizzata per proteggere qualsiasi cosa: da messaggi di chat, file, foto, dati sensoriali su dispositivi IoT, dati permanenti o temporanei. Possiamo scegliere quali dati vogliamo crittografare end-to-end. Ad esempio, potremmo voler mantenere le informazioni benigne relative a un’app di chat (come i timestamp) in testo semplice ma crittografare end-to-end il contenuto del messaggio.

  • Ogni utente ha una chiave pubblica privata & che il software deve generare sul dispositivo degli utenti al momento dell’iscrizione o la prossima volta che accedono.
  • La chiave pubblica dell’utente viene pubblicata in un luogo pubblico (ad esempio un servizio di gestione delle chiavi basato su REST): ciò è necessario affinché gli utenti possano trovare le rispettive chiavi pubbliche ed essere in grado di crittografare i dati tra loro.
  • La chiave privata dell’utente rimane sul dispositivo dell’utente, protetta dall’archivio chiavi nativo del sistema operativo (o da altri archivi sicuri).
  • Prima di inviare un messaggio di chat o condividere un documento, l’app crittografa i contenuti utilizzando la chiave pubblica del destinatario (lato client).

Conclusione

Il nostro viaggio attraverso i vari paradigmi di crittografia è completo: ci auguriamo vivamente che questa panoramica possa aiutare gli utenti e gli amministratori di sistema ad aumentare la loro consapevolezza dei vari tipi di crittografia disponibili oggi.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

lg