Devo crittografare i dati nel database?

Personalmente controllerei le leggi su questo. Se i dati devono essere crittografati, devono essere crittografati.

Se tuttavia non ricevi alcuna guida, mirerei a proteggere il collegamento tra il paziente ei suoi dati. Cioè molto probabilmente hai un PatientID usato nelle tabelle in tutto il database. PatientID non identifica un paziente, solo l'anamnesi del paziente, ecc ... Tuttavia, per identificare il PatientID di Joe Bloggs che vive a Rua de São Bernardo Lisbona, lo terrei in un DB separato se posso. Usa TDE per i dettagli personali del paziente e prendi in considerazione la possibilità di crittografarlo utilizzando le chiavi della tua applicazione web.

Mentre il furto di quei dati medici senza i mezzi per identificare i pazienti sarà estremamente imbarazzante, è improbabile che ci sia qualcosa oltre. Ci sono letteralmente concorsi online che utilizzano questi dati medici resi anonimi.

Con la separazione dei dati medici dai dettagli personali del paziente. Utilizzare un solido set di ruoli per limitare il personale solo a ciò di cui hanno bisogno. Ad eccezione del personale medico che richiede di trattare direttamente con il paziente (infermiere e medici in prima linea), nessuno dovrebbe avere accesso a entrambi. Gli addetti alla reception hanno solo bisogno dei dati personali del paziente, il personale di laboratorio ha solo bisogno della cartella clinica e del PatientID, solo le infermiere chirurgiche sono attualmente in condizioni mediche e nome.

Quando hai identificato ogni set di ruoli, miri non solo a implementarli nella tua applicazione web, ma anche nel database e in un ulteriore livello di sicurezza.

Sì, dovresti crittografare il database.

La crittografia di base per i dati memorizzati ("dati a riposo") è un principio di sicurezza generalmente accettato ed è probabilmente richiesto dalla legge se il tuo Paese ha leggi che proteggono le informazioni personali o sulla salute.

