Obfuscating ID per una maggiore sicurezza nel DB?

Se stai tentando di essere conforme e / o di evitare la regola di notifica di violazione di HIPAA negli Stati Uniti, allora l'offuscamento delle relazioni tra i dati all'interno del tuo database non ti aiuterà affatto.

In HIPAA, se i dati sono crittografati non è necessario informare i pazienti / assicuratori / ecc. della violazione. Tuttavia, crittografato significa che è stato crittografato utilizzando una cifratura conforme a FIPS 140-2 e solo i dati crittografati sono stati ottenuti dalla terza parte.

Su un database, è possibile utilizzare strumenti come la crittografia trasparente del database o suite di crittografia di terze parti. Ciò significherebbe che se qualcuno avesse ricevuto una copia del database, sarebbe stato FIPS 140-2 codificato in modo conforme e quindi non avrebbe attivato notifiche di violazione o altre conseguenze sotto HIPAA.

Tuttavia, il semplice fatto di avere un database difficile da comprendere non è coperto da nessuna parte sotto HIPAA e la sicurezza per oscurità non ti conquista punti su un audit CMS ... anche se spieghi che l'oscurità è un "controllo compensativo" per un requisito HIPAA.

Anche se la sicurezza in genere significa escludere individui non autorizzati, la prossima cosa peggiore che possa accadere a un'organizzazione che mantiene i dati PHI sta perdendo quei dati. Avere un DB con relazioni complesse rende facile perdere quei dati e l'integrità dei dati dovrebbe essere considerata un problema di sicurezza quando si tratta di HIPAA.

Si noti che la crittografia trasparente del database o altri metodi di crittografia on-line faranno ben poco contro il compromesso online del database, ad es. attraverso l'iniezione SQL. Se qualcuno ottiene un dump di DB eseguendo le istruzioni SELECT *, questi dati non verrebbero crittografati. Per questo, è necessario proteggere / segmentare gli utenti del database e anche esaminare le migliori pratiche per proteggere l'applicazione Web front-end.

In breve, crittografare il database in qualche modo; ma la crittografia DB dovrebbe essere solo una piccola parte di una più ampia strategia di conformità HIPAA. La sicurezza per oscurità, tuttavia, non dovrebbe far parte della vostra strategia di sicurezza.

Hai chiesto migliore , permettimi di iniziare qualificando la mia risposta come migliore nel senso che è il mio miglior sforzo per permetterti fare la tua scelta forse con più sicurezza. Dal momento che "il migliore" può essere piuttosto soggettivo, e io non sono il potentissimo conoscitore di cose , sono sicuro che è possibile trovare un'altra risposta migliore .

Voglio anche citare Regola di usabilità di AviD :

Security at the expense of usability comes at the expense of security.

(Anche se non c'è una connessione diretta a questo, voglio indicarlo, se non altro per dire che se si interrompe l'usabilità, allora tutto è inutile)

Il mio primo pensiero è "Oh no, tutto il tuo DB viene rubato!". Spero che la tua prima priorità sia quella di prevenire questo (non so se sei realmente preoccupato per questo o se si sta solo pianificando uno scenario peggiore). Quindi fai tutto il necessario per nascondere tutti i dati richiesti . Eventuali dati aggiuntivi che è possibile nascondere senza un notevole impatto sulle prestazioni sono gravi.

Ho fatto una quantità molto piccola di HIPAA ai miei tempi e ho trovato alcune regole forse intenzionalmente vaghe. Presumo che ciò consenta l'utilizzo di nuove tecniche senza dover modificare le regole o qualcosa del genere.

In breve, se gli ID di offuscamento sono richiesti nella tua situazione, allora deve farlo (i requisiti sono requisiti), in caso contrario, allora possibile fai questo se senti che la difficoltà e il rendimento sono tollerabili. Seguire prima i requisiti. Vai sopra e oltre dove ha senso.

Nel tuo caso, sembra come se non avesse senso passare a tutti quei problemi in più solo per rendere la manutenzione futura molto più difficile. Potrebbe essere un uso migliore del tempo per concentrarsi sulla protezione del DB stesso mantenendo la crittografia / offuscamento solo sui campi richiesti. Puoi nascondere gli id che desideri, ma se il DB viene facilmente rubato, allora qual è il punto?

PS: non sono un avvocato, né gioco uno in TV. Assicurati di controllare tu stesso i requisiti HIPAA se in effetti stai trattando con HIPAA.

