Что такое обезличивание данных

Обезличенные данные: как защитить граждан и стимулировать бизнес

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

Обезличивание – это метод снижения риска, но не полная гарантия защиты прав граждан.

Татьяна Матвеева, начальник управления президента по применению информационных технологий и развитию электронной демократии

С другой стороны, данные – это топливо для искусственного интеллекта и катализатор для развития экономики. Государство все это понимает и делает шаги навстречу бизнесу, заверила Матвеева. Сейчас активно обсуждается законопроект по регулированию обезличенных данных, запущен федеральный проект по искусственному интеллекту, который предусматривает введение экспериментальных правовых режимов.

«Но так или иначе все решения нужно принимать и оценивать через призму прав граждан», – подчеркнула спикер. С ней согласился замглавы Роскомнадзора Милош Вагнер: «При введении любого регулирования должны не ухудшаться, а улучшаться права граждан».

«Обезличенные» равно «персональные»?

Персональные данные, полученные в результате обезличивания, – это все равно персональные данные. К ним должно применяться соответствующее законодательство, пояснил Вагнер позицию Роскомнадзора.

С такой интерпретацией поспорил бизнес. «По закону персональные данные – это данные, которые позволяют определить конкретную личность. Обезличивание – это отрыв данных от личности», – заявил Руслан Ибрагимов, вице-президент по взаимодействию с органами госвласти и связям с общественностью ПАО «МТС».

По его словам, обезличенные данные – отдельный вид информации, которую можно пустить в оборот. Если кто-то решил «де-обезличить» такие сведения, они становятся персональными и на них распространяется соответствующее регулирование.

Нам нужно определиться с понятиями. Как только мы достигнем консенсуса в этом, все остальные вопросы будут решаться автоматически.

Руслан Ибрагимов, вице-президент ПАО «МТС»

Обезличенность и свободный оборот

Степень обезличивания данных может быть разная. Ирина Левова из АНО «Институт исследований интернета» представила схему, на которой показала, как в зарубежных странах свобода обращения зависит от уровня обезличивания.

Существуют специальные коэффициенты: 0 – это персональные данные, 1 – полностью анонимизированные. Компания сама оценивает степень обезличивания в каждом конкретном случае, исходя из используемых методов. Чем больше мер она использует, тем меньше вероятность повторной идентификации и тем выше коэффициент обезличивания, пояснила Левова.

Если он равен 0,7 – 0,8, зарубежные регуляторы не признают данные персональными и разрешают более свободное обращение. По словам спикера, они уже несколько месяцев работают над математическим обоснованием рисков применения тех или иных методов. «Надеюсь, мы сможем апробировать полученные результаты в рамках экспериментальных режимов, а потом уже вернуться к разработке законодательных поправок», – поделилась Левова.

Хорошо, конечно, апробировать методики в различных «песочницах», ждать реализации пилотов. Но не займет ли это годы? А ведь все это время бизнес по-прежнему будет трать свои ресурсы на преодоление непрозрачных и непонятных правил работы с обезличенными данными.

Анна Попова, вице-президент ПАО «Сбербанк»

В завершении своего выступления Попова перечислила основные запросы, которые сейчас есть у бизнеса:

Источник

Что это – обезличивание персональных данных?

Обезличивание персональных данных – это один из методов их защиты. В соответствии с действующим законодательством персональную информацию людей, в общем случае, нельзя распространять без их согласия. В связи с этим в некоторых случаях государственные и муниципальные органы обязаны производить обезличивание персональных данных. Если сказать простым языком, это сокрытие перссведений, содержащихся в документах, размещаемых властями в открытом доступе. Подробнее об этом читайте в материале.

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

Определение всегда остается теоретической выкладкой, каким бы понятным оно не казалось. Наиболее наглядно сущность обезличивания его может проиллюстрировать пример. Обезличивание персональных данных – это действия, в результате которых из судебного решения, к примеру, изымаются непременно содержащиеся в нем персональные данные. Только после этого обезличенная копия судебного акта может быть размещена в свободном доступе (п. 3 ст. 15 Федерального закона от 22.12.2008 № 262-ФЗ).

