Una risposta precedente ha fatto riferimento al sito web di ICO, dove è possibile conoscere le regole applicabili nel Regno Unito (che sono essenzialmente le stesse di quelle di altri paesi dell'UE), dal momento che il Data Protection Act è il Regno Unito attuazione della direttiva UE).
Volevo solo aggiungere, tuttavia, che come con molte altre cose simili, la legislazione sulla protezione dei dati è generalmente usata come un bastone per batterti quando qualcosa è già andato storto. Cioè, qualunque misura tu metti in atto, se perdi le informazioni private dei clienti in qualche modo, sarai colpevole di una violazione e molto probabilmente riceverai (almeno) dei "consigli" su come dovresti aver evitato la violazione in questione.
In altre parole, la legge sulla protezione dei dati non impone tanto le cose come la crittografia quanto i principi generali, di cui si avrà la rottura se si perdono informazioni private . A quel punto, ti potrebbe essere chiesto di accettare ad es. crittografare i dati in futuro (supponendo, secondo il parere del funzionario dell'esecuzione probabilmente non tecnico-esperto, che avrebbe aiutato).
Infine, poiché lo chiedi a proposito, come per la crittografia dei dati memorizzati, dovresti prendere in considerazione
- Quanto è probabile che la chiave di decodifica venga compromessa nello stesso momento in cui un utente malintenzionato ha ottenuto l'accesso ai dati (se entrambi sono compromessi insieme, non ha senso) oltre a soddisfare la mentalità delle caselle di controllo di qualcuno, laddove applicabile - crittografare le cose) .
- Quanto sono sensibili i dati e se esistono altri requisiti che impongono la crittografia (ad esempio PCI-DSS).
- Con quale frequenza si accede ai dati (che influisce sulle implicazioni delle prestazioni e sulla probabilità che la chiave possa essere facilmente individuata da un utente malintenzionato).
- Come ti proponi di crittografare i dati. La crittografia del disco, ad esempio, può mitigare i problemi di sicurezza fisica alcuni , ma non protegge contro compromissioni del server.
- Dove vengono archiviati i dati e in che modo viene effettuato l'accesso. per esempio. Crittografare le colonne in una tabella SQL potrebbe renderle difficili da interrogare, oppure no (a seconda di come sono crittografate).
- Sicurezza fisica del tuo server, incluso, per configurazioni virtualizzate, sicurezza delle immagini del disco.
- Sicurezza dei tuoi back-up. Talvolta può essere utile crittografare i backup anche quando la crittografia per i dati in tempo reale è indesiderabile ...
- Quanto sai della crittografia. Se decidi di crittografare le cose, devi farlo correttamente. Non ha molto senso aggiungere la crittografia se si rompe facilmente, e se non sai cosa stai facendo, è facile commettere errori che rendono molto più facile leggere i dati di quanto dovrebbe essere.
In sostanza, per ottenere protezione dalla crittografia dei dati, è necessario comprendere la minaccia che si sta tentando di proteggere, i compromessi che si faranno in cambio della crittografia e come utilizzare correttamente le primitive di crittografia stanno impiegando.
Su una nota correlata, vorrei sempre raccomandare l'hashing di qualsiasi campo password, preferibilmente usando una moderna funzione di hash sicura come bcrypt , anche se al molto minimo con SHA256 salato. Qualunque cosa tu faccia, non usare MD5 o storico UNIX crypt() , e non dimenticare di aggiungere sale. Non solo protegge da compromissione della password, significa che gli utenti non possono accusarti di accedere al proprio conto bancario utilizzando la password che hanno stupidamente utilizzato sia sul tuo sito che sulla loro banca.