MongoDB
 sql >> база данни >  >> NoSQL >> MongoDB

Маскиране на PII в MongoDB, Cassandra и Elasticsearch с DarkShield:…

Тази статия демонстрира използването на IRI DarkShield за идентифициране и коригиране (маскиране) на личната информация (PII) и други чувствителни данни в бази данни MongoDB, Cassandra и Elasticsearch. Въпреки че тези стъпки се фокусират основно върху намирането и екранирането на данни в колекциите на MongoDB, същите стъпки могат да се използват и за данни в таблици на Cassandra. Вижте и тази статия в Elasticsearch.

Имайте предвид, че тази статия представлява четвъртия метод, който IRI поддържа за маскиране на данни в MongoDB, и втория метод за Cassandra. Тези предишни  и все още поддържани методи разчитат на откриване и деидентификация на структурирани данни чрез IRI FieldShield, докато методът DarkShield поддържа текстови данни в структурирани или неструктурирани колекции. Въпреки че DarkShield и FieldShield са самостоятелни IRI продукти за маскиране на данни, и двата са включени в платформата за управление на данни IRI Voracity.

Най-новият подход използва някои елементи от Класификация на данните , интегрирана парадигма за каталогизиране на данни за дефиниране на методите за търсене, използвани за намиране на PII независимо от източника на данните. Въпреки че тази статия предоставя кратко въведение в класификацията на данни по време на Стъпка 1, може да ви е полезно да прочетете как класификацията на данни се вписва в нашия унифициран подход за провеждане на търсения. За повече информация относно класификацията на данните в предния край на IRI Workbench за DarkShield et al, моля, прочетете тази статия, преди да продължите.

Идентифицирането и отстраняването на PII с помощта на IRI DarkShield включва 4 общи стъпки:

(По избор) Стъпка – Регистрирайте своя източник(и) на данни

В тази (по избор) стъпка се регистрират източници на данни за база данни Mongo, ключово пространство Cassandra или клъстер Elasticsearch. Това позволява източниците на данни да бъдат повторно използвани. В резултат на това тази стъпка е незадължителна, ако желаният източник на данни вече съществува в системния регистър или ако планирате да ги дефинирате от съветника.

Стъпка 1 – Определете параметри за търсене

Тук се избират всички аспекти на търсенето. Първо, изходна и целева колекция/таблица се настройват въз основа на връзката с данни, посочена в системния регистър или създадена в съветника. След това можете да посочите критериите за търсене и коригиране за вашите данни, като използвате Search Matchers, видовете информация, която да търсите и как тази информация трябва да бъде коригирана. Резултатът от тази стъпка е .търсене файл.

Стъпка 2 – Извършете търсене

Търсене може да се стартира от .search файл. Резултатът е .darkdata файл, отбелязващ всички идентифицирани лични данни.

Стъпка 3 – Ремедиация (маскиране)

Възстановяването може да се извърши от .darkdata файл. Всички идентифицирани лични данни ще бъдат коригирани по начина, посочен при създаването на търсене.

(По избор) Стъпка – Регистрирайте вашите източници на данни

Като предпоставка ще трябва да регистрирате връзките към вашите онлайн източници на данни (и цели) в регистъра на URL връзките, който се намира в Предпочитания> IRI> Регистър на URL връзки диалогов прозорец в IRI Workbench.

Всички URL връзки, включително низове за URI връзка за MongoDB, Cassandra и Elasticsearch могат да бъдат запазени. Това позволява URL адресите, идентификационните данни за удостоверяване и всякакви допълнителни параметри да бъдат запазени и съхранени от IRI Workbench за бъдеща употреба.

Стъпка 1 – Определете параметри за търсене (Създайте .Search файл)

В IRI Workbench IDE за DarkShield изберете Нова задача за откриване на база данни от менюто DarkShield. Изберете папка на проекта и въведете име за заданието:

Указване на източник и цел

Всички URL адреси на Mongo, Cassandra или Elasticsearch, които са били създадени и запазени в регистъра, могат да бъдат достъпни от URI падащо меню както за селектора Източник, така и за Цел. Ще трябва да се въведе и името на съответната колекция MongoDB, таблица Cassandra или индекс на Elasticsearch:

Нов URI може да бъде създаден и чрез натискане на Нов бутон. Това ще отвори диалоговия прозорец Подробности за URL връзката. Въведете име за връзката, изберете желаната схема, въведете хоста и въведете базата данни. Ако няма порт, ще се приеме портът по подразбиране за схемата.

Потребителско име и парола също могат да бъдат предоставени, ако базата данни изисква оторизация. Всички нови URL връзки ще бъдат запазени в регистъра на URL връзките и могат да бъдат използвани повторно като цел.

След като източникът е посочен, можете да продължите към следващата страница, за да изберете или създадете целеви URI. Схемата на целевия URI ще бъде ограничена до избрания URI на източника, така че източник на MongoDB може да бъде изпратен само до друга цел на MongoDB и по подобен начин за Cassandra или Elasticsearch.

