Hvilken datamaskeringsfunktion skal jeg bruge?

Afidentifikation er ikke en enkelt teknik, men en samling af tilgange, algoritmer og værktøjer, der kan anvendes på forskellige slags data med forskellige effektivitetsniveauer. Generelt forbedres beskyttelsen af ​​privatlivets fred, efterhånden som der anvendes mere aggressive afidentifikationsteknikker, men der er mindre nytte tilbage i det resulterende datasæt.

-Af-identifikation af personlige oplysninger, NISTIR 8053

Statisk datamaskering (SDM) er den brancheanerkendte betegnelse for disse forskellige måder at afidentificere dataelementer i hvile. Elementerne er typisk databasekolonne- eller fladfilfeltværdier, der anses for at være følsomme; i sundhedssektoren omtales de som nøgleidentifikatorer. Specifikt i fare er personligt identificerbare oplysninger (PII), beskyttede sundhedsoplysninger (PHI), primære kontonumre (PAN), forretningshemmeligheder eller andre følsomme værdier.

Det "startpunkt" datacentrerede sikkerhedsprodukt IRI FieldShield - eller IRI CoSort-produktet og IRI Voracity-platformen, der inkluderer de samme muligheder - giver flere dataopdagelse og SDM-funktioner til flere datakilder. Tilgængelige maskeringsfunktioner pr. felt/kolonne omfatter:

1. multiple, NSA Suite B og FIPS-kompatible krypterings- (og dekrypterings-) algoritmer, inklusive formatbevarende kryptering
2. SHA-1 og SHA-2 hashing
3. ASCII de-ID (bit scrambling)
4. binær kodning og afkodning
5. datasløring eller bucketing (anonymisering)
6. tilfældig generering eller udvælgelse
7. redaktion (karakter sløring)
8. reversibel og ikke-reversibel pseudonymisering
9. brugerdefineret udtryk (beregning / shuffle) logik
10. betinget/delvis værdifiltrering eller fjernelse (udeladelse)
11. erstatning med tilpasset værdi
12. byteskift og strengfunktioner
13. tokenisering (til PCI)

Du kan også "rulle din egen" eksterne datamaskeringsfunktion. Dette giver dig mulighed for at kalde en specialskrevet rutine på feltniveau under kørsel i stedet for en indbygget.

Spørgsmålet står tilbage, hvilken maskeringsfunktion skal jeg bruge (på hvert emne)? Det afhænger af din virksomheds behov og regler samt gældende lovgivning om databeskyttelse. På et teknisk niveau betyder det normalt, at man skal beslutte, hvordan den resulterende chiffertekst (maskerede data) skal fremstå, om den skal være reversibel eller unik, hvor sikker den er, og muligvis hvilken slags computerressourcer og tid der er til rådighed for processen . Lad os se nærmere på disse fælles beslutningskriterier:

Udseende (realisme)

Skal de nyligt maskerede data ligne de originale data mere eller mindre? Hvad med dens størrelse og format? Pseudonymisering og formatbevarende kryptering er de to mest almindelige måder at 

bevare udseendet og fornemmelsen af ​​henholdsvis egennavne og alfacifrede konto- eller telefonnumre. Men understrengmaskering (a/k/a delvis feltredaktion, f.eks. XXX-XX-1234) kan være helt fint for ting som SSN'er. Tænk på vedholdenheden og visningen af ​​data til analyser osv.

Relateret til dette kan chiffertekstens udseende og realisme også bestemme resultaternes anvendelighed. Mål for applikations- og databasetabel (load utility) kan kræve, at formatet af dataene ikke kun overholder foruddefinerede strukturer, men fortsætter med at arbejde i forespørgsler eller andre operationelle sammenhænge downstream.

Med andre ord, hvis maskerede data, der er smukke og/eller funktionelle data, er påkrævet, skal du ikke gå efter fuld redaktion, randomisering, hashing eller lige kryptering (hvilket udvider og slører resultaterne). Du kan muligvis slippe af sted med mindre justeringer som aldring og understrengsmanipulation, men overvej virkningen af ​​disse valg på dine andre beslutningskriterier …

Reversibilitet (genidentifikation)

Har du brug for de originale data gendannet? Svaret på det kan afhænge af, om du lader kildedataene være alene, som du ville gøre i dynamisk datamaskering, eller når du skriver de maskerede data ud til nye mål. I de tilfælde er svaret nej.

Hvis svaret er nej, har du muligvis stadig brug for realisme, i hvilke tilfælde ikke-reversibel pseudonymisering kan være dit bedste bud. Hvis det er nej, og udseendet ikke betyder noget, så gå med karakterredigering. Og hvis ingen af ​​dem er sande, kan du overveje direkte sletning af kildekolonnen fra målet.

Når svaret er ja, er IRI-datamaskeringsfunktioner som kryptering, reversibel pseudonymisering eller tokenisering, kodning eller ASCII re-ID (bit scrambling) angivet. I mere avancerede brugstilfælde kan du også få brug for differentiel reversering; dvs., når forskellige modtagere af det samme mål har tilladelse til at se forskellige ting i det samme datasæt. I sådanne tilfælde kan private krypteringsnøgler, brugerspecifikke afsløringsjobscripts eller endda tilpassede applikationer implementeres.

Unikhed (konsistens)

