Anonimizzare i dati sensibili nel DB MySQL mantenendo la ricerca [chiusa]

3

Ho un database MySQL che memorizza dati personali (personali) sensibili; e sono stati incaricati di garantire che questi dati siano crittografati in qualche modo per proteggere le persone e i loro dati se ad es. il server deve essere compromesso o un utente malintenzionato dal nostro provider di servizi di hosting accede al server senza autorizzazione. Il database viene utilizzato da un framework Web PHP che si trova sullo stesso server.

Sto lottando con un buon schema che consente di crittografare i dati e amp; impossibile leggere senza una corretta autorizzazione; mantenendo la funzionalità (indici, relazioni con il database, possibilità di rileggere i dati nel framework web). Quali sono le opzioni migliori?

Due approcci che ho considerato sono:

1) Crittografia di campi / dati specifici nel database con una chiave in modo che se il database viene compromesso, le informazioni in esso non saranno deducibili da un singolo utente (ad esempio, manteniamo indo e relazioni, ma le informazioni personali identificabili sono criptate ). L'app decodifica le informazioni utilizzando la chiave in fase di runtime. La sfida consiste nel modo in cui gestire la chiave: se è inserita nella logica dell'app o accessibile dalla logica dell'app come un file sullo stesso server, può comunque essere compromessa. Forse potrebbe essere posizionato su un altro server; ma sarebbe ancora necessario accedere in fase di esecuzione dalla logica dell'app; ad esempio, l'accesso alla logica dell'app consentirà di acquisire il possesso della chiave. Forse potrei memorizzare la chiave in memoria all'avvio del server; ma introduce un possibile problema di stabilità (servizio inattivo dopo il riavvio). Quali sono le opzioni? È un buon approccio?

2) Implementazione di una sorta di divisione logica dei dati tra le informazioni di identificazione personale e il database rimanente. Per esempio. una tabella con informazioni personali (nome utente, email) un indice; una tabella con i dati sensibili (ad esempio tabella di informazioni sulla salute) con un altro indice; e quindi introducendo un tipo di crittografia a chiave unidirezionale (p.es. per esempio link ) mappatura tra i due, dove il relazione tra le informazioni personali e amp; i dati sensibili possono essere creati (anche in fase di esecuzione dalla logica dell'app) se è possibile fornire una chiave per abbinare la tabella. Ma ancora una volta, mi imbatto sulla necessità di gestire l'accesso alla chiave utilizzata nello scenario di cui sopra; simile a sopra.

Che cosa è la migliore pratica?

    
posta ppswede 30.09.2014 - 16:55
fonte

3 risposte

1

Tutti i dettagli sulla corretta gestione delle informazioni del database vanno ben oltre lo scopo di una rapida risposta StackExchange. Vuoi davvero farlo in modo giusto . Parte del problema è l'architettura in cui il database e l'app Web che accede alle informazioni sensibili si trovano sullo stesso server. Se quel server viene compromesso, lo stesso vale per il materiale di codifica per qualsiasi crittografia eseguita.

Se stai cercando una soluzione pratica, piuttosto che la teoria del design, ho due suggerimenti.

Uno è gratuito e open source, ma attivamente in fase di sviluppo (quindi non ho idea di quanto sarebbe adatto per il tuo uso di produzione aziendale).

L'altra è una soluzione commerciale che è possibile acquistare (adatta per il business, ma non conosco il budget o le esigenze aziendali).

Open source - cryptdb (codice disponibile su github)

Commerciale - Voltage SecureData

Ho usato entrambi, ma senza sapere di più sulle tue circostanze, non potrei dire quale sia giusto per te. La tensione è più business-ready e utilizzata dalle aziende Fortune 500, cryptdb è più un progetto di ricerca che può fare appello ai tipi fai-da-te.

    
risposta data 14.11.2014 - 21:32
fonte
0

Questo è abbastanza simile a Proteggi i dati del database da tutti, inclusi amministratori di sistema, ecc .

La tua seconda opzione non funziona (almeno in isolamento). Solo conoscere i dati delle informazioni sulla salute potrebbe essere "abbastanza grave" (e indirettamente abbinabile all'utente). Potrebbe essere interessante nascondere ulteriormente questa relazione, ma non sono convinto che valga la pena farlo.

La seconda opzione è corretta. Poiché si desidera mantenere la ricerca del database, mantenere gli indici nei campi utilizzati come chiavi (ad esempio nome, numero paziente), che non si sta crittografando. Gli altri campi sono decifrati dall'applicazione.

La migliore soluzione su dove archiviare la chiave non è salvarla. Fai in modo che l'utente inserisca manualmente la chiave. O crittografarlo su diverse chiavi pubbliche e l'utente deve sbloccare la propria chiave prima di utilizzarla.

Supponiamo di avere il seguente schema:

Table doctors:
 Username, public key, disabled

Table patients:
 Name, encrypted info

La prima volta che un nuovo utente apre l'app, crea localmente una nuova chiave pubblica (protetta da password) e si registra nella tabella dei medici (soggetto a convalida, ecc.).

La volta successiva, all'utente viene chiesta la password (utilizzata per sbloccare la chiave) e la conoscenza della chiave privata viene utilizzata per controllare l'accesso.

Quando recuperi i dettagli da un paziente, recupera il blob, decrittalo con la tua chiave pubblica ed estrai i dettagli (potrebbe essere più efficiente memorizzare più campi in un blob se saranno effettivamente usati insieme).

È possibile memorizzare in chiaro nel db (che consentirebbe a un utente malintenzionato di inserire la propria chiave) o crittografato nel BLOB, quindi un medico esistente deve aggiungere il nuovo medico come "curare il paziente".

Se l'app stabilisce che un paziente è collegato a un medico con il bit disabilitato è impostato (ad esempio, ha lasciato l'azienda), tale viene rimosso dall'elenco delle persone a cui sono crittografate le cose.

    
risposta data 30.09.2014 - 18:31
fonte
0

Penso che sia necessario decidere se si desidera crittografare l'intero Db o se si desidera criptare ogni record singolarmente.

Crittografare l'intero Db - è facile da realizzare. Esistono vari meccanismi che è possibile implementare. Questo meccanismo offre una buona protezione dall'essere hackerato / db rubato, ma sarà facile per il personale IT leggere / rubare i dati.

Crittografia di ogni record: offre agli utenti la migliore protezione dei dati. Come se il Db venisse rubato, gli hacker avrebbero dovuto forzare ogni record. Implementare come soluzione 2 server, 1 server che genera la chiave, l'altro server che memorizza i dati. Questo protegge i tuoi dati dal tuo personale interno, come pure "Mr Black Hat", a patto che i 2 database siano amministrati separatamente. Mr "Black Hat" ora ha bisogno di rubare entrambi i Db da 2 sistemi per accedere ai tuoi dati.

Spero che questo possa darti alcune idee su come affrontare il problema.

    
risposta data 30.10.2014 - 07:41
fonte

Leggi altre domande sui tag