Sicurezza crittografia del database

Quando ho fatto questo ho spostato del tutto la crittografia dal server web. Fondamentalmente ho avuto il seguente scenario

• Un server di database che memorizza il file dati crittografati
• Un server web che esegue l'applicazione e memorizza / recupera i dati crittografati
• Un server crittografico che esegue il crittografia e decrittografia e quali è bloccato

Fondamentalmente il server Web chiama un servizio Web sul server crittografico, che è disponibile solo su una rete interna e dice "Ecco alcuni dati e il tipo di dati". Il server crittografico prende una decisione sulla dimensione della chiave, sulla scadenza della chiave ecc. In base al tipo di dati, lo crittografa con una nuova chiave simmetrica e salta e restituisce un blob binario più un identificatore di chiave. Il server crittografico memorizza quindi la chiave nel proprio database SQL, ma lo protegge prima con un certificato X509, a cui ha accesso solo il servizio crittografico, quindi se si riesce ad accedere al database da remoto è inutile in quanto sarà comunque necessario l'accesso al sistema operativo. per ottenere il certificato X509 per decifrare le chiavi, e in ogni caso i dati sono conservati altrove.

Le password dell'amministratore del server crittografico sono conservate in una "break box" dove servono due persone separate per combinare le loro parti per ottenere la password.

Questo significa che gli sviluppatori non devono preoccuparsi di quali algoritmi utilizzare, o proteggere l'archiviazione delle chiavi poiché sono prese in carico dal server crittografico, e puoi aggiornare gli algoritmi usati come modifiche al processo o nuove regole senza dover per aggiornare qualcosa di diverso dal server crittografico. Solo il processo che esegue l'applicazione Web può chiamare il server crittografico, i normali account utente o persino gli account dell'amministratore non possono. Gli amministratori di database che possono vedere il database Web vedono solo i dati crittografati e non possono accedere neanche alle chiavi.

Anche se il server Web è compromesso, è ancora limitato in ciò che può fare, chiama il server crittografico per ottenere le chiavi, quindi chiama il database di archiviazione dei dati per ottenere i dati a cui i tasti fanno riferimento. Difficile da fare se il compromesso è solo la possibilità di eseguire codice arbitrario, senza sapere come avvengono queste cose o dove si trovano i server sulla rete interna.

Ovviamente se il compromesso è un rooting e l'attaccante può prendere il tuo codice e impersonare i processi, beh, tutte le scommesse sono andate via - ma sarà sempre così.

Le risposte qui sono buone (sia @blowdart che @Tate), ma la cosa importante da prendere in considerazione è che se il tuo sito web è compromesso, è gameover per quanto riguarda la sicurezza - sei stato pasticciato.

Il codice takeover malevolo può fare qualsiasi cosa che può fare il tuo sito, incluso l'accesso al tuo codice, processo in esecuzione, database, ecc. Ciò significa, indipendentemente da come fai la tua crittografia, indipendentemente da dove la tua chiave, possono raggiungerla e decrittografare i tuoi dati. Qualunque cosa tu provi, è solo oscurità, nel migliore dei casi, e nel peggiore dei casi, possono semplicemente lasciare che il TUO codice esegua la decrittazione e lavorare solo in seguito.

La migliore risorsa disponibile a mio avviso in questo momento per quanto riguarda tutte le cose che la sicurezza del database è il documento di Securosis:

Understanding and Selecting a Database Encryption or Tokenization Solution
This paper includes descriptions of major database encryption and tokenization technologies, a decision tree to help determine which type of encryption is best for you, and example use cases drawn from real world deployments. If you are considering any database encryption or tokenization project, this paper should save you hours of research and architecture development time.

link

Link diretto al PDF: link

In primo luogo, questo è un problema estremamente difficile. Il problema di base è che se la tua applicazione web ha una conoscenza sufficiente per decrittografare i dati, allora se viene dirottata avrà informazioni sufficienti per decodificare i dati. Devi davvero iniziare da lì. Questo significa un paio di cose.

1. Se ti fidi della tua applicazione per decrittografare i dati, se viene rilevata, può decodificare tutti i dati.

2. Se non ti fidi della tua applicazione per decrittografare i dati, probabilmente ci si può fidare di alcuni set di testo semplice.

Un'opzione consiste nell'avere un servizio tra l'applicazione e il database che gestisce la crittografia e la decrittografia. Questo può essere progettato in modo che due persone debbano lavorare insieme per memorizzare le chiavi in memoria, ma anche se non è così, si ottiene ancora un po 'di difesa in profondità. Se la tua applicazione web viene rilevata, ottiene solo l'accesso a ciò che il servizio di decrittografia può ottenere, e quindi la mitigazione può far parte di tale strategia. Un utente malintenzionato dovrebbe quindi compromettere il servizio di decrittografia / crittografia per l'accesso ai dati non elaborati (difesa approfondita sul lavoro).

(Per essere onesti, tendo a fondere questo servizio di crittografia / decrittografia con il database, ma i libri potrebbero essere scritti su come farlo in modo sicuro per ogni RDBMS dato e non è una soluzione semplice.)

Buone risposte su questo thread. Questo fondamentalmente si basa su due problemi principali, vale a dire il metodo di crittografia e l'archiviazione della chiave di crittografia.

Ho lavorato per un fornitore di crittografia DB e ho lavorato su numerosi progetti simili implementando la nostra soluzione D'Amo . Di solito crittografiamo i dati a livello di DB a seconda del tipo di DB, ma in un caso come questo installiamo un Security Agent (modulo) di crittografia / decodifica sul server web che può essere monitorato da remoto per configurare le politiche enc / dec da seguire durante operazione.

Il nostro consiglio generale è di archiviare le chiavi in un KMS (Key Management Server) separato e dedicato che potremmo anche fornire. Alcuni clienti hanno persino fatto un passo in più per chiederci o acquistare da una società di terze parti un modulo di sicurezza hardware ( HSM) per la gestione delle chiavi. Poiché la nostra soluzione è basata su colonne, c'erano diverse chiavi per ogni colonna crittografata. Anche la comunicazione tra Security Agent e KMS deve essere protetta per evitare l'attacco MITM quando Security Agent riceve le chiavi dal KMS.

Divulgazione: sono un ingegnere presso Penta Security Systems Inc.