Когато се изпълнява задача за маскиране, всички редове в източника ще бъдат добавени към целта и всички редове със съвпадащи ключове ще бъдат презаписани. За Cassandra се уверете, че схемата на целевата таблица е съвместима с данните от таблицата източник.

Добавяне на съвпадения за търсене

След като са посочени както източник, така и цел, можете да отидете на следващата страница, за да добавите съвпадения за търсене. Изберете местоположение на библиотеката, съдържащо всякакви библиотеки с шаблони или правила, които искате да използвате, и щракнете върху Добавяне за да добавите нов Search Matcher.

KeyNameMatcher

Първият Search Matcher, който ще създадем, ще бъде използван за съпоставяне на цялата стойност, съответстваща на всеки ключ „име“, намиращ се в произволно вложени json структури и ще приложи алгоритъм за запазване на формат за криптиране, за да го маскира. Можем да постигнем това, като създадем JSON филтър за пътя „$..name“. Повече информация за JSON  пътищата можете да намерите тук.

Тъй като колекциите на MongoDB, таблиците на Cassandra и индексите на Elasticsearch се анализират от DarkShield като json документи, филтърът може да се приложи и към двете, за да се маскира всяка стойност, съответстваща на всеки ключ „име“.

За да съответстваме на съдържанието на филтрираните данни, трябва да създадем нов Клас данни . Класът данни представлява PII и свързаните съвпадения, използвани за идентифицирането му. Тези съвпадения могат да включват всяка комбинация от:

  • Модели за регулярни изрази
  • Задаване на справки в файловия речник
  • Модели за разпознаване на наименувани обекти
  • Ограничаващи кутии за съвпадение (само за изображения)
  • Разпознаване на лица (само изображения)

Можете да дефинирате класове данни в съветника или като отворите Класове и групи данни страница в Предпочитания на IRI . Класовете данни, дефинирани в предпочитанията, могат да се използват както в FieldShield, така и в DarkShield за други източници на данни, включително структурирани и неструктурирани данни.

Можем да създадем свързано ВСИЧКО Клас на данни за този съпоставител, който ще съвпада с цялото съдържание на стойността, тъй като сме доста сигурни, че всичко, което ще намерим в стойностите, са имена. Можете да използвате набор за търсене на файлове, съдържащи речник от имена, ако не сте сигурни в съдържанието на вашите клавиши „име“ или ако искате да маскирате само подмножество от имена.

За Име на правило полето на KeyNameMatcher, можем да изберем съществуващо правило за данни от местоположението на библиотеката, което сме избрали, или да създадем ново правило, което използва шифроване с запазване на формат (FPE), например:

За да създадете FPE правило, щракнете върху Създаване до Име на правилото поле, изберете Функции за шифроване или декриптиране от съветника за правила за данни, който се показва:

Посочете подходяща парола, която да служи като ключ за криптиране/декриптиране, която може да бъде изричен низ, променлива на средата или име на защитен файл, съдържащ този низ.

EmailsMatcher

След като приключим с предишния диалог и създадем нашия нов KeyNameMatcher, можем да добавим друг Search Matcher за имейл адреси. Просто щракнете върху Добавяне за да създадете друг Search Matcher, който да добавите към списъка.

IRI Workbench идва с предварително зареден EMAIL Клас данни, който може да бъде избран чрез щракване върху Преглед до Име на клас данни поле и изберете EMAIL от падащото меню.

За правилото за данни можете да изберете правилото за FPE, което сте създали за предишния Search Matcher, като щракнете върху Преглед до Име на правилото поле или създайте ново с една от наличните множество функции за маскиране. Създадох проста функция за редактиране на данни, която замества целия имейл със звездички.

Вашият Search Matcher вече може да бъде добавен към списъка, като щракнете върху OK.

NamesMatcher

Нашият последен Search Matcher ще се използва за намиране на имена в свободно течащ текст. За това ще използваме Разпознаване на именуван обект (NER) за намиране на имена, използвайки контекста на изречението. За да започнем, трябва да щракнем върху Добавяне за да създадете нов Search Matcher и да създадете нов клас данни, наречен NAMES_NER:

За да създадете NAMES_NER Data Class, първо трябва да изтеглим модела за намиране на имена на хора, en-ner-person.bin , от хранилището на OpenNLP sourceforge. След това щракнете върху Добавяне за да добавите нов съвпадение, изберете NER модел от падащото меню. Щракнете върху Преглед и навигирайте до местоположението на изтегления модел; например:

След като създадете новия клас данни, щракнете върху OK и изберете FPE Data Rule, което сте дефинирали по-рано, за да завършите създаването на Search Matcher:

