Комментарии 24
Интересно, а зачем маскировать дату рождения? Ведь она не только не уникальна, но даже не «почти уникальна» (как ФИО, например — в России каждый день рождается почти по 5000 человек, а при Союзе было еще больше). Имея только дату рождения, вряд ли можно сделать какие-то выводы о клиенте, если остальные данные преобразованы до неузнаваемости (разве что о возрасте, но ведь в статье говорится о сдвиге даты с сохранением возраста). Собственно,
Почему такая логика неприменима к дате рождения?
Логика в том, что если мы замаскировали ФИО пациента в больнице, можно маскировать или не маскировать диагноз — всё равно никто не узнает, от кого он.
Почему такая логика неприменима к дате рождения?
Потому что дата рождения — часть базовых предопределённых наборов, составляющих персональные данные. Она в сочетании с другими данными с высокой вероятностью даёт ПД. Да, по логике она редко сама по себе деперсонализирует. Вот наш старый пост про то, как работают ПД.
Все-таки дата рождения это самый надёжный случайный хэш для человека. Особенно для относительно небольших выборок в несколько сотен человек. Когда звоню в больницу, школу и тд для быстрого поиска они спрашивают дату рождения пациента студента (пол они знают их контекста) — второго вопроса почти никогда не следует, сразу называют правильную фамилию.
Можно подумать что у банка клиентов десятки тысяч, но, мне кажется, в тестовой БД все равно останутся неизменные параметры — например, год открытия счета, пол, город — которые разобьют всю выборку на группы в несколько десятков /сотен человек. Дата рождения в такой группе почти наверняка деанонимизирует
Спасибо, интересная статья. Но вот по этому поводу
сразу вспомнился (возможно несколько теоретический) пример из обсуждения GDPR: если в деревне на сто человек, только один страдает от такого заболевания — то не замаскировав его диагноз — вы автоматом раскрываете его и все остальные не маскированные данные связанные с этим персонажем.
Логика в том, что если мы замаскировали ФИО пациента в больнице, можно маскировать или не маскировать диагноз — всё равно никто не узнает, от кого он.
сразу вспомнился (возможно несколько теоретический) пример из обсуждения GDPR: если в деревне на сто человек, только один страдает от такого заболевания — то не замаскировав его диагноз — вы автоматом раскрываете его и все остальные не маскированные данные связанные с этим персонажем.
Да, но там же не 100 человек, а 50 гиг данных и адреса уже изменены, так что никто не узнает, был ли там кто из той деревни
тут кстати другой интересный вопрос: когда говорят о гигабайтах данных — немалая часть из них, ИМХО, это информация о транзакциях и прочая служебные и / или «не персональные» данные, а вот на ФИО, приходится существенно меньшая часть этих гигабайт. И перебор может выдавать уже очень интересные результаты. Там как раз в следующем комментарии от автора — есть ссылка на их же статью про ПД с интересными примерами. ;)
Вот тут мы подробнее писали про то, что считать персональными данными. И про случай с диагнозом там тоже есть.
Интересно, если ли opensource решения для обезличивания данных базы PostgreSQL.
Цель обезличивание и копирование продовой базы в тест/препрод/UAT для тестирования.
менять коля на вася? потом легко обратно поменять
мы делали кол на имя1, вася на имя2, где 1 и 2 — коды записи
ну и надо разрабов в штат банка взять и не парить с обезличкой
мы делали кол на имя1, вася на имя2, где 1 и 2 — коды записи
ну и надо разрабов в штат банка взять и не парить с обезличкой
Разрабы в банке с доступом к живым данным клиентов нарушают принцип наименьших привилегий.
Генерировать новые имена в стиле имя1 один из самых популярных способов. Думаю, что каждый разработчик, который сталкивался с задачей деперсонализации своей БД начинал решать её именно таким образом.
Но, если коротко, такие имена портят селективность, меняют размер индексов, затрудняют работу функциональных тестировщиков, а самое главное коренным образом меняют структуру данных, убирая возможные ошибки в них. Самый простой пример — в реальной БД могут содержаться имена содержащие смешанные буквы латиницы и кириллицы. Фамилия «Семенов» может быть с латинской буквы C, а может быть с русской буквы С.
Разработчики в штате не должны иметь доступ к финансовым данным клиентов.
Но, если коротко, такие имена портят селективность, меняют размер индексов, затрудняют работу функциональных тестировщиков, а самое главное коренным образом меняют структуру данных, убирая возможные ошибки в них. Самый простой пример — в реальной БД могут содержаться имена содержащие смешанные буквы латиницы и кириллицы. Фамилия «Семенов» может быть с латинской буквы C, а может быть с русской буквы С.
Разработчики в штате не должны иметь доступ к финансовым данным клиентов.
Обезличивание и рандомизация?
прочитав заголовок сразу появляется мысль, что автор просто не понимает ни первого ни второго.
однако по тексту — уже такой явной ошибки вроде нет…
но вчитавшись все же остается впечатление поверхностного изложения
прочитав заголовок сразу появляется мысль, что автор просто не понимает ни первого ни второго.
однако по тексту — уже такой явной ошибки вроде нет…
но вчитавшись все же остается впечатление поверхностного изложения
А что вы за продукт описываете? Мы недавно смотрели Redgate Data Masker(для SQL Server), но там конечно не дешевые цены www.red-gate.com/products/dba/data-masker
В нашем банке как то тоже была проблема с обезличиванием перс данных клиентов.Но проблема кроется не с самим процессом обезличиванием информации а выборке записей(т.е. конкретных клиентов, их платежи, взаимосвязи с другими клиентами и прочее).Т.е. согласно закону должны быть обезличены данные по клиентам по которым прошел срок обработки информации(5 лет).
А разработчики банковского ПО данный факт не предусмотрели.Хотя бы должна быть дата последнего обслуживания в банке.
Для тестовой схемы для предоставления сторонним разработчикам согласен что нужно маскировать все перс данные и по всем клиентам нужно.
А разработчики банковского ПО данный факт не предусмотрели.Хотя бы должна быть дата последнего обслуживания в банке.
Для тестовой схемы для предоставления сторонним разработчикам согласен что нужно маскировать все перс данные и по всем клиентам нужно.
А как-то решается задача обеспечения полноты обезличивания? Когда работал в банке сталкивался, что основные очевидные таблицы были обезличены, но в дальних неочевидных уголках (типа складского учета оригиналов договоров) можно было все еще найти данные о клиентах.
Задача решается «профилированием БД». С помощью специальных инструментов и правил читается как вся БД, так и только некая часть данных. Например, 10% от количества строк в таблице, но не менее 200 000. После чего к каждой прочитанной ячейке применяются правила (регулярки) которые говорят «да» или «нет». Например, у нас есть регулярка, которая проверяет, что число является ИНН. Смотрит на размер 10 или 12 чисел, смотрит на то, что на конце контрольные числа и говорит true на каждое успешное вхождение.
Прочитав и обработав таким образом БД мы получаем некий отчет, который потом желательно проверить глазами.
Обычно разработка указывает на 20-30 таблиц с персональными данными, а после профилирования таких таблиц 100-300.
Прочитав и обработав таким образом БД мы получаем некий отчет, который потом желательно проверить глазами.
Обычно разработка указывает на 20-30 таблиц с персональными данными, а после профилирования таких таблиц 100-300.
Интересная статья, спасибо.
Пару вопросов, нет ли случаев, и как с ними бороться:
1. Есть хэш / цифровая подпись, и при изменении любого атрибута (имени, даты) — всё портится. А если подпись приватным ключом клиента?
2. С датами, сдвиг без изменения возраста не возможен в принципе. Возможен только без изменения «количества лет» на определённую дату. Поменяли дату на 25 дней раньше, а оказалось что кто-то получил документ ещё не родившись, или сделал что-то раньше чем ему разрешено это по закону. (например снял деньги со вклада до наступления 18 лет).
3. Есть ли обработка геоданных (GPS Координаты)?
Пару вопросов, нет ли случаев, и как с ними бороться:
1. Есть хэш / цифровая подпись, и при изменении любого атрибута (имени, даты) — всё портится. А если подпись приватным ключом клиента?
2. С датами, сдвиг без изменения возраста не возможен в принципе. Возможен только без изменения «количества лет» на определённую дату. Поменяли дату на 25 дней раньше, а оказалось что кто-то получил документ ещё не родившись, или сделал что-то раньше чем ему разрешено это по закону. (например снял деньги со вклада до наступления 18 лет).
3. Есть ли обработка геоданных (GPS Координаты)?
1. Любой хэш придётся пересчитывать. Бывают даже ID составные натуральные+синтетика. То есть приходится для новых данных генерировать хэши в полном объеме и никуда от этого не деться. В случае цифровой подписи, на мой взгляд, достаточно нескольких тестовых клиентов и их ключа. Например, читаем/пишем таблицу в четыре потока — вот пусть и будет четыре подписи. С точки зрения качества данных под тестирование, вроде, не должно быть проблем.
2. На практике пока не сталкивались с подобными проблемами. Но они конечно же возможны.
3. Геоданные — это два набора цифр. Их можно перемешать или можно менять последние три символа числа, или делать с ними ещё что-то подобное. Вопрос, чего вы хотите добиться. Чисто теоретически можно даже генерировать реальный адрес, потом у того же Яндекса запрашивать координаты и подставлять настоящие. Работать это дело будет, безусловно, очень медленно.
2. На практике пока не сталкивались с подобными проблемами. Но они конечно же возможны.
3. Геоданные — это два набора цифр. Их можно перемешать или можно менять последние три символа числа, или делать с ними ещё что-то подобное. Вопрос, чего вы хотите добиться. Чисто теоретически можно даже генерировать реальный адрес, потом у того же Яндекса запрашивать координаты и подставлять настоящие. Работать это дело будет, безусловно, очень медленно.
Работал в финтехе до 2018. Не скажу где, смысл в том, что бэк-офис с покером и программистами был в России, а фронт с продажами и директором в Москве. То есть нагрянуть в бэк ВНЕЗАПНО — эта вероятность была близка к нулю. А у фронтов не было доступа никуда, даже у директора.
Намаявшись с 1 и 2 пришли к тому, что все прогеры работали с дампами реальной базы. Единственное что было захэшировано — номер паспорта, но заклинание для расшифровки тоже каждый знал.
Вроде как нехорошо и все такое, но из-за 1 и 2 работать было ну просто невозможно, вы часть причин описали.
FFaker::Random.seed=user.id
user.name = FFaker::Name.name
user.email = FFaker::Internet.email
…
Profit!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обезл***вание д***ных — это не просто рандомизация