Qual è una buona strategia di crittografia dei dati per una risorsa condivisa (testo)?

Qualcuno che si intromette nel server farà il giro del software e dei database. Avendo tutti i tuoi fattori, saranno quindi in grado di eseguire la strategia di decrittografia al contrario per recuperare tutte le PII.

Nell'autenticazione a più fattori, i fattori aggiuntivi non contano se verrebbero rubati contemporaneamente a un fattore esistente. Ad esempio, un token hardware è un fattore diverso da una password, perché un keylogger (il tipico modo di rubare la password), essendo software, non sarebbe in grado di rubare il token hardware allo stesso tempo.

Se ho capito correttamente la tua domanda, stai cercando di rafforzare i dati contro un utente malintenzionato che potrebbe assumere un controllo parziale sul tuo datacenter. Non dimenticare che una volta che una parte di un data center viene compromessa, si presume che la zona completa amministrativamente accessibile da lì sia compromessa. Ciò significa che non è sufficiente separare le informazioni su 3 server diversi, ma che 3 server dovrebbero trovarsi in 3 zone diverse con un rigoroso firewall tra di loro per garantire che solo le informazioni richieste possano essere scambiate. O almeno, il database protetto e il normale database non dovrebbero trovarsi nella stessa zona.

In particolare, l'applicazione dovrebbe essere in grado di ottenere la chiave di crittografia / decrittografia attraverso un servizio web e presentando le credenziali che dimostrano che lo fa per conto di un utente autorizzato. Ciò significa che dovrai configurare un sistema di autenticazione e autorizzazione avanzato e esaminare attentamente tutte le implicazioni sulla sicurezza. Inoltre, è necessario impostare controlli del codice per controllare che l'applicazione non mantenga quella chiave più a lungo del necessario

Ciò che intendo è che è necessario utilizzare un sistema di crittografia strong, ma è solo la parte visibile di ciò che dovrebbe essere fatto per aumentare effettivamente la sicurezza. La parte essenziale non sarà solo tecnica, ma coinvolgerà l'organizzazione e una definizione precisa di quali privilegi sono concessi a chi e a quale server è permesso comunicare con quale altro. Dovresti anche considerare come vengono eseguiti i backup perché sono una parte essenziale in un sistema sicuro perché devono essere robusti ma non troppo facilmente accessibili. IMHO si dovrebbe anche prendere in considerazione il valore dei dati e dei rischi a cui è esposto. Perché l'installazione di un sistema sicuro non verrà senza un costo.

TL / DR: non ci sono evidenti difetti in ciò che descrivi, ma ciò che manca è la definizione della segregazione tra le diverse parti, perché il diavolo si nasconderà in tali dettagli.

So che hai accennato al fatto che i due database sono separati, ma ovviamente comunicano in qualche modo, quindi li considererei entrambi a rischio se la tua rete è compromessa, il che significa che potrebbero essere considerati solo 1 fattore.

Avere un token fisico separato è comunque una buona idea, ovviamente, ma il mio messaggio è che l'utilizzo di 2 database potrebbe non essere molto meglio che usare 1.

Forse un modo per migliorare la sicurezza non è l'hardcode della "chiave master" nel software, piuttosto il recupero in fase di esecuzione da un altro server. Almeno in questo modo l'attaccante non può semplicemente andarsene con software e DB, ma deve anche creare un dump della memoria per ottenere la chiave master o addirittura attaccare il server delle chiavi.

Se quello che stai facendo è un progetto su larga scala come hai detto, la mia raccomandazione è di andare con soluzioni commerciali indirizzate proprio a questo.

Conoscete il solito consiglio: non tirate da soli quando si tratta di crittografia / crittografia. Ci sono molti modi in cui la tua strategia può andare storta. Meglio controllare una soluzione testata e ce ne sono alcuni che penso si adattino esattamente alle tue esigenze.

In parole povere, vuoi una soluzione che abbia crittografia a livello di colonna, che fornisca chiavi di crittografia / decrittografia diverse per ogni colonna e ti dia la possibilità di definire i criteri di controllo dell'accesso per colonna.

La soluzione dovrebbe anche aiutarti a memorizzare e gestire le tue chiavi in un server separato (preferibilmente HSM) e garantire una trasmissione sicura delle chiavi tra i server.

Come divulgazione, ho lavorato come consulente di crittografia DB per un po 'di tempo, ma di nuovo questo mi mette nelle condizioni di darti un consiglio "I-ve-been-done-that".

Ho consultato molti clienti che hanno requisiti molto severi in termini di sicurezza e prestazioni. Non sono sicuro di quale DBMS stai utilizzando, ma se utilizzi il DB open source, potresti trovare mydiamo per avere tutto ciò che sei cercando. Se stai utilizzando DBMS commerciale, questo compan y o questo ha soluzioni abbastanza ben collaudate.

HSM

Una pratica piuttosto comune in questi contesti è quella di avere la "chiave master" del tuo scenario in un modulo di sicurezza hardware, quindi non la lascia mai e può decodificare le chiavi specifiche dei dati quando richiesto.

Come descritto attualmente, il tuo software sembra essere un singolo punto di errore: un exploit nella tua applicazione avrebbe accesso alla chiave master e probabilmente anche l'accesso in lettura a entrambi i database. Se vuoi veramente una "difesa in strati", allora devi assicurarti che il sistema che ha accesso a tutti i dati non sia in grado di decrittografarlo e il sistema in grado di decrittografare i dati non possa accedere a tutti i dati.