Volgens Simson L. Garfinkel van het Information Technology Laboratory van de NIST Information Access Division,
De-identificatie is geen enkele techniek, maar een verzameling benaderingen, algoritmen en hulpmiddelen die kunnen worden toegepast op verschillende soorten gegevens met verschillende niveaus van effectiviteit. Over het algemeen verbetert de privacybescherming naarmate er agressievere de-identificatietechnieken worden gebruikt, maar er blijft minder bruikbaarheid over in de resulterende dataset.
-De-identificatie van persoonlijke informatie, NISTIR 8053
Statische gegevensmaskering (SDM) is de door de industrie erkende term voor deze verschillende manieren om gegevenselementen in rust te de-identificeren. De elementen zijn doorgaans databasekolom- of platte veldwaarden die als gevoelig worden beschouwd; in de gezondheidszorg worden ze key identifiers genoemd. Specifiek risico lopen persoonlijk identificeerbare informatie (PII), beschermde gezondheidsinformatie (PHI), primaire rekeningnummers (PAN), handelsgeheimen of andere gevoelige waarden.
Het "startpunt" datacentrische beveiligingsproduct IRI FieldShield — of het IRI CoSort-product en IRI Voracity-platform met dezelfde mogelijkheden — bieden meerdere gegevensontdekkings- en SDM-functies voor meerdere gegevensbronnen. Beschikbare maskeerfuncties per veld/kolom zijn:
- meerdere, NSA Suite B- en FIPS-compatibele coderings- (en decoderings)algoritmen, waaronder formaatbehoud encryptie
- SHA-1 en SHA-2 hashing
- ASCII de-ID (bit scrambling)
- binaire codering en decodering
- vervaging of bucketing van gegevens (anonimisering)
- willekeurige generatie of selectie
- redactie (verduistering van tekens)
- omkeerbare en niet-omkeerbare pseudonimisering
- aangepaste expressie (berekening/shuffle) logica
- voorwaardelijke / gedeeltelijke waardefiltering of verwijdering (omissie)
- vervanging aangepaste waarde
- byteverschuiving en tekenreeksfuncties
- tokenisatie (voor PCI)
U kunt ook uw eigen externe gegevensmaskeringsfunctie "rollen". Hierdoor kunt u tijdens runtime een op maat geschreven routine op veldniveau aanroepen in plaats van een ingebouwde.
De vraag blijft, welke maskeerfunctie moet ik gebruiken (op elk item)? Dat hangt af van uw zakelijke behoeften en regels, evenals van de toepasselijke wetgeving(en) op het gebied van gegevensprivacy. Op technisch niveau betekent dat meestal beslissen hoe de resulterende cijfertekst (gemaskeerde gegevens) moet verschijnen, of deze omkeerbaar of uniek moet zijn, hoe veilig deze is en mogelijk, wat voor soort computerbronnen en tijd beschikbaar zijn voor het proces . Laten we deze algemene beslissingscriteria eens nader bekijken:
Uiterlijk (realisme)
Moeten de nieuw gemaskeerde gegevens er min of meer uitzien als de originele gegevens? Hoe zit het met de grootte en het formaat? Pseudonimisering en versleuteling met behoud van de indeling zijn de twee meest voorkomende manieren om
behoud de look en feel van respectievelijk eigennamen en alfacijferige account- of telefoonnummers. Maar substring-masking (a/k/een gedeeltelijke veldredactie, bijv. XXX-XX-1234) kan prima zijn voor zaken als SSN's. Denk aan de persistentie en weergave van de gegevens voor analyses, enz.
Gerelateerd hieraan kunnen uiterlijk en realisme van de cijfertekst ook de bruikbaarheid van de resultaten bepalen. Toepassings- en databasetabeldoelen (laadhulpprogramma) vereisen mogelijk dat het formaat van de gegevens niet alleen voldoet aan vooraf gedefinieerde structuren, maar verder werkt in query's of andere operationele contexten stroomafwaarts.
Met andere woorden, als gemaskeerde gegevens die mooie en/of functionele gegevens zijn vereist zijn, ga dan niet voor volledige redactie, randomisatie, hashing of directe versleuteling (wat de resultaten verbreedt en vertroebelt). U kunt misschien wegkomen met kleinere aanpassingen zoals veroudering en manipulatie van substrings, maar overweeg de impact van deze keuzes op uw andere beslissingscriteria ...
Omkeerbaarheid (heridentificatie)
Wilt u de originele gegevens herstellen? Het antwoord daarop kan afhangen van het feit of u de brongegevens alleen laat, zoals bij dynamische gegevensmaskering, of wanneer u de gemaskeerde gegevens naar nieuwe doelen schrijft. In die gevallen is het antwoord nee.
Als het antwoord nee is, heb je misschien nog steeds realisme nodig, in welke gevallen niet-omkeerbare pseudonimisering de beste keuze is. Als het nee is en het uiterlijk er niet toe doet, ga dan met karakterredactie. En als geen van beide waar is, overweeg dan om de bronkolom uit het doel te verwijderen.
Als het antwoord ja is, worden IRI-gegevensmaskeringsfuncties zoals codering, omkeerbare pseudonimisering of tokenisering, codering of ASCII-re-ID (bitscrambling) aangegeven. In meer geavanceerde gebruiksgevallen heeft u mogelijk ook differentiële omkering nodig; d.w.z. wanneer verschillende ontvangers van hetzelfde doelwit geautoriseerd zijn om verschillende dingen in dezelfde dataset te zien. In dergelijke gevallen kunnen privé-coderingssleutels, gebruikersspecifieke taakscripts voor openbaringen of zelfs aangepaste toepassingen worden geïmplementeerd.
Uniek (consistentie)
Moet dezelfde oorspronkelijke waarde altijd worden vervangen door dezelfde, maar andere, vervangingswaarde? Worden de gegevens samengevoegd op of gegroepeerd op de vervangingswaarden? Als dat het geval is, moet het gekozen vervangingsalgoritme resultaten opleveren die uniek en herhaalbaar zijn om de referentiële integriteit te behouden ondanks de opgetreden maskering.
Dit kan worden bereikt door middel van codering wanneer hetzelfde algoritme en dezelfde wachtwoordzin (sleutel) worden gebruikt voor dezelfde leesbare tekst. De wizards voor gegevensclassificatie en kruistabelbeveiliging in de IRI Workbench IDE voor FieldShield, Voracity, enz. vergemakkelijken dit door middel van kruistabel (of meer algemene) toepassing van de overeenkomende maskeringsregel. Op deze manier krijgt dezelfde waarde in leesbare tekst altijd hetzelfde resultaat in cijfertekst, ongeacht de locatie.
Pseudonimisering is hier echter lastiger vanwege een tekort aan unieke vervangende namen, dubbele originele namen en wijzigingen ( invoegingen, updates of verwijderingen) naar de oorspronkelijke waarden in brontabellen of bestanden. IRI heeft het probleem van consistente kruistabel-pseudonimisering aangepakt in dit Voracity-workflowvoorbeeld.
Kracht (Beveiliging)
Een blik op de algoritmen in elke functie kan u helpen hun relatieve "kraakbaarheid" te bepalen en dat te beoordelen tegen de andere cijfertekstoverwegingen zoals uiterlijk en snelheid. De AES256-functie van IRI is bijvoorbeeld sterker dan de AES128-optie, SHA2 is sterker dan SHA1 en ze zijn allemaal sterker dan base64-codering/decodering en ASCII de-ID/re-ID-functies.
Per definitie zijn omkeerbare functies doorgaans zwakker dan functies die niet kunnen worden teruggedraaid. De onomkeerbare (buitenlandse opzoekset) pseudonimiseringsmethode van IRI is bijvoorbeeld veiliger dan de omkeerbare (versleutelde originele set) pseudonimiseringsmethode. Dat gezegd hebbende, kan het AES-256-coderingsalgoritme ook heel moeilijk te kraken zijn als de sleutel verloren is gegaan.
Een nog sterkere beveiliging is natuurlijk weglating, gevolgd door verduistering van tekens (redactie), die onomkeerbaar zijn. Maar het nadeel is het gebrek aan bruikbaarheid. In de HIPAA-veilige havencontext voldoet het verwijderen van sleutel-ID's. Als u echter een deel van de brongegevens moet gebruiken voor analyse, onderzoek, marketing of demonstratie, hebt u in plaats daarvan een maskeerfunctie nodig en een expert om te bepalen (en te certificeren) dat uw techniek(en) een lage statistische waarschijnlijkheid van heridentificatie.
Nu we het toch hebben over de-identificatie van HIPAA, onthoud dat er ook risico's kunnen zijn verbonden aan zogenaamde quasi-identificatiemiddelen (zoals postcode en leeftijd). Die waarden kunnen in combinatie met andere datasets worden gebruikt om een her-identificatiespoor vast te stellen, en zijn dus in veel gevallen ook de moeite waard om te maskeren; of en hoe zijn onderworpen aan dezelfde overwegingen.
Berekening (prestaties)
Een van de leuke dingen van de aanpak van gegevensmaskering - zelfs als er rekenintensieve versleutelingsalgoritmen bij betrokken zijn - is dat de overhead ten opzichte van breedbandversleuteling (van een volledig netwerk, database, bestand/systeem, schijfstation) veel lager is. Alleen die gegevenselementen (kolomwaarden) die u aanwijst voor bescherming, hoeven te worden opgenomen in, verwerkt door en geretourneerd door de maskeringsfunctie.
Over het algemeen geldt:hoe complexer (en sterker) het algoritme, hoe langer het duurt om het toe te passen. De snelheid van gegevensmaskering hangt ook af van het aantal toegepaste functies, het aantal DB-kolommen en rijen, het aantal opzoekbeperkingen dat in het proces moet worden gerespecteerd (voor referentiële integriteit), netwerkbandbreedte, RAM, I/O, gelijktijdige processen en spoedig.
De volgende niet-wetenschappelijke tabel geeft een overzicht van de meeste van de hierboven beschreven attributen voor gemakkelijke referentie, voor sommige (maar niet alle!) ondersteunde functionele categorieën voor IRI-gegevensmaskering, en in het algemeen alleen in relatieve termen. Onnodig te zeggen dat IRI elke garantie van geschiktheid of aansprakelijkheid voor deze kaart afwijst!
IRI-gegevensmaskeringsfuncties (in FieldShield &Voracity)
Of u nu ingebouwde IRI-gegevensmaskeringsfuncties gebruikt of aangepaste functies die u definieert, het idee is om ze op basis van uw bedrijfsregels toe te passen op specifieke rijen of kolommen en/of over tabellen heen. En u doet dit door middel van regels voor gegevensmaskering die u kunt definiëren, opslaan en hergebruiken. Het is ook mogelijk (en verdient de voorkeur) om deze gegevensmaskeringsfuncties toe te passen op automatisch geclassificeerde gegevens als regels voor gemak en consistentie. En u kunt er meerdere gebruiken in toepassingen voor dynamische gegevensmaskering via een API-aanroep.
Gebruikers van FieldShield (of Voracity) kunnen uw gegevensmaskeringstaken maken, uitvoeren en beheren in een gratis geavanceerde GUI, gebouwd op Eclipse.™ Of ze kunnen compatibele, zelfdocumenterende 4GL-scripts bewerken en uitvoeren die hun bron-/doelgegevens en maskeerfuncties, en voer die scripts uit op de opdrachtregel.
Ga voor meer informatie naar https://www.iri.com/solutions/data-masking of neem contact op met uw IRI-vertegenwoordiger.