Il sovraccarico di una funzione PHP nativa per crittografare i dati per la conformità HIPAA

Question

Informazioni

Background:

faccio parte di un team di sviluppatori che esegue un'applicazione web che memorizza e recupera i dati HIPAA (medici). Recentemente, le linee guida HIPAA sono state aggiornate per includere un criterio che richiede che tutte le informazioni identificative dei client vengano crittografate quando sono "a riposo" (memorizzate nel database e non accessibili).

il problema iniziale

Il primo problema che abbiamo dovuto affrontare è stato determinare il modo migliore per bidirezionale crittografare i dati in un modo che rende i dati sicuri in caso di violazione.

soluzione iniziale

La soluzione più veloce siamo arrivati ​​a era quello di utilizzare mcrypt per crittografare i dati prima di abbiamo inserito nel database.

il nuovo problema

L'applicazione che stiamo sviluppando è piuttosto vecchio (come le applicazioni web Go) e usa un sacco di programmazione procedurale, così come forte dipendenza della funzione mysql_query per inserire, aggiornare, recuperare, e cancella i dati Non abbiamo il tempo o il lusso di tradurre il nostro codice in un livello di astrazione del database. Quindi, l'unico modo per implementare questo sistema di crittografia/decrittografia è quello di modificare manualmente tutte le query CRUD per utilizzare i dati che sono stati crittografati tramite mcrypt. Questo è molto inefficiente ed estremamente soggetto a errori.

La nostra Soluzione proposta

Abbiamo deciso che il modo più veloce ed efficace per risolvere il nostro problema è quello di sovrascrivere la funzione nativa mysql_query con uno dei nostri stessi concepite. Nella nostra nuova funzione, cripteremo/decodificheremo i valori dei dati prima di inviare la query al server/restituire il set di risultati.

Where You gente venire in

1. È questa la soluzione migliore per risolvere il nostro problema iniziale?
2. Come si fa a sovrascrivere una funzione PHP di base esistente?

Answer 1

Anche se in precedenza hai dichiarato che non puoi/non tradurrò il tuo codice in un livello di astrazione del database, credo che sarebbe la soluzione ideale. Certo, ora c'è molto più lavoro, ma paga. Quello che hai proposto è un hack, che può (e probabilmente lo farà) portare a errori e mal di testa in futuro.

La cosa migliore sarebbe criptare l'intero database, come proposto nei commenti. Ci sono soluzioni là fuori per la crittografia trasparente in diversi livelli, vale a dire: this o this

Un'altra cosa che si potrebbe voler esaminare è nativo encryption and decryption funzioni di MySQL, che potrebbero essere utilizzati per implementare la crittografia a livello di colonna se siete preoccupati sulle prestazioni.

Answer 2

È possibile crittografare a livello di file system e consentire al sistema operativo di gestirlo. Se desideri gestirlo a livello di PHP, estendi, non sovrascrivere.

function mysqle_query() { 
    // Do some stuff 
    // like replace fieldnames with AES_ENCRYPT(fieldname) on insert and delete 
    // and replace fieldnames with AES_DECRYPT(fieldname) on select 
    mysql_query(); 
} 

Answer 3

Mentre la soluzione migliore sarebbe il livello di astrazione che le altre risposte hanno suggerito, è possibile escludere funzioni PHP esistente con le proprie versioni con il PECL Runkit extension

Qualcosa di simile:

runkit_function_rename ('mysql_query', 'mysql_query_old'); 
function mysql_query ($query , $link_identifier=null) { 
    // modify $query here for UPDATE/DELETE statement and any WHERE clause, etc 
    $newQuery = modifyQuery($query); 

    if (is_null($link_identifier)) { 
     $result = mysql_query_old ($newQuery); 
    } else { 
     $result = mysql_query_old ($newQuery, $link_identifier); 
    } 
    // modify $result here for returned data from any SELECT statement 
    return modifyResult($result); 
} 

Nota: per impostazione predefinita, solo le funzioni userspace possono essere rimosse, rinominate o modificate . Per ignorare le funzioni interne di , è necessario abilitare l'impostazione runkit.internal_override in php.ini.

Non è una soluzione che consiglio davvero. Ho dovuto fare qualcosa di simile qualche anno fa in Java, dove era molto più facile estendere jdbc; ma mentre si analizza la sintassi delle query SQL è abbastanza difficile, diventa ancora più difficile se le query utilizzano variabili di bind. Fai attenzione alle corde scappate! Fai attenzione a qualsiasi funzione correlata come mysql_db_query, nel caso in cui vengano utilizzati insieme a mysql_query all'interno dell'applicazione!

Ci scusiamo per la tipizzazione tremolante. Mia moglie è stata rimbalzando nostro router un paio di volte mentre I'be scritto questo suggerimento

Answer 4

Penso che un modo di gestire automaticamente potrebbe essere quella di guardare in MySQL proxy

e implementare la crittografia attraverso quella. Ci ho giocato circa 2 anni fa quando era in una fase iniziale, e da quello che ricordo potrebbe fondamentalmente intercettare le richieste e fare 'cose' con loro :) Nessun cambiamento di codice richiesto essenzialmente. Speriamo che questo aiuti.

Answer 5

Esistono soluzioni disponibili in commercio per facilitare la crittografia dei dati a riposo. Puoi controllare Gazzang o Packet General. Entrambi offrono crittografia MySQL per aiutare con la conformità HIPPA. Good Luck

Answer 6

Penso davvero che tu stia guardando questo dalla prospettiva sbagliata. Questo non è un problema da risolvere dagli sviluppatori tramite la crittografia/decrittografia dei dati man mano che li archivi e li recuperi dal database - usa una soluzione di infrastruttura.

Considerare l'hardware o il software di crittografia dell'intero disco, la crittografia del database stesso tramite la funzione di crittografia dei dati trasparente di RDBMS (se il particolare RDBMS ne ha uno) o tramite il sistema operativo.

Vedi this document from NIST