"Ny Multi Table Protection Job ..." guiden i IRI Workbench beskrevet i denne artikel er en af måderne, hvorpå IRI FieldShield-produkt (eller IRI Voracity-platform) brugere automatisk kan maskere personligt identificerbar information (PII) i databasekolonner, der er en del af et fremmednøgleforhold, og dermed bevare referenceintegritet mellem bordene. Dette sikrer, at posterne forbliver forbundet, selv efter de er afidentificeret.
Bemærk, at siden 2018 er en nyere og mere robust metode til at opnå det samme resultat offentliggjort i vores artikel om klassificering, opdagelse og maskering af flere databasetabeller her, og demonstreres i Youtube-video 1, 2, 3, 5 og 7 her.
Men i denne originale og stadig populære guide bevarer brugere referentiel integritet ved at definere maskeringsregler på feltniveau, der automatisk og konsekvent anvendes på samme navngivne kolonner. Enhver af de omkring 14 kategorier af datamaskeringsfunktioner tilgængelige for FieldShield-brugere – inklusive kryptering, pseudonymisering og redaktion – kan anvendes på grundlag af sådanne regler.
Denne guide er bedst egnet til brugere, der maskerer og kortlægger flere tabeller i et skema, som ikke alle indeholder PII. For eksempel vil IRI anbefale denne guide, hvis du har 50 tabeller og skal flytte dem alle til et lavere miljø, men kun har 20 af tabellerne, der indeholder PII, der skal maskeres konsekvent (de andre 30 har ingen PII).
Dette eksempel bruger kun tre Oracle-tabeller - afdelinger, medarbejdere og jobhistorik - for at vise, hvordan denne guide fungerer. Da bordene oprindeligt blev designet, blev medarbejderens personnummer brugt til deres ID. Dette skaber en sikkerhedsrisiko, når der køres rapporter, der viser ID-feltet.
Ovenstående E-R-diagram for disse tabeller og SQL-forespørgslen og dens resultater nedenfor er alle vist i forskellige IRI Workbench-GUI for FieldShield-visninger. Se denne artikel om:ERD-oprettelse i IRI Workbench. Forespørgslen forenede oplysninger om medarbejdere, ledere og afdelinger, men afslører SSN-værdier (Social Security Number) i kolonnerne Employee SID og Manager SID. Se denne artikel om kodning og kørsel af SQL-job i IRI Workbench.
Brug af FieldShield Multi Table Protection Job guiden, kan disse felter krypteres (eller på anden måde de-identificeres), så de rigtige SSN'er maskeres i tabellerne og efterfølgende forespørgsler. Referenceintegriteten bevares, fordi den samme kryptering anvendes på alle tabeller ved hjælp af én regel.
På opsætningssiden for guiden er ODBC valgt som indlæser. De tre førnævnte tabeller er valgt på siden Dataudtræk. Den næste side er siden Feltændringsregler. På denne side kan reglerne, der skal anvendes på alle de valgte udtrukne tabeller, designes.
Ved at klikke på Opret vil åbne siden Field Rule Matcher. Det er her detaljerne om matcheren indtastes. Start med at indtaste et matchernavn.
Efter at have klikket på Opret ud for Regelnavn , vises siden Valg af guiden Ny beskyttelsesfeltregel. Vælg Krypterings- eller dekrypteringsfunktioner . Dette valg sikrer, at den samme beskyttelsesalgoritme gælder for alle data, hvilket sikrer referentiel integritet.
Den næste side er, hvor typen af kryptering er valgt. I dette tilfælde enc_fp_aes256_ascii anvendes. Denne formatbevarende krypteringsalgoritme bruger ASCII-tegnsættet til at erstatte de rigtige data. Det bruges i denne demonstration, så krypteringen er mærkbar i outputtet. Et mere realistisk valg ville normalt være alfanum version, som også ville bevare det faktiske udseende af SSN'er (9 numre i dette tilfælde).
Selvom dette eksempel bruger en indlejret adgangssætning, kan en adgangskodefil også bruges til krypteringsnøglen, ligesom en miljøvariabel kan.
Klik på Udfør vil indtaste denne regel i matcheren. Dernæst skal selve matcheren oprettes. Klik på Tilføj i Matchere afsnit. Dette åbner siden Feltregelmatcherdetaljer. Her kan enten et mønster eller en dataklasse bruges. Se artiklen Anvendelse af feltregler ved hjælp af klassificering for detaljer om den anden mulighed.
I dette eksempel Mønster er valgt og .*SID indtastes i detaljerne. Dette regex vil matche alle kolonnenavne, der ender på SID.
Matcheren slutter med detaljerne vist nedenfor. Test knappen kan bruges til at teste matcherne for at sikre, at de matcher alle de tilsigtede kolonner. Flere matcher detaljer kan indtastes, og OG/ELLER logik kan bruges til at producere finkornede matchere. For eksempel er der en ekstra kolonne med navnet VP_SSN . Den samme matcher ovenfor kan bruges med en anden matcher med et mønster på .*SSN og operatøren AND at matche på denne ekstra kolonne, men med samme regel.
Klik på OK her vender tilbage til siden Regler, hvor hver regelmatcher vises. Forskellige matchere kan bruges til forskellige felter, så det kun er nødvendigt med ét transformationspas, selvom reglerne skulle maskere forskellige kolonner på forskellige måder.
Ved at klikke på Næste vil vise siden Data Loading Stage. Her er outputtabellen og mulighederne valgt. I dette eksempel er de samme tabeller som inputtabellerne valgt. Derudover ændres outputtilstand til Opret at afkorte tabellerne før indlæsning, så unikke nøgler ikke krænkes.
Efter at have klikket på Udfør , oprettes en mappe med flere scripts, der vil blive udført med den medfølgende batchfil.
For at se, hvordan reglen vil forvandle feltet og give os en chance for at ændre tingene manuelt, SCOTT_EMPLOYEES.fcl script kan gennemgås i Workbench-editoren. I outputtet er både EMPLOYEE_SID og MANAGER_SID vis den anvendte krypteringsalgoritme.
Efter udførelse af batchfilen viser den samme SQL-forespørgsel de samme sammenføjede resultater, men med Employee_SID og Manager_SID nu krypteret. Endvidere bevares referentiel integritet. De oprindelige medarbejder-leder-relationer bevares, og ID'erne for lederen på linje 2 og medarbejderen på linje 26 er de samme.
Dette eksempel viser, hvordan én krypteringsregel kan bruges på tværs af flere kolonner i flere tabeller og samtidig bevare referenceintegriteten. Alle regler, der oprettes under jobguiderne, gemmes i et regelbibliotek. Dette giver dem mulighed for at blive genbrugt og endda delt med kolleger så de samme resultater sikres på de samme data.
Hvis du har spørgsmål om FieldShield-datamaskeringsregler eller har brug for hjælp til at bruge nogen af dets dataopdagelses- eller maskeringsguider, skal du kontakte din IRI-repræsentant.