Raccomandazione per l'implementazione del database MySQL crittografato

Question

Raccomandazione per l'implementazione del database MySQL crittografato

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)

3

Per fornire uno sfondo veloce, dobbiamo implementare una soluzione in cui possiamo garantire che le informazioni siano archiviate crittografate. L'accesso ai dati di crittografia sarà possibile solo attraverso un'applicazione che abbia accesso dedicato al database. Con ogni "richiesta" di questa applicazione, verranno forniti i dettagli di autenticazione che verranno poi utilizzati per creare un registro di chi ha letto quali informazioni e quando.

I miei requisiti principali sono:

MySQL 5.5
Il database verrà replicato a scopo di backup. Uno dovrebbe essere in grado di ripristinare da tale database replicato, ma accedendo a un database replicato non dovrei essere in grado di leggere alcuna informazione.

La mia idea è di usare la crittografia a livello di applicazione e memorizzare i valori crittografati espliciti nel database. Cioè, a livello tecnico, il database non ha modo di sapere che le informazioni sono criptate. L'effettiva "struttura" del database (tabelle, colonne, ecc.) Non è qualcosa che consideriamo segreto. Per implementare la crittografia a livello di applicazione, sto pensando di applicare AES_ENCRYPT / AES_DECRYPT che è incorporato in MySQL, utilizzando una passphrase conosciuta solo dall'applicazione.

Qualcuno vede un problema con questo approccio? Sicuramente, la passphrase deve essere tenuta segreta. Se la passphrase dovesse perdere, penso che sarebbe banale riancrivere tutti i valori con una nuova passphrase. Il database non dovrebbe essere grande, i requisiti di prestazione sono bassi. Gli ambienti di sviluppo e testing sarebbero facili da avere, poiché l'unica differenza sarebbe la passphrase utilizzata.

mysql aes

posta Matthias 16.11.2017 - 13:58

fonte

3 risposte

Leggi altre domande sui tag mysql aes

È possibile specificare una politica di sicurezza del contenuto nei browser? Se Java è intrinsecamente vulnerabile agli attacchi di injection System.getProperty, vale la pena validarlo?

score 1 · Answer 1

Potenziali problemi -

Devi assicurarti di usare SSL - altrimenti le chiavi saranno inviate in chiaro.
Il tuo codice sarà disseminato di chiamate di crittografia / decrittografia. C'è anche il sovraccarico di iniettare nella chiave e inviarlo ogni volta - se la rete è il collo di bottiglia, allora potresti avere una capacità notevolmente ridotta.
Le chiavi devono essere nell'applicazione Web e vengono inviate costantemente al server DB. Questo significa due punti di errore invece di uno.
Questo dipende dal fatto che gli sviluppatori siano vigili. Se in qualsiasi momento qualcuno aggiunge un metodo che invia / riceve i dati senza le chiamate, allora va a sedersi lì in testo semplice.
Alcuni dati potrebbero non essere in grado di crittografare in questo modo senza rovinare le prestazioni del DB poiché non può più guardare direttamente i valori o memorizzarli in un ordine logico.
Il debugging diventa molto più difficile. Interrogare il DB per vedere cosa è memorizzato non è più banale.

I thinking that it would be trivial to re-encrypt all values with a new passphrase

Quanti dati ti aspetti di avere? "Trivial" spesso non scala. Ciò potrebbe comportare l'interruzione dell'intero sistema per un lungo periodo di tempo.

score 1 · Answer 2

Sembra che il tuo obiettivo è non fidarsi del database con la conoscenza dei dati originali. Se questo è corretto, allora sarà necessario crittografare / decodificare sull'altra macchina, NON in MySQL. Se si usa MySql per crittografare / decifrare, allora si ha fiducia in MySQL con l'accesso ai dati originali (e alla chiave), sconfiggendo così l'obiettivo.

Prima di progettare la soluzione, ti suggerisco di delineare il modello di minaccia che ti interessa. Ogni mitigazione dovrebbe quindi affrontare completamente qualcosa in quel modello di minaccia. Ricorda, anche i recinti bassi sono più utili dei pali veramente alti che speri che il tuo avversario decida di imbatterti per te. I modelli di minacce aiutano a identificare le lacune in quel recinto (come l'accesso al database alle chiavi e al testo in chiaro).

score 1 · Answer 3

My idea is to use application-level encryption and store explicit encrypted values in the database.

Sarai sempre in grado di eseguire il recupero indicizzato su chiavi hash con corrispondenze esplicite. È un design di database insolito molto in cui questo è un approccio praticabile e, in uno scenario del genere, non ha assolutamente senso utilizzare un database relazionale, non una versione di MySQL di 10 anni. Essenzialmente il tuo database è ridotto a un negozio di valore-chiave di fantasia.

Funzionerà solo se la tua applicazione è specificatamente progettata per operare su un database con tali caratteristiche.

Mi rimane da chiedermi quale sia il modello di minaccia che merita un simile approccio. Se pensi di poter proteggere i dati da un utente root malintenzionato, ti sbagli molto.

Se fossi in me, sfiderei questi requisiti e proverei a vedere se l'obiettivo può essere raggiunto utilizzando la crittografia del database nativo (attualmente sono più aggiornato con implementazione MariaDB di questo rispetto a MySQL) o le strutture del sistema operativo (LUKS, FUSE).