Utilizziamo SQL Server 2008, quindi utilizziamo TDE di Microsoft; potrebbe esserci qualche soluzione di terze parti per MySQL o forse solo un approccio generale di crittografia del volume (come TrueCrypt) funzionerebbe (anche se mi piacerebbe avere qualcosa che è stato certificato per l'uso con un database).

Se fatto correttamente, il risultato della performance dovrebbe essere piccolo.

A proposito, il link che hai citato (riguardo alla separazione delle informazioni sensibili) è qualcosa che dovresti considerare in cima alla crittografia di base del database.

EDIT: la crittografia sopra menzionata avrebbe crittografato il volume. Se qualcuno dovesse rubare il disco rigido, troverebbe i dati crittografati. Tuttavia, se qualcuno dovesse eseguire query sul database, vedrebbe i dati non crittografati (ecco perché ho menzionato la separazione delle informazioni, anche se l'OP non voleva discuterne).

Si noti che questa raccomandazione è intesa come il minimo che si dovrebbe fare. Se vuoi una consulenza legale, ovviamente dovrai cercare altrove. Se vuoi una discussione più approfondita sulla scrittura di un codice sicuro, inizierei con il libro Scrittura del codice di sicurezza .

Ignorando per un momento ciò che il cliente sta chiedendo e qualunque sia la legge ...

No, probabilmente non dovresti crittografare i dati. Se lo fai, non sarai in grado di cercarlo facilmente. Ad esempio, come si cerca un cognome like 'Smith%' se ogni voce di nome è crittografata? Come calcoli la pressione sanguigna del paziente nel tempo se non puoi select .... from.... where patient_id = N ?

Dovresti, ovviamente, assicurarti che il server sia correttamente protetto, che la connessione di rete sia protetta e che l'interfaccia utente sia protetta correttamente (compresi i timeout delle sessioni in modo che gli utenti non possano lasciare l'accesso a chiunque usi il loro computer). Potrebbe anche voler cifrare i backup del database. E proteggere fisicamente la stanza in cui si trova il server. Ma non crittograferei i dati in tempo reale.

Precisazione: Ciò presuppone che l'OP stava chiedendo di crittografare effettivamente i dati in del database. Non il file system su cui si trova il database.

Prima di decidere su questioni di sicurezza, è necessario valutare il modello di minaccia. Senza un'idea su cosa ti stai difendendo, qualsiasi misura che prendi sarà di scarso valore.

Ora, ci sono alcune cose di cui potresti preoccuparti in questo contesto:

• Gli hacker che ottengono l'accesso fisico ai tuoi dati (ad es. irrompere nel data center, rubare i nastri di backup, ecc.)
• Gli utenti che ottengono l'accesso in lettura al tuo database non elaborato
• Gli hacker che compromettono la tua richiesta, ad es. tramite SQL injection, overrun del buffer, ecc.

Per il primo scenario, il salvataggio del database e di tutti i backup su volumi crittografati dovrebbe funzionare, a patto che il server non abbia headless: rubare il server oi nastri richiederebbe quindi la rottura della crittografia a livello di disco.

Per il secondo scenario, la crittografia dei dati del database è di aiuto, ma solo se non si memorizzano le chiavi o le frasi d'accesso necessarie in qualsiasi luogo.

Nel terzo scenario, tutto dipende dal contesto in cui si verifica l'attacco: se è, ad esempio, un attacco XSS o CSRF, allora un utente malintenzionato può fare tutto ciò che l'utente legittimo può fare, e la crittografia dei dati non lo fa aiuto a tutti.

Il modello di minaccia, quindi, è un utente malintenzionato che ottiene l'accesso in lettura al database non elaborato, trovando le credenziali di accesso e riuscendo a collegarsi al server del database dall'esterno o ottenendo l'accesso come root al server del database. Un percorso tipico è quello di ottenere prima l'accesso alla shell sul server web; da lì, un utente malintenzionato può quindi leggere le credenziali di accesso dal file di configurazione e connettersi al database.

Un'ulteriore considerazione è dove mantieni le chiavi e i passphrase, specialmente se stai usando una piattaforma con un modello di esecuzione senza stato come PHP. Idealmente, è possibile che il cliente digiti la propria passphrase quando richiesto, e lo tenga solo in memoria, o ancora meglio, esegua la decrittazione lato client (ma ciò non è spesso fattibile). Su una piattaforma senza stato, lo stato viene solitamente portato avanti usando sessioni, memcache, database o file flat; ma tutti questi sono molto più vulnerabili rispetto al mantenimento dello stato nella memoria di un'applicazione web di stato. Evitare questo è un problema di pollo e uova, perché se si cripta lo stato prima di persisterlo, si è appena creato un altro segreto che bisogna ricordare in sicurezza. Ricordare la passphrase sul client e inviarlo insieme ad ogni richiesta che ne ha bisogno potrebbe essere la soluzione meno orribile di allora; il cliente è ancora vulnerabile in caso di perdite XSS, e devi prendere le consuete precauzioni (servire solo https, impostare tutti i cookie su httponly e sicuro, ecc.), ma questi sono problemi che hai comunque.

Se sviluppi attentamente l'applicazione web utilizzando un efficace framework MVC come CakePHP. Zend o Rails, quindi dovresti essere in grado di abilitare / disabilitare la crittografia a livello di dati Modale.

CakePHP ad esempio ha alcuni esempi di comportamenti per Modal che crittografano i dati. Rendere trasparente il processo per i controller e le viste.

Ignorare problemi relativi all'indicizzazione e ad altri problemi tecnici del database quando si esegue questa operazione. Dovrebbe essere possibile avere questa opzione configurabile.

Inoltre, attivare la crittografia in un momento successivo o solo sul server di produzione. I dati crittografati sono difficili da eseguire il debug e funzionano durante lo sviluppo e possono essere eseguiti solo su determinate colonne.

Sì, dovresti crittografare il database.

Dato che si tratta di informazioni personali e sensibili, sono assolutamente convinto che dovrebbe.

Dalla password, è possibile derivare una chiave di crittografia che si archivia solo per la sessione. In questo modo, non viene memorizzato da nessuna parte e nessuno (inclusi gli amministratori di database) può saperlo poiché nessuno può conoscere la password. Chiunque tenti di visualizzare direttamente il DB, guarderà senza senso. L'unico modo per corromperlo è tramite il dirottamento di sessione, ma qui presumo che anche le sessioni siano sicure.

Mi chiedo perché il client ti chiede di crittografare il DB? Se ti chiedesse di proteggere i dati, sarei d'accordo, ma ha già in mente un'implementazione implicita. Quindi, fino a quando non sa esattamente di cosa sta parlando, sta solo gettando parole d'ordine dal mio punto di vista.

Inoltre trovo molto inutile crittografare il DB, perché sono convinto che letteralmente ogni DBMS principale prende in considerazione la sicurezza in modo appropriato e probabilmente migliore di quanto si possa. Per accedere al DB attraverso il DBMS occorrono credenziali. Nel caso di un DB crittografato avresti bisogno anche di quelle credenziali, e per decrittografare i dati ti serviranno quelle credenziali che sembra già avere.

Seguendo questa mentalità, propongo di lasciare che il DBMS gestisca la sicurezza e di impegnarsi a proteggere le credenziali dall'input dell'utente all'accesso db, ma può anche imporre password e cambiamenti periodici.