General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679)

vassy

Active Member
От известо време дискутираме темата за General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679) по няколко форума и специализирани сайтове. Ако сте чели по въпроса, това касае всички ви. От всякакви софтуери в търговия, фактуриране, работни заплати, маркетинг до онлайн магазини и сайтове за онлайн фактуриране. Проблема е много сериозен. Касае обработката на лични данни, тяхното криптиране и не само. Срещнах 2 споменавания на GDPR и 2016/679 във форума, за това и отварям темата.

Регламент 2016/679 предвижда нови правила относно защитата на физическите лица във връзка с обработването на лични данни и относно свободното движение на такива данни. Отменя Директива 95/46/EО и се прилага от 25 май 2018 г. Разширява се териториалният обхват и се увеличават санкциите – до 4% от оборота. В определени случаи компетентността по сигнали за нарушения се измества от КЗЛД към надзорните органи в други страни членки на ЕС. Касае всички компании, които за целите на дейността си събират, обработват или съхраняват лични данни – на служители, клиенти или трети лица.

При нас проблема идва от нуждата от криптиране на чувствителни полета в PostgreSQL база и държене на ключовете на друго място. Освен това базата е на отделна машина и комуникацията с основното приложение също трябва да е криптирана. При повечето от вас проблема е подобен, може би с MySQ или друга база. Пускам темата за дискусия докато е време. Регулацията влиза в сила на 25.05.2018 г.

Забележете, че не е нужно да се регистрирате като администратор на лични данни в КЗЛД за да важи и за вас регулацията, просто важи за всички, а глобите са твърде солени.

Още линлове:
https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
https://www.cpdp.bg/?p=element&aid=991
https://www.cpdp.bg/?p=element&aid=1043
 
Последно редактирано:
Обработваш ли лични данни - т.е. издаваш фактури, получаваш поръчки онлайн или записваш имена на листче в магазина си задължен да се регистрираш в КЗЛД. За останалото ще прочета, но според мен това нещо няма как да просъществува дълго или поне контрола по него ще е доста скъп и труден (както стана с кукитата) и ще се облекчи режима много скоро след като влезне в сила и видят западняците търговци какво са им набутали от Брюксел бюрократите и почне да се мрънка...
 
След 25 май 2018 г. няма да е нужно да си регистриран като оператор на лични данни.По презумпция регламента важи за всички.

По долу цитирам мой колега от същата дискусия, но в друг форум:

За решаването на даден проблем трябва първо да се изясни от какво се поражда. Проблемът с чувствителните лични данни е в няколко аспекта:
1. Какво са чувствителни лични данни - това е информация запазена под каквато и да е форма, чрез която може да се идентифицира дадения субект лице. Какво би означавало това: Проблемът е създаден от държавната администрация със същата тази цел, т.е. надеждно идентифициране, а сега в съвременния глобален свят, където границите са на практика само за държавните администрации, а не за личностите. В тази връзка ЕГН е основен източник за идентификация + трите имена и вече имаме чуствителни лични данни, ако добавим и адрес с пощенски код Град. ,
Извод: Чувствителни данни са данните от личната ти карта, техните копия под каквато и да е форма, настоящият ти адрес. Обвързаност с други хора, здравословно състояние, политическа принадлежност и др.
Как да защитим личните данни. Трябва да се разкъса връзката между различните детайли от информацията.
Решения: криптиране на ЕГН, имена или пощенски код и град, останалите полета не са достатъчни за идентифициране.
Проблеми: Индексното търсене в криптирани полета е трудно или невъзможно. Опасност от ненадежно криптиране - при странична атака на криптиращите физически устройсва може да доведе до загуба на информация т.е. криптиране с невъзможност за възстановяване. Това е сериозен проблем при асинхронно съхранение на информация. Друг проблем е съхраняването на информацията, заедно с инструмента за обработка, т.е. изпълнителната част на програмата и база с данни на едно физическо място. Евентуално при тази конфугурация може да се открадне физическата машина и това на практика обезсмисля криптирането и хеширането. Ключодържателите са добро решение, но трябва да са съхранени на "добро" място, евентуално в карта. Друг основен проблем е загубата на ключовете за криптиране, ако това се случи това ще е загуба на пълната информация.
Какво трябва да се защити: Първо данните, може би криптация на целият диск с базата данни или криптиране на отделни колони с функции ползващи pgp криптация с ключове и ид-ве за криптиране/декриптиране.
Пътят до данните: повечето случаи достъпа на инструмента до базите става по някой от интернет протоколи или през сокет. Обикновено се прави с потребител, ползван от инструмента за вход в базата. Примерите са много в българския софтуер. Имаш възможност да манипулираш която си искаш база данни без инструмента, който го прави. Рядко се срещат свързвания с бази данни през криптирани протоколи.
Инструмента: Обиновенно това е приложение разчитащо на затворена библиотека с неясни действия вътре в нея, при тази ситуация много ясно в регламента е казано, че се наказва организацията ползвател на този инструмент/библиотека, това е доста сериозно предизвикателство за разработчиците, те трябва да гарантират по някъв начин, че използват напълно прозрачен инструмент. openPGP, openSSL е добро решение.
Последният и немаловажен проблем е: Възможноста по искане на субектите да се заличи информацията. Това в момента е най-сериозният проблем, защото при сегашния модел на изисквания на публичната администрация са изградени множество копия на лини данни под формата на хартиени носители, електронни копия, и множество електронни архиви и прочие. С други думи като се започне от личната карта с милионите си копия някъде си до данни върху фактури и всякакви други бланки. Какво касае програмистите за горното, да му мислят умните глави. Принципно е необходимо да се раздели архивирането на лични данни и други данни, за да има възможност да се проследи и изстрие информацията.
За мен решение на част от проблемите е:
1. Уеб базиран инструмент с https надежно подписана страница.
2. Връзка с бази дании през ssl/tcl протокол.
3. Инструменти за дроп на сесии въз основа на отказан достъп.
4. Криптиране на полета с ид информация ЕНГ и прочие, и по скоро обединяване в единна таблица за да се използва маскиране с ИД
5. Архивиране на данни с чувствителна информация в некомпресиран вид и с криптация.
6. Използване на keystore инструменти за частния и публичния ключ.
7. Времево зависимо прекодиране с нов ключ и проверка.

http://www.linux-bg.org/forum/index.php?topic=47842.msg300292#msg300292
 

Горе