Supporto completamente la crittografia delle informazioni sensibili mentre è in memoria. La crittografia delle informazioni sensibili nel database impedisce a un utente malintenzionato di raccogliere informazioni utili se ha ottenuto il database. Tuttavia, come sempre, come implementare il sistema di crittografia è di fondamentale importanza.
Per prima cosa dobbiamo confrontare e mettere a confronto due situazioni in cui il database è compromesso:
- La situazione si verifica quando il database è stato compromesso, ma il file system è ancora sicuro.
- La situazione due si verifica quando sia il database sia il file system sono compromessi.
La situazione uno è quando la crittografia è la più utile. Questo tipo di attacco si verifica quando l'utente malintenzionato ha utilizzato un metodo come l'iniezione SQL. Questo è l'ideale perché l'utente malintenzionato non ha una chiave / metodo di decrittografia e lui / lei dovrebbe forzare la chiave di decodifica per ottenere i dati (ciò dovrebbe essere impossibile).
La situazione due è molto meno favorevole. Questo tipo di attacco si verifica quando l'utente malintenzionato ha ottenuto l'accesso al server (ad esempio, accesso fisico, FTP, SSH, eccetera). Poiché l'autore dell'attacco ha ottenuto l'accesso al file system, probabilmente ha la chiave di decrittografia, il che significa che può solo decodificare il database ed è game over.
Tuttavia, qui hai un vantaggio perché hai sia un server front-end che un server back-end. Ciò significa che è possibile implementare un design più sicuro per proteggere dalla situazione due. È possibile crittografare / decodificare su entrambi i server, il che significa che l'utente malintenzionato dovrebbe compromettere entrambi i file system del server. Ecco cosa intendo: il server di frontend può crittografare i dati sensibili utilizzando la propria chiave; inviare tali dati al server di back-end; il server di back-end quindi crittografa i dati crittografati utilizzando una chiave diversa; e infine il server di back-end memorizza i dati con doppia crittografia. Il processo di decodifica è solo il contrario: il server di backend estrae i dati crittografati; il server back-end decrittografa il primo livello di crittografia e lo invia al server frontend; il server di frontend rimuove quindi il secondo livello di crittografia; infine, il server di frontend visualizza i dati sensibili decrittografati all'utente.
Tutto ciò detto, come afferma la risposta di Kevinze, ci sono altre protezioni che dovrebbero essere in atto. Dovresti utilizzare HTTPS (SSL / TLS) per le comunicazioni tra l'utente e il server frontend. Ciò impedirebbe MiTM (nella maggior parte dei casi) e aiuterà a proteggere le comunicazioni tra il client e il server. Dovresti anche prendere in considerazione altre protezioni come la crittografia completa del disco. Non posso darti molte informazioni al riguardo, ma ovviamente aggiungerebbe protezione al file system.
Nella tua domanda, hai chiesto di aggiornare il tuo database e convertirlo in un modulo crittografato. Se fossi nella tua posizione, costruirò un nuovo database per memorizzare le informazioni crittografate e poi scriverò un programma per leggere tutte le voci dal vecchio database, scorrere su di esse, crittografare le colonne sensibili e inserirle nel nuovo database. Ecco alcuni pseudo-codice:
All_Entries[][] = Fetch_Array_All_Entries(FROM_OLD_DATABASE); // Multidimensional Array
for(int i = 0; i < count(All_Entries); i++){
thisEntry = All_Entries[i];
encryptedEntry = new Array();
encryptedEntry["Some Insensitive Column Name"] = thisEntry["Some Insensitive Column Name"];
encryptedEntry["Sensitive Column 1"] = encryptColumn(Backend_Key, encryptColumn(Frontend_Key, thisEntry["Sensitive Column 1"]));
encryptedEntry["Sensitive Column 2"] = encryptColumn(Backend_Key, encryptColumn(Frontend_Key, thisEntry["Sensitive Column 2"]));
// ... Encrypt all sensitive columns and assign them to the encryptedEntry ...
// Once all encryption is done:
Insert_Array_Entry(TO_NEW_DATABASE, encryptedEntry);
} // end entry loop
Una volta che il nuovo database è stato aggiornato con voci crittografate, è sufficiente sostituire il vecchio database con quello nuovo.
La tua domanda menziona il passaggio da VARCHAR a VARBINARY . Questa è davvero una tua scelta, ma potresti continuare a utilizzare VARCHAR se converti i byte in un formato stringa. Solitamente i dati crittografati vengono visualizzati come una stringa Base64. Ancora una volta, devi prendere quella decisione per te stesso, ma è così che probabilmente lo farei.