Ha senso crittografare il database per conformarsi a GDPR?

Question

Ha senso crittografare il database per conformarsi a GDPR?

#1 da (5 voti)

3

Ho avuto difficoltà a formulare la domanda. Preferirei chiedere, "Come faccio a rispettare GDPR ?" Ma probabilmente sarebbe una domanda troppo ampia. La crittografia del database mi preoccupa di più, poiché è ciò che il cliente desidera.

Consideriamo alcuni siti tipici: front end (Javascript), back-end (Ruby, Python, PHP, tu lo chiami) e database (ad esempio PostgreSQL). Può essere un'app a pagina singola o l'approccio tradizionale (MPA). Molto probabilmente il database e il back-end si trovano sullo stesso server.

A me sembra che non valga la pena. In generale, il segreto può essere mantenuto solo sul server. Se qualcuno accede al database, molto probabilmente sarà in grado di trovare il segreto. A meno che, probabilmente, non si ottenga l'accesso tramite la vulnerabilità di SQL, che sono per lo più scomparsi con le strutture odierne. O così credo.

Quindi ha senso crittografare il database per rispettare GDPR? Dove mantenere il segreto? Quali sono gli svantaggi della crittografia del database? Quali informazioni da crittografare? Ci sono approcci migliori?

encryption gdpr databases

posta x-yuri 15.04.2018 - 12:09

fonte

1 risposta

Leggi altre domande sui tag encryption gdpr databases

I protocolli di commutazione sono una misura di sicurezza che vale la pena implementare? È possibile utilizzare una sorta di CSRF usando il tag img / script per leggere le informazioni sensibili

score 5 · Accepted Answer

Conformità

Ho solo familiarità con le specifiche della legislazione, ma, a quanto ho capito, non c'è nulla che indichi che la crittografia del database è necessaria per conservare le informazioni personali e rispettare il regolamento generale sulla protezione dei dati (GDPR).

D'altra parte, l'utilizzo di misure di crittografia appropriate ridurrà in qualche modo l'impatto sulla privacy e i requisiti di notifica dovrebbero comportare una violazione.

(3) The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:

a) the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption;

Excerpt from: https://gdpr-info.eu/art-34-gdpr/

I vantaggi della crittografia per la sicurezza del database

La crittografia può ridurre in modo significativo l'impatto di una violazione dei dati. Ad esempio, nel 2015, Patreon è stata violata, perdendo il controllo di 15 GB di dati. A loro merito, Patreon ha utilizzato forti hash di bcrypt per proteggere le password e ha utilizzato misure di crittografia secondarie per proteggere le informazioni sensibili come i numeri di previdenza sociale e le informazioni fiscali.

Se non avessero crittografato le informazioni, l'impatto della violazione - sia per Patreon che per i suoi utenti - sarebbe stato considerevolmente peggiore.

Gestione chiavi

Se la tua preoccupazione è che un utente malintenzionato sia comunque in grado di accedere alla chiave, ci sono alcune misure che puoi adottare per mitigare tale rischio.

In definitiva, a meno che non si utilizzi un modulo di sicurezza hardware (HSM), la protezione delle chiavi è fondamentalmente come giocare a shell con l'attaccante. Un modo ragionevolmente efficace per mantenere le chiavi protette non è memorizzarle sul server. Una delle mie soluzioni preferite per questo è il servizio Azure KeyVault.

Tenendo le chiavi fuori dalla memoria permanente sul server e recuperandole solo per l'uso dalla memoria, rende molto più difficile per un utente malintenzionato recuperare la chiave. Dovrai comunque memorizzare i tasti per accedere ai tasti ... ma aggiungere quel livello aggiuntivo di riferimento indiretto renderà più difficile l'attacco.