Что такое деперсонализация персональных данных
Обезличивание данных: сохранение баланса между правами граждан и развитием инноваций
 |
| waider.list.ru / Depositphotos.com |
Повсеместное использование информационных технологий поднимает вопросы, возникающие в связи с обработкой персональных прав граждан. Особенно остро встает проблема защиты персональных данных при их обработке государством или частными компаниями, в том числе с помощью технологий искусственного интеллекта. Напомним, что персональные данные – это любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (ч. 1 ст. 3 Федерального закона от 27 июля 2006 № 152-ФЗ «О персональных данных», далее – Закон № 152-ФЗ). Одним из методов решения проблемы защиты данных является процедура их обезличивания. В соответствии с законом обезличивание персональных данных представляют собой действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных (ч. 9 ст. 3 Закона № 152-ФЗ). Как на практике выполняется процедура обезличивания, действительно ли она может обеспечить защиту персональных данных и как соблюдается баланс между интересами граждан, государства и компаний – в нашем материале.
В ходе пленарного заседания, организованного в рамках Петербургского Международного Юридического Форума 9 3/4, информационным партнером которого является компания «Гарант», президент Ассоциации участников рынка больших данных Анна Серебряникова обратила внимание на то, что сейчас тема обезличивания данных в первую очередь должна рассматриваться как механизм защиты прав граждан, а уже после этого – как стимулирование развития бизнес-сектора. Важность темы понимается и на федеральном уровне – государство демонстрирует разнообразие обсуждаемых и принимаемых инициатив по вопросу оборота данных при использовании информационных технологий, например, для развития технологии искусственного интеллекта. В настоящее время процедура обезличивания данных активно применяется, при этом эксперт считает, что ее нужно отрегулировать таким образом, чтобы, с одной стороны, не остановить технический прогресс, с другой – защитить граждан от деобезличивания.
В ходе обсуждения Татьяна Матвеева, начальник управления президента РФ по применению информационных технологий и развития электронной демократии, отметила, что на сегодняшний день метода, который мог бы полностью обезличить данные с сохранением ценности таких данных, не существует. Связано это с тем, что текущий уровень развития информационных технологий при сборе нескольких наборов данных (в том числе, обезличенных) и при последующей математической обработке могут быть опять персонализированы. Таким образом, обезличивание персональных данных выступает методом снижения рисков нарушения прав граждан при обработке персональных данных, например, при их утечке. Но гарантии полной защиты прав граждан не происходит, подчеркивает эксперт.
Напомним, что в РФ процедура по обезличиванию персональных данных регламентирована Приказом Роскомнадзора от 5 сентября 2013 г. № 996 «Об утверждении требований и методов по обезличиванию персональных данных». Так, в соответствии с Приказом, к наиболее перспективным и удобным для практического применения относятся следующие методы обезличивания:
Также запущен Федеральный проект «Искусственный интеллект», разработанный Минэкономразвития России в целях реализации Национальной стратегии развития искусственного интеллекта на период до 2030 года (утв.Указом Президента Российской Федерации от 10 октября 2019 г. № 490), который уточняет условия использования данных в рамках экспериментальных правовых режимов (ЭПР), так называемых регуляторных песочниц. Подробнее об ЭПР читайте в нашем материале: «Проблемы защиты персональных данных в рамках экспериментальных правовых режимов». Заместитель руководителя Роскомнадзора Милош Вагнер отметил, что введение таких режимов является результатом ответа на запрос бизнеса о желании воспользоваться данными – такие режимы позволяют с учетом послаблений апробировать методики обезличивания.
Важно обратить внимание, что есть различие между обезличенными и анонимизированными данными. Как объясняет Анна Серебряникова, полностью анонимизированные данные представляют собой статистику, которая доступна в свободном доступе и относится к открытым данным. Аналогичной позиции придерживается Татьяна Матвеева, приводя в пример таких данных статистику Росстата и соцопросы – такие данные являются «загрубленными» с точки зрения социально-демографического портрета опрашиваемой аудитории. По мнению Анны Серебряниковой, такие данные не несут той же ценности, как обезличенные, на основании которых можно определить некоторые особенности разных видов социальных групп. Эксперт приводит в пример анализ поведенческих особенностей малых социальных групп, прогнозирование возрастных трендов, измерение настроения людей и определение их отношения к тем или иным явлениям – все эти функции на основании анонимизированных данных невозможны. Другими словами, полностью анонимизированные данные не представляют ценности для бизнеса, а для некоторых областей искусственного интеллекта даже обезличенные данные не представляют ценности – для его обучения требуется опыт, а если такой опыт с пробелами, его обучение будет соответственным, объяснила Анна Серебряникова.
Руслан Ибрагимов, вице-президент по взаимодействию с органами государственной власти и связям с общественностью ПАО «МТС» считает, что основная проблема, связанная с обезличиванием персональных данных, – расхождение в определении того, что представляют собой такие данные. Государственные органы не видят разницы между персональными и обезличенными данными, что создает ряд юридических проблем. На практике такой подход может ужесточать оборот обезличенных персональных данных. При подходе, согласно которому такие данные являются отдельной частью персональных данных, такие данные могут быть свободно пущены в оборот. Эксперт считает, что следует достичь консенсуса при решении вопроса о том, какой из этих подходов должен быть использован в отношении обезличивания персональных данных.
Анна Серебряникова считает, что для обучения искусственного интеллекта нужны более широкие дата-сеты, включающие такие данные, которые будут соблюдать баланс – с одной стороны, не нарушать права субъектов персональных данных, с другой – предоставлять для бизнеса максимально полные данные для развития технологий. Обработка персональных данных в любом случае сопряжена с потенциальными рисками для субъектов, при этом такие риски могут возникать не только рамках исполнения бизнес-задач, но и при других неправомерных действиях, резюмировала Татьяна Матвеева. В связи с этим решения по условиям обработки и обезличиванию данных следует принимать и оценивать через призму защиты прав граждан. Помимо нормативного государственного регулирования разработка отраслевых стандартов и кодексов по работе с обезличенными данными позволит повысить внутреннюю цифровую культуру компаний, работающих с данными, а также увеличить уровень доверия граждан, заключила эксперт. С коллегой согласился Милош Вагнер – регулирование должно осуществляться как со стороны надзорного органа (в соответствии со ст. 23 Закона № 152-ФЗ), так и со стороны операторов (в соответствии со ст. 18.1 Закона № 152-ФЗ), то есть должен присутствовать также внутренний контроль за соблюдением положений законодательства, считает эксперт.
1 С текстом законопроекта № 992331-7 О внесении изменений в Федеральный закон «О персональных данных» (в части уточнения порядка обработки персональных данных) и материалами к нему можно ознакомиться на официальном сайте Госдумы.
Обезличенные данные и цифровая медицина
В настоящее время можно наблюдать развитие сервисов цифровой медицины, которые используются для анализа результатов обследований на основе большого массива имеющихся данных. К примеру, уже разработаны и активно используются программы, сравнивающие рентгенограммы патологий и рентгенограммы обследуемых пациентов, и отмечающие возможные места патологий на изучаемом снимке. Данные инструменты помогают медицинским работникам быстрее обрабатывать результаты исследований и ставить диагнозы. Преимущества подобных технологий очевидны, но для их работы требуется большой объём персональных данных, что налагает на их работу ряд законных ограничений.
Ключевым вопросом при определении режима использования обезличенных данных о результатах медицинский исследований является их возможная квалификация в качестве персональных. Для прояснения данного вопроса необходимо определить, возможно ли отнести такие данные к определённому или определяемому лицу (п.1 ст.3 ФЗ «О персональных данных»). П.9 ст.3 ФЗ «О персональных данных» гласит, что обезличиванием являются «действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных». Таким образом, в результате обезличивания персональные данные нельзя будет отнести к определённому лицу, но можно будет отнести к определяемому лицу путём использования дополнительной информации. Следовательно, рассматриваемые данные допустимо относить к персональным, если речь идёт именно об обезличивании.
Необходимо помнить, что определение «уничтожения» персональных данных (п.8 ст.3 ФЗ «О персональных данных») подразумевает совершение таких действий, в результате которых становится невозможным восстановить содержание персональных данных в информационной системе персональных данных и (или) в результате которых уничтожаются материальные носители персональных данных. Следовательно, ключевым различием между обезличиванием и уничтожением является возможность восстановления данных до состояния персональных. И в рамках разных информационных систем одни и те же данные могут иметь возможность восстановления, так и не иметь.
Например, при снятии рентгенограммы медицинское учреждение может использовать на снимках пометки, содержащие имя и иные идентификаторы пациента, в результате чего данные снимков можно будет признать персональными. Но если медицинское учреждение передаст такие данные третьему лицу – оператору цифрового медицинского сервиса, в информационной системе последнего такие данные не будут являться персональными. В случае же, если в рамках своей же информационной системы медицинское учреждение безвозвратно уничтожит части снимков, содержащие идентифицирующие пометки, то такие данные перестанут быть персональными в результате уничтожения и без передачи третьему лицу. И в случае, если из рентгенограммы будет удалено имя пациента, но останется номер медицинской карты, такая операция будет считаться обезличиванием, поскольку определить субъекта персональных данных можно будет, сопоставив номер карты на снимке и номер карты в картотеке.
Таким образом, при использовании данных медицинских исследований оператор цифрового медицинского сервиса должен убедиться в отсутствии возможности их восстановления – в противном случае на процессы обработки данных будут распространяться ограничения, связанные с их персональным характером. И в этом случае необходимо исходить из того, к какой категории будут относиться персональные данные медицинских исследований.
Специальными персональными данным (ч.1 ст.10 ФЗ «О персональных данных») являются данные, касающиеся расовой, национальной принадлежности, политических взглядов, религиозных или философских убеждений, состояния здоровья, интимной жизни. Не вызывает сомнений, что данные медицинских исследований можно отнести к специальным в случае их квалификации в качестве персональных. В качестве допустимых оснований обработки в рассматриваемых обстоятельствах можно назвать следующие (ч.2 ст.10 ФЗ «О персональных данных»):
— наличие письменного согласия – для оператора цифрового медицинского сервиса получение письменных согласий является затруднительным, но возможным, если получение согласий будет поручено медицинскому учреждению;
— осуществление обработки в медико-профилактических целях, в целях установления медицинского диагноза, оказания медицинских и медико-социальных услуг при условии, что обработка персональных данных осуществляется лицом, профессионально занимающимся медицинской деятельностью и обязанным в соответствии с законодательством Российской Федерации сохранять врачебную тайну – в данном случае не ясно, относится ли это основание исключительно к субъекту персональных данных или также к третьим лицами (например, в случае использования снимков других пациентов для установления диагноза иному пациенту), и, кроме того, данное основание подразумевает необходимость наличия лицензии на медицинскую деятельность, что, впрочем, не является абсолютным препятствием для оператора цифрового медицинского сервиса;
— необходимость обработки данных для защиты жизни, здоровья или иных жизненно важных интересов субъекта персональных данных либо жизни, здоровья или иных жизненно важных интересов других лиц в условиях невозможности получения согласия субъекта персональных данных – данное основание может быть применимо, но с оговоркой, что обработка персональных данных в информационной системе цифрового медицинского сервиса хотя и является полезной, но может не являться необходимой, а то обстоятельство, что получение согласия субъекта невозможно, подлежит доказыванию.
Независимо от квалификации данных медицинских исследований в качестве персональных необходимо также затронуть и аспект врачебной тайны. Согласно ч.1 ст.13 ФЗ «Об основах охраны здоровья граждан в Российской Федерации» врачебной тайной являются сведения о факте обращения гражданина за оказанием медицинской помощи, состоянии его здоровья и диагнозе, иные сведения, полученные при его медицинском обследовании и лечении. Поскольку даже в случае отсутствия возможности восстановления данных исследования до уровня персональных, такие данные по-прежнему будут относиться к иным сведениями, полученным при медицинском обследовании или лечении, а, следовательно, к врачебной тайне.
Ч.3 ст.13 ФЗ «Об основах охраны здоровья граждан в Российской Федерации» допускает передачу сведений, содержащих врачебную тайну, с письменного согласия гражданина или его законного представителя в целях медицинского обследования и лечения пациента, проведения научных исследований, их опубликования в научных изданиях, использования в учебном процессе и в иных целях. При этом п.8 ч.4 ст.13 ФЗ «Об основах охраны здоровья граждан в Российской Федерации» допускает передачу данных в медицинскую организацию и без письменного согласия. Таким образом, оператор цифрового медицинского сервиса будет вынужден либо получать соответствующую лицензию, либо получать письменные согласия от пациентов, что наравне с получением письменного согласия на обработку персональных данных целесообразнее поручить медицинскому учреждению, непосредственно проводящему обследование.
Обезл***вание д***ных — это не просто рандомизация
В банке есть проблема: нужно давать доступ к базе данных разработчикам и тестировщикам. Есть куча клиентских данных, которые по PCI DSS требованиям Центробанка и законам о персональных данных вообще нельзя использовать для раскрытия на отделы разработки и тестирования.
Казалось бы, достаточно просто поменять всё на какие-нибудь несимметричные хеши, и всё будет хорошо.
Дело в том, что база данных банка — это множество связанных между собой таблиц. Где-то они связаны по ФИО и номеру счёта клиента. Где-то по его уникальному идентификатору. Где-то (тут начинается боль) через хранимую процедуру, которая вычисляет сквозной идентификатор на основе этой и соседней таблицы. И так далее.
Обычная ситуация, что разработчик первой версии системы уже десять лет как умер или уехал, а системы ядра, запущенные в старом гипервизоре внутри нового гипервизора (чтобы обеспечить совместимость) ещё в проде.
То есть прежде чем всё это обезличить, сначала надо разобраться в базе данных.
Кто делает обезличивание и зачем?
Обезличиванием или маскированием занимаются потому, что есть законы и стандарты. Да, гораздо лучше тестировать на «снапшоте прода», но за такой залёт регуляторы могут и отозвать лицензию. То есть прикрыть бизнес как таковой.
Любое обезличивание — это достаточно дорогая и неповоротливая прослойка между продуктивными системами и тестированием с разработкой.
Цель проектов по обезличиванию (маскированию) практически всегда — подготовить данные для тестирования, максимально похожие на реальные, хранящиеся в продуктивных базах. То есть если данные содержат ошибки — вместо email забит телефон, вместо кириллицы в фамилии латиница и т. п., то и замаскированные данные должны быть такого же качества, но изменёнными до неузнаваемости. Вторая цель — уменьшение объёма баз данных, которые используются в тестировании и разработке. Полный объём оставляют только под нагрузочное тестирование, а под остальные задачи обычно делается некий срез данных по заранее определённым правилам — усечение БД. Третья цель — получить связанные между собой данные в разных замаскированных и усечённых базах. Имеется в виду, что данные в разных системах, в разное время, должны быть обезличены единообразно.
По вычислительной сложности обезличивание — это примерно как несколько архивирований базы данных на предельной компрессии. Алгоритм примерно похож. Разница в том, что алгоритмы архивирования оттачивались годами и дошли до почти максимального КПД. А алгоритмы обезличивания пишут так, чтобы они хотя бы работали на текущей базе и были достаточно универсальными. И софт после обезличивания вообще заработал. То есть отличный результат — перемолоть 40 ТБ за ночь. Бывает так, что заказчику дешевле загонять в обезличивание базу раз в полгода на неделю на слабеньком сервере — тоже подход.
Как заменяются данные?
Каждый тип данных меняется в соответствии с правилами, которые могут использоваться в коде. Например, если мы заменим ФИО на случайный хеш со спецсимволами и цифрами, то первая же проверка корректности данных сразу выдаст ошибку в реальном тестировании.
Поэтому сначала система обезличивания должна определить, что за тип данных хранится в поле. В зависимости от вендора используются разные подходы от ручной разметки до попыток дискаверинга базы и автоопределения, что же там хранится. У нас есть практика внедрения всех основных решений на рынке. Разберём один из вариантов, когда есть визард, который пытается найти данные и «угадать», что там за тип данных хранится.
Естественно, для работы с этим софтом нужен допуск к реальным данным (обычно это копия недавнего бекапа БД). По банковскому опыту мы сначала два месяца подписываем тонну бумаг, а потом приезжаем в банк, нас раздевают, обыскивают и одевают, потом мы идём в отдельное обшитое клеткой Фарадея помещение, в котором стоят двое безопасников и тепло дышат нам в затылок.
Итак, предположим, после всего этого мы видим таблицу, в которой есть поле «ФИО». Визард уже за нас его разметил как ФИО, и нам остаётся только подтвердить и выбрать тип обезличивания. Визард предлагает случайную замену на славянские имена (есть базы для разных регионов). Мы соглашаемся и получаем замены вроде Иван Иванов Петренко — Иосиф Альбертович Чингачгук. Если это важно, сохраняется пол, если нет — замены идут по всей базе имён.
Следующее поле — дата в юникстайме. Визард это тоже определил, а нам надо выбрать функцию обезличивания. Обычно даты используются для контроля последовательности событий, и ситуации, когда клиент сначала сделал перевод в банке, а потом открыл счёт, никому особо не нужны на тестировании. Поэтому мы задаём небольшую дельту — по умолчанию в пределах 30 дней. Ошибки всё равно будут, но если это критично, можно настроить более сложные правила, дописав свой скрипт в обработку обезличивания.
Адрес должен валидироваться, поэтому используется база российских адресов. Номер карточки должен соответствовать реальным номерам и валидироваться по ним. Иногда бывает задача «сделать все Визы случайными Мастеркардами» — это тоже выполнимо в пару кликов.
Под капотом визарда находится профилирование. Профилирование — это поиск данных в БД по заранее заданным правилам (атрибутам, доменам). Фактически мы читаем каждую ячейку базы данных заказчика, применяем к каждой ячейке набор регулярных выражений, сравниваем значения в этой ячейке со словарями и т. д. В результате чего имеем набор сработавших правил на столбцах таблиц базы данных. Профилирование мы можем настраивать, можем читать не все таблицы в БД, можем брать только определённое количество строк из таблицы или определённый процент строк.
Что происходит внутри?
К каждой записи в базе применяются правила обезличивания, которые мы выбрали. При этом на время работы процесса создаются временные таблицы, куда записываются замены. Каждая последующая запись в БД прогоняется по этим таблицам соответствия замен, и если там есть соответствие — заменяется так же, как раньше. Всё на деле чуть сложнее в зависимости от ваших скриптов и правил сопоставления паттернов (может быть неточная замена, например для родов или замен дат, хранимых в разном формате), но общая идея такова.
Если есть размеченные соответствия «имя кириллицей — имя латиницей», то они должны быть явно обозначены на этапе разработки, и тогда в таблице замен они будут соответствовать друг другу. То есть имя кириллицей будет обезличено, а потом эта обезличенная запись будет сконвертирована в латиницу, например. В этом моменте мы отходим от подхода «не улучшать качество данных в системе», но это один из компромиссов на которые приходится идти ради какой-никакой, но производительности системы. Практика показывает, что если нагрузочное, функциональное тестирование в своей работе не замечает компромисса, то ничего не было. И тут всплывает важный момент, что обезличивание в целом это не шифрование. Если у вас пару ярдов записей в таблице, а в десятке из них ИНН не изменился, то что? То ничего, этот десяток записей не найти.
После окончания процесса таблицы перекодировки остаются в защищённой базе сервера обезличивания. База нарезается (усекается) и передается в тестирование без таблиц перекодировки, таким образом, для тестировщика обезличивание становится необратимым.
Полная обезличенная база передаётся тестировщикам для нагрузочного тестирования.
Это значит, что во время работы с БД таблица перекодировки «пухнет» (точный объём зависит от выбора замен и их типа), но рабочая база остаётся исходного размера.
Как примерно выглядит процесс в интерфейсе оператора?
Общий вид IDE на примере одного из вендоров:
Запуск трансформации из IDE:
Настройка выражения для поиска чувствительных данных в профилировщике:
Страница с набором правил для профилировщика:
Результат работы профилировщика, веб-страница с поиском по данным:
Все ли данные в базе маскируются?
Нет. Обычно список данных под обезличивание регулируется законами и стандартами сферы, плюс у заказчика есть пожелания по конкретным полям, про которые не должен знать никто.
Логика в том, что если мы замаскировали ФИО пациента в больнице, можно маскировать или не маскировать диагноз — всё равно никто не узнает, от кого он. У нас был случай, когда примечания к операции в банке просто маскировали случайными буквами. Там были заметки уровня: «В кредите отказано, так как клиент пришёл пьяным, его вырвало на стойку». С точки зрения отладки это просто строка символов. Ну вот пусть ей и остаётся.
Динамическая seed-таблица это таблица перекодировки в которую складываем уже случившиеся перекодировки. Хеш может быть сильно разный и в случае того же ИНН, чаще генерируется новый случайный ИНН с сохранением первых символов, с контрольными цифрами.
Можно ли менять данные средствами самой СУБД?
Да. При обезличивании данных есть два основных подхода — изменять данные в БД средствами самой БД либо организовать ETL-процесс и менять данные посредством стороннего софта.
Ключевой плюс первого подхода — данные не надо никуда из базы выносить, нет затрат на сеть, используются быстрые и оптимизированные средства БД. Ключевой минус — отдельная разработка под каждую систему, отсутствие общих таблиц перекодировки для разных систем. Таблицы перекодировки нужны для воспроизводимости обезличивания, дальнейшей интеграции данных между системами.
Ключевой плюс второго подхода — неважно, какая у вас БД, система, файл это или какой-то веб-интерфейс, — один раз реализовав какое-то правило, вы можете использовать его везде. Ключевой минус — надо читать данные из базы, обрабатывать их отдельным приложением, записывать в базу обратно.
Практика показывает, что если у заказчика есть набор из нескольких систем, которые требуют дальнейшей интеграции, то реализуемым за конечную стоимость в деньгах, а также за приемлемые сроки разработки может быть только второй подход.
То есть сделать можем всё, что угодно, но в банковском секторе очень хорошо зарекомендовал себя именно ETL-подход.
А почему данные просто не портят вручную?
Один раз так можно сделать. Кто-то просидит три дня, обезличит кучу данных и подготовит базу данных на 500-1000 записей. Сложность в том, что процесс надо повторять регулярно (с каждым изменением структуры БД и появлением новых полей и таблиц) и на больших объёмах (для разных видов тестирования). Обычный запрос — обезличить первые 10-50 ГБ базы так, чтобы этот объём пришёлся на каждую таблицу равномерно.
Что делать, если в базе хранятся сканы документов?
Если документ можно свести к XML и конвертировать обратно (это, например, документы офиса), — можно провести и обезличивание в них. Но иногда бывают бинарники вроде сканов паспортов в PDF/JPG/TIFF/BMP. В этом случае общепринятая практика — нагенерить сторонним скриптом похожих документов и подменять реальные на образцы из базы нагенерённых случайным образом. Сложнее всего с фотографиями, но есть сервисы вроде этого, которые примерно похожим образом решают вопрос.
Кто за что отвечает?
При обновлении после изменения ПО или «вдогонку» процессы попроще.
А что, если на тестах что-то пойдёт не так?
Обычно так и случается. Во-первых, тестировщики после первого прогона обезличивания точнее формулируют требования к базе. Мы можем поменять правила обезличивания или отбраковывать записи вроде «вот тут действия должны идти в хронологическом порядке, а не в хаотичном». Во-вторых, в зависимости от внедрения мы или поддерживаем обезличивание по мере изменения базы, либо оставляем всю документацию, описания структуры БД и типов обработки, передаём весь код обработки (правила в xml/sql) и обучаем специалистов у заказчика.