"Nya flerbordsskyddsjobb ..." guiden i IRI Workbench som beskrivs i den här artikeln är ett av sätten som användare av IRI FieldShield-produkt (eller IRI Voracity-plattform) automatiskt kan maskera personligt identifierbar information (PII) i databaskolumner som är en del av en främmande nyckelrelation och därmed bevara referensintegriteten mellan borden. Detta säkerställer att posterna förblir länkade även efter att de har avidentifierats.
Observera att sedan 2018 har en nyare och mer robust metod för att uppnå samma resultat publicerats i vår artikel om klassificering, upptäckt och maskering av flera databastabeller här, och visas i Youtube-videorna 1, 2, 3, 5 och 7 här.
Men i denna ursprungliga och fortfarande populära guide bevarar användare referensintegritet genom att definiera maskeringsregler på fältnivå som automatiskt och konsekvent tillämpas på kolumner med samma namn. Vilken som helst av de 14 eller så kategorier av datamaskeringsfunktioner tillgängliga för FieldShield-användare – inklusive kryptering, pseudonymisering och redaktion – kan tillämpas på grundval av sådana regler.
Den här guiden är mest lämplig för användare som maskerar och mappar flera tabeller i ett schema som inte alla innehåller PII. Till exempel skulle IRI rekommendera den här guiden om du har 50 tabeller och behöver flytta alla till en lägre miljö men bara har 20 av tabellerna som innehåller PII att maskera konsekvent (de andra 30 har ingen PII).
Det här exemplet använder bara tre Oracle-tabeller – Avdelningar, Anställda och Job_History – för att visa hur den här guiden fungerar. När borden ursprungligen designades användes den anställdes personnummer för deras ID. Detta skapar en säkerhetsrisk när du kör några rapporter som visar ID-fältet.
Ovanstående E-R-diagram för dessa tabeller och SQL-frågan och dess resultat nedan visas alla i olika IRI Workbench-GUI för FieldShield-vyer. Se den här artikeln om:ERD-skapande i IRI Workbench. Frågan sammanfogade information om anställda, chefer och avdelningar men visar värden för personnummer (SSN) i kolumnerna Employee SID och Manager SID. Se den här artikeln om kodning och körning av SQL-jobb i IRI Workbench.
Använda FieldShield Multi Table Protection Job guiden, kan dessa fält krypteras (eller på annat sätt avidentifieras) så att de verkliga SSN:erna maskeras i tabellerna och efterföljande frågor. Referensintegriteten behålls eftersom samma kryptering tillämpas på alla tabeller med en regel.
På inställningssidan för guiden väljs ODBC som laddare. De tre ovannämnda tabellerna väljs på sidan Dataextraktion. Nästa sida är sidan Regler för fältändringar. På den här sidan kan reglerna som ska tillämpas på alla utvalda extraherade tabeller utformas.
Klicka på Skapa kommer att öppna sidan Fältregelmatchning. Det är här som matcharens uppgifter skrivs in. Börja med att ange ett matchningsnamn.
Efter att ha klickat på Skapa bredvid Regelnamn , visas sidan för val av guiden Nytt skyddsfältregel. Välj Krypterings- eller dekrypteringsfunktioner . Detta val säkerställer att samma skyddsalgoritm gäller för all data, vilket säkerställer referensintegritet.
Nästa sida är där typen av kryptering väljs. I det här fallet enc_fp_aes256_ascii är använd. Denna formatbevarande krypteringsalgoritm använder ASCII-teckenuppsättningen för att ersätta den verkliga datan. Den används i denna demonstration så att krypteringen märks i utdata. Ett mer realistiskt val skulle normalt vara alfanum version, som också skulle bevara det faktiska utseendet på SSN:er (9 nummer i detta fall).
Även om det här exemplet använder en inbäddad lösenfras, kan en lösenordsfil också användas för krypteringsnyckeln, liksom en miljövariabel.
Klicka på Slutför kommer att skriva in denna regel i matcharen. Därefter måste själva matcharen skapas. Klicka på Lägg till i Matchningar sektion. Detta öppnar sidan Fältregelmatchningsdetaljer. Här kan antingen ett mönster eller en dataklass användas. Se artikeln Applying Field Rules Using Classification för mer information om det andra alternativet.
I det här exemplet Pattern väljs och .*SID skrivs in i detaljerna. Detta regex kommer att matcha alla kolumnnamn som slutar på SID.
Matcharen avslutar med detaljerna som visas nedan. Test knappen kan användas för att testa matcharna för att se till att de matchar alla avsedda kolumner. Flera matchningsdetaljer kan matas in och OCH/ELLER-logik kan användas för att producera finkorniga matchare. Till exempel finns det en extra kolumn som heter VP_SSN . Samma matchare ovan skulle kunna användas med en annan matchare med mönstret .*SSN och operatorn AND att matcha på denna extra kolumn men med samma regel.
Klicka på OK återgår här till sidan Regler där varje regelmatchare visas. Olika matchare kan användas för olika fält så att endast ett omvandlingspass krävs även om reglerna skulle maskera olika kolumner på olika sätt.
Klicka på Nästa kommer att visa sidan för dataladdningsstadiet. Här är utgångstabellen och alternativen valda. I det här exemplet är samma tabeller som inmatningstabellerna valda. Dessutom ändras utdataläget till Skapa att trunkera tabellerna innan de laddas så att unika nycklar inte kränks.
Efter att ha klickat på Slutför , skapas en mapp med flera skript som kommer att köras med den medföljande batchfilen.
För att se hur regeln kommer att förvandla fältet och ge oss en chans att manuellt ändra saker på SCOTT_EMPLOYEES.fcl skriptet kan granskas i Workbench-redigeraren. I utgången visas både EMPLOYEE_SID och MANAGER_SID visa den använda krypteringsalgoritmen.
Efter att ha kört batchfilen visar samma SQL-fråga samma sammanfogade resultat, men med Employee_SID och Manager_SID nu krypterad. Vidare bevaras referensintegriteten. De ursprungliga relationerna mellan anställd och chef bevaras och ID:n för chefen på rad 2 och medarbetaren på rad 26 är desamma.
Det här exemplet visar hur en krypteringsregel kan användas över flera kolumner i flera tabeller med bibehållen referensintegritet. Alla regler som skapas under jobbguiderna sparas i ett regelbibliotek. Detta gör att de kan återanvändas och till och med delas med kollegor så att samma resultat säkerställs på samma data.
Om du har några frågor om FieldShield-datamaskeringsregler, eller behöver hjälp med att använda någon av dess dataupptäcknings- eller maskeringsguider, kontakta din IRI-representant.