Protezione del contenuto del database contro le perdite

0

Modello / scenario delle minacce
Mi preoccupo di un modello di thread, in cui determinati dati sensibili vengono archiviati in un database. Non è così sensibile come le informazioni o le password della carta di credito, ma numeri di telefono, indirizzi e-mail e simili. Supponiamo che temo una perdita di database, in cui un utente malintenzionato in qualche modo può leggere più informazioni di quelle a lui consentite dal database. Cosa può fare uno come amministratore contro questo?

Ciò che ho considerato
Supponiamo di mantenere aggiornato il software che organizza e distribuisce i dati e di correggere ogni vulnerabilità alla stessa velocità di una patch.

Ho considerato che potremmo crittografare i dati sensibili con, ad esempio, la password degli utenti. (Non l'hash memorizzato nel database). Il consenso tuttavia è che non è buona pratica salvare i dati crittografati in un database. Inoltre, i dati andrebbero persi se un utente dimenticasse la sua password.

Ho anche preso in considerazione la crittografia di tutti i dati con una chiave memorizzata nell'ambiente del sistema operativo, ma questo probabilmente non sarebbe di aiuto nei confronti di perdite sotto forma di ad es. Iniezioni SQL, a meno che non si mantengano i dati crittografati finché un utente non esegue l'accesso e quindi decrittografa solo la parte degli utenti dei dati finché non si disconnette nuovamente.

Quindi la mia domanda è, quale sarebbe un modo sensato di andare nello scenario di cui sopra?

    
posta WeGi 10.05.2017 - 18:54
fonte

1 risposta

0

L'unica ragione per non crittografare i dati all'interno delle colonne del database di cui sono a conoscenza sono i problemi di duplicazione delle prestazioni / dati. Stai andando a fare join o ricerche dal database in base ai dati in questione? Se non hai bisogno di farlo, sentiti libero di criptare i dati nelle colonne del database

Credo che il modo corretto per farlo sarebbe quello di crittografare le colonne nel database e memorizzare la chiave di crittografia in un datastore separato, ad esempio in un file nel filesystem. La decodifica dovrebbe avvenire immediatamente nell'applicazione web ogni volta che i dati vengono richiesti. In questo modo se il database viene mai compromesso tramite SQL injection, l'utente malintenzionato sarà in grado di recuperare i dati crittografati. Tieni presente che se non hai una chiave univoca per utente, è possibile che un utente malintenzionato determini due utenti che hanno lo stesso numero di telefono poiché lo stesso testo semplice cifrato con la stessa chiave di crittografia darà lo stesso testo cifrato. Si prega di tenere a mente anche la corretta rotazione delle chiavi.

    
risposta data 10.05.2017 - 19:14
fonte

Leggi altre domande sui tag