Questa è in definitiva una pessima idea e ti costerà in termini di integrità dei dati. Le relazioni dati che sono oscurate sono relazioni di dati che saranno danneggiate e inaffidabili. Non ti rende nemmeno più sicuro. L'oscurità protegge solo dalla più mite curiosità. Guarda la lunga storia di sistemi oscurati incrinati per comprovare ciò.

Questo approccio porterà a appuntamenti persi, possibilmente appuntamenti fatti con il medico sbagliato e un sistema generalmente inaffidabile.

In generale, questi tipi di requisiti (HIPPA, PCI, ecc.) sono scritti da non-tecnologi e hanno un'interpretazione ampia.

Chiedi alla persona che guida il requisito se è disposto a sacrificare l'integrità e l'affidabilità del sistema per la sicurezza attraverso l'oscurità. Questo è essenzialmente ciò che viene chiesto. La mia ipotesi è che qualcuno stia interpretando HIPPA è un modo molto stretto se stanno chiedendo cose pazzesche come "oscurare gli ID delle tabelle del database".

Il mio consiglio generale è trovare qualcuno con esperienza nell'interpretazione dei requisiti HIPPA di ciò che puoi realmente fare piuttosto che qualcuno che cerchi di interpretarlo nel modo più restrittivo possibile.

Ho appena iniziato a esaminare la conformità HIPPA per una prossima applicazione che sto costruendo, e da quello che vedo tu stai prendendo le regole / i regolamenti un po 'fuori bordo. Per quanto riguarda l'offuscamento dei dati, uno dei requisiti principali è la protezione delle informazioni sanitarie protette elettronicamente o (ePHI). Questo include cose come nomi, numeri SSI o dati riservati o riservati ai pazienti. Uno dei tuoi ID interni nel tuo database non rientrerebbe in questa categoria, e cercando di offuscare ciò creerebbe per te un intero mondo di problemi senza ottenere nulla. Ad esempio, se dovesse verificarsi una violazione dei dati e vedessero che l'Id 5 è legato all'id 8, non significherebbe molto per nessuno senza altri dati personali, che verrebbero crittografati.

Anche in questo caso potrei non essere la migliore fonte dato che sto imparando a conoscere la conformità HIPPA, ma conosco una buona dose di conformità PCI e sembrano abbastanza simili.

Sono d'accordo con gli altri: questa è una cattiva pratica, da ogni POV, inclusi design, audit, recovery, sicurezza, performance. L'elenco continua.

Se un hacker entra nel database, il gioco è finito. Non importa se hai nascosto i dati, sarà una questione di tempo prima che ciò possa essere de-offuscato.

Gli RDBMS in questi giorni consentono le autorizzazioni basate su colonne e, quindi, l'utilizzo di chiavi reali per l'aggiunta ad altre tabelle consente l'utilizzo di query SQL standard, senza il sovraccarico di offuscamento. Inoltre, i revisori apprezzeranno l'attenzione alla capacità di scalare, aggiornare, risolvere e mantenere l'integrità e la sicurezza.

Detto questo, alcuni fornitori, come Microsoft e Oracle, forse altri, hanno intensificato e consentito crittografia molto focalizzata. Le chiavi sono memorizzate in un sistema separato e l'accesso alle colonne è protetto. Microsoft SQL Server, ad esempio, utilizza TDE (crittografia trasparente dei dati) ed EKM (Extensible Key Management) per fare proprio questo. Pertanto, le strutture della tabella non cambiano, e non compromettete il sovraccarico di join con l'offuscamento, et al. Quindi, mentre potresti avere un medico e un paziente, non conoscerai necessariamente i nomi o altri dettagli di entrambi, poiché TDE può consentire la crittografia di questi campi.

I sistemi RDBMS consentono anche la crittografia dell'intero database, per gestire le istanze in cui il database stesso viene rubato.

In breve, non offuscare le chiavi dei dati. Piuttosto, crittografa i dati che sono sensibili. Puoi guardare in questo modo: non offuscare i metadati; piuttosto, cripta solo i dati. Pensa alle chiavi e alle chiavi esterne come metadati.

Fai attenzione, inoltre, a non cadere vittima della pratica di mettere strong sicurezza sulla porta principale, lasciando la porta posteriore sbloccata: i registri delle transazioni, i registri degli errori, le applicazioni, i registri delle applicazioni, i sistemi di backup e le persone a cui ci si può fidare di avere accesso a questi dati e le applicazioni sono tutte fonti di perdite, quindi, autorizzare le autorizzazioni e fare attenzione a ciò che si registra e cosa si fa con tali registri.

Una volta applicati questi principi, diventa meno importante offuscare le chiavi.