Представьте большую компанию с миллионами клиентов. У такой в IT-архитектуре есть среды двух видов: промышленная с персональными данными людей и тестовая. Последняя нужна, например, чтобы анализировать клиентскую базу, обучать ML-модели, тестировать интеграции перед релизом.
Хорошо бы положить в тестовую среду те же данные, что хранят на проде. Тогда, например, интеграцию проверят на особенностях реальной базы — учтут пустые поля, опечатки в адресах и ФИО, недействительные паспорта. А значит, тестировщики заметят больше неочевидных багов.
Но переливать сведения с прода на тест опасно, ведь это персональные данные. На тестовый контур часто пускают десятки человек — и внешних подрядчиков, и сотрудников компании. К тому же, тестовую среду обычно хуже защищают от злоумышленников. Стоит перелить ПД клиентов на тестовый контур, как кто-нибудь выложит информацию в интернет. И все: суды, штрафы по 152-ФЗ, испорченная репутация. Безопасники этого не допустят.
Иногда обезличенные данные так отличаются от «живых», что невозможно нормально тестировать и обучать ML-модели
Чтобы избежать рисков, персональные данные обезличивают и уже потом заливают на тестовый контур. Но часто замаскированные сведения оказываются бесполезными.
Вот пример.
Наш продукт «Фактор» определяет оператора для номера телефона — это одна из функций. Присылаешь «+7 926 024-43-26», программа отвечает: «„Мегафон“».
Тут «Фактор» пускают в тестовую среду с замаскированными данными и говорят: «Гляди, вот телефон — 8**********2, назови-ка оператора». Программа смотрит на звездочки и не представляет, что делать. Как тестировать продукт — неясно.
Чтобы тестировать интеграции и получать ценные выводы от ML-моделей, важно обезличить информацию по-умному. То есть сохранить исходные смысл и качество данных:
гендерный баланс;
социально-демографическую структуру;
родственные связи;
страну и оператора в телефоне;
валидность паспортов, ИНН, СНИЛС;
очевидные ошибки в данных. Например, бессмысленный набор цифр в поле «телефон» оставить бессмысленным.
Мы сделали продукт «Маскировщик» — промышленный софт, который обезличивает персональные данные, сохраняя качество и смысл. Он принимает на вход изолированные кусочки данных: например, за 45 секунд обезличит миллион телефонов. А еще — сплошные тексты: найдет ПД в документе и замаскирует.
В этой статье пролью свет на методы изменения состава и семантики, которые использует продукт. Для простоты буду называть их «алгоритмами маскирования». Расскажу, по какой логике продукт меняет одни данные другими, какие ограничения и как учитывает.
Как обычно обезличивают данные и почему эти техники не всегда работают
Часто используют две техники обезличивания.
Заменяют часть букв и цифр на звездочки. «Иван Петров» → «И**н П****в». У такого подхода две проблемы:
Звездочки в числах и датах влияют на тип данных. Если, например, заменить телефон «8 926 118 12 12» на «89***12», программы не поймут, что перед ними номер. А значит, сведения будут бесполезными для аналитики и тестов.
Смысл данных исчезает. Скажем, в базе хранили Ивана Иванова с телефоном +8 926 011–12–32, который родился 21.02.1979. Сразу видно — 43-летний мужчина из Москвы. Но звездочки превратили сведения в бессмыслицу: «И**н Ив», «+8 * * », «2.0.1**9». Пропала информация о поле, возрасте и адресе.
Заменяют одни буквы и цифры другими. «Иван Петров» → «Усвы Щвачса». Такая техника сохраняет типы данных, но портит качество и полноту.
Допустим, мы обезличили клиента:
Наталья Сергеевна → Нонингел Гльпдбч Мношннагп;
21.07.1961 → 11.02.1973;
6806 108711 → 7187 315818.
Вместо 61-летней жительницы Тамбова с действующим паспортом получили 50-летнего человека из Тулы с недействительным документом и неизвестным полом. Такие данные испортят соцдем‑исследование и не пройдут форматно‑логические проверки.
Мы маскируем даты рождения, сохраняя возраст
Представьте: ML‑модель в банке вычисляет продукты, которые уместно предложить подписчикам рассылки. Маркетолог дает обезличенные сведения о человеке, модель их анализирует и подбирает варианты. Результат зависит в том числе от возраста клиента. Если очень упрощать, 20-летнему юноше модель посоветует ипотеку, пенсионеру — вряд ли.
Если замаскировать даты рождения клиентов случайным образом, возраст изменится и ML‑модель будет советовать глупости. Например, пенсионные вклады вместо кредитов на жилье. Чтобы не раздражать маркетологов, важно сохранить возраст клиентов в обезличенной базе.
Логика обезличивания. Мы разделяем дату рождения на два компонента: «год» и «день.месяц». Компоненты будем маскировать отдельно друг от друга.
На возраст в основном влияет год рождения: заменишь 2006 на 1956, и школьник станет пенсионером. Поэтому мы маскируем исходный год в соседний — к значению прибавляем или вычитаем заданную величину, например, «2». Скажем, 1998 обезличим в 1996 или 2000.
День и месяц рождения влияют на возраст минимально — с точностью до года. Поэтому мы изменяем их случайным образом. Скажем, «25.09» — на «10.03».
Допустим, сегодня 24.09.
Возьмем для примера 20-летнюю девушку, которая родилась 25.09.
Если заменим дату рождения на 10.10, возраст не изменится. По состоянию на 24.09 девушке по‑прежнему будет 20 лет.
Если заменим дату на 23.09, то увеличим возраст девушки на год: с 20 до 21. А если заодно вычтем «2» из года рождения, то суммарно увеличим возраст на три года — с 20 до 23.
Нашим заказчикам такой разброс кажется нормальным, потому что не влияет на процессы. Условно, ML‑модель банка предложит ипотеку и 20-летней, и 23-летней девушкам. Три года разницы не повлияют на вывод нейронки.
❗Ограничение. Бывает, при маскировании нельзя менять возраст ни на год. Дело в том, что от числа лет зависят права и возможности человека. Например, 17-летнему юноше не дадут ипотеку, поэтому он вряд ли интересен банку как клиент. А вот 18-летнему — вполне.
Мы учитываем, в какой из трех интервалов попадает исходный возраст человека:
младше 14 лет — без паспорта;
от 14 до 18 лет — с паспортом, но несовершеннолетний;
от 18 лет — совершеннолетний с паспортом.
И проверяем, входит ли замаскированный возраст в одну категорию с исходным. Если выбивается, подбиваем год рождения.
Например, исходный год рождения — 2008. Человеку 15 лет. Возраст входит в интервал «14 — 18».
Мы прибавили к году рождения «2» — знак операции выбрали случайно. Получился 2010 год. Теперь человеку 13 лет, и он выпадает из исходной категории. Это ошибка.
Тогда мы меняем знак операции и вычитаем «2» из исходного года рождения. Получился 2006 год. Теперь человеку 17 лет, и он входит в исходную категорию. То что нужно.
Такие интервалы зашили в дефолтную логику маскирования, но можем настроить любые — смотря что важно заказчику. Например, проверим, пересек ли человек границу пенсионного возраста.
❗Еще ограничение. Если дата рождения равна текущей, мы пробрасываем ее в ответ как есть. Дело в том, что сегодняшний день в качестве даты рождения похож на ошибку. Такое полезно подсвечивать, а не маскировать.
Вряд ли человек утром родился, а в обед пришел в страховую за полисом. А вот в роддоме или ЗАГСе дата рождения «Сегодня» — обычная практика. Среди наших заказчиков таких пока нет, но если будут, правило для них отменим.
❗И еще ограничение. Бывает, в дате рождения указывают день из будущего или из далекого прошлого — раньше 1900 года. Это явные ошибки, поэтому мы замаскируем день рождения так, чтобы их подсветить.
Например, исходный год рождения — 2024.
Будь это дата из настоящего, мы бы случайным образом изменили значение на заданную величину. Например, на «2». В результате получили бы 2022 или 2026 год рождения.
Но раз исходный год рождения не наступил, то замена на 2022 год не годится. В этом случае дата из будущего станет датой из настоящего. Поэтому из двух возможных вариантов «Маскировщик» выберет «2026» — другой год из будущего.
Сохраняем валидность паспорта — привязываем серию к году рождения и дате выдачи документа
По серии паспорта видно, в каком регионе России выдали документ и в каком году напечатали бланк. Если заменить исходные цифры случайными, окажется, например, что бланк напечатали в 2075 году. Так не бывает: паспорт окажется невалидным и не пройдет форматно‑логический контроль.
Чтобы при обезличивании сохранить валидность паспорта, важно понимать, какие сведения зашифровали в его реквизитах. А еще — как эти сведения зависят друг от друга. О таких взаимосвязях мы подробно рассказывали в статье о проверке паспорта на действительность.
Логика обезличивания. Мы отделяем серию паспорта от номера — первые четыре цифры от следующих шести.
Первые две цифры серии — регион, в котором выдали паспорт. Значения берут из справочника ОКАТО. Например, 77 — Москва. Эти цифры при маскировании не изменяем.
Следующие две цифры серии — год печати бланка. Бланки печатают с 1997 года, так что значения попадают в диапазоны 97–99 и 00–23. Исходные цифры можно было бы сохранить без изменений, если бы не ограничение. О нем расскажем ниже.
Цифры номера не несут полезной информации, помимо самих себя. Поэтому мы заменяем их случайным образом. Скажем, «1 234 567» — на «7 654 321».
❗Ограничение. Сходу кажется, что при маскировании достаточно изменить номер паспорта, а цифры серии можно сохранить без изменений. В результате получим документ, который выдали в том же регионе и на бланке того же года, что исходный.
На деле сохранить серию не выйдет, если мы меняли год рождения человека и день выдачи документа. Если не согласовать эти даты с годом печати бланка в серии, документ не пройдет форматно‑логический контроль.
Давайте разбираться на примере.
Возьмем паспорт со следующими параметрами: 2004 год рождения, 2018 год выдачи паспорта, 2022 год печати бланка.
Заметьте, год печати бланка моложе года выдачи паспорта. Это норма, например, для Москвы. В столице часто не хватает бланков, которые отпечатали на год, поэтому бланки грядущих лет выпускают раньше срока.
Допустим, мы изменили дату рождения: 2004 → 2002.
Паспорт в России выдают в 14, 20 и 45 лет, поэтому допустимые годы выдачи замаскированного документа — 2016 или 2022. Исходный 2018 не годится: получится, что человек получил паспорт в 16 лет. Это противоречит законодательству.
Исправим нестыковку: подтянем год выдачи паспорта к измененной дате рождения: 2018 → 2016.
Возникает новая проблема. Важно, чтобы дата выдачи паспорта попадала в интервал от «год печати бланка − 5 лет» до «год печати бланка + 3 года». Такое правило мы обнаружили, изучив 100 млн паспортов.
Выходит, если паспорт выдали в 2016 году, бланк должны были напечатать между 2013 и 2021. Исходный 2022 выглядит подозрительно.
Чтобы паспорта проходили форматно‑логический контроль, мы привязываем год печати бланка к дате выдачи паспорта и году рождения. Изменяем значения на одну и ту же дельту.
Возьмем клиента из примера выше. Год его рождения при маскировании уменьшили на «2». Значит, годы выдачи паспорта и печати бланка тоже уменьшим на «2»: 2018 → 2016, 2022 → 2020.
Получился паспорт со следующими параметрами: 2002 год рождения, 2016 год выдачи паспорта, 2020 год печати бланка. Это валидный документ.
Сохраняем пол и популярность имени
Не хорошо, если Иван из исходной базы сменит пол и станет Ларисой на тестовом стенде. Или превратится в бесполое «Шцвв». Это запутает аналитиков и ML‑модели.
Вспомните нейронку — ту, что вычисляет подходящие продукты для клиентов банка. Маркетолог выдаст ей сведения о Ларисе, которая на самом деле — Иван. Нейронка примет мужчину за женщину и посоветует, например, карту с кэшбеком в салоны красоты. Реклама сработает хуже ожидаемого.
Логика маскирования. Мы делим ФИО на три компонента: имя, фамилию и отчество. Каждый компонент ищем в специальном справочнике, о котором расскажем ниже. Определяем пол и популярность найденного компонента — эти значения уже лежат в справочнике. И подбираем замену того же пола и популярности.
Давайте разбираться на примере:
Возьмем ФИО «Иван Иванович Иванов» и разделим его на гранулы: «Иван», «Иванович», «Иванов».
В справочнике имен найдем «Иван». Это имя мужского пола, с популярностью «100» — очень популярное.
Теперь в справочнике выберем случайное мужское имя с аналогичным показателем популярности — «Ильяс». Все верно, в 2023 году это одно из самых популярных российских имен.
Заменим «Иван» на «Ильяс». Аналогичную процедуру провернем с фамилией и отчеством: «Иванович» станет, например, «Петровичем», а «Иванов» — «Сергеевым».
В результате «Иван Иванович Иванов» превратился в «Ильяса Петровича Сергеева». А условная «Абжалбек Абдоловна Иванова» стала бы, скажем, «Абдыш Абизовной Лебедевой». Редкие имя и отчество остались бы редкими.
Справочник. Мы заменяем одни существующие имена, фамилии и отчества другими, которые нужно где‑то брать. Поэтому нам не обойтись без справочника с компонентами ФИО. В интернете таких полно, но для нашей задачи важно соответствие трем требованиям:
Компонентам ФИО в справочнике проставили пол.
Для каждой фамилии, имени и отчества рассчитали показатель популярности.
Собрали как можно больше экзотики. Дело вот в чем: чтобы узнать популярность исходных фамилий, имен и отчеств, нужно сперва найти их в справочнике. И чем больше там вариантов, тем выше шанс отыскать редкие.
Мы используем собственный справочник ФИО, который пополняем больше 10 лет. Внутри — 891 тыс. фамилий, 99 тыс. имен и 200 тыс. отчеств. Поэтому мы без проблем маскируем редкие ФИО.
В открытом интернете справочников такой полноты не найти. Например, в справочнике ФИО Портала «Данные НКО» лежат 48 тыс. фамилий, 5 тыс. имен и 7 тыс. отчеств. В разы меньше, чем у нас.
❗Ограничение. Встречаются имена, отчества и фамилии, которых нет даже в нашем справочнике. Такие компоненты мы замаскируем посимвольно: гласную букву заменим гласной, согласную — согласной. ФИО будет нечитаемым, но с этим ничего не поделать, увы. Нет справочников, которые включали бы все‑все ФИО на свете.
Например, «Дракарис Иванов» превратится в «Лметэщяб Петрова». Со временем имя «Дракарис» в России станет заметным, мы добавим его в справочник и будем маскировать в условного «Джоффри».
❗И еще ограничение. С именем «Иван» все просто — это мужское имя, которое достаточно заменить другим того же пола. Но иногда нужно замаскировать, например, «Адель». В нашем справочнике имя встречается дважды — как мужское и женское. В такой ситуации мы используем алгоритм:
Проверяем, вдруг вместе с ФИО нам сообщили пол — как одну из гранул. Если да, подбираем новое имя того же пола.
Если пол не передали, пробуем самостоятельно его определить из строки с ФИО. Например, по отчеству сообразим, что у «Адель Ивановны» пол женский.
Если и тут определить пол не получилось, проверим, у формы какого пола популярность выше. Например, мужское имя «Адель» популярнее женского. Значит, заменим исходное, допустим, «Степаном».
А еще нам часто попадаются фамилии, которые бывают и мужскими, и женскими. Такие мы заменяем аналогичными: скажем, «Манько» на «Бурко». Как это работает — в следующем разделе.
Сохраняем родственные связи
Представьте, что в базе хранят Ивана Петровича Худина и его дочь — Ольгу Ивановну Худину.
Родственную связь легко потерять при маскировании: например, обезличить отца в Сергея, а дочь сделать Васильевной. Или замаскировать отца в «Бабина», а дочь сделать «Травиной».
Это станет проблемой, например, если ML‑модель учитывает домохозяйства.
Вернемся к нейронке из банка. Маркетолог отправит ей сведения о клиентах — супругах с детьми. Модель проанализирует информацию, но из‑за разницы в отчествах и фамилиях не распознает в людях родственников. В результате предложит продукты, которые выбирают бездетные холостяки.
Логика маскирования. Чтобы сохранить родственные связи, мы заменяем одни имена, отчества и фамилии другими не абы как, а консистентно.
Начинается самая сложная часть статьи, давайте разбираться на примерах.
Допустим, однажды в рамках сессии маскирования мы заменили Олега на Илью.
Это мужские имена, а значит, они дают по два производных отчества — мужскую и женскую формы: «Олегович» и «Олеговна», «Ильич» и «Ильинична». Такие формы мы заранее записали в справочнике ФИО — рядом с каждым мужским именем.
Группируем по парам производные отчества от имен «Олег» и «Илья»: мужскую форму — с мужской, женскую — с женской. То есть «Олегович» — «Ильич», «Олеговна» — «Ильинична».
Пары запомним — запишем в кэш.
Перед тем как замаскировать очередное имя и отчество, проверим кэш. Если для исходных компонентов уже подбирали пары, возьмем замены из памяти.
Если встретим еще тысячу Олегов в базе, заменим каждого Ильей — вспомним о подобранной паре. Аналогично всех Олеговичей превратим в Ильичей, каждую Олеговну в Ильиничну.
Кэш храним до тех пор, пока пользователь его не сотрет. Поэтому получится по одним правилам маскировать базу в несколько заходов — с перерывами. Или одинаково обезличить несколько тестовых стендов.
Скажем, мы замаскировали базу клиентов, а через месяц решили ее актуализировать — добавить «свежих» клиентов. Возьмем кэш месячной давности, и каждый новый Олег без проблем станет Ильей.
Если стереть кэш, Олега заменим уже не Ильей, а, скажем, Петром. Тогда тысячи других Олегов — Петрами.
❗Ограничение. Как правило, мужское имя дает два производных отчества:
мужскую форму — Олегович, Ильич;
женскую форму — Олеговна, Ильинична.
Мужскую форму отчества мы заменяем мужской формой другого отчества, женскую — женской. В кэш достаточно записать две пары замен: «Олегович» — «Ильич», «Олеговна» — «Ильинична».
Но бывает, имя дает больше двух производных отчеств. Например, имя Никита — формы Никитич, Никитович и Никитична. В этом случае двух замен в кэше не всегда достаточно.
Допустим, мы заменили «Никита» на «Олег».
Имя «Олег» дает одну мужскую форму отчества — «Олегович». Имя «Никита» — две: «Никитич» и «Никитович». Эти формы мы заранее записали в справочнике ФИО рядом с именем Никита.
В кэш запишем пары: «Никитич» — «Олегович», «Никитович» — «Олегович». И пару женских форм.
Но представьте обратную ситуацию: мы заменили «Олег» на «Никита». Тогда для отчества «Олегович» нужно подобрать единственную замену — либо «Никитич», либо «Никитович». Мы выберем ту форму, у которой выше показатель популярности в справочнике ФИО.
В кэш запишем одну мужскую пару: «Олегович» — «Никитич». И женскую, конечно.
Какой бы из вариантов отчества ни был у человека, консистентность замен мы сохраним.
Например, в базе встретили Никиту и его сына Ивана Никитича. Имя отца заменим на «Олег», отчество сына — на «Олегович».
Если сын окажется не Никитичем, а Никитовичем, это не повлияет на алгоритм. Любое из отчеств все равно заменим на «Олегович».
❗Еще ограничение. Фамилии, как правило, тоже образуют по две формы:
мужскую — «Травин», «Иванов»;
женскую — «Травина», «Иванова».
Мужскую форму одной фамилии мы заменяем мужской формой другой фамилии, женскую — женской. В кэш записываем две пары замен: «Травин» — «Иванов», «Травина» — «Иванова». Все, как при маскировании отчеств.
Но для части фамилий существует больше двух форм. Так происходит из‑за разницы в ударениях.
Представьте фамилию «Дубовый» — мужскую.
У такой есть женская пара — «Дубовая».
Но, что если ударение в женском варианте фамилии поставить на третий слог — не «Дубóвая», а «Дубова́я»? Тогда парой для нее будет вовсе не «Дубóвый», а «Дубовóй».
При этом встречается и женская форма украинской фамилии «Дубóвая». Ее мужская пара — «Дубóвий». Пишут через «и», а читают через «ы» — «Дубовый». Такие особенности языка.
Стоит в фамилии «Дубовий» поставить ударение на последний слог, как фамилия перестанет склонятся — «ДубовИй». Это одновременно и мужская, и женская форма.
Разумеется, никто не указывает в клиентских базах фамилии с ударениями. Поэтому при обезличивании легко потерять родственные связи:
На вход передали отца и дочь — «Иван Дубовый» и «Ирина Дубовая». Фамилию мужчины заменили на «Травин», его дочери — на «Травина».
Замены «Дубовый» — «Травин» и «Дубовая» — «Травина» записали в кэш. Пока все консистентно.
Но тут на вход мы получаем других отца и дочь — «Олег Дубовой» и «Елена Дубовая». Для фамилии дочери замену берем из кэша: «Дубовая» — «Травина». А для фамилии отца в кэше замены нет: «Дубовой — ×»
Придется изменить фамилию мужчины, теряя родственную связь.
Чтобы не терять родственников, в справочнике ФИО мы заранее сгруппировали фамилии, которые без ударения одинаково выглядят на письме. Например, в одной группе лежат четыре варианта фамилии из примера выше:
Дубовый — мужская фамилия;
Дубовая — женская (два варианта ударений);
Дубовой — мужская (пара к женской «Дубова́я»);
Дубовий — и мужская, и женская (если ударение на «И»). Или мужская украинская (если ударение на «О»).
Если маскируем фамилию из подобной группы, подбираем замены для каждой фамилии‑ одногруппницы. И записываем в кэш.
При этом для замены важно взять группу, которая включает формы тех же полов, что исходная. Иначе одному из вариантов не хватит пары в кэше.
Возьмем для примера уже знакомую группу из четырех фамилий: «Дубовый», «Дубовая», «Дубовой», «Дубовий».
Попробуем заменить ее группой из двух фамилий: «Травин», «Травина». Для этого составим пары по полу:
Дубовый — Травин;
Дубовой — Травин;
Дубовая — Травина;
Дубовий — ×.
Последняя фамилия — и мужская, и женская одновременно. Нельзя заменить ее ни мужской формой «Травин», ни женской «Травина». Это будет ошибкой.
Поэтому для маскирования подберем группу фамилий, аналогичную исходной по содержанию. Такую, которая состоит из >2 вариантов фамилий, один из которых не склоняется.
Это, например, группа из трех фамилий: «Круглый», «Круглая», «Круглий».
Теперь всем формам фамилии хватит замен.
Дубовый — Круглый;
Дубовой — Круглый;
Дубовая — Круглая;
Дубовий — Круглий.
Сохраняем регистры в ФИО
Фамилии, имена и отчества в базе данных записывают как попало: строчными буквами, заглавными, строчными и заглавными через одну.
Зоопарк вариантов мешает доставлять заказы, рассылать письма и анализировать клиентскую базу. Поэтому обычно заказчики просят нас привести варианты к единому формату.
Но в случае обезличивания задача обратная — оставить кавардак из исходной базе. Мы поступаем следующим образом:
имя, которое записали только заглавными буквами, заменим именем из заглавных букв. Имя из строчных — именем из строчных. Например, «ВИКТОРИЯ» → «ЕЛИЗАВЕТА» или «анастасия» → «мария»;
первую заглавную букву в имени оставим заглавной. «Кристина» → «Ирина»;
если в имени встречаются и заглавные, и строчные буквы, посчитаем, каких больше. Замаскированное имя напишем в превалирующем регистре. Например, в имени «аНаСтАсИя» четыре заглавные буквы и пять строчных. Поэтому мы заменим его строчным «кристина». А в имени «А‑н-А‑с-Т‑а-С‑и-Я» больше заглавных, поэтому трансформируем в условное «Е‑Т-И‑П-Б‑У-М‑Е-О». Замаскировали посимвольно, потому что исходного «А‑н-А‑с-Т‑а-С‑и-Я» в справочнике не нашли.
Сохраняем страну, город и район в адресе
Негоже, если коренной петербуржец на тестовом стенде станет москвичом, а житель Смоленской области — жителем Камчатского края. Поэтому мы сохраняем географию.
Логика маскирования. Для исходного адреса вычисляем уровень в ГАР — адресном справочнике налоговой. Уровень — это, например, город, улица или дом. Чем выше уровень, тем адрес точнее.
Скажем, Московская область — 1 уровень. А Россия, Москва, ул. Сухонская, д 11 — 8 уровень.
Затем выбираем в ГАР другой адрес того же уровня с нужным «родителем» — уровнем, который важно сохранить в замаскированном адресе.
Сейчас «родитель» — априори регион или город регионального значения: Москва, Санкт‑Петербург, Севастополь или Байконур. Такая точность устраивает наших заказчиков. Но если нужно, сохраним «родителя», которого пожелает клиент — хоть конкретный район города.
Давайте разбираться на примере:
Возьмем адрес «ЦАО, Московская область, г Можайск, ул Московская». Его уровень по ГАР — «7», улица (в терминах справочника — «STREET»). Значит, мы знаем улицу, а ничего более детального, типа дома или квартиры, нет.
Мы маскируем часть адреса ниже региона. Регион тут — «Родитель».
Тогда выбираем случайный идентификатор адреса (ГАР ID) в Мособласти с уровнем «7». Скажем, d5396ca3–750f-4047–894d-2716c4168f7f.
Осталось расшифровать идентификатор — узнать значения гранул из справочника ГАР. Получится адрес «ЦАО, Московская область, г Люберцы, ул Урицкого».
Справочник. Мы заменяем одни существующие адреса другими, которые нужно где‑то брать. Используем справочник ГАР — самый полный из официальных и доступных. Подробности о том, как устроен ГАР, рассказали в отдельной статье на «Хабре».
❗Нюанс. Иногда мы получаем адреса с точностью до страны или региона. Например, «Россия» или «Россия, Бурятия». Такие вовсе не изменяем — адрес не тянет на персональные данные.
❗Ограничение. Бывает, в исходном адресе пропускают часть уровней — «Россия, Солнечная ул. 3». Это адрес первого уровня по ГАР — «Россия», а мы такие не изменяем. Но раз улицу указали, замаскируем адрес с точностью, которую пожелает заказчик — до города, улицы или дома. Для этого пойдем на уловку:
Подберем адрес, хоть сколько-то похожий на исходный. Для этого отправим строку нашему продукту «Фактор». Он предположит, какой адрес имели в виду. Вряд ли угадает, но лучше, чем ничего.
Скажем, для «Россия, Солнечная ул. 3» «Фактор» предположит «Москва, Царицыно, ул Солнечная д. 3».
Дальше идем по стандартному алгоритму. Выбираем случайный ID уровня «улица» в Москве — b0d6bb92-119f-405c-bcd1-5b88a87cb209. И расшифровываем в «Москва, ул Петровка, д 17».
Следующий шаг — маскирование документов
Это не все, что умеет «Маскировщик». Сервис без потери качества замаскирует:
телефоны,
емейлы,
инициалы ФИО,
реквизиты банковских карт и счетов,
водительские удостоверения,
реквизиты юрлиц,
паспорта транспортных средств,
СНИЛС.
Протестировать обезличивание можно в демо‑форме на странице «Маскировщика». На сайте работает облачная версия продукта, которая заменяет одни персональные данные другими, но не учитывает их взаимосвязи. Консистентные замены — в «коробке».
Пока писали статью, разработчики научили сервис маскировать ФИО, адреса, СНИЛСы, ИНН и названия компаний в сплошном тексте. Например, договорах или сообщениях из онлайн‑чата. Можно прислать текст целиком — «Маскировщик» найдет персональные данные в полотне слов и обезличит. Пока в бета‑версии.
