Как защитить базы с персональными данными, рассказываем на примере крупного ритейлера

А потом чудесный программист на PHP забудет убрать из релиза отладочный код, который пишет в лог (доступный по HTTP конечно же) данные о новых регистрациях. А дальше - дело времени, когда и кто на этот лог наткнется. Видел я такое у совсем немаленького ритейла в РФ, да...

Первое, что приходит в голову — обезличить данные. Их все равно придется защищать, но, по крайней мере, не придется беспокоиться о Роскомнадзоре.

А можно про это поподробнее? Насколько я понимаю официальную позицию Роскомнадзора, обезличенные персональные данные -- это тоже персональные данные. Просто потому что их можно восстановить. При той же утечке данных. То есть это один из способов снизить последствия утечки, то никак не выведение таких данных из под сферы действия закона о персональных данных.

Путаницы наводит юридическая техника, потому что в соответствии с тем же самым приказом Роскомнадзора о способах обезличивания, деобезличивание -- это действия, в результате которых данные становятся персональными данными. Подразумевая, что обезличенные данные -- это просто какие-то данные. Вроде даже есть древние судебные акты, где обезличенные данные не признавались персональными. Но так же есть и противоположные решения. И весьма свежее.

При этом сам ФЗ "О персональных данных" как раз использует трактовки, поддерживающие позицию, что обезличенные персональные данные -- это всё ещё персональные данные. Обезличивание лишь одно из способов обработки. К примеру, "обработка персональных данных осуществляется в статистических или иных исследовательских целях, за исключением целей, указанных в статье 15 настоящего Федерального закона, при условии обязательного обезличивания персональных данных" (п. 9 ч. 1 ст. 6).

На семинарах представители Роскомонадзора обычно подчёркивают, что то, чего хотят операторы, это анонимизация персональных данных. И их способы ещё не нашли воплощения в НПА, поэтому всё на свой страх и риск. Посчитают ли при проверке их анонимизированными либо обезличенными.

GDPR пошло аналогичным путём. Там тоже разделяют псевдонимизацию и анонимизирование, при этом псевдонизимация (обезличивание) рассматривается по сути как способ защиты персональных данных.

Буду благодарен, если поделитесь кейсами реальными. Просто мне приходилось встречать советы по обходу регулирования трансграничной передачи данных, мол, оставьте ФИО в России, а за кордон всё остальное, типу туда уже ненастоящие персональные данные уходят. Выглядит весьма сомнительно. Вот, например, как здесь -- юридическое заключение по Microsoft Azure.

С точки зрения регулятора, достаточно, чтобы хотя бы где-то в цепочке передачи данных встретились, например, имя и телефон.

Интересно, что Роскомнадзор не считает телефон сам по себе персональными данными (хотя их как флюгер крутит постоянно в классификациях), а вот их шефы в Минцифре считают. "Таким образом, абонентский номер или адрес электронной почты могут быть признаны персональными данными в случае, когда такая информация относится к прямо или косвенно определенному или определяемому физическому лицу" (Письмо Минкомсвязи России от 07.07.2017 N П11-15054-ОГ "О разъяснении норм федерального законодательства"). В принципе, позиция Минцифры логичная. У нас сегодня телефон стал основным идентификатором по сути во всех сервисах, в том числе в личных мессенджерах.

В известном решении по cookie (между МГТС и Росмкомнадзором) всё пошло вообще по странному пути и по сути как персональные данные рассматривали "следующие сведения об абонентах (пользователях): случайный идентификатор (Cookie «UID») в HTTP-запросе пользователя, позволяющий отличить трафик пользователя от трафика других пользователей для получения списка его предпочтений; IP-адрес из IP-пакета HTTP-запроса пользователя, позволяющий получить географическое положение пользователя с точностью определения до названия населенного пункта; User-Agent HTTP-запроса пользователя, позволяющий получить модель устройства или типа браузера, используемого пользователем; Время просмотра веб-страниц (HTTP-запроса пользователя), позволяющее оценить частоту, с которой пользователь проявляет те или иные предпочтения; URL-адрес и заголовок Referrer HTTP-запроса пользователя, позволяющее определить предпочтения пользователя; Hash-ID линии пользователя, позволяющий определить линии, абоненты которых выразили несогласие с обработкой данных".

В целом, тоже логично. Технологии больших данных сегодня на основании совсем косвенных сведений позволяют почти точно установить личность человека.

Создаётся впечатление, что единственный способ снять с себя риски, рассматривать вообще все данные, которые относятся к физику, как персональные.

И наоборот, можно надежно защититься, и все равно получить штраф от регулятора, например, неправильно подготовив проектную документацию на систему.

Уточните конкретную статью КоАП (или УК), каким образом можно получить штраф? На что регулятор будет ссылаться?

После установки эта система автоматически находит базы данных в сети компании, проверяет их на наличие персональных данных

really ?

И всё это ради скидки три рубля на майонез ? Ага щаззз !

Вывод - проще стащить backup этой БД :)

Я правильно понимаю, что при постановке этой системы в мониторинг на копии трафика требуется, чтобы соединения от приложений к серверу БД не должны быть шифрованными?

Насколько это распространённая практика -- оставлять подключение к базе не защищёнными шифрованием?