1. Любой хэш придётся пересчитывать. Бывают даже ID составные натуральные+синтетика. То есть приходится для новых данных генерировать хэши в полном объеме и никуда от этого не деться. В случае цифровой подписи, на мой взгляд, достаточно нескольких тестовых клиентов и их ключа. Например, читаем/пишем таблицу в четыре потока — вот пусть и будет четыре подписи. С точки зрения качества данных под тестирование, вроде, не должно быть проблем.
2. На практике пока не сталкивались с подобными проблемами. Но они конечно же возможны.
3. Геоданные — это два набора цифр. Их можно перемешать или можно менять последние три символа числа, или делать с ними ещё что-то подобное. Вопрос, чего вы хотите добиться. Чисто теоретически можно даже генерировать реальный адрес, потом у того же Яндекса запрашивать координаты и подставлять настоящие. Работать это дело будет, безусловно, очень медленно.
Задача решается «профилированием БД». С помощью специальных инструментов и правил читается как вся БД, так и только некая часть данных. Например, 10% от количества строк в таблице, но не менее 200 000. После чего к каждой прочитанной ячейке применяются правила (регулярки) которые говорят «да» или «нет». Например, у нас есть регулярка, которая проверяет, что число является ИНН. Смотрит на размер 10 или 12 чисел, смотрит на то, что на конце контрольные числа и говорит true на каждое успешное вхождение.
Прочитав и обработав таким образом БД мы получаем некий отчет, который потом желательно проверить глазами.
Обычно разработка указывает на 20-30 таблиц с персональными данными, а после профилирования таких таблиц 100-300.
Генерировать новые имена в стиле имя1 один из самых популярных способов. Думаю, что каждый разработчик, который сталкивался с задачей деперсонализации своей БД начинал решать её именно таким образом.
Но, если коротко, такие имена портят селективность, меняют размер индексов, затрудняют работу функциональных тестировщиков, а самое главное коренным образом меняют структуру данных, убирая возможные ошибки в них. Самый простой пример — в реальной БД могут содержаться имена содержащие смешанные буквы латиницы и кириллицы. Фамилия «Семенов» может быть с латинской буквы C, а может быть с русской буквы С.
Разработчики в штате не должны иметь доступ к финансовым данным клиентов.
Скриншоты из Ataccama One, но статья не преследует цели описать какой-то продукт. Больше про наш подход, который может быть реализован и на платформах других вендоров и про маскирование в целом.
Потому что дата рождения — часть базовых предопределённых наборов, составляющих персональные данные. Она в сочетании с другими данными с высокой вероятностью даёт ПД. Да, по логике она редко сама по себе деперсонализирует. Вот наш старый пост про то, как работают ПД.
2. На практике пока не сталкивались с подобными проблемами. Но они конечно же возможны.
3. Геоданные — это два набора цифр. Их можно перемешать или можно менять последние три символа числа, или делать с ними ещё что-то подобное. Вопрос, чего вы хотите добиться. Чисто теоретически можно даже генерировать реальный адрес, потом у того же Яндекса запрашивать координаты и подставлять настоящие. Работать это дело будет, безусловно, очень медленно.
Прочитав и обработав таким образом БД мы получаем некий отчет, который потом желательно проверить глазами.
Обычно разработка указывает на 20-30 таблиц с персональными данными, а после профилирования таких таблиц 100-300.
Но, если коротко, такие имена портят селективность, меняют размер индексов, затрудняют работу функциональных тестировщиков, а самое главное коренным образом меняют структуру данных, убирая возможные ошибки в них. Самый простой пример — в реальной БД могут содержаться имена содержащие смешанные буквы латиницы и кириллицы. Фамилия «Семенов» может быть с латинской буквы C, а может быть с русской буквы С.
Разработчики в штате не должны иметь доступ к финансовым данным клиентов.