Skal den samme oprindelige værdi altid erstattes af den samme, men forskellige, erstatningsværdi? Vil dataene blive samlet på eller grupperet efter erstatningsværdierne? Hvis det er tilfældet, skal den valgte erstatningsalgoritme give resultater, der er unikke og gentagelige for at bevare referenceintegriteten på trods af den maskering, der er opstået.

Dette kan opnås gennem kryptering, når den samme algoritme og adgangssætning (nøgle) bruges mod den samme almindelige tekst. Dataklassifikations- og krydstabelbeskyttelsesguiderne i IRI Workbench IDE for FieldShield, Voracity osv. letter dette gennem krydstabel- (eller mere global) anvendelse af den matchede maskeringsregel. På denne måde får den samme klartekstværdi altid det samme chiffertekstresultat uanset dens placering.

Pseudonymisering er dog vanskeligere her på grund af mangel på unikke erstatningsnavne, duplikerede originalnavne og ændringer ( indsætter, opdaterer eller sletter) til de originale værdier i kildetabeller eller filer. IRI behandlede spørgsmålet om konsekvent krydstabel-pseudonymisering i dette Voracity-workflow-eksempel.

Styrke (sikkerhed)

Et kig på algoritmerne inde i hver funktion kan hjælpe dig med at bestemme deres relative "knækbarhed" og vurdere det i forhold til andre chiffertekstovervejelser som udseende og hastighed. For eksempel er IRI's AES256-funktion stærkere end AES128-muligheden, SHA2 er stærkere end SHA1, og alle er stærkere end base64 encode/decode og ASCII de-ID/re-ID-funktioner.

Per definition er reversible funktioner typisk svagere end dem, der ikke kan vendes. For eksempel er IRIs irreversible (udenlandske opslagssæt) pseudonymiseringsmetode mere sikker end dens reversible (forvrænget originalsæt) pseudonymiseringsmetode. Når det er sagt, kan AES-256-krypteringsalgoritmen også være meget svær at knække, når nøglen er gået tabt.

Endnu stærkere sikkerhed er naturligvis udeladelse, efterfulgt af tegnobfuskation (redaktion), som er irreversible. Men ulempen er manglende brugervenlighed. I HIPAA safe harbor sammenhæng er fjernelse af nøgleidentifikatorer i overensstemmelse. Hvis du dog skal bruge en del af kildedataene til analyse, forskning, markedsføring eller demonstration, skal du i stedet bruge en maskeringsfunktion og en ekspert til at bestemme (og attestere), at din(e) teknik(ker) har en lav statistisk sandsynlighed for genidentifikation.

Mens vi er på emnet HIPAA afidentifikation, husk, at der også kan være risiko forbundet med såkaldte kvasi-identifikatorer (som postnummer og alder). Disse værdier kan bruges sammen med andre datasæt til at etablere et re-identifikationsspor og er derfor også værd at maskere i mange tilfælde; om og hvordan er underlagt de samme overvejelser.

Beregning (Ydeevne)

En af de gode ting ved datamaskeringstilgangen - selv når computerintensive krypteringsalgoritmer er involveret - er, at dens overhead i forhold til bred-børstekryptering (af et helt netværk, database, fil/system, diskdrev) er langt lavere. Det er kun de dataelementer (kolonneværdier), som du angiver til beskyttelse, der skal indsættes i, behandles af og returneres fra maskeringsfunktionen.

Generelt, jo mere kompleks (og stærkere) algoritmen er, jo længere tid vil det tage at anvende. Datamaskeringshastigheder vil også afhænge af antallet af anvendte funktioner, antallet af DB-kolonner og rækker, antallet af opslagsbegrænsninger, der skal respekteres i processen (for referenceintegritet), netværksbåndbredde, RAM, I/O, samtidige processer og snart.

Det følgende ikke-videnskabelige skema nedbryder de fleste af de attributter, der er beskrevet ovenfor for praktisk reference, for nogle (men ikke alle!) understøttede IRI-datamaskeringsfunktionelle kategorier, og generelt kun i relative termer. Det er overflødigt at sige, at IRI fraskriver sig enhver garanti for egnethed eller ansvar for dette diagram!

IRI-datamaskeringsfunktioner (i FieldShield &Voracity)

Uanset om du bruger indbyggede IRI-datamaskeringsfunktioner eller brugerdefinerede funktioner, som du definerer, er ideen at anvende dem baseret på dine forretningsregler på specifikke rækker eller kolonner og/eller på tværs af tabeller. Og du vil gøre det gennem datamaskeringsregler, du kan definere, gemme og genbruge. Det er også muligt (og at foretrække) at anvende disse datamaskeringsfunktioner mod automatisk klassificerede data som regler for nemheds skyld og sammenhæng. Og du kan udnytte flere af dem i dynamiske datamaskeringsapplikationer via et API-kald.

FieldShield (eller Voracity)-brugere kan oprette, køre og administrere dine datamaskeringsjob i en gratis avanceret GUI, bygget på Eclipse.™ Eller de kan redigere og køre kompatible, selvdokumenterende 4GL-scripts, der definerer deres kilde-/måldata og maskeringsfunktioner, og kør disse scripts på kommandolinjen.

For flere oplysninger, se https://www.iri.com/solutions/data-masking eller kontakt din IRI-repræsentant.