Защита на данните в покой и в движение
Приложенията за бази данни, които актуализират и правят заявки за таблици, може да се наложи да защитят данните, влизащи или извличани от тези таблици. Чувствителните данни трябва да бъдат защитени при влизане в таблицата, веднъж в таблицата или при излизане. Във всеки случай целта е да се предпази неупълномощени хора от достъп до определени стойности на редове или колони, считани за чувствителни.
За данни в нормална форма (структурирани) в релационни бази данни, самостоятелната помощна програма за маскиране на данни IRI FieldShield или нейната съвместима библиотека от извикваеми маскиращи функции може да побере горните сценарии, като предоставя много опции както за статични (постоянни, в покой), така и за динамични (в -транзит) опции за маскиране на данни. Ако имате и PII/PHI стойности, плаващи произволно в полу- и неструктурирани RDB колони (като текст, C/BLOB, XML/JSON), вижте тази статия за подхода IRI DarkShield.
Тази статия обаче ще говори за опциите на FieldShield, тъй като повечето потребители на RDB са загрижени за намирането и маскирането на фиксирани стойности на колони. Потребителите на FieldShield могат да класифицират, локализират и маскират данни в DB таблици, а за потребители на приложения да се изпълняват чрез:
- статично маскиране на данни в производствени таблици и динамично демаскиране от оторизирани потребители на приложения
- маскиращи функции, вградени в съвместими с метаданни задачи за трансформиране, почистване или отчитане
- базирана на прокси система за динамично редактиране на данни
- чрез SDK API или системно повикване от програма
- на място, чрез SQL процедури с помощта на персонализирана библиотека
Ако вашите данни са в NoSQL бази данни като MongoDB, Cassandra, Elasticsearch или MarkLogic, FieldShield ще обработва структурирани колекции, докато DarkShield ще обработва както структурирани, така и неструктурирани колекции.
По подразбиране — и начинът, по който графичният интерфейс на IRI Workbench представя FieldShield на крайните потребители и DBA – една или повече пълни таблици обикновено са защитени с функции за маскиране на статични данни (като криптиране, редактиране, псевдонимизация) в съответствие с бизнес правилата. Изборът на всеки „щит на поле (колона)“ трябва да се основава на сигурност, реализъм, обратимост и може би съображения за процесор или съхранение.
Статичният подход работи добре, когато данните са в покой. Или таблицата източник може да бъде защитена, или може да се създаде нова целева таблица или файл с приложени защити. Приложенията, които извличат защитените данни, не трябва да се притесняват за сигурността, тъй като техните източници на данни са били предварително защитени. Програмите FieldShield, предназначени да защитават данните в покой, също могат да бъдат планирани или извикани в пакетни задания за редовни актуализации.
Въпреки това, в среда в реално време, където актуализираните редове се нуждаят от динамична защита, функциите на FieldShield трябва да бъдат интегрирани в потока от данни на приложението. Има няколко подхода за разглеждане:
1) Вашата програма извиква FieldShield
База данни и други програми, които извличат или изпращат нови или променени данни в таблици, могат да ги предават във функция на API за криптиране, хеширане, кодиране или редактиране на FieldShield в C, Java или .NET. Можете също така да предадете данните в движение в самостоятелна програма FieldShield чрез процедура за въвеждане или въвеждане. Всеки от тези методи може да попълни цели с приложени функции за защита (или разкриване) на ниво колона.
2) FieldShield защитава само актуализации
Програмите на FieldShield могат също да бъдат персонализирани чрез функциите /QUERY и /UPDATE, или да филтрират условно само нови записи, където редовете, които трябва да бъдат защитени, отговарят на специфични критерии, като новост. Обажданията на API биха позволили за още по-подробна бизнес логика и ще улеснят повече условия за „скорост“ (или латентност) на данните — например повече маскиране на данни в реално време — защото тези нужди могат да бъдат изразени чрез приложението и дефинирани от неговата логика. Вижте този PL/SQL пример за маскиране в реално време въз основа на задействане.
3) Улавяне и защита на делтите в CoSort (родител на FieldShield)
Задачите за улавяне на промяна на данни (CDC) могат също да бъдат програмирани в езика за управление на сортирането на CoSort (SortCL), при което само избрани вмъквания, актуализации, изтривания или непроменени редове могат да се предават към таблици или файлове с приложена защита на колони, когато това се случи. Потребителите на CoSort разполагат с всички функции за защита на FieldShield, така че е възможно да маскират само променените данни в тази парадигма за групово отчитане.
4) Прихващания на заявки, базирани на прокси
IRI вече предоставя специален драйвер “JDBC SQL Trail” за приложения за използване, който филтрира DB заявки за оторизирани потребители и определени таблици и колони. Тези, които не са освободени от дефиницията на политиката на DDM, ще виждат само напълно или частично редактирани стойности по време на полет към това специално свързано приложение от базата данни, което остава демаскирано в покой.
5) Персонализирани интеграции
IRI може да работи с вашия DBA или програмист на приложения, за да проектира индивидуално решение, което включва елементи от горното, или да предостави библиотеки на FieldShield, които вашите SQL процедури могат да извикат на място като тези, за да защитят или разкрият (криптиране или декриптиране) на заявка резултати, таблици със заявки, материализирани изгледи и т.н.
Свържете се за помощ за интегриране на функция за динамично маскиране на данни, като редактиране или запазване на формат криптиране във вашето приложение.