Имайте предвид, че нашият NamesMatcher и KeyNameMatcher може да има припокриващи се съвпадения. Ако това се случи, DarkShield избира най-дългото налично съвпадение и премахва всички други припокриващи се съвпадения. По този начин не е нужно да се притеснявате, че DarkShield ще приложи маскираща функция върху вече маскирани стойности.

След като добавите всички желани съвпадения, щракнете върху завършване, за да генерирате .search файл.

Генерираното .search файл може да бъде проверен, за да се покажат подробностите за търсене. Това включва изходния и целевия URI и информация за всички съвпадения.

Стъпка 2 – Извършете търсене (Създайте .Darkdata Файл)

Завършване на заданието за откриване на тъмни данни съветникът генерира ново .търсене конфигурационен файл. Този файл съдържа опциите, които избрахме, включително източника и целта на нашите данни, както и Search Matchers, които ще бъдат използвани за маркиране на PII за откриване, доставка, изтриване и/или де-идентификация.

За да започнете търсенето, щракнете с десния бутон върху .search файл, изберете Изпълни като, и изберете или IRI Търсене на работа или IRI Търсене и коригиране на работа .

Търсене ще извършва само търсене, докато Търси и отстранява също така ще се опита да маскира (или изтрие) всички идентифицирани данни. И двете ще генерират .darkdata файл, идентифициращ всякакви данни, които представляват интерес.

Източникът, който използвах, беше попълнен с произволно генерирани стойности, така че няма нищо лошо в споделянето на генерираните .darkdata файл тук. Въпреки това, когато обработват действително чувствителна информация, потребителите трябва да уверят, че .darkdata файлът не е изложен и е безопасно архивиран или изтрит след завършване на отстраняването, за да се предотврати изтичане на PII. IRI ще добави опция за карантина за съхранение на .darkdata файл и съответните артефакти за търсене на безопасно място; свържете се с [email protected] за подробности относно тази планирана функция.

Стъпка 3 – Поправяне (маскиране)

Отново, маскирането или изтриването на данни може да се извърши по време на операциите за търсене чрез Търсене и отстраняване опция в съветника за Dark Data Discovery. Въпреки това, ако искате просто да прегледате идентифицираната информация и да я поправите по-късно, стартирайте заданията за маскиране от .darkdata файл, създаден в търсенето (стъпка 2) по следния начин: 

Щракнете с десния бутон върху .darkdata файл, задръжте мишката върху Изпълни като и щракнете върху IRI Remediate Job . След като заданието се изпълни, коригираните данни трябва да се появят в целевата база данни.

Ето пример, показващ преди и след малка колекция от база данни MongoDB с помощта на командния ред на Workbench за достъп до локалния сървър Mongo:

ЗАКЛЮЧЕНИЕ

В тази статия демонстрирахме нова способност на IRI за достъп до неструктурирани данни в бази данни Mongo, ключови пространства Cassandra и клъстери Elasticsearch, използвайки няколко Search Matchers в IRI DarkShield. Можете да проверите генерираните .darkdata модел, за да видите резултатите от търсенето, които са намерени и коригирани, и проверете базата си данни, за да видите актуализираните таблици/колекции.

  1. Ако PII е вграден в двоични обекти във вашите колекции MongoDB, Cassandra, Elasticsearch, можем да помогнем за автоматизирането на тяхното извличане в самостоятелни файлове за операции за търсене/маска на DarkShield и повторното им импортиране.
  2. Интегрираната среда на IRI Workbench IDE, изградена върху Eclipse™,  включва всички FieldShield, DarkShield и свързаните с тях маскиране на данни — и по-широки възможности за обработка на данни — в платформата IRI Voracity.
  3. Регистърът на URL връзката се използва за конфигуриране и запазване на базирани на URL източници на данни, използвани в операциите за търсене/маска на DarkShield и CoSort/SortCL (Voracity) ETL операции; напр. HDFS, Kafka, S3 buckets, MongoDB, S/FTP. Този регистър е подобен, но не е идентичен с регистъра на Data Connection в IRI Workbench за източници на релационни бази данни, където ODBC DSN се свързват към съответните профили на JDBC връзка в полза на съветниците за работа, които използват и двете връзки.
  4. Подборът за търсене е асоциация между клас данни , който се използва за дефиниране на метода за търсене за намиране и класифициране на PII и Правило за данни който ще бъде приложен към всеки екземпляр от класа данни, намерен в колекцията или таблицата. В допълнение, Search Matchers ви позволяват да дефинирате филтри, които могат да се използват за намаляване на обхвата на търсенето. Това е особено полезно в колекциите на Mongo, таблиците на Cassandra и индексите на Elasticsearch, тъй като името на ключа може да е показателно за PII, който се съхранява в съответната стойност.

  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Ефективно пейджинг в MongoDB с помощта на mgo

  2. MongoDB $round

  3. Уникални документи, използващи множество стойности в Mongoose Schema

  4. Налагане на контроли за достъп, базирани на роли, с ClusterControl

  5. Добавете ново поле към всеки документ в колекция MongoDB