Според Симсън Л. Гарфинкел от лабораторията за информационни технологии на отдела за достъп до информация на NIST,
Деидентификацията не е отделна техника, а съвкупност от подходи, алгоритми и инструменти, които могат да бъдат приложени към различни видове данни с различни нива на ефективност. Като цяло защитата на поверителността се подобрява, тъй като се използват по-агресивни техники за де-идентификация, но остава по-малко полезност в получения набор от данни.
- Де-идентификация на лична информация, NISTIR 8053
Статичното маскиране на данни (SDM) е признатият в индустрията термин за тези различни средства за деидентификация на елементи от данни в покой. Елементите обикновено са стойности на колона на базата данни или поле с плосък файл, които се считат за чувствителни; в здравната индустрия те се наричат ключови идентификатори. Конкретно застрашени са личната информация (PII), защитена здравна информация (PHI), номера на първични сметки (PAN), търговски тайни или други чувствителни стойности.
Продуктът за сигурност, ориентиран към данни „начална точка“ IRI FieldShield — или продуктът IRI CoSort и платформата IRI Voracity, които включват едни и същи възможности — предоставят множество функции за откриване на данни и SDM за множество източници на данни. Наличните функции за маскиране на поле/колона включват:
- множество, NSA Suite B и FIPS-съвместими алгоритми за криптиране (и декриптиране), включително запазване на формат криптиране
- SHA-1 и SHA-2 хеширане
- ASCII de-ID (разкодиране на битове)
- двоично кодиране и декодиране
- замъгляване на данни или групиране (анонимизиране)
- случайно генериране или избор
- редакция (закриване на знаци)
- обратима и необратима псевдонимизация
- логика на персонализиран израз (изчисление/разбъркване)
- филтриране или премахване (пропускане) с условна/частична стойност.
- замяна на персонализирана стойност
- функции за изместване на байтове и низове
- токенизация (за PCI)
Можете също да „навиете своя собствена“ функция за маскиране на външни данни. Това ви позволява да извикате персонализирана рутина на ниво поле по време на изпълнение вместо вградена.
Остава въпросът коя функция за маскиране да използвам (за всеки елемент)? Това зависи от вашите бизнес нужди и правила, както и от приложимите закони за поверителност на данните. На техническо ниво това обикновено означава да се реши как трябва да се появи полученият шифротекст (маскирани данни), дали трябва да бъде обратим или уникален, колко е сигурен и евентуално какъв вид изчислителни ресурси и време са налични за процеса . Нека разгледаме подробно тези общи критерии за вземане на решения:
Външен вид (реализъм)
Трябва ли новите маскирани данни да изглеждат повече или по-малко като оригиналните данни? Какво ще кажете за неговия размер и формат? Псевдонимизацията и криптирането, запазващо формата, са двата най-често срещани начина за
запазват облика и усещането на собствени съществителни и буквено-цифрени акаунти или телефонни номера, съответно. Но маскирането на поднизове (а/к/частична редакция на полето, напр. XXX-XX-1234) може да е добре за неща като SSN. Помислете за постоянството и показването на данните за анализ и т.н.
Свързано с това, външният вид и реализмът на шифрования текст също могат да определят използваемостта на резултатите. Целите на таблицата на приложенията и базата данни (помощна програма за зареждане) може да изискват форматът на данните не само да съответства на предварително дефинирани структури, но и да продължи да работи в заявки или други оперативни контексти надолу по веригата.
С други думи, ако се изискват маскирани данни, които са красиви и/или функционални, не се насочвайте към пълно редактиране, рандомизиране, хеширане или директно криптиране (което разширява и замъглява резултатите). Може да успеете да се измъкнете с по-малки настройки като стареене и манипулиране на поднизове, но помислете за въздействието на тези избори върху другите ви критерии за решение...
Обратимост (повторна идентификация)
Имате нужда от възстановяване на оригиналните данни? Отговорът на това може да зависи от това дали оставяте изходните данни сами, както бихте направили при динамично маскиране на данни, или когато записвате маскираните данни към нови цели. В тези случаи отговорът е не.
Ако отговорът е не, все още може да се нуждаете от реализъм, в които случаи необратимата псевдонимизация може да бъде най-добрият ви залог. Ако е не и външният вид няма значение, преминете към редакция на знаци. И ако нито едно от двете не е вярно, помислете за пълно изтриване на колоната източник от целта.
Когато отговорът е да, се показват функции за маскиране на IRI данни като криптиране, обратима псевдонимизация или токенизация, кодиране или ASCII повторно идентификатор (кодиране на битове). При по-напреднали случаи на използване може да се наложи и обръщане на диференциала; т.е. когато различни получатели на една и съща цел са упълномощени да виждат различни неща в един и същ набор от данни. В такива случаи могат да бъдат разгърнати частни ключове за криптиране, специфични за потребителя скриптове за разкриване или дори персонализирани приложения.
Уникалност (последователност)
Винаги ли една и съща първоначална стойност трябва да бъде заменена със същата, но различна заместваща стойност? Данните ще бъдат ли обединени или групирани от заместващите стойности? Ако е така, избраният алгоритъм за заместване трябва да дава резултати, които са уникални и повтарящи се, за да се запази референтната цялост въпреки маскирането, което е настъпило.
Това може да се постигне чрез криптиране, когато един и същ алгоритъм и парола (ключ) се използват срещу един и същ открит текст. Помощниците за класификация на данни и кръстосана защита на таблици в IRI Workbench IDE за FieldShield, Voracity и т.н. улесняват това чрез кръстосано (или по-глобално) прилагане на правилото за съвпадение за маскиране. По този начин една и съща стойност на отворен текст винаги получава един и същ резултат от шифрован текст, независимо от местоположението му.
Псевдонимизацията тук обаче е по-сложна поради недостига на уникални заместващи имена, дублиращи се оригинални имена и промени ( вмъква, актуализира или изтрива) към оригиналните стойности в изходните таблици или файлове. IRI обърна внимание на проблема с последователната псевдонимизация на различни таблици в този пример за работен процес на Voracity.
Сила (Сигурност)
Погледът към алгоритмите във всяка функция може да ви помогне да определите тяхната относителна „пробиваемост“ и да оцените това спрямо другите съображения за шифроване като външен вид и скорост. Например, функцията AES256 на IRI е по-силна от опцията AES128, SHA2 е по-силна от SHA1 и всички са по-силни от функциите за кодиране/декодиране на base64 и функциите за де-ID/повторна идентификация на ASCII.
По дефиниция, обратимите функции обикновено са по-слаби от тези, които не могат да бъдат обърнати. Например, методът на необратимия псевдонимизация (набор за чуждестранно търсене) на IRI е по-сигурен от неговия обратим (кодиран оригинален набор) метод за псевдонимизация. Въпреки това алгоритъмът за криптиране AES-256 може да бъде много труден за разбиване, когато ключът е загубен.
Разбира се, дори по-силната сигурност е пропускане, последвано от замъгляване на знаци (редактиране), което е необратимо. Но недостатъкът е липсата на използваемост. В контекста на HIPAA безопасното пристанище премахването на ключови идентификатори е в съответствие. Ако обаче трябва да използвате която и да е част от изходните данни за анализ, изследване, маркетинг или демонстрация, вместо това ще ви трябва функция за маскиране и експерт, който да определи (и да удостовери), че вашата техника(и) носят нисък статистически вероятност от повторно идентифициране.
Докато сме по темата за деидентификация по HIPAA, не забравяйте, че може да има риск, свързан с така наречените квази идентификатори (като пощенски код и възраст). Тези стойности могат да се използват във връзка с други набори от данни за установяване на следа за повторна идентификация и следователно също си струва да се маскират в много случаи; дали и как са предмет на същите тези съображения.
Изчисление (производителност)
Едно от хубавите неща за подхода за маскиране на данни - дори когато са включени алгоритми за криптиране с интензивно изчисление - е, че режийните му разходи спрямо криптирането с широка четка (на цяла мрежа, база данни, файл/система, дисково устройство) са далеч по-ниски. Само онези елементи от данни (стойности на колони), които сте определили за защита, трябва да бъдат погълнати, обработени от и върнати от функцията за маскиране.
Като цяло, колкото по-сложен (и по-силен) е алгоритъмът, толкова повече време ще отнеме прилагането му. Скоростите на маскиране на данни също ще зависят от броя на приложените функции, броя на колоните и редовете на DB, броя на ограниченията за търсене, които трябва да се спазват в процеса (за референтна цялост), мрежовата честотна лента, RAM, I/O, едновременните процеси и скоро.
Следващата ненаучна диаграма разбива повечето от атрибутите, описани по-горе за удобна справка, за някои (но не всички!) поддържани функционални категории за маскиране на IRI данни и като цяло само относително. Излишно е да казвам, че IRI отказва всякаква гаранция за годност или отговорност за тази диаграма!
Функции за маскиране на IRI данни (в FieldShield &Voracity)
Независимо дали използвате вградени функции за маскиране на IRI данни или персонализирани функции, които дефинирате, идеята е да ги приложите въз основа на вашите бизнес правила към конкретни редове или колони и/или между таблици. И ще го направите чрез правила за маскиране на данни, които можете да дефинирате, съхранявате и използвате повторно. Възможно е (и за предпочитане) тези функции за маскиране на данни да се прилагат срещу автоматично класифицирани данни като правила за удобство и последователност. И можете да използвате няколко от тях в приложения за динамично маскиране на данни чрез извикване на API.
Потребителите на FieldShield (или Voracity) могат да създават, изпълняват и управляват вашите задачи за маскиране на данни в безплатен съвременен GUI, изграден върху Eclipse.™ Или могат да редактират и изпълняват съвместими, самодокументиращи 4GL скриптове, определящи техните изходни/целеви данни и функции за маскиране и стартирайте тези скриптове в командния ред.
За повече информация вижте https://www.iri.com/solutions/data-masking или се свържете с вашия представител на IRI.
