Devo crittografare i dati nel database?

Ho un cliente, per il quale realizzerò un'applicazione Web per l'assistenza ai pazienti, la gestione dei pazienti, i consulti, la storia, i calendari, praticamente tutto ciò.

Il problema è che si tratta di dati sensibili, anamnesi del paziente e simili.

Il client insiste per crittografare i dati a livello di database, ma penso che questo peggiorerà le prestazioni dell'app Web. (Ma forse non dovrei preoccuparmi di questo)

Ho letto le leggi sulla protezione dei dati in materia di salute (Portogallo), ma non sono molto specifico al riguardo (le ho appena interrogate a riguardo, aspetto una loro risposta).

Ho letto il seguente link , ma la mia domanda è diversa, dovrei crittografare i dati nel database o no.

Un problema che prevedo nella crittografia dei dati è che avrò bisogno di una chiave, questa potrebbe essere la password dell'utente, ma sappiamo tutti come sono le password dell'utente (12345 ecc. Ecc.) E generare una chiave che dovrei memorizzare da qualche parte, questo significa che il programmatore, dba, qualunque cosa possa avervi accesso, qualche pensiero su questo?

Anche l'aggiunta di un salt casuale alla password dell'utente non risolverà il problema poiché posso sempre accedervi e quindi decrittografare i dati.

Verificherei personalmente le leggi in merito. Se i dati devono essere crittografati, devono essere crittografati.

Se non ricevi alcuna guida, tuttavia, vorrei proteggere il collegamento tra il paziente e i suoi dati. Vale a dire che molto probabilmente ne hai uno PatientIDusato nelle tabelle del database. PatientIDnon identifica un paziente, ma solo la storia medica del paziente, ecc ... Tuttavia, per identificare PatientIDcome Joe Bloggs residente a Rua de São Bernardo Lisbona, se possibile, lo terrei in un DB separato. Utilizzare TDE per i dettagli personali del paziente e considerare la possibilità di crittografarlo in aggiunta a quello usando le chiavi nell'applicazione Web.

Mentre il furto di quei dati medici senza i mezzi per identificare i pazienti sarà estremamente imbarazzante, è improbabile che ci sia qualcosa di diverso. Ci sono letteralmente gare online che utilizzano questi dati medici 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 (infermieri e medici di prima linea), nessuno dovrebbe avere accesso ad entrambi. Gli addetti alla reception necessitano solo dei dati personali del paziente, il personale di laboratorio ha solo bisogno della cartella clinica e del PatientID, gli infermieri chirurgici attualmente solo in condizioni mediche e il nome.

Dopo aver identificato ogni set di ruoli, mira a implementarli non solo nella tua applicazione web, ma anche nel database, oltre a un ulteriore livello di sicurezza.

Sì, è necessario crittografare il database.

La crittografia di base per i dati memorizzati ("dati a riposo") è un principio di sicurezza generalmente accettato ed è probabilmente obbligatoria per legge se il proprio paese dispone di leggi che proteggono le informazioni personali o sanitarie.

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

Se eseguito correttamente, l'hit performance dovrebbe essere piccolo.

A proposito, il link che hai citato (per quanto riguarda la separazione delle informazioni sensibili) è qualcosa che dovresti considerare oltre alla crittografia di base del database.

