Secondo Simson L. Garfinkel presso il Laboratorio di tecnologia dell'informazione della divisione di accesso alle informazioni del NIST,
La de-identificazione non è un'unica tecnica, ma una raccolta di approcci, algoritmi e strumenti che possono essere applicati a diversi tipi di dati con diversi livelli di efficacia. In generale, la protezione della privacy migliora con l'impiego di tecniche di anonimizzazione più aggressive, ma nel set di dati risultante rimane meno utilità.
-De-identificazione delle informazioni personali, NISTIR 8053
Static data masking (SDM) è il termine riconosciuto dal settore per questi vari mezzi di anonimizzazione degli elementi di dati inattivi. Gli elementi sono in genere valori di colonne di database o campi di file flat considerati sensibili; nel settore sanitario, sono indicati come identificatori chiave. Sono specificamente a rischio le informazioni di identificazione personale (PII), le informazioni sanitarie protette (PHI), i numeri di conto primario (PAN), i segreti commerciali o altri valori sensibili.
Il prodotto di sicurezza incentrato sui dati "punto di partenza" IRI FieldShield, o il prodotto IRI CoSort e la piattaforma IRI Voracity che includono le stesse funzionalità, forniscono molteplici funzioni di rilevamento dei dati e SDM per più origini dati. Le funzioni di mascheramento per campo/colonna disponibili includono:
- più algoritmi di crittografia (e decrittografia) conformi a NSA Suite B e FIPS, inclusa la conservazione del formato crittografia
- Hashing SHA-1 e SHA-2
- ASCII de-ID (bit scrambling)
- codifica e decodifica binaria
- sfocatura o bucketing dei dati (anonimizzazione)
- generazione o selezione casuale
- redazione (offuscamento dei caratteri)
- pseudonimizzazione reversibile e non reversibile
- logica dell'espressione personalizzata (calcolo/riproduzione casuale)
- filtraggio o rimozione del valore condizionale/parziale (omissione)
- sostituzione del valore personalizzato
- spostamento di byte e funzioni di stringa
- tokenizzazione (per PCI)
Puoi anche "rotolare la tua" funzione di mascheramento dei dati esterni. Ciò consente di chiamare una routine a livello di campo scritta in modo personalizzato in fase di esecuzione anziché una routine incorporata.
La domanda rimane, quale funzione di mascheramento dovrei usare (su ogni articolo)? Ciò dipende dalle esigenze e dalle regole aziendali, nonché dalle leggi sulla privacy dei dati applicabili. A livello tecnico, ciò di solito significa decidere come deve apparire il testo cifrato risultante (dati mascherati), se deve essere reversibile o unico, quanto è sicuro e, eventualmente, che tipo di risorse di calcolo e tempo sono disponibili per il processo . Diamo un'occhiata a questi criteri decisionali comuni in dettaglio:
Aspetto (realismo)
I dati appena mascherati dovrebbero assomigliare più o meno ai dati originali? E le sue dimensioni e il suo formato? La pseudonimizzazione e la crittografia di conservazione del formato sono i due modi più comuni per
conserva l'aspetto dei nomi propri e dei conti o numeri di telefono a cifre alfa, rispettivamente. Ma il mascheramento delle sottostringhe (a/k/una redazione parziale del campo, ad es. XXX-XX-1234) potrebbe andare bene per cose come gli SSN. Pensa alla persistenza e alla visualizzazione dei dati per l'analisi, ecc.
In relazione a ciò, l'aspetto e il realismo del testo cifrato possono anche determinare l'usabilità dei risultati. Gli obiettivi delle applicazioni e delle tabelle di database (utilità di caricamento) possono richiedere che il formato dei dati non solo rispetti le strutture predefinite, ma continui a funzionare in query o altri contesti operativi a valle.
In altre parole, se sono necessari dati mascherati che siano belli e/o funzionali, non optare per la redazione completa, la randomizzazione, l'hashing o la crittografia diretta (che amplia e offusca i risultati). Potresti riuscire a farla franca con piccoli ritocchi come l'invecchiamento e la manipolazione delle sottostringhe, ma considera l'impatto di queste scelte sugli altri criteri decisionali...
Reversibilità (Riidentificazione)
È necessario ripristinare i dati originali? La risposta potrebbe dipendere dal fatto che tu stia lasciando da soli i dati di origine, come faresti con il mascheramento dinamico dei dati, o quando stai scrivendo i dati mascherati su nuovi obiettivi. In questi casi la risposta è no.
Se la risposta è no, potresti comunque aver bisogno di realismo, nel qual caso la pseudonimizzazione non reversibile potrebbe essere la soluzione migliore. Se è no e l'aspetto non ha importanza, vai con la redazione del personaggio. E se nessuno dei due è vero, considera l'eliminazione definitiva della colonna di origine dalla destinazione.
Quando la risposta è sì, vengono indicate le funzioni di mascheramento dei dati IRI come crittografia, pseudonimizzazione o tokenizzazione reversibile, codifica o re-ID ASCII (bit scrambling). In casi d'uso più avanzati, potrebbe essere necessaria anche l'inversione differenziale; vale a dire, quando diversi destinatari dello stesso target sono autorizzati a vedere cose diverse nello stesso set di dati. In questi casi, è possibile distribuire chiavi di crittografia private, script di processi di rivelazione specifici dell'utente o persino applicazioni personalizzate.
Unicità (coerenza)
È necessario sostituire sempre lo stesso valore originale con lo stesso valore di sostituzione, ma diverso? I dati verranno uniti o raggruppati in base ai valori di sostituzione? In tal caso, l'algoritmo di sostituzione scelto deve produrre risultati unici e ripetibili al fine di preservare l'integrità referenziale nonostante il mascheramento che si è verificato.
Ciò può essere ottenuto tramite la crittografia quando lo stesso algoritmo e la stessa passphrase (chiave) vengono utilizzati contro lo stesso testo in chiaro. La classificazione dei dati e le procedure guidate di protezione tra tabelle nell'IDE di IRI Workbench per FieldShield, Voracity, ecc. facilitano ciò attraverso l'applicazione tra tabelle (o più globali) della regola di mascheratura abbinata. In questo modo, lo stesso valore di testo in chiaro ottiene sempre lo stesso risultato di testo cifrato indipendentemente dalla sua posizione.
La pseudonimizzazione è più complicata qui, tuttavia, a causa della carenza di nomi sostitutivi univoci, nomi originali duplicati e modifiche ( inserimenti, aggiornamenti o eliminazioni) ai valori originali nelle tabelle o nei file di origine. IRI ha affrontato il problema della pseudonimizzazione coerente tra tabelle incrociate in questo esempio di flusso di lavoro Voracity.
Forza (Sicurezza)
Uno sguardo agli algoritmi all'interno di ciascuna funzione può aiutarti a determinare la loro "crackability" relativa e valutarla rispetto ad altre considerazioni sul testo cifrato come l'aspetto e la velocità. Ad esempio, la funzione AES256 di IRI è più potente dell'opzione AES128, SHA2 è più potente di SHA1 e tutte sono più potenti delle funzioni di codifica/decodifica base64 e de-ID/re-ID ASCII.
Per definizione, le funzioni reversibili sono in genere più deboli di quelle che non possono essere invertite. Ad esempio, il metodo di pseudonimizzazione irreversibile (set di ricerca straniera) di IRI è più sicuro del suo metodo di pseudonimizzazione reversibile (set originale criptato). Detto questo, l'algoritmo di crittografia AES-256 può essere molto difficile da decifrare anche quando la chiave è stata persa.
Una sicurezza ancora più forte è ovviamente l'omissione, seguita dall'offuscamento dei caratteri (redazione), che sono irreversibili. Ma lo svantaggio è la mancanza di usabilità. Nel contesto HIPAA Safe Harbor, la rimozione degli identificatori chiave è conforme. Se è necessario utilizzare una qualsiasi parte dei dati di origine per analisi, ricerca, marketing o dimostrazione, tuttavia, sarà necessaria una funzione di mascheramento e un esperto per determinare (e certificare) che le proprie tecniche hanno un basso livello statistico probabilità di reidentificazione.
Mentre siamo in tema di anonimizzazione HIPAA, ricorda che potrebbero esserci anche rischi associati ai cosiddetti quasi identificatori (come il codice postale e l'età). Questi valori possono essere utilizzati insieme ad altri set di dati per stabilire un percorso di reidentificazione e, quindi, in molti casi vale anche la pena mascherarli; il se e il come sono soggetti a queste stesse considerazioni.
Calcolo (prestazioni)
Una delle cose belle dell'approccio di mascheramento dei dati, anche quando sono coinvolti algoritmi di crittografia ad alta intensità di calcolo, è che il suo sovraccarico relativo alla crittografia a pennello ampio (di un'intera rete, database, file/sistema, unità disco) è molto più basso. Solo gli elementi di dati (valori di colonna) designati per la protezione devono essere inseriti, elaborati e restituiti dalla funzione di mascheramento.
In generale, più complesso (e forte) è l'algoritmo, più tempo sarà necessario per l'applicazione. Le velocità di mascheramento dei dati dipenderanno anche dal numero di funzioni applicate, dal numero di colonne e righe DB, dal numero di vincoli di ricerca da rispettare nel processo (per l'integrità referenziale), dalla larghezza di banda della rete, dalla RAM, dall'I/O, dai processi simultanei e presto.
Il seguente grafico non scientifico scompone la maggior parte degli attributi sopra descritti per un comodo riferimento, per alcune (ma non tutte!) categorie funzionali di mascheramento dei dati IRI supportate e solo in termini generalmente relativi. Inutile dire che IRI declina ogni garanzia di idoneità o responsabilità per questo grafico!
Funzioni di mascheramento dei dati IRI (in FieldShield e Voracity)
Indipendentemente dal fatto che utilizzi le funzioni di mascheramento dei dati IRI integrate o le funzioni personalizzate che definisci, l'idea è di applicarle in base alle tue regole aziendali a righe o colonne specifiche e/o tra tabelle. E lo farai attraverso regole di mascheramento dei dati che puoi definire, archiviare e riutilizzare. È anche possibile (e preferibile) applicare queste funzioni di mascheramento dei dati rispetto ai dati classificati automaticamente come regole per comodità e coerenza. E puoi sfruttarne molti in applicazioni di mascheramento dei dati dinamici tramite una chiamata API.
Gli utenti FieldShield (o Voracity) possono creare, eseguire e gestire i tuoi lavori di mascheramento dei dati in una GUI gratuita all'avanguardia, basata su Eclipse.™ Oppure possono modificare ed eseguire script 4GL compatibili e autodocumentanti che definiscono i loro dati di origine/destinazione e funzioni di mascheramento ed eseguire quegli script sulla riga di comando.
Per ulteriori informazioni, visita https://www.iri.com/solutions/data-masking o contatta il tuo rappresentante IRI.
