Mascheramento dei dati in un database [chiuso]

0

Sfondo

Il team di sviluppo sta ricevendo dati di produzione (come file di backup del database) al fine di correggere bug e miglioramenti delle applicazioni. Il team di sviluppo ripristina questi backup nel loro ambiente ed esegue il lavoro di sviluppo dell'applicazione / correzione dei bug ecc.

Problema

Il cliente è preoccupato di esporre i dati di produzione sensibili come le Informazioni personali (identificazione personale) al team di sviluppo. Il cliente ha bisogno di schermare questi dati sensibili preservandone le proprietà in cui il team di sviluppo può eseguire il lavoro giorno per giorno senza interruzioni.

Non è necessario invertire i dati proiettati.

Probabile soluzione 1: mascheramento dei dati

Come vedo la soluzione più corretta per questo problema è identificare i campi del database PII ed eseguire il mascheramento dei dati. Un problema che stiamo affrontando è la necessità di preservare le proprietà dei dati nel DB come segue.

  • La lunghezza dei dati mascherati non può andare oltre la particolare lunghezza del campo.
  • I dati mascherati devono essere nello stesso tipo di dati dei dati originali: ad esempio se il tipo di campo DB è int i dati mascherati dovrebbero anche essere un int
  • Se il risultato mascherato del valore ABC è XYZ, tutte le istanze di dati ABC devono essere mascherate su XYZ (questo perché alcuni PII vengono utilizzati come chiavi DB)

Domande

  • Dato che non è necessario invertire i dati mascherati, possiamo usare l'hashing per realizzare questo? In tal caso, come mantenere le proprietà dei dati che ho descritto sopra?

  • Se useremo la crittografia, possiamo conservare le proprietà dei dati? Quali sono i migliori algoritmi che abbiamo?

  • Esistono altre tecniche per realizzare questo obiettivo?

  • Possiamo impedire l'inferenza dei dati utilizzando il mascheramento dei dati?

posta user3496510 19.04.2017 - 14:04
fonte

1 risposta

2

Il mascheramento dei dati è una richiesta comune e vari fornitori hanno la propria soluzione o si affidano a soluzioni di terze parti. Potresti implementare il tuo (ad esempio usando l'hashing) ma, come hai sottolineato, sarebbe difficile mantenere l'integrità, i vincoli e i formati dei dati. Ad esempio, potresti avere una colonna di identità nazionale che viene convalidata utilizzando modulo X (o qualche altro meccanismo di verifica). Come maschereresti queste colonne ma preserverai la validazione?

Utilizzare gli strumenti già disponibili risolverà questo per te. Proprio come un esempio di funzionalità che tali strumenti offrono (e non sto suggerendo che dovresti usare questo specifico strumento), dai un'occhiata a Oracle propria soluzione per il mascheramento e il subset dei dati . Citazione dalla scheda tecnica che descrive alcuni dei formati di mascheramento dei dati supportati:

  • Encryption encrypts the sensitive data using a key while preserving the format of the data. This transformation is useful when masked data sent to a third party has to be merged back along with further updates.
  • Format Preserving Randomization (or auto mask format) randomizes the data, preserving the input length, position, the case of the character (upper or lower), and special characters in the input.
  • Conditional Masking masks columns according to different conditions. For example, identifiers that belong to the United States can be masked using Social Security Number format and those that belong to the United Kingdom can be masked using National Insurance Number format.
  • Compound Masking groups and masks related columns together. For example, if you want to shuffle address fields like city, state, and country, then grouping city and the state will keep these columns together during the shuffling process.
  • Deterministic Masking generates consistent masked output for a given input across application schemas and databases. This makes it possible to mask names consistently or deterministically across different modules across your organization.

Credo che questi formati si adattino alle tue esigenze.

Indipendentemente dall'architettura RDBMS, il punto è che la richiesta è comune, esiste un mercato e su questo mercato ci sono vari fornitori che forniscono la soluzione. Dovresti scegliere uno di loro piuttosto che reinventare il tuo.

    
risposta data 19.04.2017 - 16:31
fonte

Leggi altre domande sui tag