Таким образом, обезличивание персональных данных – это действия, в результате которых становится невозможным определить принадлежность опубликованных данных конкретному человеку. По крайнем мере, нельзя этого сделать без дополнительной информации (ст. 3 Федерального закона от 27.07.2006 № 152-ФЗ).

Как это делается

Чтобы поставить работу по обезличиванию данных, нужно выполнить ряд соответствующих действий. В частности, нужно утвердить (подп. «б» п. 1 перечня, утв. постановлением Правительства от 21.03.2012 № 211):

Важно понимать, что существуют специальные требования и способы обезличивания данных, которые обрабатываются в информационных системах. Они перечислены в приказе Роскомнадзора от 05.09.2013 № 996.

Однако кроме защитных функций обезличивание персональных данных – это действия направленные на последующую возможность работы с полученными сведениями. То есть обезличивание не должно повлиять на возможность обработки. Иными словами изменяемая информация должна сохранить (п. 3, 4 требований и методов, утв. приказом Роскомнадзора от 05.09.2013 № 996):

В завершение перечислим применяющиеся на практике из-за своего удобства и функциональности методы обезличивания (п. 10-15 требований и методов, утв. приказом Роскомнадзора от 05.09.2013 № 996):

Источник

Обезл***вание д***ных — это не просто рандомизация

В банке есть проблема: нужно давать доступ к базе данных разработчикам и тестировщикам. Есть куча клиентских данных, которые по PCI DSS требованиям Центробанка и законам о персональных данных вообще нельзя использовать для раскрытия на отделы разработки и тестирования.

Казалось бы, достаточно просто поменять всё на какие-нибудь несимметричные хеши, и всё будет хорошо.

Дело в том, что база данных банка — это множество связанных между собой таблиц. Где-то они связаны по ФИО и номеру счёта клиента. Где-то по его уникальному идентификатору. Где-то (тут начинается боль) через хранимую процедуру, которая вычисляет сквозной идентификатор на основе этой и соседней таблицы. И так далее.

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

То есть прежде чем всё это обезличить, сначала надо разобраться в базе данных.

Кто делает обезличивание и зачем?

Обезличиванием или маскированием занимаются потому, что есть законы и стандарты. Да, гораздо лучше тестировать на «снапшоте прода», но за такой залёт регуляторы могут и отозвать лицензию. То есть прикрыть бизнес как таковой.

Любое обезличивание — это достаточно дорогая и неповоротливая прослойка между продуктивными системами и тестированием с разработкой.

Цель проектов по обезличиванию (маскированию) практически всегда — подготовить данные для тестирования, максимально похожие на реальные, хранящиеся в продуктивных базах. То есть если данные содержат ошибки — вместо email забит телефон, вместо кириллицы в фамилии латиница и т. п., то и замаскированные данные должны быть такого же качества, но изменёнными до неузнаваемости. Вторая цель — уменьшение объёма баз данных, которые используются в тестировании и разработке. Полный объём оставляют только под нагрузочное тестирование, а под остальные задачи обычно делается некий срез данных по заранее определённым правилам — усечение БД. Третья цель — получить связанные между собой данные в разных замаскированных и усечённых базах. Имеется в виду, что данные в разных системах, в разное время, должны быть обезличены единообразно.

По вычислительной сложности обезличивание — это примерно как несколько архивирований базы данных на предельной компрессии. Алгоритм примерно похож. Разница в том, что алгоритмы архивирования оттачивались годами и дошли до почти максимального КПД. А алгоритмы обезличивания пишут так, чтобы они хотя бы работали на текущей базе и были достаточно универсальными. И софт после обезличивания вообще заработал. То есть отличный результат — перемолоть 40 ТБ за ночь. Бывает так, что заказчику дешевле загонять в обезличивание базу раз в полгода на неделю на слабеньком сервере — тоже подход.

Как заменяются данные?

Каждый тип данных меняется в соответствии с правилами, которые могут использоваться в коде. Например, если мы заменим ФИО на случайный хеш со спецсимволами и цифрами, то первая же проверка корректности данных сразу выдаст ошибку в реальном тестировании.

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

