Requisito di anonimizzazione / crittografia dei dati

2

Ho controllato i post precedenti e non ho trovato quello che stavo cercando- scuse se questa è una ripetizione.

Sto lavorando a un incarico di analisi per un cliente e lui ha bisogno di condividere l'accesso alle sue transazioni di vendita dei clienti per farmi fare il mio lavoro. L'idea era di creare una routine di crittografia in base alla quale i dettagli come SSN e Zip sarebbero stati resi anonimi in modo tale che non avrei accesso ai dati PII. Quando presento i risultati, ha bisogno di avere la possibilità di vedere i dati originali dal testo confuso con cui lavoro.

Da una prospettiva di definizione, capisco che il mascheramento / l'offuscamento nascondono i dettagli e possono avere un impatto sull'integrità referenziale. Leggo sulla tokenizzazione e credo che sia un modello abbastanza complesso. Probabilmente mi manca una sfumatura qui ...

In realtà non mi interessa il tempo di elaborazione per criptare / decriptare - che non è rilevante e il costo di elaborazione può essere ignorato. Ho solo bisogno di un modo per SSN: 123-45-6789 da crittografare in modo coerente per dire, A467YuGHT, così posso lavorare senza ostacoli e il cliente è a suo agio che nessun dato che ha condiviso con me viola le PII dei clienti. Quando invio un rapporto affermando che A467YuGHT è un potenziale churn, lo decifra di nuovo a 123-45-6789 [ce ne sono troppi PII per me per creare identificatori alternativi]

Stavo pensando a una chiave privata (che il cliente conserva) / chiave pubblica per fare questo: mi manca qualcosa qui? Qualsiasi strumento open source che faccia questo

    
posta raghu 03.07.2014 - 22:51
fonte

4 risposte

2

Capisco i tuoi problemi, ma una delle massime fondamentali della crittografia è che non devi reinventare la ruota e creare il tuo algoritmo di crittografia, soprattutto perché non sarà affatto sicuro come uno stabilito.

Questi dati saranno accessibili via Internet o trasmessi su canali non criptati? Se la risposta a uno di questi è sì, il fattore di rischio aumenta in modo esponenziale. Se usi i tuoi sforzi per oscurare la casa, basta un determinato hacker per scoprirlo e loro avranno tutti i tuoi dettagli SSN.

Come hanno potuto trovarlo? Cosa succede se il cliente lascia qualcosa in giro dicendogli come decifrare? Cosa succede se la tua email viene violata? Cosa succede se il tuo server non è sicuro come pensavi che fosse?

Hai davvero bisogno di una soluzione in cui, se una qualsiasi di queste cose dovesse accadere, un avversario non può ancora decrittografare i dati, e in realtà ciò viene fornito solo con un'infrastruttura a chiave pubblica. Certo, ci sono modi per sconfiggerlo, ma sfortunatamente la realtà è che sono molto più difficili di quanto non lo sarebbero per compromettere un algoritmo di crittografia sviluppato in proprio.

    
risposta data 03.07.2014 - 23:04
fonte
2

Ti consiglio di mantenerlo semplice. Potresti semplicemente AES i campi che devi proteggere.

Indipendentemente dal metodo di crittografia che usi, devi criptare insieme alcuni campi:

  • Nome + cognome
  • Data di nascita
  • Stato + numero civico + nome via * ...

Altrimenti potresti provare l'analisi statistica contro i dati.

    
risposta data 04.07.2014 - 01:54
fonte
0

La maggior parte se non tutti i motori di database supportano "colonne crittografate" che memorizzano in modo sicuro i dati, quindi in questo modo sì ci sono strumenti che fanno questo per te.

Successivamente hai il problema della ricerca basata su quelle colonne crittografate.

link

La rapida spiegazione è che si memorizza un hash dei dati insieme ai dati crittografati. È possibile eseguire query e partecipare a tale colonna solo se si conosce il contenuto di tale colonna, quindi questa tecnica è fattibile solo per i dati che l'utente conosce esplicitamente per il punto di ingresso (parametri di input) della query, ma dopo si dovrebbe essere in grado di iscriviti ma solo sulle corrispondenze esatte , in quanto anche la mancata corrispondenza di uno spazio bianco causerà un effetto valanga sull'hash.

    
risposta data 20.11.2014 - 16:24
fonte
0

Perché non usare solo uno strumento come IRI FieldShield (funziona su qualsiasi DB e file flat tramite Eclipse o riga di comando) e applicare la crittografia AES-256 che preserva il formato come regola attraverso le colonne SSN e ZIP code tra le origini? Ciò preserva il realismo, l'integrità referenziale, l'accesso limitato e la reversibilità allo stesso tempo.

    
risposta data 25.11.2014 - 05:31
fonte

Leggi altre domande sui tag