Denne artikel demonstrerer brugen af IRI DarkShield til at identificere og afhjælpe (maske) personligt identificerbare oplysninger (PII) og andre følsomme data i MongoDB, Cassandra og Elasticsearch-databaser. Selvom disse trin hovedsageligt fokuserer på at finde og afskærme data i MongoDB-samlinger, kan de samme trin også bruges til data i Cassandra-tabeller. Se også denne artikel om Elasticsearch.
Bemærk, at denne artikel repræsenterer den fjerde metode, IRI understøtter til maskering af data i MongoDB, og den anden metode for Cassandra. Disse tidligere og stadig understøttede metoder er afhængige af struktureret dataopdagelse og afidentifikation via IRI FieldShield, mens DarkShield-metoden understøtter tekstdata i enten strukturerede eller ustrukturerede samlinger. Selvom DarkShield og FieldShield er selvstændige IRI-datamaskeringsprodukter, er begge inkluderet i IRI Voracity-dataadministrationsplatformen.
Den seneste tilgang bruger nogle elementer i Dataklassificering , et integreret datakatalogiseringsparadigme til at definere de søgemetoder, der bruges til at finde PII uafhængigt af datakilden. Selvom denne artikel giver en lille introduktion til dataklassificering under trin 1, kan du finde det nyttigt at læse op på, hvordan dataklassificering passer ind i vores fælles tilgang til udførelse af søgninger. For mere information om dataklassificering i IRI Workbench-frontenden til DarkShield et al., læs venligst denne artikel, før du fortsætter.
Identifikation og udbedring af PII ved hjælp af IRI DarkShield involverer 4 generelle trin:
(Valgfrit) Trin – Registrer din(e) datakilde(r)
I dette (valgfrie) trin registreres datakilder for en Mongo-database, Cassandra-nøgleområde eller Elasticsearch-klynge. Dette gør det muligt at genbruge datakilder. Som følge heraf er dette trin valgfrit, hvis den ønskede datakilde allerede findes i registreringsdatabasen, eller hvis du planlægger at definere dem fra guiden.
Trin 1 – Angiv søgeparametre
Her er alle aspekter af en søgning valgt. Først opsættes en kilde- og målsamling/tabel baseret på den dataforbindelse, der er angivet i registreringsdatabasen eller oprettet i guiden. Derefter kan du angive søge- og afhjælpningskriterierne for dine data ved hjælp af Search Matchers, hvilke typer oplysninger du skal søge efter, og hvordan disse oplysninger skal afhjælpes. Resultatet af dette trin er en .søgning fil.
Trin 2 – Udfør en søgning
En søgning kan udføres fra en .search fil. Resultatet er en .darkdata fil med annotering af identificeret PII.
Trin 3 – Afhjælpning (maskering)
Udbedring kan udføres fra en .darkdata fil. Enhver identificeret PII vil blive udbedret på den måde, der er angivet under oprettelse af søgning.
(Valgfrit) Trin – Registrer dine datakilder
Som et forudsætningstrin skal du registrere forbindelserne til dine onlinedatakilder (og -mål) i URL-forbindelsesregistret, som er placeret i Preferences> IRI> URL Connection Registry dialog i IRI Workbench.
Alle URL-forbindelser, inklusive URI-forbindelsesstrenge til MongoDB, Cassandra og Elasticsearch kan gemmes. Dette giver mulighed for, at URL'er, godkendelsesoplysninger og eventuelle yderligere parametre kan gemmes og gemmes af IRI Workbench til fremtidig brug.
Trin 1 – Angiv søgeparametre (Opret .Search-fil)
I IRI Workbench IDE for DarkShield skal du vælge New Database Discovery Job fra DarkShield-menuen. Vælg en projektmappe, og indtast et navn til jobbet:
Angivelse af en kilde og et mål
Alle Mongo-, Cassandra- eller Elasticsearch-URL'er, der tidligere blev oprettet og gemt i registreringsdatabasen, kan tilgås fra URI'en dropdown for både Kilde- og Målvælgerne. Navnet på den tilsvarende MongoDB-samling, Cassandra-tabel eller Elasticsearch-indeks skal også indtastes:
En ny URI kan også oprettes ved at trykke på Ny knap. Dette åbner dialogboksen URL-forbindelsesdetaljer. Indtast et navn til forbindelsen, vælg det ønskede skema, indtast værten, og indtast databasen. Hvis der ikke er nogen port, antages standardporten for ordningen.
Et brugernavn og en adgangskode kan også leveres, hvis databasen kræver autorisation. Alle nye URL-forbindelser vil blive gemt i URL-forbindelsesregistret og kan genbruges som et mål.
Når en kilde er angivet, kan du fortsætte til næste side for at vælge eller oprette en mål-URI. Skemaet for mål-URI'en vil være begrænset til den valgte kilde-URI, så en MongoDB-kilde kan kun sendes til et andet MongoDB-mål, og tilsvarende for Cassandra eller Elasticsearch.
Når et maskeringsjob køres, vil alle rækker i kilden blive tilføjet til målet, og alle rækker med matchende nøgler vil blive overskrevet. For Cassandra skal du sikre dig, at måltabelskemaet er kompatibelt med data fra kildetabellen.
Tilføjelse af søgematchere
Når både en kilde og et mål er angivet, kan du gå til næste side for at tilføje søgematchere. Vælg en biblioteksplacering, der indeholder eventuelle mønstre eller regelbiblioteker, som du ønsker at bruge, og klik på Tilføj for at tilføje en ny søgematcher.
KeyNameMatcher
Den første Search Matcher, som vi vil oprette, vil blive brugt til at matche hele værdien, der svarer til enhver "navn"-nøgle placeret i vilkårligt indlejrede json-strukturer og anvende en formatbevarende krypteringsalgoritme til at maskere den. Vi kan opnå dette ved at oprette et JSON-stifilter "$..name". Du kan finde flere oplysninger om JSON-stier her.
Da MongoDB-samlinger, Cassandra-tabeller og Elasticsearch-indekser parses af DarkShield som json-dokumenter, kan filteret anvendes på begge for at maskere enhver værdi, der svarer til enhver "navn"-nøgle.
For at matche indholdet af de filtrerede data skal vi oprette en ny dataklasse . En dataklasse repræsenterer PII og de tilhørende matchere, der bruges til at identificere den. Disse matchere kan omfatte enhver kombination af:
- Regulære udtryksmønstre
- Indstil filordbogsopslag
- Modeller til navngivne enhedsgenkendelse
- Bounding Box Matchers (kun billeder)
- Ansigtsgenkendelse (kun billeder)
Du kan definere dataklasser i guiden eller ved at åbne Dataklasser og -grupper siden i IRI-indstillinger . Dataklasserne, der er defineret i præferencerne, kan bruges i både FieldShield og DarkShield til andre datakilder, inklusive strukturerede og ustrukturerede data.
Vi kan oprette et tilknyttet ALT Dataklasse for denne matcher, som vil matche hele indholdet af værdien, da vi er rimelig sikre på, at det eneste, vi finder i værdierne, er navne. Du kan bruge sæt filopslag, der indeholder en ordbog med navne, hvis du er usikker på indholdet af dine "navne"-taster, eller hvis du kun ønsker at maskere et undersæt af navne.
For Regelnavnet feltet i KeyNameMatcher, kan vi vælge en eksisterende dataregel fra den biblioteksplacering, vi har valgt, eller oprette en ny regel, der bruger Format Preserving Encryption (FPE), for eksempel:
For at oprette en FPE-regel skal du klikke på Opret ud for Regelnavn skal du vælge Krypterings- eller Dekrypteringsfunktioner fra Data Rule Wizard, der vises:
Angiv en passende adgangssætning, der skal fungere som din krypterings-/dekrypteringsnøgle, som kan være en eksplicit streng, miljøvariabel eller navnet på en sikret fil, der indeholder denne streng.
EmailsMatcher
Efter at have afsluttet den forrige dialog og oprettet vores nye KeyNameMatcher, kan vi tilføje endnu en Search Matcher til e-mailadresser. Du skal blot klikke på Tilføj for at oprette en anden Search Matcher for at føje til listen.
IRI Workbench leveres forudindlæst med en EMAIL Dataklasse, som kan vælges ved at klikke på Gennemse ud for Data Class Name felt og vælg EMAIL fra rullemenuen.
For datareglen kan du vælge den FPE-regel, du har oprettet for den tidligere søgematcher, ved at klikke på Gennemse ud for Regelnavn felt, eller opret et nyt med en af de mange tilgængelige maskeringsfunktioner. Jeg lavede en simpel Data Redaction funktion, som erstatter hele e-mailen med stjerner.
Din Search Matcher kan nu føjes til listen ved at klikke på OK.
NamesMatcher
Vores sidste søgematcher vil blive brugt til at finde navne i fritflydende tekst. Til dette vil vi bruge Navnet enhedsgenkendelse (NER) at finde navne ved hjælp af sætningens kontekst. For at begynde skal vi klikke på Tilføj for at oprette en ny Search Matcher og oprette en ny dataklasse kaldet NAMES_NER:
For at oprette en NAMES_NER Dataklasse, skal vi først downloade Person Name Finder-modellen, en-ner-person.bin , fra OpenNLP sourceforge-lageret. Klik derefter på Tilføj for at tilføje en ny matcher, vælg NER Model fra rullemenuen. Klik på Gennemse og naviger til placeringen af den downloadede model; for eksempel:
Når du har oprettet den nye dataklasse, skal du klikke på OK og vælg den FPE-dataregel, du definerede tidligere, for at afslutte oprettelsen af Search Matcher:
Bemærk, at vores NamesMatcher og KeyNameMatcher kan have overlappende kampe. Hvis dette sker, vælger DarkShield det længste tilgængelige match og fjerner alle andre overlappende kampe. På den måde behøver du ikke bekymre dig om, at DarkShield anvender en maskeringsfunktion på allerede maskerede værdier.
Når du har tilføjet alle de ønskede matchere, skal du klikke på Afslut for at generere en .search fil.
Den genererede .search fil kan inspiceres for at vise detaljerne om en søgning. Dette inkluderer kilde- og mål-URI'er og oplysninger om alle matcherne.
Trin 2 – Udfør en søgning (Opret en .Darkdata Fil)
Fuldførelse af Dark Data Discovery Job guiden genererer en ny .søgning konfigurationsfil. Denne fil indeholder de valgmuligheder, vi valgte, inklusive kilden og målet for vores data, og de søgematchere, der vil blive brugt til at tagge PII til opdagelse, levering, sletning og/eller afidentifikation.
For at starte søgningen skal du højreklikke på .search fil, vælg Kør som, og vælg enten IRI Search Job eller IRI Search and Remediation Job .
Søg vil kun udføre en søgning, mens Søg og afhjælp vil også forsøge at maskere (eller slette) alle identificerede data. Begge vil generere en .darkdata fil, der identificerer eventuelle data af interesse.
Kilden, jeg brugte, var udfyldt med tilfældigt genererede værdier, så der er ingen skade i at dele de genererede .darkdata fil her. Men når de håndterer faktisk følsomme oplysninger, bør brugere sikre .darkdata filen er ikke afsløret og er sikkert arkiveret eller slettet efter afslutningen af udbedringen for at forhindre PII-lækage. IRI tilføjer en karantæneindstilling til lagring af .darkdata fil og tilsvarende søgeartefakter på et sikkert sted; kontakt [email protected] for detaljer om denne planlagte funktion.
Trin 3 – Udbedring (maskering)
Igen kan datamaskering eller sletning udføres under søgeoperationer via Søg og ret mulighed i Dark Data Discovery-guiden. Men hvis du blot ønsker at undersøge identificerede oplysninger og udbedre dem senere, skal du køre maskeringsopgaverne fra .darkdata fil produceret i søgningen (trin 2) på denne måde:
Højreklik på .darkdata fil, hold musen over Kør som , og klik på IRI Remediate Job . Når jobbet kører, bør de korrigerede data vises i måldatabasen.
Her er et eksempel, der viser en før og efter af en lille MongoDB-databasesamling ved hjælp af Workbench-kommandoprompten for at få adgang til den lokale Mongo-server:
Konklusion
I denne artikel demonstrerede vi ny IRI-evne til at få adgang til ustrukturerede data i Mongo-databaser, Cassandra-nøglerum og Elasticsearch-klynger ved hjælp af adskillige Search Matchers i IRI DarkShield. Du kan tjekke de genererede .darkdata model for at se de søgeresultater, der blev fundet og rettet, og tjek din database for at se de opdaterede tabeller/samlinger.
- Hvis PII er indlejret i binære objekter i dine MongoDB-, Cassandra-, Elasticsearch-samlinger, kan vi hjælpe med at automatisere deres udtræk til selvstændige filer til DarkShield-søgning/maske-operationer og deres genimport.
- IRI Workbench IDE, bygget på Eclipse™, fronter al FieldShield, DarkShield og relaterede datamaskering – og bredere datahåndteringsmuligheder – i IRI Voracity-platformen.
- URL-forbindelsesregistret bruges til at konfigurere og gemme URL-baserede datakilder, der bruges i DarkShield-søgning/maske og CoSort/SortCL (Voracity) ETL-operationer; f.eks. HDFS, Kafka, S3 buckets, MongoDB, S/FTP. Dette register ligner, men ikke identisk, med Data Connection-registret i IRI Workbench for relationelle databasekilder, hvor ODBC DSN'er er koblet til tilsvarende JDBC-forbindelsesprofiler til gavn for jobguider, der udnytter begge forbindelser.
- En søgematcher er en forbindelse mellem en Dataklasse , som bruges til at definere søgemetoden til at finde og klassificere PII, og en Data Regel som vil blive anvendt på enhver forekomst af dataklassen, der findes i samlingen eller tabellen. Derudover giver Search Matchers dig mulighed for at definere filtre, som kan bruges til at reducere omfanget af søgningen. Dette er især nyttigt i Mongo-samlinger, Cassandra-tabeller og Elasticsearch-indekser, fordi nøglenavnet kan være indikativt for PII, som er gemt i den tilsvarende værdi.