Естественно, для работы с этим софтом нужен допуск к реальным данным (обычно это копия недавнего бекапа БД). По банковскому опыту мы сначала два месяца подписываем тонну бумаг, а потом приезжаем в банк, нас раздевают, обыскивают и одевают, потом мы идём в отдельное обшитое клеткой Фарадея помещение, в котором стоят двое безопасников и тепло дышат нам в затылок.

Итак, предположим, после всего этого мы видим таблицу, в которой есть поле «ФИО». Визард уже за нас его разметил как ФИО, и нам остаётся только подтвердить и выбрать тип обезличивания. Визард предлагает случайную замену на славянские имена (есть базы для разных регионов). Мы соглашаемся и получаем замены вроде Иван Иванов Петренко — Иосиф Альбертович Чингачгук. Если это важно, сохраняется пол, если нет — замены идут по всей базе имён.

Следующее поле — дата в юникстайме. Визард это тоже определил, а нам надо выбрать функцию обезличивания. Обычно даты используются для контроля последовательности событий, и ситуации, когда клиент сначала сделал перевод в банке, а потом открыл счёт, никому особо не нужны на тестировании. Поэтому мы задаём небольшую дельту — по умолчанию в пределах 30 дней. Ошибки всё равно будут, но если это критично, можно настроить более сложные правила, дописав свой скрипт в обработку обезличивания.

Адрес должен валидироваться, поэтому используется база российских адресов. Номер карточки должен соответствовать реальным номерам и валидироваться по ним. Иногда бывает задача «сделать все Визы случайными Мастеркардами» — это тоже выполнимо в пару кликов.
Под капотом визарда находится профилирование. Профилирование — это поиск данных в БД по заранее заданным правилам (атрибутам, доменам). Фактически мы читаем каждую ячейку базы данных заказчика, применяем к каждой ячейке набор регулярных выражений, сравниваем значения в этой ячейке со словарями и т. д. В результате чего имеем набор сработавших правил на столбцах таблиц базы данных. Профилирование мы можем настраивать, можем читать не все таблицы в БД, можем брать только определённое количество строк из таблицы или определённый процент строк.

Что происходит внутри?

К каждой записи в базе применяются правила обезличивания, которые мы выбрали. При этом на время работы процесса создаются временные таблицы, куда записываются замены. Каждая последующая запись в БД прогоняется по этим таблицам соответствия замен, и если там есть соответствие — заменяется так же, как раньше. Всё на деле чуть сложнее в зависимости от ваших скриптов и правил сопоставления паттернов (может быть неточная замена, например для родов или замен дат, хранимых в разном формате), но общая идея такова.

Если есть размеченные соответствия «имя кириллицей — имя латиницей», то они должны быть явно обозначены на этапе разработки, и тогда в таблице замен они будут соответствовать друг другу. То есть имя кириллицей будет обезличено, а потом эта обезличенная запись будет сконвертирована в латиницу, например. В этом моменте мы отходим от подхода «не улучшать качество данных в системе», но это один из компромиссов на которые приходится идти ради какой-никакой, но производительности системы. Практика показывает, что если нагрузочное, функциональное тестирование в своей работе не замечает компромисса, то ничего не было. И тут всплывает важный момент, что обезличивание в целом это не шифрование. Если у вас пару ярдов записей в таблице, а в десятке из них ИНН не изменился, то что? То ничего, этот десяток записей не найти.

После окончания процесса таблицы перекодировки остаются в защищённой базе сервера обезличивания. База нарезается (усекается) и передается в тестирование без таблиц перекодировки, таким образом, для тестировщика обезличивание становится необратимым.

Полная обезличенная база передаётся тестировщикам для нагрузочного тестирования.

Это значит, что во время работы с БД таблица перекодировки «пухнет» (точный объём зависит от выбора замен и их типа), но рабочая база остаётся исходного размера.

Как примерно выглядит процесс в интерфейсе оператора?

Общий вид IDE на примере одного из вендоров:

Запуск трансформации из IDE:

Настройка выражения для поиска чувствительных данных в профилировщике:

Страница с набором правил для профилировщика:

Результат работы профилировщика, веб-страница с поиском по данным:

Все ли данные в базе маскируются?

