Комментарии 24
Логика в том, что если мы замаскировали ФИО пациента в больнице, можно маскировать или не маскировать диагноз — всё равно никто не узнает, от кого он.
Почему такая логика неприменима к дате рождения?
Все-таки дата рождения это самый надёжный случайный хэш для человека. Особенно для относительно небольших выборок в несколько сотен человек. Когда звоню в больницу, школу и тд для быстрого поиска они спрашивают дату рождения пациента студента (пол они знают их контекста) — второго вопроса почти никогда не следует, сразу называют правильную фамилию.
Можно подумать что у банка клиентов десятки тысяч, но, мне кажется, в тестовой БД все равно останутся неизменные параметры — например, год открытия счета, пол, город — которые разобьют всю выборку на группы в несколько десятков /сотен человек. Дата рождения в такой группе почти наверняка деанонимизирует
Логика в том, что если мы замаскировали ФИО пациента в больнице, можно маскировать или не маскировать диагноз — всё равно никто не узнает, от кого он.
сразу вспомнился (возможно несколько теоретический) пример из обсуждения GDPR: если в деревне на сто человек, только один страдает от такого заболевания — то не замаскировав его диагноз — вы автоматом раскрываете его и все остальные не маскированные данные связанные с этим персонажем.
Интересно, если ли opensource решения для обезличивания данных базы PostgreSQL.
Цель обезличивание и копирование продовой базы в тест/препрод/UAT для тестирования.
мы делали кол на имя1, вася на имя2, где 1 и 2 — коды записи
ну и надо разрабов в штат банка взять и не парить с обезличкой
Но, если коротко, такие имена портят селективность, меняют размер индексов, затрудняют работу функциональных тестировщиков, а самое главное коренным образом меняют структуру данных, убирая возможные ошибки в них. Самый простой пример — в реальной БД могут содержаться имена содержащие смешанные буквы латиницы и кириллицы. Фамилия «Семенов» может быть с латинской буквы C, а может быть с русской буквы С.
Разработчики в штате не должны иметь доступ к финансовым данным клиентов.
прочитав заголовок сразу появляется мысль, что автор просто не понимает ни первого ни второго.
однако по тексту — уже такой явной ошибки вроде нет…
но вчитавшись все же остается впечатление поверхностного изложения
А разработчики банковского ПО данный факт не предусмотрели.Хотя бы должна быть дата последнего обслуживания в банке.
Для тестовой схемы для предоставления сторонним разработчикам согласен что нужно маскировать все перс данные и по всем клиентам нужно.
Прочитав и обработав таким образом БД мы получаем некий отчет, который потом желательно проверить глазами.
Обычно разработка указывает на 20-30 таблиц с персональными данными, а после профилирования таких таблиц 100-300.
Пару вопросов, нет ли случаев, и как с ними бороться:
1. Есть хэш / цифровая подпись, и при изменении любого атрибута (имени, даты) — всё портится. А если подпись приватным ключом клиента?
2. С датами, сдвиг без изменения возраста не возможен в принципе. Возможен только без изменения «количества лет» на определённую дату. Поменяли дату на 25 дней раньше, а оказалось что кто-то получил документ ещё не родившись, или сделал что-то раньше чем ему разрешено это по закону. (например снял деньги со вклада до наступления 18 лет).
3. Есть ли обработка геоданных (GPS Координаты)?
2. На практике пока не сталкивались с подобными проблемами. Но они конечно же возможны.
3. Геоданные — это два набора цифр. Их можно перемешать или можно менять последние три символа числа, или делать с ними ещё что-то подобное. Вопрос, чего вы хотите добиться. Чисто теоретически можно даже генерировать реальный адрес, потом у того же Яндекса запрашивать координаты и подставлять настоящие. Работать это дело будет, безусловно, очень медленно.
Работал в финтехе до 2018. Не скажу где, смысл в том, что бэк-офис с покером и программистами был в России, а фронт с продажами и директором в Москве. То есть нагрянуть в бэк ВНЕЗАПНО — эта вероятность была близка к нулю. А у фронтов не было доступа никуда, даже у директора.
Намаявшись с 1 и 2 пришли к тому, что все прогеры работали с дампами реальной базы. Единственное что было захэшировано — номер паспорта, но заклинание для расшифровки тоже каждый знал.
Вроде как нехорошо и все такое, но из-за 1 и 2 работать было ну просто невозможно, вы часть причин описали.
FFaker::Random.seed=user.id
user.name = FFaker::Name.name
user.email = FFaker::Internet.email
…
Profit!
Обезл***вание д***ных — это не просто рандомизация