Protezione del database dell'assistenza sanitaria

1. Connessione SSL al server in modo che nessuno possa annusare passphrase o dati attraverso la rete.
2. Non dimenticare il tuo backup: dovrebbe essere crittografato . La chiave deve essere archiviata in modo indipendente, quindi se qualcuno accede al backup non può utilizzare i dati.
3. A seconda del tuo Paese di residenza, possono esserci requisiti legali per la protezione dei dati sanitari.
4. Gestisci le autorizzazioni di accesso : assicurati che se qualcuno perde le autorizzazioni di accesso, l'account viene annullato.
5. Limita l'accesso a determinati indirizzi IP . Nel caso ideale la rete locale. È piuttosto improbabile che qualcuno di un altro continente abbia bisogno di accesso, quindi non aver paura di bloccare interi paesi.
6. Blocca password troppo semplici . Password123 e simili non dovrebbero essere possibili! Se un utente malintenzionato si impossessa di un numero sufficiente di nomi utente, qualcuno avrà una password debole. Usando più IP / una botnet un utente malintenzionato può eludere la protezione della forza bruta.

Vorrei aggiungere un controllo di accesso a grana fine. Hai bisogno di un livello in cima al tuo database che controlli chi può accedere a quale cartella clinica. Il NIST definisce quale controllo di accesso a grana fine implica qui .

Dopo averlo installato, devi anche una tecnica per registrare tutti gli accessi e tutte le informazioni di recupero in modo che gli utenti possano essere ritenuti responsabili.

Entrambe queste tecniche sono necessarie per implementare la privacy dei dati che è particolarmente importante nel settore medico.

Dai un'occhiata al sito web Privacy che avrà anche dei buoni suggerimenti.

Hai una buona lista di ciò che deve essere fatto per proteggere e rafforzare un'applicazione, ciò che manca è il reporting. La sicurezza non riguarda solo la protezione, riguarda la gestione. Aggiungo al tuo elenco un sistema di segnalazione che può fornirti alcune statistiche di gestione sugli accessi non riusciti, i tentativi di violare la sicurezza, ecc.

Buone risposte qui.

Vorrei approfondire i 4 punti che hai menzionato:

• Crittografia delle informazioni riservate
• Privilegi limitati per ogni utente
• Registro di controllo
• Controllo di accesso

Li sto osservando separatamente perché sono quelli che sono particolarmente importanti quando gestisci dati personali / confidenziali come i dati relativi alla sanità. Altri, come SQL Injection, vengono solitamente trattati sul livello dell'applicazione (utilizzando ad esempio un firewall per applicazioni Web).

Ora torniamo ai nostri 4 punti, avrete bisogno di una soluzione di crittografia DB completa che abbia tutte le 4 funzionalità.

In un caso come il tuo, potresti voler controllare una soluzione di crittografia basata su colonne come D'Amo o MyDiamo se stai utilizzando DBMS open source. Le cosiddette "soluzioni di crittografia trasparente" che crittografano i dati a livello di file non ti proteggeranno da qualcuno che ruba fisicamente il tuo disco rigido DB, ma sono poco più che inutili se hai bisogno di un controllo di accesso strong basato su utenti, applicazioni, IP indirizzi, ora del giorno, ecc.

Un altro ovvio vantaggio che si ottiene con le colonne in un caso come il tuo è che non dovrai crittografare tutti i dati. Puoi scegliere di crittografare colonne specifiche che contengono informazioni riservate e definire criteri diversi e chiavi di crittografia enc / dec per colonna.

La gestione delle chiavi sarà ovviamente un altro problema separato dall'ambito di questa discussione.

Spero che questo aiuti.

Divulgazione: sono un consulente per i prodotti sopra menzionati.