EDIT: la crittografia di cui sopra avrebbe crittografato il volume. Se qualcuno dovesse rubare il disco rigido, troverebbero i dati crittografati. Tuttavia, se qualcuno eseguisse query nel database, visualizzerebbe i dati non crittografati (ecco perché ho citato la separazione delle informazioni, anche se l'OP non ha voluto discuterne).

Nota che questa raccomandazione è intesa come il minimo che dovresti fare. Se vuoi una consulenza legale, ovviamente dovrai cercare altrove. Se vuoi una discussione più approfondita sulla scrittura di codice sicuro, inizierei con il libro Writing Secure Code .

Prima di decidere su tali questioni di sicurezza, è necessario valutare il modello di minaccia. Senza avere idea di cosa si stia difendendo, è probabile che qualsiasi misura adottata abbia scarso valore.

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

• Attaccanti che ottengono l'accesso fisico ai tuoi dati (ad es. Irruzione nel data center, furto di nastri di backup, ecc.)
• Attaccanti che ottengono l'accesso in lettura al database non elaborato
• Attaccanti che compromettono l'applicazione, ad es. Tramite iniezione SQL, sovraccarichi del buffer, ecc.

Per il primo scenario, l'archiviazione del database e di tutti i backup su volumi crittografati dovrebbe funzionare, a condizione che il server sia senza testa: rubare il server o i nastri richiederebbe quindi di interrompere la crittografia a livello del disco.

Per il secondo scenario, la crittografia dei dati del database aiuta, ma solo se non si memorizzano le chiavi o le passphrase richieste ovunque.

Nel terzo scenario, tutto dipende dal contesto in cui si verifica l'attacco: se si tratta, ad esempio, di un attacco XSS o CSRF, un utente malintenzionato può fare tutto ciò che l'utente legittimo può fare e la crittografia dei dati non aiuta affatto .

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 accedere al server del database dall'esterno o ottenendo l'accesso root al server del database. Un percorso tipico è innanzitutto ottenere 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 conservi le chiavi e le passphrase, specialmente se stai usando una piattaforma con un modello di esecuzione senza stato come PHP. Idealmente, il cliente deve digitare la propria passphrase quando richiesto e tenerlo solo in memoria, o ancora meglio, eseguire la decodifica lato client (ma ciò non è spesso fattibile). Su una piattaforma stateless, lo stato viene generalmente portato avanti utilizzando sessioni, memcache, database o file flat; ma tutti questi sono molto più vulnerabili che mantenere lo stato nella memoria di un'applicazione Web stateful. Evitare questo è un problema di gallina e uovo, perché se si crittografa lo stato prima di persisterlo, si è appena creato un altro segreto che è necessario ricordare in modo sicuro. Ricordare la passphrase sul client e inviarla insieme ad ogni richiesta che ne ha bisogno potrebbe essere la soluzione meno orribile in quel momento;

Ignorando per un momento ciò che il cliente chiede e qualunque siano le leggi ...

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

Ovviamente dovresti assicurarti che il server sia adeguatamente protetto, che la connessione di rete sia protetta e che l'interfaccia utente sia adeguatamente protetta (compresi i timeout della sessione in modo che gli utenti non possano andarsene lasciando l'accesso a chiunque usi il proprio computer). È inoltre possibile crittografare i backup del database. E proteggere fisicamente la stanza in cui si trova il server. Ma non crittograferei i dati in tempo reale.

Chiarimento: si presume che ciò di cui l'OP stava chiedendo sia effettivamente la crittografia dei dati nel database. Non il file system su cui risiede il database.

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

CakePHP, ad esempio, ha alcuni esempi di comportamenti di Modal che crittografano i dati. Rendere il processo trasparente ai controller e alle visualizzazioni.

Ignorando i problemi relativi all'indicizzazione e altri problemi tecnici del database durante questa operazione. Dovrebbe essere possibile avere questo come opzione configurabile.

Inoltre, accenderei la crittografia in un secondo momento o solo sul server di produzione. È difficile eseguire il debug e lavorare con i dati crittografati durante lo sviluppo e può essere eseguito solo su determinate colonne.

Sì, è necessario crittografare il database.

Dal momento che si tratta di informazioni personali e sensibili, credo fermamente che dovrebbero.

Dalla password, è possibile derivare una chiave di crittografia che è memorizzata solo per la sessione. In questo modo, non viene archiviato da nessuna parte e nessuno (compresi i DBA) può conoscerlo poiché nessuno può conoscere la password. Chiunque provi a visualizzare direttamente il DB guarderà senza senso. L'unico modo per corromperlo è tramite il dirottamento della sessione, ma presumo qui 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 finché non sa esattamente di cosa sta parlando, sta solo lanciando parole d'ordine dal mio punto di vista.

Trovo anche molto inutile crittografare il DB, perché sono convinto che letteralmente ogni grande DBMS tenga conto della sicurezza in modo appropriato e probabilmente migliore di quanto tu possa fare. Per accedere al DB tramite il DBMS sono necessarie le credenziali. Nel caso di un DB crittografato, occorrerebbero anche quelle credenziali e per decrittografare i dati occorrerebbero quelle credenziali che sembrano già possedere.

Seguendo questa mentalità, propongo di consentire al DBMS di gestire la sicurezza e di impegnarsi a proteggere le credenziali dall'input dell'utente all'accesso db, anche per imporre password complesse e cambiamenti periodici.