PHI, NoSQL e ricerca

3

Sto lavorando con un sistema che utilizza NoSQL (Azure Table Storage) principalmente per ospitare i suoi dati. Sfortunatamente, il lavoro riguarda anche la fatturazione e le cartelle cliniche, il che significa che i dati stessi dovranno essere protetti. Va bene, possiamo fornire l'accesso degli utenti al sistema e crittografare tali dati sul filo e a riposo nel NoSQL.

Il problema deriva dal fatto che vogliamo che i dati siano ricercabili . Non crittografato, non è un problema così tanto - creiamo le chiavi di riga dei campi ricercabili e possiamo fare interrogazioni di intervallo. Crittografato, non funzionerà. Peggio ancora, sembra che qualsiasi tipo di struttura o struttura simile debba essere archiviata senza cifratura, vanificando lo scopo. La memorizzazione di stringhe parziali crittografate renderebbe facile rompere la crittografia poiché si perderebbero informazioni sul testo in chiaro.

Finora, le uniche soluzioni semi-valide che ho incontrato sono 1) smettere di usare NoSQL o 2) leggere l'intero set in memoria e fare la ricerca lì.

Né sono particolarmente elettrizzanti. C'è qualche altro buon approccio per questa confluenza di requisiti?

    
posta Telastyn 11.12.2015 - 15:33
fonte

1 risposta

1

Potresti conservare un archivio separato (o come parte del record NoSQL) degli hash dei dati ricercabili. La natura di un hash che non è reversibile fa perdere molte meno informazioni delle stringhe crittografate quando si hanno diverse quantità di stringhe disponibili. Poi, quando arrivano le query, hai appena cancellato le informazioni sulla richiesta di query e la corrispondenza sugli hash. Ciò rende i dati meno compromettenti rispetto alla crittografia stessa, mantenendo le prestazioni di non dover decrittografare tutti i dati.

Per maggiore sicurezza, se esiste un discriminatore (come l'organizzazione proprietaria) che è possibile utilizzare per le persone che eseguono la query che esamina i record su cui stanno interrogando - potresti usarlo come sale. Ciò funzionerebbe solo se c'è una corrispondenza completa con l'ambito: una serie di record è visibile solo per il gruppo A, e il gruppo A può solo visualizzare quell'insieme di record; quindi puoi salare gli hash per quel gruppo separatamente dal sale usato per il gruppo B ecc.

Inoltre, se hai un discriminatore come sopra, puoi decifrare in memoria o fare altre cose che potrebbero essere costose, solo su quei particolari gruppi di dati. Ridurre l'ambito dei dati su ogni operazione come quella può consentire di fare cose molto più costose per ottenere le corrispondenze delle query.

    
risposta data 11.12.2015 - 15:44
fonte

Leggi altre domande sui tag