La memorizzazione di dati crittografati in un database è inutile?

4

Il modo in cui lo vedo: ci sono due modi per crittografare i dati per un'app Web.

1) Archivia una singola chiave di crittografia sul server e usala per crittografare / decodificare i dati in fase di runtime. Il problema ovvio qui è che se un hacker ottiene l'accesso al tuo server, è solo una questione di tempo finché non trovano la chiave di crittografia e quindi ogni speranza è persa.

2) Utilizzare la password di un utente come chiave di crittografia. Tuttavia, sembra una cattiva idea archiviare la propria password nelle informazioni di sessione e non funzionerebbe con le app collaborative. Per la collaborazione, potresti utilizzare un segreto condiviso, ma non ho mai visto un sito web che ti chieda di ricordare due password (una nota a tutti i membri dell'organizzazione).

Quindi dovremmo andare con il metodo 1 e sperare per il meglio? O basta cifrare a livello di disco? Con ciò anche se, se un hacker può ottenere l'accesso, non avranno problemi a leggerlo. Qual è lo standard qui quando si tratta di dati sensibili?

    
posta Luke Sapan 03.07.2015 - 14:20
fonte

2 risposte

2

Dipende da quali minacce hai intenzione di proteggere.

La crittografia dei dati a livello di database è un'ottima protezione, quando hai così tanti dipendenti IT, che sei in grado di dividerli in team responsabili per ogni livello.

Ad esempio, gli acquirer di banche e carte di credito utilizzano lo standard di sicurezza PCI DSS, che richiede tale protezione oltre a dividere il personale IT in team e limitare le autorizzazioni al di fuori del livello assegnato (ad esempio, rete interna o solo router di confine).

D'altra parte, la crittografia dei dati a livello di database offre una protezione aggiuntiva minima dalle minacce esterne, causando al contempo un enorme sovraccarico di sviluppo delle applicazioni.

Quindi, se non ti interessa tanto proteggere dalle minacce interne, allora la crittografia del livello del disco dovrebbe essere perfetta.

    
risposta data 03.07.2015 - 15:21
fonte
0

Nulla è inutile e non ci sono proiettili d'argento. Tutto dipende.

C'era una barra laterale sull'utilizzo della crittografia del disco. Questo è proteggere da una superficie di attacco diversa, quindi lasciala ignorare.

La domanda chiede se abbia senso crittografare i dati che si trovano in un database, supponendo che debba essere un testo in chiaro per un client web. Le scelte presentate consistono nell'utilizzare un token master (esterno al database) per decrittografare il cryptotext memorizzato, o per usare un token fornito dall'utente, con l'osservazione che questa è una cattiva idea e non funzionerebbe per la collaborazione.

Se la preoccupazione è che qualcuno possa violare la riservatezza del server web, ad esempio per passare in rassegna il token master memorizzato e il database, in realtà non si è fortunati. La mitigazione qui è che spesso la violazione del database e la violazione delle configurazioni web sono diverse, e l'una senza l'altra non è utile. Quindi è protettivo, ad esempio, nel classico esempio di un attacco sql injection che scarica il DB.

A quel punto, usare un token fornito dall'utente è molto utile, e non lo definirei una cattiva idea. Si noti che in teoria questo può essere ancora utile nelle app collaborative: il crittotesto memorizzato può essere crittografato utilizzando un codice di flusso la cui chiave è crittografata (ad esempio tramite una PKI) contro le chiavi di più persone. Ora, la riservatezza del server non è un problema (supponendo che non abbiano accesso al runtime) - nessuna raccolta di informazioni sul server può trasformare il cryptotext in testo normale senza i token dell'utente.

Tuttavia, se l'integrità del server è in questione, questa soluzione non riesce. Il testo in chiaro è nella memoria del server, quindi il suo gioco su ... il programma può essere riconfigurato per mantenere il testo in chiaro ovunque desiderato, o anche per cambiare la messaggistica tra i client. Ecco dove entra in gioco la terza soluzione. Se si dispone di codice in esecuzione sul computer client che esegue la decrittografia delle informazioni trasmesse e la crittografia di qualsiasi risposta, si torna in acqua sicura. (Anche se, naturalmente, ora è giù per l'opsec dei client finali, ma è sempre così.)

Quindi valuta i rischi e i costi dei vari casi di perdita di integrità sul server e fai la tua scelta.

Barra laterale: se davvero ti interessa questa roba, smetti di usare le password. Se non lo fai, IMHO un token master va bene.

    
risposta data 03.07.2015 - 21:12
fonte

Leggi altre domande sui tag