Нет. Обычно список данных под обезличивание регулируется законами и стандартами сферы, плюс у заказчика есть пожелания по конкретным полям, про которые не должен знать никто.

Логика в том, что если мы замаскировали ФИО пациента в больнице, можно маскировать или не маскировать диагноз — всё равно никто не узнает, от кого он. У нас был случай, когда примечания к операции в банке просто маскировали случайными буквами. Там были заметки уровня: «В кредите отказано, так как клиент пришёл пьяным, его вырвало на стойку». С точки зрения отладки это просто строка символов. Ну вот пусть ей и остаётся.

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

Можно ли менять данные средствами самой СУБД?

Да. При обезличивании данных есть два основных подхода — изменять данные в БД средствами самой БД либо организовать ETL-процесс и менять данные посредством стороннего софта.

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

Ключевой плюс второго подхода — неважно, какая у вас БД, система, файл это или какой-то веб-интерфейс, — один раз реализовав какое-то правило, вы можете использовать его везде. Ключевой минус — надо читать данные из базы, обрабатывать их отдельным приложением, записывать в базу обратно.

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

То есть сделать можем всё, что угодно, но в банковском секторе очень хорошо зарекомендовал себя именно ETL-подход.

А почему данные просто не портят вручную?

Один раз так можно сделать. Кто-то просидит три дня, обезличит кучу данных и подготовит базу данных на 500-1000 записей. Сложность в том, что процесс надо повторять регулярно (с каждым изменением структуры БД и появлением новых полей и таблиц) и на больших объёмах (для разных видов тестирования). Обычный запрос — обезличить первые 10-50 ГБ базы так, чтобы этот объём пришёлся на каждую таблицу равномерно.

Что делать, если в базе хранятся сканы документов?

Если документ можно свести к XML и конвертировать обратно (это, например, документы офиса), — можно провести и обезличивание в них. Но иногда бывают бинарники вроде сканов паспортов в PDF/JPG/TIFF/BMP. В этом случае общепринятая практика — нагенерить сторонним скриптом похожих документов и подменять реальные на образцы из базы нагенерённых случайным образом. Сложнее всего с фотографиями, но есть сервисы вроде этого, которые примерно похожим образом решают вопрос.

Кто за что отвечает?

При обновлении после изменения ПО или «вдогонку» процессы попроще.

А что, если на тестах что-то пойдёт не так?

Обычно так и случается. Во-первых, тестировщики после первого прогона обезличивания точнее формулируют требования к базе. Мы можем поменять правила обезличивания или отбраковывать записи вроде «вот тут действия должны идти в хронологическом порядке, а не в хаотичном». Во-вторых, в зависимости от внедрения мы или поддерживаем обезличивание по мере изменения базы, либо оставляем всю документацию, описания структуры БД и типов обработки, передаём весь код обработки (правила в xml/sql) и обучаем специалистов у заказчика.

Источник

Обезличивание персональных данных в России и в Европе: когда данные перестают быть персональными?

Обезличивание персональных данных в России и в Европе: когда данные перестают быть персональными?

Федеральным законом «О персональных данных» № 152-ФЗ (далее – ФЗ-152) предусмотрена категория «обезличивание персональных данных».

В соответствии со ст. 3 ФЗ-152 «обезличивание персональных данных — действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных».

Ввиду методической общности европейского и отечественного правового регулирования персональных данных представляется целесообразным изучить понимание обезличивания в европейском законодательстве и практике.

В европейских юрисдикциях (в настоящем исследовании рассмотрены Европейский Союз и Соединенное Королевство Великобритании и Северной Ирландии) понятие «обезличивание» не используется. Вместе с тем, для обозначения данных, отделяемых от идентификаторов субъекта, существуют категории «анонимизация» и «псевдонимизация».

I. Анонимизация и псевдонимизация в европейском законодательстве.

Понятию «обезличивание» в значении, принятом в Российской Федерации, соответствует псевдонимизация в значении GDPR.

Согласно параграфу 5 ст. 4 GDPR «псевдонимизация» — это обработка персональных данных таким образом, что их больше невозможно отнести к конкретному субъекту данных без использования дополнительной информации, при условии, что такая дополнительная информация хранится отдельно, и в отношении нее приняты технические и организационные меры, предотвращающие ее отнесение идентифицированному или идентифицируемому физическому лицу.

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

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

