что значит обезличить в е услугах
Обезличивание персональных данных
Одним из действий, которые входят в понятие обработки, является обезличивание персональных данных. На это прямо указывает статья 3 Закона о персональных данных от 27.07.2006 г. № 152-ФЗ. Поэтому все принципы и правила обработки персональных данных напрямую действуют и при их обезличивании. Что это такое и как применять процедуру? Об этом мы расскажем ниже, а дополнительные вопросы можно задать дежурному юристу сайта.
Что такое обезличивание персональных данных
Категории персональных данных свидетельствуют, что такими данными являются не только сведения, которые непосредственно связаны с человеком. Но и относящиеся к нему косвенно. Закон во многих случаях требует получать согласие на обработку персональных данных. Процедура обезличивания — одна из мер защиты персональных данных.
Согласно ст. 3 Закона, обезличивание персональных данных — действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных. Проще говоря, сокрытие конкретных сведений принадлежности к субъекту. Ключ к обезличенным данным может получить ограниченное количество людей, имеющих доступ к персональным данным. Например, на своих официальных сайтах суд размещает вынесенные решения. В идеале Вы не найдете в открытых источниках фамилии, имена, отчества истцов, свидетелей, ответчика. Это и есть обезличивание. Без дополнительной информации получить информацию, к кому относится данный документ, невозможно.
По общему правилу по достижении целей обработки персональных данных, они подлежат удалению или обезличиванию. Таким образом, это действие является одним из этапов завершения процедуры работы с персональными данными.
Кстати, обработка информации в исследовательских, статистических целях допускается без получения согласия субъекта только при условии обезличивания.
Законодательное регулирование процедуры
Помимо Закон о персональных данных, есть ряд подзаконных нормативных правовых актов. Во-первых, это постановление Правительства РФ от 21.03.2012 г. № 211. Его применяют органы государственной власти и муниципальные органы. Постановление предусматривает разработку локальных актов (правила работы с обезличенными данными, перечень должностей, ответственных за обезличивание.
Основным, конечно, является приказ Роскомнадзора от 05.09.2013 г. № 966, который регламентирует требования и методы по обезличиванию персональных данных. Они касаются данных, которые обрабатываются в информационных системах, в т.ч. в рамках реализации федеральных программ.
Если какой-то орган пользуется Единой информационной базой, то есть и установленный порядок обезличивания сведений. Например, в сфере здравоохранения действует приказ Минздрава от 14.06.2018 г. № 341н.
Не всякое сокрытие составляющих персональных данных Роскомнадзор (а он надзирает в этой сфере) станет обезличиванием. Основным свойством обезличенной информации является анонимность: без дополнительной информации нельзя соотнести обезличенную к субъекту персональных данных.
Роскомнадзор рекомендует такие методы обезличивания информации, как ввод идентификатора (часть сведений заменяется какой-то меткой), изменение состава или семантики слов и т.п.
Для чего нужно обезличивание данных частным компаниям
Компании обезличить данные может помочь, когда хранение данных невозможно организовать правильно. Например, не хочется хранить информацию в информационных системах иных операторов, прошедших государственную экспертизу. А обезличивание позволит хранить данные. А значит, и сократить собственные расходы.
Руководителю организации при обезличивании персональных данных рекомендуем придерживаться политики правильного кадрового обеспечения — прописать соответствующие методы и способы в положении о персональных данных, ограничить допуск и т.п.
Обезличенные данные приравняют к персональным
О подписании документа главой ведомства перед внесением законопроекта в правительство заявил замминистра цифрового развития Олег Иванов на заседании рабочей группы по совершенствованию законодательства в сфере персональных данных и доступности цифровых технологий.
Законопроект регламентирует политику обработки обезличенных данных. Например, теперь оператор не сможет использовать какую-либо дополнительную информацию, которая помогает определить принадлежность персональных данных конкретному субъекту. Также будет запрещено в дополнение к обезличенным данным передавать третьим лицам информацию, которая позволит идентифицировать конкретного человека. Под запретом окажется деобезличивание данных, за исключением тех случаев, когда необходимо защитить жизнь или здоровье человека.
По словам Иванова, новые требования к обращению обезличенной информации вызваны тем, что уже сейчас доступны технологии, позволяющие деобезличивать данные и определять по ним конкретного человека: «Обезличивание и анонимизация – разные понятия. Деобезличивание – обратимая вещь».
Использовать обезличенные персональные данные без согласия можно будет только в исследовательских и статистических целях, уточнили в Минцифре.
Участники рабочей группы считают, что законопроект в текущей редакции задачу не решает, а наоборот – приводит к ужесточению правового режима и не создает дополнительных возможностей для обработки обезличенных данных, которые широко используются бизнесом. В частности, для таргетирования рекламы.
«При передаче обезличенного массива данных третьему лицу обработка этих данных в иных целях, кроме тех, для которых данные собирались, невозможна, так как требует нового согласия гражданина, но обратиться за ним невозможно, так как данные обезличены», – объясняет представитель пресс-службы АНО «Цифровая экономика» Екатерина Батманова. По ее словам, законопроект содержит избыточные требования к идентификации субъекта персональных данных: прежняя его версия предусматривала возможность получить согласие на обработку персональных данных без указания ФИО (используя электронную почту или телефонный номер), а нынешняя предполагает, что пользователь должен указать ФИО для получения тех или иных услуг.
«При принятии этих требований граждане не станут пользоваться, к примеру, российскими сервисами знакомств, так как не захотят там вводить ФИО. В итоге поправки в закон не усилят защиту, а наоборот – приведут к перетоку данных наших граждан за рубеж», – говорит Батманова.
В мировой практике применяются различные методы обезличивания данных и их сочетания, позволяющие надежно обезопасить информацию, отмечает президент Ассоциации больших данных Анна Серебряникова: «Уровень обезличенности оценивают по специальной модели – исходя из риска повторного установления личности: если по данным можно установить их владельца, таким методам обезличивания присваивается низкий коэффициент – от 0 до 0,4. Если после обезличивания установить владельца данных невозможно без существенных усилий, то коэффициент будет выше – от 0,5 до 0,8». Если же установить личность субъекта персональных данных можно только с помощью крайне трудоемких и дорогих процедур, тогда данные признаются обезличенными, а методы, с помощью которых их «очистили» от персональных, получают коэффициент от 0,8 до 1 – максимальной оценки степени обезличивания, добавляет Серебряникова.
Законопроектом предлагается внести в федеральное законодательство изменения, которые в значительной степени устраняют разницу в правоотношениях, возникающих при сборе, обработке и использовании персональных и обезличенных данных, отмечает управляющий партнер юридической фирмы Enterprise Legal Solutions Юрий Федюкин. «Приравнивание обезличенных данных к персональным значит, что по отношению к обезличенным оператор обязан будет принимать все меры по их защите, что и для обычных персональных данных», – соглашается ведущий эксперт направления «Информационная безопасность» IT-компании КРОК Анастасия Федорова.
Для бизнеса приравнивание обезличенных данных к персональным означает возникновение новых оснований для привлечения его к ответственности в связи с нарушением законодательства, регулирующего правоотношения в области их сбора, хранения, обработки и распространения, предупреждает Федюкин: «Формально это значит, что любая попытка использования обезличенных данных, т. е. массива, содержащего в себе сведения о множестве субъектов, в случае если хотя бы один из них не дал разрешения на использования их для какой-то совершенно конкретной цели или отозвал свое разрешение, может привести к нарушению закона и штрафным санкциям». Все это максимально утяжелит работу большинства компаний, работа которых так или иначе связана с большими данными, а также государственных учреждений, заключает Федюкин.
Конструкция с получением согласия на обезличивание нерабочая и приведет к приостановке множества проектов, связанных с обработкой больших данных: непонятно, зачем создавать дополнительный искусственный барьер, если при получении самих персональных данных согласие на их обработку уже получалось, рассуждает представитель «Вымпелкома» Анна Айбашева: «Предлагаемое регулирование существенно ограничит развитие цифровой экономики в России, внедрение новых сервисов и технологий, а также значительно затормозит переход на новый технологический уклад».
Обезличенные данные: как защитить граждан и стимулировать бизнес
Методов, которые полностью обезличивают данные и при этом сохраняют их ценность, на сегодняшний день не существует, отметила Татьяна Матвеева, начальник управления президента по применению информационных технологий и развитию электронной демократии. Все обезличенные данные, по словам спикера, могут быть вновь персонализированы.
Обезличивание – это метод снижения риска, но не полная гарантия защиты прав граждан.
Татьяна Матвеева, начальник управления президента по применению информационных технологий и развитию электронной демократии
С другой стороны, данные – это топливо для искусственного интеллекта и катализатор для развития экономики. Государство все это понимает и делает шаги навстречу бизнесу, заверила Матвеева. Сейчас активно обсуждается законопроект по регулированию обезличенных данных, запущен федеральный проект по искусственному интеллекту, который предусматривает введение экспериментальных правовых режимов.
«Но так или иначе все решения нужно принимать и оценивать через призму прав граждан», – подчеркнула спикер. С ней согласился замглавы Роскомнадзора Милош Вагнер: «При введении любого регулирования должны не ухудшаться, а улучшаться права граждан».
«Обезличенные» равно «персональные»?
Персональные данные, полученные в результате обезличивания, – это все равно персональные данные. К ним должно применяться соответствующее законодательство, пояснил Вагнер позицию Роскомнадзора.
С такой интерпретацией поспорил бизнес. «По закону персональные данные – это данные, которые позволяют определить конкретную личность. Обезличивание – это отрыв данных от личности», – заявил Руслан Ибрагимов, вице-президент по взаимодействию с органами госвласти и связям с общественностью ПАО «МТС».
По его словам, обезличенные данные – отдельный вид информации, которую можно пустить в оборот. Если кто-то решил «де-обезличить» такие сведения, они становятся персональными и на них распространяется соответствующее регулирование.
Нам нужно определиться с понятиями. Как только мы достигнем консенсуса в этом, все остальные вопросы будут решаться автоматически.
Руслан Ибрагимов, вице-президент ПАО «МТС»
Обезличенность и свободный оборот
Степень обезличивания данных может быть разная. Ирина Левова из АНО «Институт исследований интернета» представила схему, на которой показала, как в зарубежных странах свобода обращения зависит от уровня обезличивания.
Существуют специальные коэффициенты: 0 – это персональные данные, 1 – полностью анонимизированные. Компания сама оценивает степень обезличивания в каждом конкретном случае, исходя из используемых методов. Чем больше мер она использует, тем меньше вероятность повторной идентификации и тем выше коэффициент обезличивания, пояснила Левова.
Если он равен 0,7 – 0,8, зарубежные регуляторы не признают данные персональными и разрешают более свободное обращение. По словам спикера, они уже несколько месяцев работают над математическим обоснованием рисков применения тех или иных методов. «Надеюсь, мы сможем апробировать полученные результаты в рамках экспериментальных режимов, а потом уже вернуться к разработке законодательных поправок», – поделилась Левова.
Хорошо, конечно, апробировать методики в различных «песочницах», ждать реализации пилотов. Но не займет ли это годы? А ведь все это время бизнес по-прежнему будет трать свои ресурсы на преодоление непрозрачных и непонятных правил работы с обезличенными данными.
Анна Попова, вице-президент ПАО «Сбербанк»
В завершении своего выступления Попова перечислила основные запросы, которые сейчас есть у бизнеса:
Обезл***вание д***ных — это не просто рандомизация
В банке есть проблема: нужно давать доступ к базе данных разработчикам и тестировщикам. Есть куча клиентских данных, которые по PCI DSS требованиям Центробанка и законам о персональных данных вообще нельзя использовать для раскрытия на отделы разработки и тестирования.
Казалось бы, достаточно просто поменять всё на какие-нибудь несимметричные хеши, и всё будет хорошо.
Дело в том, что база данных банка — это множество связанных между собой таблиц. Где-то они связаны по ФИО и номеру счёта клиента. Где-то по его уникальному идентификатору. Где-то (тут начинается боль) через хранимую процедуру, которая вычисляет сквозной идентификатор на основе этой и соседней таблицы. И так далее.
Обычная ситуация, что разработчик первой версии системы уже десять лет как умер или уехал, а системы ядра, запущенные в старом гипервизоре внутри нового гипервизора (чтобы обеспечить совместимость) ещё в проде.
То есть прежде чем всё это обезличить, сначала надо разобраться в базе данных.
Кто делает обезличивание и зачем?
Обезличиванием или маскированием занимаются потому, что есть законы и стандарты. Да, гораздо лучше тестировать на «снапшоте прода», но за такой залёт регуляторы могут и отозвать лицензию. То есть прикрыть бизнес как таковой.
Любое обезличивание — это достаточно дорогая и неповоротливая прослойка между продуктивными системами и тестированием с разработкой.
Цель проектов по обезличиванию (маскированию) практически всегда — подготовить данные для тестирования, максимально похожие на реальные, хранящиеся в продуктивных базах. То есть если данные содержат ошибки — вместо email забит телефон, вместо кириллицы в фамилии латиница и т. п., то и замаскированные данные должны быть такого же качества, но изменёнными до неузнаваемости. Вторая цель — уменьшение объёма баз данных, которые используются в тестировании и разработке. Полный объём оставляют только под нагрузочное тестирование, а под остальные задачи обычно делается некий срез данных по заранее определённым правилам — усечение БД. Третья цель — получить связанные между собой данные в разных замаскированных и усечённых базах. Имеется в виду, что данные в разных системах, в разное время, должны быть обезличены единообразно.
По вычислительной сложности обезличивание — это примерно как несколько архивирований базы данных на предельной компрессии. Алгоритм примерно похож. Разница в том, что алгоритмы архивирования оттачивались годами и дошли до почти максимального КПД. А алгоритмы обезличивания пишут так, чтобы они хотя бы работали на текущей базе и были достаточно универсальными. И софт после обезличивания вообще заработал. То есть отличный результат — перемолоть 40 ТБ за ночь. Бывает так, что заказчику дешевле загонять в обезличивание базу раз в полгода на неделю на слабеньком сервере — тоже подход.
Как заменяются данные?
Каждый тип данных меняется в соответствии с правилами, которые могут использоваться в коде. Например, если мы заменим ФИО на случайный хеш со спецсимволами и цифрами, то первая же проверка корректности данных сразу выдаст ошибку в реальном тестировании.
Поэтому сначала система обезличивания должна определить, что за тип данных хранится в поле. В зависимости от вендора используются разные подходы от ручной разметки до попыток дискаверинга базы и автоопределения, что же там хранится. У нас есть практика внедрения всех основных решений на рынке. Разберём один из вариантов, когда есть визард, который пытается найти данные и «угадать», что там за тип данных хранится.
Естественно, для работы с этим софтом нужен допуск к реальным данным (обычно это копия недавнего бекапа БД). По банковскому опыту мы сначала два месяца подписываем тонну бумаг, а потом приезжаем в банк, нас раздевают, обыскивают и одевают, потом мы идём в отдельное обшитое клеткой Фарадея помещение, в котором стоят двое безопасников и тепло дышат нам в затылок.
Итак, предположим, после всего этого мы видим таблицу, в которой есть поле «ФИО». Визард уже за нас его разметил как ФИО, и нам остаётся только подтвердить и выбрать тип обезличивания. Визард предлагает случайную замену на славянские имена (есть базы для разных регионов). Мы соглашаемся и получаем замены вроде Иван Иванов Петренко — Иосиф Альбертович Чингачгук. Если это важно, сохраняется пол, если нет — замены идут по всей базе имён.
Следующее поле — дата в юникстайме. Визард это тоже определил, а нам надо выбрать функцию обезличивания. Обычно даты используются для контроля последовательности событий, и ситуации, когда клиент сначала сделал перевод в банке, а потом открыл счёт, никому особо не нужны на тестировании. Поэтому мы задаём небольшую дельту — по умолчанию в пределах 30 дней. Ошибки всё равно будут, но если это критично, можно настроить более сложные правила, дописав свой скрипт в обработку обезличивания.
Адрес должен валидироваться, поэтому используется база российских адресов. Номер карточки должен соответствовать реальным номерам и валидироваться по ним. Иногда бывает задача «сделать все Визы случайными Мастеркардами» — это тоже выполнимо в пару кликов.
Под капотом визарда находится профилирование. Профилирование — это поиск данных в БД по заранее заданным правилам (атрибутам, доменам). Фактически мы читаем каждую ячейку базы данных заказчика, применяем к каждой ячейке набор регулярных выражений, сравниваем значения в этой ячейке со словарями и т. д. В результате чего имеем набор сработавших правил на столбцах таблиц базы данных. Профилирование мы можем настраивать, можем читать не все таблицы в БД, можем брать только определённое количество строк из таблицы или определённый процент строк.
Что происходит внутри?
К каждой записи в базе применяются правила обезличивания, которые мы выбрали. При этом на время работы процесса создаются временные таблицы, куда записываются замены. Каждая последующая запись в БД прогоняется по этим таблицам соответствия замен, и если там есть соответствие — заменяется так же, как раньше. Всё на деле чуть сложнее в зависимости от ваших скриптов и правил сопоставления паттернов (может быть неточная замена, например для родов или замен дат, хранимых в разном формате), но общая идея такова.
Если есть размеченные соответствия «имя кириллицей — имя латиницей», то они должны быть явно обозначены на этапе разработки, и тогда в таблице замен они будут соответствовать друг другу. То есть имя кириллицей будет обезличено, а потом эта обезличенная запись будет сконвертирована в латиницу, например. В этом моменте мы отходим от подхода «не улучшать качество данных в системе», но это один из компромиссов на которые приходится идти ради какой-никакой, но производительности системы. Практика показывает, что если нагрузочное, функциональное тестирование в своей работе не замечает компромисса, то ничего не было. И тут всплывает важный момент, что обезличивание в целом это не шифрование. Если у вас пару ярдов записей в таблице, а в десятке из них ИНН не изменился, то что? То ничего, этот десяток записей не найти.
После окончания процесса таблицы перекодировки остаются в защищённой базе сервера обезличивания. База нарезается (усекается) и передается в тестирование без таблиц перекодировки, таким образом, для тестировщика обезличивание становится необратимым.
Полная обезличенная база передаётся тестировщикам для нагрузочного тестирования.
Это значит, что во время работы с БД таблица перекодировки «пухнет» (точный объём зависит от выбора замен и их типа), но рабочая база остаётся исходного размера.
Как примерно выглядит процесс в интерфейсе оператора?
Общий вид IDE на примере одного из вендоров:
Запуск трансформации из IDE:
Настройка выражения для поиска чувствительных данных в профилировщике:
Страница с набором правил для профилировщика:
Результат работы профилировщика, веб-страница с поиском по данным:
Все ли данные в базе маскируются?
Нет. Обычно список данных под обезличивание регулируется законами и стандартами сферы, плюс у заказчика есть пожелания по конкретным полям, про которые не должен знать никто.
Логика в том, что если мы замаскировали ФИО пациента в больнице, можно маскировать или не маскировать диагноз — всё равно никто не узнает, от кого он. У нас был случай, когда примечания к операции в банке просто маскировали случайными буквами. Там были заметки уровня: «В кредите отказано, так как клиент пришёл пьяным, его вырвало на стойку». С точки зрения отладки это просто строка символов. Ну вот пусть ей и остаётся.
Динамическая seed-таблица это таблица перекодировки в которую складываем уже случившиеся перекодировки. Хеш может быть сильно разный и в случае того же ИНН, чаще генерируется новый случайный ИНН с сохранением первых символов, с контрольными цифрами.
Можно ли менять данные средствами самой СУБД?
Да. При обезличивании данных есть два основных подхода — изменять данные в БД средствами самой БД либо организовать ETL-процесс и менять данные посредством стороннего софта.
Ключевой плюс первого подхода — данные не надо никуда из базы выносить, нет затрат на сеть, используются быстрые и оптимизированные средства БД. Ключевой минус — отдельная разработка под каждую систему, отсутствие общих таблиц перекодировки для разных систем. Таблицы перекодировки нужны для воспроизводимости обезличивания, дальнейшей интеграции данных между системами.
Ключевой плюс второго подхода — неважно, какая у вас БД, система, файл это или какой-то веб-интерфейс, — один раз реализовав какое-то правило, вы можете использовать его везде. Ключевой минус — надо читать данные из базы, обрабатывать их отдельным приложением, записывать в базу обратно.
Практика показывает, что если у заказчика есть набор из нескольких систем, которые требуют дальнейшей интеграции, то реализуемым за конечную стоимость в деньгах, а также за приемлемые сроки разработки может быть только второй подход.
То есть сделать можем всё, что угодно, но в банковском секторе очень хорошо зарекомендовал себя именно ETL-подход.
А почему данные просто не портят вручную?
Один раз так можно сделать. Кто-то просидит три дня, обезличит кучу данных и подготовит базу данных на 500-1000 записей. Сложность в том, что процесс надо повторять регулярно (с каждым изменением структуры БД и появлением новых полей и таблиц) и на больших объёмах (для разных видов тестирования). Обычный запрос — обезличить первые 10-50 ГБ базы так, чтобы этот объём пришёлся на каждую таблицу равномерно.
Что делать, если в базе хранятся сканы документов?
Если документ можно свести к XML и конвертировать обратно (это, например, документы офиса), — можно провести и обезличивание в них. Но иногда бывают бинарники вроде сканов паспортов в PDF/JPG/TIFF/BMP. В этом случае общепринятая практика — нагенерить сторонним скриптом похожих документов и подменять реальные на образцы из базы нагенерённых случайным образом. Сложнее всего с фотографиями, но есть сервисы вроде этого, которые примерно похожим образом решают вопрос.
Кто за что отвечает?
При обновлении после изменения ПО или «вдогонку» процессы попроще.
А что, если на тестах что-то пойдёт не так?
Обычно так и случается. Во-первых, тестировщики после первого прогона обезличивания точнее формулируют требования к базе. Мы можем поменять правила обезличивания или отбраковывать записи вроде «вот тут действия должны идти в хронологическом порядке, а не в хаотичном». Во-вторых, в зависимости от внедрения мы или поддерживаем обезличивание по мере изменения базы, либо оставляем всю документацию, описания структуры БД и типов обработки, передаём весь код обработки (правила в xml/sql) и обучаем специалистов у заказчика.