Una delle cose che mi ha sempre infastidito sulla semplice crittografia dei dati del database: se il server viene compromesso, il database viene effettivamente compromesso. L'utente malintenzionato può utilizzare lo stesso codice dell'app per interrogare i dati come desiderato. Una semplice revisione del codice dell'app mostrerà dove / come è memorizzata la chiave e quali sono i parametri di connessione del database.
Naturalmente, la crittografia dei dati può essere utile per la memorizzazione di backup fuori server, ecc., ma a tale scopo i file di backup potrebbero essere crittografati interamente, anziché i campi, risparmiando qualche mal di testa con le query, ecc.
In generale, accertarsi che il server sia sicuro è la procedura migliore. Ma, cosa succede se i dati devono essere protetti da tutti, inclusi gli amministratori di sistema (proprio come il modo in cui trattiamo le password degli utenti, attraverso l'hashing)?
In definitiva, mi chiedo, come può essere protetta una chiave di crittografia, in modo che non sia accessibile da chiunque senza il segreto, anche il codice dell'applicazione. L'unico approccio che posso pensare è che la chiave deve essere fornita dall'utente in fase di esecuzione (non è persistente sulla macchina host, punto).
Immagino che il primo problema è che se un utente ha accesso al server, probabilmente c'è un modo in cui il segreto potrebbe essere annusato al punto di entrata, o se la chiave è archiviata in memoria dall'app (ad es. una variabile di sessione) potrebbe essere probabilmente sfruttata anche.
Quali sono gli altri problemi (probabilmente evidenti) con questo approccio? Sta solo reinventando la ruota? In tal caso, qual è la migliore pratica quando la sicurezza dei dati è fondamentale, anche dai ruoli di super utente?
Questa domanda potrebbe essere in qualche modo simile a: Come accedere e crittografare i dati con la stessa password / chiave , tranne per il fatto che sto chiedendo se il concetto è anche buono, non come implementarlo.