На это указывает и преамбула 28, согласно которой, использование «псевдонимизации» не подразумевает отказ от каких-либо иных мер защиты персональных данных. Применение псевдонимизации к персональным данным может снизить риски для соответствующих субъектов данных и помочь контролёрам и процессорам данных выполнить свои обязанности по защите персональных данных.

В соответствии с преамбулой 29, для того, чтобы стимулировать применение псевдонимизации при обработке персональных данных, допускается псевдонимизация, обработка и общий анализ псевдонимизированных данных одним и тем же контролёром, если этот контролёр принял технические и организационные меры, необходимые для того, чтобы обеспечить исполнение настоящего Регламента в отношении соответствующей обработки, а также чтобы дополнительная информация, позволяющая отнести персональные данные к определённым субъектом данных хранилась отдельно.

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

В отличие от псевдонимизации, которая повышает защиту данных, но по-прежнему оставляет их персональными, анонимизация делает данные анонимными, т.е. не персональными.

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

GDPR не применяется в отношении обработки анонимной информации, в том числе в статистических или исследовательских целях.

II. Официальные разъяснения, позиции и методические руководства.

Общеевропейские и национальные надзорные органы являются ключевым элементом европейской системы защиты прав субъектов персональных данных. Разъяснения, позиции и методические руководства надзорных органов обеспечивают единообразное понимание норм права формирование доступной, понятной, предсказуемой, последовательной и устойчивой правоприменительной практики.

Соответствующая практика сформирована и в отношении анонимизации и псевдонимизации данных.

Грань между псевдонимизацией и анонимизацией пролегает там, где субъект данных перестает быть идентифицируемым.

Позиция о концепции персональных данных (Opinion 4/2007 on the concept of personal data) WP29 от 20.06.2007 (Далее по тексту – Opinion 4/2007) [7] определяет лицо как идентифицируемое, если оно еще не идентифицировано, но его возможно идентифицировать прямо, например, по имени (если оно позволяет выделить субъекта из группы) или косвенно — по номеру паспорта, автомобиля, телефона или комбинации существенных критериев, позволяющих выделить субъекта из группы (это может быть возраст, место проживания, внешний вид и т.д.).

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

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

В целях установления того, является ли физическое лицо идентифицируемым, следует принять во внимание все средства, с разумной вероятностью используемые контролёром или иным лицом, для того чтобы прямо или косвенно идентифицировать физическое лицо. При определении того, используются ли средства с разумной вероятностью для идентификации физического лица, следует обратить внимание на все объективные факторы, такие как затраты и время, необходимые для идентификации, с учетом имеющихся на момент обработки технологий и технологических разработок.

Реальность идентификации субъекта зависит от конкретного контекста. Для оценки субъекта как идентифицируемого необходимо определить какие разумные усилия контролер или любое третье лицо должны будут приложить: затраты денежных средств на такие усилия; временные и человеческие ресурсы; наличие технологии, позволяющей выполнить идентификацию без особых усилий и затрат; подразумеваемая (а не декларируемая цель) и построение обработки; какие выгоды может извлечь контролер или любое другое третье лицо; продолжительность хранения данных и потенциальное развитие технологий для идентификации в этот период.

WP29 в Opinion 05/2014 подчеркивает: «В свете Директивы 95/46/EC и других соответствующих правовых документов ЕС, анонимизация является результатом обработки персональных данных с целью необратимого предотвращения идентификации. При этом контролеры данных должны учитывать ряд элементов, принимая во внимание все средства, которые «с большой долей вероятности» могут быть использованы для идентификации (как контролером, так и любой третьей стороной).

WP29 предлагает описание основных методов анонимизации в Opinion 05/2014. К числу основных групп методов анонимизации WP29 относит рандомизацию и обобщение (генерализацию). В Opinion 05/2014 объясняются их принципы, их сильные и слабые стороны, а также общие ошибки и риски, связанные с использованием каждого метода, приводятся примеры успешных практик (Приложение № 1).

Opinion 05/2014 оценивает надежность каждого метода, на основе трех критериев:

