„Ново задание за защита на няколко таблици…“ съветникът в IRI Workbench описан в тази статия е един от начините, по които потребителите на продукта IRI FieldShield (или платформата IRI Voracity) могат автоматично да маскират личната информация (PII) в колони на базата данни, които са част от връзка с външен ключ, и по този начин да запазят референтната цялост между масите. Това гарантира, че записите остават свързани дори след като бъдат де-идентифицирани.
Обърнете внимание, че от 2018 г. по-нов и по-стабилен метод за постигане на същия резултат е публикуван в нашата статия за класификацията, откриването и маскирането на множество таблици от база данни тук, и се демонстрира във видеоклипове 1, 2, 3, 5 и 7 в Youtube тук.
Но в този оригинален и все още популярен съветник потребителите запазват референтната цялост, като дефинират правила за маскиране на ниво поле, които автоматично и последователно се прилагат към колони с подобни имена. Всяка от около 14-те категории функции за маскиране на данни достъпни за потребителите на FieldShield – включително криптиране, псевдонимизиране и редактиране – може да се прилага въз основа на такива правила.
Този съветник е най-подходящ за потребители, маскиращи и съпоставящи множество таблици в схема, които не всички съдържат PII. Например, IRI би препоръчал този съветник, ако имате 50 таблици и трябва да преместите всички в по-ниска среда, но имате само 20 от таблиците, съдържащи PII, за да се маскират последователно (останалите 30 нямат PII).
Този пример използва само три таблици на Oracle — Departments, Employees и Job_History — за да покаже как работи този съветник. Когато таблиците са били първоначално проектирани, социалноосигурителният номер на служителя е бил използван за техния идентификационен номер. Това създава риск за сигурността при стартиране на отчети, показващи полето ID.
Горната E-R диаграма за тези таблици и SQL заявката и резултатите от нея по-долу са показани в различни IRI Workbench GUI за FieldShield изгледи. Вижте тази статия относно:Създаване на ERD в IRI Workbench. Заявката обединява информация за служители, мениджъри и отдели, но разкрива стойностите на социалноосигурителния номер (SSN) в колоните SID на служителите и SID на мениджъра. Вижте тази статия за кодиране и изпълнение на SQL задания в IRI Workbench.
Използване на FieldShield Задание за защита на няколко таблици съветника, тези полета могат да бъдат криптирани (или по друг начин де-идентифицирани), така че истинските SSN да бъдат маскирани в таблиците и последващите заявки. Референтната цялост се запазва, тъй като едно и също криптиране се прилага към всички таблици с едно правило.
На страницата за настройка на съветника ODBC е избран като зареждане. Трите гореспоменати таблици са избрани на страницата за извличане на данни. Следващата страница е страницата Правила за промяна на полето. На тази страница могат да бъдат проектирани правилата, които да се прилагат към всички избрани извлечени таблици.
Щракнете върху Създаване ще отвори страницата за съвпадение на правилата на полето. Тук се въвеждат подробностите за съвпадението. Започнете с въвеждане на име за съвпадение.
След като кликнете върху Създаване до Име на правило , се показва страницата за избор на съветника за ново поле за защита. Изберете Функции за шифроване или декриптиране . Този избор гарантира, че един и същ алгоритъм за защита се прилага за всички данни, осигурявайки референтната цялост.
Следващата страница е мястото, където се избира типът на криптиране. В този случай, enc_fp_aes256_ascii се използва. Този алгоритъм за криптиране, запазващ формат, използва набора от ASCII знаци, за да замени реалните данни. Използва се в тази демонстрация, така че криптирането да е забележимо в изхода. По-реалистичен избор обикновено би бил алфана версия, която също ще запази действителния вид на SSN (9 номера в този случай).
Въпреки че този пример използва вградена парола, файл с парола може да се използва и за ключа за криптиране, както и променлива на средата.
Кликване върху Край ще въведе това правило в съвпадението. След това трябва да се създаде самият съвпадение. Кликнете върху Добавяне в Matchers раздел. Това ще отвори страницата с подробности за съвпадението на правилата на полето. Тук може да се използва или шаблон, или клас данни. Вижте статията Прилагане на полеви правила чрез класификация за подробности относно втората опция.
В този пример Шаблон е избран и .*SID е въведен в подробностите. Този регулярен израз ще съвпада с всички имена на колони, завършващи на SID.
Съвпадението завършва с подробностите, показани по-долу. Тестът бутонът може да се използва за тестване на съпоставителите, за да се уверите, че съвпадат с всички предвидени колони. Могат да бъдат въведени множество детайли за съвпадение и логиката И/ИЛИ може да се използва за създаване на фини съвпадения. Например, има допълнителна колона с име VP_SSN . Същият съпоставител по-горе може да се използва с друг съпоставител с модел .*SSN и оператора И за съвпадение в тази допълнителна колона, но със същото правило.
Щракнете върху OK тук се връща към страницата с правила, където се показва всяко съпоставяне на правила. Различни съвпадения могат да се използват за различни полета, така че е необходимо само едно преминаване на трансформация дори ако правилата трябва да маскират различни колони по различни начини.
Щракнете върху Напред ще покаже страницата Етап на зареждане на данни. Тук се избират изходната таблица и опциите. В този пример са избрани същите таблици като входните таблици. Освен това режимът на извеждане се променя на Създаване за да съкратите таблиците преди зареждане, така че да не се нарушават уникалните ключове.
След като кликнете върху Край , се създава папка с множество скриптове, които ще се изпълняват с включения пакетен файл.
За да видите как правилото ще трансформира полето и да ни даде шанс да променим нещата ръчно, SCOTT_EMPLOYEES.fcl скриптът може да бъде прегледан в редактора на Workbench. В изхода и двата EMPLOYEE_SID и MANAGER_SID покажете приложения алгоритъм за криптиране.
След изпълнение на пакетния файл, същата SQL заявка показва същите обединени резултати, но с Employee_SID и Manager_SID сега криптиран. Освен това е запазена референтната цялост. Оригиналните взаимоотношения служител-мениджър се запазват и идентификаторите на мениджъра на ред 2 и служителя на ред 26 са еднакви.
Този пример демонстрира как едно правило за криптиране може да се използва в множество колони в множество таблици, като се запазва референтната цялост. Всички правила, създадени по време на съветниците за задания, се записват в библиотека с правила. Това им позволява да бъдат използвани повторно и дори споделяни с колеги за да се осигурят същите резултати за едни и същи данни.
Ако имате въпроси относно правилата за маскиране на данни на FieldShield или се нуждаете от помощ при използването на някой от неговите съветници за откриване на данни или маскиране, свържете се с вашия представител на IRI.