(i) сохраняется ли возможность выделения индивида из множества других лиц (‘singling out’);

(ii) сохраняется ли возможность установить связь между данными, касающихся отдельного лица (‘linkability’);

(iii) может ли информация быть объектом успешной «логической атаки» (‘inference’).

Периодическая оценка рисков должна включать обе категории таких рисков:

— риск повторной идентификации;

— риски, связанные с использованием анонимизированных данных как таковых, без повторной идентификации.

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

Во многих случаях даже анонимизированные наборы данных представляют остаточные риски для субъектов.

Британский документ принят до вступления в силу GDPR на основе Data Protection Act 1998, замененного ныне действующим Data Protection Act 2018.

ICO отмечает, что несомненно, что 100% анонимизация наиболее желательна, но Data Protection Act 1998 устанавливает более мягкий тест.

Представляется, что в данном решении Палаты Лордов, которое является чрезвычайно сложным и демонстрирует расхождение мнений судей по ряду вопросов (фактически, из пяти судей, четверо дали concurring judgments с различной аргументацией и объяснением концепта «персональные данные»), можно уловить отражение различий в понимании концепта «персональные данные» в Великобритании по отношению к континентальной Европе.

Data Protection Act 2018 прямо имплементирует положения GDPR в национальную правовую систему Соединенного Королевства и содержит множество прямых отсылок к GDPR, следовательно, общие критерии применимого в UK подхода аналогичны вышеизложенным. Упомянутые судебные решения в части их ratio de с idendi также остается действующим источником права.

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

Британский кодекс содержит множество примеров, пояснений, инструкций и разбирает различные ситуации.

Ирландский Guidance Note: Guidance on Anonymisation and Pseudonymisation подчеркивает, что, если первоначальные данные не удалены и могут быть использованы для идентификации лиц, чьи данные анонимизированы, такие данные не являются анонимными и рассматриваются как псевдонимизированные, и, следовательно, продолжают считаться персональными.

Развивая подход WP29 (и неоднократно цитируя упомянутый Opinion), Ирландский регулятор поясняет значение термина «идентификатор»: «информация, тесно связанная с отдельным индивидом, которая может быть использована для его выделения. Такие идентификаторы могут быть прямыми (“direct”), как имя или изображение, или косвенными (“indirect”), как номер телефона, адрес электронной почты или другие уникальные идентификаторы, служащие для определения контролером субъекта персональных данных». Удаление прямых идентификаторов не делает набор данных анонимными. Данные, которые не являются идентификаторами, могут быть использованы для установления контекста, который может привести к идентификации или выделению человека из множества других лиц, например серия данных о местоположении или покупках или история поисковых запросов в интернете. Ирландский надзорный орган, как и их коллеги в Брюсселе и Уилмслоу, во всех случаях подчеркивает важность контекста и относительность определений персональных данных и анонимизации.

Как и WP29, ирландский регулятор называет три ключевых группы рисков, которые подлежат оценке:

Ирландский DPA также рассматривает тест, по содержанию близкий английскому ‘motivated intruder’ test’.

Как и WP29, ирландский орган называет две основные группы методов анонимизации: рандомизация и генерализация. В числе методов, повышающих защищенность данных, но не делающих их анонимными, Комиссия называет псевдонимизацию, а также «маскировку» данных.

В отличие от труднопонимаемого Opinion 05/2014, ирландский гайданс не перегружен математической и технической информацией, деталями и примерами, является простым и удобным для восприятия.

Как поясняется в документе, «технологические разработки последних лет неуклонно повышают спрос на качественные данные. В связи с этим государственные и частные организации рассматривают анонимизацию как средство обмена данными без ущерба для основных прав человека. Однако наряду с ростом популярности анонимизации получили широкое распространение некоторые заблуждения, связанные с ней.

Согласно документу, топ-10 заблуждений в отношении анонимизации составляют:

В действительности, это различные понятия. И это было показано в настоящем исследовании. Псевдонимизация помогает защитить персональные данные, но они остаются персональными, анонимизация делает данные анонимными, т.е. не персональными.

В действительности, шифрование это не анонимизация, но оно может быть мощным инструментом для псевдонимизации. Любая зашифрованная информация может быть расшифрована. Ключи для расшифровки будут являться дополнительной информацией, которая позволяет идентифицировать субъекта персональных данных. Даже если ключи шифрования уничтожаются или «неизвестны», никто не может дать гарантии, что информация никогда не будет расшифрована.

В действительности, далеко не во всех случаях практически возможно снизить риск обратной идентификации субъекта до приемлемого уровня и при этом сохранить полезные свойства набора данных. Анонимизация – это процесс, который пытается найти баланс между сокращением риска обратной идентификации и сохранением полезных свойств набора данных. Контекст и природа данных могут быть таковы, что снижение вероятности обратной идентификации до приемлемого уровня вообще будет недостижимо (например, если данные касаются малого, ограниченного и известного числа субъектов, например, депутатов Европарламента).

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

В действительности, процесс анонимизации и метод, которым он реализован, оказывает прямое воздействие на вероятность риска обратной идентификации. Цель надежной анонимизации состоит в том, чтобы сократить риск обратной идентификации ниже определенного порога, который зависит от многих обстоятельств, таких как возможные последствия от обратной идентификации для субъекта, степень заинтересованности, мотив и средства, доступные потенциальному злоумышленнику. Хотя 100% анонимизация является наиболее желаемой, во многих случаях она недостижима, и остаточные риски обратной идентификации также должны приниматься во внимание и оцениваться.

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

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

В действительности, надлежаще проведенная анонимизация сохраняет полезность набора данных для определенной цели. Процесс анонимизации должен учитывать цель, для которой планируется использовать анонимизированные данные. Принцип «минимизации данных» требует определения цели обработки и использования данных, в т.ч. после их анонимизации. Если выяснится, что анонимизированные данные не обеспечивают достижения определенной цели, контролер данных может выбрать, достичь цели путем обработки псевдонимизированных персональных данных, соблюдая GDPR, или отказаться от обработки и достижения соответствующей цели.

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

В действительности, персональные данные сами по себе представляют ценность для самих субъектов и для третьих сторон. Обратная идентификация может иметь серьезные последствия для прав и свобод субъектов.

Выводы:

1. В европейском законодательстве и практике понятия «обезличивание» и «обезличенные данные» отсутствует.

2. Российскому концепту «обезличенные данные» соответствует понятие «псевдонимизированные данные», соответственно, «обезличивание» — это «псевдонимизация».

3. Псевдонимизированные данные считаются персональными данными, составляют объект регулирования законодательства о защите персональных данных и требуют соответствующей защиты. Псевдонимизация не делает данные анонимными, но может рассматриваться в качестве одной из мер защиты данных, которая должна применяться в совокупности с другими.

4. Понятие «анонимизированные данные» не соответствует российскому понятию «обезличенные данные» и не имеет прямого аналога в отечественном законодательстве.

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

6. Анонимность данных является динамичной категорией и определяется каждый раз в конкретном случае с учетом контекста, характера данных, целей обработки, доступных технологий и ресурсов, потенциальных рисков и т.д. Данные могут перестать быть анонимными со временем, перейдя в категорию псевдонимизированных. Утвержденного перечня методов анонимизации также не существует. Конкретные используемые методы также подлежат оценке. Для проведения соответствующей оценки существуют различные критерии и тесты, описания методов и примеров.

7. Оценка должна проводиться периодически с учетом изменения контекста, круга доступной информации, развития технологий и их доступности.

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

— устойчивость к логическим атакам.

10. Обязанность оценки лежит на контролёре данных. В случае утечки, иного нарушения, жалобы субъекта персональных данных, возникновения спорной ситуации, контролер должен быть способен доказать факт проведения оценки и ее качество. Национальные надзорные органы имеют возможность проверить такую оценку и ее качество.

11. Проблематика, связанная с анонимизацией и псевдонимизацией данных решается на основе гибких критериев и балансировочных тестов. Это является общей чертой правового регулирования защиты данных в европейских юрисдикциях. Ключевым элементом данной системы, обеспечивающим ее функционирование, являются сильные и независимые надзорные органы.

[20] Agencia Española Protección de Dados – Испанский надзорный орган по защите персональных данных.

Источник